ワークロードを新しいコンピューティングインスタンスに移動する

状況によっては、既存の仮想マシンインスタンス（VM）から新しい VM にワークロードを移動する必要があります。新しい VM に移動する理由には次のものがあります。

新しい VM タイプを活用して、ストレージやネットワークの速度を向上させるため。たとえば、C2 から H3 にアップグレードしてネットワーク帯域幅を改善します。
移行元の VM タイプと比較して優れた費用対効果のメリットを活用するため。たとえば、第 5 世代 Intel Xeon プロセッサの価値を得るために N1 から N4 にアップグレードします。
新しい VM タイプでのみ使用可能な機能を使用するため。たとえば、C3 から N4 に移行して、カスタムマシンタイプで提供される追加の VM シェイプを活用します。
仮想マシン（VM）インスタンスをベアメタルインスタンスに変更するため。

最新世代のマシンシリーズにアップグレードする際に、現在のコンピューティングインスタンスのオペレーティングシステムが新しいマシンシリーズでサポートされており、現在のインスタンスが新しいマシンシリーズでサポートされていない機能やディスクタイプを使用していない場合、現在の VM で次の条件を満たしている場合は、コンピューティングインスタンスのマシンタイプを編集するで説明されている、より簡単な手順を使用できます。

オペレーティングシステム（OS）が新しいマシンシリーズでサポートされている
現在の VM が、新しいマシンシリーズでサポートされている機能またはディスクタイプのみを使用している
VM がローカル SSD ストレージを使用していない
VM がマネージドインスタンスグループ（MIG）に含まれていない

VM 移行オプションを評価する

ある VM タイプから別の VM タイプへの移行は、新しい VM タイプのリージョンでの可用性、移行元と移行先のディスクタイプの互換性、ローカル SSD の可用性、ディスクインターフェース、ストレージオプション、ゲスト OS と互換性のある VM に関するネットワークインターフェースなど、いくつかの要因によって異なります。

コンピューティングの要件

マシンファミリーのリソースのドキュメントで、ワークロードに適した VM タイプを確認します。アプリケーションに特定のハードウェア（GPU）、高パフォーマンス、低コストのいずれが必要かを検討します。
新しい VM でサポートされているディスクタイプの機能を確認します。Persistent Disk で利用可能なすべての機能が Hyperdisk でサポートされているわけではありません。たとえば、同じディスクを複数の VM にアタッチできるのは、Persistent Disk の場合のみで、Hyperdisk ではこの機能を利用できません。
新しい VM タイプの機能を確認します。新しい VM マシンシリーズでは、現在の VM で使用しているものと同じ機能（カスタムマシンタイプ、ローカル SSD、Shielded VM など）がサポートされていない場合があります。
リージョンとゾーンを確認して、新しいマシンシリーズが現在の VM と同じようにすべてのリージョンで使用できることを確認します。デプロイ、可用性、障害復旧計画を調整する必要があることがあります。
SCSI から NVMe に移行する OS 移行計画を確認します。
- 新しい VM に新しいバージョンの OS が必要な場合は、アプリケーションが新しい OS と互換性があることを確認します。
- Arm に移行し、現在のオペレーティングシステムで Arm イメージを使用できない場合は、アプリケーションを実行する新しいオペレーティングシステムを選択して、アプリケーションが新しいオペレーティングシステムに対応していることを確認します。

ストレージ要件

新しい VM マシンシリーズでサポートされているストレージタイプとサポートされているストレージインターフェースを確認します。
- デフォルトでは、第 1 世代と第 2 世代の VM は、Persistent Disk ストレージタイプと VirtIO-SCSI インターフェースのみを使用します。
- 第 3 世代以降のマシンシリーズ（M3、C3、N4 など）は、NVMe インターフェースのみをサポートし、Hyperdisk とローカル SSD ストレージタイプのみをサポートします。
アプリケーションとゲストオペレーティングシステム（OS）が、新しい VM で使用されるディスクインターフェースタイプをサポートしていることを確認します。
現在の VM が新しい VM シリーズでサポートされていないブートディスクまたはデータディスクタイプ（pd-standard など）を使用している場合は、ディスクタイプの変更で説明するように、スナップショットを使用してソースディスクを新しいディスクタイプに変更できます。

ネットワーキングの要件

新しい VM でサポートされているネットワークインターフェースを確認します。M3、C3、N4 などの新しい VM シリーズは、gVNIC インターフェースのみをサポートしています。VirtIO-net インターフェースはサポートしていません。アプリケーションが新しい VM タイプで使用可能なインターフェースをサポートしていることを確認します。

gcloud compute instances describe コマンドを使用して VM の nic-type を表示します。これは gVNIC に設定する必要があります。

  gcloud compute instances describe VM_NAME --zone=ZONE

