次の方法で共有

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

  • [アーティクル]

Azure Availability Zones にさまざまな SAP アーキテクチャ レイヤーをデプロイすることは、Azure 上への SAP ワークロードのデプロイに推奨されるアーキテクチャです。 Azure 可用性ゾーンは次のように定義されます。"リージョン内の一意の物理的な場所。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。" Azure Availability Zones は、すべてのリージョンで使用できるわけではありません。 Availability Zones が提供される Azure リージョンについては、Azure リージョン マップを確認してください。 この記事には、Availability Zones を利用できるリージョンが記載されています。 大規模な SAP ワークロードをホストする機能を備えた Azure リージョンのほとんどは、Availability Zones を利用できます。 新しい Azure リージョンでは、最初から Availability Zones を利用できます。 以前のリージョンの一部は、Availability Zones の導入が完了しているか、現在も進行中です。

一般的な SAP NetWeaver または S/4HANA アーキテクチャにおいては、次の 3 つの異なるレイヤーを保護する必要があります。

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

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

  • 可用性セットを使用したデプロイでは、セット内の VM が単一のゾーンまたはデータセンター (特定のリージョンに対してどちらでも適用できます) 内に配置されます。 その結果、可用性セットを使用したデプロイは、そのゾーンのデータセンター全体に影響する電源、冷却手段、またはネットワークの問題からは保護されません。 可用性セットを使用すると、VM とそのディスク間の強制的なアラインメントは行われません。 つまり、ディスクは、リージョンのゾーン構造に関係なく、Azure リージョンの任意のデータセンターに配置できます。 プラス面としては、VM が、そのゾーンまたはデータセンター内の更新ドメインと障害ドメインに応じて配置されます。 特に、1 つの可用性セットにつき 2 台の VM を保護する SAP ASCS またはデータベース レイヤーでは、障害ドメインに応じた配置により、両方の VM が同じホスト ハードウェア上にデプロイされるのを防ぐことができます。
  • Azure Availability Zones を使用して VM をデプロイし、異なるゾーン (最大 3 つまで可能) を選択すると、それらの VM が異なる物理的な場所にデプロイされ、そのゾーンのデータセンター全体に影響する電源、冷却手段、またはネットワークの問題の保護が強化されます。 VM とそれに関連するディスクも同じ可用性ゾーンに併置されます。 ただし、同じ VM ファミリの複数の VM を同じ可用性ゾーンにデプロイする場合は、それらの VM が同じホスト上や同じ障害ドメインにデプロイされるのを防ぐことはできません。 そのため、Availability Zones を使用したデプロイは、通常はそれぞれ 2 台の VM が存在する SAP ASCS およびデータベース レイヤーに最適です。 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 ソリューションとして使用する場合は、自然災害により、電力インフラストラクチャに対する深刻で広範囲な被害など、世界各地で広範囲にわたる被害が生じていることに留意してください。 さまざまなゾーン間の距離は、このような大規模な自然災害を補うには十分でない場合があります。
  • Availability Zones 間のネットワーク待ち時間は、すべての Azure リージョンで同じではありません。 1 つの Azure リージョン内であっても、異なるゾーン間のネットワーク待機時間は異なる場合があります。 ただし、最悪の場合でも、HANA システム レプリケーションまたは SQL Server Always On に基づくデータベース レベルの同期レプリケーションは、ワークロードのスケーラビリティに影響を与えることなく機能します。
  • Availability Zones を使用する場所を決定する際はゾーン間のネットワークの待ち時間に基づいて決定してください。 ネットワーク待ち時間は、次の 2 つの点で重要な役割を果たします。
    • 同期レプリケーションが必要な 2 つのデータベース インスタンス間の待機時間。 ネットワーク待機時間が長い (1.5 ミリ秒未満) ゾーン間の最大規模の NetWeaver と S/4HANA システムの運用が非常に成功していることを踏まえると、この考慮事項は無視できます
    • アクティブなデータベース インスタンスを含むゾーンで SAP ダイアログ インスタンスを実行している VM と、別のゾーンの同様の VM との間のネットワーク待機時間の違い。 この違いが大きいほど、データベースを含むゾーン、または別のゾーンのどちらで実行しているかに応じて、ビジネス プロセスとバッチ ジョブの実行時間への影響も大きくなります (この記事で後述します)。
  • Azure Availability Zones のネットワーク待機時間は、最大のゾーンであっても、SAP ビジネス プロセスを十分に実行できる低い値です。 これまでのところ、お客様が 1 つのデータセンター ネットワーク スパインの下に SAP アプリケーション レイヤーとデータベース レイヤーを併置する必要があるという例外的なケースは少数しか確認されていません。

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

  • Azure Availability Zones にデプロイするときは Azure Managed Disks を使用する必要があります。
  • 物理ゾーンに対するゾーン列挙のマッピングは、Azure サブスクリプションごとに固定されています。 さまざまなサブスクリプションを使用して SAP システムをデプロイする場合は、サブスクリプションごとに最適なゾーンを定義する必要があります。 異なるサブスクリプションの論理マッピングを比較したい場合は、Avzone-Mapping スクリプトを検討してください。
  • Azure 近接通信配置グループを使用しない場合、1 つの Azure Availability Zone 内に Azure 可用性セットをデプロイすることはできません。 SAP データベース レイヤーとセントラル サービスを複数のゾーンにわたってデプロイすると同時に、可用性セットを使用して SAP アプリケーション レイヤーをデプロイし、さらに VM の近接通信も実現する方法については、SAP アプリケーションで最適なネットワーク待機時間を実現する Azure 近接通信配置グループの記事で説明しています。 Azure 近接配置グループを使用していない場合は、仮想マシン用のデプロイ フレームワークとして、いずれかを選択する必要があります。
  • Azure Basic Load Balancer を使用して Windows Server フェールオーバー クラスタリングまたは Linux Pacemaker に基づくフェールオーバー クラスター ソリューションを作成することはできません。 代わりに、Azure Standard Load Balancer SKU を使用する必要があります。
  • 必要なゾーン保護を実現するには、ゾーン バージョンの ExpressRoute Gateway、VPN Gateway、Standard パブリック IP アドレスをデプロイする必要があります。

