Oracle Cloud VMware Solutionを使用したOCIリージョンへのVMware vSANストレッチ・クラスタのデプロイについて学習

Oracle Cloud VMware Solutionを使用した、OCIリージョンへのVMware vSANストレッチ・クラスタのデプロイについて学習

Oracle Cloud Infrastructure (OCI)は、その複数のアベイラビリティ・ドメイン・リージョン全体で高可用性とフォルト・トレランスを提供します。これらのリージョンは本質的にデータ・センター・レベルの障害分離を提供し、各アベイラビリティ・ドメインを複数のフォルト・ドメインに分割して、ラックレベルの停止から保護します。この組込みアーキテクチャは、ほとんどのエンタープライズ・ワークロードの自己回復性要件に対応します。

VMwareワークロードの場合、Oracle Cloud VMware Solutionは、3つのアベイラビリティ・ドメインを持つリージョン内の複数のアベイラビリティ・ドメイン・デプロイメントをサポートします。この場合、複雑なクロスサイト構成を必要とせずに、VMware HAおよびVMware vSANを利用して、VMware vSANストレッチ・クラスタを単一リージョン内にネイティブにデプロイできます。

ただし、1つのアベイラビリティ・ドメインのみのOCIパブリック・リージョン、またはOracle Cloud Infrastructure Dedicated Region(以前はOracle Dedicated Region Cloud@Customerと呼ばれていたOCI Dedicated Region)では、複数のアベイラビリティ・ドメイン構成は使用できません。サイト全体の停止に対するリージョンレベルの保護を必要とする環境では、別のアプローチが必要です。このソリューション・プレイブックでは、Oracle Cloud VMware Solutionが提供するフルスタック制御によって実現されるソリューションである、複数のOCIリージョンにVMWare vSANストレッチ・クラスタをデプロイするための検証済みの顧客管理アーキテクチャを紹介します。

ノート:

このデプロイメント・モデルは、OCI専用リージョンで正常にテストされました。必要なレイテンシ、ホスト・シェイプおよびネットワーク接続要件が満たされている場合は、OCIパブリック・リージョンでもレプリケートできます。

OCIは、クロスリージョンVMware vSANストレッチ・クラスタをデプロイするためのネイティブまたは自動化された方法を提供していませんが、Oracle Cloud VMware Solutionは、独自の柔軟性により実現します。お客様は、VMware vCenter、VMware NSXおよびVMware ESXiホストに対する完全な管理制御を保持し、より制限されたマネージド・クラウドVMware製品では困難または不可能な高度な構成を設計および実装できるようにします。

このソリューション・プレイブックでは、Oracle Cloud VMware Solutionを使用してこの強力な構成を構築するためのアーキテクチャ・ガイダンスと詳細なステップについて説明します。

コア概念の理解

VMware vSANストレッチ・クラスタとは何ですか。

vSANストレッチ・クラスタは、単一の論理VMware vSANデータストアを物理的に分離した2つの場所に拡張するVMware構成です。どちらの場所もアクティブ/アクティブ・サイトとみなされ、1つのサイトが使用できなくなった場合に、構成によって継続的な可用性が保証されます。VMwareのネイティブ機能であるvSphere HAのおかげで、仮想マシン(VM)はサイト間で自動的にフェイルオーバーできます。vSANは、1つのサイトと目撃ノードが動作し続けるかぎり、ストレージの可用性を確保します。

OCIのコンテキストでは、このアーキテクチャはOCI専用リージョンに適切にマッピングされます。このリージョンは、通常、VMware vSAN拡張デプロイメントの厳しい低レイテンシ要件を満たすほど地理的に近いものです。

詳細は、Broadcomの公式ドキュメント「vSANストレッチ・クラスタの概要」を参照してください。

vSAN拡張クラスタをOCIおよびOracle Cloud VMware Solutionに拡張

VMware vSANストレッチ・クラスタは通常、物理的に分離された2つのサイトにまたがりますが、OCI内では、Oracle Cloud VMware Solutionは、VMwareソフトウェア定義データ・センター(SDDC)を単一のアベイラビリティ・ドメインにデフォルトでデプロイするか、それに応じて構成すると同じリージョン内の複数のアベイラビリティ・ドメインにまたがってデプロイできます。このデプロイメント・モデルは、基礎となるVirtual Cloud Network (VCN)のリージョナル・スコープと一致します。これは、OCIリージョン内で動作しますが、OCIリージョン間で動作しません。

