FlexPod SM-BC 解決策 には、各サイトに FlexPod インフラストラクチャ、サイト間のネットワーク接続、および 3 番目のサイトに導入された ONTAP メディエーターが含まれており、必要な RPO と RTO の目標を達成します。次の図に、各サイトの Cisco UCS B200M5 サーバと、サイト内およびサイト間の SM-BC 機能を備えたネットアップストレージとのエンドツーエンドのネットワーク接続を示します。

FlexPod の導入アーキテクチャは、この解決策 検証で各サイトで同じです。ただし、解決策 は非対称型の導入をサポートしており、要件を満たす既存の FlexPod ソリューションに追加することもできます。

拡張レイヤ 2 アーキテクチャは、各データセンターにおけるポートチャネルの Cisco UCS コンピューティングとネットアップストレージの間の接続、およびデータセンター間の接続を提供する、シームレスなマルチサイトデータファブリックに使用されます。ポートチャネルの構成、および必要に応じて仮想ポートチャネルの構成は、コンピューティングレイヤ、ネットワークレイヤ、ストレージレイヤ間の帯域幅集約とフォールトトレランス、およびクロスサイトリンクに使用されます。その結果、 UCS ブレードサーバは、ローカルとリモートの両方のネットアップストレージに接続され、マルチパスアクセスを提供します。

クラスタ内の各ホストは、場所に関係なく同一の仮想ネットワークを使用して導入されます。この設計では、 VMware 仮想スイッチ（ vSwitch ）と VMware 仮想分散スイッチ（ vDS ）を使用して、さまざまなトラフィックタイプを分離しています。VMware vSwitch は主に FlexPod インフラネットワーク用、 vDS はアプリケーションネットワーク用ですが、必須ではありません。

仮想スイッチ（ vSwitch 、 vDS ）は、仮想スイッチごとに 2 つのアップリンクで展開されます。 ESXi ハイパーバイザーレベルのアップリンクは、 Cisco UCS ソフトウェアでは vmnic および仮想 NIC （ vNIC ）と呼ばれます。vNIC は、 Cisco UCS サービスプロファイルを使用して、各サーバの Cisco UCS VIC アダプタ上に作成されます。次の図に示すように、 6 つの vNIC が定義され、 vSwitch0 に 2 つ、 vDS0 に 2 つ、 vSwitch1 に 2 つ、 iSCSI アップリンクに 2 つです。

vSwitch0 は VMware ESXi ホストの設定中に定義され、管理用に FlexPod インフラ管理 VLAN と ESXi ホスト VMkernel （ VMK ）ポートが含まれています。インフラ管理仮想マシンポートグループも、必要な重要なインフラ管理仮想マシン用の vSwitch0 に配置されます。

このような管理インフラストラクチャ仮想マシンは、 vDS ではなく vSwitch0 に配置することが重要です。これは、 FlexPod インフラストラクチャがシャットダウンまたは電源の再投入された場合に、その管理仮想マシンが最初に実行されていたホスト以外のホストで、仮想マシンをアクティブ化しようとするためです。 vSwitch0 のネットワークで正常にブートします。このプロセスは、 VMware vCenter が管理仮想マシンである場合は特に重要です。vCenter が vDS 上にあり、別のホストに移動してブートした場合、起動後にネットワークに接続されません。

この設計では、 2 つの iSCSI ブート vSwitch を使用します。Cisco UCS iSCSI ブートには、 iSCSI ブート用に個別の vNIC が必要です。これらの vNIC は、適切なファブリックの iSCSI VLAN をネイティブ VLAN として使用し、適切な iSCSI ブート vSwitch に接続されます。また、新しい vDS を導入するか、既存の vDS を使用して、 vDS に iSCSI ネットワークを導入することもできます。

両方の SM-BC サイトで任意の ESXi ホスト上で仮想マシンを実行できるようにするには、すべての ESXi ホストが両方のサイトから iSCSI データストアをマウントする必要があります。両方のサイトのデータストアがすべての ESXi ホストで適切にマウントされている場合は、 vMotion を使用するすべてのホスト間で仮想マシンを移行しても、それらのデータストアから作成されたすべての仮想ディスクへのアクセスは維持されます。

ローカルデータストアを使用する仮想マシンの場合、仮想ディスクがリモートサイトのホストに移行されると、仮想ディスクへのアクセスがリモートになり、サイト間の物理的な距離による読み取り処理のレイテンシが増加します。そのため、ローカルホストに仮想マシンを保持し、サイトでローカルストレージを利用することを推奨します。

VM とホストのアフィニティメカニズムを使用すると、 VM / ホストグループを作成して、特定のサイトに配置された仮想マシンとホストの VM グループとホストグループを作成できます。VM/ ホストルールを使用して、 VM とホストが従うポリシーを指定できます。サイトのメンテナンスまたは災害時にサイト間で仮想マシンを移行できるようにするには、その柔軟性のため、「グループ内のホストで実行する」ポリシー仕様を使用します。

次のスクリーンショットは、サイト A とサイト B のホストおよび VM について、 2 つのホストグループと 2 つの VM グループが作成されたことを示しています

さらに、次の 2 つの図は、「グループ内のホストで実行する必要があります」ポリシーを使用して、サイト A およびサイト B の VM がそれぞれのサイトのホストで実行されるように作成された VM/ ホストルールを示しています。

VMware vSphere HA は、ホストの状態を検証するためのハートビートメカニズムを備えています。一次ハートビートメカニズムはネットワーク経由で行われ、二次ハートビートメカニズムはデータストアを経由します。ハートビートを受信しない場合は、デフォルトゲートウェイに ping を送信するか、手動で設定した隔離アドレスに基づいて、ハートビートをネットワークから隔離するかを決定します。データストアのハートビートでは、ストレッチクラスタのハートビートデータストアを最小構成から 4 つに増やすことを推奨します。

解決策 の検証では、 2 つの ONTAP クラスタ管理 IP アドレスを隔離アドレスとして使用します。また、次の図に示すように、推奨される vSphere HA の詳細オプション「 DS.heartbeatDsPerHost 」の値が 4 に追加されました。

ハートビートデータストアの場合、クラスタから 4 つの共有データストアを指定し、次の図に示すようにそれを補完します。

VMware HA Cluster および VMware vSphere Metro ストレージクラスタのその他のベストプラクティスおよび設定については、を参照してください "vSphere HA クラスタを作成および使用する"、 "VMware vSphere Metro Storage Cluster （ vMSC ）" およびの VMware KB です "NetApp ONTAP と NetApp SnapMirror のビジネス継続性（ SM-BC ）および VMware vSphere Metro Storage Cluster （ vMSC ）"。

"次：解決策 の検証済みのシナリオ"