Availability Zones について調べる

  • 7 分

前に説明したデプロイ シナリオは、可用性セットに大きく依存しています。 場合によっては、これらのシナリオを Azure Availability Zones の使用に適合させることができます。 ただし、そのためには他にもいくつかのことを検討し、アーキテクチャを変更することが必要です。

Azure の可用性ゾーンは、リージョン内の一意の物理的な場所と定義できます。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 一般的な SAP NetWeaver または S/4HANA アーキテクチャにおいては、次の 3 つの異なるレイヤーを保護する必要があります。

  • SAP アプリケーション レイヤー。1 台から数十台の VM を使用できます。 複数の VM が同じホスト サーバー上にデプロイされる可能性を最小限に抑える必要があります。 また、それらの VM を DBMS レイヤーに十分近い場所に配置し、ネットワーク待機時間を許容可能な範囲に維持することもできます。
  • SAP ASCS/SCS レイヤー。SAP NetWeaver および S/4HANA アーキテクチャ内の単一障害点を表します。 通常は、フェールオーバー フレームワークによってカバーされる 2 台の VM があります。 したがって、これらの VM を、異なるインフラストラクチャの障害ドメインと更新ドメインに割り当てる必要があります。
  • SAP DBMS レイヤー。これも単一障害点を表します。 通常のケースでは、フェールオーバー フレームワークの対象となる 2 つの VM で構成されます。 したがって、これらの VM を、異なるインフラストラクチャの障害ドメインと更新ドメインに割り当てる必要があります。 例外は SAP HANA のスケールアウト デプロイの場合で、2 つより多くの VM を使用できます。

組織にはそれぞれ固有の要件があるので、複雑なビジネス ニーズを最適に満たすようにアプリケーションを設計する必要があります。 ターゲット SLA を定義することで、アーキテクチャがビジネス要件を満たしているかどうかを評価できるようになります。 次のような点を検討します。

  • 可用性要件は何か。
  • どの程度のダウンタイムを許容できるのでしょうか。
  • 起こり得るダウンタイムによって貴社のビジネスが被るコストはいくらになるでしょうか。
  • アプリケーションの可用性を高めることにいくら投資すべきでしょうか。
  • データ バックアップ要件は何か。
  • データ レプリケーション要件は何か。
  • 監視要件は何か。
  • アプリケーションに特定の待機時間要件はあるか。

Availability Zones の使用を判断する際の考慮事項:

  • 1 つの Azure リージョン内の異なる Availability Zones 間の距離に関する保証はありません。

  • Availability Zones は、理想的な DR ソリューションではありません。 自然災害により、電力設備に対する大きな損害を含め、世界のリージョンで広範囲にわたる損害が発生する場合があります。 異なるゾーン間の距離が、適切な DR ソリューションを構成するのに十分な長さではない場合があります。

  • Availability Zones 間のネットワーク待ち時間は、すべての Azure リージョンで同じではありません。 いくつかの場合では、1 つのゾーンからアクティブ DBMS VM へのネットワーク待機時間が許容されるため、異なるゾーン間で SAP アプリケーション層をデプロイし実行できます。 しかし、一部の Azure リージョンでは、異なるゾーンにデプロイされたアクティブ DBMS VM と SAP アプリケーション インスタンスとの間の待ち時間が、SAP ビジネス プロセスにとって許容できないものである場合があります。 そのような場合は、アプリケーションのアクティブ/アクティブ アーキテクチャまたはアクティブ/パッシブ アーキテクチャ (ゾーンをまたがるネットワーク待ち時間が長すぎる場合) で、デプロイ アーキテクチャを異なるものにする必要があります。

  • Availability Zones を使用する場所を決定する際はゾーン間のネットワークの待ち時間に基づいて決定してください。 ネットワーク待ち時間は、次の 2 つの点で重要な役割を果たします。

    • 同期レプリケーションが必要な 2 つの DBMS インスタンス間の待ち時間。 ネットワークの待機時間が長いほど、ワークロードのスケーラビリティに影響を及ぼす可能性が高くなります。
    • アクティブな DBMS インスタンスを含むゾーンで SAP ダイアログ インスタンスを実行している VM と、別のゾーンの同様の VM との間のネットワーク待ち時間の違い。 この違いが大きいほど、DBMS を含むゾーン、または別のゾーンのどちらで実行しているかに応じて、ビジネス プロセスとバッチ ジョブの実行時間への影響も大きくなります。

Azure VM を複数の Availability Zones にデプロイして、同じ Azure リージョン内でフェールオーバー ソリューションを確立する場合、いくつかの制限が適用されます。

  • Azure Availability Zones にデプロイするときは、Azure Managed Disks を使用する必要があります。
  • 物理ゾーンに対するゾーン列挙のマッピングは、Azure サブスクリプションごとに固定されています。 さまざまなサブスクリプションを使用して SAP システムをデプロイする場合は、サブスクリプションごとに最適なゾーンを定義する必要があります。
  • 1 つの Azure Availability Zone 内に Azure 可用性セットをデプロイすることはできません。 仮想マシンのデプロイ フレームワークとしてどちらかを選択してください。
  • Azure Basic ロード バランサーを使って、Windows Server フェールオーバー クラスタリングまたは Linux Pacemaker に基づくフェールオーバー クラスター ソリューションを作成することはできません。 代わりに、Azure Standard ロード バランサー SKU を使用する必要があります。