リージョンレベルの回復性を実現し、リージョンの停止から保護するために、OCI Dedicated Regionを使用しているお客様は、2つの異なるOracle Cloud VMware Solution SDDCを個別のOCI Dedicated Regionにデプロイできます。これらのSDDCは、OCIのプライベート・バックボーン・ネットワークを介して相互接続されるため、安全で低レイテンシの通信が可能になります。必要なVMware vSAN Witnessノードは、拡張されたクラスタ構成を完了するために、地理的に近い3番目のリージョン(OCIパブリック・リージョンなど)にデプロイされます。

この設計により、VMware環境内のアクティブ/アクティブ・サイトの可用性が実現され、地域的な障害が発生した場合でも継続的な操作が保証されます。高可用性とディザスタ・リカバリのために、VMwareとOracleの両方のベストプラクティスに準拠しています。

アーキテクチャ

このアーキテクチャは、複数のOCIリージョンにカスタムのVMware vSANストレッチ・クラスタをデプロイする方法を示しています。

大まかなトポロジは、次のもので構成されます。

プライマリ・サイト: OCI専用リージョンAにデプロイされたOracle Cloud VMware Solution SDDC。
セカンダリ・サイト: OCI専用リージョンBにデプロイされたOracle Cloud VMware Solution SDDC。
目撃者サイト: VMware vSAN Witness Applianceをデプロイするためのリージョン別の場所。

これらのサイト間の通信は、OCIのプライベート・バックボーンとOCI FastConnectを介して確立されます。これらはどちらも、安定したVMware vSANストレッチ・クラスタの低レイテンシおよび高帯域幅の要件を満たすために必須です。

ノート:

IPSec VPNはこの構成ではサポートされていません。

次の図に、このアーキテクチャを示します。

図ocrs-vsan-stretched-cluster.pngの説明

ocvs-vsan-stretched-cluster-oracle.zip

次の項では、OCI Dedicated Region全体のOracle Cloud VMware SolutionでのVMware vSAN拡張クラスタの正常なデプロイメントに影響を与える主な技術的考慮事項について説明します。

ネットワークに関する考慮事項

このアーキテクチャの重要なイネーブラは、顧客テナンシ内でOCI専用リージョンを相互接続する堅牢なOCIバックボーン・ネットワークです。このバックボーンは、VMware vSANレプリケーション・トラフィックおよびサイト間のハートビート・シグナリングに必要な高速で低レイテンシの通信を保証します。

計画する主な要因:

Dynamic Routing Gateways (DRG)を使用して、OCI専用リージョンAのVCNsとOCI専用リージョンBの間のリモート・ピアリング接続(RPC)を確立します。これにより、すべてのVMware ESXiホストで完全なメッシュ接続が可能になります。
OCI FastConnect (IPSec VPNではない)を使用して、両方のOCI専用リージョンを、証人をホストするパブリックOCIリージョンに接続します。これにより、一貫した低レイテンシと信頼性の高いスループットが保証され、証人のコミュニケーションがサポートされます。
参照ドキュメント: 「リモート・ピアリング」、「DRGの管理」、「OCI FastConnect」

コンピュートおよびストレージに関する考慮事項

3つのリージョンすべてにわたるインフラストラクチャ計画には、いくつかの決定事項が含まれます。

リージョンの選択
- 5ミリ秒未満のRTTレイテンシを持つOCI専用リージョンを2つ選択してください。
- Witnessデプロイメント用のOCI Dedicated Regionの両方に対するレイテンシが200ミリ秒未満のパブリックOCIリージョンを選択します。
シェイプの選択
- VMware vSANには、Dense Bare Metalシェイプ(BM.DenseIO.E5.128など)をローカルのNVMeストレージとともに使用します。
- ブロック・ボリュームを使用する標準シェイプは、拡張されたvSANデプロイメントには適していないため、使用しないでください。
ホストの最小要件
- プライマリ・リージョン: 最小3つのDenseベア・メタル・ホスト
- セカンダリ・リージョン: 最小3つのDenseベア・メタル・ホスト
- 「Witness」リージョン: 1つのベア・メタル・ホスト
目撃者アプライアンスのガイドライン
- vSAN Witness Designのガイダンスに従います。
- 要件が変更される可能性があるため、最新の更新を入手するには、常にBroadcomの公式ドキュメントを参照してください。以下はいくつかの参照:
  - VCF 5.1.2での拡張クラスタの考慮事項
  - vSANストレッチ・クラスタの最小ホスト数

