PlateSpin環境でアクティブノードの検出が有効になっている(デフォルト)場合、Windowsクラスタのマイグレーションは、仮想の1ノードクラスタにストリームされるアクティブノード上の変更による増分レプリケーションで実現できます。アクティブノードの検出を無効にした場合、Windowsクラスタの各ノードはスタンドアロンノードとして検出およびマイグレートすることができます。
Windowsクラスタをマイグレーション対象として設定する前に、ご使用の環境で前提条件が満たされていること、およびクラスタワークロードをマイグレートするための条件を理解していることを確認してください。
クラスタマイグレーションのサポート範囲は、表 25-1に記載されている条件に従う必要があります。PlateSpin環境でクラスタのマイグレーションを設定する際には次の要件を検討してください。
表 25-1 クラスタのマイグレーションの要件
要件 |
説明 |
---|---|
Windowsクラスタとしてのアクティブノードの検出 |
PlateSpinグローバル環境設定DiscoverActiveNodeAsWindowsClusterは、Windowsクラスタをクラスタとしてマイグレートするか、別個のスタンドアロンマシンとしてマイグレートするかどうかを判断します。
詳細については、セクション 25.2, Windowsアクティブノードの検出の設定を参照してください。 |
リソース名の検索値 |
PlateSpinグローバル環境設定MicrosoftClusterIPAddressNamesは、PlateSpin環境で検出可能なクラスタリソース名を判断します。共有クラスタのIPアドレスリソース名を、クラスタ上の他のIPアドレスリソース名から区別するため、検索値を指定する必要があります。 詳細については、セクション 25.4, リソース名の検索値の追加を参照してください。 |
Windowsクラスタモード |
PlateSpinグローバル環境設定WindowsClusterModeは、増分レプリケーションのブロックベースのデータ転送方法を判断します。
次を参照してください。 |
アクティブノードのホスト名またはIPアドレス |
ワークロードの追加操作を実行する場合、クラスタのアクティブノードのホスト名またはIPアドレスを指定する必要があります。Microsoftによるセキュリティ変更のため、仮想クラスタ名(つまり、共有クラスタIPアドレス)を使用してWindowsクラスタを検出することはできなくなりました。 |
解決可能なホスト名 |
PlateSpin Serverは、クラスタの各ノードのホスト名をIPアドレスで解決できる必要があります。 メモ:IPアドレスによってホスト名を解決するには、DNS前方向検索および後方向検索が必要です。 |
クォーラムリソース |
クラスタのクォーラムリソースは、マイグレートされるクラスタのリソースグループ(サービス)と同じノードにある必要があります。 |
クラスタノードの類似性 |
デフォルトのWindowsクラスタモードでは、ノードが類似している場合、アクティブになる任意のノードからドライブレス同期を続行できます。それらが一致しない場合、元々検出されていたアクティブノードでのみレプリケーションが発生する可能性があります。 詳細については、クラスタノードの類似性を参照してください。 |
PowerShell 2.0 |
Windows PowerShell 2.0 を、クラスタの各ノードにインストールする必要があります。 |
クラスタ用のブロックベース転送は、スタンドアロンサーバ用とは異なる方法で動作します。最初のレプリケーションでは、完全なコピー(フル)が作成されるか、またはクラスタのアクティブノード上で実行されるドライバレスの同期方法が使用されます。後続の増分レプリケーションでは、ブロックベースのデータ転送でドライブレスの方法またはドラバベースの方法を使用できます。
メモ:PlateSpin Migrateでは、クラスタ用のファイルベース転送がサポートされていません。
PlateSpinグローバル環境設定WindowsClusterModeは、増分レプリケーションのブロックベースのデータ転送方法を判断します。
デフォルト: 現在のアクティブノード上でMD5ベースレプリケーションを使用したドライブレス同期
SingleNodeBBT: 元々検出されていたアクティブノード上にインストールされたBBTドライバを使用したドライバベースの同期
どちらの方法も、ファイバチャネルSANおよびiSCSI SAN上のローカルストレージと共有ストレージのブロックレベルレプリケーションをサポートします。
表 25-2では、2つの方法について説明および比較しています。
表 25-2 増分レプリケーション用のブロックベースのデータ転送方法の比較
検討事項 |
デフォルトBBT |
シングルノードBBT |
---|---|---|
データ転送方法 |
現在のアクティブノード上でMD5ベースレプリケーションとともにドライブレス同期を使用します。 |
元々検出されていたアクティブノード上にインストールされたBBTドライバを使用します。 |
パフォーマンス |
潜在的に低速な増分レプリケーション。 |
増分レプリケーションのパフォーマンスが大幅に向上します。 |
サポートされるWindowsクラスタ |
サポートされているWindows Serverクラスタと連携動作します。 |
Windows Server 2008 R2以降と連携動作します。 他のサポートされるWindowsクラスタでは、レプリケーションにドライバレス同期方法が使用されます。 |
ドライバ |
|
|
最初の増分レプリケーション |
アクティブノード上でドライバレス同期を使用します。 |
BBTドライバがインストールされた後で完全レプリケーションが完了した場合、元々検出されていたアクティブノード上でドライバベースのブロックベース転送を使用します。 それ以外の場合、元々検出されていたアクティブノード上でドライバレス同期を使用します。 |
後続の増分レプリケーション |
アクティブノード上でドライバレス同期を使用します。 |
元々検出されていたアクティブノード上でドライバベースのブロックベース転送を使用します。 クラスタがノードを切り替える場合、元々アクティブなノードが再びアクティブになった後で、最初の増分レプリケーションにドライバレス同期方法が使用されます。 詳細については、レプリケーションでのクラスタノードのフェールオーバーの影響を参照してください。 |
表 25-3では、レプリケーションでのクラスタノードフェールオーバーの影響と、Migrate管理者による実行が必要なアクションについて説明します。
表 25-3 レプリケーションでのクラスタノードのフェールオーバーの影響
クラスタノードフェールオーバーまたはフェールバック |
デフォルトBBT |
シングルノードBBT |
---|---|---|
最初の完全レプリケーション時にクラスタノードフェールオーバーが発生する |
レプリケーションが失敗します。最初の完全レプリケーションは、クラスタノードフェールオーバーなしで正常に完了する必要があります。
|
|
後続の完全レプリケーションまたは後続の増分レプリケーション時にクラスタノードフェールオーバーが発生する |
レプリケーションコマンドが中止され、レプリケーションを再実行する必要があることを示すメッセージが表示されます。 新しいアクティブノードのプロファイルが、障害の発生したアクティブノードと同様の場合は、マイグレーションコントラクトが有効なままになります。
新しいアクティブノードのプロファイルが、障害が発生したアクティブノードと同様ではない場合は、マイグレーションコントラクトは元々アクティブなノード上でのみ有効になります。
|
レプリケーションコマンドが中止され、レプリケーションを再実行する必要があることを示すメッセージが表示されます。元々検出されていたアクティブノード上でのみマイグレーションコントラクトが有効です。
クラスタフェールオーバー/フェールバックイベント後のこの最初の増分レプリケーションでは、自動的にドライバレス同期が使用されます。後続の増分レプリケーションではシングルノードBBTで指定されているように、ブロックベースドライバが使用されます。 |
レプリケーション間でクラスタノードフェールオーバーが発生する |
新しいアクティブノードのプロファイルが、障害が発生したアクティブノードと同様な場合、次回の増分レプリケーションではマイグレーションコントラクトの処理がスケジュールどおりに続行されます。それ以外の場合は、次回の増分レプリケーションコマンドが失敗します。 スケジュール済みの増分レプリケーションが失敗する場合:
|
アクティブノードがレプリケーション間で切り替わる場合は増分レプリケーションが失敗します。
クラスタフェールオーバー/フェールバックイベント後のこの最初の増分レプリケーションでは、自動的にドライバレス同期が使用されます。後続の増分レプリケーションではシングルノードBBTで指定されているように、ブロックベースドライバが使用されます。 |
デフォルトのWindowsクラスタモードの場合、レプリケーションプロセスでの中断を回避するため、クラスタノードが類似プロファイルを持っている必要があります。クラスタノードのプロファイルは、次のすべての条件を満たす場合、類似していると見なされます。
ノードのローカルボリューム(システムボリュームおよびシステム予約済みボリューム)のシリアル番号は各クラスタノードで同一である必要があります。
メモ:カスタマイズされたボリュームマネージャユーティリティを使用して、ローカルボリュームのシリアル番号をクラスタの各ノードで一致するように変更します。詳細については、クラスタノードにおけるローカルストレージのシリアル番号の同期を参照してください。
クラスタの各ノードのローカルボリュームでシリアル番号が異なる場合、クラスタノードでのフェールオーバーの実行後にレプリケーションを実行できません。たとえば、クラスタノードでのフェールオーバーの実行時には、アクティブノードであるノード1に障害が発生し、クラスタソフトウェアによってノード2がアクティブノードに設定されます。2つのノードのローカルドライブでシリアル番号が異なる場合、ワークロードの次回のレプリケーションコマンドが失敗します。
各ノードが同じ数のボリュームを持っている必要があります。
各ボリュームが各ノードでまったく同じサイズである必要があります。
各ノードがまったく同数のネットワーク接続を持っている必要があります。
Windowsクラスタのマイグレーションを設定するには、通常のワークロードマイグレーションワークフローに従います。クラスタのアクティブノードのホスト名またはIPアドレスを指定してください。
PlateSpin Migrateは、各ターゲットVMノードがVMwareクラスタ内の異なるホストに存在する場合に、ターゲットVM上の共有RDM (ローデバイスマッピング)ディスク(FC SAN)を使用してWindows Serverフェールオーバークラスタ(WSFC)をVMwareへ半自動でマイグレートできます。詳細については、RDMディスクを使用するVMware VMへのWindowsクラスタの高度なマイグレーションを参照してください。