Azure リージョンの枠を越えた SAP HANA の可用性
この記事では、さまざまな Azure リージョンにまたがる SAP HANA の可用性に関連するシナリオについて説明します。 Azure リージョン間の距離が原因で、複数の Azure リージョンでの SAP HANA の可用性の設定には特別な考慮事項があります。
複数の Azure リージョンにまたがって展開する理由
多くの場合、Azure リージョンは長い距離で隔てられています。 地理的リージョンによっては、米国でのように Azure リージョン間の距離が何百 km から何千 km にもなる可能性があります。 このような距離が原因で、2 つの異なる Azure リージョンに展開されたアセット間のネットワーク トラフィックは、ネットワーク ラウンドトリップの待機時間が長くなります。 待機時間が長いので、一般的な SAP ワークロードでは、2 つの SAP HANA インスタンス間で同期データの交換を行わないことも考えられます。
その一方で、多くの場合、組織にはプライマリ データセンターの場所とセカンダリ データセンターの場所の間に距離の要件があります。 距離の要件は、地理的に広い場所で自然災害が発生した場合に可用性を確保するのに役立ちます。 たとえば、2017 年 9 月と 10 月にカリブ海とフロリダを襲ったハリケーンなどです。 組織には、少なくとも最短距離の要件がある可能性があります。 ほとんどの Azure のお客様では、最短距離の定義で Azure リージョンをまたがる可用性の設計が要求されています。 2 つの Azure リージョン間の距離が長すぎて HANA の同期レプリケーション モードを使用できないため、RTO と RPO の要件により、1 つ目のリージョン内に可用性の構成を展開し、2 つ目のリージョンの追加の展開で補完する必要があります。
このシナリオで考慮すべきもう 1 つの側面は、フェールオーバーとクライアントのリダイレクトです。 2 つの Azure リージョン内にある SAP HANA インスタンス間のフェールオーバーは、常に手動フェールオーバーであるという前提があります。 SAP HANA システム レプリケーションのレプリケーション モードは非同期に設定されているため、プライマリ HANA インスタンスでコミットされたデータはセカンダリ HANA インスタンスにまだ作成されていない可能性があります。 そのため、レプリケーションが非同期の構成では、自動フェールオーバーを選択できません。 フェールオーバーのように手動で制御されたフェールオーバーでも、プライマリ側でコミットされたすべてのデータがセカンダリ インスタンスに確実に転送されてから、別の Azure リージョンに手動で移動する必要があります。
Azure Virtual Network では、異なる IP アドレス範囲を使用します。 IP アドレスは、2 番目の Azure リージョンに展開されます。 そのため、SAP HANA クライアント構成を変更するか、可能であれば、名前解決を変更するステップを作成する必要があります。 これにより、クライアントは新しいセカンダリ サイトのサーバー IP アドレスにリダイレクトされます。 詳しくは、引き継ぎ後のクライアント接続の回復に関する SAP の記事をご覧ください。
2 つの Azure リージョン間の単純な可用性
1 つのリージョン内に可用性構成を配置しないことを選択しても、災害が発生した場合にはワークロードを処理することが必要な場合があります。 このようなシナリオの一般的な例として、非運用環境システムがあります。 システムを半日または 1 日停止することには耐えられても、48 時間以上システムを利用不可にすることはできません。 セットアップ コストを低く抑えるには、重要度の低い別のシステムを VM で実行します。 他のシステムは同期先として機能します。 セカンダリ リージョンの VM のサイズを小さくして、データを事前に読み込まないことも選択できます。 フェールオーバーは手動で行われ、完全なアプリケーション スタックをフェールオーバーするには手順が増えるため、VM を停止し、サイズを変更して VM を再起動するための追加の時間は許容されます。
DR ターゲットを 1 つの VM 内の QA システムと共有するシナリオを使用している場合は、次の考慮事項を考慮する必要があります。
- delta_datashipping と logreplay の 2 つの操作モードがあり、このようなシナリオに利用できます
- どちらの操作モードにも、データをプリロードしない、異なるメモリ要件があります
- delta_datashipping では、プリロード オプションを使用することなく、logreplay よりも必要なメモリが大幅に少なくなる場合があります。 SAP ドキュメント「How To Perform System Replication for SAP HANA」 (SAP HANA に対してシステム レプリケーションを実行する方法) の第 4.3 章を参照してください
- プリロードなしの logreplay 操作モードのメモリ要件は決定論的ではなく、読み込まれた列ストア構造によって異なります。 極端な場合では、プライマリ インスタンスの 50% のメモリが必要なことがあります。 logreplay 操作モードでのメモリは、プリロードされたデータが設定されていることを選んだかどうかに依存しません。
注意
この構成では、HANA システム レプリケーション モードが非同期なので、RPO = 0 を指定できません。 RPO = 0 を指定する必要がある場合、この構成は選択できません。
データを事前読み込みとして構成するために、構成で小さな変更を行える可能性があります。 ただし、手動のフェールオーバーという性質と、アプリケーション レイヤーを 2 つ目のリージョンに移行する必要があるという点も考慮すると、データの事前読み込みは意味がない可能性があります。
1 つのリージョン内の可用性とリージョンをまたがる可用性を組み合わせる
1 つのリージョン内の可用性とリージョンをまたがる可用性の組み合わせは、次の要因で推進される可能性があります。
- 1 つの Azure リージョン内で RPO = 0 の要件がある。
- リージョンの広域に影響する大規模な自然災害の影響を受ける事業について、組織がグローバルに展開するつもりがない、または展開することができない。 これは、数年前にカリブ海を襲ったハリケーンのケースです。
- プライマリ サイトとセカンダリ サイト間の必要距離を規定した規制が、Azure 可用性ゾーンが提供できる範囲を明らかに超えている。
このような場合は、HANA システム レプリケーションを使用して SAP HANA 多層システム レプリケーション構成を呼 び出す内容を設定できます。 アーキテクチャは次のようになります。
SAP では、HANA 2.0 SPS3 によるマルチターゲット システム レプリケーションが導入されました。 マルチターゲット システム レプリケーションには、更新のシナリオでいくつかの利点があります。 たとえば、セカンダリ HA サイトがメンテナンスまたは更新のために停止しても、DR サイト (リージョン 2) は影響を受けません。 HANA マルチターゲット システム レプリケーションの詳細については、SAP Help Portal を参照してください。 マルチターゲット レプリケーションで可能なアーキテクチャは、次のようになります。
組織の要件が、2 番目の (DR) Azure リージョンで高可用性の準備ができていることである場合、アーキテクチャは次のようになります。
操作モードとして logreplay を使用すると、この構成は、プライマリ リージョン内に RPO = 0、低 RTO を提供します。 構成は、2 つ目のリージョンへの移行が必要な場合にも適切な RPO を提供します。 2 つ目のリージョンの RTO 時間は、データが事前に読み込まれるかどうかによって変わります。 多くのお客様は、セカンダリ リージョンの VMを 使用してテスト システムを実行します。 このユース ケースでは、データを事前読み込みできません。
重要
異なる階層間の操作モードは、同じ種類にする必要があります。 階層 1 と階層 2 の間の操作モードとして logreplay を使用して、レベル 3 を提供delta_datashipping することはできません 。 すべての階層に一貫性がある必要がある、いずれか一方の操作モードのみを選ぶことができます。 RPO=0 を提供するために delta_datashipping は適していないため、このような多層構成に適切な唯一の操作モードは logreplay です。 操作モードと一部の制限事項について詳しくは、SAP の SAP HANA システム レプリケーションの操作モードに関する記事をご覧ください。
次のステップ
Azure でのこれらの構成の設定手順については、以下をご覧ください。