【テクニカルレポート】DataMotion for Volumes ベストプラクティスとユースケース(前編)……Tech OnTap | RBB TODAY
※本サイトはアフィリエイト広告を利用しています

【テクニカルレポート】DataMotion for Volumes ベストプラクティスとユースケース(前編)……Tech OnTap

エンタープライズ ソフトウェア・サービス
図1)NetApp DataMotion for Volumesを使用すると、単一のNetAppストレージコントローラ上の異なるアグリゲート間で、LUNを含むボリュームを無停止で移行できる
  • 図1)NetApp DataMotion for Volumesを使用すると、単一のNetAppストレージコントローラ上の異なるアグリゲート間で、LUNを含むボリュームを無停止で移行できる
  • 表1)DataMotion for VolumesとDataMotion for vFilerの違い
  • 図2)DataMotion for Volumesの全プロセス図
 従来のデータ移行方法は、ボリュームをオフラインにし、何時間もかけて新しい場所にデータをコピーし、影響を受けたサーバやアプリケーションを設定し直して再起動するというものでした。しかし、インフラが共有され、運用が24時間体制になった今、この方法はほぼ不可能になりました。そこでNetAppでは、必要になればいつでもデータを無停止で、しかも最小限の労力で新しい場所に移行できる、さまざまな選択肢を提供しています。

 Tech OnTapの定期購読者である皆様なら、NetApp Data Motion(NetApp DataMotion for vFilerから名称変更)については、すでにご存じでしょう。NetApp Data Motionを使用すれば、マルチテナント環境のストレージシステム間でMultiStore vFilerユニットとすべての関連データを移行できます。NetAppがData ONTAP 8.0.1のリリースで導入した新機能のうちの1つがDataMotion for Volumesです。DataMotion for Volumesを使用すると、同じストレージコントローラ上のアグリゲート間でLUNを含むボリュームを無停止で移行できます。

 この記事では、DataMotion for Volumesについて紹介し、DataMotion for vFilerとの違いについて説明します。また、ベストプラクティスや考えられる利用方法についても、いくつか取り上げたいと思います。

■DataMotion for Volumesとは

 DataMotion for Volumesは、7-ModeのData ONTAP 8.0.1でサポートされている新しい機能です。単一のストレージコントローラ上で、あるアグリゲートから別のアグリゲートへボリュームを無停止で移行できます(HAペアを構成する2つの異なるコントローラ間でボリュームを移行することはできません)。FC LUN、FCoE LUN、iSCSI LUNを含むボリュームについてのみ、移行を容易にする設計が採用されています。NFSボリュームとCIFSボリュームはサポートされていません。

DataMotion for Volumesの大きなメリットの1つに、ボリュームに関連付けられたすべての詳細設定を移行後も維持できることがあります。具体的には以下のような設定を維持できます。

・SnapshotとSnapshotスケジュール

・SnapMirror関係、SnapVault関係、MetroCluster関係

・シンプロビジョニングの設定

・重複排除の状態(移行先でフィンガープリント・データベースを再構築するには、再スキャンが必要)

 ストレージコントローラに接続されたあらゆる種類のメディア間でデータを移行できます。たとえば、FCやSASディスクを含むアグリゲートから、SATAディスクで構成されるアグリゲートにデータを移行できます。その逆も可能です。この初回リリースでは、32ビットアグリゲート間または64ビットアグリゲート間でボリュームを移行できますが、32ビットアグリゲートと64ビットアグリゲート間ではボリュームを移行できません。

■DataMotion for VolumesとDataMotion for vFilerの違い

 皆様の中にはDataMotion for vFilerテクノロジについてすでによくご存じの方もいらっしゃると思いますが、DataMotion for VolumesとDataMotion for vFilerの間には、いくつか重要な違いがあります。DataMotion for VolumesはFlexVolレベルで機能しますが、DataMotion for vFilerはvFilerレベルで機能し、1つのvFilerユニットに関連付けられたすべてのNFSボリュームまたはiSCSIボリュームを移行します。DataMotion for vFilerでは、異なるストレージシステム間やHAペア間でボリュームを移行することが可能です。DataMotion for vFilerはNetApp Protection Managerを使用して管理し、 コマンドラインからvol moveコマンドを使用してのみ起動できます。

表1に違いをまとめました(上記では触れなかった違いも含まれています)。

■DataMotion for Volumesの仕組み

 DataMotion for Volumesは、定評のあるNetApp SnapMirrorテクノロジをボリュームの移行に利用しています。プロセスの仕組みについて簡単に理解しておくと、DataMotion for Volumesを有効に活用できます。移行は、3つのフェーズに分かれています。

セットアップ
データコピー
カットオーバー
セットアップフェーズやデータコピーフェーズ中でも、移行元ボリュームはI / O要求に中断なく応え続けます。

