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

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

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

最新の世代のマシンシリーズにアップグレードする際に、現在の（移行元）VM が次の条件を満たしている場合は、コンピューティング インスタンスのマシンタイプを編集するで説明する、より簡単な方法を使用できる場合があります。

• オペレーティング システム（OS）バージョンが新しいマシンシリーズでサポートされている。
• 移行元の VM にアタッチされているブートディスクのディスクタイプが、新しいマシンシリーズでサポートされている。
• VM がローカル SSD ストレージを使用していない。
• GPU が接続された VM が G2 マシンタイプを使用している。詳細については、GPU の追加または削除をご覧ください。
• VM が、新しいマシンシリーズでサポートされている機能のみを使用している。
• VM がマネージド インスタンス グループ（MIG）に含まれていない。
• VM が gVNIC ネットワーク インターフェースを使用している。

始める前に

• まだ設定していない場合は、認証を設定します。認証とは、Google Cloud のサービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のいずれかのオプションを選択して Compute Engine に対する認証を行います。
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

  2. Set a default region and zone.

  REST

  このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。

必要なロール

VM の編集または変更に必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

• Compute インスタンス管理者（v1）（roles/compute.admin.v1）
• ネットワーク タイプを変更する: Compute Engine ネットワーク管理者（roles/compute.networkAdmin）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

これらの事前定義ロールには、VM の編集または変更に必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

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

マシンタイプ間での移行は、新しいマシンタイプのリージョンでの可用性、移行元と新しいマシンシリーズのゲスト OS に対するストレージ オプションとネットワーク インターフェースの互換性など、いくつかの要因によって異なります。

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

現在のインスタンスと新しいマシンタイプの次の要件を確認します。

• マシン ファミリーのリソースのドキュメントで、ワークロードに適したマシンタイプを確認します。アプリケーションに特定のハードウェア（GPU）、高パフォーマンス、低コストのいずれが必要かを検討します。
• 新しいマシンタイプでサポートされているディスクタイプの機能を確認します。Hyperdisk は Persistent Disk のほとんどの機能をサポートしていますが、すべてではありません。ただし、Hyperdisk には Persistent Disk では利用できない追加機能があります。
• 候補となるマシンシリーズの機能を確認します。新しいマシンシリーズは、現在のマシンシリーズで使用しているものと同じ機能（カスタム マシンタイプ、ローカル SSD、Shielded VM など）をサポートしていない場合があります。
• リージョンとゾーンを確認して、新しいマシンシリーズが現在の VM と同じようにすべてのリージョンで使用できることを確認します。デプロイ、高可用性、障害復旧計画を調整する必要があることがあります。
• OS 移行計画を確認します。
  • 新しい VM に新しいバージョンの OS が必要な場合は、アプリケーションが新しい OS バージョンと互換性があることを確認します。
  • Arm に移行し、現在の OS バージョンで Arm イメージを使用できない場合は、アプリケーションを実行する新しい OS または OS バージョンを選択し、アプリケーションが新しい OS と互換性があることを確認します。
• 移行元の C3 VM インスタンスがサポート対象のオペレーティング システムとネットワーク ドライバを使用している限り、C3 VM インスタンスから C3 ベアメタル インスタンスに移行できます。
• C3 以外のマシンシリーズからベアメタル インスタンスに移行する場合は、新しいインスタンスを作成する必要があります。独自のハイパーバイザを実行しなければならない場合がありますが、IDPF ドライバが有効になっている限り、C3 metal でサポートされている任意のオペレーティング システムを実行することもできます。ベアメタル インスタンスは、仮想機能ではなく物理機能としてのみ提示される IDPF ネットワーク インターフェースを使用します。

ストレージ要件

現在のインスタンスと新しいインスタンス タイプの次のストレージ要件を確認します。

• 新しいマシンシリーズでサポートされているストレージ タイプとサポートされているストレージ インターフェースを確認します。
  • デフォルトでは、第 1 世代と第 2 世代のマシンシリーズは、Persistent Disk ストレージ タイプと VirtIO-SCSI インターフェースのみを使用します。
  • 第 3 世代以降のマシンシリーズ（M3、C3、N4 など）は、NVMe インターフェースのみをサポートし、Hyperdisk とローカル SSD ストレージ タイプのみをサポートします。
  • ベアメタル インスタンス（C3 metal、X4 など）は Hyperdisk のみをサポートします。
