ストレッチされたVMware vSANクラスタの作成

すべての前提条件の構成が完了したら、VMware vSANストレッチ・クラスタの作成に進むことができます。このステップでは、OCI Dedicated Region AとOCI Dedicated Region Bのホスト間の接続、および3番目のリージョンにデプロイされたWitnessノード間の接続を形式化します。

クイックスタート・ウィザードを使用するか、VMware vCenter UIでクラスタ、構成、vSAN、フォルト・ドメインおよびストレッチ・クラスタに直接移動できます。

このプロセス中に次を構成します。

  • OCI専用リージョンのホストをフォルト・ドメイン1に割り当てます
  • OCI専用リージョンBホストをフォルト・ドメイン2に割り当てます
  • 定足数の「Witness Host」(以前に追加したもの)を指定します

詳細は、Stretched Cluster RequirementsおよびVMware vSAN Stretched Cluster Guideを参照してください。

ストレッチされたクラスタの作成後:

  • vSANヘルス・チェックを実行して、クラスタの整合性を検証します。
  • ネットワーク関連のエラー(MTUの不一致やルーティングの問題など)に対処します。

ノート:

特定のホストで、元のクラスタから失効したvSANオブジェクトが発生する場合があります。削除するには、このガイドを参照してください: vSANデータストアでアクセスできないオブジェクトを削除する方法

完了すると、クラスタは上位90sのvSANヘルス・スコアを報告し、構成が成功したことを示します。

NSXの構成

VMware vSANクラスタがストレッチされた状態で、クロスサイト・オーバーレイ・ネットワーキングをサポートするようにVMware NSXを更新します。このステップにより、両方のリージョンのESXiホストが、それぞれのトランスポート・ゾーンを使用してNSXトンネル経由で通信できるようになります。

NSX TEP構成のクローニング
  • NSX TEP IPプールをOCI専用リージョンB NSXマネージャからOCI専用リージョンNSXマネージャにコピーします。
  • OCI専用リージョンBにまだ存在する管理ESXiホストとのIPの競合を回避するには、OCI専用リージョンAの新しいIPプールを.10から開始するように構成します。

    例: OCI専用リージョンNSXマネージャで、OCI専用リージョンBホストに対して.10から.20の範囲のTEPプールを作成し、既存のIPと重複しないようにします。

OCI専用リージョンAでのOCI専用リージョンBアップリンク・プロファイルの作成
  • 「OCI専用リージョン」NSXマネージャで、OCI専用リージョンBホスト専用の新しいアップリンク・プロファイルを定義します。
  • 正しいVLAN IDを使用し、アップリンク順序がOCI専用リージョンB構成と一致していることを確認します。
NSXのホストの準備
  • トランスポートゾーンとして OVERLAY-TZおよび VLAN-TZを使用します。
  • ホストの準備中に、ホストがOCI専用リージョンAからのものかOCI専用リージョンBからのものかに応じて、適切なアップリンク・プロファイルを割り当てます。

    注意:一部のシナリオでは、特にフェイルオーバー・イベント後に、NSXトンネル・インタフェースが正しく起動しない場合があります。これを解決するには:

    • 影響を受けるESXiホストまたはを再起動します。
    • ホストでSSHを介してservices.sh restartを実行します。

    これにより、すべてのNSXサービスが正しい順序で開始され、トンネルの安定性が回復されます。

NSXオーバーレイ・セグメントの作成
  • 4つのNSXオーバーレイ・セグメントを作成します。
  • これらのセグメントが両方のサイトのすべてのESXiホストにわたって表示および同期されていることを確認します。
DHCPの構成(オプション)
  • オプションで、新しいオーバーレイ・セグメントのDHCP設定を構成します。
  • DNS設定は、このガイドですでに構成されているため、ここで繰り返す必要はありません。
エンドツーエンドのオーバーレイ接続の検証
  • 4つの仮想マシンをデプロイし、両方のリージョンに各ホストに1つ配置します。
  • 各 VMに、それぞれのセグメント範囲内の静的IPアドレスを割り当てます。
  • セグメント・ゲートウェイと仮想マシン間のPing: 拡大した環境全体でのL3オーバーレイ接続を検証します。

オーバーレイVMの外部接続の有効化

VMware NSXオーバーレイ・仮想マシンが外部ネットワークにアクセスできるようにするには、関連するVLANのNATルールおよびルーティングを構成します。

VCN-MGMT-ActiveとVCN-MGMT-Failoverの両方で、NSX Edgeアップリンク1 VLANのNAT構成を更新します:

  • 両方のリージョンで同じ外部アクセスIPを使用し、OCI専用リージョンAデプロイメント中に使用したものと一致します。
  • 使用されるIPがNSXエッジ・ノードのHA VIPであり、NSXマネージャに表示されることを確認します。

vSphere VLANの外部アクセス・ルールも更新します:

  • 両方のVCNsで、vcenter-vip、nsxt-manager-vipおよびHCX-manager-vip (HCXが使用されている場合)のNATルールを構成します。

DNS転送のサポート

