Azure Availability Zones での SAP ワークロードの構成

  • [アーティクル]

Azure 可用性セットでのさまざまな SAP アーキテクチャ レイヤーのデプロイに加えて、Azure Availability Zones を SAP ワークロードのデプロイに使用することもできます。 Azure 可用性ゾーンは次のように定義されます。"リージョン内の一意の物理的な場所。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。" Azure Availability Zones は、すべてのリージョンで使用できるわけではありません。 Availability Zones が提供される Azure リージョンについては、Azure リージョン マップを確認してください。 このマップでは、Availability Zones が提供されているか、または提供予定と発表されているリージョンが示されます。

一般的な 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 を、異なるインフラストラクチャの障害ドメインに割り当てる必要があります。 例外は、3 台以上の VM を使用できる SAP HANA のスケールアウト デプロイです。

重要な VM を可用性セットを使用してデプロイする場合と、Availability Zones を使用してデプロイする場合の主な違いは次のとおりです。

  • 可用性セットを使用したデプロイでは、セット内の VM が単一のゾーンまたはデータセンター (特定のリージョンに対してどちらでも適用できます) 内に配置されます。 その結果、可用性セットを使用したデプロイは、そのゾーンのデータセンター全体に影響する電源、冷却手段、またはネットワークの問題からは保護されません。 プラス面としては、VM が、そのゾーンまたはデータセンター内の更新ドメインと障害ドメインに応じて配置されます。 特に、1 つの可用性セットにつき 2 台の VM を保護する SAP ASCS または DBMS レイヤーでは、障害ドメインに応じた配置により、両方の VM が同じホスト ハードウェア上にデプロイされるのを防ぐことができます。
  • Azure Availability Zones を使用して VM をデプロイし、異なるゾーン (最大 3 つまで可能) を選択すると、それらの VM が異なる物理的な場所にデプロイされ、そのゾーンのデータセンター全体に影響する電源、冷却手段、またはネットワークの問題の保護が強化されます。。 ただし、同じ VM ファミリの複数の VM を同じ可用性ゾーンにデプロイする場合は、それらの VM が同じホスト上や同じ障害ドメインにデプロイされるのを防ぐことはできません。 そのため、Availability Zones を使用したデプロイは、通常はそれぞれ 2台の VM が存在する SAP ASCS および DBMS レイヤーに最適です。 VM 数が 2 台を大幅に超える可能性がある SAP アプリケーション レイヤーでは、別のデプロイ モデルへのフォールバックが必要になる場合があります (後述)。

複数の Azure 可用性ゾーンにわたるデプロイは、1 台の重要な VM の障害への対応、または重要な VM におけるソフトウェア修正プログラムのためのダウンタイムの削減に加えて、1 つまたは複数の Azure データセンターの可用性に影響する可能性がある大規模なインフラストラクチャの問題からの保護を目的として行う必要があります。

もう 1 つの回復性デプロイ機能として、Azure では フレキシブル オーケストレーションを備えた Virtual Machine Scale Sets が導入されました。 仮想マシン スケール セットは、プラットフォームによって管理される仮想マシンの論理グループを提供します。 仮想マシン スケール セットのフレキシブル オーケストレーションでは、スケール セットをリージョン内で作成するか、可用性ゾーンをまたいで作成するオプションを提供します。 platformFaultDomainCount>1 (FD>1) を使用するリージョン内でフレキシブルなスケール セットを作成すると、スケール セットにデプロイされた VM は、同じリージョン内の指定された数の障害ドメインに分散されます。 一方、platformFaultDomainCount=1 (FD=1) を使用して可用性ゾーン間でフレキシブルなスケール セットを作成すると、さまざまなゾーンに仮想マシンが分散され、スケール セットによって、ベスト エフォートベースで各ゾーン内のさまざまな障害ドメインに VM が分散されます。 SAP ワークロードでは、FD=1 のフレキシブルなスケール セットのみがサポートされます。 従来の可用性ゾーンのデプロイではなく、FD=1 でフレキシブルなスケール セットを使用する利点は、スケール セットでデプロイされた VM がベスト エフォート方式でゾーン内のさまざまな障害ドメインに分散されることです。 詳細については、SAP ワークロード用のフレキシブルなスケール セットのデプロイ ガイドを参照してください。

