HANA Large Instances にディザスター リカバリーを実装する
HANA L インスタンスでは、さまざまな Azure リージョンの HANA L インスタンス スタンプ間でのディザスター リカバリー機能が提供されます。 たとえば、Azure の米国西部リージョンに HANA L インスタンス ユニットをデプロイした場合、米国東部リージョンの HANA L インスタンス ユニットをディザスター リカバリー ユニットとして使用できます。 前述のように、ディザスター リカバリーでは DR リージョンの別の HANA L インスタンス ユニットの料金を支払う必要があるため、ディザスター リカバリーは自動的には構成されません。 ディザスター リカバリー セットアップは、スケールアップおよびスケールアウト セットアップに対応しています。
これまでにデプロイされたシナリオでは、お客様は DR リージョンのユニットを使って、インストール済みの HANA インスタンスを使用する非運用システムを実行していました。 HANA L インスタンス ユニットは、運用環境で使用される SKU と同じ SKU である必要があります。
その後、2 つ目のディスク ボリューム セットを注文する必要があります。 ターゲット ディスク ボリュームは、ディザスター リカバリー ユニットの実稼働インスタンス用の実稼働ボリュームと同じサイズです。 これらのディスク ボリュームは、ディザスター リカバリー (DR) サイトの HANA Large Instance サーバー ユニットに関連付けられています。 次のボリュームは、実稼働リージョンから DR サイトにレプリケートされます。
- /hana/data
- /hana/logbackups
- /hana/shared (/usr/sap を含みます)
hana/log ボリュームは、それらのボリュームから復元が行われる方法では SAP HANA トランザクション ログは必要ないため、レプリケートされません。
提供される ディザスター リカバリー機能の基礎は、HANA L インスタンス インフラストラクチャによって提供されるストレージ レプリケーション機能です。 ストレージ側で使用される機能は、ストレージ ボリュームに対する変更が発生したときに非同期で変更を絶えずレプリケートするものではありません。 これらのボリュームでスナップショットが定期的に作成されるということに依存するメカニズムです。 既にレプリケートされたスナップショットとまだレプリケートされていない新しいスナップショット間の差分が、ディザスター リカバリー サイトのターゲット ディスク ボリュームに転送されます。 これらのスナップショットはボリュームに格納され、ディザスター リカバリー フェールオーバーが発生した場合は、それらのボリュームで復元する必要があります。
ボリュームの完全なデータの最初の転送は、データ量がスナップショット間の差分より小さくなる前に、行われる必要があります。 そのため、DR サイトのボリュームには、実稼働サイトで実行されたすべてのボリューム スナップショットが含まれています。 これにより、運用システムをロールバックすることなく、その DR システムを使用して以前の状態に戻し、失われたデータを最終的に回復することができます。
1 つの HANA Large Instance ユニット上の複数の独立した SAP HANA インスタンスを使用する MCOD (Multiple Components One Database) のデプロイがある場合は、すべての SAP HANA インスタンスが DR 側にレプリケートされたストレージを使用するものと想定されます。
HANA システム レプリケーションを運用サイトの高可用性機能として使用し、DR サイトではストレージ ベースのレプリケーションを使用する場合、両方のノードのボリュームがプライマリ サイトから DR インスタンスにレプリケートされます。 プライマリとセカンダリ両方から DR へのレプリケーションに対応するには、DR サイトで追加のストレージ (プライマリ ノードと同じサイズ) を購入する必要があります。
注意
HANA L インスタンスのストレージ レプリケーション機能では、ストレージ スナップショットをミラーリングおよびレプリケートします。 ストレージ スナップショットを実行しない場合は、ディザスター リカバリー サイトへのレプリケーションは存在できません。 ストレージ スナップショットの実行は、ディザスター リカバリー サイトへのストレージ レプリケーションの前提条件となります。