オーバーレイVMは通常、NSX-Tで定義されたDNSフォワーダ(192.168.253.253など)を使用します。これらのDNS問合せをルーティングするには:

  1. NAT Gatewayの専用ルート表を作成します。
  2. 静的ルートを定義します。
    • 宛先: 10.x.x.x (オーバーレイVMサブネット)
    • ターゲット: NAT Gateway
    • DNSフォワーダIP: 192.168.253.253

この構成は、両方のサイトでレプリケートする必要があります。一貫した動作のために、新しいルート表をNAT Gatewayに関連付けます。

フローティングVCNへのESXiホストVLANの再割当て

現在の設定では、各ESXiホストに2つの物理NICがプロビジョニングされ、それぞれがVCN-Primary (OCI専用リージョンA)およびVCN-Secondary (OCI専用リージョンB)へのVNICアタッチメントを介して構成されたVLANのデフォルト・セットに関連付けられます。These VNICs are configured using the secondary CIDR block (172.45.0.0/16) attached to the respective VCNs.

拡大構成への移行を完了するには、タグが200以上のすべてのVLAN (vSphere、HCX、NSX Edgeなど)をフローティングVCNsに移行する必要があります:
  • OCI専用リージョンAのVCN-MGMT-Active
  • OCI専用リージョンBのVCN-MGMT-Failover

フローティングVCNへのVNICの移行

両方のSDDCのESXiホストごとに次のステップを実行します。
  1. ESXiホストの詳細へのアクセス: OCIコンソールで、「コンピュート、ESXiホスト」に移動します。
  2. 既存のVNICアタッチメントの削除: ホストごとに、VLAN 201以上に関連付けられたVNICをVCN- プライマリまたはVCN- セカンダリから削除します。

    ノート:

    古いVLANが存在する場合、同じVLANに対して新しい VNICを作成できないため、この手順は必須です。
  3. フローティングVCN内のVNICを再作成します:
    • 対応する浮動VCN内のVLANごとに新しいVNICを作成します:
      • OCI専用リージョンAでのVCN-MGMT-Activeの使用
      • OCI専用リージョンBでのVCN-MGMT-Failoverの使用
    • 適切な -NEW接尾辞でタグ付けされたVLANを選択して、元の接尾辞と区別します。

    ホストごとの両方のVNICに対してこのプロセスを繰り返します。体系的なアプローチをお薦めします。VLAN 201の場合は、vnic0およびvnic1から開始し、置換を完了してから、次のVLANに進みます。

    セカンダリ・サイト・ホストの特別な考慮事項

    プライマリサイトでホストのVNICを移行したあと、セカンダリサイト内のすべてのホストについてプロセスを繰り返します。ただし、次の1つの重要な詳細を確認してください。

    • セカンダリ・サイトのvSphere管理コンポーネントは、最初に一時VLAN(VLAN-Stretched-Cls-Mgmt-vSphere-TEMPなど)にデプロイされました。
    • この一時VLANは、移行中に所定の位置にとどまることができます。これは、拡張されたvSAN機能には影響せず、必要に応じてvCenterおよびNSXコンポーネントへのフォールバック・アクセスを提供します。

    この一時VLANを保持すると、VNICおよびネットワーク移行ワークフロー中に中断のない管理アクセスが保証されます。

    接続の影響と回復

    VNICの更新時には、vCenter、NSXマネージャまたはESXiホストへの接続の一時的な損失が予想されます。リカバリを保証するには:

    1. DRGアタッチメントの確認: 適切な管理VCNs(アクティブとフェイルオーバーの両方)が、それぞれのDynamic Routing Gateways (DRG)にアタッチされていることを確認します。
    2. ルート表の更新:
      • DRGを指すように、各管理VCNのマスター・ルート表を更新します。
      • 要塞サブネット・ルート表を更新して、管理トラフィックがVCNs間およびリージョン間で正しくルーティングされるようにします。
    3. アクセスの検証:
      • ルートを更新したら、要塞ホストからすべての管理インタフェースへのアクセスをリストアする必要があります。
      • リソースにアクセスできない場合は、NSGルールを再確認し、VCNs間のルート伝播を行います。

    vNICの移行後のクリーンアップ

    VNICの移行が完了したら:

    • 172.45.0.0/16 CIDRブロックに属するすべての未使用VLANをVCN-PrimaryおよびVCN-Secondaryから削除します。
    • セカンダリCIDR (172.45.0.0/16)は、使用されなくなったため、VCN-Primaryからデタッチします。

    OCIでは、アクティブなリソース(VNIC、サブネットまたはVLAN)が使用されていない場合にのみ、CIDRのデタッチが許可されます。

    • 警告インジケータは、OCIコンソールのSDDCリソース・ページで確認できます。これは、Oracle Cloud VMware SolutionサービスがVCN-Primaryに最初にデプロイされたコンポーネントをトラッキングしなくなったためです。

    新規VCNアタッチメントのルーティングの更新

    1. OCI専用リージョンAのDRGにVCN-MGMT-Activeをアタッチします。
    2. ルート表の更新:
      • VCN-MGMT-Activeの場合: デフォルト・ルート(0.0.0.0/0)をDRGにポイントします。
      • VCN-Primaryの要塞サブネットの場合: DRGを指すようにルート表を更新して、VMware vCenterおよびVMware NSXマネージャに引き続きアクセスできることを確認します。

    これらの変更が行われた後、基礎となるインタフェースが別のVCNに存在していても、OCI専用リージョンAのVMware vCenterおよびVMware NSXマネージャに要塞ホストからアクセスできるようになります。

