はじめに
ストレージの入れ替えには、計画から移行完了までの間に多くの手続き、時間、費用を必要とします。サーバーベンダー、SAN スイッチベンダー、ストレージベンダーが異なるようなマルチベンダー環境においては登場人物も多くなりやすく、作業ステップに応じて各ベンダー間の引き継ぎや連携を管理するのは容易ではありません。
また、ストレージベンダーが提供するデバイスドライバー（マルチパスソフトウェア）を利用している環境では、接続互換性などの制限からサーバーに対するドライバーインストール / アンインストール作業が必要となり、その作業計画は煩雑を極めます。これが原因となり、ストレージ更改とサーバー更改を同時に行わざるを得ないこともあります。さらには、ストレージデータの移行作業を行うために、決して短くないサービスの停止が必要になることもあるでしょう。
Purity//Migrate は、既存ストレージから FlashArray へのストレージデータの移行において、これら全ての複雑要素を極限まで排除します。次の図は、データ移行における一般的なフローと、Purity//Migrate を使用する場合のフローとの比較を示しています。
※本ブログでは、2019 年 4 月時点における最新情報をご紹介しています。
Purity//Migrate の特長
Purity//Migrate は、既存の FC-SAN に接続し、ストレージのデータを FlashArray にストレージ間コピーします。Purity//Migrate には、以下のような特長があります。
サーバー設定変更不要
コピーデータはサーバーを経由しないため、実際にストレージの入れ替えを行う時点まで、マルチパスソフトウェアの変更などの作業が一切必要ありません。すなわち、ストレージデータの移行前にサーバーをリブートする必要がありません。
スイッチゾーニング自動設定
ストレージデータの移行のために必要なゾーンは、Purity//Migrate が自動で設定します。このとき、既存のゾーン設定の変更は不要です。移行完了後は、移行のために作成したゾーンをウィザードで削除できます。
既存ストレージ設定変更不要
既存ボリュームのアクセス設定を含め、既存ストレージの設定変更は一切必要ありません。
その他の特長
サーバーからのデータ書き込み / 読み出し要求は、全て既存ストレージで処理されます。移行処理はストレージボリューム単位、または、それを利用するサーバー単位で設定することができます。移行データはストレージ間通信で処理されるので、サーバーには移行負荷がかかりません。
実際の移行処理は、スケジュール設定に従って自動実行されます。スケジュールは、1 回のみ実行の他に、最短 1 時間間隔の非同期差分転送を設定できます。この差分はストレージブロック単位で検知できるので、移行直前の最終同期時間の短縮が可能です。これにより、移行のためのサービス停止時間（書き込み処理のフリーズ）を大幅に短縮することができます。
Purity//Migrate の動作概要
Purity//Migrate を利用するためには、マイグレーションキット（専用の FC カード）が必要です。マイグレーションキットは、コントローラ当たり 2 枚、合計 4 枚のカードで構成されています。
1 枚のカードには 2 つの FC ポート（NEXUS* ポート）があり、それぞれ「UPSTREAM」「DOWNSTREAM」という役割があります。UPSTREAM はサーバーとの I/O、DOWNSTREAM はストレージとの I/O 処理に利用されます。
* NEXUS とは「結合」や「連結」を意味しており、特定のネットワーク機器を指しているものではありません。
NEXUS ポートの SAN スイッチ接続には、以下のような条件があります。
- 既存ストレージが接続されている同一スイッチ筐体に接続する必要があります。
- 同一コントローラの NEXUS ポートは、同一スイッチ筐体に接続します。耐障害性は、サーバーと既存ストレージの接続パスで担保されているので、NEXUS ポートは「たすき掛け」をしません。
- NEXUS ポートの接続先スイッチポートは、既存サーバー / ストレージと同一の VSAN または Virtual Fabric に割り当てられている必要があります。
- NEXUS ポートの接続先スイッチポートは、NPIV が有効になっている必要があります。
- NEXUS ポートは、ゾーン設定する必要がありません。
Purity//Migrate は、既存サーバーとストレージの間に FlashArray を差し込むこと（インサーション）によってデータ移行処理を可能にします。
NPIV と VSAN（または Virtual Fabric）の機能を活用し、次のような環境を構成します。
サーバー ⇔（UPSTREAM）FlashArray（DOWNSTREAM）⇔ 既存ストレージ
Purity//Migrate が SAN スイッチにアクセスし、ゾーンの構成を検知した上で、NPIV の設定や FlashArray（DOWNSTREAM）⇔ 既存ストレージのための VSAN（または Virtual Fabric）とゾーンを自動作成します。サーバー ⇔（UPSTREAM）FlashArray は、既存のゾーンをそのまま活用します。
この設定処理は、Purity//Migrate の WebUI によりウィザードで自動設定します。
サーバー ⇔ 既存ストレージ間の I/O は FlashArray を介して処理されますが、NEXUS ポートは I/O をそのまま引き渡しているので、ACK は今までどおり既存ストレージから返されます。
インサーションが完了したら、Purity//Migrate の WebUI を利用してマイグレーションセッションを設定します。
Purity//Migrate は既存ストレージのボリュームと、それを利用するサーバーを自動検知します。移行するボリュームを選択し、マイグレーションの条件（容量拡張可否、スケジュール、帯域制限等）を指定してセッションを設定します。移行先ボリュームも Purity//Migrate が自動作成します。
ここで設定したスケジュールに従い、Purity//Migrate がデータ移行を行います。前述のとおり、ボリュームへのアクセスは NEXUS を介しているので、Purity//Migrate は既存ストレージのデータ変更を追跡することができます（図 5 Migration Status ― Session Status ― Current Data Changed 参照）。これにより、ストレージブロックレベルのデータ差分転送が可能になります。
まとめ
ストレージデータの移行には、ストレージベンダー特有の制限や手続きによってプロジェクトが煩雑化しやすいという課題があります。Purity//Migrate は、この課題を最大限解消し、スムーズなデータ移行を実現します。
次回以降で、インサーションやマイグレーションセッションについて、もう少し詳しくご紹介します。