• ディスクの互換性:
  • ブートディスクが新しいマシンシリーズでサポートされていないディスクタイプ（pd-standard など）を使用している場合は、新しい VM に新しいブートディスクを作成する必要があります。
  • OS を新しいバージョンにアップグレードしていて、オペレーティング システムがインプレース アップグレードをサポートしていない場合は、新しいブートディスクを作成する必要があります。一時的な非ブートディスクにコピーしない限り、移行元のブートディスク上のデータはすべて失われます。次に、新しいブートディスクを作成し、一時的な非ブートディスクに保存されているデータを新しいブートディスクにコピーします。
  • OS バージョンをアップグレードしない場合は、現在のブートディスクのスナップショットを取得して、サポートされている新しいディスクタイプに復元できます。VM を作成するときに、この新しいディスクをブートディスクとして使用できます。
  • 非ブートディスクが新しいマシンシリーズでサポートされていないディスクタイプを使用している場合は、ディスクタイプの変更で説明するように、スナップショットを使用して移行元ディスクを新しいディスクタイプに変更できます。
• ローカル SSD ディスクは新しい VM に移行できません。すべてのローカル SSD データを保存するのに十分なサイズのディスクを現在の VM にアタッチし、ディスクタイプの変更で説明するように、スナップショットを使用して移行元ディスクを新しいディスクタイプに変更できます。ローカル SSD ディスクがアタッチされた VM を作成したら、データをローカル SSD ディスクにコピーできます。
• 現在の VM インスタンスがストレージ プール内のディスクを使用しているにもかかわらず、ワークロードを別のリージョンの VM に移動する場合は、新しいリージョンでディスクとストレージ プールを再作成する必要があります。
• 新しいマシンシリーズで別のディスク インターフェース（SCSI ではなく NVMe など）を使用している場合、ゲスト OS のディスク デバイス名が異なります。アプリケーションとスクリプトが、アタッチされたディスクを参照するときに永続的なデバイス名またはシンボリック リンクを使用するようにします。

ネットワーキングの要件

現在のインスタンスと新しいインスタンス タイプの次のネットワーク要件を確認します。

• 新しい VM でサポートされているネットワーク インターフェースを確認します。

  • デフォルトでは、第 1 世代と第 2 世代のマシンシリーズは VirtIO ネットワーク インターフェースのみを使用します。
  • 第 3 世代以降のマシンシリーズ（M3、C3、N4 など）は、gVNIC ネットワーク インターフェースのみをサポートします。
  • ベアメタル インスタンスは、IDPF ネットワーク インターフェースのみをサポートします。

• アプリケーションとオペレーティング システムが、マシンシリーズで使用可能なインターフェースをサポートしていることを確認します。

• VM のネットワーク構成を確認し、割り当てられた IP アドレスを保持する必要があるかどうかを判断します。その場合は、IP アドレスを静的 IP アドレスに昇格させる必要があります。

• 現在の VM で VM ごとの Tier_1 ネットワーキング パフォーマンスを使用している場合は、新しいマシンシリーズで使用可能かどうか、また必要かどうかを確認します。たとえば、C2 マシンタイプでは Tier_1 ネットワーキングを使用できますが、H3 VM では必要ありません。

現在の VM のネットワーク インターフェース タイプを確認するには、gcloud compute instances describe コマンドを使用して VM の nic-type を表示します。

  gcloud compute instances describe VM_NAME --zone=ZONE

VM で nic-type が VIRTIO に設定されている場合、ネットワーク インターフェースのタイプを変更することはできません。新しい VM を作成し、ネットワーク インターフェース タイプを gVNIC に設定する必要があります。

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

評価セクションを完了したら、次のステップは、新しい VM インスタンスのリソースをリクエストし、移行元の VM インスタンスのバックアップを準備して、VM インスタンスの移行を準備することです。

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

現在のインスタンスを新しいインスタンスに移動する準備を行う手順は次のとおりです。

