次の方法で共有

SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャ のガイドライン

  • [アーティクル]

Azure で重要なビジネス アプリケーションを実行している多くの組織は、高可用性 (HA) とディザスター リカバリー (DR) の両方の戦略を設定しています。 高可用性の目的は、基になるシステム インフラストラクチャの単一障害点を取り除いて、ビジネス システムの SLA を向上させることです。 高可用性テクノロジは、計画外のインフラストラクチャ障害の影響を減らし、計画メンテナンスに役立ちます。 ディザスター リカバリーは、地理的に広範な自然災害や人為的な災害が発生した後も、重要なテクノロジ インフラストラクチャおよびシステムの復旧または継続動作を可能にする一連のポリシー、ツール、手順として定義されます。

Azure 上の SAP ワークロードの高可用性を実現するには、通常、可用性セット、可用性ゾーンまたはフレキシブル スケール セットに仮想マシンをデプロイして、リージョン内のインフラストラクチャのメンテナンスや障害からアプリケーションを保護します。 ただし、デプロイによって、リージョン内の広範囲の災害からアプリケーションが保護されることはありません。 そのため、リージョンの障害からアプリケーションを保護するには、アプリケーションのディザスター リカバリー戦略を設ける必要があります。 ディザスター リカバリーは文書化されて構造化されたアプローチであり、組織が障害に対応して復旧プロセスを実行するのを支援し、IT サービスの中断を防ぐか最小限に抑え、復旧を促進するように設計されています。

このドキュメントでは、構造化 DR アプローチを実装することで、大規模な災害から SAP ワークロードを保護する方法について詳しく説明します。 このドキュメントの詳細は、さまざまな Azure サービスと SAP コンポーネントに基づいて、抽象レベルで説明されています。 SAP ワークロードの正確な DR 戦略と復旧順序をテストし、文書化して、定期的に微調整する必要があります。 また、このドキュメントでは、Azure と Azure の間での SAP ワークロードの DR 戦略に焦点を当てています。

ディザスター リカバリー計画に関する一般的な考慮事項

Azure 上の SAP ワークロードは、さまざまな Azure サービスと組み合わせて仮想マシンで実行され、一般的な SAP NetWeaver アプリケーションの異なるレイヤー (セントラル サービス、アプリケーション サーバー、データベース サーバー) をデプロイします。 一般に、Azure で実行されている IT ランドスケープ全体に対して DR 戦略を計画する必要があり、これは SAP 以外のアプリケーションも考慮する必要があることを意味します。 依存するサービスまたは資産が DR サイトで復旧されない場合、SAP システムで実行されているビジネス ソリューション全体が実行されない可能性があります。 そのため、すべてのコンポーネントとシステムが考慮されている、明確に定義された包括的な DR プランを用意する必要があります。

Azure での DR の場合、組織はフェールオーバーをトリガーする可能性のあるさまざまなシナリオを検討する必要があります。

  • SAP アプリケーションまたはビジネス プロセスの可用性。
  • 広範囲の障害のために利用できないリージョン内の Azure サービス (仮想マシン、ストレージ、ロード バランサーなど)。
  • アプリケーションに対する潜在的な脅威と脆弱性 (アプリケーション 層の DDoS 攻撃など)
  • DR 戦略のテストに関するビジネス コンプライアンスで必要な運用タスク (たとえば、コンプライアンスに従って毎年 DR エラーの演習を実行する必要があります)。

さまざまなシナリオで復旧目標を達成するには、組織は、ビジネス要件に基づいてワークロードの目標復旧時間 (RTO) と目標復旧時点 (RPO) の概要を示す必要があります。 RTO は、アプリケーションをダウンさせておくことができる時間の長さであり、通常は時間、分、または秒で測定します。 一方、RPO は、通常の操作を再開するためにビジネスで失われてもかまわないトランザクション データの量を示します。 DR 戦略を最適に設計するのに役立つので、ビジネスの RTO と RPO を明らかにすることは非常に重要です。 SAP ワークロードに関連するコンポーネント (コンピューティング、ストレージ、データベースなど) は、さまざまな手法 (Azure ネイティブ サービス、ネイティブ DB レプリケーション テクノロジ、カスタム スクリプト) を使って DR リージョンにレプリケートされます。 提供される RPO は手法ごとに異なり、DR 戦略を設計するときにそれを考慮する必要があります。 Azure では、SAP ワークロードの RTO と RPO を満たすのに役立つ Azure Site Recovery や Azure Backup などのいくつかの Azure ネイティブ サービスを使用できます。 RTO と RPO に最適に合わせるには、Azure Site Recovery と Azure Backup の SLA に関するページを参照してください。

