移行は仮想化技術の基本的な利点であり、パフォーマンスに影響を与えることなく、サーバ間で仮想マシンをシームレスに移行できます。
移行設定の確認またはホストサーバーへの再接続
サーバ間でのVMマイグレーションには、まず両方のサーバでマイグレーション機能が有効になっている必要があります。たとえば、VMware ESX または ESXi を使用している両方のサーバで vMotion を有効にする必要があります。VM マイグレーション用の Hyper-V サーバの場合は、両方のサーバで動的マイグレーション機能が使用可能であることを確認してください。IT 管理者は、各ハイパーバイザーに対応するドキュメントを使用し、各サーバーで移行機能を有効にする必要があります。
サーバーハードウェアの互換性とデバイスの関連性の確認
仮想化サーバーは、特に上位のワークロードから基礎となるハードウェアを抽象化するように設計されています。抽象化によってワークロードの移行が可能になりますが、移行元と移行先のサーバー間でハードウェアの互換性がないために移行が失敗するシナリオも少なからずあります。
トラブルシューティングの最初のステップは、サーバーのハードウェアと構成を評価することです。単純な例として、ワークロードの移行には、移行元／移行先のサーバーがまったく同じプロセッサーを使用する必要があります。各システムのBIOSの処理設定やI/O仮想化設定がわずかに異なる場合も、ハードウェアの問題を引き起こす可能性があります。
また、VMが移行先のサーバで利用できないハードウェアに依存している場合にも、移行が失敗する可能性があります。例えば、VMware ESX/ESXiのようなハイパーバイザーでは、VMは物理ディスクに接続することができます。VMがソースサーバに接続された物理ディスクに依存しており、デスティネーションサーバに物理ディスクがない場合、マイグレーションは失敗します。移行元サーバのVM上のローカル物理ディスクやクライアントデバイスを安全に切断してから、移行をやり直してください。
サーバー間のネットワーク接続の確認
移行はネットワーク接続に依存しているため、移行元/移行先サーバー間の接続性に問題があると、移行活動に容易に影響を及ぼします。最も簡単な方法は、移行元/移行先サーバ間のネットワーク接続にpingを打つことです。たとえば、VMwareのvmkpingをソースサーバで使用して、コマンドシェルを使用してデスティネーションサーバにpingを送信することができます。宛先サーバのホスト名またはIPアドレスに移動し、成功したpingのフィードバックを確認します。
この手順は、WindowsのコマンドプロンプトまたはLinuxのコマンドラインから、標準のpingコマンドを使用して実行することもできます。pingが成功すれば、送信元サーバと宛先サーバ間のLAN通信が正常であることが証明されます。失敗した場合は、ソースサーバーと宛先サーバーのNIC間に互換性がない可能性があります。
一般的な互換性の問題は、超長フレームの使用です。たとえば、一方のサーバーのNICが超長フレームをサポートするように設定されており、もう一方がそうでない場合、両方のNICが同じように設定されていない限り、2つのサーバーは正しく通信できず、ワークロードの移行は成功しません。もう1つの一般的な問題は、ターゲットサーバーのホスト名pingを使用する場合に発生します。ホスト名pingは失敗するが、IPアドレスpingは問題なく動作する場合は、ホスト名解決に問題があり、この問題を解決することで接続性の問題を解決できます。
インストール先サーバーのコンピューティングリソースの確認
デスティネーションサーバに十分な計算リソースがない場合も、ワークロードの移行に失敗する可能性があります。デスティネーションサーバに十分な処理コア、メモリスペース、NICポート、またはストレージがない場合、新しいワークロードをリザーブできません。これは、物理サーバーの台数が減少し、ワークロードの統合レベルが高まるにつれて、ますます一般的になっている問題です。
たとえば、宛先サーバーが他のシステムから追加のワークロードを受信してすでに障害が発生している場合、リソース不足が発生する可能性があります。または、デスティネーションサーバ上の既存のワークロードが、ユーザー アクティビティの増加によるリソース要求の増加に対応するために、追加のコンピューティングリソースを与えられた場合にも、リソース不足が発生する可能性があります。十分なコンピューティングリソースを持つ別のシステムにワークロードを移行するか、需要のあるサーバーでワークロードバランシングを実行してみてください。
よくある問題は、移行先サーバのディスク容量不足です。たとえば、VMware ESX/ESXiのユーザは、移行先サーバに向かってコンソールを開き、df -hコマンドを使用して、使いやすいスペースを監視することができます。移行したワークロードを保存するのに十分なスペースがない場合、管理者はスペースを確保するか、ワークロードを別のシステムに移行する必要があります。ストレージがストレージエリアネットワークを介して提供されている場合、移行元と移行先のサーバーが同じパーティションで構成されていることを確認します。
ハイパーバイザーの脆弱性、移行のセットアップ、予期しないハードウェアの相関関係、ネットワーク接続の問題や構成の問題、ストレージリソース、SANのセットアップなどはすべて、ワークロードの移行を失敗させる可能性があります。幸いなことに、IT専門家が最も一般的な移行問題を理解すれば、これらの問題の多くは一般的に分離して修正することができます。
