SAP アプリケーションに関するディザスター リカバリーのガイドライン

  • [アーティクル]

Azure で SAP ワークロードのディザスター リカバリー (DR) を構成するには、プロセスを定期的にテスト、微調整、更新する必要があります。 ディザスター リカバリーのテストは、SAP ワークロードの DR フェールオーバーをトリガーしたり、セカンダリ サイトでシステムを起動したりする前に必要な依存サービスのシーケンスを特定するのに役立ちます。 組織は通常、SAP システムを Active Directory (AD) とドメイン ネーム システム (DNS) サービスに接続して正しく機能させます。 SAP ワークロードの DR を設定するときは、アプリケーションが正しく機能するように、SAP や他の非 SAP システムを復旧する前に、AD と DNS サービスが機能していることを確認します。 Active Directory と DNS の保護については、Active Directory と DNS の保護の方法を学習してください。 このドキュメントで説明する SAP アプリケーションの DR 推奨事項は抽象レベルであり、ユーザーは特定のセットアップに基づいて DR 戦略を設計し、エンド ツー エンドのシナリオを文書化する必要があります。

SAP ワークロードに関する DR の推奨事項

通常、分散 SAP NetWeaver システムでは、中央サービス、データベース、共有ストレージ (NFS/SMB) が単一障害点 (SPOF) です。 さまざまな SPOF の影響を軽減するには、これらのコンポーネントの冗長性を設定する必要があります。 プライマリ リージョンでのこれらの SPOF コンポーネントの冗長性は、高可用性を構成することによって実現されます。 コンポーネントの高可用性設定により、SAP システムはローカル環境の障害や大災害から保護されます。 ただし、地理的に分散した災害から SAP アプリケーションを保護するには、すべての SAP コンポーネントに対して DR 戦略を実装する必要があります。

仮想マシンで実行される SAP システムの場合は、Azure Site Recovery を使ってディザスター リカバリー計画を作成できます。 SAP システムの各コンポーネントに推奨されるディザスター リカバリー アプローチを次に示します。 TREX や非 SAP アプリケーションなどの、スタンドアロンの NetWeaver 以外の SAP エンジンについては、このドキュメントでは説明しません。

Components 推奨
SAP Web Dispatcher Azure Site Recovery を使用して VM をレプリケートする
SAP セントラル サービス Azure Site Recovery を使用して VM をレプリケートする
SAP アプリケーション サーバー Azure Site Recovery を使用して VM をレプリケートする
SAP データベース データベースによって提供されるレプリケーション方法を使用する
ストレージの共有 ストレージの種類ごとに適切な方法を使用してコンテンツをレプリケートする

SAP Web Dispatcher

SAP Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックのロード バランサーとして機能します。 プライマリ リージョンで SAP Web Dispatcher コンポーネントの高可用性を実現するには、さまざまなオプションがあります。 このオプションについて詳しくは、「SAP Web Dispatcher の高可用性」と Azure での SAP Web Dispatcher の HA セットアップに関するページをご覧ください。

  • オプション 1: クラスター ソリューションを使用した高可用性。
  • オプション 2: 並列 SAP Web Dispatcher を使用した高可用性。

プライマリ リージョンで高可用性 SAP Web Dispatcher セットアップの DR を実現するには、Azure Site Recovery を使用できます。 プライマリ リージョンで実行されている並列 Web ディスパッチャー (オプション 2) の場合は、Azure Site Recovery を構成することで DR を実現できます。 しかしプライマリ リージョンでオプション 1 を使って SAP Web Dispatcher を構成する場合は、フェールオーバー後に追加の変更を行って、DR リージョンで同様の HA 設定にする必要があります。 クラスター ソリューションによる SAP Web Dispatcher の高可用性の構成は、SAP セントラル サービスと同様の方法で構成されます。 SAP セントラル サービスについて説明されているものと同じガイドラインに従ってください。

SAP セントラル サービス

SAP セントラル サービスに含まれるエンキューおよびメッセージ サーバーは、SAP アプリケーションの SPOF の 1 つです。 SAP システムでは、そのようなインスタンスは 1 つだけ存在でき、高可用性を実現するように構成できます。 「SAP セントラル サービスの高可用性」を読んで、Azure 上の SAP ワークロードのためのさまざまな高可用性ソリューションについて理解してください。

