SVM data mobilityを試してみた

SVM Data Mobility調査 - しろぺん日記でまとめた後、実際に試す環境を用意できたのでやってみた。

環境

SVM data mobilityを試した環境は以下

機材 AFF C190 FAS 8200
ONTAP 9.12.1P4 9.12.1P4

移行対象のSVMには100GBのvolumeを1つ作って、約15GBのデータを入れておきました。

前提条件確認

cluster peer関係

ソース・デスティネーションクラスタ間でcluster peer関係を構築しておきます。構築後、cluster peer showコマンドで確認します

ontap1::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
ontap2                    x-xx-xxxxxx           Available      ok
1 entries were displayed.
 
ontap1::>

ライセンス確認

ソースデスティネーションとデスティネーションクラスタ両方にData Protection Bundleライセンスがインストールされている必要があります。

最近は「ONTAP One」というすべての機能が包括されたオールインワンライセンスになっているので、通常は気にする必要はないでしょう(ONTAP Baseを選択している場合は別途購入が必要)。

system license show-statusコマンドで、SnapMirror、SnapMirror Synchronous、SnapVaultが有効になっていればよいです

ONTAPバージョン

AFF-Aシリーズ、AFF-Cシリーズ、FASSVM data mobilityをサポートするONTAPのバージョンが異なります。ONTAP 9.12.1P4以降なら、AFF-A/AFF-C/FASどれでもサポートされます。

ソースクラスタ・デスティネーションクラスタそれぞれでノードのONTAPバージョンは同じである必要があります(通常運用している場合はほぼないかと思います)。

デスティネーションクラスタのONTAPバージョンはソースクラスタと同じか、メジャーバージョンが2世代後以内のONTAPバージョンである必要があります。ONTAPバージョンのメジャーバージョンが異なると、SVMを双方向に移行できないので、ONTAPのメジャーバージョンはそろえておいたほうがよいです。

data LIF用ネットワーク

ソースクラスタとデスティネーションクラスタで、移行対象SVMのdata LIFが利用するネットワークへの疎通が取れる必要があります。

その他

  • ソースクラスタとデスティネーションクラスタ間の最大RTT
    • ONTAP 9.11.1までは2ms
    • ONTAP 9.12.1以降は10ms
  • デスティネーションクラスタのアグリゲートに十分な空き容量がある
  • SVMのボリューム数

にも制限があります。

やってみる

事前確認

作業はデスティネーションクラスタ側で実施します。

vserver migrate startコマンドに--check-only trueを指定することで、事前確認を実施することができます。

ontap2::> vserver migrate start -vserver svm-test -source-cluster ontap1 -check-only true
 
Error: command failed: There are no network ports on the destination cluster "ontap2" where reachability is confirmed for the following IP addresses: 192.168.1.111
 
ontap2::> vserver migrate start -vserver svm-test -source-cluster ontap1 -ipspace IPSPACE1 -check-only true
 
Info: Vserver migrate checks finished successfully. Vserver migrate can be started now.
 
ontap2::>

上記にある通り、移行対象SVMのdata LIFが所属しているIPSPACEを指定しなかった場合、疎通確認に失敗して、事前確認がエラーとなります。

移行

事前確認で問題ないことを確認後、実際に移行を行います。

ontap2::> vserver migrate start -vserver svm-test -source-cluster ontap1 -ipspace IPSPACE1
 
Info: To check the status of the migrate operation use the "vserver migrate show" command.
 
ontap2::> vserver migrate show
                 Destination         Source
Vserver          Cluster             Cluster             Status
---------------- ------------------- ------------------- ---------------------
svm-test         ontap2              ontap1              setup-configuration
 
 
ontap2::>

vserver migrate showに-instanceオプションをつけると、詳細が表示されます。ただし、進捗はステータスのみで、%表示はないです(なので、時間予測が難しい)。

デフォルトでは、転送→カットオーバー→クリーンアップまで自動で実施されますが、カットオーバーとクリーンアップを手動で行うことも可能です。

移行中および後のSVMへのアクセスは、

  • NFSマウントは維持されている
  • SVMが提供しているボリュームへの書き込みは約50秒停止
    • 1秒間隔で書き込みしていたところ、カットオーバー開始から遅延発生
  • NFSクライアントからのping監視は1回だけ落ちた

という状態でした。

snapshot関連では、

  • SVM内のボリュームで取得していたsnapshotは一緒に移行される
  • snapshotポリシーも移行される
  • job scheduleは移行したSVMに紐づく形で移行される

ことを確認しています。