Azure でのディザスター リカバリーに関する設計上の考慮事項

Azure でのディザスター リカバリー ソリューションを設計するときは、さまざまな要素を考慮する必要があります。 オンプレミスのディザスター リカバリー ソリューションを設計するときに考慮する原則と概念は、Azure にも適用されます。 ただし、Azure では、リージョンの選択がディザスター リカバリーの設計戦略において重要な部分です。 そのため、Azure で DR リージョンを選ぶときは、次の点に注意してください。

  • ビジネスまたは規制のコンプライアンス要件では、プライマリ サイトとディザスター リカバリー サイトの間の距離の要件が指定されている場合があります。 距離の要件は、地理的に広い範囲で自然災害が発生した場合に可用性を確保するのに役立ちます。 このような場合、組織はディザスター リカバリー サイトとして別の Azure リージョンを選択できます。 Azure リージョン間は、多くの場合、大きく離れています (米国のように数百または数千キロメートル)。 距離が長いため、ネットワーク ラウンドトリップの待ち時間が長くなり、RPO が大きくなる可能性があります。

  • Azure 上でもオンプレミスのメトロ DR 戦略のようにしたいお客様は、ディザスター リカバリーに可用性ゾーンを使用できます。 ただし、地理的に広範囲に及ぶ自然災害の場合、ゾーン間 DR 戦略では回復性の要件が満たされないことがあります。

  • Azure では、各リージョンは同じ地域内の別のリージョンとペアになっています (ブラジル南部を除く)。 このアプローチにより、プラットフォームでリージョン間のリソースのレプリケーションを提供できます。 ペアになったリージョンを選ぶ利点については、リージョンのペアに関するドキュメントをご覧ください。 組織が Azure のペアになったリージョンの使用を選ぶ場合は、SAP ワークロードに関してさらに考慮する必要のあるポイントがいくつかあります。

    • ペアのリージョンでのリージョン間レプリケーションは、すべての Azure サービスで提供されているわけではありません。

    • ペアの Azure リージョンでの Azure サービスと機能は、対称的でない場合があります。 たとえば、Azure NetApp Files や M シリーズなどの VM SKU は、プライマリ リージョンでは使用できても、ペアのリージョンでは使用できない場合があります。 Azure 製品またはサービスをあるリージョンで利用できるかどうかを調べるには、「リージョン別の利用可能な製品」をご覧ください。

    • GRS オプションは、ペアのリージョンにデータをレプリケートする Standard Storage の種類のストレージ アカウントで使用できます。 ただし、Standard Storage は SAP DBMS や仮想データ ディスクには適していません。

    • サポートされるソリューションのバックアップに使われる Azure Backup サービスは、ペアのリージョン間でのみバックアップをレプリケートできます。 他のすべてのデータについては、SQL Server Always On、SAP HANA システム レプリケーション、その他のサービスなどのネイティブ DBMS 機能を使用して、独自のレプリケーションを実行します。 SAP アプリケーション レイヤーには、Azure Site Recovery、rsync、または robocopy と、他のサードパーティ製ソフトウェアを組み合わせて使います。

参照 SAP ワークロードのデプロイ

DR リージョンを決定した後は、プライマリ リージョンで構成したさまざまな Azure コア サービス (ネットワーク、コンピューティング、ストレージなど) が、DR リージョンで利用可能であり、構成できることが重要です。 組織は、SAP ワークロード向けの DR デプロイ パターンを開発する必要があります。 デプロイ パターンは、組織のニーズによって異なり、それに合わせる必要があります。

  • 運用 SAP ワークロードをプライマリ リージョンにデプロイし、非運用ワークロードをディザスター リカバリー リージョンにデプロイします。
  • すべての SAP ワークロード (運用と非運用) をプライマリ リージョンにデプロイします。 ディザスター リカバリー リージョンは、フェールオーバーが行われる場合にのみ使われます。