Availability Zones 間でのデプロイに関する考慮事項

Availability Zones を使用する場合、次の点に考慮してください。

  • Azure Availability Zones 間の最大ネットワーク ラウンドトリップの待機時間は、「リージョンと可用性ゾーン」のドキュメントに記載されています。
  • 経験豊富なネットワーク ラウンドトリップの待機時間は、異なるゾーンを形成するデータセンターの実際の地理的距離を必ずしも示すものではありません。 ネットワーク ラウンドトリップの待機時間は、ケーブルの接続性と、これらの異なるデータセンター間のケーブルのルーティングの影響も受けます。
  • Availability Zones は、理想的な DR ソリューションではありません。 自然災害により、電力設備に対する大きな損害を含め、世界のリージョンで広範囲にわたる損害が発生する場合があります。 異なるゾーン間の距離が、適切な DR ソリューションを構成するのに十分な長さではない場合があります。
  • Availability Zones 間のネットワーク待ち時間は、すべての Azure リージョンで同じではありません。 あるゾーンからアクティブ 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 システムをデプロイする場合は、サブスクリプションごとに最適なゾーンを定義する必要があります。 異なるサブスクリプションの論理マッピングを比較したい場合は、Avzone-Mapping スクリプトを検討してください
  • Azure 近接通信配置グループを使用しない場合、1 つの Azure Availability Zone 内に Azure 可用性セットをデプロイすることはできません。 SAP DBMS レイヤーとセントラル サービスを複数のゾーンにわたってデプロイすると同時に、可用性セットを使用して SAP アプリケーション レイヤーをデプロイし、さらに VM の近接通信も実現する方法については、「SAP アプリケーションで最適なネットワーク待ち時間を実現する Azure 近接通信配置グループ」の記事で説明しています。 Azure 近接配置グループを使用していない場合は、仮想マシン用のデプロイ フレームワークとして、いずれかを選択する必要があります。
  • Azure Basic Load Balancer を使用して Windows Server フェールオーバー クラスタリングまたは Linux Pacemaker に基づくフェールオーバー クラスター ソリューションを作成することはできません。 代わりに、Azure Standard Load Balancer SKU を使用する必要があります。

Availability Zones の最適な組み合わせ

複数のゾーンにわたって SAP NetWeaver または S/4HANA システムをデプロイする場合は、デプロイできるアーキテクチャ パターンとして次の 2 つがあります。

  • アクティブ/アクティブ:ASCS/SCS を実行する VM のペアと DBMS レイヤーを実行する VM のペアが、2 つのゾーンに分散されます。 SAP アプリケーション レイヤーを実行する VM の数は、同じ 2 つのゾーンに偶数台ずつデプロイされます。 1 台の DBMS または ASCS/SCS VM がフェールオーバーすると、開いているアクティブなトランザクションの一部がロールバックされる可能性があります。 しかし、ユーザーはログインした状態のままとなります。 アクティブな DBMS VM とアプリケーション インスタンスがどちらのゾーンで実行されているかは、あまり重要ではありません。 このアーキテクチャは、複数のゾーンにわたるデプロイに対して推奨されるアーキテクチャです。
  • アクティブ/パッシブ:ASCS/SCS を実行する VM のペアと DBMS レイヤーを実行する VM のペアが、2 つのゾーンに分散されます。 SAP アプリケーション レイヤーを実行する VM の数が、いずれか一方の可用性ゾーンにデプロイされます。 アプリケーション レイヤーは、アクティブな ASCS/SCS および DBMS インスタンスと同じゾーン内で実行されます。 このデプロイ アーキテクチャは、異なるゾーン間のネットワーク待ち時間が、アプリケーション レイヤーを複数のゾーンに分散するには長すぎる場合に使用します。 代わりに、SAP アプリケーション レイヤーをアクティブな ASCS/SCS および/または DBMS インスタンスと同じゾーン内で実行する必要があります。 1 台の ASCS/SCS または DBMS VM がセカンダリ ゾーンにフェールオーバーすると、ネットワーク待ち時間が長くなり、スループットが低下する可能性があります。 前にフェールオーバーした VM をできるだけ早くフェールバックして、前のスループット レベルに戻す必要があります。 ゾーン障害が発生した場合は、アプリケーション レイヤーをセカンダリ ゾーンにフェールオーバーする必要があります。 これは、ユーザーが完全なシステム シャットダウンとして経験するアクティビティです。 一部の Azure リージョンでは、このアーキテクチャが、Availability Zones を使用する場合の唯一の実行可能なアーキテクチャとなります。 ASCS/SCS または DBMS VM がセカンダリ ゾーンにフェールオーバーすることによって考えられる影響を受け入れられない場合は、可用性セットを使用したデプロイを引き続き使用する方がよいでしょう。

