サポート終了となる ve1 ハードウェアからワークロードを移行する

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

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

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

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

始める前に

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

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

  • 厳格な 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 の記事 HCX アプライアンスを別の SSO、PSC、または 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 アカウント チームと協力して、ワークロードに適した ve2 ノードタイプ（mega、large、standard、small）と数を決定します。技術仕様については、VMware Engine HCI ノードタイプをご覧ください。

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

移行のライセンスとソフトウェアの要件は次のとおりです。

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

コミットメントと請求を計画する

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

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

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 になります。

移行手順

移行は次の手順で行います。

  1. EoL の対象となる各クラスタのターゲット容量オファーを確認します。別の構成（ノードタイプまたは数量）が必要な場合は、アカウント チームと協力して容量オファーを調整します。Google Cloud
  2. 確約利用割引（CUD）を管理する: ハードウェアの EoL 日よりも有効期限が長いアクティブな ve1 CUD コミットメントがある場合は、アカウント チームと協力して調整または終了します。
  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. コンソールで、新しいターゲット ハードウェア ファミリー（ve1 または ve2）とノード数の割り当てリクエストを送信します。 Google Cloud
  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 を右クリックして [Migrate] を選択します。
  2. [Change both compute resource and storage] を選択します。
  3. 新しいクラスタと移行先データストアを選択します。

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

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

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

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

  • VMware HCX サービス メッシュ: Fleet アプライアンスは vMotion をサポートしていません。 ターゲット クラスタに HCX サービス メッシュ コンポーネントを再デプロイします。詳細については、Broadcom の記事 HCX アプライアンスを別の SSO、PSC、または 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 CLI、または Terraform を使用して、ターゲット ハードウェアに新しいプライベート クラウドをデプロイします。
  2. 現在のデプロイで従来の VMware Engine ネットワーク（2022 年 11 月より前に作成された VMware Engine ネットワーク）を使用している場合は、同じプロジェクトに新しいプライベート クラウドを作成して、従来の VMware Engine ネットワークを引き続き使用します。詳細については、 標準の Google Cloud VMware Engine ネットワークと従来の Google Cloud VMware Engine ネットワークをご覧ください。

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

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

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

  • VMware HCX: 新しいプライベート クラウドに HCX サービス メッシュをデプロイします。
  • Aria プロダクト: Google ライセンスの Aria スイートを使用している場合は、新しいプライベート クラウドに 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)]"

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

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

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

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

  • タイムラインの重複: CUD コミットメントの有効期限が現在のノード 配置グループの EoL 日より前に切れる場合、請求は変更されません。
  • ve1 ノードでの移行: ターゲット容量オファーで新しい ve1 ハードウェアを使用する場合、CUD コミットメントは期間中有効です。
  • ve2 ノードへの移行: CUD タイプは特定のハードウェア カテゴリにバインドされるため、アカウント チームと協力してアクティブな 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 を購入する必要があります。アカウント チームと協力してください。
ve1 一部の変換可能な ve1 CUD が EoL 後に期限切れになる ve2 ve1 CUD を適切な ve2 ポータブル ライセンス CUD に変換します。アカウント チームと協力してください。

次のステップ