こんにちは、キクです。
「vol moveって実際のところ何してるの？」
「vol moveについてイメージが湧く解説を読みたい」
NetAppについて調べていると「図がある資料を読みたい」と思うことが多々あります。
上記のような疑問は実際に僕も感じたことですし、他にも感じている方もいるかと思います。
僕は現在NetAppのリプレース作業に従事しており、その中でボリュームの移動も経験することができたので記録として残しておこうと思います。
そんなわけで、今回のテーマはNetAppの『ボリュームの移動』についてです。
本記事の内容
それでは、よろしくお願いします。
事前説明
今回のテーマである『ボリュームの移動』の話に入る前に、次の2点について簡単にお話していきたいと思います。
本記事をお読みいただく上でもイメージしやすくなるかと思いますので、少々お付き合いください。
そもそもボリュームの移動とは何なのか
本記事ではボリュームの移動に関する内容を書いていきますが、「そもそもボリュームの移動って何なのか」についても触れておこうと思います。
NetApp公式の説明は以下になります。
ストレージ容量に不均衡があるときは、FlexVolを同じStorage Virtual Machine（SVM）内で別のアグリゲート、ノード、またはその両方に移動してストレージ容量のバランスを調整することができます。
例えば、2ノード（コントローラ）構成のクラスタで片方のコントローラが管理するアグリゲートばかりにボリュームが偏ってしまっているというのは運用上好ましくないというのは直感的に想像できるかと思います。
ボリュームを配置するアグリゲートは各コントローラ毎に管理しますので、ボリュームの配置が偏ってしまえばコントローラが請け負う負担も偏ってしまいますよね。
そういった場合にボリュームを移動することで各コントローラへの負担を分散することができるようになります。
僕がどのようなケースでボリューム移動をしたのか
次に僕がどのようなケースでボリュームを移動したのかについてご説明します。
一言で言えば「旧環境から新環境へのボリューム移動確認テスト」です。
冒頭でも少し触れましたが、僕は現在NetAppのリプレース作業に取り組んでいます。
元々あるNetApp環境（旧環境）のクラスタに新しいコントローラ（新環境）を追加してボリュームを移動しようというのが目的です。
そのためには、ざっくり以下のような作業が必要です。
新環境で各種設定が完了してすぐにボリュームを移動してしまうと、もしも設定に不備があった場合に障害に繋がってしまうかもしれません。
また、「そもそもボリュームの移動ができるのか？」というのは事前に確認しておきたいところです。
そこで実施するのが③の動作確認テスト。
旧環境で稼働中のボリュームとは別に「テスト用のボリューム」を作成し、これを新環境に移動しました。
本記事ではこれをベースにお話していきます。
Step1：ボリューム移動前の確認
まず最初に実施するのは事前確認作業です。
ボリュームを移動する前にはいくつか確認しておきたい項目があるので、本節ではそれらを確認していきます。
確認したい項目としては以下2つになります。
これら2項目を作業前後で比較することで、実際にアグリゲート間でのボリューム移動ができたかどうかを確認することができます。
念の為お伝えすると、これらの確認項目は全量ではなく、あくまでも僕が確認した項目となりますのでご了承ください。
アグリゲートに含まれるボリューム数は以下のコマンドで確認できます。
::> storage aggregate showこのコマンドを実行するとアグリゲート一覧を表示することができます。
そして、その中にある「#Vols」という項目がアグリゲートに含まれるボリューム数になります。
今回のケースで言えば、ボリューム移動前のアグリゲート#1には「メインvol」と「テストvol」が存在しているので、ボリューム数は「2」と表示されることになります。
また、アグリゲート#3に関してはまだボリュームが存在していないので「0」と表示されます。
続いて、対象ボリュームが所属するアグリゲートは以下のコマンドで確認できます。
::> volume show -vserver SVM名 -volume ボリューム名 -fields aggregateこのコマンドでは指定したボリュームが所属するアグリゲート名のみ表示することができます。
今回のケースでは各パラメータを以下のように指定します。
「-vserver」で指定するのは対象ボリュームを管理するSVM名
「-volume」で指定するのは対象ボリュームである「テストvol」
これにより「テストvol」は「アグリゲート#1」に所属しているという情報を得ることができます。
Step2：ボリューム移動の開始
それではいよいよ本題の「ボリュームの移動」になります。
この作業により、新環境で管理するアグリゲートに旧環境のボリュームを移動することができるようになります。
ボリューム移動のためのコマンドは以下のようになります。
::> volume move start -vserver SVM名 -volume ボリューム名 -destination-aggregate アグリゲート名今回のケースでは各パラメータを以下のように指定します。
「-vserver」で指定するのは対象ボリュームを管理するSVM名
「-volume」で指定するのは対象ボリュームである「テストvol」
「-destination-aggregate」で指定するのは新環境側アグリゲートである「アグリゲート#3」
これにより対象ボリューム「テストvol」の新環境アグリゲート「アグリゲート#3」への移動が開始されます。
Step3：ボリューム移動中の確認
ボリュームの移動にかかる時間は、ボリュームの容量やネットワーク帯域によってさまざまです。
そこで気になるのが「進捗状況」です。
進捗状況を確認するには以下のコマンドを実行します。
::> volume move show -vserver SVM名 -volume ボリューム名言うまでもなく今回のケースでは各パラメータ以下のように指定します。
「-vserver」で指定するのは対象ボリュームを管理するSVM名
「-volume」で指定するのは対象ボリュームである「テストvol」
このコマンドでは主に以下の2項目について確認します。
Percentage Complete
こちらの項目ではボリューム移動の進捗率を「%表示」で確認することができます。
今どのくらいの割合が完了しているのか把握するのに役立つので是非チェックしてみましょう。
Move Phase
こちらの項目でも作業進捗に関する内容を表示してくれます。
先述の「Percentage Complete」とは異なり、「replicating」や「completed」などという形で進捗状態を表示してくれます。
正直なところ「Percentage Complete」のみの確認でも大丈夫だと思いますが、ボリューム移動が完了時に「completed」という文字で確認できたほうがより確実と言えるでしょう。
Step4：ボリューム移動後の確認
最後に実施するのは「ボリューム移動後の確認」になります。
確認する項目としては「ボリューム移動前の確認」と同じで、移動前後で比較します。
まずはアグリゲートに含まれるボリューム数を確認するために以下のコマンドを実行します。
::> storage aggregate showボリューム移動後のアグリゲート#1には「メインvol」だけが存在しているので、ボリューム数は「1」と表示されます。
また移動先であるアグリゲート#3については新しく「テストvol」が配置されたので、こちらもまた「1」と表示されます。
それぞれ以下のように変更されているのが分かります。
アグリゲート#1は移動前と比べて「-1」されており、アグリゲート#3は「+1」されたということになります。
続いて、対象ボリュームが所属するアグリゲートを確認するために以下のコマンドを実行します。
::> volume show -vserver SVM名 -volume ボリューム名 -fields aggregateボリューム移動前後で対象ボリューム「テストvol」の所属アグリゲートを示す項目「aggregate」の値は、以下のように変更されています
以上により、アグリゲート#3に含まれるボリューム数が増えていることと、対象ボリューム「テストvol」が無事アグリゲート#3に所属していることが確認できました。
補足：必要であればLIFも移動する
ここまでの作業で本記事のテーマである「ボリュームの移動」は完了しています。
しかし、必要に応じてLIFの移動も実施してあげましょう。
というのも、ボリュームはSVMに紐付いており、LIFもまたSVMに紐付いているからです。
LIFは論理的なインターフェースであり、コントローラの物理的なポートを使用します。
例えばLIFがコントローラ#1のポートを使用している場合。
今回の作業で「テストvol」は新環境である「アグリゲート#3」に移動できましたが、LIFが旧環境である「コントローラ#1」に紐付いていては完全に旧環境から新環境にリプレースできたとは言えませんよね。
「テストvol」に対するアクセスはLIFを通ってきますので、旧環境を経由してボリュームに通信が届くということになります。
そこでLIFのホームポートを「コントローラ#3」あるいは「コントローラ#4」に設定してあげることでアクセス経路も新環境にしてあげることができます。
新旧環境でのLIFの移動は下記の記事が参考になるかと思います。
関連記事：【NetApp】ブロードキャストドメインの結合 / 分割を用いたLIFの移動方法
おわりに
いかがでしたでしょうか。
今回は「ボリュームの移動」についてお話してきました。
実際にデータを格納するボリュームを別のアグリゲートに移動するというものでした。
僕のようにNetApp環境のリプレース作業以外にも、通常運用の中でもボリュームを移動するケースは発生するかと思います。
そんなときに本記事の内容が少しでもお役に立てれば幸いです。
本記事を最後までお読みいただき、ありがとうございました。
ではでは！