廃止される ve1 ハードウェアからワークロードを移行する

このドキュメントでは、廃止される ve1 ハードウェアからサポートされている ve1 または ve2 ハードウェアに Google Cloud VMware Engine ワークロードを移行する方法について説明します。ワークロードを移行するには、次の 2 つの方法があります。オプション 1 では、既存のプライベート クラウドに新しいハードウェア クラスタを追加して、混合ノードのプライベート クラウドを作成します。オプション 2 では、新しいハードウェアを使用して新しいプライベート クラウドをデプロイします。

Google Cloud は、物理インフラストラクチャが耐用年数の終了を迎えるにつれて、第 1 世代の ve1 ハードウェアを段階的に廃止しています。廃止は、さまざまなサービス リージョンにわたるプレースメント グループに基づいてバッチで行われます。

Google Cloud がハードウェアの廃止をスケジュール設定すると、詳細なタイムライン、リソース上限、移行手順を含む、対象となるサポート終了（EoL）通知が届きます。これらのターゲット通知は 2026 年第 1 四半期にロールアウトを開始し、ve1 ハードウェアの最初のバッチは 2027 年第 1 四半期にサポートを終了します。プレースメント グループが予定された廃止日に達したら、ワークロードを新しいハードウェアに移行できます。

このドキュメントでは、サポート終了のお知らせの詳細と、ワークロードを移行する手順について説明します。サービスの継続性を維持し、サービスレベル契約（SLA）の対象範囲を確保するには、クラスタが EoL 日に達する前に移行を完了します。

始める前に

新しいリソースを構成する前に、このセクションで要件、制限事項、移行をブロックする可能性のある要因を確認してください。この情報は、移行を成功させ、サービスの中断を回避するのに役立ちます。

注意: サービスの中断を回避し、移行の失敗を防ぐため、移行プロセスを開始する前に、リソースの上限、IP アドレス空間の可用性、ライセンス契約を確認してください。

移行を開始する前に考慮すべき重要な要件は次のとおりです。

• 厳格な 60 日間の移行期間: Google は、ターゲット容量の割り当てリクエストを承認してから最大 60 日間、移行をサポートします。
  • この期間内に、ワークロードの移行を完了し、廃止されたハードウェアを廃止する必要があります。
  • ワークロードの移行期間がターゲット クラスタのプロビジョニング後 60 日を超える場合は、標準利用資格を超える使用量をカバーするために、独自の Broadcom ライセンス（BYOL）が必要です。

移行をブロックする可能性のある要因は次のとおりです。

• IP アドレス空間ブロッカー（オプション 1 ブロッカー）: オプション 1（混合ノード プライベート クラウド）では、既存のプライベート クラウドに十分な空き管理 IP アドレス空間が必要です。追加されたターゲット クラスタをサポートするには、十分な容量が必要です。これには少なくとも 3 つのノードが必要です。既存の CIDR ブロックで少なくとも 3 つの追加ノードをサポートできない場合は、オプション 1 を使用できません。この場合は、代わりに新しいプライベート クラウドをデプロイする必要があります（オプション 2）。IP アドレス空間の容量を計画するを確認して、利用資格を確認します。
• ライブ マイグレーション データベースのサポート: 一部のデータベース プラットフォームでは、ライブ vMotion 移行を許容できません。これらの VM データベース インスタンスを特定し、ターゲット クラスタで直接再構築する計画を立てます。
• VMware HCX 接続: VMware HCX Fleet アプライアンスは標準のライブ vMotion をサポートしていません。ターゲット クラスタに HCX サービス メッシュを再デプロイする計画を立てる必要があります。詳細については、Broadcom の記事 Migrating HCX appliances to a different SSO, PSC, or vCenter をご覧ください。

IP アドレス空間の容量を計画する

混合ノードのプライベート クラウド（オプション 1）を使用して移行する場合は、既存のプライベート クラウドの管理 IP アドレス範囲に十分な空き容量があることを確認します。追加されたターゲット クラスタには、少なくとも 3 つのノードが必要です。

1. プライベート クラウドの管理 IP アドレス範囲と IP プランのバージョンを表示します。リファレンスについては、サブネット CIDR の範囲分割バージョンをご覧ください。
2. プライベート クラウド内の現在のノード数をカウントします。
3. CIDR サイズでサポートされている最大ノード数を確認します。vSphere と vSAN サブネットの CIDR の範囲のサイズの表を参照してください。
4. 計算: Existing node count + 3 ≤ maximum nodes supported by CIDR size

CIDR ブロックで少なくとも 3 つの追加ノードをサポートできない場合は、混合ノードのプライベート クラウドを使用できません。この場合は、代わりに新しいプライベート クラウドをデプロイする必要があります（オプション 2）。

ノード容量を計画する