そのため、Availability Zones の使用方法を決定する前に、次の事項を判断する必要があります。

  • Azure リージョンの 3 つのゾーン間のネットワーク待ち時間。 リージョンのゾーン間のネットワーク待ち時間を把握することにより、ゾーンをまたいだネットワーク トラフィックでネットワーク待ち時間が最も短いゾーンを選択できます。
  • 選択した 1 つのゾーン内の VM 間の待ち時間と、選択した 2 つのゾーン間のネットワーク待ち時間の差。
  • デプロイする必要がある VM の種類が、選択した 2 つのゾーンで使用可能かどうかの判断。 一部の VM SKU では、一部の SKU が 3 つのゾーンのうち 2 つのゾーンでしか使用できない状況が発生する場合があります。

ゾーン間とゾーン内のネットワーク待ち時間

異なるゾーン間の待ち時間を判断するには、以下のことを行う必要があります。

  • DBMS インスタンスに使用する VM SKU を 3 つのゾーンすべてにデプロイします。 この測定を実行するときは、Azure Accelerated Networking が有効になっていることを確認します。 高速ネットワークは、数年前から既定の設定になっています。 それでも、有効になっているか、動作しているかを確認してください
  • ネットワーク待ち時間が最も短い 2 つのゾーンがわかったら、アプリケーション レイヤー VM として使用する VM SKU の別の 3 つの VM を 3 つの Availability Zones にデプロイします。 選択した 2 つの DBMS ゾーン内の 2 つの DBMS VM に対して、ネットワーク待ち時間を測定します。
  • 測定ツールとして niping を使用します。 SAP 提供のこのツールの説明は、SAP サポート ノート #500235 と #1100926 をご覧ください。 待ち時間測定用に記載されているコマンドに注目してください。 ping は Azure Accelerated Networking コード パスでは機能しないので、ping の使用は推奨されません。

これらのテストを手動で実行する必要はありません。 説明されている待機時間のテストを自動化する、PowerShell プロシージャの可用性ゾーンの待機時間テストを使用できます。

測定値と Availability Zones での VM SKU の可用性に基づいて、いくつかの決定を行う必要があります。

  • DBMS レイヤーの理想的なゾーンを定義する。
  • ゾーン内とゾーンをまたいだ場合のネットワーク待ち時間の違いに基づいて、アクティブ SAP アプリケーション レイヤーを 1 つのゾーン、2 つのゾーン、または 3 つ全部のゾーンのいずれに分散するかを決定する。
  • アプリケーションの観点から、アクティブ/パッシブまたはアクティブ/アクティブのどちらの構成をデプロイするかを決定する。 (これらの構成については、この記事で後述します)。

これらの決定を行うときは、SAP ノート #1100926 に記載されている SAP のネットワーク待ち時間に関する推奨事項も考慮してください。

重要

行った測定と決定は、測定に使用した Azure サブスクリプションに対して有効です。 別の Azure サブスクリプションを使用する場合、列挙されたゾーンのマッピングが別の Azure サブスクリプションで異なる場合があります。 その結果、測定を繰り返すか、Avzone-Mapping script ツールを使用して、古いサブスクリプションに対する新しいサブスクリプションのマッピングを見つける必要があります。

重要