ストレッチされたクラスタの要件

プライマリ・リージョンとセカンダリ・リージョン間のRTTレイテンシが5ミリ秒未満
サイトとWitnessノード間のRTTレイテンシが200ミリ秒未満
すべてのホスト(Witnessを含む)が同じVMware vSANクラスタに属している必要があります
ホストのハードウェアおよび構成はリージョン間で同一である必要があります
目撃者は3分の1の別々の場所にいる必要があります

運用上の考慮事項

お客様は、2日目のオペレーションを手動で完了する必要があります。主なノート:

Oracle Cloud VMware Solution環境は、各OCI専用リージョンに個別にデプロイされます。セカンダリ・サイトのVMware vCenterおよびVMware NSX Managerは、手動でデタッチしてプライマリ・クラスタと統合する必要があります。
サイト障害の場合、手動フェイルオーバーおよびルート更新が必要です。
VMware NSX Tier-0 Gatewayは、1つのサイトでのみアクティブです。つまり、North-Southトラフィック・ルーティングのアクティブ- パッシブ・モデルを意味します。

設計の概要

この項では、Oracle Cloud VMware Solutionを使用した拡張vSAN構成のアーキテクチャおよび要件について説明した前の項に基づいて、OCI Dedicated Regionの障害に対応できる高可用性設計を実装する方法について説明します。

この設計では、サイトごとに2つのVCNsが使用されるため、合計で4つのVCNsになります:

OCI専用リージョンA

2つのCIDRブロックを持つVCN Primary。たとえば、プライマリとして10.16.0.0/16、セカンダリCIDRとして172.45.0.0/16 (VCNの作成後に追加)です。セカンダリCIDRは、最初のSDDCデプロイメントにのみ必要です。
Since an Oracle Cloud VMware Solution SDDC cannot span multiple VCNs, a secondary CIDR block (172.45.0.0/16) is attached to the Primary VCN within OCI Dedicated Region A.これにより、管理サブネットおよびサービス・サブネットのVLAN定義が可能になり、単一のVCN内で論理的にグループ化されます。
VCN MGMT Active。VCNプライマリにアタッチされたセカンダリCIDRと同じCIDRブロック(172.45.0.0/16)を使用します。

OCI専用リージョン B

VCN Secondary。VCN Primaryと重複しないCIDRブロック(10.17.0.0/16など)。
VCN MGMT Failover。VCN MGMT Activeと同じCIDRブロック(172.45.0.0/16)を使用します。

Oracle Cloud VMware Solutionは、ネットワーク・プロビジョニングの柔軟性を提供します。SDDCの作成時に、ユーザーは次のいずれかを実行できます:

CIDRブロックを指定し、Oracle Cloud VMware Solutionの自動化で必要なネットワーキング・コンポーネントを作成できるようにするか、または
事前にVCNs、サブネット、VLAN、ルート表およびNSGを手動で作成し、デプロイメント中にこれらの既存のリソースを選択します。

この拡張されたvSAN設計には、後者のアプローチが必要です。複数のVCNsおよびリージョンにわたるネットワーク・セグメンテーションを正確に制御するには、ルート表、NSGおよびVLANを事前に作成する必要があります。この分離により、VCNs間の明確な責任がサポートされ、シームレスなフェイルオーバー動作が可能になります。

重要な側面は、管理サブネット(172.45.0.0/16)が両方のOCI専用リージョンでアクセスできる必要があることです。フェイルオーバーをサポートするために、この設計により、ルート表の変更やDRGアタッチメントを介したサブネットの再通知など、フェイルオーバー・イベント中の手動ネットワーク更新を介して、このVCN MGMTネットワークが2つのサイト間で"フロート"できます。

DNSの解決は、フェイルオーバーとサービスの可用性に不可欠です。したがって、DNSおよびサポート・インフラストラクチャをホストするために、各VCNに専用サービス・サブネットが作成されます。

VLANタグ付けの簡略化:

100範囲のVLANタグはリージョン固有で、それぞれのサイトに限定されます。
200の範囲のVLANタグは、172.45.0.0/16サブネットに関連付けられ、サイト間でフロートされます。

上位レベルの設計を定義して、プライマリ・リージョンから各サイトの実際の構成に進みます。