既存の VM の移行を準備する

評価セクションを完了したら、次のステップは移行元の VM に変更を加えて VM の移行を準備することです。

コンピューティングリソースを準備する

リソースを移動する予定のリージョンとゾーンで割り当てをリクエストします。マシンタイプに既存の割り当てがある場合は、その割り当ての移動をリクエストできます。このプロセスが完了するまでに数日かかります。
新しい VM の予約を作成して、新しいリージョンとゾーンでマシンリソースを使用できるようにします。
新しいリージョンで VM を作成する場合は、新しいリージョンに VPC ネットワークとサブネットを作成します。
新しい VM でサポートされているバージョンに OS をインプレースアップグレードし、期待どおりに動作することを確認します。新しい VM が現在のバージョンの OS をサポートしている場合は、追加の作業は必要ありません。
VM インスタンスをベアメタルインスタンスに変更する場合は、独自のハイパーバイザまたは仮想マシンソフトウェアをベアメタルインスタンスにインストールすることが必要になる場合があります。ベアメタルインスタンスは、仮想関数ではなく物理関数としてのみ提示される IDPF ネットワークインターフェースを使用します。

ストレージリソースを準備する

現在の VM が使用しているブートディスクタイプが新しい VM マシンシリーズでサポートされている場合は、VM インスタンスの作成と起動の手順、または Arm VM インスタンスの作成と起動の手順に沿って、仕様に基づいて新しい VM を構成します。
現在の VM に Persistent Disk ブートディスクがあり、新しい VM が Hyperdisk のみをサポートしている場合は、Persistent Disk ボリュームを Hyperdisk に移行する必要があります。ディスクタイプを変更するをご覧ください。インスタンスのブートディスクを交換するには、ブートディスクを切断して再アタッチするをご覧ください。
新しい VM が現在の VM と同じディスクタイプをサポートしていない場合は、デプロイスクリプトまたはインスタンステンプレートを更新する必要があります。
アプリケーションが、Linux システムのデバイス名でアタッチされた Persistent Disk を参照しないようにします。
ローカル SSD 情報を移動する必要がある場合は、ローカル SSD ディスクをバックアップするのに十分な大きさの空のディスクを作成します。
- 可能であれば、新しい VM でサポートされているディスクタイプを使用します。
- 現在の VM と新しい VM の両方でサポートされているディスクタイプがない場合は、現在の VM でサポートされている Persistent Disk タイプを使用して一時ディスクを作成します。
このディスクを現在の VM にアタッチし、ディスクをフォーマットしてマウントします。現在の VM にアタッチされているローカル SSD ディスクからこの一時ディスクにデータをコピーします。
現在の VM にアタッチされているすべてのディスクのスナップショットを作成します。スナップショットを取得した後にディスクに保存されたデータは一時ディスクには保存されません。スナップショットですべてのデータをキャプチャしてください。
- アプリケーション整合性スナップショット
- 標準スナップショット
- ローカル SSD データを含む一時ディスクを追加する
現在の VM でブートディスクに pd-standard Persistent Disk を使用している場合は、次の手順で pd-standard ディスクをサポートしていない VM に移動します。
1. 非常に少数の VM を移行する場合:
  1. 現在の VM の pd-standard ブートディスクのスナップショットを作成します。
  2. ブートディスクスナップショットから VM を作成します。新しい VM を作成するときに、ブートディスクでサポートされているディスクタイプ（Hyperdisk Balanced や Hyperdisk Extreme など）のいずれかを選択します。
2. 複数の VM を移行する場合は、カスタムイメージを使用して新しい VM を作成します。
  1. 現在の VM の pd-standard ブートディスクのスナップショットを作成します。
  2. ディスクスナップショットをソースとして使用してカスタムイメージを作成します。
  3. カスタムイメージから VM を作成します。新しい VM を作成するときに、ブートディスクでサポートされているディスクタイプ（Hyperdisk Balanced や Hyperdisk Extreme など）のいずれかを選択します。
非ブート Persistent Disk を古い VM から新しい VM に移動します。
- Persistent Disk のスナップショットを作成して、同じサイズまたは大きいサイズの新しい Hyperdisk を新しい VM に追加すると、スナップショットを Hyperdisk に復元できます。
- また、ある VM から別の VM にファイルを転送することもできます。
省略可: 移行の開始時にローカル SSD ディスクの内容をサポートされているディスクタイプに移動した場合は、保存したデータをローカル SSD に移動して一時ディスクを削除できます。
ローカル SSD の NVMe インターフェースとドライバを使用するための準備については、インターフェースの選択をご覧ください。