将来の容量オファーで ve2 ノードが指定されている場合は、 Google Cloud Google のアカウント担当者と協力して、ワークロードに適した ve2 ノードタイプ（mega、large、standard、small）と数を決定します。技術仕様については、VMware Engine HCI ノードタイプをご覧ください。

ライセンスとソフトウェアの要件

移行では、次のライセンスとソフトウェアの要件を考慮してください。

• Broadcom ライセンス: ワークロードの移行期間がターゲット クラスタのプロビジョニング後 60 日を超える場合は、標準の利用資格を超える使用量をカバーするために、独自の Broadcom ライセンスを持ち込む必要があります。
• VMware HCX サービス メッシュ: VMware HCX Fleet アプライアンスは vMotion をサポートしていません。ターゲット クラスタに HCX サービス メッシュを再デプロイする必要があります。詳細については、Broadcom の記事 Migrating HCX appliances to a different SSO, PSC, or vCenter をご覧ください。
• 管理プレースメント グループ: Google は、正しいプレースメント グループに容量をプロビジョニングします。混合ノード設定の場合、Cloud カスタマーケアはターゲット プレースメント グループに新しいクラスタを設定します。新しいプライベート クラウドの場合は、プライベート クラウドを作成する前に、計画しているプライベート クラウド名を Google のアカウント担当者 に送信して、Google が正しいプレースメント グループに構成するようにします。

プランのコミットメントと請求

移行パスを選択する前に、確約利用割引（CUD）の次の制約を確認してください。

• ve1 CUD の制限事項: ポータブル ライセンスの料金オプションを含む 1 年間の ve1 CUD のみを使用できます。新しい 1 年間の確約を適用するには、同じリージョンの新しい ve1 プレースメント グループに移行する必要があります。
• ve2 CUD のサポート: 3 年間の CUD コミットメントは、ve2 ノード ファミリーでのみサポートされています。
• 利用資格の確認: 新しいコミットメントは、リージョン内のノード配置グループの残存期間に依存するため、 Google Cloud Google のアカウント担当者と協力して利用資格を確認する必要があります。

ve1 のサポート終了通知について

ve1 ライフサイクル終了（EoL）通知は、ve1 ベアメタルノードがライフサイクルの終了に近づいていることをお知らせする公式メールです。

EoL 通知の主なコンポーネント

この通知には次の詳細情報が含まれます。

• EoL 通知が適用されるリージョンとゾーン。
• 現在の使用量: リージョン内のすべてのアクティブなプロジェクトと ve1 プライベート クラウドを一覧表示し、次の詳細を表示します。
  • プライベート クラウドの名前
  • プロジェクト番号
  • クラスタ名
  • ve1 ノードタイプ（HCI または SON）
  • 各タイプの ve1 ノードの数
  • クラスタのサポートが終了するサポート終了日
• 将来の容量の提案: EoL 通知には、リージョン内の各 ve1 クラスタの将来の容量の提案が記載されています。
  • ターゲット容量オファーが ve1 の場合: 現在の ve1 クラスタと同じ数のノードで、十分な長寿命構成。
  • ターゲット容量オファーが ve2 の場合: ve2-mega-128 ノードタイプ。同等以上のコンピューティング、メモリ、ストレージ容量のリソースを提供します。
  • SLA と許容障害数（FTT）: 3 つ以上のノードを持つクラスタの場合、将来のオファーは最低 3 つのノードで構成されます。これにより、デフォルトの FTT 値が 1 になります。

注: EoL 通知のクラスタの表では、現在のサポート終了通知の対象となる VMware Engine クラスタが黄色でハイライト表示されます。この通知には、完全性を確保するために、リージョン内の他のクラスタも記載されています。複数のプロジェクトを管理している場合は、プロジェクトごとに個別の通知が届くことがあります。

移行手順

移行は、次の手順のシーケンスで構成されます。

1. EoL の対象となる各クラスタのターゲット容量オファーを確認します。別の構成（ノードタイプや数量）が必要な場合は、Google Cloud アカウント担当の Google チームと協力して容量プランを調整してください。
2. 確約利用割引（CUD）を管理する: ハードウェアの EoL 日付よりも長い有効期間の ve1 CUD コミットメントがある場合は、Google のアカウント担当者と協力して調整または終了します。
3. 移行パスを選択します。混合ノード ファミリーのプライベート クラウドを作成するか、新しいプライベート クラウドのデプロイを作成するかを選択します。移行方法を決定するには、次のセクションで移行方法を比較します。
4. 移行を実行する: 選択したパスを使用してワークロードを移行します。Google が割り当てリクエストを承認してから移行を完了するまでのサポート期間は、最長で 60 日間です。
5. 古いハードウェアを廃止する: 移行を完了するには、廃止する ve1 クラスタと関連する割り当てを削除します。

移行オプションを比較する