前述の測定は、Availability Zones をサポートするすべての Azure リージョンで異なる結果になることが予想されます。 ネットワーク待ち時間の要件が同じでも、ゾーン間でネットワーク待ち時間が異なる可能性があるため、異なる Azure リージョンでは異なるデプロイ戦略の採用が必要になる場合があります。 一部の Azure リージョンでは、3 つの異なるゾーン間のネットワーク待ち時間が大きく異なる可能性があります。 他のリージョンでは、3 つの異なるゾーン間のネットワーク待ち時間がより均一になる可能性があります。 常に 1 ～ 2 ミリ秒のネットワーク待ち時間があるという主張は正しくありません。 Azure リージョン内の Availability Zones 間のネットワーク待ち時間を一般化することはできません。

アクティブ/アクティブのデプロイ

このデプロイ アーキテクチャがアクティブ/アクティブと呼ばれるのは、2 つまたは 3 つのゾーンにアクティブな SAP アプリケーション サーバーをデプロイするためです。 エンキュー レプリケーションを使用する SAP セントラル サービス インスタンスは、2 つのゾーン間にデプロイされます。 DBMS レイヤーについても同じで、SAP セントラル サービスと同じゾーンにデプロイされます。 この構成を検討する際は、リージョン内で、ワークロードと同期 DBMS レプリケーションについて許容されるゾーン間のネットワーク待ち時間を提供する 2 つの Availability Zones を見つける必要があります。 また、選択したゾーン内のネットワーク待ち時間とゾーン間のネットワーク待ち時間の差が、大きすぎないようにする必要があります。

SAP アーキテクチャの性質として、異なる方法で構成しない限り、ユーザーとバッチ ジョブを別々のアプリケーション インスタンスで実行できるという点があります。 これがアクティブ/アクティブ デプロイに及ぼす副作用は、バッチ ジョブが、アクティブな DBMS と同じゾーン内で実行されるかどうかに関係なく、任意の SAP アプリケーション インスタンスによって実行される可能性があるということです。 異なるゾーン間と 1 つのゾーン内とでネットワーク待ち時間にあまり差がない場合は、バッチ ジョブの実行時間の差は重要ではないかもしれません。 しかし、ゾーン間とゾーン内のネットワーク トラフィックのネットワーク待ち時間の差が大きいほど、DBMS インスタンスがアクティブではないゾーン内でジョブが実行された場合のバッチ ジョブの実行時間への影響が大きくなる可能性があります。 実行時間の違いをどの程度許容できるかは、お客様ご自身で判断してください。 お客様のワークロードにとって、クロスゾーン トラフィックで許容できるネットワーク待ち時間はどの程度かについても同様です。

異なる可用性ゾーンにわたってデプロイされたアプリケーション レイヤー内で、実行時間とスループットに著しく大きな差が生じることなくアクティブ/アクティブ デプロイが可能な Azure リージョンには、たとえば次のものがあります。

  • オーストラリア東部 (3 つのゾーンのうち 2 つ)
  • ブラジル南部 (3 つのゾーンすべて)
  • インド中部 (3 つのゾーンすべて)
  • 米国中部 (3 つのゾーンすべて)
  • 東アジア (3 つのゾーンすべて)
  • 米国東部 (3 つのゾーンのうち 2 つ)
  • 米国東部 2 (3 つのゾーンすべて)
  • ドイツ中西部 (3 つのゾーンすべて)
  • イスラエル中部 (3 つのゾーンすべて)
  • イタリア北部 (3 つのゾーンのうちの 2 つ)
  • 韓国中部 (3 つのゾーンすべて)
  • ポーランド中部 (3 つのゾーンすべて)
  • カタール中部 (3 つのゾーンすべて)
  • 北ヨーロッパ (3 つのゾーンすべて)
  • ノルウェー東部 (3 つのゾーンのうちの 2 つ)
  • 南アフリカ北部 (3 つゾーンのうちの 2 つ)
  • 米国中南部 (3 つのゾーンすべて)
  • 東南アジア (3 つのゾーンすべて)
  • スウェーデン中部 (3 つのゾーンすべて)
  • スイス北部 (3 つのゾーンすべて)
  • アラブ首長国連邦北部 (3 つのゾーンすべて)
  • 英国南部 (3 つのゾーンのうち 2 つ)
  • 西ヨーロッパ (3 つのゾーンのうち 2 つ)
  • 米国西部 2 (3 つのゾーンすべて)
  • 米国西部 3 (3 つのゾーンすべて)

