ONTAP9でボリューム削除して再作成しようとしたら空き容量がないと言われる


NetApp ONTAP8 7-modeで使用中のボリュームがあり、それをNetApp ONTAP9.5環境に対してtransitionのsnapmirrorを行った。

が・・・元ボリュームがqtree snapmirror中であったため、最後の処理で失敗した。(event log showの結果より)

1/14/2020 05:52:49  netapp95         ERROR         smc.snapmir.init.fail: Initialize from source volume 'netapp7mode:vol211' to destination volume 'netapp95svm:vol211' failed with error 'Transfer failed.'. Relationship UUID 'a3555a83-3360-11ea-a0b6-00a098f844df'.
1/14/2020 05:52:49  netapp95         ERROR         replication.dst.err: SnapMirror: destination transfer from netapp7mode:vol211 to vol211 : replication transfer failed to complete.
1/14/2020 05:52:49  netapp95         ERROR         snapmirror.dst.OnlineErr: SnapMirror not able to bring destination volume vol211 online, CR_TRANS_QTREE_REPLICA.
1/14/2020 05:52:46  netapp95         ERROR         wafl.voltrans.qtree.replica: The source of volume vol211 is a qtree replica. It cannot be transitioned to clustered Data ONTAP.

これについては、元のボリューム(netapp7mode:vol211)が受け側となっているqtree snapmirror全てに対して、「snapmirror quiesce netapp7mode:/vol/vol211/~」 と「snapmirror break netapp7mode:/vol/vol211/~」 を実行し、snapmirrorのステータスが「Broken-off」であれば7mode→ONTAP9へのtransition snapmirrorが成功することを確認。

で、snapmirrorの初期化(snapmirror initialize)にした場合、受け側のボリューム(今回はnetapp95svm:vol211)を削除して、再作成する必要がある。

netapp95上で「snapmirror delete -destination-path netapp95svm:vol211」でsnapmirror登録を消した後、ボリュームを「volume offline -vserver netapp95svm -volume vol211」でオフラインにしてから「volume delete -vserver netapp95svm -volume vol211」 で削除。

そして、「volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP」で作成!

netapp95::> volume create -vserver netapp95svm -volume vol211 -aggregate aggr名 -size 22t -state online -type DP
[Job 351] Job is queued: Create vol211.                                        

Error: command failed: [Job 351] Job failed: Failed to create the volume on
       node "netapp95svm". Reason: Request to create volume "vol211" failed
       because there is not enough space in aggregate "aggr名". Either
       create 10.9TB of free space in the aggregate or select a size of at most
       11.2TB for the new volume. 
netapp95::>

おや?

netapp95::> storage aggregate show
Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
--------- -------- --------- ----- ------- ------ ---------------- ------------
<略>
aggr名 
           29.41TB   11.29TB   62% online       2 netapp95svm      raid_dp,
                                                                   normal
<略>
netapp95::>

まだ使用中という認識になっている???

いろいろ調べた結果、ONTAP 8.3より導入されたVolume Recovery Queueにより、削除したボリュームは12時間残しておく、という機能によるものだった。

How to use the Volume Recovery Queue feature in clustered Data ONTAP 8.3
How to enable the volume recovery queue in clustered Data ONTAP 8.3
After deleting a volume, the volume is brought offline with type DEL

強制的に削除するにはdiagモードにあるvolume recovery-queue purgeを使用する。

netapp95::> set diag 
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y

netapp95::*> volume recovery-queue show
Vserver   Volume      Deletion Request Time     Retention Hours
--------- ----------- ------------------------  ---------------
netapp95svm vol211_1032_1032 
                      Thu Jan 16 14:33:18 2020               12

netapp95::*> 

上記の「volume recovery-queue show」で現在保持している削除したボリュームを確認できる。

削除は「volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032」というような感じで実行する。

netapp95::*> volume recovery-queue purge -vserver netapp95svm -volume vol211_1032_1032 
Queued private job: 251                                                        

netapp95::*> volume recovery-queue show
This table is currently empty.

netapp95::*> 

消えたのでaggregateは復活したはず!!!

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
<略>
aggr名                    29TB       18TB       11TB      61%
aggr名/.snapshot            0B         0B         0B       0%
<略>
netapp95::*>

あれ????

なぜだろー??

なぜだろー???としばらく検索してから、再度実行

netapp95::*> df -A -h
Aggregate                total       used      avail capacity
<略>
aggr名                    29TB       16TB       12TB      57%
aggr名/.snapshot            0B         0B         0B       0%
<略>
netapp95::*> 