適切な移行パスを選択すると、ネットワークを正しく構成できます。また、移行中のサービス中断を回避することもできます。次の表は、各オプションの技術的基準、ネットワーク基準、運用基準を比較したものです。

機能	オプション 1: 混合ノード（ハイブリッド）プライベート クラウド	オプション 2: 新しいプライベート クラウドのデプロイ
説明	ターゲット ハードウェア ファミリー クラスタを既存のプライベート クラウドに直接追加します。	ターゲット ハードウェアに完全に新しいプライベート クラウドをデプロイします。
管理 IP 範囲の要件	追加されたクラスタ（少なくとも 3 つのノード）をサポートするために、既存のプライベート クラウドに十分な空き CIDR 空間が必要です。空き容量が不足しているため、オプション 1 はブロックされます。	フレキシブル。新しい管理 IP アドレス範囲を完全に使用します。
ネットワーキングと DNS への影響	最小。現在のネットワーク、サブネット、管理インターフェースを保持します。	高。新しいネットワーク トポロジ、DNS、アクセス座標を構成する必要があります。
移行ワークフロー	標準のライブ VMware vMotion と Storage vMotion。	VMware HCX を使用した大規模な移行。
作成方法	Cloud カスタマーケア チケットを使用してリクエストします（ハイブリッド プライベート クラウドにクラスタを自分で追加することはできません）。	完全なセルフサービス（コンソール、REST API、Google Cloud CLI、または Terraform）。

オプション 1: 混合ノードのプライベート クラウドの移行

この方法では、ターゲット ハードウェア ファミリー クラスタを既存のプライベート クラウドに直接追加し、クラスタごとにワークロードを移行できます。60 日間の移行制限は、各クラスタの移行に適用されます。

ターゲット ハードウェアの割り当てリクエストを送信する

1. Google Cloud コンソールで、新しいターゲット ハードウェア ファミリー（ve1 または ve2）とノード数の割り当てリクエストを送信します。
2. 割り当てリクエストの説明に、次のプロパティを明示的に記述します。
   • "ve1 hardware end of life"
   • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
   • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
3. Google がリクエストを承認すると、コンソールで新しい割り当てを確認できます。

プライベート クラウドにターゲット クラスタを作成する

1. 混合ノードのプライベート クラウドでクラスタを自分で作成することはできません。クラスタの設定をリクエストするには、サポート チケットを送信します。
2. サポート チケットに次の詳細情報を入力します。
   • プロジェクト番号
   • プライベート クラウドの名前
   • 新しいターゲット クラスタ名
   • 新しいマシン ファミリー（ve1 または ve2）とノードタイプ
   • HCI ノードの数
   • ストレージのみのノードの数（該当する場合）
3. ターゲット クラスタがオンラインになると、Cloud カスタマーケアから通知が届きます。

ワークロードの移行

ターゲット クラスタの準備ができたら、VMware vMotion と Storage vMotion を組み合わせて、ワークロード VM と VM ディスクを移行します。

1. vSphere Client で、VM を右クリックして [移行] を選択します。
2. [コンピューティング リソースとストレージの両方を変更する] を選択します。
3. 新しいクラスタと移行先のデータストアを選択します。

プライベート クラウドの管理 VM を移行する

廃止するクラスタがプライベート クラウドのプライマリ（最初の）クラスタである場合は、管理 VM を移行する必要があります。

1. Google Cloud VMware Engine コンソールまたは REST API を使用して、管理 VM を新しいクラスタに移行します。詳細な手順については、プライベート クラウド リソースを管理するをご覧ください。
2. 移行中は、他のクラスタ アクティビティ（ノードの追加など）を実行しないでください。このプロセスでは、プライベート クラウドのステータスが更新中に変わります。
3. 古い ve1 クラスタに接続されている NFS データストアをすべてマウント解除します。

他の構成とアプリケーションを調整する

• VMware HCX サービス メッシュ: Fleet アプライアンスは vMotion をサポートしていません。ターゲット クラスタに HCX サービス メッシュ コンポーネントを再デプロイします。詳細については、Broadcom の記事 Migrating HCX appliances to a different SSO, PSC, or vCenter をご覧ください。サポートが必要な場合は、サポート チケットを送信してください。
• Aria アプリケーション: 標準のワークロード VM と同様に、Aria アプリケーション VM を移行します。
• データベース プラットフォーム: vMotion を許容できない場合は、ターゲット クラスタでデータベース インスタンスを再構築します。

廃止されたクラスタを廃止する

1. ワークロードと管理 VM の移行を完了して確認したら、 Google Cloud コンソール、REST API、または Google Cloud CLI コマンドラインを使用して、廃止するクラスタを削除します。
2. 割り当てリクエストを送信して、ソースクラスタのハードウェアの割り当てを減らします。リクエストの説明で、次の情報を指定します。
   • "ve1 hardware end of life"
   • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
   • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

