SAP 移行における事業継続とディザスター リカバリー

  • [アーティクル]

この記事は、「BCDR のための Azure ランディング ゾーンの設計領域」で定義されているいくつかの考慮事項と推奨事項に基づいています。 この記事は、SAP プラットフォームをサポートするすべてのランディング ゾーンに対する一意の制約を理解するのに役立ちます。 SAP はミッション クリティカルなプラットフォームであるため、このドキュメントの「Azure ランディング ゾーンの設計領域」セクションに記載されている他のガイダンスも参照して設計に組み込む必要があります。

シナリオとスコープ

アーキテクチャには、オンプレミスのビジネス継続性とディザスター リカバリー (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 ABAP や ASCS + SCS などのアプリケーションの単一障害点。 例としては、SAP NetWeaver と SAP S/4HANA アーキテクチャがあります。
  • その他のツール (SAP Web Dispatcher など)。

その他のシナリオでは、可用性をインフラストラクチャまたはソフトウェアの障害に制限しないでください。 VM の OS、DBMS、SAP ソフトウェアへのパッチ適用など、必要なすべてのライフサイクル管理タスクに可用性を適用します。 計画されたダウンタイム中およびライフサイクル管理操作中に発生する停止を最小限に抑えるには、計画外のサービス中断からシステムを保護するのに役立つ一般的なツールを使用します。

SAP および SAP データベースでは、自動フェールオーバー クラスターがサポートされます。 Windows では、Windows Server フェールオーバー クラスタリングでフェールオーバーがサポートされています。 Linux では、Linux Pacemaker またはサードパーティ製ツール (SIOS Protection Suite や Veritas InfoScale など) でフェールオーバーがサポートされています。 Azure では、独自のデータセンターに高可用性構成のサブセットのみをデプロイできます。

Azure でサポートされている SAP の詳細については、AZURE VM でサポートされている SAP ワークロードのシナリオおよびSAP HANA の大規模インスタンスでサポートされているシナリオに関するページを参照してください。

DBMS レイヤーの場合、一般的なアーキテクチャ パターンでは、データベースを同時にレプリケートし、プライマリ VM とセカンダリ VM で使用されるストレージ スタックとは異なるストレージ スタックを使用します。 Azure では、プライマリとセカンダリの VM で DBMS データ用のストレージを共有するアーキテクチャはサポートされていません。 また、トランザクション ログと再実行ログもサポートされていません。 基本原則は、ネットワーク ファイル システム (NFS) 共有に基づいている場合でも、2 つの独立したストレージ スタックを使用することです。 オンプレミスで可能なことと Azure で可能なことを比較する場合、このアプローチが主な制限事項になります。

Azure では、NFS またはサーバー メッセージ ブロック共有のいずれかがサポートされているため、他のオプションも用意されています。 Windows では、ASCS + SCS コンポーネントと特定の高可用性シナリオに Azure 共有ディスクを使用できます。 SAP アプリケーション レイヤー コンポーネントと DBMS レイヤー用にフェールオーバー クラスターを個別に設定します。 Azure では現在、SAP アプリケーション レイヤー コンポーネントと DBMS レイヤーを 1 つのフェールオーバー クラスターに結合する高可用性アーキテクチャはサポートされていません。

SAP アプリケーション レイヤー コンポーネントと DBMS レイヤーのフェールオーバー クラスターのほとんどには、フェールオーバー クラスターの仮想 IP アドレスが必要です。 一般的な例外は、Oracle Data Guard を使用する場合です。 これには仮想 IP アドレスは必要ありません。 それ以外の場合は、 Azure Load Balancerが仮想 IP アドレスを処理する必要があります。 設計上の原則として、クラスター構成ごとに 1 つのロード バランサーを使用します。 ロード バランサーの標準バージョンを使用することをお勧めします。 詳細については、「SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した Virtual Machines のパブリック エンドポイント接続」を参照してください。

詳細とオプションについては、「SAP NetWeaver のための高可用性のアーキテクチャとシナリオ」を参照してください。

さまざまな高可用性デプロイ オプションに対するプラットフォーム レベルの SLA を次に示します。 管理サービスを提供するパートナーは、アプリケーション レベルの SLA を提供します。

レベル HA シナリオ プラットフォームの SLA
レベル 1 可用性ゾーン 99.99%
レベル 2 可用性セット 99.95%
階層 3 1 つの VM (自己復旧) 99.9%

詳細については、次のセクションを参照してください。

Azure 可用性セットと可用性ゾーン

高可用性インフラストラクチャをデプロイする前に、選択したリージョンに応じて、Azure 可用性セットまたは可用性ゾーンのどちらを使用してデプロイするかを決定します。 可用性セットを使用してデプロイされた仮想マシンの主な違いは次のとおりです。

  • 仮想マシンが複数の可用性ゾーンに分散していない。
  • ホストは、セットにデプロイされた最初の仮想マシンによって定義されるため、1 つの可用性セットでデプロイできる仮想マシンの種類は制限されます。 1 つの例として、M シリーズと E シリーズの仮想マシンを 1 つの可用性セットに結合することはできません。

異なる可用性ゾーンに高可用性アーキテクチャをデプロイする利点は、VM のサービス レベル アグリーメント (SLA) を向上させることができる点です。 詳細については、Azure VM の SLAに関するページを参照してください。 Azure リージョンによっては、仮想マシン間のネットワーク トラフィックで異なるネットワーク待機時間が検出されることがあります。 詳細については、「Azure Availability Zones での SAP ワークロードの構成」を参照してください。

ゾーン デプロイ アプローチを選択する場合、選択した Azure リージョン、アプリケーション サーバーとデータベース間、2 つのデータベース ノード間のゾーン間待機時間がパフォーマンスとアーキテクチャ設計の選択に与える影響を考慮します。

アプリケーション サーバー層にアクティブまたはパッシブ ゾーンデプロイを使用する場合 (アプリケーション サーバーを同じ可用性ゾーン内のデータベースに接続する必要があります)、データベース フェールオーバーがある場合に迅速かつ自動化された復旧を可能にするために、自動化と SOP をビルドします。

SAP ソリューションで可用性ゾーンを使用する場合は、ゾーン冗長性のために SAP ランドスケープ内の他のすべての Azure サービスとインフラストラクチャ コンポーネントも設計して、真のゾーン冗長性を実現できるようにします。 考慮するサービスとコンポーネントの例としては、Azure ExpressRoute ゲートウェイ、Azure Load Balancer、Azure Files、Azure NetApp Files、リバース プロキシ、ファイアウォール、ウイルス対策、バックアップ インフラストラクチャがあります。

高可用性に関する設計上の推奨事項

  • Azure には、アプリケーションのインフラストラクチャ SLA を満たすのに役立つオプションがいくつか用意されています。 3 つの SAP コンポーネント (中央サービス、アプリケーション サーバー、およびデータベース) のすべてについて同じオプションを選択する必要があります。 VM、可用性セット、可用性ゾーンの SLA については、「Virtual Machines の SLA」を参照してください。

  • 可用性セットに VM を展開すると、障害ドメインおよび更新ドメインとの連携により、VM が同じホスト ハードウェア上に存在するのを防ぎ、ハードウェア障害に対する保護が提供されます。 可用性ゾーンを使用して VM をデプロイし、異なるゾーンを使用すると、VM は異なる物理的な場所に作成されます。 この構成により、ゾーン全体のデータセンターに影響を与える電力、冷却、またはネットワークの問題に対する保護を追加できます。 ただし、近接配置グループを使用しない場合、1 つの Azure 可用性ゾーン内に複数の Azure 可用性セットをデプロイすることはできません。

    ゾーン デプロイ アプローチを選択する場合、SAP DBMS、中央サービス、およびアプリケーション レイヤーは異なる可用性ゾーンで実行されます。 ただし、各可用性ゾーンには、多くの場合、複数のアプリケーション サーバーがあります。 このシナリオでは、各ゾーン内のアプリケーション サーバーは、障害ドメインと更新ドメインの恩恵を自動的に受けることはありません。 これらの利点を実現するには、SAP で最適なネットワーク待ち時間を実現するための Azure 近接配置グループに関するページの説明に従って可用性セットを使用します。

  • 可用性セットを作成する際には、使用可能な最大数の障害ドメインと更新ドメインを使用します。 たとえば、1 つの可用性セットに複数の VM をデプロイする場合、障害ドメインの最大数 (3) と十分な更新ドメインを使用して、Azure の計画メンテナンスに加えて、物理ハードウェア障害、ネットワークの停止、または停電の影響を制限します。 障害ドメインの既定の数は 2 であり、後でオンラインで変更することはできません。

  • 可用性セットのデプロイでは、SAP システムの各コンポーネントが独自の可用性セット内に存在する必要があります。 SAP 中央サービス、データベース、およびアプリケーション VM は、独自の可用性セット内に存在する必要があります。

  • 可用性セットのデプロイで Azure 近接配置グループを使用する場合、3 つの SAP コンポーネント (中央サービス、アプリケーションサーバー、データベース) はすべて同じ近接配置グループに存在する必要があります。

  • 近接配置グループを使用する場合は、SAP SID ごとに 1 つを使用します。 グループは、複数の可用性ゾーンまたは Azure リージョンにまたがっていません。

  • 可用性ゾーンのデプロイで Azure 近接配置グループを使用する場合、2 つの SAP コンポーネント (中央サービスとアプリケーションサーバー) はすべて同じ近接配置グループに存在する必要があります。 2 つのゾーン内のデータベース VM は、近接配置グループの一部ではなくなりました。 各ゾーンの近接配置グループのスコープは、SAP ASCS + SCS インスタンスを実行する VM のデプロイによって決まります。 この構成の利点は、VM のサイズをより柔軟に変更できることです。 また、DBMS レイヤーまたは SAP システムのアプリケーション レイヤーのいずれかで、新しい VM の種類に簡単に移行することもできます。

  • Azure では現在、1 つの Linux Pacemaker クラスターで ASCS とデータベースの高可用性を組み合わせることはサポートされていません。 これらは、個々のクラスターに分けます。 複数の中央サービス クラスターを最大 5 つまで 1 組の VM に結合できます。

  • ASCS およびデータベース クラスターの前に Standard Load Balancer の SKU を使用します。

  • すべての運用システムを Premium マネージド SSD 上で実行し、Azure NetApp Files または Ultra Disk Storage を使用します。 パフォーマンスを向上させ、SLA を最大限に高めるために、少なくとも OS ディスクは Premium レベルである必要があります。

  • 可用性セット内または可用性ゾーン内の高可用性ペアに、両方の VM をデプロイします。 これらの VM は同じサイズで、同じストレージ構成を持つ必要があります。

  • 高可用性ペアのデータベースを同期するには、ネイティブ データベース レプリケーションのテクノロジを使用します。

  • オペレーティング システムに応じて、次のいずれかのサービスを使用して SAP セントラル サービス クラスターを実行します。

  • 中央サービスおよびデータベース クラスターのドキュメントで推奨されるクラスターのタイムアウト パラメーターを設定します。

SAP ワークロードのストレージ

  • SAP ワークロードの回復性を考慮した設計の一環として、適切なストレージ オプションを選択する必要があります。 Azure ストレージ上の SAP ワークロードの設計は、待機時間を最小限に抑え、スループットを最大にすることを目的としています。 実装について、また以下のガイダンスが SAP on Azure 実装のアーキテクチャの決定にどのように役立つかについて検討します。 さまざまな種類のストレージと、SAP ワークロードおよびコンポーネントとの互換性については、「SAP ワークロードの Azure Storage の種類」を参照してください。

  • SAP HANA on Azure は、SAP によって認定されているストレージの種類でのみ実行する必要があります。 該当する場合、特定のボリュームは特定のディスク構成で実行する必要があることに注意してください。 これらの構成には、書き込みアクセラレータの有効化や Premium ストレージの使用が含まれます。 また、ストレージで実行されるファイル システムが、マシン上で実行される DBMS に対応していることを確認する必要があります。 詳細については、SAP HANA のストレージ構成に関するページを参照してください。

  • VM にアタッチされている Azure マネージド データ ディスクに加えて、さまざまな Azure ネイティブの共有ストレージ ソリューションが Azure での SAP アプリケーションの実行に使用されます。 Azure で利用できる一部のストレージ サービスは Azure Site Recovery でサポートされていないため、高可用性の構成が異なる場合があります。 SAP ワークロードには通常、次のストレージの種類が使用されます。

    ストレージの種類 高可用性構成のサポート
    Azure 共有ディスク (LRS または ZRS) Windows Server フェールオーバー クラスター。 構成の詳細については、Windows Server フェールオーバー クラスタリングを使用した SAP HA の設計に関する記事を参照してください。
    Azure Files 上の NFS (LRS または ZRS) Linux 環境の Pacemaker ベースのクラスター。 必ず、異なるリージョンでの NFS の可用性を確認してください。
    Azure NetApp Files 上の NFS Linux 環境の Pacemaker ベースのクラスター。 詳細については、SAP 仮想マシンの Azure NetApp Files に関するページを参照してください。
    Azure Files 上の SMB (LRS または ZRS) Windows Server フェールオーバー クラスター。 構成の詳細については、「SAP アプリケーションのための Azure Files Premium SMB を使用した Windows 上の Azure VM での SAP NetWeaver の高可用性」を参照してください。
    Azure NetApp Files 上の SMB Windows Server フェールオーバー クラスター。 構成の詳細については、「SAP アプリケーション用の Azure NetApp Files (SMB) を使用した Windows 上の Azure VM における SAP NetWeaver の高可用性」を参照してください。

  • Azure ネイティブの共有ストレージ サービスの代わりに、(DRBD レプリケーションに基づいた) 従来の NFS クラスター、GlusterFS、記憶域スペース ダイレクトを備えたクラスター共有ボリュームを、Azure 上で SAP ワークロードを実行する代替共有ストレージ ソリューションとして使用できます。 これらの選択肢は、Azure ネイティブの共有ストレージ サービスが、対象の Azure リージョンで使用できないか、ターゲット アーキテクチャをサポートしていない場合に特に役立ちます。 ストレージ サービスの可用性については、リージョン別の Azure 製品を参照してください。

  • Azure 上の SAP ワークロードに使用できるストレージ オプションについては、ディザスター リカバリーの設定に関するストレージの推奨事項とガイドラインを参照してください。

バックアップと復元

以降のセクションでは、SAP シナリオでのバックアップと復元に関する設計上の考慮事項と推奨事項について説明します。

通常、バックアップと復元は運用環境の SAP ワークロードに適した高可用性ソリューションとは見なされませんが、このテクノロジには他の利点があります。 SAP アプリケーションを使用するほとんどの企業は、バックアップの長期保存を義務付けたコンプライアンス規制に従う必要があります。 また、他のシナリオでは、バックアップを作成し、そのバックアップから復元できることも不可欠です。 SAP アプリケーションのバックアップと復元のベスト プラクティスが既に確立されており、それに従っていることが前提となります。つまり、次のことが可能である必要があります。

  • RTO を満たす概算時間内の任意の時点で、運用データベースのポイントインタイム リストアを実行する。 ポイントインタイム リストアでは、通常、DBMS レイヤー上のデータまたは SAP を介したデータの削除などのオペレーター エラーを防ぐことができます。

  • コンプライアンス規制を満たすために、長期的なバックアップを保持するためのストアを維持する。

  • データベース バックアップを使用して SAP システムを複製し、別のサーバーまたは VM にバックアップを復元します。

  • データベース バックアップからの実稼働データベース データを使用して、実稼働前システムを更新します。

  • SAP アプリケーション サーバーと仮想マシン、ディスク、または VM スナップショットをバックアップします。

オンプレミスでバックアップおよび復元する場合は、これらの機能を Azure の SAP システムに取り込む必要があります。

現在のソリューションに問題がなければ、バックアップ ベンダーが Azure のデプロイをサポートしているかどうか、または Azure 用のサービスとしてのソフトウェア (SaaS) ソリューションがあるかどうかを確認します。

Azure には、バックアップ SaaS サービスである Azure Backup が用意されています。これは VM のスナップショットを取得し、SQL Server と SAP HANA のストリーミング バックアップを管理します。 Azure NetApp Files を使用して SAP HANA データベースを格納している場合は、HANA 整合ストレージのスナップショットに基づいてバックアップを実行できます。

バックアップと復元に関する設計上の推奨事項

  • Azure Backup を使用して、SAP アプリケーション サーバーと中央サービス VM をバックアップすることができます。

  • SAP HANA バックアップは、最大 8 TB までの HANA デプロイに使用できます。 詳細については、Azure VM 上の SAP HANA データベースのバックアップに関するサポート マトリックスを参照してください。

  • IaaS バックアップ ソリューションを使用する場合は、バックアップ インフラストラクチャのサイズを設定して、すべての運用規模のシステムを同時に、または実際のシナリオと同様に、予想される時間枠内で、ネットワーク、セキュリティなどの観点から、運用セットアップまたは同様のセットアップを使用して、確実にバックアップできるようにします。

  • バックアップと復旧の時間をテストして、障害発生後にすべてのシステムを同時に復元するための RTO 要件を満たしていることを確認します。

  • 理想的には、(特に大規模なデータベースの場合) Azure からオンプレミスのバックアップ インフラストラクチャにバックアップをプルすることは避けてください。 それを行うと、ExpressRoute 回線で使用される帯域幅に影響します。

  • パフォーマンス テスト計画の一環として、バックアップ ツールと回復ツールをロード テストします。

障害復旧

以降のセクションでは、SAP シナリオでのディザスター リカバリーに関する設計上の考慮事項と推奨事項について説明します。

ディザスター リカバリーの設計上の考慮事項

Azure リージョン マップには、65 を超える Azure リージョンが表示されていますが、それらのすべてが同じサービスを実行するわけではありません。 大規模な SAP ソフトウェア デプロイ (特に SAP HANA を使用するもの) 向けには、Azure M シリーズや 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 機能を使用して、レプリケーションを実行します。 SAP アプリケーション レイヤーには、Site Recovery、rsync または robocopy、その他のサードパーティ製ソフトウェアを組み合わせて使用します。

  • 障害が発生した場合、Azure リージョン内の影響を受けた複数の顧客は、対応するペアの DR リージョンにフェールオーバーする必要があります。 この状況により、DR リージョンで休止中の VM を起動するためにリソースの競合が発生します。 回避策は、DR リージョンで非運用システムを実行し、同じリソースを使用して運用システムの DR レプリカをホストすることです。 DR リージョンで Azure インフラストラクチャをこの二重目的で使用すると、リソース容量の制約を回避できます。

もう 1 つの重要な考慮事項は、障害リージョンで必要な運用容量を確保することです。 障害が発生した場合は、プライマリ リージョンでの通常の運用の復旧に取り組んでいる間のみ不可欠な人材によって最小限の IT 容量で最短期間 SAP アプリケーションを実行することが必要になることがあります。 これには、DR リージョンで使用できる最小限の IT インフラストラクチャが必要です。

Azure リージョンを定義したら、デプロイ パターンを選択する必要があります。

  • 運用システムをプライマリ リージョンにデプロイする場合。
  • 非運用 SAP システムをディザスター リカバリー リージョンにデプロイする場合。
  • すべての SAP システムをプライマリ リージョンにグループ化するアーキテクチャを使用する場合。 この構成により、ディザスター リカバリー リージョンがディザスター リカバリーにのみ使用されるようになります。

ほとんどの組織では、両方のリージョンを稼働中の SAP システムに使用しています。 運用システムの完全なコピーをビジネス回帰テスト システムとして実行している組織は、通常、SAP 製品ラインのビジネス回帰テスト システムをディザスター リカバリーのターゲットとして使用することを計画しています。

ディザスター リカバリー リージョンを選ぶときは、そのリージョンに ExpressRoute 接続ができることを確認してください。 Azure に接続する ExpressRoute 回線が複数ある場合は、それらの回線の少なくとも 1 つがプライマリ Azure リージョンに接続している必要があります。 残りは、ディザスター リカバリー リージョンに接続する必要があります。 この種類のアーキテクチャでは、ユーザーは別の地理的または地政学的地域にある Azure ネットワークに接続されるため、大災害の影響が Azure リージョンのいずれかに及ぶ場合、接続が保護されます。

一部の組織は、高可用性とディザスター リカバリーを組み合わせたアーキテクチャを使用しています。これは、高可用性とディザスター リカバリーを同じ Azure リージョンにグループ化したものです。 しかし、高可用性とディザスター リカバリーをグループ化することは理想的ではありません。 Azure Availability Zones では、このアーキテクチャがサポートされています。 1 つの Azure リージョン内の可用性ゾーン間の距離は、2 つの Azure リージョン間の距離ほど大きくないため、自然災害によって、それが発生したリージョン内のアプリケーション サービスが危険にさらされる可能性があります。 また、SAP アプリケーション サーバーとデータベース サーバー間の待機時間も考慮する必要があります。 SAP Note 1100926 によると、0.3 ms 以下のラウンドトリップ時間が適切な値であり、0.7 ms 以下の時間は並みの値です。 そのため、待機時間が長いゾーンでは、SAP アプリケーション サーバーとデータベース サーバーが常に同じゾーンで実行されるように、運用手順を実施する必要があります。 組織は次のような理由でこのアーキテクチャを選びます。

  • コンプライアンスは、運用環境のデプロイとディザスター リカバリーのターゲットの間の距離が短い場合をサポートする構成で十分である。
  • データ主権が要因である。
  • 地政学的要因が関係している。
  • これは、ゾーンでの失敗をサポートする低コストのオプションであり、影響の範囲が大きい自然災害向けにセカンダリ リージョンへのバックアップ転送と組み合わせることがある。

ディザスター リカバリー リージョンを選ぶ際に考慮する必要があるもう 1 つの要因は、ディザスター リカバリー サイトにフェールオーバーするための RPO と RTO です。 運用リージョンとディザスター リカバリー リージョンの間の距離が離れているほど、ネットワーク待機時間は長くなります。 Azure リージョン間で非同期にレプリケートしますが、ネットワーク待機時間は、レプリケートできるスループットと RPO ターゲットに影響を与える可能性があります。 多くの場合、高可用性とディザスター リカバリー アーキテクチャの組み合わせを使用することで、RPO を最小限に抑えることができます。 ただし、この構成では、大規模な自然災害によるリスクが高くなる可能性があります。

ディザスター リカバリーの設計上の推奨事項

  • プライマリ仮想ネットワークのクラスレス ドメイン間ルーティング (CIDR) が、確実にディザスター リカバリー サイトの仮想ネットワークの CIDR と競合または重複しないようにします。
  • オンプレミスからプライマリとセカンダリの Azure ディザスター リカバリー リージョンへの ExpressRoute 接続を設定します。
  • ExpressRoute を使用する代わりに、オンプレミスからプライマリおよびセカンダリの Azure ディザスター リカバリー リージョンへの VPN 接続を設定することを検討します。
  • Site Recovery を使用して、アプリケーション サーバーをディザスター リカバリー サイトにレプリケートします。 また、Site Recovery は、中央サービス クラスター VM をディザスター リカバリー サイトにレプリケートする場合にも役立ちます。 ディザスター リカバリーを呼び出す場合は、ディザスター リカバリー サイトで Linux Pacemaker クラスターを再構成する必要があります。 たとえば、VIP や SBD を置き換えたり、corosync.conf を実行したりする必要があります。
  • 証明書、シークレット、キーなどのキー コンテナーの内容をリージョン間でレプリケートして、DR リージョン内のデータの暗号化を解除できるようにします。
  • Azure NetApp Files でリージョン間レプリケーション (現在パブリック プレビュー中) を使用して、プライマリ リージョンとディザスター リカバリー リージョンの間でファイル ボリュームを同期します。
  • Site Recovery ではなく、ネイティブ データベース レプリケーションを使用して、データをディザスター リカバリー サイトに同期します。
  • プライマリとディザスター リカバリーの仮想ネットワークをピアリングします。 たとえば、HANA システム レプリケーションの場合、SAP HANA DB 仮想ネットワークをディザスター リカバリー サイトの SAP HANA DB 仮想ネットワークとピアリングする必要があります。
  • SAP デプロイに Azure NetApp Files ストレージを使用する場合は、少なくとも 2 つのリージョンで Premium レベルの 2 つの Azure NetApp Files アカウントを作成します。
  • アプリケーションのパフォーマンスを踏まえて、ビジネスの重要性と近接依存性に基づきシステムをグループ化することを検討してください。 リージョンの障害によるビジネスへの影響を最小限に抑えるため、各グループをペア リージョン構成で別のリージョンにデプロイします。 たとえば、2 つの異なる部署にサービスを提供する 2 つの重要な ECC システムを英国南部と英国西部にデプロイすることで、リージョンの障害による影響を最小限に抑えることができます。

次のステップ

Azure での SAP 用デプロイ オプション