vMotion の概念とベスト・プラクティス

HCX は、両方向で使用できる vMotion プロキシーであると見なすことができます。 HCX の各インスタンスは、クラスタ外の vSphere データ センター内の単一の VMware ESXi™ ホストをエミュレートします。 HCX インスタンスは、クラウド・ゲートウェイ・フリート・コンポーネント (CGW) の「フロント」です。 プロキシー・ホストは、現在の表示サイトにリンクされている HCX サイトごとに表示されます。 vMotion がリモート・ホストに対して開始されると、ローカル ESXi ホストは、ローカル・プロキシー ESXi ホストへ対象 VM をマイグレーションします。

宛先の vSphere 物理 ESXi ホストがトンネルを介してソースの CGW のデータを受信すると、リモートの ESXi プロキシー・ホストからこの vSphere 物理 ESXi ホストへの vMotion マイグレーションが開始されます。 vMotion が採用される場合、一括マイグレーション・オプションとは異なり、一度に実行されるのは 1 つの VM マイグレーション操作のみです。 そのため、多くの VM を移行する場合は、ダウンタイムが選択できない場合、または VM を再起動するリスクが存在する場合にのみ、vMotion を使用することをお勧めします。 ただし、標準の vMotion の場合と同様、VM はプロセス中も稼働できます。

単一の vMotion は、WAN オプティマイザを経由して、LAN 上で 1.7 Gbps、WAN 上で 300 ～ 400 Mbps 程度で最大限界に達します。 これは、LAN 上の 1.7 Gbps と WAN 最適化プログラム経由の WAN 上の 400 Mbps が等価だという意味ではなく、特定の環境でそうした最大値が計測されたという意味です。 それは、実動 Web トラフィックによって共有される、10 GB LAN vMotion ネットワークと 1GB インターネット・アップリンクで構成されている環境です。

vMotion は以下の場合に使用してください。

• VMのシャットダウンや起動が困難な場合、あるいは稼働時間が長く、VMをシャットダウンすることでリスクが生じる可能性がある場合。
• Oracle RAC クラスタなど、ディスク UUID を必要とするクラスタ型アプリケーションの場合。vMotion はデスティネーションのディスク UUID を変更しません。
• 単一の VM をできる限り迅速に移動したい場合。
• スケジュールされたマイグレーションが不要である場合。

一括マイグレーションの概念とベスト・プラクティス

HCX の一括マイグレーション機能では vSphere レプリケーションを使用して、宛先の vSphere HCX インスタンスで VM を再作成している間にディスク・データをマイグレーションします。 VM のマイグレーションにより、以下のワークフローが生じます。

• 宛先サイドでの新しい VM とその対応する仮想ディスクの作成。
• 新しい VM への VM データのレプリケーション。 レプリケーションは、切り替えスケジュールに関係なく、ウィザードが完了次第開始される。
• 元の VM のパワーダウン。
• パワーオフ期間中に発生する、変更データの最終レプリケーション。
• 宛先サイドにおける新しい VM のパワーオン。
• 元の VM を移動先のクラウド・フォルダーに名前変更して移動する処理。

vMotion と比較して一括マイグレーションには以下の利点があります。

• 同時に複数の VM をマイグレーションできる。
• より一貫性のある帯域幅の使用。vMotion は、帯域幅の使用量に変動が発生する可能性があります。これは、ネットワーク・モニター・ツールまたは WAN Opt UI 内でピークおよび谷として表示されます。
• 単一の vMotion を使用する場合よりも高いネットワーク帯域機能をすべて利用するために、一括マイグレーションを使用できる。
• 一括マイグレーションのスケジュールを設定し、計画停止期間中にマイグレーション後の新しい VM に切り替えることができる。
• クラウド側とは異なる仮想 CPU 機能を現在使用している VM のマイグレーションを許可します。このような場合、vMotion マイグレーションが失敗する可能性があります。

vMotion と比較して一括マイグレーションには以下の欠点があります。

• vMotion に比べ、個々の VM マイグレーション速度がかなり遅い。
• 宛先サイドに新たに VM が複製されると VM で短時間のダウン時間が生じる。
• ディスクの順序とディスク UUID に依存する VM (Oracle RAC) の場合、UUID が変更されて問題が生じ、元とは異なるディスクが表示される可能性がある。それに伴い、仮想ディスク・デバイスへの OS パスが変更されることがあります。

共有ディスク・クラスター

Oracle RAC、MS Exchange、MS-SQL などのアプリケーションのクラスターでは、複数の VM が 1 つのクラスターに参加し、すべての VM またはクラスター・ノードが使用する共有ディスクを必要とします。 アプリケーション・クラスターの一部であるディスク (非 OS 仮想ディスク) に対して、すべての VM ノードで VMware® マルチライター・フラグを有効にする必要があります。 どの仮想ディスクでもマルチライターフラグが有効になっているVMはサポートされません。