1. リソースを移動する予定のリージョンとゾーンで割り当てをリクエストします。マシンタイプに既存の割り当てがある場合は、その割り当ての移動をリクエストできます。このプロセスが完了するまでに数日かかります。
2. 新しい VM インスタンスの予約を作成して、新しいリージョンとゾーンでマシンリソースを使用できるようにします。予約済みリソースの使用方法を確認し、予約済みリソースを使用できることをテストします。
3. 新しいリージョンを含めるように高可用性と障害復旧の計画を拡張します。
4. 必要に応じて、現在の VM で OS をアップグレードします。
   1. オペレーティング システム ベンダーでサポートされている場合は、新しいマシンシリーズでサポートされているバージョンに OS をインプレース アップグレードし、新しい OS バージョンでワークロードが期待どおりに動作することを確認します。
   2. OS のインプレース アップグレードがサポートされていない場合は、新しい VM を作成するときに新しいブートディスクを作成する必要があります。現在のブートディスクからコピーする必要がある情報を特定し、新しい VM に転送できるように、非ブートディスクの一時的な場所にコピーします。現在の VM に非ブートディスクがアタッチされていない場合:
      • 第 1 世代と第 2 世代のマシンタイプの場合は、Persistent Disk ストレージを VM に追加するをご覧ください。
      • 第 3 世代以降のマシンタイプの場合は、VM に Hyperdisk ストレージを追加するをご覧ください。
5. ご使用の Linux ディストリビューションに該当する場合は、/etc/udev/rules.d/ で udev ルールを確認します。このファイルには、現在のインスタンスのハードウェア構成に関連するエントリが含まれていますが、新しいインスタンスには含まれていません。たとえば、次のエントリにより、eth0 が virtio-pci ドライバ（VirtIO Net）によって提供されるため、gve ドライバ（gVNIC）がこのインターフェースを提供できなくなります。これにより、新しいインスタンスでネットワーク起動スクリプトと接続の問題が発生する可能性があります。

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="virtio-pci", ATTR{dev_id}=="0x0", KERNELS=="0000:00:04.0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

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

現在のインスタンスにアタッチされているディスク内のデータを新しいインスタンスに移動する準備を行うには、次の操作を行います。

1. Linux システムで、更新したアプリケーションとスクリプトをテストし、ディスクのデバイス名ではなく、永続デバイス名またはシンボリック リンクで動作することを確認します。
2. Microsoft Windows を実行する VM から移行する場合:
   • 2022 年 5 月より前に作成された VM の NVMe ドライバを更新する必要があります。これは、現在の VM のブートディスクと、VM の作成に使用される以前に作成されたスナップショットまたはカスタム イメージに適用されます。
   • Microsoft NVMe ドライバ（StorNVMe）の使用を開始するように Windows を再構成する必要があります。起動デバイスを更新する手順に沿って操作します。
3. 新しい VM が現在の VM と同じディスクタイプをサポートしていない場合は、新しいマシンシリーズをサポートするようにデプロイ スクリプトまたはインスタンス テンプレートを更新する必要があります。
4. 現在の VM が新しいマシンシリーズでサポートされていないブートディスク タイプを使用しており、同じ構成の複数の VM を移行する場合は、新しい VM の作成時に使用するカスタム イメージを作成します。
   1. 現在の VM の pd-standard ブートディスクのスナップショットを作成します。
   2. ディスク スナップショットをソースとして使用してカスタム イメージを作成します。
5. ローカル SSD 情報を移動する必要がある場合は、ローカル SSD ディスクをバックアップするのに十分な大きさの空のディスクを作成します。
   1. 可能であれば、新しい VM でサポートされているディスクタイプを使用します。
   2. 現在の VM と新しい VM の両方でサポートされているディスクタイプがない場合は、現在の VM でサポートされているディスクタイプを使用して一時ディスクを作成します。
   3. 現在の VM に新しいディスクをアタッチし、ディスクをフォーマットしてマウントします。
   4. 現在の VM にアタッチされているローカル SSD ディスクからこの一時ディスクにデータをコピーします。

6. 新しい VM でサポートされていないディスクタイプを使用している現在の VM のディスクのディスクタイプを変更します。ディスクデータを新しいディスクに移動するには、ディスクのスナップショットを作成します。また、別の VM にファイルを転送することもできます。

   1. VM の実行中にスナップショットを作成できますが、スナップショットの作成後にディスクに書き込まれたデータはキャプチャされません。スナップショットは増分であるため、VM を停止した後に 2 つ目のスナップショットを取得すると、最新の変更をすべてキャプチャできます。このアプローチにより、新しい VM に切り替えている間、VM を使用できない時間を最小限に抑えることができます。
   2. また、VM を停止した後にすべてのディスク スナップショットを作成することもできます。ディスクタイプが新しいマシンシリーズでサポートされている場合でも、VM にアタッチされているすべてのディスクのスナップショットを作成することをおすすめします。コピーされたローカル SSD データを含む一時ディスクも対象にします。
   3. ディスクのスナップショットの取得にかかる時間は、ディスクのサイズやディスク内のデータ量など、複数の要因によって異なります。たとえば、85% 使用済みの 1 TiB ディスクのスナップショットを作成する場合、スナップショットの完了に 5 分かかることがあります。ただし、85% 使用済みの 100 TiB ディスクのスナップショットを取得する場合は、完了までに 11 分かかることがあります。移行プロセスを開始する前にディスクのテスト スナップショットを実行して、スナップショットの所要時間を把握することをおすすめします。

