Azure での SAP HANA システムのディザスター リカバリー

2019年10月29日 に投稿済み

Cloud Solution Architect

このブログ記事では、SAP S/4HANA ランドスケープによってクラス最高の回復ポイントの目標 (RPO) と回復時間の目標 (RTO) を達成すべく、ディザスター リカバリー (DR) をセットアップするための設計、テクノロジ、推奨事項を、エンタープライズのお客様にご紹介します。この記事は、Cognizant の SAP クラウド プラクティス担当グローバル責任者、Sivakumar Varadananjayan (英語) 氏との共著です。

Microsoft Azure は、クラウドの SAP ソリューションを使用して、エンタープライズ対応イノベーションへの信頼済みのパスを提供します。Azure 上では、SAP をはじめとするミッション クリティカルなアプリケーションが確実に動作します。Azure は、エンタープライズで実証済みのプラットフォームであり、お客様の SAP ランドスケープを実行するためのハイパースケール、俊敏性、コスト削減効果をもたらします。

システムの可用性とディザスター リカバリーは、ミッション クリティカルな SAP アプリケーションを Azure で実行されているお客様にとって極めて重要です。

予期しないイベントの発生に備えて、ビジネス継続性を維持するための適切なディザスター リカバリー計画を策定する際には、RTO と RPO が考慮すべき重要な指標となります。  回復ポイントの目標 (RPO) は、"時間" の観点からリスクにさらされているデータの量を指すのに対し、回復時間の目標 (RTO) は、障害発生後システムが復旧するまでの最大許容時間を指します。

下図は、BAU (通常のビジネス活動) シナリオでの RPO と RTO をタイムラインで示したものです。

BAU シナリオでの RPO と RTO を示すタイムライン

当社のお客様である Orica は、工業用爆薬と発破システムを手がける世界最大手のメーカーとして、鉱山業、採石業、石油・ガス採掘業、建設業の市場に製品を提供しています。また、金抽出用シアン化ナトリウムの大手サプライヤーとしても知られるほか、採掘とトンネル工事に関する地上支援サービスの専門家派遣も行っています。

Orica のデジタル トランスフォーメーション プロジェクトの一環として、Cognizant は、信頼できるテクノロジ アドバイザーおよびマネージド クラウド プラットフォーム プロバイダーに選ばれ、Microsoft Azure で運用される SAP S/4HANA と他の SAP アプリケーション向けの可用性に優れ、拡張性が高く、障害に強い IT プラットフォームを構築してきました。

この記事では、Cognizant が SAP S/4HANA をデジタル コアとして採用したデジタル トランスフォーメーション プロジェクトの一環として、Orica のためにディザスター リカバリー ソリューションを構築するという課題にいかに対処したかについてご紹介します。SAP on Azure アーキテクチャ設計に関する考慮事項について、過去 2 年間で RTO を 4 時間まで短縮した Cognizant と Orica を例にとって説明します。このような成果は、Azure で提供されている最新のテクノロジ機能を、自動化と組み合わせて展開したことで得られたものです。RTO の短縮のほかにも、SAP HANA システム レプリケーションや Azure Site Recovery などのデータベース専用テクノロジを使用して、RPO を 5 分未満にまで短縮しました。

ディザスター リカバリー システムの設計原則

  • SAP HANA 用の SAP 認定 VM に基づく DR リージョンの選定 - DR リージョンでの SAP 認定 VM タイプの可用性を検証することが重要になります。
  • RPO と RTO の値 - 企業は、RPO と RTO の値に対する期待値を明確に設定する必要があります。その値は、ディザスター リカバリーのアーキテクチャと、ディザスター リカバリーの実装に必要なツールや自動化の要件に大きく影響するためです。
  • DR、メンテナンス、および DR ドリルのコスト
    • システムの重要度 - DR 実装コストとビジネス要件の間でのトレードオフは可能です。最も重要度が高いシステムでは、最先端の DR アーキテクチャを利用することが考えられますが、重要度が中程度あるいは低いシステムでは、RPO/RTO の値がより高くても許されるかもしれません。
    • DR インスタンスのオンデマンドでのサイズ変更 - DR インスタンスには小さなサイズの VM を使用し、実際の DR シナリオでそれらのサイズを大きくすることが望ましいといえます。また、DR リージョンで必要な VM の容量を予約しておき、VM のサイズを拡大する際に "待ち" 時間が発生しないようにすることもできます。マイクロソフトでは、事前に仮想マシンを予約して、コストを 80% 節約できる、占有インスタンスを提供しています。必要な RTO の値に応じて、小規模な VM を運用するか、Azure 占有インスタンスを利用するかで、トレードオフを検討する必要があります。
    • クラウド インフラストラクチャのコストに関する考慮事項にはほかにも、非破壊的 DR テスト用の環境をセットアップする作業があります。非破壊的 DR テストとは、ビジネスのあらゆるダウンタイムを避けるために、DR システムへの実稼働システムのフェールオーバーを行わずに DR テストを実施することを指します。これには、DR テストの間、完全に分離された vNet 内に配置される一時的なインフラストラクチャをセットアップするための追加コストがかかります。
    • クラスター化されたネットワーク ファイル システム (NFS) など、SAP システム アーキテクチャ内の特定のコンポーネントについては、Azure Site Recovery を使用してレプリケートすることは推奨されません。そのため、NFS レイヤーの DR 用に、SUSE Geo クラスターや SIOS Datakeeper などのライセンスコストがかかる追加ツールが必要になります。
  • 専用のテクノロジとツールの選定 - Azure では、リージョン全体で仮想マシンをレプリケートするための Azure Site Recovery (ASR) を提供しています。このテクノロジがシステムのデータベース以外のコンポーネントやレイヤーで使用されるのに対し、SAP HANA システム レプリケーション (HSR) などのデータベース専用の方法は、データベースの整合性を確保するためにデータベース レイヤーで使用されます。