次の参照アーキテクチャは、高可用性のプライマリ リージョンの Azure で実行されている一般的な SAP NetWeaver システムを示したものです。 次に示すセカンダリ サイトはディザスター リカバリー サイトであり、障害イベントの後でそこに SAP システムが復元されます。 プライマリ リージョンとディザスター リカバリー リージョンはどちらも同じサブスクリプションの一部です。 SAP ワークロードの DR を実現するには、アプリケーションで使われるさまざまな Azure サービスと共に、各 SAP レイヤーの復旧戦略を特定する必要があります。

組織は、IT ランドスケープ全体の観点で DR 戦略を計画および設計する必要があります。 通常、運用環境で実行されている SAP システムは、Active Directory、DNS、サードパーティ アプリケーションなどのさまざまなサービスやインターフェイスと統合されます。 そのため、ディザスター リカバリー計画にも SAP 以外のシステムや他のサービスを含める必要があります。 このドキュメントの焦点は、SAP アプリケーションの復旧計画です。 ただし、要件に合わせて依存コンポーネントまで DR 計画の規模と範囲を広げることができます。

SAP ワークロード向けのディザスター リカバリー参照アーキテクチャ

SAP ワークロード向け DR ソリューションのインフラストラクチャ コンポーネント

Azure で実行されている SAP ワークロードでは、ビジネス ソリューションを実行するためにさまざまなインフラストラクチャ コンポーネントが使われます。 そのようなソリューションのための DR を計画するには、プライマリ リージョンで構成されているすべてのインフラストラクチャ コンポーネントを、DR リージョンでも使用でき、構成できることが不可欠です。 Azure 上の SAP ワークロード用の DR ソリューションを設計するときは、次のインフラストラクチャ コンポーネントを考慮する必要があります。

  • ネットワーク
  • Compute
  • ストレージ

ネットワーク

  • ExpressRoute は、接続プロバイダーが提供するプライベート接続を介して、オンプレミスのネットワークを Microsoft クラウドに拡張します。 ディザスター リカバリー アーキテクチャの設計では、geo 冗長 ExpressRoute 回線を使って堅牢なバックエンド ネットワーク接続を構築することを考慮する必要があります。 オンプレミスからプライマリ リージョンに少なくとも 1 つの ExpressRoute 回線を設定し、もう 1 つの ExpressRoute 回線をディザスター リカバリー リージョンに接続することをお勧めします。 ExpressRoute のディザスター リカバリーを設計するさまざまなシナリオについては、ディザスター リカバリーのための Azure ExpressRoute の設計に関する記事をご覧ください。

    Note

    Azure ExpressRoute のバックアップとして、サイト間 (S2S) VPN を設定することを検討します。 詳しくは、「ExpressRoute プライベート ピアリングのバックアップとしてのサイト間 VPN の使用」をご覧ください。

  • 仮想ネットワークとサブネットは、リージョン内のすべての可用性ゾーンにまたがっています。 2 つのリージョンにまたがる DR の場合は、ディザスター リカバリー リージョンで個別に仮想ネットワークとサブネットを構成する必要があります。 DR リージョンでのネットワークの設定について詳しくは、「Azure VM ディザスター リカバリーのネットワークについて」をご覧ください。

  • Azure Standard Load Balancer では、SAP システムの高可用性設計にネットワーク要素を提供します。 クラスター化システムの場合、Standard Load Balancer により、ASCS/SCS インスタンスや、VM 上で実行されているデータベースなど、クラスター サービスの仮想 IP アドレスが提供されます。 DR サイトで高可用性の SAP システムを実行するには、個別にロード バランサーを作成し、それに応じてクラスター構成を調整する必要があります。

  • Azure Application Gateway は、Web トラフィックのロード バランサーです。 その Web Application Firewall 機能により、セキュリティを強化して Web アプリケーションをインターネットに公開するのに適したサービスです。 Azure Application Gateway は、構成に応じて、パブリック (インターネット)、プライベート クライアント、またはその両方にサービスを提供できます。 フェールオーバーの後、DR リージョンで同様の着信 HTTPs トラフィックを受け入れるには、DR リージョンで別に Azure Application Gateway を構成する必要があります。

  • ネットワーク コンポーネント (仮想ネットワーク、ファイアウォールなど) を DR リージョンで個別に作成するため、DR リージョンの SAP ワークロードが、DNS 更新やファイアウォールなどのネットワーク変更に適合していることを確認する必要があります。

  • 両方のリージョンの仮想ネットワークは独立しており、2 つの間の通信を確立するには、2 つのリージョンの間で仮想ネットワーク ピアリングを有効にする必要があります。