SAP セントラル サービスの高可用性を構成すると、局地的な出来事からリソースとプロセスが保護されます。 SAP セントラル サービスの DR を実現するには、Azure Site Recovery を使用できます。 Azure Site Recovery が VM と接続されたマネージド ディスクをレプリケートしますが、DR 戦略にはさらなる考慮事項があります。 SAP セントラル サービスに使われるオペレーティング システムに基づいて、以下のセクションで詳細を確認してください。

SAP システムの場合、プライマリ リージョンでの SPOF コンポーネントの冗長性は、高可用性を構成することによって実現されます。 フェールオーバー後にディザスター リカバリー リージョンで同様の高可用性設定を実現するには、Azure Site Recovery を使用して VM と接続マネージド ディスクを DR サイトにレプリケートすると共に、クラスターの再構成、SAP 共有ディレクトリの可用性などの点を検討する必要があります。 Linux では、Pacemaker クラスター ソリューションを使って SAP アプリケーションの高可用性を実現できます。 次の図は、Pacemaker を使用した SAP セントラル サービスの高可用性の構成に関連するさまざまなコンポーネントを示したものです。 各構成要素を考慮して、同様の高可用性を DR サイトに設ける必要があります。 Pacemaker クラスター ソリューションを使って SAP Web Dispatcher を構成した場合は、同様の考慮事項も適用されます。

SAP システムの Linux アーキテクチャ

内部ロード バランサー

Azure Site Recovery は VM を DR サイトにレプリケートしますが、Azure ロード バランサーのレプリケートは行いません。 フェールオーバーの前または後に、DR サイトに個別に内部ロード バランサーを作成する必要があります。 内部ロード バランサーを事前に作成する場合は、空のバックエンド プールを作成し、フェールオーバー イベントの後で VM を追加します。

Pacemaker クラスター ソリューション

Pacemaker クラスターの構成は VM のローカル ファイルに存在し、Azure Site Recovery で DR サイトにレプリケートされます。 Pacemaker クラスターの構成は、そのままではフェールオーバー後に VM で機能しません。 ソリューションを機能させるには、追加のクラスター再構成が必要です。

ストレージとフェンスのメカニズムの種類に基づく、DR リージョンでの Pacemaker クラスターの再構成については、次のブログをご覧ください。

Linux 用の SAP 共有ディレクトリ

SAP NetWeaver または ABAP プラットフォームの高可用性セットアップでは、Pacemaker クラスター構成での SAP システムのエンキュー サービスに対するアプリケーション レベルの冗長性を実現するために、エンキュー レプリケーション サーバーが使われます。 SAP セントラル サービス (ASCS および ERS) の高可用性セットアップでは、NFS マウントが使われます。 そのため、これらの NFS マウント内の SAP バイナリとデータが DR サイトにレプリケートされるようにする必要があります。 Azure Site Recovery では、VM とそれにアタッチされているローカル マネージド ディスクはレプリケートされますが、NFS マウントはレプリケートされません。 セットアップ用に構成した NFS ストレージの種類に基づいて、データがレプリケートされ、DR サイトで使用可能になるようにする必要があります。 各ストレージのリージョン間レプリケーション手法は、抽象レベルで示されています。 ユーザーは、ストレージをレプリケートしてテストを実行するための正確な手順を確認する必要があります。

SAP 共有ディレクトリ リージョン間レプリケーション
Azure Files 上の NFS カスタム (rsync など)
ANF 上の NFS あり (リージョン間レプリケーション)
NFS クラスター Custom

ヒント

高可用性 SAP システムに共有データを格納するには、Azure ファースト パーティ NFS サービス (Azure Files 上の NFS または NFS ANF ボリューム) のいずれかをデプロイすることをお勧めします。 SAP 参照アーキテクチャを重視しなくなり、NFS クラスターを利用していることに注意してください。

フェンシング メカニズム

オペレーティング システム (SLES または RHEL) とそのバージョンに関係なく、Pacemaker では、ソリューション全体が適切に動作するために有効なフェンシング メカニズムが必要です。 プライマリ リージョンでセットアップしたフェンシング メカニズムの種類に基づいて、フェールオーバー後に DR サイトで同じフェンシング メカニズムが設定されるようにする必要があります。