SAP HANA データベース上で実行されている SAP システムのディザスター リカバリー アーキテクチャ

下図は、SAP HANA をベースとする SAP システムのアーキテクチャをかなり大まかに示したものです。これらのシステムは、ローカルまたはリージョンレベルの障害が発生した場合に利用できるようになります。

SAP HANA をベースとする SAP システムのアーキテクチャを示す図。これらのシステムは、ローカルまたはリージョンレベルの障害が発生した場合に利用できるようになります。

下図は、SAP HANA システムのコンポーネントと、ディザスター リカバリーを実現するために使用されるそれぞれのテクノロジについて、もう少し詳しく示したものです。

SAP HANA システムのコンポーネントと、ディザスター リカバリーを実現するために使用されるそれぞれのテクノロジについて、もう少し詳しく示した図。

データベース レイヤー

データベース レイヤーでは、SAP HANA システム レプリケーション (HSR) などのデータベース専用のレプリケーション方法が使用されます。データベース専用のレプリケーション方法を使用すると、さまざまなレプリケーション専用のパラメーターを構成できるので、RPO の値をより的確に制御できるようになります。また、DR サイトでのデータベースの整合性も確保できます。バックアップと復元や、回復またはストレージベースのレプリケーションなど、データベース (DB) レイヤーでディザスター リカバリーを実現する方法は他にも提供されていますが、その結果、RTO の値が高くなってしまいます。

また、SAP HANA データベースの RPO の値を左右する要素としては、レプリケーション方法 (高可用性の場合は同期、DR レプリケーションの場合は非同期)、バックアップの頻度、バックアップ データの保持ポリシー、セーブポイント、レプリケーション構成パラメーターなどが挙げられます。

SAP Solution Manager を使用して、レプリケーションが影響を受ける場合に電子メール アラートがトリガーされるように、レプリケーションの状態を監視することもできます。

ディザスター リカバリー アーキテクチャを HANA データベース レベルで示した図。ローカルの可用性にもディザスター リカバリーにも HANA システム レプリケーション (HSR) が使用されます。

SAP HANA 2.0 SP 3 (revision 33) の時点で複数ノードのレプリケーションを利用できますが、その時点あるいは本稿の執筆時点では、このシナリオは高可用性クラスターと組み合わせてテストされていません。複数ターゲットのレプリケーションの実装に成功すれば、プライマリ サイトでのフェールオーバー シナリオによって、DR のメンテナンス プロセスが簡素化され、手作業での介入が不要になるでしょう。

アプリケーション レイヤー - (A)SCS、APP、iSCSI

Azure Site Recovery は、(A)SCS、アプリケーション サーバー、Linux クラスター フェンス エージェント (iSCSI など) といった、SAP システム アーキテクチャのデータベース以外のコンポーネントのレプリケーションに使用されます (ただし、NFS レイヤーは除きます (下記参照))。Azure Site Recovery は、仮想マシン (VM) 上で実行されているワークロードをプライマリ サイトからセカンダリ ロケーションにストレージ レイヤーでレプリケートします。VM を実行状態にする必要はありません。VM は実際の障害シナリオや DR ドリル時に起動できます。

Azure で Pacemaker クラスターをセットアップする場合、選択肢が 2 つあります。1 つはフェンス エージェントを使う方法です。フェンス エージェントは、障害が発生したノードを Azure API で再起動させる役割を担います。もう 1 つは、SBD (Storage Based Death) デバイスを使う方法です。SBD デバイスを使う場合、iSCSI ターゲット サーバーとして機能しつつ SBD デバイスを提供する VM が、少なくとも 1 つ、追加で必要となります。ただし、これらの iSCSI ターゲット サーバーは他の Pacemaker クラスターと共有することができます。SBD デバイスを使う利点は、フェールオーバー時間を短縮できることです。