提供されているリージョンの一覧では、お客様が自分のワークロードをテストしてアクティブ/アクティブなデプロイ アーキテクチャが可能かどうかを判断することはできません。

Azure リージョンで、ゾーンをまたいだアクティブ/アクティブな SAP デプロイ アーキテクチャができない可能性があるものを、次に示します。

  • カナダ中部
  • フランス中部
  • 東日本

ただし、個々のワークロードでは機能する可能性があります。 そのため、アーキテクチャを決定する前にテストする必要があります。 Azure は、ネットワークの品質と待ち時間を改善するために絶えず取り組んでいます。 何年も前に行われた測定値は、現在の状況を反映していない可能性があります。

お客様が実行時間の差をどの程度許容されるかによって、これ以外のリージョンも対象となる可能性があります。

2 つのゾーン間のアクティブ/アクティブ デプロイの簡略化されたスキーマは次のようになります。

Active/Active zone deployment

この構成には、次の考慮事項が適用されます。

  • Azure 近接通信配置グループを使用しない場合、可用性セットは Azure Availability Zones にデプロイできないため、Azure Availability Zones をすべての VM に対する障害ドメインとして扱います。
  • DBMS レイヤーとセントラル サービス用にゾーン デプロイを組み合わせたい一方で、アプリケーション レイヤーには Azure 可用性セットを使用したい場合は、「SAP アプリケーションで最適なネットワーク待ち時間を実現する Azure 近接通信配置グループ」の記事で説明しているように、Azure 近接通信グループを使用する必要があります。
  • SAP セントラル サービスおよび DBMS レイヤーのフェールオーバー クラスターのロード バランサーには、Standard SKU Azure Load Balancer を使用する必要があります。 Basic Load Balancer は、ゾーンをまたいでは機能しません。
  • SAP システムをホストするためにデプロイした Azure 仮想ネットワークは、そのサブネットと共にゾーンをまたいで拡大されます。 ゾーンごとに仮想ネットワークとサブネットを分ける必要はありません。
  • デプロイするすべての仮想マシンで、Azure Managed Disks を使用する必要があります。 アンマネージド ディスクは、ゾーン ベースのデプロイにはサポートされていません。
  • Azure Premium Storage、Ultra SSD ストレージ、および ANF では、どのような種類のゾーン間ストレージ レプリケーションもサポートされていません。 DBMS デプロイの場合、データをゾーン間でレプリケートするデータベースメソッドに依存しています
  • Azure Premium Files に基づく SMB 共有と NFS 共有の場合、同期レプリケーションを使用したゾーン冗長が提供されます。 このドキュメントで、デプロイをしたいリージョンで Azure Premium Files の ZRS を利用できるかどうかを調べてください。 ゾーン レプリケートされた NFS 共有と SMB 共有の使用は、SAP アプリケーション層のデプロイと、NetWeaver または S/4HANA セントラル サービスの高可用性フェールオーバー クラスターで完全にサポートされています。 これらのケースをカバーするドキュメントは次のとおりです。
  • 3 番目のゾーンは、SUSE Linux Pacemaker クラスターをビルドし、Azure Fencing Agent ではなく SBD デバイスを使用する場合に、SBD デバイスをホストするために使用されます。 あるいは、より多くのアプリケーション インスタンスのために。
  • 重要なビジネス プロセスの実行時間の整合性を達成するには、SAP バッチ サーバー グループ、SAP ログオン グループ、または RFC グループを使用して、アクティブな DBMS インスタンスを含むゾーン内のアプリケーション インスタンスに、特定のバッチ ジョブとユーザーを直接送ることができます。 ただし、ゾーン ベースのフェールオーバー プロセスでは、アクティブ DB VM を含むゾーン内の VM で実行されているインスタンスにこれらのグループを手動で移動する必要があります。
  • 各ゾーンに休止状態のダイアログ インスタンスをデプロイすることをお勧めします。

重要

