SAP 移行における事業継続とディザスター リカバリー
この記事は、「BCDR の Azure ランディング ゾーン設計領域」に記載されているいくつかの考慮事項と推奨事項に基づいています。 この記事では、SAP プラットフォームをサポートするランディング ゾーンに対する一意の制約について説明します。 SAP はミッション クリティカルなプラットフォームであるため、他のミッション クリティカル ガイダンスも設計に組み込む必要があります。
シナリオとスコープ
オンプレミスのビジネス継続性とディザスター リカバリー (BCDR) のシナリオに対処する原則をアーキテクチャに組み込みます。 これらの原則は、Azure にも適用されます。 ただし、Azure には、ホストの障害を補うために、オンプレミス環境よりも多くのハードウェア容量がある場合があります。 最大の Azure 仮想マシン (VM) でも自動的に復旧するには、別のサーバーで再起動するように構成できます。 オンプレミスのデプロイと同じ条件を使用するように Azure デプロイを設定します。 自動フェールオーバー クラスター構成を使用してオンプレミス システムまたはベアメタル ハードウェアをデプロイする場合は、Azure にも同じ方法でデプロイします。 組織の最も重要なビジネスプロセスを実行する SAP アプリケーションには、次のものが必要です。
サービスおよびビジネス プロセスの可用性。
障害シナリオまたは災害シナリオの目標復旧時間 (RTO)。
失敗シナリオの回復ポイントの目標 (RPO)。
障害シナリオで実行する運用とライフサイクル管理タスクおよびテクノロジ。 これらの管理タスクには、ゲスト オペレーティング システムとデータベース管理システムの修正プログラムの適用、SAP システムの複製、更新などがあります。
ヒント
SAP ランドスケープの各アーキタイプに対する高可用性と災害復旧 (HADR) ソリューションを早期に決定します。 ソリューションがすべての SAP コンポーネントを対象にしていることを確認します。
少なくとも 1 つのランドスケープで、Azure 上で HADR ソリューションを早期に構成し、アクティブな状態を維持します。 その後、チームはソリューションのテクノロジの経験を得ることができます。これは、既存のテクノロジとは異なる場合があります。 HADR を早期に構成して、標準作業手順書 (SOP) の開発と進化に役立てます。
システムが稼動したら即座に、運用ワークロードの完全な高可用性、ディザスター リカバリー、バックアップ保護を計画します。
この記事では、エンタープライズ規模の SAP シナリオでの BCDR の次の側面について説明します。
Azure リージョン内の高可用性
バックアップと復元の考慮事項
地域横断型災害復旧と地域災害復旧のどちらを選択するかを決定する基準
Azure リージョン内の高可用性
以降のセクションでは、SAP エンタープライズ シナリオのための Azure リージョン内の高可用性に関する設計上の考慮事項と推奨事項について説明します。
高可用性の設計上の考慮事項
高可用性を実装する場合の目標は、次のような SAP ソフトウェアの単一障害点の可用性を提供することです。
データベース管理システム。
SAP Advanced Business Application Programming (ABAP)、ABAP SAP Central Services (ASCS)、SAP Central Services (SCS) など、アプリケーションの単一障害点。 高可用性の例として、SAP NetWeaver や SAP S/4HANA アーキテクチャなどが挙げられます。
その他のツール (SAP Web Dispatcher など)。
その他のシナリオでは、可用性をインフラストラクチャの障害やソフトウェアの障害に制限しないでください。 必要なすべてのライフサイクル管理タスクに可用性を適用します。 たとえば、VM、データベース管理システム (DBMS)、SAP ソフトウェアの OS にパッチを適用できます。 計画されたダウンタイム中およびライフサイクル管理操作中に発生する停止を最小限に抑えるには、計画外のサービス中断からシステムを保護するのに役立つ一般的なツールを使用します。
SAP および SAP データベースでは、自動フェールオーバー クラスターがサポートされます。 Windows では、Windows Server 2022 フェールオーバー クラスタリング機能でフェールオーバーがサポートされています。 Linux では、Linux Pacemaker や SIOS Protection Suite や Veritas InfoScale などのパートナーツールがフェイルオーバーをサポートします。 Azure では、独自のデータセンターに高可用性構成のサブセットのみをデプロイできます。
詳細については、「Azure VM の SAP ワークロードでサポートされるシナリオ」および「SAP HANA Large Instances でサポートされるシナリオ」を参照してください。
DBMS レイヤーの場合、一般的なアーキテクチャ パターンでは、データベースを同時にレプリケートし、プライマリ VM とセカンダリ VM で使用されるストレージ スタックとは異なるストレージ スタックを使用します。 Azure では、プライマリ VM とセカンダリの VM で DBMS データ用のストレージを共有するアーキテクチャはサポートされていません。 Azure では、トランザクション ログも再実行ログもサポートされていません。 基本原則は、ネットワーク ファイル システム (NFS) 共有に基づいている場合でも、2 つの独立したストレージ スタックを使用することです。 これらの制限は、オンプレミス ソリューションではなく、Azure ソリューションに限定されます。
Azure では、NFS とサーバー メッセージ ブロックの共有をサポートしているため、他のオプションも用意されています。 Windows では、ASCS および SCS そして、特定の高可用性シナリオに対して Azure 共有ディスクを使用できます。 SAP アプリケーション レイヤー コンポーネントと DBMS レイヤー用にフェールオーバー クラスターを個別に設定します。 Azure では、SAP アプリケーション レイヤー コンポーネントと DBMS レイヤーを 1 つのフェールオーバー クラスターに結合する高可用性アーキテクチャはサポートされていません。
SAP アプリケーション レイヤー コンポーネントと DBMS レイヤーのフェールオーバー クラスターのほとんどには、フェールオーバー クラスターの仮想 IP アドレスが必要です。 一般的な例として、仮想 IP アドレスを必要としない Oracle Data Guard の使用時が挙げられます。 それ以外の場合は、 Azure Load Balancerが仮想 IP アドレスを処理する必要があります。 クラスター構成ごとに 1 つのロード バランサーを使用できます。 ロード バランサーの標準バージョンを使用することをお勧めします。 詳細については、「SAP 高可用性シナリオにおける Standard Azure Load Balancer を使用した VM へのパブリック エンドポイント接続」を参照してください。
詳細については、「SAP NetWeaver の高可用性のアーキテクチャとシナリオ」を参照してください。
次の表は、さまざまな高可用性デプロイ オプションのプラットフォーム レベルのサービス レベル アグリーメント (SLA) を示しています。 マネージド サービスを提供するパートナーは、アプリケーション レベルの SLA も提供します。
| レベル | 高可用性シナリオ | プラットフォームの SLA |
|---|---|---|
| 1 | 可用性ゾーン | 99.99% |
| 2 | 可用性セット | 99.95% |
| 3 | 1 つの VM (自己復旧) | 99.90% |
Azure 可用性セットと可用性ゾーン
高可用性インフラストラクチャをデプロイする前に、選択した地域に応じて、Azure 可用性セットまたは可用性ゾーンのどちらを使用してデプロイするかを決定します。 可用性セットを使用してデプロイされた VM の主な違いは次のとおりです。
仮想マシンが複数の可用性ゾーンに分散していない。
単一の可用性セットを介してデプロイされた VM の種類は、制限されています。これは、セットで始めてデプロイした VM がホストを定義しているからです。 たとえば、M シリーズ VM と E シリーズ VM を 1 つの可用性セットに結合することはできません。
さまざまな可用性ゾーンに高可用性アーキテクチャをデプロイする場合は、VM の より高い SLA を保持できます。 詳細については、「Azure VM SLA」を参照してください。 Azure リージョンによっては、仮想マシン間のネットワーク トラフィックで異なるネットワーク待機時間が検出されることがあります。 詳細については、「Azure Availability Zones での SAP ワークロードの構成」を参照してください。
ゾーン デプロイ アプローチを選択する場合は、選択した Azure リージョンのゾーン間待機時間がパフォーマンスとアーキテクチャの設計の選択にどのように影響するかを検討してください。 アプリケーション サーバーとデータベースの間、および 2 つのデータベース ノード間の待機時間を考慮してください。
アプリケーション サーバーが同じ可用性ゾーンのデータベースに接続するアプリケーション・サーバー層にアクティブ/パッシブ ゾーン デプロイメントを使用する場合は、自動化を構成し、データベース フェイルオーバーが発生した場合に迅速かつ自動化されたリカバリーを可能にする SOP を作成します。
SAP ソリューションで可用性ゾーンを使用する場合は、ゾーン冗長性のために SAP ランドスケープ内の他のすべての Azure サービスとインフラストラクチャ コンポーネントも設計して、真のゾーン冗長性を実現できるようにします。 考慮すべきサービスとコンポーネントの例としては、Azure ExpressRoute ゲートウェイ、Load Balancer、Azure Files、Azure NetApp Files、リバース プロキシ、ファイアウォール、ウイルス対策サービス、バックアップ インフラストラクチャなどが挙げられます。
高可用性に関する設計上の推奨事項
Azure には、アプリケーションのインフラストラクチャ SLA を満たすのに役立つオプションがいくつか用意されています。 3 つすべての SAP コンポーネント (中央サービス、アプリケーション サーバー、およびデータベース) に対して同じオプションを選択する必要があります。 VM、可用性セット、および可用性ゾーンの SLA の詳細については、「オンライン サービスの SLA」を参照してください。
可用性セットに VM を展開すると、障害ドメインおよび更新ドメインとの連携により、VM が同じホスト ハードウェア上に存在するのを防ぎ、ハードウェア障害に対する保護が提供されます。 可用性ゾーンを介して VM をデプロイし、異なるゾーンを使用する場合は、異なる物理的な場所に VM を作成します。 この構成により、ゾーン全体のデータセンターに影響を与える電源、冷却、またはネットワークの問題に対する保護が強化されます。 ただし、近接通信配置グループを使用しない限り、Azure 可用性セットは、Azure 可用性ゾーン内ではデプロイできません。
ゾーン デプロイ アプローチを選択する場合、SAP DBMS、中央サービス、およびアプリケーション レイヤーは異なる可用性ゾーンで実行されます。 ただしほとんどの場合、各可用性ゾーンには、複数のアプリケーション サーバーがあります。 このシナリオでは、各ゾーン内のアプリケーション サーバーは、障害ドメインと更新ドメインの恩恵を自動的に受けることはありません。 可用性セットを使用して、それらの利点を活用できます。 詳細については、「SAP での適切なネットワーク待機時間に対する Azure 近接通信配置グループ」を参照してください。
可用性セットを作成する際には、使用可能な最大数の障害ドメインと更新ドメインを使用します。 たとえば、1 つの可用性セットに複数の VM をデプロイする場合は、障害ドメインの最大数 (3) を使用します。 また、Azure の計画メンテナンスに加えて、潜在的な物理ハードウェア障害、ネットワークの停止、または電源の中断の影響を制限するために、十分な更新ドメインを使用します。 障害ドメインの既定の数は 2 であり、後でオンラインで変更することはできません。
可用性セットのデプロイでは、SAP システムの各コンポーネントが独自の可用性セット内に存在する必要があります。 SAP 中央サービス、データベース、およびアプリケーション VM は、独自の可用性セット内に存在する必要があります。
可用性セット デプロイの Azure 近接通信配置グループを使用する場合、3 つすべての SAP コンポーネント (中央サービス、アプリケーションサーバー、データベース) は、同じ近接通信配置グループに存在する必要があります。
近接通信配置グループを使用する場合は、SAP システム ID (SID) ごとに 1 つを使用します。 グループは、複数の可用性ゾーンまたは Azure リージョンにまたがっていません。
可用性ゾーン デプロイで Azure 近接通信配置グループを使用する場合は、2 つの SAP コンポーネント (中央サービス、アプリケーションサーバー) が同じ近接通信配置グループに存在する必要があります。 2 つのゾーン内のデータベース VM は、近接配置グループの一部ではなくなりました。 各ゾーンの近接通信配置グループは、SAP ASCS と SCS インスタンスで実行される VM のデプロイに基づき規模を確認します。 この構成の利点は、VM のサイズを柔軟に変更できることです。 また、SAP システムの DBMS レイヤーまたはアプリケーション レイヤーで新しい VM タイプに簡単に切り替えることができます。
Azure では、ASCS とデータベースの高可用性を 1 つの Linux Pacemaker クラスターで組み合わせることはできません。 これらは、個々のクラスターに分けます。 複数の中央サービス クラスターを最大 5 つまで 1 組の VM に結合できます。
ASCS およびデータベース クラスターの前で Standard Load Balancer を使用します。
Azure Premium SSD ですべての実稼働システムを実行し、Azure NetApp Files または Azure Ultra Disk Storage を使用します。 少なくとも、パフォーマンスを向上させ、最高の SLA を得ることができるように、OS ディスクが、プレミアム層にあることを確認します。
可用性セット内または可用性ゾーン内の高可用性ペアに、両方の VM をデプロイします。 これらの VM が同じサイズで、同じストレージ構成であることを確認します。
高可用性ペアのデータベースを同期するには、ネイティブ データベース レプリケーションのテクノロジを使用します。
次のいずれかのサービスを使用して、OS に応じて SAP セントラル サービス クラスターを実行します。
SUSE Linux Enterprise Server Pacemaker クラスターは、Azure フェンス エージェントと最大 3 つのノード分離デバイスをサポートします。
Red Hat Enterprise Linux Pacemaker クラスターは Azure フェンス エージェントをサポートしていますが、ノード分離デバイスはサポートしていません。
SAP 認定の Microsoft 以外のクラスター ソフトウェア。
中央サービスおよびデータベース クラスターのドキュメントで推奨されるクラスターのタイムアウト パラメーターを設定します。
SAP ワークロードのストレージ
SAP ワークロードの回復性を設計するときに、適切なストレージ オプションを選択します。 SAP ワークロードに適した Azure ストレージ設計により、待機時間を最小限に抑え、スループットを最大化できます。 実装について、また以下のガイダンスが SAP on Azure 実装のアーキテクチャの決定にどのように役立つかについて検討します。 詳細については、「SAP ワークロード向け Azure ストレージの種類」を参照してください。
Azure上の SAP HANA は、SAP 認定された種類のストレージでのみ実行する必要があります。 特定のディスク構成で特定のボリュームを実行する必要があります。 たとえば、構成で書き込みアクセラレータを有効にしたり、Premium SSD ストレージを使用したりできます。 また、ストレージで実行されるファイル システムが、マシン上で実行される DBMS に対応していることを確認する必要があります。 詳細については、SAP HANA のストレージ構成に関するページを参照してください。
VM に接続されている Azure マネージド データ ディスクに加えて、さまざまな Azure ネイティブ共有ストレージ ソリューションが Azure 上で SAP アプリケーションを実行します。 Azure Site Recovery では、Azure で使用できる一部のストレージ サービスがサポートされていないため、高可用性の構成が異なる場合があります。 SAP ワークロードには、次のストレージの種類を使用します。
ストレージの種類 高可用性構成のサポート Azure 共有ディスク (ローカル冗長ストレージ (LRS) またはゾーン冗長ストレージ (ZRS)) Windows Server 2022 フェールオーバー クラスター。 構成の詳細については、「Windows Server 2022 フェールオーバー クラスタリングを使用した SAP 高可用性の設計」を参照してください。 Azure Files 上の NFS (LRS または ZRS) Linux 環境の Pacemaker ベースのクラスター。 「さまざまなリージョンにおける NFS の可用性」を確認します。 Azure NetApp Files 上の NFS Linux 環境の Pacemaker ベースのクラスター。 詳細については、「SAP VN 向け Azure NetApp Files」を参照してください。 Azure Files 上の SMB (LRS または ZRS) Windows Server 2022 フェールオーバー クラスター。 構成の詳細については、「Azure Files SMB を使用した 高可用性 SAP NetWeaver のインストール」を参照してください。 Azure NetApp Files 上の SMB Windows Server 2022 フェールオーバー クラスター。 構成の詳細については、「SAP アプリケーション用 Azure NetApp Files (SMB) を使用した SAP NetWeaver の高可用性」を参照してください。 Azure ネイティブの共有ストレージ サービスの代わりに、従来の NFS クラスター (分散レプリケートされたブロック デバイス レプリケーションに基づく)、GlusterFS、または記憶域スペース ダイレクトを使用したクラスター共有ボリュームを、Azure で SAP ワークロードを実行するための代替の共有ストレージ ソリューションとして使用できます。 これらの選択肢は、Azure ネイティブの共有ストレージ サービスが、対象の Azure リージョンで使用できないか、ターゲット アーキテクチャをサポートしていない場合に特に役立ちます。 ストレージ サービス可用性の詳細については、「リージョン別 Azure 製品」を参照してください。
Azure 上で SAP ワークロードが利用できる ストレージ オプションの詳細については、「障害復旧を設定するためのストレージの推奨事項とガイドライン」を参照してください。
バックアップと復元
以降のセクションでは、SAP シナリオでのバックアップと復元に関する設計上の考慮事項と推奨事項について説明します。
通常、バックアップと復元は運用環境の SAP ワークロードに適した高可用性ソリューションとは見なされませんが、このテクノロジには他の利点があります。 SAP アプリケーションを使用するほとんどの企業は、長年にわたってバックアップを保存する必要があるコンプライアンス規制に従う必要があります。 その他のシナリオでは、復元元のバックアップも必要です。 このガイダンスは、バックアップとリストアをすでに確立し、SAP アプリケーションのベスト プラクティスに従っていることを前提としています。つまり、次の操作を実行できることを意味します。
RTO を満たす概算時間内の任意の時点で、運用データベースのポイントインタイム リストアを実行する。 ポイントインタイム リストアでは、通常、DBMS レイヤー上のデータまたは SAP を介したデータの削除などのオペレーター エラーを防ぐことができます。
コンプライアンス規制を満たすために、長期的なバックアップを保持するためのストアを維持する。
データベース バックアップを使用して SAP システムを複製し、別のサーバーまたは VM にバックアップを復元します。
データベース バックアップからの実稼働データベース データを使用して、実稼働前システムを更新します。
SAP アプリケーション サーバーと仮想マシン、ディスク、または VM スナップショットをバックアップします。
レプリケーションが有効になっている SAP HANA システムをバックアップする。
SAP HANA データベース インスタンス スナップショットのバックアップ。
オンプレミスでバックアップとリストアをする場合は、これらの機能を Azure の SAP システムに取り込む必要があります。 現在のソリューションに問題がなければ、バックアップ ベンダーが Azure のデプロイをサポートしているかどうか、または Azure で Software as a Service (SaaS) ソリューションを設定したかどうかを確認します。
Azure には、VM スナップショットを取得し、ストリーミングSQL Server と SAP HANA バックアップを管理する、 Azure Backup と呼ばれる SaaS サービスが用意されています。 Azure NetApp Files を使用して SAP HANA データベースを格納している場合は、HANA 整合ストレージのスナップショットに基づいてバックアップを実行できます。
また、Azure Backup を使用して、SAP HANA システム レプリケーション (HSR) が有効になっているデータベースをバックアップすることもできます。 Azure Backup は、フェールオーバーが発生したときにバックアップを自動的に管理し、手動による介入を必要としません。 バックアップには、次の機能も用意されています。
修復のための完全バックアップを行わずに直ちに保護できるため、、HANA インスタンスまたは HSR セットアップ ノードを単一の HSR コンテナーとして保護できます。
インスタント バックアップとインスタント リストアの利点。
SAP HANA 用 Backint と統合される、HANA と整合性のあるスナップショット ベースのアプローチ。 Backup は、HANA ランドスケープ全体および任意のデータベース サイズに対して 1 つの製品として使用できます。
詳細については、レプリケーションが有効になっている SAP HANA データベース」および「SAP HANA インスタンス スナップショット バックアップ」を参照してください。
バックアップと復元に関する設計上の推奨事項
Azure Backup を使用すると、SAP アプリケーションサーバーと中央サービス VM をバックアップできます。
SAP HANA バックアップは、最大 8 TB の HANA デプロイに使用できます。 詳細については、「Azure VM の SAP HANA データベースのバックアップマトリックスのサポート」を参照してください。
Infrastructure as a Service バックアップ ソリューションを使用して、バックアップ インフラストラクチャのサイズを変更して、すべての実稼働サイズのシステムを同時にバックアップするか、実際のシナリオのように、想定時間内にバックアップできるようにします。 ネットワークやセキュリティなどの領域に対しては、運用セットアップまたは同様のセットアップを使用します。
バックアップ時間とリカバリ時間をテストして、障害後にすべてのシステムを同時にリストアするための RTO 要件を満たしていることを確認します。
理想的には、(特に大規模なデータベースの場合) Azure からオンプレミスのバックアップ インフラストラクチャにバックアップをプルすることは避けてください。 このアプローチは、ExpressRoute 回線が使用する帯域幅の量に影響を与える場合があります。
パフォーマンス テスト計画の一環として、バックアップ ツールとリカバリ ツールをロード テストします。
障害復旧
以降のセクションでは、SAP シナリオでのディザスター リカバリーに関する設計上の考慮事項と推奨事項について説明します。
ディザスター リカバリーの設計上の考慮事項
Azure リージョン マップには、65 以上の Azure リージョンが含まれますが、これらすべてが同じサービスを実行するわけではありません。 大規模 SAP ソフトウェア デプロイ、特に SAP HANA を使用するデプロイの場合、Azure M シリーズ VM または Mv2 シリーズ VM を提供する Azure リージョンを探します。 また Azure Storage は、異なるリージョンをペアにして、ストレージの種類の小さなサブセットを別のリージョンにレプリケートします。 詳細については、「Azure ペア領域の概要」を参照してください。
SAP ワークロード用に Azure リージョンを組み合わせることの主な課題は次のとおりです。
ペアは、M シリーズまたは Mv2 シリーズの VM サービスと常に一致するとは限りません。 SAP システムをデプロイしている多くの組織は、ペアになっている Azure リージョンを使用していません。 代わりに、必要な VM の種類の可用性に基づいてリージョンを選択しています。
ペアになっているリージョン間で Standard Storage をレプリケートすることはできますが、Standard Storage を使用してデータベースや仮想ハード ディスクを格納することはできません。 バックアップは、使用するペアになっているリージョン間でのみレプリケートできます。 他のすべてのデータについては、SQL Server Always On や SAP HANA システム レプリケーションなどのネイティブ DBMS 機能を使用してレプリケーションを実行します。
rsyncやrobocopyなどの Site Recovery ツールと SAP アプリケーション層向けのその他非 Microsoft ソフトウェアを組み合わせて使用します。障害が発生した場合、Azure リージョン内の影響を受ける複数のお客様は、対応するペアの障害復旧リージョンにフェール オーバーします。 この状況は、障害復旧リージョンで休止状態の VM を起動するためのリソースの競争につながります。 回避策は、障害復旧リージョンで非運用システムを実行し、同じリソースを使用して運用システムの障害復旧レプリカをホストすることです。 障害復旧リージョンで Azure インフラストラクチャをこのように 2 つの目的で使用すると、リソース容量の制約を回避できます。
もう 1 つの重要な考慮事項は、障害リージョンで必要な運用容量を確保することです。 障害が発生した場合は、プライマリ リージョンでの通常の運用の復旧に取り組んでいる間のみ不可欠な人材によって最小限の IT 容量で最短期間 SAP アプリケーションを実行することが必要になることがあります。 この戦略では、障害復旧リージョンで使用できる IT インフラストラクチャが最小限である必要があります。
Azure リージョンを定義したら、デプロイ パターンを選択する必要があります。
運用システムをプライマリ リージョンにデプロイする場合。
非運用 SAP システムをディザスター リカバリー リージョンにデプロイする場合。
すべての SAP システムをプライマリ リージョンにグループ化するアーキテクチャを使用する場合。 この構成により、ディザスター リカバリー リージョンがディザスター リカバリーにのみ使用されるようになります。
ほとんどの組織では、両方のリージョンを稼働中の SAP システムに使用しています。 運用システムの完全なコピーをビジネス回帰テスト システムとして実行している組織は、通常、SAP 製品ラインのビジネス回帰テスト システムをディザスター リカバリーのターゲットとして使用することを計画しています。
ディザスター リカバリー リージョンを選ぶときは、そのリージョンに ExpressRoute 接続ができることを確認してください。 Azure に接続する ExpressRoute 回線が複数ある場合は、それらの回線の少なくとも 1 つがプライマリ Azure リージョンに接続している必要があります。 残りは、ディザスター リカバリー リージョンに接続する必要があります。 この種類のアーキテクチャは、地理的または地政学的な異なるエリアにある Azure ネットワークに接続し、Azure リージョンの 1 つに大災害が発生した場合に接続を保護するのに役立ちます。
一部の組織は、高可用性と障害復旧を組み合わせたアーキテクチャを使用しています。これは、高可用性と障害復旧を同じ Azure リージョンにグループ化したものです。 しかし、高可用性とディザスター リカバリーをグループ化することは理想的ではありません。 Azure Availability Zones では、このアーキテクチャがサポートされています。 Azure リージョン内の可用性ゾーン間の距離は、 2 つのリージョン間の距離ほど長くはないため、自然災害が発生すると、そのリージョン内線のアプリケーション サービスに危険が及ぶ場合があります。 また、SAP アプリケーション サーバーとデータベース サーバー間の待機時間も考慮する必要があります。 SAP Note 1100926 によると、0.3 ミリ秒以下の往復時間が適正値で、0.7 ミリ秒以下は、適度な値です。 そのため、高いレイテンシのゾーンの場合、SAP アプリケーション サーバーとデータベース サーバーが常に同じゾーンで実行されることを確実にするための運用手順を準備する必要があります。 組織は次のような理由でこのアーキテクチャを選びます。
コンプライアンスは、運用環境のデプロイとディザスター リカバリーのターゲットの間の距離が短い場合をサポートする構成で十分である。
データ主権が要因である。
地政学的要因が関係している。
これは、ゾーン障害をサポートする低コストオプションであり、大きな半径に影響する自然災害に備えたセカンダリ リージョンへのバックアップ転送と組み合わせることがあります。
ディザスター リカバリー リージョンを選ぶ際に考慮する必要があるもう 1 つの要因は、ディザスター リカバリー サイトにフェールオーバーするための RPO と RTO です。 運用リージョンと障害復旧リージョン間の距離が長いほど、ネットワーク待機時間が長引きます。 Azure リージョン間では非同期的にレプリケートしますが、ネットワーク待機時間は、レプリケートできるスループットと RPO 目標に影響を与える可能性があります。 RPO を最小限に抑えるために、高可用性と障害復旧アーキテクチャを組み合わせて使用できます。 ただし、この構成では、大規模な自然災害によるリスクが高くなる可能性があります。
ディザスター リカバリーの設計上の推奨事項
プライマリ仮想ネットワークのクラスレス ドメイン間ルーティング (CIDR) が、確実にディザスター リカバリー サイトの仮想ネットワークの CIDR と競合または重複しないようにします。
オンプレミスからプライマリとセカンダリの Azure ディザスター リカバリー リージョンへの ExpressRoute 接続を設定します。
オンプレミスからプライマリおよびセカンダリの Azure 障害復旧リージョンへの VPN 接続を設定することを検討してください。 ExpressRoute を使用する代わりに、このメソッドを使用します。
Site Recovery を使用して、アプリケーション サーバーをディザスター リカバリー サイトにレプリケートします。 また、Site Recovery は、中央サービス クラスター VM をディザスター リカバリー サイトにレプリケートする場合にも役立ちます。 ディザスター リカバリーを呼び出す場合は、ディザスター リカバリー サイトで Linux Pacemaker クラスターを再構成する必要があります。 たとえば、仮想 IP アドレスまたは SBD を置き換えたり、corosync.conf を実行したりする必要がある場合があります。
証明書、シークレット、キーなどのキー コンテナーの内容をリージョン間でレプリケートして、障害復旧リージョンのデータを復号化できるようにします。
Azure NetApp Files でリージョン間レプリケーションを使用して、プライマリ リージョンとディザスター リカバリー リージョンの間でファイル ボリュームを同期します。
Site Recovery ではなく、ネイティブ データベース レプリケーションを使用して、データをディザスター リカバリー サイトに同期します。
プライマリとディザスター リカバリーの仮想ネットワークをピアリングします。 たとえば、HANA システム レプリケーションの場合、SAP HANA DB 仮想ネットワーク ニーズを障害復旧現場の SAP HANA DB 仮想ネットワークにピアリングする必要があります。
SAP デプロイに Azure NetApp Files ストレージを使用する場合は、少なくとも 2 つのリージョンで Premium レベルの 2 つの Azure NetApp Files アカウントを作成します。
アプリケーションのパフォーマンスを踏まえて、ビジネスの重要性と近接依存性に基づきシステムをグループ化することを検討してください。 リージョンの停止によるビジネスへの影響を最小限に抑えるには、各グループをペアのリージョン構造内の個別のリージョンにデプロイします。 たとえば、地域的な障害の影響を最小限に抑えるために、英国南部と英国西部の 2 つの異なる事業部門にサービスを提供する 2 つの重要な ERP Central Component システムをデプロイできます。