次の方法で共有

vSAN ストレッチ クラスターを設計する

  • [アーティクル]

この記事では、Azure VMware Solution プライベート クラウド用に vSAN ストレッチ クラスターを設計する方法について説明します。

背景

Azure のグローバル インフラストラクチャはリージョンに分かれています。 各リージョンは、特定の地域のサービスをサポートしています。 各リージョン内では、可用性ゾーン (AZ) と呼ばれる、冗長性を持つ孤立したインフラストラクチャ領域が Azure によって構築されます。 AZ は、リソース管理の境界として機能します。 AZ で使用できるコンピューティングとその他のリソースは有限であり、顧客の要求によって使い果たされる可能性があります。 AZ は個別に回復性を持つように構築されています。つまり、1 つの AZ の障害は他の AZ には影響しません。

Azure VMware Solution では、標準の vSphere クラスターにデプロイされた ESXi ホストは、従来は単一の Azure 可用性ゾーン (AZ) に存在し、vSphere 高可用性 (HA) によって保護されます。 ただし、ワークロードは Azure AZ の障害から保護されません。 AZ 障害から保護するために、1 つの vSAN クラスターが vSAN ストレッチ クラスターと呼ばれる 2 つの個別の可用性ゾーンにまたがるようにできます。

ストレッチ クラスターを使用すると、2 つの AZ にまたがる vSAN 障害ドメインを構成して、ホストが各可用性ゾーン (AZ) に存在することを vCenter Server に通知できます。 わかりやすくするために、各障害ドメインには、そのドメインが存在する AZ の名前が付けられます。 1 つのリージョン内の 2 つの AZ に vSAN クラスターを拡張した場合、AZ がダウンすると vSphere HA イベントとして扱われ、もう一方の AZ で仮想マシンが再起動されます。

ストレッチ クラスターの利点:

  • アプリケーションの可用性を向上させます。
  • エンタープライズ アプリケーションの再設計や、高価なディザスター リカバリー (DR) ソリューションをデプロイすることなく、回復ポイントの目標 (RPO) 機能をゼロにできます。
  • ストレッチ クラスターを備えたプライベート クラウドは、AZ 障害に対する回復性があるため、99.99% の可用性を提供するように設計されています。
  • お客様がインフラストラクチャの可用性ではなく、主要なアプリケーション要件と機能に集中できるようにします。

スプリット ブレイン シナリオから保護し、サイトの正常性を測定するために、マネージド vSAN Witness が 3 番目の AZ に作成されます。 各 AZ のデータのコピーを使用して、vSphere HA は仮想マシンの再起動を使用して、障害からの復旧を試みます。

次の図は、2 つの AZ にまたがって拡張された vSAN クラスターを示しています。

図は、3 つ目の可用性ゾーンに作成されたマネージド vSAN ストレッチ クラスターを示しています。3 つの AZ すべてにデータがコピーされています。

次の図は、2 つの AZ にまたがる vSAN クラスター内のネットワーク トラフィックの通常のフローを示しています。

図は、マネージド vSAN ストレッチ クラスターの VMware NSX トラフィック フローを示しています。

要約すると、ストレッチ クラスターは、Azure インフラストラクチャのスケールと柔軟性に加えて、同じ信頼できる制御と機能を提供することで、保護のニーズを簡素化します。