おや?空き容量が少し増えてる?

「df -A」の実行に切り替えてみると、徐々に空き容量が増えていっていることが判明。

どうやら内部処理に時間がかかっているだけのようでした。

ワコムの廉価液タブWacom Oneの使えるペンとAndroid対応機種


ワコムからEMRペン採用の廉価液晶タブレットWacom Oneが出るそうで

製品ページその1
製品ページその2

ワコムの比較的廉価ラインや他社WindowsタブやAndroidタブで使われるWacom Feel IT technologysのうち、EMRペン(電磁誘導方式ペン)を採用しているとのこと。

(AESペン/ アクティブ静電結合ペンではない)

EMRペンは、ドスパラが出した 絵描き向けWindowsタブレットraytrektab とか、CES2020で発表されたAcerの絵描き向けタブレット(Acer、イーゼルヒンジ採用のクリエイター向けPCなど のクリエイター向けのConceptDシリーズ)とかで使われている。

数年前まではAESペン採用例が多かったけど、最近のワコム採用タブレットというとEMRペン採用例が多いような気がする。

Amazonで簡単に買えるあたりだと↓のような感じ

Samsungスマホ向けの以下も使えるはず。

で、今回のWacom Oneは一部のAndroidでも使えると記載されているのでどんな機種か確認・・・

画像

SamsungとHuaweiの一部のみ対応??

Androidスマホを液晶につないでパソコンみたいにつかう?

そういえば、SamsungもHuaweiもそういったオプションを提供しているぞ、と確認

HUAWEI MateDock 2対応機種

Compatible devices with the HUAWEI MateDock 2

The HUAWEI MateDock 2 is compatible with devices with USB-C and DP ports and supports wired projection. The following phone, tablet, and laptop models are compatible with the HUAWEI MateDock 2: HUAWEI P20 series, HUAWEI P30 series, HUAWEI Mate 10 series, HUAWEI Mate 20 series, HUAWEI Mate RS Porsche Design series, HONOR V20 series, HUAWEI MediaPad M6 10.8″, HUAWEI MateBook series, and HONOR MagicBook series.

Samsung Dex Station対応機種

Samsung DeX device requirements

Mobile Device: Samsung Galaxy S8, S8+, S9, S9+, and Note 8, Note 9, and Tab S4.

Samsungのリストの方はちょっと古いけど、だいたい重複している。

おそらく、Android本体のディスプレイとペンタブ部分を同時に使える機能を実装しているのは、こういった特殊なオプションを用意しているメーカ以外にはないと思うので、これから先もおそらくSamsungとHuaweiの高い機種以外での対応は増えないでしょうね。

もう1つ気になる点は、Wacom Oneとパソコンを繋ぐケーブルについて

画像

こんな感じの液タブ側はType-Cと同じ形状で、そこから3つに分かれたケーブルになり、1つは電源用USBコネクタ、1つはパソコン接続用のUSBコネクタ、1つはディスプレイ出力用のHDMIコネクタとなっている。

この形状、実は中華タブ系統では以前から見かけるものなんです。

たとえば、HUIONのKAMVAS Pro 13 GT-133/Pro 12 GT-116で使われているケーブルはこんな感じ。

画像

Type-C形状のコネクタがL型配置になっているという点も同じですね。

これ・・・もしかして、同じケーブルだったりしますかね?

ちょっと気になるところですが、単品販売が見つからないので試せないですね・・・

どうなんだろうなぁ・・・