マルチライター仮想ディスクが有効なクラスターのマイグレーションに関する以下の情報を確認してください。

• 元の VM ディスクと UUID マッピングが維持されるので、vMotion を使用します。
• クラスターはマイグレーション中に低下状態 (単一ノード) で稼働状態を維持します。
• クラスターでは、クラスター VM 全体でマルチライター構成を再アセンブルするために、マイグレーションの開始前とマイグレーションの完了後にダウン時間が生じます。

マルチライター・ディスクが有効なクラスターをマイグレーションするには、以下の手順を実行します。

1. アプリケーションのベスト・プラクティスに基づいて、クラスターとすべてのノードの電源を切ります。
2. アプリケーションで必要となる場合には、マルチライター構成が設定されている仮想ディスクの各ノード VM におけるディスクの順序をメモに取ります。
3. 仮想ディスク UUID フィーチャーを使用する Oracle などのアプリケーションの場合、ESXi ホストにログインし、コマンド vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk を実行します。 このコマンドは、クラスターに設定されているマルチライター・フラグを必要とする仮想ディスク・ファイルごとに UUID を取得します。 このステップは、ベスト・プラクティスとして、オペレーティング・システムでパスがどのように表示されるかによってディスク・オーダーを調整する場合に必要です。vMotion はディスク (disk1、disk2、disk3) を再配列できますが、UUID は同じままです。 マイグレーションが完了したら、メモしておいた UUID を使用してディスク情報をマップし、ディスクの命名順序と SCSI ID (必要な場合) を再作成します。 マップされた仮想ディスクが Oracle インスタンスに多数存在する場合は、この情報がトラブルシューティングに役立つ可能性があります。
4. プライマリーと見なされているもの以外の仮想ディスクをすべてのクラスター VM から削除します。
5. プライマリクラスターVM（クラスターディスクを所有する唯一のVM）からマルチライターフラグを削除します。
6. ダウン時間を最小にするために必要な場合はプライマリー・クラスターの電源を入れます。
7. vMotion ですべてのクラスター・ノードをマイグレーションします。 まずプライマリー・クラスターをマイグレーションします。 その電源を切ってから、他のすべてのノードをマイグレーションします。
8. プライマリー・ディスクが所有しているノードのマイグレーションが完了したら、その電源をオフにします。
9. 必要に応じて、適切なディスク UUID と scsi ID でディスクの順序を再マップします。 アプリケーションが機能するために再マップが必須であるわけではありません。
10. プライマリー・ノードでマルチライター・フラグを再び有効にします。
11. プライマリノードを起動し、動作を確認する。
12. 他のすべてのクラスター VM でディスクをマップするかマルチライター・フラグを有効化し、それらをパワーオンします。
13. 他のクラスターの操作を検証します。

一般の VM

HCX の機能が正しく動作していることを確認した後に、一括マイグレーションを導入する必要があります。 冗長アプリケーションには一括マイグレーションが必要です。 例えば、VM 数が数百、数千と多数あるような Web サーバーをマイグレーションする場合などが該当します。

直接接続された NAS を使用する VM

NFS は通常、Web サーバー・コンテンツなどの多数のサーバー間でデータを共有するために使用されます。iSCSI は、電子メールや RDBMS などのアプリケーション・クラスターで構成される VM ノード全体で使用でき、通常は NFS よりも待ち時間の影響を受けます。

どちらの場合も、待ち時間を IBM Cloud データ・センター (iSCSI の場合は < ~ 7 ms、NFS の場合はどのようなアプリケーションでも可) まで短くして、アプリケーションが約 1 Gbps 以下の帯域幅で動作できるようにすることができれば、HCX を使用して NAS ネットワークを IBM Cloud ロケーションに拡張することができます。 その後、VM をマイグレーションしたり、HCX で vMotion を実行したりできます。

マイグレーション後に、iSCSI ボリュームを OS と一緒に別のローカル・クラウド・ストレージ・ソリューションにミラーリングできます。また、任意のクラウド・ソリューションに NFS データを複製できます。 次の考慮事項について確認してください。

• 待ち時間 (iSCSI、または NFS におけるアプリケーション許容範囲)
• 帯域幅 (ストレッチ・ネットワークあたり約 1 Gbps)
• アンダーレー・リンク帯域幅

マイグレーション・ライフサイクルが終了したら、実稼働環境でマイグレーションを試す前に、開発アプリケーションやステージング・アプリケーションをテストしてください。 待ち時間に厳格なストレッチ L2 ネットワークをサポートする L2C HCX アプライアンス間のアンダーレー・トンネル・トラフィック (UDP 500/4500) に関して QoS を導入できます。