ストレッチ クラスターのプライベート クラウドは、回復性の追加レイヤーを提供するだけで、すべての障害シナリオに対処するわけではないことを理解することが重要です。 たとえば、ストレッチ クラスターのプライベート クラウドは次のように機能します。

  • Azure 内のリージョン レベルの障害や、アプリケーションの問題や計画が不十分なストレージ ポリシーによって発生するデータ損失シナリオへの保護は行いません。
  • 単一のゾーンの障害に対する保護は提供しますが、二重の障害や進行する障害に対する保護を提供するようには設計されていません。 例:

    • ファブリックにさまざまな冗長性の層が組み込まれていても、AZ 間障害によってセカンダリ サイトのパーティション分割が発生した場合、vSphere HA はセカンダリ サイト上のワークロード VM の電源オフを開始します。

      次の図は、セカンダリ サイトのパーティション分割シナリオを示しています。

      図は、セカンダリ サイト上のワークロード仮想マシンの電源をオフにする vSphere の高可用性を示しています。

    • セカンダリ サイトのパーティション分割が代わりにプライマリ サイトの障害に発展した場合、または完全なパーティション分割が発生した場合、vSphere HA はセカンダリ サイト上のワークロード VM の再起動を試みます。 vSphere HA がセカンダリ サイト上のワークロード VM を再起動しようとすると、ワークロード VM は不安定な状態になります。

      次の図は、優先されるサイトの障害および完全なネットワーク パーティション分割シナリオを示しています。

      図は、優先サイトの障害が発生したときに、セカンダリ サイト上のワークロード仮想マシンを再起動しようとしている vSphere 高可用性を示しています。

      図は、完全なネットワーク分離が発生したときに、セカンダリ サイト上のワークロード仮想マシンを再起動しようとしている vSphere 高可用性を示しています。

      次の図は、完全なサイト障害時に拡張された vSAN クラスター内のネットワーク トラフィックのフローを示しています。

      図は、完全なサイト障害時のマネージド vSAN ストレッチ クラスターの VMware NSX トラフィック フローを示しています。

これらの種類の障害はまれですが、ストレッチ クラスターのプライベート クラウドによって提供される保護の範囲外になることに注意してください。 このようなまれな障害のため、ストレッチ クラスター ソリューションは vSphere HA に依存するマルチ AZ 高可用性ソリューションと見なす必要があります。 ストレッチ クラスター ソリューションは、アプリケーションの可用性を確保するために使用できる包括的なマルチリージョン ディザスター リカバリー戦略を置き換えることを意図していないことを理解しておくことが重要です。 その理由は、ディザスター リカバリー ソリューションには通常、個別の Azure リージョンに個別の管理プレーンとコントロール プレーンがあるためです。 Azure VMware Solution のストレッチ クラスターでは、同じ Azure リージョン内の 2 つの可用性ゾーンにまたがって 1 つの管理プレーンとコントロール プレーンが拡張されます。 たとえば、1 つの vCenter Server、1 つの NSX Manager クラスター、1 つの NSX Edge VM ペアなどです。

ストレッチ クラスター リージョンの可用性

Azure VMware Solution ストレッチ クラスターは、次のリージョンで使用できます。

  • 英国南部 (AV36 および AV36P 上)
  • 西ヨーロッパ (AV36 および AV36P 上)
  • ドイツ中西部 (AV36 と AV36P 上)
  • オーストラリア東部 (AV36P 上)
  • 米国東部 (AV36P 上)

サポートされているストレージ ポリシー

次の SPBM ポリシーがサポートされており、クラスターの既定のポリシーとして PFTT の "デュアル サイト ミラーリング" と "RAID 1 (ミラーリング)" の SFTT が有効になっています。

  • サイトのディザスター トレランス設定 (PFTT):
    • デュアル サイト ミラーリング
    • なし - 優先にデータを保持する
    • なし - 非優先にデータを保持する
  • ローカル許容エラー (SFTT):
    • 1 つの障害 – RAID 1 (ミラーリング)
    • 1 つの障害 – RAID 5 (イレイジャー コーディング)、各 AZ で少なくとも 4 つのホストが必要
    • 2 つの障害 – RAID 1 (ミラーリング)
    • 2 つの障害 – RAID 6 (イレイジャー コーディング)、各 AZ で少なくとも 6 つのホストが必要
    • 3 つの障害 – RAID 1 (ミラーリング)

よく寄せられる質問

他のリージョンは計画されていますか?

現在、ストレッチ クラスターは、5 つのリージョンでサポートされています。

ストレッチ クラスターではどのような種類の SLA が Azure VMware Solution によって提供されますか?