会津バスのスマートバス停を見てきた(PAPERCAST製品利用例


2018年2月に会津バスでスマートバス停が実証試験を始めるというニュースがあった。

インプレス:「会津バスに「スマートバス停」、KDDIなど導入支援――LPWA・電子ペーパー活用で外部電源不要
みちのりホールディングズ:「みちのりホールディングス(会津バス)など会津若松市内で国内初となる次世代スマートバス停の実証実験を開始
会津バス:「会津若松市内で国内初となる次世代スマートバス停の実証実験を開始します。

2018年2月17日より運用を始め、設置した2種類をベースに新しいものを2018年4月から1年間で開発する、的なリリースになっていた。

さすがにもう無くなったかな?と会津バスのtwitterアカウントに聞いて見たところ、実用化に課題があるため実証期間を延長し、まだ運用されているとの回答をもらったので見に行ってみた。

まず、見に行ったのは神明通りバス停。

ちょっと離れたところから、会津若松駅方面のバス停をみたところ、なさそうに見えたので、TSUTAYA前の鶴ヶ城方面のバス停を見てみる。

めっちゃ普通のバス停しかない。

おやー?と思ってもう1回会津若松駅方面のバス停の方を見てみると・・・

おや?奥にもう1つバス停がある?

ありました。

2連タイプのバス停です。

ただし、バスロケーションシステムは稼働していませんでした。

まず、時刻表の表示位置が低すぎるのと、文字が細すぎるの2点があるため、バス停の前でしゃがまないと時刻表を読むのが困難でした。

そして、しゃがんでもなお、注意書きとか細かな経路違い表示とかの文字が小さすぎるし、文字の濃淡が薄すぎて読めない・・・

スマートバス停の後ろ側に普通の時刻表がありましたが、こっちのがハッキリしてて見やすいですね。

横に出てるのはLWPAのアンテナなのかな?

ここについているカメラは何の役割なのかな?

バス停の前に立ったらE-Ink表示のリフレッシュが走ったので人感センサーを兼ねてたりするのかな?

時刻表の下にある銀色の丸スイッチを押すと画面のリフレッシュ処理が実行されました。

続いて、鶴ヶ城入口のバス停まで移動・・・

こちらは会津若松駅から来るバスが止まるバス停にありました。

こちらの1画面タイプは、時刻表の表示位置も適切で、表示内容も比較的見やすい感じでした。

よこからみるとこれくらいの大きさで、まぁ、実際に設置するならこれくらいがいいんじゃないかなぁ、と感じました。

こちらのバス停は「PAPERCAST」というロゴが入っていました。

調べて見ると「PAPERCAST E-Paper Bus Stop Passenger Information Display」という既存製品でした。

2画面タイプのもとになっているのでは?というものもありました。

元々WiFi/3G/LTEモジュールを組み込む前提の製品なようで、会津バスで導入するにあたり、LWPAモジュール連動と日本語表示カスタマイズを行ったようです。

PAPERCAST掲載のサンプル例には、日本のマス目レイアウトの1日の全体を表示するような時刻表は無く、次のバスまで何分、というものばかりでした。

顧客が必要なのは「次のバスまで何分」という表示を実現するには液晶だと電力消費が大きいので、E-Inkにする、という感じなのが、もともとのPAPERCAST製品のありかたであるようです。

日本みたいな1日全体の時刻表示のニーズがあまりないんでしょうかねぇ?

1日全体を表示するにはスペースがキツイ、という感じですね。

ちなみにPAPERCAST製品としては、使用するE-Inkディスプレイも、9.7インチ、13.3インチ、23インチ、32インチ、42インチ、57インチが選択できるようです。

このうち32インチモデルはカラー表示も可能なようです。

ハードウェアとしては問題なさそうですが、ソフトウェア面の課題が大きそうです。

はたして本格稼働はいつになることやら?

Oracle CloundのAlways Freeインスタンスが死んだ


Oracleさんから「Production Event Notification: Oracle Cloud Infrastructure Compute – Terminated Instance for Tenant:~」というお手紙が3通来た。

障害でインスタンスを止めた。データは失われてないから新しくインスタンス作ってね。

え・・・?

というわけでログインして確認。

ない・・・

ブートボリュームは?

ちゃんとあった。

お知らせは何かあるかな?と確認

書いてある内容はメールとだいたい一緒。

しかたがないので作り直し。ブートボリュームで作り直すボリュームを選択し、「インスタンスの作成」を選択。

ん?可用性ドメインが「ロード中」のまま動かないのですが・・・

詳細を開くとあるので大丈夫かな?sshキーも指定して「作成」

無事作成完了です。

教訓としては常用するのであればパブリックIPアドレスは予約済みで取得しておかないとダメというところですね。

あと、出先でもインスタンス再作成ができるよう、sshキーのメモをどこかに用意しておかないと・・・

cluster ONTAP/ONTAP9のNFS exports設定にNISホスト名が使えないのでdnsmasqでごまかすことにした


NetAppのcluster ONTAP8.x/ONTAP9はNISを使える、と書いてあるものの、詳細を確認すると、NISホスト名は使用できず、NISユーザとパスワード、NISグループ、NIS netgroup(ホスト名用のグループ)しか使えないとのこと。

NIS netgroup対応といっても、netgroupに含まれるホスト名にNIS ホスト名が許されるわけではなく、DNS起因のホスト名の使用が許される、というものでした。(ONTAPシミュレータで確認)

既存のDNSサーバにエントリを追加してもらえれば解決ではありますが、できるかどうかわからないので、お手軽にできる回避策として、RHEL6/RHEL7などの標準パッケージ群に含まれているdnsmasqを使用した簡易DNSサーバを立ててみることにした。

dnsmasqは/etc/hostsもしくはhostsフォーマットに準じたファイルを指定して、そこのエントリを元にDNS応答を返すことができる。

NISホスト名を「ypcat hosts」で一括出力するとhostsフォーマットでエントリが取得できるので、crontabで定期的に「ypcat hosts」を実行して情報更新を行い、dnsmasqでDNSで応答を返せるようにした。

まずは、DNSサーバのインストール。

[root@nisclient ~]# yum install dnsmasq
読み込んだプラグイン:fastestmirror
インストール処理の設定をしています
Loading mirror speeds from cached hostfile
 * base: ftp.nara.wide.ad.jp
 * extras: ftp.nara.wide.ad.jp
 * updates: ftp.nara.wide.ad.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package dnsmasq.x86_64 0:2.48-18.el6_9 will be インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 パッケージ       アーキテクチャ  バージョン                リポジトリー   容量
================================================================================
インストールしています:
 dnsmasq          x86_64          2.48-18.el6_9             base          150 k

トランザクションの要約
================================================================================
インストール         1 パッケージ

総ダウンロード容量: 150 k
インストール済み容量: 294 k
これでいいですか? [y/N]y
パッケージをダウンロードしています:
dnsmasq-2.48-18.el6_9.x86_64.rpm                         | 150 kB     00:00
rpm_check_debug を実行しています
トランザクションのテストを実行しています
トランザクションのテストを成功しました
トランザクションを実行しています
  インストールしています  : dnsmasq-2.48-18.el6_9.x86_64                    1/1
  Verifying               : dnsmasq-2.48-18.el6_9.x86_64                    1/1

インストール:
  dnsmasq.x86_64 0:2.48-18.el6_9

完了しました!
[root@nisclient ~]#

/etc に配置された設定ファイルを確認。

[root@nisclient ~]# ls -l /etc/dnsmasq.*
-rw-r--r--. 1 root root 21214 10月  3 08:18 2017 /etc/dnsmasq.conf

/etc/dnsmasq.d:
合計 0
[root@nisclient ~]#

NISで配布されたhostsを/etc/hosts-from-nisに保存するということにして、/etc/hosts は使用しない、ということにして、/etc/dnsmasq.conf の以下を変更

変更前
# If you don't want dnsmasq to read /etc/hosts, uncomment the
# following line.
#no-hosts
# or if you want it to read another file, as well as /etc/hosts, use
# this.
#addn-hosts=/etc/banner_add_hosts
変更後
# If you don't want dnsmasq to read /etc/hosts, uncomment the
# following line.
no-hosts
# or if you want it to read another file, as well as /etc/hosts, use
# this.
addn-hosts=/etc/hosts-from-nis

上記以外のエントリは標準設定のままです。NISから配布されたhostsを/etc/hosts-from-nisに保存

[root@nisclient ~]# ypcat hosts > /etc/hosts-from-nis
[root@nisclient ~]# cat /etc/hosts-from-nis
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
172.17.44.100   nfstest
172.17.44.49    server49      server49.vm2.example.com
172.17.44.49    server49      server49.vm2.example.com
172.17.44.87    server87
172.17.44.88    server88
172.17.44.89    server89
[root@nisclient ~]#

続いてfirewalld/iptablesの設定変更して、ポート53のtcp/udpを許可。

[root@nisclient ~]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
[root@nisclient ~]# service iptables restart
iptables: チェインをポリシー ACCEPT へ設定中filter         [  OK  ]
iptables: ファイアウォールルールを消去中:                  [  OK  ]
iptables: モジュールを取り外し中:                          [  OK  ]
iptables: ファイアウォールルールを適用中:                  [  OK  ]
[root@nisclient ~]#

firewalldの場合は以下

-bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

-bash-4.2# firewall-cmd --permanent --zone=public --add-service=dns
success
-bash-4.2# firewall-cmd --reload
success
-bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: dhcpv6-client dns ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

-bash-4.2#

で、dnsmasqを起動して、DNSにより名前解決ができるか確認してみます。

[root@nisclient ~]# service dnsmasq status
dnsmasq は停止しています
[root@nisclient ~]# service dnsmasq start
Starting dnsmasq:                                          [  OK  ]
[root@nisclient ~]# service dnsmasq status
dnsmasq (pid  1556) を実行中...
[root@nisclient ~]#

[root@nisclient ~]# nslookup nfstest 127.0.0.1
Server:         127.0.0.1
Address:        127.0.0.1#53

Name:   nfstest
Address: 172.17.44.100

[root@nisclient ~]#