7. オフラインにできるディスクがある場合は、移行元 VM が使用可能な間に、次の方法でデータを新しいディスクに移動できます。

   1. VM からディスクを切断します。
   2. ディスクのスナップショットを作成します。
   3. スナップショットを使用して、新しいマシンシリーズでサポートされているディスクタイプで新しいディスクを作成します。新しいディスクのサイズは、移行元ディスクと同じか、それ以上にする必要があります。

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

次の手順で、現在のインスタンスで使用されているネットワーク構成を更新して、新しいインスタンスをサポートします。

1. 現在の VM が gVNIC を使用していない場合は、gVNIC を使用するネットワーク インターフェースを持つ新しいインスタンスを作成する必要があります。Compute Engine VM での gVNIC の使用の概要で、新しいインスタンスの作成手順を確認します。
2. 新しいリージョンで VM を作成する場合は、新しいリージョンに VPC ネットワークとサブネットを作成します。
3. カスタム NIC キュー数を構成した場合は、キューの割り当てとマシンタイプの変更をご覧ください。
4. 移行元 VM で使用されている IP アドレスを保持する場合は、IP アドレスを静的 IP アドレスに昇格させます。
5. 移行元 VM を停止する前に、静的 IP アドレスの割り当てを解除します。

SUSE Enterprise Linux Server オペレーティング システムを準備する

ハードウェア固有の依存関係を回避するには、initramfs（初期 RAM ファイル システム）を再ビルドします。これには、より幅広いドライバとモジュールが含まれ、オペレーティング システムが他のインスタンス タイプと互換性を持つようになります。これを行わないと、VM が正常に起動できない既知の問題が発生します。

システムをシャットダウンする前に、root として次のコマンドを実行して、すべてのドライバで initramfs を再ビルドします。

  sudo dracut --force --no-hostonly

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

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

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

このタスクに必要な権限

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

• VM に対する compute.instances.setMachineType

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

1. 新しい VM を作成するときに、ブートディスクでサポートされているディスクタイプ（Hyperdisk Balanced など）を選択します。

新しい VM を作成する

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

1. 移行元 VM が、新しいマシンシリーズでサポートされているディスクタイプの非ブートディスクを使用している場合は、VM からディスクを切断します。
2. 移行元の VM を停止します。
3. 移行元 VM にアタッチされているすべてのディスクのスナップショットを作成します。
4. 公開イメージまたは gVNIC を使用するように構成されたカスタム イメージを使用して、新しいコンピューティング VM インスタンスを作成します。新しい VM を作成するときに、次のオプションを選択します。
   • 選択したマシンシリーズからマシンタイプを選択します。
   • サポートされている OS イメージを選択するか、以前に作成したカスタム イメージを使用します。
   • ブートディスクにサポートされているディスクタイプを選択します。
   • 元のディスクのスナップショットから新しいディスクを作成した場合は、その新しいディスクを含めます。
   • 別のリージョンにインスタンスを作成する場合は、新しい VPC ネットワークを指定します。
   • 新しいインスタンスで VirtIO と gVNIC の両方がサポートされている場合は、gVNIC を選択します。
   • 移行元 VM のエフェメラル IP アドレスを昇格させた場合は、静的 IP アドレスを指定します。
5. 新しい VM を起動します。

インスタンスの起動後

新しいインスタンスが作成されて起動されたので、次の手順で新しいインスタンスの構成を完了し、移行元インスタンスからすべてのデータをコピーします。

1. 移行元 VM から切断したディスクを新しい VM にアタッチします。
2. 移行元 VM が新しい VM でサポートされていないディスクタイプを使用している場合は、スナップショットからディスクを作成して新しいインスタンスにアタッチします。新しいディスクを作成するときに、新しい VM でサポートされているディスクタイプを選択し、元のディスクと同じサイズか、それ以上のサイズを指定します。
3. 元の VM が新しい VM 用に再作成されたディスクにリソースポリシーを使用している場合は、新しいディスクにリソースポリシーを追加する必要があります。
4. カスタム イメージではなく公開 OS イメージを使用して新しい VM を作成した場合は、次の操作を行います。
   1. ワークロードをサポートするために必要なユーザー、ドライバ、パッケージ、ファイル ディレクトリを新しいインスタンスで構成します。
   2. 変更したアプリケーションとプログラムを新しい VM にインストールします。必要に応じて、新しい OS またはアーキテクチャでプログラムを再コンパイルします。
