SAP NetWeaver のための高可用性のアーキテクチャとシナリオ

[アーティクル]
11/15/2023

用語の定義

高可用性: IT の中断を最小限に抑える一連のテクノロジを表し、"同じ" データセンター内の冗長性、フォールトトレランス、またはフェールオーバーで保護されたコンポーネントを通じて IT サービスのビジネス継続性を提供することで実現されます。ここの例では、データセンターは 1 つの Azure リージョン内にあります。

ディザスターリカバリー :互いに数百マイル離れているような "さまざまな" データセンター間で、IT サービスの中断と復旧を最小にすることも表します。ここの例では、データセンターは同じ地理的リージョン内のさまざまな Azure リージョンや顧客が設定した場所に存在している可能性があります。

高可用性の概要

Azure での SAP 高可用性は、次の 3 つの種類に分類できます。

Azure インフラストラクチャの高可用性

たとえば、高可用性には、コンピューティング (VM)、ネットワーク、ストレージおよび SAP アプリケーションの可用性を高めるためのその利点を含めることがあります。
Azure インフラストラクチャ VM の再起動を利用して SAP アプリケーションを保護する:

Linux で Windows Server フェールオーバークラスタリング (WSFC) や Pacemaker などの機能を使用しない場合は、Azure VM の再起動を利用します。 Azure 物理サーバーインフラストラクチャと基盤となる Azure プラットフォーム全体に、計画的および計画外のダウンタイムが発生した場合に、SAP システムの機能を復元します。
SAP アプリケーションの高可用性

SAP システム全体の高可用性を実現するには、SAP システムの重要なすべてのコンポーネントを保護する必要があります。次に例を示します。
- SAP アプリケーションサーバーの冗長性。
- 一意のコンポーネント。たとえば、SAP ASCS/SCS インスタンスやデータベース管理システム (DBMS) などの単一障害点 (SPOF) コンポーネントがあります。

Azure における SAP の高可用性は、オンプレミスの物理環境または仮想環境内の SAP 高可用性とは異なります。

Windows 向けはありますが、Linux 向けの SAPinst 統合 SAP 高可用性構成は用意されていません。 Linux 向け SAP 高可用性オンプレミスについては、高可用性パートナー情報に関するページをご覧ください。

Azure インフラストラクチャの高可用性

単一インスタンス仮想マシンの SLA

現在 Premium Storage では、99.9% の単一 VM SLA があります。単一 VM の可用性について理解するために、さまざまな Azure サービスレベルアグリーメントを利用できる製品を構築できます。

計算の基準は、1 か月あたり 30 日間または 43,200 分です。たとえば、0.05% のダウンタイムは 21.6 分に相当します。通常どおり、さまざまなサービスの可用性は次の方法で計算されます。