Availability Zones の最適な組み合わせ

ログオン グループ、RFC サーバー グループ、バッチ サーバー グループなどの SAP 機能を使用してビジネス プロセスの割り当てを構成しない限り、SAP アプリケーション レイヤー全体のさまざまなアプリケーション インスタンスでビジネス プロセスを実行できます。 このことによる副作用は、バッチ ジョブがアクティブなデータベース インスタンスと同じゾーン内で実行されるかどうかに関係なく、任意の SAP アプリケーション インスタンスによって実行される可能性があるということです。 異なるゾーン間と 1 つのゾーン内とでネットワーク待ち時間にあまり差がない場合は、バッチ ジョブの実行時間の差は重要ではないかもしれません。 しかし、ゾーン間とゾーン内のネットワーク トラフィックのネットワーク待機時間の差が大きいほど、データベース インスタンスがアクティブではないゾーン内でジョブが実行された場合のバッチ ジョブの実行時間への影響が大きくなる可能性があります。 実行時間の違いをどの程度許容できるかは、お客様ご自身で判断してください。 お客様のワークロードにとって、クロスゾーン トラフィックで許容できるネットワーク待ち時間はどの程度かについても同様です。 純粋に技術的な観点から見ると、Azure リージョン内の Azure 可用性ゾーン間のネットワーク待機時間は、NetWeaver、S/4HANA、またはその他の SAP アプリケーションのアーキテクチャに影響します。 また、この記事で紹介するデプロイ概念のいずれかを選択するときに、ログオン グループ、RFC サーバー グループ、バッチ サーバー グループなどの SAP 概念を使用して、このような差異を軽減できる可能性はありますが、それもお客様が行う必要があります。

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

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

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

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

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

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

  • データベース インスタンスに使用する VM SKU を 3 つのゾーンすべてにデプロイします。 この測定を実行するときは、Azure Accelerated Networking が有効になっていることを確認します。 高速ネットワークは、数年前から既定の設定になっています。 それでも、有効になっているか、動作しているかを確認してください
  • ネットワーク待ち時間が最も短い 2 つのゾーンがわかったら、アプリケーション レイヤー VM として使用する VM SKU の別の 3 つの VM を 3 つの Availability Zones にデプロイします。 選択した 2 つのゾーン内の 2 つのデータベース VM に対して、ネットワーク待機時間を測定します。
  • 測定ツールとして niping を使用します。 SAP 提供のこのツールの説明は、SAP サポート ノート #500235 と #1100926 をご覧ください。 SAP Note #1100926 のネットワーク待機時間の分類を大まかなガイダンスとして扱います。 ネットワーク待機時間が 0.7 ミリ秒を超えても、システムが技術的に機能しないことや、ビジネス プロセスが個々の SLA を満たしていないことを意味するわけではありません。 この注記は、SAP や Microsoft が何をサポートし、何をサポートしていないかを示すことを目的としていません。 待ち時間測定用に記載されているコマンドに注目してください。 ping は Azure Accelerated Networking コード パスでは機能しないので、ping の使用は推奨されません。

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

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

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

重要

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

重要

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

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

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

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