下図では、アプリケーション レイヤーでのディザスター リカバリーについて説明しています。(A)SCS、アプリ サーバー、および iSCSI サーバーで同じアーキテクチャを使い、Azure Site Recovery を利用して DR リージョン全体でデータをレプリケートします。 

アプリケーション レイヤーでのディザスター リカバリーについて説明した図。(A)SCS、アプリ サーバー、および iSCSI サーバーで同じアーキテクチャを使い、Azure Site Recovery を利用して DR リージョン全体でデータをレプリケートします。

NFS レイヤー - プライマリ サイトの NFS レイヤーでは、高可用性レプリケーションを実現するために、DRBD (分散レプリケートされたブロック デバイス) が構成されたクラスターを使用します。当社では、NFS レイヤーでの DR の実装に向けていくつものテクノロジを検討しました。DRBD と Site Recovery の構成には互換性がないため、NFS レイヤーの DR を実現するために、SUSE Geo クラスター、SIOS Datakeeper、あるいは単純な VM スナップショット バックアップと回復といったソリューションが提供されています。DRBD によって、ディスク レプリケーションを使って NFS レイヤーで高可用性を実現できるため、Site Recovery レプリケーションはサポートされていません。DRBD が有効でない場合は、NFS レイヤーの DR を実現するためのコスト効率の高い方法として、VM スナップショット バックアップによる単純なバックアップと回復を使用できます。

DR または DR ドリルを実施するためのステップ

Microsoft Azure Site Recovery テクノロジは、DR リージョンでのデータのレプリケーションの迅速化に役立ちます。Site Recovery が使用/構成されていない DR の実装環境では、5 つ程のシステムを回復するのに 24 時間以上かかり、最終的に RTO が 24 時間を超えてしまいます。一方、アプリケーション レイヤーで Site Recovery が使用されていて、DB レイヤーでのデータベース専用のレプリケーション方法が利用されている場合は、同数のシステムに対する RTO の値を、4 時間をはるかに下回るところまで減らすことが可能です。下図は、RTO の値が 4 時間のディザスター リカバリーを実現するためのステップを含むタイムライン ビューを示しています。

DR または DR ドリルを実施するためのステップ:

  • VM で新しい IP アドレスを使用するために DNS を変更
  • iSCSI を起動 - ASR によってレプリケートされたデータによる単一の VM
  • データベースを回復し、VM のサイズを必要な容量に変更
  • NFS を手動でプロビジョニング - スナップショット バックアップを使用する単一の VM
  • ASR によってレプリケートされたデータからアプリケーション レイヤーの VM を作成
  • クラスターの変更を実行
  • アプリケーションを起動
  • アプリケーションを検証
  • システムをリリース

DR ドリル計画の例を示すスクリーンショット

非破壊的 DR ドリルに関する推奨事項

企業によっては DR ドリル中のダウンタイムが許されない場合もあります。DR を実行するためのダウンタイムに備えた体制を整えることができない場合は、非破壊的 DR ドリルが推奨されます。非破壊的 DR の手順を実行するには、追加の DR VNet を作成し、それをネットワークから分離して、DR ドリルを以下のステップに従って実施します。

前提条件として、分離された VNet で SAP HANA データベース サーバーを構築し、SAP HANA システム レプリケーションを構成してください。

  1. DR リージョンへの ExpressRoute 回線を切断します。ExpressRoute が切断されると、プライマリ リージョンのシステムの突発的障害がシミュレートされます。
  2. 前提条件として、ExpressRoute が切断されるまでは、バックアップ ドメイン コントローラーをアクティブにすると共に、プライマリ ドメイン コントローラーとのレプリケーション モードにする必要があります。
  3. DNS サーバーを分離された DR VNet (非破壊的 DR ドリル用に作成した追加の DR VNet) で構成し、ExpressRoute が切断されるまでは、スタンバイ モードのままにする必要があります。
  4. DR テスト用に管理者と主要ユーザーのためのポイント対サイト VPN トンネルを確立します。
  5. DR VNet がネットワーク全体から分離されるように、NSG を手動で更新します。
  6. DR リージョンで DR 有効化手順に従ってアプリケーションを起動します。
  7. テストが完了したら、NSG、ExpressRoute、および DR レプリケーションを構成し直します。

DR テスト中は、インフラストラクチャと SAP に関する適切な知識を持つ当該分野の専門家を参加させることを強くお勧めします。

非破壊的 DR の手順を実施する場合は、必ず非実稼働システムを使って事前に検証とテストを行い、細心の注意を払って進めてください。DR リージョンでのデータベース VM の容量は、全容量を予約するか、マイクロソフトのタイムラインに従って必要な容量を割り当て、データベース VM のサイズを変更するかで、トレードオフを考えながら決めてください。

次のステップ

SAP に最適な Azure インフラストラクチャのアーキテクチャ設計については、以下のリソースで詳細を確認してください。