DRSアフィニティー規則、HA、および VMware vSANストレージポリシーの構成

ストレッチされたクラスタが完全に動作し、ネットワークが両方のサイトで安定したら、分散リソース・スケジューラ(DRS)、高可用性(HA)を構成し、サイト対応のVMware vSANストレージ・ポリシーをワークロードおよび管理仮想マシン(VM)に割り当てます。

これらの構成により、フォルト・ドメイン間での仮想マシンの最適な配置が保証され、サイト障害時の自動リカバリが可能になります。

ストレッチされたクラスタへのVMの移行

まず、すべての管理仮想マシンおよびテスト・ワークロード・仮想マシンを、新しく作成されたストレッチ・クラスタに移行します:

  • vMotionを使用して、元のサイト固有のクラスタから拡大されたクラスタに仮想マシンを移動します。
  • すべて(ネットワーク、ストレージ、ポートグループ)が正しく構成されている場合、VMの移行は問題なく完了します。

デフォルトのNSX DRSルールが存在し、「MUST」に設定されている場合は、それらを削除します。これらはHA操作を妨げ、NSX EdgeノードおよびNSX Manager VMのフェイルオーバーを防止できます。

VMおよびホスト・グループの作成

ワークロード配置のアフィニティ・グループを定義します。

  1. ホスト・グループの作成:
    • プライマリ・サイトに属するホストをグループ化します。
    • セカンダリ・サイトに属するホストをグループ化します。
  2. VMグループの作成:
    • 各サイト内のホストに存在する必要があるグループ管理仮想マシン(vCenter、NSXマネージャ、NSXエッジ・ノード、HCXマネージャなど(該当する場合)。
    • 同様に、すべてのワークロード・仮想マシンをグループ化します(この場合は、すべてのテスト・仮想マシン)。

VM/ホスト・アフィニティ・ルールの定義

グループの定義後:

  • VM対ホスト・アフィニティ・ルールを作成して、目的のサイトのホスト上に仮想マシンを保持します。
  • 「ホストでのVMの実行」ルールを使用して、フェイルオーバー・シナリオにおけるHAの柔軟性を確保します。
  • このようなルールを、管理VMとワークロードVMグループの両方に対して作成します。

この設定により、通常の操作中に、各サイトが目的のワークロードをホストするようになりますが、ホストまたはサイトに障害が発生した場合の自動リカバリが可能になります。

高可用性(HA)の有効化
  • アフィニティ・ルールの設定後に、クラスタ・レベルでHAが有効であることを確認します。
  • ホスト障害イベント時に仮想マシンを再起動するデフォルト・オプションにより、サイト全体の停止など、予期しない障害時にVMが再起動されます。

ストレッチされたvSANストレージポリシーの作成と適用

拡大された構成で両方のサイト間でデータの冗長性を確保するには、新しいvSANストレージベースのポリシー管理(SBPM)ポリシーを定義します。このポリシーは、フォルト・ドメインおよび目撃サイト間でVMデータを分散する方法を制御します。

ポリシー内で次の配置ルールを構成します:

  • ストレージ・タイプ: vSAN
  • サイト障害の許容範囲: サイトのミラー化 – ストレッチされたクラスタ
  • 許容できない障害: データの冗長性がない
  • オブジェクト当たりのディスク・ストライプ数: 1
  • オブジェクトのIOPS制限: 0

他のオプションはすべてデフォルト値のままにします。

ポリシーが作成されると、次のようになります。

  1. ストレッチされたクラスタ内のすべてのテストおよび管理仮想マシンにポリシーを適用します。
  2. 「モニター」、「vSAN」、「オブジェクトの再同期」にナビゲートして、再同期プロセスを監視および追跡します。
  3. 再同期の完了後、オブジェクトの配置を確認して、ポリシーが期待どおりに機能していることを確認します:
    • 1つのレプリカ・オブジェクトがプライマリ・サイトにあります
    • 2番目のレプリカ・オブジェクトはセカンダリ・サイトにあります
    • 証人コンポーネントは、リモートの証人リージョンにあります

すべての仮想マシンは、最初は非準拠として表示されます。各 VMまたはVMのグループを選択し、新しく作成された拡張ポリシーを手動で割り当てて、それらをコンプライアンスに組み込みます。

さらに、「モニター、vSAN、オブジェクトおよび仮想オブジェクトの再同期」にナビゲートします。再同期プロセスが完了したら、各VMの仮想オブジェクトがプライマリ・サイト、セカンダリ・サイトおよび証人ノード全体に正しく分散され、拡大されたクラスタ設計への完全な準拠が検証されていることを確認する必要があります。