オプション 2: 新しいプライベート クラウドの移行

この方法では、ターゲット ハードウェアに完全に新しいプライベート クラウドをデプロイし、VMware HCX を使用して廃止するプライベート クラウドからワークロードを移行できます。

リクエストの割り当て

1. ターゲット ハードウェアの割り当てリクエストを送信します。
2. リクエストの説明に、次のように明記します。
   • "ve1 hardware end of life"
   • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
   • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
   • "New PC Name: [YOUR_NEW_PC_NAME]"

新しいプライベート クラウドを作成する

1. Google Cloud コンソール、REST API、Google Cloud CLI、または Terraform を使用して、新しいプライベート クラウドをターゲット ハードウェアにデプロイします。
2. 現在のデプロイで以前の VMware Engine ネットワーク（2022 年 11 月より前に作成された VMware Engine ネットワーク）を使用している場合は、同じプロジェクトに新しいプライベート クラウドを作成して、標準のネットワーキング機能を引き続き使用します。詳細については、標準とレガシーの Google Cloud VMware Engine ネットワークをご覧ください。

HCX を使用したワークロードの移行

1. 新しいプライベート クラウドに VMware HCX を設定します。
2. HCX 設定をリンクし、移行メッシュを構成して、廃止されるプライベート クラウド クラスタからワークロードとデータを移動します。廃止するプライベート クラウドに複数のクラスタがある場合は、ワークロードの移行元となるすべてのクラスタを含めるように HCX コンピューティング プロファイルとサービス メッシュが構成されていることを確認します。
3. 適切なメンテナンスの時間枠で移行バッチを計画します。

サービスとアプリケーションを調整する

• VMware HCX: 新しいプライベート クラウドに HCX サービス メッシュをデプロイします。
• Aria プロダクト: Google ライセンスの Aria Suite を使用している場合は、新しいプライベート クラウドに Aria Suite Lifecycle Manager（LCM）をインストールするサポートをリクエストします。

古いプライベート クラウドを廃止する

1. すべてのワークロードが新しいプライベート クラウドで機能することを確認したら、古いクラスタとプライベート クラウド自体を削除します。
2. 割り当てリクエストを送信して、廃止された割り当てを解放します。リクエストの説明で、次の項目を指定します。
   • "ve1 hardware end of life"
   • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
   • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

コミットメントと請求を管理する

お客様のアカウント担当の Google チームと協力して、移行中に請求構造を整理し、確約利用割引（CUD）を調整します。

二重使用の請求に対するインセンティブ

移行期間中に廃止されたフットプリントとターゲット フットプリントの両方を実行することに伴う同時使用（二重）料金を相殺するため、Google は一定期間、二重使用料金を軽減するインセンティブを提供しています。これらの特典を活用するには、移行の期間を慎重に計画してください。

確約利用割引（CUD）の調整

アクティブな ve1 確約利用割引（CUD）に対する ve1 ハードウェア移行の影響は、タイムラインと容量のオファーによって異なります。

• タイムラインの重複: CUD コミットメントが現在のノード配置グループの EOL 日付より前に期限切れになる場合、請求は変更されません。
• ve1 ノードでの移行: ターゲット容量オファーで新しい ve1 ハードウェアを使用する場合、CUD コミットメントは期間中有効です。
• ve2 ノードへの移行: CUD タイプは特定のハードウェア カテゴリにバインドされるため、Google のアカウント担当者と協力して、アクティブな ve1 契約を終了または変換する必要があります。
  • 変換できない CUD: 既存の標準 CUD をキャンセルして、新しい標準 ve2 CUD を購入する必要があります。
  • 変換可能な CUD: アクティブな標準 ve1 CUD をポータブル ライセンス ve2 CUD に変換できます。

現在の使用状況	タイムライン	今後の特典	CUD の影響
ve1	すべての ve1 CUD は EoL より前に期限切れになります	ve1 または ve2	既存の CUD には影響しません。
ve1	一部の ve1 CUD は EoL 後に期限切れになる	ve1	移行は既存の CUD に影響しません。ターゲットの ve1 プレースメント グループの耐用年数が十分である。
ve1	一部の変換できない ve1 CUD は EoL 後に期限切れになる	ve2	既存の ve1 CUD を終了し、新しい ve2 CUD を購入する必要があります。Google のアカウント担当者にお問い合わせください。
ve1	一部の転換可能な ve1 CUD は EoL 後に期限切れになる	ve2	ve1 CUD を適切な ve2 ポータブル ライセンス CUD に変換します。Google のアカウント担当者にお問い合わせください。

次のステップ

• VMware Engine の高可用性と冗長性のオプションについて学習します。
• プライベート クラウドの自動スケーリング ポリシーを管理する方法を学習する。