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

このドキュメントでは、廃止される ve1 ハードウェアから、サポートされている ve1 または ve2 ハードウェアに Google Cloud VMware Engine ワークロードを移行する方法について説明します。ワークロードを移行するには、次の 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 を右クリックし、[移行] を選択します。
  2. [コンピューティング リソースとストレージの両方を変更する] を選択します。
  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 ネットワーク）を使用している場合は、同じプロジェクトに新しいプライベート クラウドを作成して、標準のネットワーキング機能を引き続き使用します。詳細については、 標準の 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 に変換します。アカウント チームと協力してください。

次のステップ