Share via


Azure Operator Nexus の信頼性

重要

現在、この機能はプレビュー段階にあります。 プレビュー版は、追加使用条件に同意することを条件に使用できます。

この記事では、可用性ゾーンによるリージョン内の回復性を含む、Azure Operator Nexus での信頼性のサポートについて説明します。 Azure における信頼性の詳細については、Azure の信頼性に関するページを参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャの比較の詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

Azure Operator Nexus は、既定で可用性ゾーン冗長デプロイを提供します。 クラスター マネージャーやネットワーク ファブリック コントローラーなどのオペレーター Nexus コンポーネントはすべて、可用性ゾーンで有効になっている Azure Kubernetes Service (AKS) クラスターにデプロイされます。 ストレージ アカウント サービス、KeyVault など、他のサービス依存関係も、可用性ゾーン冗長で構成されます。

注意

Operator Nexus オンプレミス インスタンスは、スタックのすべてのレベルで物理的な冗長性を提供するマルチラック設計を実装します。 各ラックは、障害ドメインまたはネクサス ゾーンとして設計されています。 顧客のワークロードは複数のラック/ノードにデプロイでき、基本的に同様のマルチ可用性ゾーン エクスペリエンスが提供されます。

Azure 可用性ゾーン ダウン エクスペリエンス

可用性ゾーンダウン シナリオでは、クラスターとリソース プロバイダーに対する API 呼び出しは中断することなく引き続き機能します。 現在実行中のオンプレミス テナント ワークロードや、新しいテナント ワークロードを作成する機能には影響しません。 また、Operator Nexus やその他のリソースの種類の回復性が確保されるため、データ損失は発生しません。

Azure 可用性ゾーン フェールオーバーのサポート

可用性ゾーンに障害が発生した場合、別の Azure 可用性ゾーンへの再接続は自動的に行われ、ユーザーによる操作は必要ありません。

Operator Nexus インスタンスのデプロイにおける可用性

Azure Operator Nexus ワークロードのデプロイにおける可用性の確保は、分割責任です。 前のセクションで説明したように、Operator Nexus AKS ベースのリソースは、可用性ゾーン冗長を使用してデプロイされます。 このセクションでは、オンプレミスのワークロードの可用性に関するベスト プラクティスについて検討します。

一般に、可用性ターゲットは、ローカルおよび geo 冗長デプロイによって実現されます。

ネクサス ゾーン: ローカル ワークロード冗長性のメカニズム

Operator Nexus オンプレミス インスタンスは、スタックのすべてのレベルで物理的な冗長性を提供するマルチラック設計で構成されます。 各ラックは障害ドメインとして指定されるため、これらのゾーンを Nexus ゾーンとして構成でき、ローカル冗長ワークロードのデプロイに使用することをお勧めします。

Nexus インスタンス: geo ワークロード冗長性のメカニズム

Nexus オンプレミス インスタンスは、特定の Azure リージョンでホストされます。 前述のように、使用されている Azure サービスと Nexus リソースは、その Azure リージョンの複数の可用性ゾーンにデプロイされます。

geo 冗長用にワークロードを冗長にデプロイするには、地理的に分散 (同じオペレーター データ センターに存在しない、あるいは同じ地理的リージョンにない可能性もあります) されていて、異なる Azure リージョンでホストされている Nexus インスタンスを使用する必要があります。

警告

たとえば、地理的に分散された 2 つの Nexus インスタンスにワークロードをデプロイしても、geo 冗長 Nexus インスタンスが異なる Azure リージョンでホストされていない限り、真の geo 冗長性を実現するには不十分です。

万一、Azure リージョンが利用不可になった場合、Azure サービスと、そのリージョンの Nexus リソースも使用できなくなります。 これは実行中のワークロードには影響しませんが、新しいワークロードの開始、分析などの機能が妨げられます。

同じ地理的な場所にある複数の Nexus インスタンス

複数の Nexus インスタンスを同じ地理的な場所にデプロイする必要があるシナリオがあります。 同じ地理的な場所の Nexus インスタンスにワークロードをデプロイしても、ワークロードの geo 冗長性が実現されないのは明らかです。

可用性以外の、信頼性を設計する際の考慮事項の 1 つは、回復性と障害から回復する機能です。 障害から復旧し、目標復旧時間を達成するには、障害の "影響範囲" (影響半径) を制限する必要があります。 複数の Nexus インスタンスが同じ地理的な場所にデプロイされるシナリオにおいて、回復性がある設計には、これらの Nexus インスタンスを異なる Azure リージョンでホストすることが求められます。 これにより、Azure リージョンで障害が発生した場合、その影響は 1 つの Nexus インスタンスに制限されます。

次のステップ