仮想マシン

  • Azure では、1 つの SAP システムの異なるコンポーネントが、異なる SKU の種類を使用する仮想マシン上で実行されます。 DR の場合、Azure VM で実行されているアプリケーション (SAP NetWeaver および SAP 以外) の保護を有効にするには、Azure Site Recovery を使って別の Azure リージョンまたはゾーンにコンポーネントをレプリケートします。 Azure Site Recovery により、Azure VM はプライマリからディザスター リカバリー サイトに継続的にレプリケートされます。 選択した Azure DR リージョンによっては、DR サイトで VM SKU の種類を使用できない場合があります。 必要な VM SKU の種類が Azure DR リージョンでも使用できることを確認する必要があります。 必要な VM ファミリの SKU の種類を使用できるかどうか確認するには、「リージョン別の利用可能な製品」をご覧ください。

    重要

    SAP システムに FD=1 のフレキシブル スケール セットが構成されている場合は、PowerShell を使用してディザスター リカバリー用に Azure Site Recovery を設定する必要があります。 現時点では、それが、スケール セットにデプロイされた VM のディザスター リカバリーの構成に使用できる唯一の方法です。

  • Azure 仮想マシンで実行されているデータベースの場合は、ネイティブ データベース レプリケーション テクノロジを使って、ディザスター リカバリー サイトにデータを同期することをお勧めします。 データベースが実行されている大規模な VM は、リージョンによっては使用できないことがあります。 ディザスター リカバリーに可用性ゾーンを使っている場合は、ディザスター リカバリー サイトのゾーンでそれぞれの VM SKU を使用できることを確認する必要があります。

    注意

    Azure Site Recovery は、DB の一貫性を保証せず、データ チャーンの制限があるため、データベースに使うことはお勧めしません。

  • 運用アプリケーションが常にプライマリ リージョンで実行されている場合は、一般に予約インスタンスが Azure のコストを節約するために使われます。 予約インスタンスを使っている場合、DR サイトでのコスト効率が低い可能性がある 1 年間または 3 年間の期間コミットメントにサインアップする必要があります。 また、Azure Site Recovery を設定すると、フェールオーバーの間に必要な VM SKU の容量は保証されません。 VM SKU の容量を確実に使用できるようにするには、オンデマンド容量予約を有効にするオプションを検討できます。 それにより、Azure リージョンまたは Azure 可用性ゾーンのコンピューティング容量が、コミットメントなしで任意の期間予約されます。 Azure Site Recovery は、オンデマンド容量予約と統合されます。 この統合により、Azure Site Recovery で容量予約の機能を使って、DR サイトのコンピューティング容量を予約し、フェールオーバーを保証できます。 詳しくは、オンデマンド容量予約の「制限事項と制約事項」をご覧ください。

  • Azure サブスクリプションには、VM ファミリ (Mv2 ファミリなど) と他のリソースのためのクォータがあります。 組織は DR に異なる Azure サブスクリプションを使いたい場合があります。 各サブスクリプション (プライマリと DR) には、VM ファミリごとに異なるクォータが割り当てられている場合があります。 DR サイトに使われているサブスクリプションに十分なコンピューティング クォータがあることを確認します。