(可用性サービス #1/100) x (可用性サービス #2/100) x (可用性サービス #3/100) *…

次に例を示します。

(99.95/100) x (99.9/100) x (99.9/100) = 0.9975、つまり全体の可用性は 99.75%。

同じ可用性セット内の仮想マシンの複数のインスタンス

同じ可用性セットにデプロイされた 2 つ以上のインスタンスがあるすべての仮想マシンについては、仮想マシンが 99.95% 以上の時間において少なくとも 1 つのインスタンスに接続されることを保証します。

2 つ以上の VM が同じ可用性セットに含まれている場合、基盤となる Azure プラットフォームによって、可用性セット内の各仮想マシンに更新ドメインと障害ドメインが割り当てられます。

更新ドメインでは、Azure インフラストラクチャの計画済みメンテナンス時に、複数の VM が同時に再起動しないことが保証されます。一度に 1 つの VM のみが再起動されます。
障害ドメインでは、共通の電源とネットワークスイッチを共有していないハードウェアコンポーネントに VM がデプロイされることが保証されます。サーバー、ネットワークスイッチ、または電源で計画外のダウンタイムが発生した場合に、1 つの VM のみが影響を受けます。

詳細については、可用性セットを使用した Azure の仮想マシンの可用性の管理の説明を参照してください。

Azure Availability Zones

Azure では、Azure Availability Zones の概念をさまざまな Azure リージョン全体にロールアウトしています。 Availability Zones が提供される Azure リージョンには複数のデータセンターがあり、電源、冷却装置、ネットワークが独立しています。 1 つの Azure リージョン内で異なるゾーンを提供する理由は、2 つまたは 3 つの Availability Zones にまたがってアプリケーションをデプロイできるようにするためです。電源やネットワークの問題により 1 つの可用性ゾーンのインフラストラクチャだけが影響を受けた場合でも、Azure リージョン内のアプリケーションのデプロイは完全に機能します。最終的には、1 つのゾーンの VM がいくつか失われて、容量が若干減る可能性があります。ただし、他の 2 つのゾーンの VM はまだ稼働しています。ゾーンを提供する Azure リージョンの一覧は、Azure Availability Zones に関するページにあります。

Availability Zones を使用する際には、考慮が必要な点がいくつかあります。考慮事項を次に示します。

可用性ゾーン内に Azure 可用性セットをデプロイすることはできません。可用性セットと Availability Zones を組み合わせる唯一の可能性は、近接配置グループを使用することです。詳細については、記事「可用性セットと Availability Zones を近接配置グループに結合する」を参照してください。
Basic Load Balancer を使用して Windows フェールオーバークラスターサービスまたは Linux Pacemaker に基づくフェールオーバークラスターソリューションを作成することはできません。代わりに Azure Standard Load Balancer SKU を使用する必要があります。
Azure Availability Zones は、1 つのリージョン内のさまざまな異なる間の特定の距離を保証するものではありません。
異なる Azure リージョン内の異なる Azure Availability Zones 間のネットワーク待ち時間は、Azure リージョンごとに異なる可能性があります。 1 つのゾーンからアクティブな DBMS VM までのネットワーク待ち時間がビジネスプロセスへの影響から依然として許容できるようなケースでは、顧客が異なるゾーンをまたいでデプロイされた SAP アプリケーションレイヤーを合理的に実行できる場合があります。一方、あるゾーン内のアクティブな DBMS VM と別のゾーンにある VM 内の SAP アプリケーションインスタンスとの間の待ち時間が過度に侵入的であり、SAP ビジネスプロセスにとって許容できない顧客シナリオがあります。そのため、待ち時間が長すぎる場合は、デプロイアーキテクチャをアプリケーションのアクティブ/アクティブアーキテクチャまたはアクティブ/パッシブアーキテクチャとは異なるものにする必要があります。
Azure Availability Zones にデプロイするには、Azure マネージドディスクの使用が必須です。

仮想マシンスケールセットとフレキシブルオーケストレーション

可用性セットや可用性ゾーンなどの他のデプロイフレームワークと同様に、Azure では、フレキシブルオーケストレーションを備えた Virtual Machine Scale Sets が SAP ワークロードの高可用性を実現する手段を提供します。柔軟なスケールセットを使用すると、VM をさまざまな可用性ゾーンや障害ドメイン間で分散できるため、可用性の高い SAP ワークロードのデプロイに適したオプションになります。

フレキシブルオーケストレーションを備えた仮想マシンスケールセットは、リージョン内でスケールセットを作成したり、可用性ゾーン全体に渡る柔軟性を提供します。 platformFaultDomainCount>1 (FD>1) を使用するリージョン内でフレキシブルなスケールセットを作成すると、スケールセットにデプロイされた VM は、同じリージョン内の指定された数の障害ドメインに分散されます。一方、platformFaultDomainCount=1 (FD=1) を指定して可用性ゾーン間で柔軟なスケールセットを作成すると、さまざまなゾーンに VM が分散され、スケールセットによって、ベストエフォートベースで各ゾーン内のさまざまな障害ドメインに VM が分散されます。 SAP ワークロードでは、FD=1 を指定した柔軟なスケールセットのみがサポートされます。

従来の可用性ゾーンのデプロイではなく、FD=1 でフレキシブルなスケールセットを使用する利点は、スケールセットでデプロイされた VM がベストエフォート方式でゾーン内のさまざまな障害ドメインに分散されることです。すべての Azure データセンターまたは各ネットワークスパインの下で VM の可用性を確保するための近接配置グループの利用に関連する制限を回避するには、FD=1 を指定した柔軟なスケールセットを使用して、可用性ゾーン全体に渡って SAP ワークロードをデプロイすることをお勧めします。このデプロイ戦略により、各ゾーンにデプロイされる VM が単一のデータセンターまたはネットワークスパインに制限されなくなり、データベース、ASCS/ERS、アプリケーション層などのすべての SAP システムコンポーネントがゾーンレベルでスコープ設定されます。

したがって、可用性ゾーン全体に渡って新しい SAP ワークロードをデプロイする場合は、FD=1 を指定した柔軟なスケールセットを使用することをお勧めします。詳細については、SAP ワークロード用の仮想マシンスケールセットのドキュメントを参照してください。

仮想マシンの計画済みメンテナンスと計画外メンテナンス

2 種類の Azure プラットフォームイベントが仮想マシンの可用性に影響を与えることがあります。

計画済みメンテナンス イベントは、Microsoft によって、基になる Azure プラットフォームに対して行われる定期的な更新です。この更新により、仮想マシンが実行されるプラットフォームインフラストラクチャの全体の信頼性、パフォーマンス、およびセキュリティが向上します。
計画外メンテナンス イベントは、仮想マシンの基盤となっているハードウェアや物理インフラストラクチャに何らかの不具合があった場合に発生します。それには、ローカルネットワーク障害、ローカルディスク障害、またはその他のラックレベルでの障害が挙げられます。そのような障害が検知されると、Azure プラットフォームは、仮想マシンをホストしている異常な物理サーバーから正常な物理サーバーへ、仮想マシンを自動的に移行します。そのようなイベントはまれですが、それらによっても仮想マシンが再起動されることがあります。

詳細については、Azure での仮想マシンのメンテナンスを参照してください。

Azure Storage の冗長性

ストレージアカウント内のデータは、持続性と高可用性を確保するために常にレプリケートされており、一時的なハードウェア障害が発生した場合でも Azure Storage SLA が満たされます。

Azure Storage は、既定で、データの 3 つのイメージを維持するため、複数の Azure ディスクにまたがる RAID 5 や RAID 1 を使用する必要はありません。

詳細については、「Azure Storage のレプリケーション」をご覧ください。

Azure Managed Disks

マネージドディスクは Azure Resource Manager のリソースの種類であり、Azure ストレージアカウントに格納されている仮想ハードディスク (VHD) の代わりに推奨されるストレージオプションです。マネージドディスクは、接続先の仮想マシンの Azure 可用性セットに自動的に配置されます。それにより、仮想マシンとそこで実行されるサービスの可用性が向上します。

詳細については、「Azure Managed Disks の概要」をご覧ください。

仮想マシンのデプロイと管理が簡単なため、マネージドディスクを使うことをお勧めします。

SAP ワークロードのさまざまなデプロイの種類の比較

ここでは、SAP ワークロードで使用できる、さまざまなデプロイの種類の簡単な概要を示します。

機能	仮想マシンスケールセットとフレキシブルオーケストレーション (FD=1)	可用性ゾーン	可用性セット
デプロイの動作	インスタンスは 1 つ、2 つ、または 3 つの可用性ゾーンに渡って配置され、ベストエフォートベースで各ゾーン内の異なるラックに分散されます	インスタンスは 1 つ、2 つ、または 3 つの可用性ゾーンに渡って分散して配置されます	インスタンスはリージョン内に配置され、異なる障害/更新ドメインに渡って分散されます
特定の可用性ゾーンに VM とマネージドディスクを割り当てる	はい	有効	いいえ
障害ドメイン - 最大分散 (Azure によってインスタンスが最大限に分散される)	はい	いいえ	はい、作成時に定義された障害ドメインの数に基づきます。
ストレージ障害ドメインの調整を計算する	いいえ	番号	はい
容量予約	はい (VM レベルで容量予約を割り当てる)	はい	いいえ

Note

更新ドメインは、フレキシブルオーケストレーションモードでは非推奨となりました。詳細については、「フレキシブルオーケストレーションでデプロイとリソースを Virtual Machine Scale Sets に移行する」を参照してください
ストレージ障害ドメインの調整の計算の詳細については、「仮想マシンスケールセットに対する障害ドメインの適切な数を選択する」と「可用性セットのしくみ」を参照してください。
容量予約を有効にするには、容量予約の制限事項と制約事項を確認することが重要です。

SAP ワークロードの高可用性デプロイのオプション

高可用性 SAP ワークロードを Azure にデプロイする場合は、使用可能なさまざまなデプロイの種類と、それを異なる Azure リージョン (ゾーン間、単一のゾーン、ゾーンのないリージョンなど) に適用する方法を考慮することが重要です。次の表に、Azure リージョンの SAP システムの、いくつかの高可用性オプションを示します。

システムの種類	1 リージョン内の異なるゾーン間	1 リージョンの 1 ゾーン内	ゾーンのないリージョン内
高可用性 SAP システム	FD=1 を指定した柔軟なスケールセット	近接配置グループを使用した Availability Sets	可用性セット
	近接配置グループを使用した Availability Sets と Availability Zones	FD=1 を指定した柔軟なスケールセット (1 つのゾーンのみを選択)	FD=1 を指定した柔軟なスケールセット (ゾーンの定義なし)
	可用性ゾーン	可用性セット

リージョン内の異なるゾーンに渡るデプロイ: 高可用性のために、SAP システムをリージョン内の異なるゾーンにデプロイする必要があります。これにより、1 つのゾーンが使用不能になった場合でも、SAP システムは別のゾーンで引き続き使用可能になります。可用性ゾーン全体に渡って新しい SAP ワークロードをデプロイする場合は、FD=1 デプロイオプションで指定された柔軟な仮想マシンスケールを使用することをお勧めします。これにより、容量の制約や配置グループを気にせずに、リージョン内の異なるゾーンに複数の VM をデプロイできます。スケールセットフレームワークにより、スケールセットと共にデプロイされた VM がベストエフォート方式でゾーン内のさまざまな障害ドメインに分散されるようになります。 SAP ASCS/ERS、SAP データベースなどの高可用性 SAP コンポーネントは、すべて異なるゾーンに分散され、各ゾーン内の複数のアプリケーションサーバーはベストエフォートベースで異なる障害ドメインに分散されます。
1 リージョンの 1 ゾーンへのデプロイ: 高可用性 SAP システムを複数の可用性ゾーンのある場所に、リージョン別にデプロイする場合や、システムのすべてのコンポーネントが単一のゾーンに存在することが不可欠な場合は、Availability Sets と近接配置グループのデプロイオプションを使用することをお勧めします。このアプローチにより、すべての SAP システムコンポーネントを 1 つの可用性ゾーンにグループ化し、可用性セット内の仮想マシンがさまざまな障害ドメインと更新ドメインに分散されるようにすることができます。このデプロイではストレージ障害ドメインの計算を調整しますが、近接性は保証されません。ただし、このデプロイオプションはリージョン限定のため、ゾーン間のディザスターリカバリー用の Azure Site Recovery はサポートしていません。さらに、このオプションでは、SAP デプロイ全体が 1 つのデータセンターに制限されるため、SKU サイズを変更したり、アプリケーションインスタンスをスケールアウトする必要がある場合に、容量の制限が発生する可能性があります。
ゾーンのないリージョンへのデプロイ: ゾーンのないリージョンに SAP システムをデプロイする場合は、可用性セットを使用することをお勧めします。このオプションは、VM を異なる障害ドメインと更新ドメインに配置することにより、冗長性とフォールトトレランスを提供します。

重要

Azure リージョンのデプロイオプションは単なる提案であることに注意してください。 SAP システムに最適なデプロイ戦略は、特定の要件と環境によって異なります。

Azure インフラストラクチャの高可用性を利用して SAP アプリケーションを保護する

Linux で WSFC や Pacemaker などの機能 (SUSE Linux Enterprise Server 12 以降、および Red Hat Enterprise Linux 7 以降でサポート) を使用しない場合は、Azure VM の再起動を利用します。 Azure 物理サーバーインフラストラクチャと基盤となる Azure プラットフォーム全体に、計画的および計画外のダウンタイムが発生した場合に、SAP システムの機能を復元します。

このアプローチの詳細については、「Azure インフラストラクチャの VM 再起動を利用して SAP システムの高可用性を実現する」を参照してください。

Azure IaaS での SAP アプリケーションの高可用性

SAP システム全体の高可用性を実現するには、SAP システムの重要なすべてのコンポーネントを保護する必要があります。次に例を示します。

SAP アプリケーションサーバーの冗長性。
一意のコンポーネント。たとえば、SAP ASCS/SCS インスタンスやデータベース管理システム (DBMS) などの単一障害点 (SPOF) コンポーネントがあります。

次に、3 つすべての重要な SAP システムコンポーネントの高可用性を実現する方法について詳しく説明します。

SAP アプリケーションサーバーの高可用性アーキテクチャ

Windows と Linux

SAP アプリケーションサーバーおよびダイアログインスタンスについては、通常、特定の高可用性ソリューションは不要です。高可用性は冗長性によって実現し、Azure Virtual Machines のさまざまなインスタンスで複数のダイアログインスタンスを構成します。 Azure Virtual Machines の 2 つのインスタンスに少なくとも 2 つの SAP アプリケーションインスタンスをインストールする必要があります。

デプロイの種類 (FD=1 を指定した柔軟なスケールセット、可用性ゾーン、または可用性セット) に応じて、冗長性を実現するために、SAP アプリケーションサーバーインスタンスを適切に分散する必要があります。

platformFaultDomainCount=1 (FD=1) を指定した柔軟なスケールセット: 柔軟なスケールセット (FD=1) を指定してデプロイされた SAP アプリケーションサーバーは、仮想マシンをさまざまな可用性ゾーンに分散し、また、スケールセットはベストエフォートベースで各ゾーン内のさまざまな障害ドメインに VM を分散します。これにより、あるゾーンが使用不能になった場合でも、別のゾーンにデプロイされた SAP アプリケーションサーバーは引き続き使用可能になります。
可用性ゾーン: 可用性ゾーン全体にデプロイされた SAP アプリケーションサーバーは、VM が異なるゾーンに渡ることで冗長性を実現します。これにより、あるゾーンが使用不能になった場合でも、別のゾーンにデプロイされた SAP アプリケーションサーバーは引き続き使用可能になります。詳細については、「Azure Availability Zones での SAP ワークロードの構成」を参照してください
可用性セット: 可用性セットにデプロイされた SAP アプリケーションサーバーでは、VM が異なる障害ドメインと更新ドメインに分散されます。異なる更新ドメインに VM を配置する場合は、計画メンテナンスのダウンタイム中に VM が同時に更新されないようにしてください。一方、VM を別の障害ドメインに配置すると、データセンター内のハードウェア障害や停電から VM が確実に保護されます。ただし、Azure スケールユニット内の Azure 可用性セットで使用できる障害ドメインと更新ドメインは、数に限りがあります。 1 つの可用性セットに VM を追加し続ける場合、2 つ以上の VM は最終的に同じ障害ドメインまたは更新ドメインに含まれます。詳しくは、SAP NetWeaver のための Azure Virtual Machines の計画と実装に関するドキュメントの Azure の可用性セットのセクションをご覧ください。

非管理対象ディスクのみ: 可用性セットでアンマネージドディスクを使用する場合は、Azure ストレージアカウントが単一障害点になることを認識することが重要です。そのため、少なくとも 2 つの仮想マシンが分散されている、2 つの Azure ストレージアカウントを所有する必要があります。理想的な設定としては、SAP ダイアログインスタンスを実行する各仮想マシンのディスクを、異なるストレージアカウントにデプロイします。

重要

SAP 高可用性インストールには、Azure マネージドディスクを使用することを強くお勧めします。マネージドディスクは接続されている仮想マシンの可用性セットに自動的に配置されるため、仮想マシンと仮想マシンで実行されているサービスの可用性を向上させます。

Windows での SAP ASCS/SCS インスタンスの高可用性のアーキテクチャ

Windows

WSFC ソリューションを使用して、SAP ASCS/SCS インスタンスを保護できます。クラスター共有構成の種類 (ファイル共有または共有ディスク) に基づいて、適切なソリューションを、ストレージの種類に基づいて参照できます。

クラスター共有 - ファイル共有
クラスター共有 - 共有ディスク
- Azure 共有ディスクを使用した SAP ASCS/SCS インスタンスの高可用性。
- SIOS を使用した SAP ASCS/SCS インスタンスの高可用性。

Linux での SAP ASCS/SCS インスタンスの高可用性アーキテクチャ

Linux

Linux の場合、SAP ASCS/SCS インスタンスクラスタリングの構成は、オペレーティングシステムの分散と使用されているストレージの種類によって異なります。特定の OS のクラスターフレームワークに従って、適切なソリューションを実装することをお勧めします。

SUSE Linux Enterprise Server (SLES)
Red Hat Enterprise Linux (RHEL)
- Azure Files で NFS を使用した SAP ASCS/SCS インスタンスの高可用性。
- Azure NetApp Files で NFS を使用した SAP ASCS/SCS インスタンスの高可用性。

クラスター化された SAP ASCS/SCS インスタンスのための SAP NetWeaver マルチ SID の構成

ウィンドウ

マルチ SID は、ファイル共有と共有ディスクを使用して WSFC でサポートされます。 Windows のマルチ SID 高可用性アーキテクチャについての詳細は、次をご覧ください。