vSAN ストレッチ クラスターを使用して作成されたプライベート クラウドは、次の条件が存在する場合に 99.99% のインフラストラクチャ可用性コミットメントを提供するように設計されています。

  • 少なくとも 6 つのノードがクラスターにデプロイされている場合 (各可用性ゾーンに 3 つ)。
  • "デュアル サイト ミラーリング" の PFTT の VM ストレージ ポリシーと 1 の SFTT がワークロード VM で使用されている場合。
  • 可用性の目標を達成するために、Azure VMware Solution の SLA の詳細でキャプチャされた追加要件への準拠が必要な場合。

プライベート クラウドがデプロイされている可用性ゾーンを選択できますか?

不正解です。 ストレッチ クラスターは 2 つの可用性ゾーンの間に作成され、3 つ目のゾーンはミラーリング監視ノードのデプロイに使用されます。 すべてのゾーンはストレッチ クラスター環境のデプロイに実質的に使用されるため、お客様に選択肢は提供されません。 代わりに、お客様はプライベート クラウドの作成時に複数の AZ にホストをデプロイすることを選択します。

注意すべき制限事項は何ですか?

  • ストレッチ クラスターを使用してプライベート クラウドを作成した後は、標準クラスターのプライベート クラウドに変更することはできません。 同様に、作成後に標準のクラスターのプライベート クラウドをストレッチ クラスターのプライベート クラウドに変更することはできません。
  • ストレッチ クラスターのスケールアウトとスケールインは、ペアでのみ行うことができます。 ストレッチ クラスター環境では、最小で 6 個、最大で 16 個のノードがサポートされます。 詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。
  • お客様のワークロード VM は、優先度中の vSphere HA で再起動されます。 管理 VM の再起動優先度は最も高くなります。
  • このソリューションの再起動とレプリケーションは vSphere HA と vSAN に依存します。 目標復旧時間 (RTO) は、1 つの AZ で障害が発生した後、残っている AZ 上の VM を再起動するのに vSphere HA でかかる時間によって決まります。
  • 現在、次のような機能は、ストレッチ クラスター環境ではサポートされていません。
    • パブリック IP から NSX Edge のような最近リリースされた機能、および ANF データストアなどの外部ストレージ。
    • VMware SRM、Zerto、JetStream などのディザスター リカバリー アドオン。
  • 次のシナリオで Azure portal からサポート チケットを開きます ([問題の種類] として [ストレッチ クラスター] を選択してください)。
    • プライベート クラウドをストレッチ クラスターのプライベート クラウドに接続する。
    • 1 つのリージョン内の 2 つのストレッチ クラスターのプライベート クラウドを接続する。

可用性ゾーン (AZ) 間で予想される待機時間はどの程度ですか?

vSAN ストレッチ クラスターは、ワークロード VM をホストする AZ 間で、5 ミリ秒のラウンド トリップ時間 (RTT) と、10 Gb/秒以上の帯域幅で動作します。 Azure VMware Solution ストレッチ クラスターのデプロイは、その基本原則に従います。 待機時間の要件が厳しいアプリケーション (同期書き込みを使用するデュアル サイト ミラーリングの SFTT を使用) を展開する場合は、その情報を考慮してください。

プライベート クラウドでストレッチ クラスターと標準クラスターを混在させることができますか?

不正解です。 ストレッチ クラスターと標準クラスターの組み合わせは、同じプライベート クラウド内ではサポートされていません。 プライベート クラウドを作成するときに、ストレッチ クラスター環境または標準クラスター環境が選択されます。 ストレッチ クラスターを使用してプライベート クラウドが作成されると、そのプライベート クラウド内で作成されたすべてのクラスターは本質的にストレッチであると想定されます。

ソリューションのコストはどれくらいですか?

お客様は、プライベート クラウド内にデプロイされたノードの数に基づいて課金されます。

ミラーリング監視ノードと AZ 間トラフィックに対して課金されますか?

いいえ。 ミラーリング監視ノードと AZ 間トラフィックに対しては課金されません。 ミラーリング監視ノードは完全にサービス管理で、Azure VMware Solution はミラーリング監視ノードの必要なライフサイクル管理を提供します。 ソリューション全体がサービス管理であるため、お客様に必要なのはワークロード仮想マシンに対して設定する適切な SPBM ポリシーを識別することだけです。 それ以外は Microsoft によって管理されます。