このアクティブ/アクティブシナリオでは、クロスゾーン トラフィックの料金が適用されます。 「帯域幅の料金詳細」のドキュメントを確認してください。 SAP アプリケーション レイヤーと SAP DBMS レイヤー間のデータ転送には、非常に大きな負荷がかかります。 そのため、アクティブ/アクティブ シナリオではコストがかかる可能性があります。

アクティブ/パッシブ デプロイ

1 つのゾーン内のネットワーク待ち時間とゾーンをまたいだネットワーク トラフィックの待ち時間の間に許容できる差が見つからない場合、SAP アプリケーション レイヤーの観点から、アクティブ/パッシブ特性を持つアーキテクチャをデプロイできます。 アクティブなゾーンを定義します。これは、完全なアプリケーション レイヤーをデプロイし、アクティブな DBMS と SAP セントラル サービス インスタンスの両方を実行するゾーンです。 このような構成では、ジョブがアクティブな DBMS インスタンスを含むゾーンで実行されるかどうかによって、ビジネス トランザクションとバッチ ジョブで実行時間に極端な違いが出ないようにする必要があります。

異なるゾーンにわたるこの種類のデプロイ アーキテクチャが適している Azure リージョンは次のとおりです。

  • カナダ中部
  • フランス中部
  • 東日本
  • ノルウェー東部
  • 南アフリカ北部

このアーキテクチャの基本的なレイアウトを次に示します。

Active/Passive zone deployment

この構成には、次の考慮事項が適用されます。

  • 可用性セットを Azure Availability Zones にデプロイすることはできません。 緩和するために、「SAP アプリケーションで最適なネットワーク待ち時間を実現する Azure 近接通信配置グループ」の記事で説明されているように Azure 近接通信配置グループを使用できます。
  • このアーキテクチャを使用する場合は、状態を注意深く監視し、デプロイしたアプリケーション レイヤーと同じゾーン内にアクティブな DBMS と SAP セントラル サービスのインスタンスを維持する必要があります。 SAP セントラル サービスまたは DBMS インスタンスのフェールオーバーがあった場合は、できるだけ早く SAP アプリケーション レイヤーがデプロイされたゾーンに手動でフェールバックできるようにする必要があります。
  • SAP セントラル サービスおよび DBMS レイヤーのフェールオーバー クラスターのロード バランサーには、Standard SKU Azure Load Balancer を使用する必要があります。 Basic Load Balancer は、ゾーンをまたいでは機能しません。
  • SAP システムをホストするためにデプロイした Azure 仮想ネットワークは、そのサブネットと共にゾーンをまたいで拡大されます。 ゾーンごとに仮想ネットワークを分ける必要はありません。
  • デプロイするすべての仮想マシンで、Azure Managed Disks を使用する必要があります。 アンマネージド ディスクは、ゾーン ベースのデプロイにはサポートされていません。
  • Azure Premium Storage、Ultra SSD ストレージ、および ANF では、どのような種類のゾーン間ストレージ レプリケーションもサポートされていません。 DBMS デプロイの場合、データをゾーン間でレプリケートするデータベースメソッドに依存しています
  • Azure Premium Files に基づく SMB 共有と NFS 共有の場合、同期レプリケーションを使用したゾーン冗長が提供されます。 このドキュメントで、デプロイをしたいリージョンで Azure Premium Files の ZRS を利用できるかどうかを調べてください。 ゾーン レプリケートされた NFS 共有と SMB 共有の使用は、SAP アプリケーション層のデプロイと、NetWeaver または S/4HANA セントラル サービスの高可用性フェールオーバー クラスターで完全にサポートされています。 これらのケースをカバーするドキュメントは次のとおりです。
  • 3 番目のゾーンは、SUSE Linux Pacemaker クラスターをビルドし、Azure Fencing Agent ではなく SBD デバイスを使用する場合に、SBD デバイスをホストするために使用されます。 または、追加のアプリケーション インスタンスに使用されます。
  • ゾーンで障害が発生した場合にアプリケーション リソースを開始できるよう、(DBMS の観点から) パッシブ ゾーンに休止中の VM をデプロイする必要があります。 もう 1 つの可能性として使用できる Azure Site Recovery は、ゾーン間でアクティブな VM を休止中の VM にレプリケートできます。
  • ゾーン障害が発生した場合に 2 番目のゾーンで SAP アプリケーション レイヤーを自動的に開始できるオートメーションに投資する必要があります。

