サイトの回復の詳細を確認する

  • 12 分

SQL Server のディザスター リカバリー

SQL Server を使うときにディザスター リカバリーを支援するために、異なるリージョンの Azure VM で Always On 可用性グループを構成できます。詳細については、「異なる Azure リージョン間で SQL Server Always On 可用性グループを構成する」を参照してください。 また、ディザスター リカバリー機能を実現する構成として他によく使われるのが、ログ配布です。

Oracle のディザスター リカバリー

Oracle Data Guard は、ディザスター リカバリーの目的でサポートされています。 Data Guard で自動フェールオーバーを実現するには、ファスト スタート フェールオーバー (FSFA) を使用することが必要です。 オブザーバー (FSFA) によってフェールオーバーがトリガーされます。 FSFA を使用しない場合は、手動フェールオーバー構成のみを使用できます。

Azure Site Recovery

Azure Site Recovery Services は、オンプレミス リソースのディザスター リカバリー (DR) フェールオーバーとフェールバックを調整する包括的なディザスター リカバリー スイートです。 Azure Site Recovery では、Enterprise-2-Enterprise (E2E) シナリオと Enterprise-2-Cloud (E2C) シナリオを調整できます。 また、Site Recovery はほとんどのオンプレミス ディザスター リカバリー ソリューションよりも優れた機能で、競合するソリューションよりも低い総保有コスト (TCO) です。

Site Recovery を使用して、次のシナリオのディザスター リカバリー ソリューションを実装できます。

  • ある Azure データセンターで実行されている SAP システムを、別の Azure データセンターにレプリケートします (Azure 間の ディザスター リカバリー)。
  • VMware (または物理) サーバーのオンプレミス上で実行されている SAP システムを、Azure データセンターのディザスター リカバリー サイトにレプリケートします (VMware から Azure へのディザスター リカバリー)。
  • Hyper-V のオンプレミス上で実行されている SAP システムを、Azure データセンターのディザスター リカバリー サイトにレプリケートします (Hyper-V から Azure へのディザスター リカバリー)。

このソリューションは、次の基盤サービスに依存しています。

  • Azure ExpressRoute または Azure VPN Gateway
  • Azure で実行されている少なくとも 1 つの Active Directory ドメイン コントローラーと DNS サーバー

Azure Site Recovery は SAP アプリケーションに対するテストを実施したうえで統合済みです。 Site Recovery を使用すると、次のことができます。

  • コンポーネントを Azure にレプリケートして、オンプレミスで実行される SAP NetWeaver および非 NetWeaver 運用アプリケーションの保護を有効にします。
  • コンポーネントを他の Azure データセンターにレプリケートして、Azure で実行される SAP NetWeaver および非 NetWeaver 運用アプリケーションの保護を有効にします。
  • Site Recovery を使用して SAP デプロイを Azure に移行することで、クラウド移行を簡略化します。
  • SAP アプリケーションをテストするためのオンデマンドの運用クローンを作成して、SAP プロジェクトのアップグレード、テスト、およびプロトタイプ作成を簡略化します。

次のメカニズムを実装して、SAP デプロイの個別の層を保護する必要があります。

SAP 層

推奨

SAP Web Dispatcher プール

Site Recovery を使ったレプリケーション

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

Site Recovery を使ったレプリケーション

SAP セントラル サービス クラスター

Site Recovery を使ったレプリケーション

Active Directory 仮想マシン

Active Directory レプリケーションを使用する

SQL Database サーバー

SQL Always On レプリケーションを使用する

Azure Site Recovery を使用して、ご自身の元のサイトが完全にレプリケートされた運用サイトを自動的に構築するには、カスタマイズされたデプロイ スクリプトを実行する必要があります。 通常、Site Recovery では VM が可用性セットにデプロイされ、次にスクリプトの実行でロード バランサーなどのリソースが追加されます。 SAP デプロイの場合、詳細はサービスによって異なります。

  • SAP Web Dispatcher プール: Web Dispatcher コンポーネントは、SAP アプリケーション サーバー間の SAP トラフィックのロード バランサーとして使われます。 Web Dispatcher コンポーネントの高可用性を実現するために、Azure ロード バランサーを使って、バランサー プールの利用可能な Web Dispatcher 間で HTTP(S) トラフィックを分散するラウンド ロビン構成で並列 Web Dispatcher のセットアップが実装されます。 実際には、VM は Azure Site Recovery (ASR) を使ってレプリケートされ、自動化スクリプトによりディザスター リカバリー リージョンでロード バランサーが構成されます。
  • SAP アプリケーション サーバー プール: ABAP アプリケーション サーバーのログオン グループの管理には、SMLG トランザクションが使われます。 この場合、セントラル サービスのメッセージ サーバー内の負荷分散機能を使って、SAPGUI および RFC トラフィックの SAP アプリケーション サーバーのプールにワークロードが分散されます。 実際には、ロード バランサーのプロビジョニングを必要とせずに、Azure Site Recovery を使って VM がレプリケートされます
  • SAP セントラル サービス クラスター: セントラル サービスは、アプリケーション層の VM 上で実行されます。 セントラル サービスは、単一の VM にデプロイされた場合に、単一障害点 (SPOF) になる可能性があります。 高可用性ソリューションを実装するには、共有ディスク クラスターまたはファイル共有クラスターを使って共有ディスク クラスターの VM を構成し、Windows Server フェールオーバー クラスターを利用します。 クォーラム監視としてクラウド監視をお勧めします。 Azure Site Recovery ではクラウド監視をレプリケートしないため、ディザスター リカバリー リージョンにクラウド監視をデプロイすることをお勧めします。 フェールオーバー クラスター環境をサポートするために、SIOS DataKeeper クラスター エディションでは、クラスター ノードが所有する独立したディスクをレプリケートすることによって、クラスターの共有ボリューム機能が実行されます。 Azure では共有ディスクがネイティブでサポートされていないため、SIOS 提供のソリューションが必要です。 ファイル共有クラスターを実装してクラスタリングを処理することもできます。 SAP では、UNC パスを介して /sapmnt グローバル ディレクトリにアクセスするための、セントラル サービス デプロイ パターンを最近変更しました。 ただし、/sapmnt UNC 共有に高可用性を確保することは引き続き推奨されます。 セントラル サービス インスタンスでこれを実現するには、Windows Server フェールオーバー クラスターと、Windows Server 2016 のスケールアウト ファイル サーバー (SOFS) および記憶域スペース ダイレクト (S2D) 機能を使用します。 Azure Site Recovery では、現時点で、記憶域スペース ダイレクトと SIOS DataKeeper のパッシブ ノードを使った仮想マシンのクラッシュ整合性ポイント レプリケーションのみがサポートされています。

Azure Site Recovery を使って Azure リージョン全体での SAP デプロイのディザスター リカバリーを実装する場合は、次の一連の手順を行います。

  1. 仮想マシンのレプリケート
  2. 復旧ネットワークを設計する
  3. ドメイン コントローラーをレプリケートする
  4. データベース層をレプリケートする
  5. テスト フェールオーバーの実行
  6. フェールオーバーの実行

Note

このコンテンツを作成する時点では、Azure VM での高速ネットワーク構成設定のレプリケーションは、まだ ASR でサポートされていません。