5. 省略可: ローカル SSD ディスクの内容を一時ディスクに移動し、新しい VM にローカル SSD ストレージがアタッチされている場合は、ディスクのフォーマットとマウント後に、一時ディスクからローカル SSD ディスクにデータを移動できます。
6. 移行元 VM に関連付けられていたすべての静的 IP アドレスを新しい VM に再割り当てします。
7. ロードバランサの構成や転送ルールの更新など、新しい VM の高可用性を確保するために必要な追加タスクを完了します。
8. 省略可: 必要に応じて、新しい VM の DNS エントリを更新します。
9. 推奨: 新しいディスクのディスク バックアップをスケジュールします。
10. 推奨: OS を別のバージョンまたはアーキテクチャに変更した場合は、アプリケーションを再コンパイルします。

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

n1-standard-8 から n4-standard-8 への移行例

次の例は、n1-standard-8 VM から n4-standard-8 VM への移行例です。n1-standard-8 VM には、Ubuntu1804 イメージを実行する PD-SSD ブートディスクと PD-SSD データディスクがあります。この手順では、CLI または REST API を使用する必要があります。

N1 VM を N4 VM にアップグレードするには、次の 2 つの方法があります。

オプション 1: N1 VM が VirtIO ネットワーク インターフェースを使用している場合は、新しい N4 VM を作成する必要があります。N4 は、gvnic ネットワーク インターフェースと Hyperdisk Balanced ディスクのみをサポートしています。Persistent Disk ブートディスクとデータディスクのスナップショットを作成し、それらのスナップショットから Hyperdisk Balanced ディスクを作成します。Hyperdisk Balanced ディスクをアタッチし、Hyperdisk Balanced ディスクを使用して新しい N4 VM を作成します。

新しいバージョンの Ubuntu OS を使用して、新しい Hyperdisk Balanced ブートディスクを作成することもできます。このシナリオでは、ブートディスクのスナップショットから新しい Hyperdisk Balanced ディスクを作成できますが、そのディスクを非ブートディスクとして N4 VM にアタッチします。その後、復元したスナップショットからシステム以外のデータを新しいブートディスクにコピーできます。

オプション 2: N1 VM が gvnic ネットワーク インターフェースを使用し、オペレーティング システムに NVMe ストレージ デバイス ドライバがあり、アタッチされたローカル SSD ディスクまたは GPU がなく、マネージド インスタンス グループ（MIG）の一部でない場合は、マシンタイプを N1 から N4 に変更できますが、Persistent Disk ディスクタイプを Hyperdisk Balanced ディスクに変更する必要があります。まず、Persistent Disk のブートディスクとデータディスクを切断し、ディスクのスナップショットを作成します。次に、スナップショットをソースとして使用して Hyperdisk Balanced ディスクを作成し、マシンタイプを変更した後に新しい Hyperdisk Balanced ディスクを N4 VM にアタッチします。VM に GPU が接続されている場合は、まず GPU を切断する必要があります。

ディスクのスナップショット作成時間は、ディスクの合計 TB 数など、複数の要因によって異なります。たとえば、85% 使用済みの 1 TB ディスクのスナップショットを作成する場合、スナップショットの完了に 5 分かかることがあります。ただし、85% 使用済みの 100 TB ディスクのスナップショットを取得する場合は、完了までに 11 分かかることがあります。移行プロセスを開始する前に、ディスクのテスト スナップショットを実行して、スナップショットの所要時間を把握することをおすすめします。

クリーンアップ

新しい VM に接続できることと、ワークロードが新しい VM で想定どおりに実行されていることを確認したら、不要になった次のリソースを削除できます。

1. 移行元 VM にアタッチされているディスク用に作成したスナップショット。
2. 移行元 VM にアタッチされていたディスクのスナップショット スケジュール。
3. ローカル SSD データを新しい VM にコピーするために作成した一時ディスク。
4. 移行元 VM と、その VM にアタッチされているすべてのディスク。

次のステップ

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