高可用性とディザスター リカバリーの構成の組み合わせ

Microsoft は、Azure リージョン内のさまざまな Azure Availability Zones をホストする施設間の地理的距離に関する情報を共有していません。 それでも、一部のお客様は、ゾーンを使用して HA と DR の構成を組み合わせることで、回復ポイントの目標 (RPO) をゼロにすることを約束しています。 RPO がゼロということは、コミットされたデータベース トランザクションが、ディザスター リカバリーの場合でも、失われてはならないことを意味します。

Note

このような構成は特定の状況でのみ使用することが推奨されます。 たとえば、セキュリティ上またはコンプライアンス上の理由でデータを Azure リージョンの外部に出せない場合に使用することができます。

このような構成の 1 つの例を次に示します。

Combined high-availability DR in zones

この構成には、次の考慮事項が適用されます。

  • Availability Zones をホストしている施設の間に大きな距離があるか、ユーザーが特定の Azure リージョン内にとどまることを余儀なくされているものと想定します。 可用性セットを Azure Availability Zones にデプロイすることはできません。 それを補うために、「SAP アプリケーションで最適なネットワーク待ち時間を実現するための Azure 近接通信配置グループ」の記事で説明されているように Azure 近接通信配置グループを使用できます。
  • このアーキテクチャを使用する場合は、状態を注意深く監視し、デプロイしたアプリケーション レイヤーと同じゾーン内にアクティブな DBMS と SAP セントラル サービスのインスタンスを維持する必要があります。 SAP セントラル サービスまたは DBMS インスタンスのフェールオーバーがあった場合は、できるだけ早く SAP アプリケーション レイヤーがデプロイされたゾーンに手動でフェールバックできるようにする必要があります。
  • アクティブな QA アプリケーション インスタンスを実行する VM には、運用アプリケーションのインスタンスがプレインストールされている必要があります。
  • ゾーンの障害が発生した場合は、QA アプリケーションのインスタンスをシャットダウンし、代わりに運用インスタンスを開始します。 これを行うには、アプリケーション インスタンスの仮想名を使用する必要があります。
  • SAP セントラル サービスおよび DBMS レイヤーのフェールオーバー クラスターのロード バランサーには、Standard SKU Azure Load Balancer を使用する必要があります。 Basic Load Balancer は、ゾーンをまたいでは機能しません。
  • SAP システムをホストするためにデプロイした Azure 仮想ネットワークは、そのサブネットと共にゾーンをまたいで拡大されます。 ゾーンごとに仮想ネットワークを分ける必要はありません。
  • デプロイするすべての仮想マシンで、Azure Managed Disks を使用する必要があります。 アンマネージド ディスクは、ゾーン ベースのデプロイにはサポートされていません。
  • Azure Premium Storage、Ultra SSD ストレージ、および ANF では、どのような種類のゾーン間ストレージ レプリケーションもサポートされていません。 DBMS デプロイの場合、データをゾーン間でレプリケートするデータベースメソッドに依存しています
  • Azure Premium Files に基づく SMB 共有と NFS 共有の場合、同期レプリケーションを使用したゾーン冗長が提供されます。 このドキュメントで、デプロイをしたいリージョンで Azure Premium Files の ZRS を利用できるかどうかを調べてください。 ゾーン レプリケートされた NFS 共有と SMB 共有の使用は、SAP アプリケーション層のデプロイと、NetWeaver または S/4HANA セントラル サービスの高可用性フェールオーバー クラスターで完全にサポートされています。 これらのケースをカバーするドキュメントは次のとおりです。
  • 3 番目のゾーンは、SUSE Linux Pacemaker クラスターをビルドし、Azure Fencing Agent ではなく SBD デバイスを使用する場合に、SBD デバイスをホストするために使用されます。

次のステップ

以下に、Azure Availability Zones 間でデプロイするための次の手順を示します。