ベストプラクティス
単一のリソースを使用する SnapCenter 構成
変更を提案
PDF
SnapCenter リソースは、 HANA システムレプリケーション環境の仮想 IP アドレス（ホスト名）で構成されます。このアプローチでは、ホスト 1 とホスト 2 のどちらがプライマリかに関係なく、 SnapCenter は常にプライマリホストと通信します。両方の SAP HANA ホストのデータボリュームは、 SnapCenter リソースに含まれています。
|
仮想 IP アドレスは常にプライマリ SAP HANA ホストにバインドされているものとします。仮想 IP アドレスのフェイルオーバーは、 HANA システムレプリケーションのフェイルオーバーワークフローの一環として、 SnapCenter の外部で実行されます。 |
ホスト 1 をプライマリホストとするバックアップを実行すると、データベースと整合性のある Snapshot バックアップがホスト 1 のデータボリュームに作成されます。ホスト 2 のデータボリュームは SnapCenter リソースの一部であるため、このボリュームに対してもう 1 つの Snapshot コピーが作成されます。この Snapshot コピーはデータベースの整合性を維持するのではなく、セカンダリホストのクラッシュイメージにすぎません。
SAP HANA のバックアップカタログと SnapCenter リソースには、ホスト 1 で作成されたバックアップが含まれています。
次の図に、ホスト 2 へのフェイルオーバーおよびホスト 2 からホスト 1 へのレプリケーション後のバックアップ処理を示します。SnapCenter は、 SnapCenter リソースに設定されている仮想 IP アドレスを使用して、ホスト 2 と自動的に通信します。これで、ホスト 2 にバックアップが作成されます。SnapCenter によって 2 つの Snapshot コピーが作成されます。ホスト 2 のデータボリュームにあるデータベースと整合性のあるバックアップと、ホスト 1 のデータボリュームにあるクラッシュイメージの Snapshot コピーです。SAP HANA のバックアップカタログと SnapCenter リソースに、ホスト 1 で作成されたバックアップとホスト 2 で作成されたバックアップが含まれるようになりました。
不要なデータバックアップやログバックアップは、定義された SnapCenter 保持ポリシーに基づいて削除され、プライマリまたはセカンダリのホストに関係なく、バックアップは削除されます。
の項で説明したように "ストレージ Snapshot バックアップと SAP システムレプリケーション"ストレージベースの Snapshot バックアップを使用したリストア処理は、リストアするバックアップによって異なります。ローカル・ストレージ・ボリュームでリストアを実行できるかどうか、または他のホストのストレージ・ボリュームでリストアを実行する必要があるかどうかを判断するには、バックアップが作成されたホストを特定することが重要です。
シングルリソースの SnapCenter 構成では、バックアップがどこに作成されたかが SnapCenter で認識されません。そのため、 SnapCenter のバックアップワークフローにバックアップ前のスクリプトを追加して、現在プライマリ SAP HANA ホストになっているホストを特定することを推奨します。
次の図は、バックアップホストの ID を示しています。
SnapCenter 構成
次の図は、ラボでのセットアップと必要な SnapCenter 構成の概要を示しています。
どの SAP HANA ホストがプライマリであっても、 1 つのホストがダウンしている場合でもバックアップ処理を実行するには、 SnapCenter SAP HANA プラグインを中央のプラグインホストに導入する必要があります。今回のラボ環境では、 SnapCenter サーバを中央プラグインホストとして使用し、 SnapCenter サーバに SAP HANA プラグインを導入しました。
HANA データベースに、バックアップ処理を実行するユーザを作成しました。SAP HANA プラグインがインストールされている SnapCenter サーバにユーザストアキーが設定されている。ユーザーストアキーには、 SAP HANA システムレプリケーションホスト（ SSR-VIP ）の仮想 IP アドレスが含まれます。
hdbuserstore.exe -u SYSTEM set SSRKEY ssr-vip:31013 SNAPCENTER <password>
SAP HANA プラグインの導入オプションとユーザストアの構成の詳細については、テクニカルレポート TR-4614 を参照してください。 "SnapCenter を使用した SAP HANA のバックアップとリカバリ"。
SnapCenter では ' 次の図に示すように ' リソースは ' 前に構成されたユーザー・ストア・キーと SnapCenter サーバを 'hdbsql' 通信ホストとして構成されます
次の図に示すように、両方の SAP HANA ホストのデータボリュームがストレージ設置面積構成に含まれています。
前述したように、 SnapCenter はバックアップがどこで作成されたかを認識しません。したがって、 SnapCenter バックアップワークフローにバックアップ前のスクリプトを追加して、現在プライマリ SAP HANA ホストとなっているホストを特定することを推奨します。この識別は、次の図に示すように、バックアップワークフローに追加された SQL ステートメントを使用して実行できます。
Select host from “SYS”.M_DATABASE
SnapCenter バックアップ処理
バックアップ処理が通常どおり実行されるようになりました。不要なデータバックアップとログバックアップの削除は、プライマリまたはセカンダリの SAP HANA ホストとは無関係に実行されます。
バックアップジョブログには SQL ステートメントの出力が含まれており、バックアップが作成された SAP HANA ホストを特定できます。
次の図に、ホスト 1 をプライマリホストとするバックアップジョブログを示します。
この図は、ホスト 2 がプライマリホストであるバックアップジョブログを示しています。
次の図は、 SAP HANA Studio の SAP HANA バックアップカタログを示しています。SAP HANA データベースがオンラインの場合、バックアップが作成された SAP HANA ホストが SAP HANA Studio に表示されます。
|
|
リストア処理とリカバリ処理で使用されるファイルシステム上の SAP HANA バックアップカタログに、バックアップが作成されたホスト名は含まれません。データベースがダウンしているときにホストを識別する唯一の方法は、バックアップカタログのエントリと、両方の SAP HANA ホストの「 backup.log 」ファイルを組み合わせることです。 |
リストアとリカバリ
前述したように、必要なリストア処理を定義するために、選択したバックアップの作成先を特定できる必要があります。SAP HANA データベースがオンラインのままの場合は、 SAP HANA Studio を使用して、バックアップが作成されたホストを特定できます。データベースがオフラインの場合、情報は SnapCenter バックアップジョブログでのみ確認できます。
次の図に、選択したバックアップに応じたリストア処理を示します。
タイムスタンプ T3 の後にリストア処理を実行する必要があり、ホスト 1 がプライマリである場合は、 SnapCenter を使用して T1 または T3 で作成されたバックアップをリストアできます。これらの Snapshot バックアップは、ホスト 1 に接続されているストレージボリュームで使用できます。
ホスト 2 （ T2 ）に作成されたバックアップを使用してリストアする必要がある場合は、ホスト 2 のストレージボリュームにある Snapshot コピーを使用する必要があります。このバックアップを利用するには、バックアップから NetApp FlexClone コピーを作成し、 FlexClone コピーをホスト 1 にマウントし、データを元の場所にコピーします。
単一の SnapCenter リソース構成では、両方の SAP HANA システムレプリケーションホストの両方のストレージボリュームに Snapshot コピーが作成されます。フォワードリカバリに使用できるのは、プライマリ SAP HANA ホストのストレージボリュームに作成された Snapshot バックアップのみです。セカンダリ SAP HANA ホストのストレージボリュームに作成された Snapshot コピーは、フォワードリカバリに使用できないクラッシュイメージです。
SnapCenter でのリストア処理は、次の 2 つの方法で実行できます。
-
有効なバックアップのみをリストアしてください
-
有効なバックアップとクラッシュ・イメージを含む ' リソース全体をリストアする以下のセクションでは '2 つの異なるリストア・オペレーションについて詳細に説明します
もう一方のホストで作成されたバックアップからのリストア処理については、を参照してください "他のホストで作成されたバックアップからのリストアとリカバリ"。
次の図は、単一の SnapCenter リソース構成を使用したリストア処理を示しています。
有効なバックアップの SnapCenter リストアのみを実行してください
次の図に、このセクションで説明するリストアとリカバリのシナリオの概要を示します。
T1 のホスト 1 にバックアップが作成されました。ホスト 2 へのフェイルオーバーが実行されました。特定の時点で、ホスト 1 へのフェイルオーバーが再度実行されます。現在の時点では、ホスト 1 がプライマリホストになります。
-
障害が発生したため、 T1 のホスト 1 で作成されたバックアップにリストアする必要があります。
-
セカンダリホスト（ホスト 2 ）はシャットダウンされますが、リストア処理は実行されません。
-
ホスト 1 のストレージボリュームは、 T1 で作成されたバックアップに復元されます。
-
フォワードリカバリは、ホスト 1 およびホスト 2 のログを使用して実行されます。
-
ホスト 2 が開始され、ホスト 2 のシステムレプリケーションの再同期が自動的に開始されます。
次の図は、 SAP HANA Studio の SAP HANA バックアップカタログを示しています。強調表示されたバックアップは、 T1 のホスト 1 で作成されたバックアップを示しています。
リストア処理とリカバリ処理は SAP HANA Studio で開始されます。次の図に示すように、バックアップが作成されたホストの名前はリストアとリカバリのワークフローには表示されません。
|
|
テストシナリオでは、データベースがオンラインのままの場合、 SAP HANA Studio で正しいバックアップ（ホスト 1 で作成されたバックアップ）を特定できました。データベースを使用できない場合は、 SnapCenter バックアップジョブログで適切なバックアップを特定する必要があります。 |
SnapCenter では、バックアップが選択され、ファイルレベルのリストア処理が実行されます。ファイルレベルのリストア画面では、有効なバックアップのみがリストアされるように、ホスト 1 のボリュームのみが選択されます。
リストア処理が完了すると、 SAP HANA Studio でバックアップが緑色で強調表示されます。ホスト 1 とホスト 2 のログバックアップのファイルパスがバックアップカタログに含まれているため、追加のログバックアップの場所を入力する必要はありません。
フォワードリカバリが完了すると、セカンダリホスト（ホスト 2 ）が起動し、 SAP HANA システムレプリケーションの再同期が開始されます。
|
|
セカンダリホストが最新の状態である（ホスト 2 に対してリストア処理が実行されていない）場合でも、 SAP HANA はすべてのデータの完全なレプリケーションを実行します。この動作は、 SAP HANA システムレプリケーションを使用したリストア処理とリカバリ処理後に標準で実行されます。 |
有効なバックアップとクラッシュイメージの SnapCenter リストア
次の図に、このセクションで説明するリストアとリカバリのシナリオの概要を示します。
T1 のホスト 1 にバックアップが作成されました。ホスト 2 へのフェイルオーバーが実行されました。特定の時点で、ホスト 1 へのフェイルオーバーが再度実行されます。現在の時点では、ホスト 1 がプライマリホストになります。
-
障害が発生したため、 T1 のホスト 1 で作成されたバックアップにリストアする必要があります。
-
セカンダリホスト（ホスト 2 ）がシャットダウンされ、 T1 クラッシュイメージが復元されます。
-
ホスト 1 のストレージボリュームは、 T1 で作成されたバックアップに復元されます。
-
フォワードリカバリは、ホスト 1 およびホスト 2 のログを使用して実行されます。
-
ホスト 2 が開始され、ホスト 2 のシステムレプリケーションの再同期が自動的に開始されます。
SAP HANA Studio でのリストアとリカバリの処理は、のセクションで説明する手順と同じです "有効なバックアップの SnapCenter リストアのみを実行してください"。
リストア処理を実行するには、 SnapCenter でリソースを完全に選択してください。両方のホストのボリュームがリストアされます。
フォワードリカバリが完了すると、セカンダリホスト（ホスト 2 ）が起動し、 SAP HANA システムレプリケーションの再同期が開始されます。すべてのデータの完全なレプリケーションが実行されます。