ストレージ

  • DR を設定するために VM で Azure Site Recovery を有効にすると、VM にアタッチされているローカル マネージド ディスクが DR リージョンにレプリケートされます。 レプリケーション中、VM ディスクへの書き込みは、ソース リージョンのキャッシュ ストレージ アカウントに送信されます。 データは、そこからターゲット リージョンに送信され、そのデータから復旧ポイントが生成されます。 DR の間に VM をフェールオーバーすると、復旧ポイントを使用してターゲット リージョンに VM が復元されます。 ただし、Azure Site Recovery では、Azure で使用可能なすべてのストレージの種類がサポートされているわけではありません。 詳しくは、Azure Site Recovery によるストレージのサポート マトリックスに関する記事をご覧ください。

  • Azure 共有ディスクを使用して Windows 上で実行されている SAP システムの場合、Azure 共有ディスクを使用した Azure Site Recovery (プレビュー) を使用できます。 この機能はパブリック プレビュー段階であるため、最も重要な SAP 運用ワークロードのシナリオを実装することはお勧めしません。 Azure 共有ディスクでサポートされるシナリオの詳細については、Azure VM ディザスター リカバリーでの共有ディスクのサポート マトリックス (プレビュー) に関するページを参照してください

  • VM にアタッチされている Azure マネージド データ ディスクに加えて、Azure で SAP アプリケーションを実行するには、さまざまな Azure ネイティブ ストレージ ソリューションが使われます。 Azure で使用可能なすべてのストレージ サービスが Azure Site Recovery でサポートされているわけではないので、各 Azure ストレージ ソリューションの DR アプローチは異なる場合があります。 SAP ワークロードに通常使われるストレージの種類の一覧を次に示します。

    ストレージの種類 DR 戦略に関する推奨事項
    マネージド ディスク Azure Site Recovery
    Azure Files 上の NFS (LRS または ZRS) 2 つのサイト間でデータをレプリケートするカスタム スクリプト (rsync など)
    Azure NetApp Files 上の NFS Azure NetApp Files ボリュームのリージョン間レプリケーションを使う
    Azure 共有ディスク (LRS または ZRS) Azure 共有ディスクを使用した Azure Site Recovery (プレビュー)
    Azure Files 上の SMB (LRS または ZRS) RoboCopy を使用して 2 つのサイト間でファイルをコピーする
    Azure NetApp Files 上の SMB Azure NetApp Files ボリュームのリージョン間レプリケーションを使う

  • NFS クラスターのようなカスタム構築ストレージ ソリューションの場合は、適切な DR 戦略を設ける必要があります。

  • さまざまなネイティブ Azure ストレージ サービス (Azure Files、Azure NetApp Files など) は、すべてのリージョンで使用できるとは限りません。 そのため、フェールオーバー後に DR リージョンで同様の SAP セットアップを行う場合は、それぞれのストレージ サービスが DR サイトで提供されていることを確認します。 詳しくは、「リージョン別の利用可能な製品」をご覧ください。

  • プライマリ リージョンで Azure Files のゾーン冗長ストレージ (ZRS) と Azure 共有ディスクを使用していて、DR リージョンでも同じ ZRS 冗長オプションを維持する場合は、[Premium ファイル共有 ZRS のサポート](Premium ファイル共有向けの Azure Files ゾーン冗長ストレージ (ZRS) のサポート | Microsoft Learn) と、Azure リージョンでの ZRS サポートに関するマネージド ディスクの ZRS のドキュメントを参照してください。

  • ディザスター リカバリーに可用性ゾーンを使う場合は、次の点に注意してください。

    • Azure NetApp Files 機能は、ゾーンにはまだ対応していません。 現在、Azure NetApp Files 機能は、Azure リージョン内のすべての可用性ゾーンにはデプロイされていません。 そのため、DR 戦略用に選んだ可用性ゾーンで、Azure NetApp Files サービスを使えない場合があります。
    • Azure NetApp Files ボリュームのリージョン間レプリケーションは、ゾーン間ではなく、固定のリージョン ペアでのみ使用できます。

  • Active Directory 統合を使ってストレージを構成した場合は、DR サイトのストレージ アカウントでも同様のセットアップを行う必要があります。

次のステップ