Azure インフラストラクチャの VM 再起動を利用して SAP システムの "高可用性" を実現する
このセクションは次に適用されます。
Windows と
Linux
Windows Server フェールオーバー クラスタリング (WSFC) や Linux の Pacemaker などの機能 (現在 SUSE Linux Enterprise Server [SLES] 12 以降でのみサポート) を使用しない場合は、Azure の VM 再起動を利用します。 これにより、Azure 物理サーバー インフラストラクチャと基になる Azure プラットフォーム全体の計画済みおよび計画外のダウンタイムに対して SAP システムを保護します。
Note
Azure の VM 再起動は、主に VM を保護するものであり、アプリケーションを保護するものでは "ありません"。 VM 再起動は、SAP アプリケーションの高可用性を提供するものではなく、一定レベルのインフラストラクチャの可用性を提供します。 それは、間接的に SAP システムの "高可用性" も提供します。 計画されたまたは計画外のホスト停止後に VM を再起動するためにかかる時間に対する SLA はないため、この方法による高可用性の実現は、SAP システムの重要なコンポーネントには適していません。 重要なコンポーネントの例として、ASCS/SCS インスタンスやデータベース管理システム (DBMS) があります。
高可用性の別の重要なインフラストラクチャ要素はストレージです。 たとえば、Azure Storage SLA の可用性は 99.9% です。 すべての VM とそれらのディスクを単一の Azure Storage アカウントにデプロイしている場合、Azure Storage が使用不能になると、ストレージ アカウントに配置されているすべての VM と VM 内で実行されているすべての SAP コンポーネントの可用性が失われます。
すべての VM を単一の Azure Storage アカウントに配置する代わりに、各 VM に専用の Storage アカウントを使用できます。 複数の独立した Azure Storage アカウントを使用することで、VM と SAP アプリケーションの全体的な可用性を向上させることができます。
Azure マネージド ディスクは、それらが接続されている仮想マシンの障害ドメインに自動的に配置されます。 2 つの仮想マシンを可用性セットに配置し、マネージド ディスクを使用した場合、プラットフォームが異なる障害ドメインへのマネージド ディスクの分散も処理します。 Premium Storage アカウントを使用する場合は、マネージド ディスクを使用することを強くお勧めします。
Azure インフラストラクチャの高可用性とストレージ アカウントを使用する SAP NetWeaver システムのアーキテクチャの例を次に示します。
Azure インフラストラクチャの高可用性とマネージド ディスクを使用する SAP NetWeaver システムのアーキテクチャの例を次に示します。
重要な SAP コンポーネントについて、これまでに以下が実現されています。
SAP アプリケーション サーバーの高可用性
SAP アプリケーション サーバー インスタンスは、冗長コンポーネントです。 各 SAP アプリケーション サーバー インスタンスは独自の VM にデプロイされ、別々の Azure の障害ドメインとアップグレード ドメインで実行されます。 詳細については、「 障害ドメイン 」および「ドメインの 更新 」セクションを参照してください。
Azure 可用性セットを使用してこの構成を保証できます。 詳細については、「Azure の可用性セット」を参照してください。
Azure の障害やアップグレード ドメインによる計画されたまたは計画外の停止によって、限られた数の VM と SAP アプリケーション サーバー インスタンスが使用不可になります。
各 SAP アプリケーション サーバー インスタンスは、独自の Azure Storage アカウントに配置されます。 1 つの Azure ストレージ アカウントが使用できなくなった場合、1 つの VM と SAP アプリケーション サーバー インスタンスのみが使用不可になります。 ただし、1 つの Azure サブスクリプションに配置できる Azure Storage アカウントの数には制限があることに注意してください。 VM の再起動後に ASCS/SCS インスタンスが自動的に開始されるようにするには、ASCS/SCS インスタンス開始プロファイルで Autostart パラメーターを設定します。
詳細については、「SAP アプリケーション サーバーの高可用性」を参照してください。
マネージド ディスクを使用している場合でも、ディスクは Azure Storage アカウントに格納されるため、Storage の停止が発生した場合は使用不可になる可能性があります。
SAP ASCS/SCS インスタンスの可用性の向上
このシナリオでは、Azure の VM 再起動を利用して、VM と インストール済みの SAP ASCS/SCS インスタンスを保護します。 Azure サーバーの計画されたまたは計画外のダウンタイムが発生した場合、VM は使用可能な別のサーバー上で起動されます。 前述したように、Azure の VM 再起動は、主に VM を保護するものであり、アプリケーション (ここでは ASCS/SCS インスタンス) を保護するものでは "ありません"。 VM 再起動を通して、SAP ASCS/SCS インスタンスの “可用性の向上” を間接的に実現できます。
VM の再起動後に ASCS/SCS インスタンスが自動的に開始されるようにするには、ASCS/SCS インスタンス開始プロファイルで Autostart パラメーターを設定します。 この設定は、単一の VM で実行される単一障害点 (SPOF) としての ASCS/SCS インスタンスが SAP ランドスケープ全体の可用性を決定することを意味します。
DBMS サーバーの可用性の向上
上記の SAP ASCS/SCS インスタンスのユース ケースと同様に、Azure の VM 再起動を利用して VM とインストール済みの DBMS ソフトウェアを保護することで、VM 再起動による DBMS ソフトウェアの "可用性の向上" を実現できます。
単一の VM で実行される DBMS は SPOF でもあるため、SAP ランドスケープ全体の可用性の決定要因になります。
SAP インスタンスでの Autostart の使用
SAP には、VM 内の OS の起動直後に SAP インスタンスを開始できる設定が用意されています。 手順については、SAP Knowledge Base Article 1909114 を参照してください。 ただし、SAP では、複数の VM に影響する場合、または VM で複数のインスタンスが実行される場合、この設定ではインスタンスを再起動する順序を制御できないため、その使用はもう推奨されていません。
VM 内に 1 つの SAP アプリケーション サーバー インスタンスがあり、最終的に単一の VM が起動されるという一般的な Azure シナリオでは、Autostart は重要ではありません。 ただし、次のパラメーターを SAP Advanced Business Application Programming (ABAP) または Java インスタンスの開始プロファイルに追加することで、それを有効にすることができます。
Autostart = 1
Note
Autostart パラメーターには欠点もあります。 具体的には、このパラメーターは、インスタンスと関連する Windows/Linux サービスが開始されたときに、SAP ABAP または Java インスタンスの起動をトリガーします。 このシーケンスは、オペレーティング システムの起動時に発生します。 ただし、SAP サービスの再起動は、Software Update Manger (SUM) などの SAP ソフトウェア ライフサイクル管理機能や、その他の更新またはアップグレードでも一般的に発生します。 これらの機能では、インスタンスが再起動されることは想定していません。 したがって、このようなタスクを実行する前に、Autostart パラメーターを無効にする必要があります。 ASCS/SCS/CI などのクラスター化された SAP インスタンスでも、Autostart パラメーターは使用しないでください。
SAP インスタンスの Autostart の詳細については、次の記事を参照してください。
- Start or stop SAP along with your Unix Server Start/Stop (Unix サーバーの開始/停止に伴う SAP の開始/停止)
- Starting and stopping SAP NetWeaver management agents (SAP NetWeaver 管理エージェントの開始と停止)
次のステップ
完全な SAP NetWeaver アプリケーション対応の高可用性の詳細については、「Azure IaaS での SAP アプリケーションの高可用性」をご覧ください。