SAP NetWeaver のための高可用性のアーキテクチャとシナリオ
用語の定義
高可用性: 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 インスタンスの高可用性のアーキテクチャ
WSFC ソリューションを使用して、SAP ASCS/SCS インスタンスを保護できます。 クラスター共有構成の種類 (ファイル共有または共有ディスク) に基づいて、適切なソリューションを、ストレージの種類に基づいて参照できます。
クラスター共有 - ファイル共有
クラスター共有 - 共有ディスク
Linux での SAP ASCS/SCS インスタンスの高可用性アーキテクチャ
Linux の場合、SAP ASCS/SCS インスタンス クラスタリングの構成は、オペレーティング システムの分散と使用されているストレージの種類によって異なります。 特定の OS のクラスター フレームワークに従って、適切なソリューションを実装することをお勧めします。
SUSE Linux Enterprise Server (SLES)
Red Hat Enterprise Linux (RHEL)
クラスター化された SAP ASCS/SCS インスタンスのための SAP NetWeaver マルチ SID の構成
マルチ SID は、ファイル共有と共有ディスクを使用して WSFC でサポートされます。 Windows のマルチ SID 高可用性アーキテクチャについての詳細は、次をご覧ください。
- ファイル共有: Windows Server フェールオーバー クラスタリングとファイル共有を使用する SAP ASCS/SCS インスタンス マルチ SID の高可用性。
- 共有ディスク: Windows Server フェールオーバー クラスタリングと共有ディスクを使用する SAP ASCS/SCS インスタンス マルチ SID の高可用性。
マルチ SID クラスタリングは、SAP ASCS/Pacemaker の Linux クラスターでサポートされており、同じクラスター上で 5 つ の SAP SID に制限されています。 Linux のマルチ SID 高可用性アーキテクチャについての詳細は、次をご覧ください。
- SUSE Linux Enterprise Server (SLES): Azure VM での SAP NW の HA SLES for SAP アプリケーションのマルチ SID ガイド。
- Red Hat Linux Enterprise (RHEL): RHEL for SAP アプリケーション マルチ SID 上の Azure VM での SAP NW の HA ガイド。
DBMS インスタンスの高可用性
SAP システムでは、DBMS サーバーも単一障害点になります。 そのため、高可用性ソリューションを実装して、データベースを保護することが重要です。 DBMS の高可用性ソリューションは、SAP システムで使用されるデータベースによって異なります。 データベースに基づき、ガイドラインに従って、データベースで高可用性を実現します。
| データベース | DR の推奨事項 |
|---|---|
| SAP HANA | HANA System Replication (HSR) |
| Oracle | Oracle データの保護 |
| IBM DB2 | 高可用性ディザスター リカバリー (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Always On |