用語の定義
高可用性: IT の中断を最小限に抑える一連のテクノロジを表し、同じデータ センター内の冗長性、フォールト トレランス、またはフェールオーバーで保護されたコンポーネントを通じて IT サービスのビジネス継続性を提供することで実現されます。 ここでは、データ センターは 1 つのAzure リージョン内に存在します。
ディザスター リカバリー :互いに数百マイル離れているようなさまざまなデータ センター間で、IT サービスの中断と復旧を最小にすることも表します。 この場合、データ センターは、同じ地政学的リージョン内のさまざまなAzureリージョン、または顧客としてお客様が確立した場所に存在する可能性があります。
高可用性の概要
Azureの SAP 高可用性は、次の 3 種類に分けることができます。
Azure インフラストラクチャの高可用性
たとえば、高可用性には、コンピューティング (VM)、ネットワーク、ストレージおよび SAP アプリケーションの可用性を高めるためのその利点を含めることがあります。
Azure インフラストラクチャ VM の再起動を利用して SAP アプリケーションを保護する
Windows Server フェールオーバー クラスタリング (WSFC) や Linux 上の 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 インフラストラクチャの高可用性
Azure インフラストラクチャの高可用性とは、仮想マシンとアプリケーションの可用性を確保するために設計されたさまざまな Azure プラットフォーム機能を指します。 これらの機能には、次のものが含まれます。
単一インスタンス仮想マシンの SLA
現在 Premium Storage では、99.9% の単一 VM SLA があります。 1 つの 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 つのインスタンスに接続されることを保証します。
複数の VM が同じ可用性セットの一部である場合、可用性セット内の各仮想マシンは、基になる Azure プラットフォームによって 更新ドメイン と 障害ドメイン として割り当てられます。
- Update ドメインでは、Azure インフラストラクチャの計画メンテナンス中に複数の VM が同時に再起動されることはありません。 一度に 1 つの VM のみが再起動されます。
- 障害ドメインでは、共通の電源とネットワーク スイッチを共有していないハードウェア コンポーネントに VM がデプロイされることが保証されます。 サーバー、ネットワーク スイッチ、または電源で計画外のダウンタイムが発生した場合に、1 つの VM のみが影響を受けます。
詳細については、「可用性セットを使用してAzure内の仮想マシンの可用性を管理するを参照してください。
Azure Availability Zones
Azureは、さまざまな
Availability Zonesを使用する場合は、考慮すべき点がいくつかあります。 考慮事項を次に示します。
- 可用性ゾーン内Azure可用性セットをデプロイすることはできません。 可用性セットと 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 マネージド ディスクの使用が必須です。
Virtual Machine Scale Sets のフレキシブル オーケストレーション
Azureでは、柔軟なオーケストレーションを使用したVirtual Machine Scale Setsは、可用性セットや可用性ゾーンなどの他のデプロイ フレームワークと同様に、SAP ワークロードの高可用性を実現する手段を提供します。 柔軟なスケール セットを使用すると、VM をさまざまな可用性ゾーンや障害ドメイン間で分散できるため、可用性の高い SAP ワークロードのデプロイに適したオプションになります。
フレキシブル オーケストレーションを備えた Virtual Machine Scale Sets は、リージョン内でスケール セットを作成したり、可用性ゾーン全体に渡る柔軟性を提供します。 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 ワークロード用の Virtual Machine Scale Set」のドキュメントを参照してください。
仮想マシンの計画済みメンテナンスと計画外メンテナンス
Azure プラットフォーム イベントの 2 種類は、仮想マシンの可用性に影響を与える可能性があります。
- 計画的なメンテナンス イベントは、基になる Azure プラットフォームに対して Microsoft が定期的に更新を行います。 この更新により、仮想マシンが実行されるプラットフォーム インフラストラクチャの全体の信頼性、パフォーマンス、およびセキュリティが向上します。
- 計画外のメンテナンス イベントは 、仮想マシンの基になるハードウェアまたは物理インフラストラクチャが何らかの方法で失敗した場合に発生します。 それには、ローカル ネットワーク障害、ローカル ディスク障害、またはその他のラック レベルでの障害が挙げられます。 このような障害が検出されると、Azure プラットフォームは、仮想マシンをホストする異常な物理サーバーから正常な物理サーバーに仮想マシンを自動的に移行します。 そのようなイベントはまれですが、それらによっても仮想マシンが再起動されることがあります。
詳細については、「
Azure Storage冗長性
ストレージ アカウント内のデータは、持続性と高可用性を確保するために常にレプリケートされ、一時的なハードウェア障害が発生した場合でもAzure Storage SLA を満たします。
Azure Storageは既定でデータの 3 つのイメージを保持するため、複数のAzure ディスクで RAID 5 または RAID 1 を使用する必要はありません。
詳細については、「Azure Storage レプリケーションを参照してください。
Azure マネージド ディスク
マネージド ディスクは Azure Resource Manager のリソースの種類であり、Azure ストレージ アカウントに格納されている仮想ハード ディスク (VHD) ではなく、推奨されるストレージ オプションです。 マネージド ディスクは、接続されている仮想マシンのAzure可用性セットと自動的に一致します。 それにより、仮想マシンとそこで実行されるサービスの可用性が向上します。
詳細については、 Azure マネージド ディスクの概要に関するページを参照してください。
仮想マシンのデプロイと管理が簡単なため、マネージド ディスクを使うことをお勧めします。
SAP ワークロードの各種デプロイの比較
ここでは、SAP ワークロードで使用できる、各種デプロイの簡単な概要を示します。
| 特徴 | フレキシブル オーケストレーションが設定されている Virtual Machine Scale Sets (FD=1) | 可用性ゾーン | 可用性セット |
|---|---|---|---|
| デプロイ動作 | インスタンスは、1 つ、2 つ、または 3 つの可用性ゾーンに配置され、ベスト エフォートベースで各ゾーン内の異なるラックに分散されます | インスタンスは、1 つ、2 つ、または 3 つの可用性ゾーンにまたがっています | インスタンスはリージョン内に配置され、異なる障害/更新ドメインに渡って分散されます |
| 特定の可用性ゾーンに VM とマネージド ディスクを割り当てる | はい | はい | いいえ |
| 障害ドメイン - 最大拡散 (Azureはインスタンスを最大限に分散します) | はい | いいえ | はい、作成時に定義された障害ドメインの数に基づきます。 |
| ストレージ障害ドメインの調整を計算する | いいえ | いいえ | はい |
| 容量予約 | はい (VM レベルで容量予約を割り当てる) | はい | いいえ |
注
- 更新ドメインは、フレキシブル オーケストレーション モードでは非推奨となりました。 詳細については、フレキシブル オーケストレーションで仮想マシンスケールセットにデプロイメントとリソースを移行する方法を参照してください。
- コンピューティングからストレージへの障害ドメインの配置の詳細については、「仮想マシン スケール セットに適切な数の障害ドメインを選択する」および「可用性セットのしくみ」を参照してください。
- 容量予約を有効にするには、容量予約の制限事項と制約事項を確認することが重要です。
SAP ワークロードの高可用性デプロイのオプション
高可用性 SAP ワークロードをAzureにデプロイする場合は、使用可能なさまざまなデプロイの種類と、異なるAzure リージョン (ゾーン間、単一ゾーン、ゾーンのないリージョンなど) に適用する方法を考慮することが重要です。 次の表に、Azure リージョンの SAP システムに関するいくつかの高可用性オプションを示します。
| システムの種類 | リージョン内の異なるゾーン間 | リージョンの単一ゾーン内 | ゾーンがないリージョン内 |
|---|---|---|---|
| 高可用 SAP システム | FD=1 を指定した柔軟なスケール セット | 近接配置グループを含む可用性セット | 可用性セット |
| 近接配置グループを用いた可用性セットと可用ゾーン | 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 アプリケーションを保護する
WSFC や Pacemaker on Linux (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仮想マシンのさまざまなインスタンスで複数のダイアログ インスタンスを構成します。 仮想マシンの 2 つのインスタンスに少なくとも 2 つの SAP アプリケーション インスタンスAzureインストールされている必要があります。
デプロイの種類 (FD=1 を指定した柔軟なスケール セット、可用性ゾーン、または可用性セット) に応じて、SAP アプリケーション サーバー インスタンスを適切に分散し、冗長性を実現する必要があります。
- platformFaultDomainCount=1 (FD=1) を指定した柔軟なスケール セット: 柔軟なスケール セット (FD=1) を指定してデプロイされた SAP アプリケーション サーバーは、仮想マシンをさまざまな可用性ゾーンに分散し、また、スケール セットはベスト エフォート ベースで各ゾーン内のさまざまな障害ドメインに VM を分散します。 これにより、あるゾーンが使用不能になった場合でも、別のゾーンにデプロイされた SAP アプリケーション サーバーは引き続き使用可能になります。
- 可用性ゾーン: 可用性ゾーン全体にデプロイされた SAP アプリケーション サーバーは、VM が異なるゾーンに渡ることで冗長性を実現します。 これにより、あるゾーンが使用不能になった場合でも、別のゾーンにデプロイされた SAP アプリケーション サーバーは引き続き使用可能になります。 詳細については、「Azure Availability ZonesSAP ワークロードの構成」を参照してください>
- 可用性セット: 可用性セットにデプロイされた SAP アプリケーション サーバーでは、VM が異なる障害ドメインと更新ドメインに分散されます。 異なる更新ドメインに VM を配置する場合は、計画メンテナンス ダウンタイム中に VM が同時に更新されないようにします。 VM を異なる障害ドメインに配置すると、データ センター内のハードウェア障害や停電から VM が保護されます。 Azureスケールユニット内の可用性セットで使用できる障害ドメインと更新ドメインの数は有限です。 1 つの可用性セットに VM を追加し続ける場合、2 つ以上の VM は最終的に同じ障害ドメインまたは更新ドメインに含まれます。 詳細については、SAP NetWeaver のAzure仮想マシンの計画と実装に関するドキュメントの「Azure可用性セット」セクションを参照してください。
管理されていないディスクのみ: 可用性セットでアンマネージド ディスクを使用する場合は、Azure ストレージ アカウントが単一障害点になることを認識することが重要です。 そのため、少なくとも 2 つの仮想マシンが分散される、少なくとも 2 つのAzureストレージ アカウントを用意することが不可欠です。 理想的な設定としては、SAP ダイアログ インスタンスを実行する各仮想マシンのディスクを、異なるストレージ アカウントにデプロイします。
重要
SAP 高可用性インストールには、Azure マネージド ディスクを使用することを強くお勧めします。 マネージド ディスクは接続されている仮想マシンの可用性セットに自動的に配置されるため、仮想マシンと仮想マシンで実行されているサービスの可用性を向上させます。
Windows上の SAP ASCS/SCS インスタンスの高可用性アーキテクチャ
WSFC ソリューションを使用して、SAP ASCS/SCS インスタンスを保護できます。 クラスター共有構成の種類 (ファイル共有または共有ディスク) に基づいて、適切なソリューションを、ストレージの種類に基づいて参照できます。
クラスター共有 - ファイル共有
- smb on Azure Files を使用した SAP ASCS/SCS インスタンスの高可用性。
- SMB on Azure NetApp Files を使用した SAP ASCS/SCS インスタンスの高可用性。
- Scale Out File Server (SOFS) を使用する SAP ASCS/SCS インスタンスの高可用性。
クラスター共有 - 共有ディスク
Linux での SAP ASCS/SCS インスタンスの高可用性アーキテクチャ
Linux の場合、SAP ASCS/SCS インスタンス クラスタリングの構成は、オペレーティング システムの分散と使用されているストレージの種類によって異なります。 特定の OS のクラスター フレームワークに従って、適切なソリューションを実装することをお勧めします。
SUSE Linux Enterprise Server (SLES)
- シンプルなマウントによる NFS を使用する SAP ASCS/SCS インスタンスの高可用性。
- AZURE FILES 上の NFS を使用した SAP ASCS/SCS インスタンスの高可用性。
- AZURE NETAPP FILES で NFS を使用した SAP ASCS/SCS インスタンスの高可用性。
- NFS サーバーを使用する SAP ASCS/SCS インスタンスの高可用性。
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 高可用性アーキテクチャの詳細については、次を参照してください。
- ファイル共有: 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): SAP アプリケーションのマルチ SID ガイド向け SLES 用 Azure VM の SAP NW の HA 。
- Red Hat Linux Enterprise (RHEL): SAP アプリケーションのマルチ SID ガイド向け RHEL 用 Azure VM の SAP NW の HA。
DBMS インスタンスの高可用性
SAP システムでは、DBMS サーバーも単一障害点になります。 そのため、高可用性ソリューションを実装して、データベースを保護することが重要です。 DBMS の高可用性ソリューションは、SAP システムで使用されるデータベースによって異なります。 データベースに基づき、ガイドラインに従って、データベースで高可用性を実現します。
| データベース | DR の推奨事項 |
|---|---|
| SAP HANA | HANA システム レプリケーション (HSR) |
| オラクル | Oracle Data Guard |
| IBM DB2 | 高可用性ディザスター リカバリー (HADR) |
| Microsoft SQL | Microsoft SQL Always On |
| SAP ASE | ASE HADR Always On |