セットアップフェーズ

 セットアップフェーズでは、処理全体を正常に完了できることを確認するために、重要な事前確認が実行されます。この事前確認は、DataMotion for Volumesを起動するたびに実行され、カットオーバーフェーズ開始時にもう一度実行されます。

 事前確認は、移行に関連するすべてのオブジェクト(移行元ボリューム、移行元アグリゲート、移行先アグリゲートなど)の状態を確認します。いずれかの事前確認が正常に完了しない場合は通知が送信され、プロセスは開始されません。事前確認のすべてのエラーはコンソールに表示され、コントローラのルートボリューム内のログファイル(/etc/log/ndvm)に記録されます。

 すべての事前確認が正常に完了すると、DataMotion for Volumesは以下を実行します。

・次の命名規則を使用して、移行先アグリゲートに一時的なプレースホルダー・ボリュームを作成

ndm_dstvol_<タイムスタンプ>

・ベースライン転送を開始して、移行元ボリュームとプレースホルダー・ボリュームの間にSnapMirror関係を設定。これが最も時間のかかるフェーズです。ボリュームのすべての内容が転送されるため、移行元ボリュームのサイズが大きいほど時間がかかります

データコピーフェーズ

 ベースライン転送が完了すると、データコピーフェーズが開始されます。データコピーフェーズでは、移行元ボリュームは引き続きアクティブなため、移行先ボリュームと同期するために連続SnapMirror更新が開始されます。SnapMirror更新が正常に終了すると、DataMotion for Volumesは2つのボリューム間の差分遅延を見積もります。差分遅延に関する通知がユーザに送信され、この差分遅延が次回の更新処理の予想所要時間になります。DataMotion for Volumesは、差分遅延の値が高い間はデータコピーフェーズに留まります。差分遅延が小さくなると、カットオーバーフェーズに入ります。

カットオーバーフェーズ

 カットオーバーフェーズは、手動、自動(デフォルト)のいずれでも実行できます。

 カットオーバー前。カットオーバー・ウィンドウ内に移行先ボリュームの同期を完了できる場合、DataMotion for Volumesはカットオーバーフェーズに入ります。カットオーバー前フェーズは一時的な段階で、前述した初期の事前確認が再度実行され、何も変更されていないことが確認されます。また、NVLOG、システムCPUの負荷の状態など、重要な項目が確認されます。

 DataMotion for Volumesでは、CPUとディスクのしきい値の上限を設定できます (以下のオプションのデフォルト値は、いずれも100です)。

vol.move.cutover.cpu.busy.limit
vol.move.cutover.disk.busy.limit

 自動カットオーバー。カットオーバー前確認が完了すると、カットオーバーフェーズが自動的に開始されます。カットオーバーは、カットオーバー・ウィンドウ内に完了する必要があります。カットオーバー・ウィンドウは、デフォルトで最長の60秒になっています。移行先ボリュームが完全に同期すると、移行元ボリュームのIDが移行先へ移譲され、移行先からI/Oが提供されるようになります。

・移行元ボリュームのすべてのLUNで、I/Oが一時停止します。この一時停止状態によって、LUN上で新しいI/Oがスケジュールされなくなり、LUN上でペンディングになっているI/Oが排出されます

・移行元ボリュームが停止します。停止処理の一環として、最後の差分遅延がSnapshotコピーにキャプチャされ、命名規則ndvm_final_<タイムスタンプ>に従って名前が付けられます

・次に、ndvm_final_<タイムスタンプ>の差分を使用して、移行先ボリュームが移行元ボリュームと完全に同期します。この、2つのボリューム間の最後のSnapMirror更新後、I / Oは移行先ボリュームから提供されるようになります

・プレースホルダー・ボリュームには、移行元ボリュームの名前とファイルシステムID(FSID)のスタンプが押され、その逆も行われます。つまり、移行元ボリュームとプレースホルダー・ボリュームのIDが交換されます

・移行先の移行済みボリュームが、移行元ボリュームのIDでオンライン化され、LUNがアクティブになります

・移行元ボリュームは、(保持するように指定していないかぎり)削除されます

 カットオーバーの失敗。カットオーバーが失敗すると、DataMotion for Volumesは再びデータコピーフェーズに入り、あとで再試行します。デフォルトでは、カットオーバーは3回試行されます。3回失敗するとカットオーバーは中止され、I / Oは引き続き元の場所から提供されます。DataMotion for Volumesで処理を続行するには、ユーザの介入が必要です。

 手動カットオーバー。手動カットオーバーでは、DataMotion for Volumesはデータコピーフェーズに留まり、連続SnapMirror更新を実行します。次のSnapMirror更新処理の所要時間が引き続き見積もられ、この情報がログに記録されます。この情報を確認してから、手動カットオーバーを開始してください。

●著者紹介

Richard Jooss
ディレクター兼SAN/iSCSIアーキテクト
NetApp

Richard Joossは、NetAppでSANプロダクト/パートナー・エンジニアリングのシニアマネージャーを務めています。SANエコシステム、SANストレージの技術要件とビジネス要件の定義を担当し、ビジネスソリューションとNetApp SANソリューションとの統合にも携わっています。ストレージ業界で15年の経験を積んでおり、 ウィスコンシン大学で電気/コンピュータ工学の理学士号を取得しています。

※同記事はネットアップ(NetApp)の発行する「Tech OnTap」の転載記事である
《RBB TODAY》
【注目の記事】[PR]

関連ニュース

特集

page top