Linux を実行している VM から移行する場合は、デバイス名ではなくシンボリックリンクを使用するように変更されたアプリケーションやスクリプトが正常に動作することをテストします。

Microsoft Windows を実行する VM から移行する場合:

2022 年 5 月より前に作成された VM の NVMe ドライバを更新する必要があります。これは、現在の VM のブートディスクと、新しい VM の作成に使用される以前に作成されたスナップショットまたはカスタムイメージに適用されます。
Microsoft NVMe ドライバ（StorNVMe）の使用を開始するように Windows を再構成する必要があります。起動デバイスを更新する手順に沿って操作します。

ネットワークリソースを準備する

gVNIC を使用するようにインスタンスを更新するには、Google Virtual NIC の使用をご覧ください。
カスタムイメージを使用して VM を作成した場合や、gVNIC をサポートしていない OS からインプレースアップグレードをした場合は、gVNIC をサポートするカスタムイメージを作成するで説明されているように、gVNIC を使用するようにイメージにタグ付けする必要があります（guest-os-features プロパティに文字列 GVNIC を含める必要があります）。また、gVNIC ドライバを含める必要もあります。VM に gVNIC のタグが付けられていることを確認するには、VM インスタンスが起動しないの診断セクションの手順を行います。
カスタム NIC キュー数を構成した場合は、キューの割り当てとマシンタイプの変更をご覧ください。
現在の VM で使用されている IP アドレスを保持する場合は、IP アドレスを静的 IP アドレスに昇格させます。
静的 IP アドレスの割り当てを解除します。

ワークロードを新しい VM に移動する

VM を移行用に準備したら、次のステップはワークロードを新しい VM に移動することです。

VM を第 1 世代から第 2 世代に移行する場合は、VM のマシンタイプを編集するの説明をご覧ください。既存の VM の名前を変更する場合は、VM の名前を変更するをご覧ください。

このタスクに必要な権限

このタスクを行うには、次の権限が必要です。

VM に対する compute.instances.setMachineType

このセクションでは、第 1 世代または第 2 世代の VM から第 3 世代（またはそれ以降）の VM にワークロードを移動する方法について説明します。この手順では、新しい VM インスタンスを作成して、ワークロードを新しい VM に移動します。

新しい VM を作成する

第 1 世代または第 2 世代の VM（N1 や N2 など）からワークロードを移行する場合は、まず新しい VM を作成して、次にワークロードを移行する必要があります。

リソースを変更する前に、既存の VM を停止します。
バックアップされたストレージリソースをサポートするマシンタイプを選択します。
サポートされている OS イメージを選択するか、作成したカスタムイメージを使用します。
サポートされているブートディスクを選択します。
別のリージョンに VM を作成する場合は、新しい VPC ネットワークを指定します。
古い VM のエフェメラル IP アドレスを昇格させた場合は、静的 IP アドレスを指定します。
古い VM から接続を解除したディスクを新しい VM に追加します。
古い VM にアタッチされているディスクが新しい VM でサポートされていないディスクタイプを使用している場合は、空のディスクを追加します。新しい VM を作成する際は、サポートされているディスクタイプを使用して、古いディスクと同じサイズ以上のサイズを指定します。これには、ローカル SSD データのコピーを保持するために古いディスクにアタッチした一時ディスクも含まれます。
元の VM に関連付けられていたすべての静的 IP アドレスを新しい VM に再割り当てします。
ワークロードをサポートするために必要なユーザー、ドライバ、パッケージ、ファイルディレクトリを新しい VM で構成します。
変更したアプリケーションとプログラムを新しい VM にインストールします。必要に応じて、新しいオペレーティングシステムまたはアーキテクチャでプログラムを再コンパイルします。

インスタンスの起動後

新しい VM に空のディスクを追加した場合は、それらのディスクをフォーマットしてマウントします。次に、古いディスクで取得したスナップショットを新しいディスクに復元します。
一時ディスクからローカル SSD ディスクにデータをコピーして一時ディスクを削除します。
カスタムイメージを使用していない場合は、アプリソフトウェアと必要なドライバやパッケージをインストールします。
転送ルールを更新します。
必要に応じて DNS エントリを更新します。
新しい VM が意図したとおりに動作し、すべてのデータがコピーされたことを確認したら、古い VM を削除します（まだ削除していない場合）。
新しいディスクのスナップショットスケジュールを作成します。

ワークロードの移行中に問題が発生した場合は、テクニカルアカウントマネージャー（TAM）または Google Professional Services Organization（PSO）にお問い合わせください。

次のステップ

Linux サーバーと Windows サーバーの既知の問題を確認する。
トラブルシューティングのヒントを確認する。
移行ライフサイクルの詳細を確認する。