フェンシング メカニズム リージョン間 DR に関する推奨事項
iSCSI ターゲット サーバーを使用する SBD Azure Site Recovery を使用して iSCSI ターゲット サーバーをレプリケートします。
DR VM で、iSCSI ディスクを再度検出します。
Azure フェンス エージェント DR VM でマネージド システム ID (MSI) を有効にします。
カスタム ロールを割り当てます。
クラスター内のフェンス エージェント リソースを更新します。
Azure 共有ディスクを使用する SBD* DR リージョンで新しい Azure 共有ディスクを構成します。 フェールオーバー後に Azure 共有ディスクを DR VM にアタッチします。
Azure 共有ディスクの SBD デバイスを設定します。

* Azure 共有ディスクの ZRS は、限られたリージョンで使用できます。

Note

操作とフェールオーバーを容易にするため、プライマリと DR 両方のリージョンで同じフェンシング メカニズムを使うことをお勧めします。 DR サイトへのフェールオーバー後に異なるフェンシング メカニズムを使うことはお勧めしません。

SAP アプリケーション サーバー

プライマリ リージョンでの SAP アプリケーション サーバーの冗長性は、複数の VM にインスタンスをインストールすることで実現されます。 SAP アプリケーション サーバーの DR を設定するには、アプリケーション サーバー VM ごとに Azure Site Recovery を設定できます。 アプリケーション サーバーにアタッチされている共有ストレージ (トランスポート ファイルシステム、インターフェイス データ ファイルシステム) の場合は、共有ストレージの種類に基づいて適切な DR プラクティスに従います。

SAP データベース サーバー

SAP ワークロードを実行しているデータベースの場合は、ネイティブの DBMS レプリケーション テクノロジを使って DR を構成します。 Azure Site Recovery は、DB の一貫性を保証せず、データ チャーンの制限があるため、データベースに使うことはお勧めしません。 レプリケーション テクノロジはデータベースごとに異なるため、それぞれのデータベースのガイドラインに従ってください。 次の表では、SAP ワークロードに使われるデータベースの一覧と、対応する DR の推奨事項を示します。

データベース DR の推奨事項
SAP HANA HANA System Replication (HSR)
Oracle Oracle Data Guard (FarSync)
IBM DB2 高可用性ディザスター リカバリー (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Always On
SAP MaxDB スタンバイ データベース

ソリューションのコストを最適化するには、データベース DR 戦略にバックアップと復元オプションを使うこともできます。

バックアップと復元

バックアップと復元は、業務の RTO と RPO が重要でない場合に SAP ワークロードのディザスター リカバリーを実現するために使用できる、もう 1 つのソリューションです。 クラウドベースのバックアップ サービスである Azure backup を使って、仮想マシン、マネージド ディスク、サポートされているデータベースなど、SAP ワークロードのさまざまなコンポーネントのコピーを取得できます。 Azure Backup のシナリオとデプロイの一般的なサポート設定と制限事項について詳しくは、Azure Backup のサポート マトリックスに関する記事をご覧ください。

サービス コンポーネント Azure Backup のサポート
Compute Azure VM サポートされています
Storage 共有ディスクを含む Azure Managed Disks サポートされています
Storage Azure ファイル共有 - SMB (Standard または Premium) サポートされています
Storage Azure BLOB サポートされています
Storage Azure ファイル共有 - NFS (Standard または Premium) サポートされていません
Storage Azure NetApp Files サポートされていません
データベース Azure VM の SAP HANA データベース サポートされています
データベース Azure VM の SQL サーバー サポートされています
データベース Oracle サポート対象*
データベース IBM DB2、SAP ASE サポートされていません

Note

* Azure Backup では、データベース整合性スナップショットのための Azure VM バックアップを使って Oracle データベースがサポートされます。

Azure Backup では、SAP ワークロードに使われるすべての Azure ストレージとデータベースがサポートされているわけではありません。

Azure Backup は、選択されているレプリケーションの種類 (LRS、ZRS、または GRS) に基づいてデータをレプリケートする Recovery Services コンテナーにバックアップを格納します。 geo 冗長ストレージ (GRS) の場合、バックアップ データはペアになっているセカンダリ リージョンにレプリケートされます。 リージョンをまたがる復元機能を有効にすると、セカンダリ リージョンでサポートされている管理の種類のデータを復元できます。

バックアップと復元は、従来からあるコスト最適化アプローチですが、より高い RTO のトレードオフが伴います。 DR リージョンにフェールオーバーする場合は、バックアップからすべてのアプリケーションを復元する必要があります。 そのため、ビジネス ニーズを分析し、それに応じて DR 戦略を設計する必要があります。

リファレンス