アクティブ/アクティブ ゾーンのデプロイ

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

  • Azure 近接通信配置グループを使用しない場合、可用性セットは Azure Availability Zones にデプロイできないため、Azure Availability Zones をすべての VM に対する障害ドメインとして扱います。
  • データベース レイヤーとセントラル サービス用にゾーン デプロイを組み合わせたい一方で、アプリケーション レイヤーには Azure 可用性セットを使用したい場合は、SAP アプリケーションで最適なネットワーク待機時間を実現する Azure 近接通信配置グループに関する記事で説明されているように、Azure 近接通信グループを使用する必要があります。
  • SAP セントラル サービスおよびデータベース レイヤーのフェールオーバー クラスターのロード バランサーには、Standard SKU Azure Load Balancer を使用する必要があります。 Basic ロード バランサーはゾーン間には機能しません。
  • 必要なゾーン保護を実現するには、ゾーン バージョンの ExpressRoute Gateway、VPN Gateway、Standard パブリック IP アドレスをデプロイする必要があります。
  • SAP システムをホストするためにデプロイした Azure 仮想ネットワークは、そのサブネットと共にゾーンをまたいで拡大されます。 ゾーンごとに仮想ネットワークとサブネットを分ける必要はありません。
  • デプロイするすべての仮想マシンで、Azure Managed Disks を使用する必要があります。 アンマネージド ディスクは、ゾーン ベースのデプロイにはサポートされていません。
  • Azure Premium SSD v2、Ultra SSD ストレージ、または Azure NetApp Files は、ゾーン間の同期ストレージ レプリケーションをサポートしていません。 データベース デプロイの場合、データをゾーン間でレプリケートする場合は、データベースのメソッドを利用しています。
  • 可用性ゾーン間の同期ゾーン レプリケーションをサポートする Premium SSD v1 は、SAP データベース ワークロードではテストされていません。 そのため、Azure Premium SSD v1 のゾーン同期レプリケーションは、SAP データベース ワークロードではサポートされていないと考える必要があります。
  • 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 グループを使用して、アクティブなデータベース インスタンスを含むゾーン内のアプリケーション インスタンスに、特定のバッチ ジョブとユーザーを直接送ることができます。 ただし、ゾーン ベースのフェールオーバー プロセスでは、アクティブ DB VM を含むゾーン内の VM で実行されているインスタンスにこれらのグループを手動で移動する必要があります。
  • 各ゾーンに休止状態のダイアログ インスタンスをデプロイすることをお勧めします。

重要

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

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

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

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

アクティブ/パッシブ ゾーンのデプロイ

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

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

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

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

Note

Availability Zones を短距離 DR ソリューションとして使用する場合は、自然災害により、電力インフラストラクチャに対する深刻で広範囲な被害など、世界各地で広範囲にわたる被害が生じていることに留意してください。 さまざまなゾーン間の距離は、このような大規模な自然災害を補うには十分でない場合があります。

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

ゾーン内の高可用性 DR の組み合わせ

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

  • 可用性ゾーンをホストする施設間にかなりの距離があると想定しています。 または、特定の Azure リージョン内に留まることを余儀なくされています。 可用性セットを Azure Availability Zones にデプロイすることはできません。 それを補うために、「SAP アプリケーションで最適なネットワーク待ち時間を実現するための Azure 近接通信配置グループ」の記事で説明されているように Azure 近接通信配置グループを使用できます。
  • このアーキテクチャを使用する場合は、状態を注意深く監視し、デプロイしたアプリケーション レイヤーと同じゾーン内にアクティブなデータベース インスタンスと SAP セントラル サービスのインスタンスを維持する必要があります。 SAP セントラル サービスまたはデータベース インスタンスのフェールオーバーがあった場合は、できるだけ早く SAP アプリケーション レイヤーがデプロイされたゾーンに手動でフェールバックできるようにする必要があります。
  • アクティブな QA アプリケーション インスタンスを実行する VM には、運用アプリケーションのインスタンスがプレインストールされている必要があります。
  • ゾーンの障害が発生した場合は、QA アプリケーションのインスタンスをシャットダウンし、代わりに運用インスタンスを開始します。 これを行うには、アプリケーション インスタンスの仮想名を使用する必要があります。
  • SAP セントラル サービスおよびデータベース レイヤーのフェールオーバー クラスターのロード バランサーには、Standard SKU Azure Load Balancer を使用する必要があります。 Basic ロード バランサーはゾーン間には機能しません。
  • 必要なゾーン保護を実現するには、ゾーン バージョンの ExpressRoute Gateway、VPN Gateway、Standard パブリック IP アドレスをデプロイする必要があります。
  • SAP システムをホストするためにデプロイした Azure 仮想ネットワークは、そのサブネットと共にゾーンをまたいで拡大されます。 ゾーンごとに仮想ネットワークを分ける必要はありません。
  • デプロイするすべての仮想マシンで、Azure Managed Disks を使用する必要があります。 アンマネージド ディスクは、ゾーン ベースのデプロイにはサポートされていません。
  • Azure Premium SSD v2、Ultra SSD ストレージ、または Azure NetApp Files は、ゾーン間の同期ストレージ レプリケーションをサポートしていません。 データベース デプロイの場合、データをゾーン間でレプリケートする場合は、データベースのメソッドを利用しています。
  • 可用性ゾーン間の同期ゾーン レプリケーションをサポートする Premium SSD v1 は、SAP データベース ワークロードではテストされていません。 そのため、Azure Premium SSD v1 の構成可能なゾーン同期レプリケーションは、SAP データベース ワークロードではサポートされていないと考える必要があります。
  • 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 間でデプロイするための次の手順を示します。