次の図は、 SnapCenterサーバー、SAP HANA データベース、およびストレージ システム間の通信の論理ビューを示しています。SnapCenterサーバーは、HANA と Linux プラグインを活用して、HANA データベースおよび Linux オペレーティング システムと通信します。

SnapCenterプラグインの推奨されるデフォルトの展開オプションは、HANA データベース ホストへのインストールです。この展開オプションでは、 「SnapCenterでサポートされる構成」の章で説明されているすべての構成と機能が有効になります。いくつかの例外があり、 SnapCenterプラグインを HANA データベース ホストにインストールできず、中央プラグイン ホスト ( SnapCenterサーバー自体など) で構成する必要があります。HANA 複数ホスト システムまたは IBM Power プラットフォーム上で実行される HANA システムには、中央プラグイン ホストが必要です。両方の展開オプションを組み合わせることもできます。たとえば、 SnapCenterサーバーを複数のホスト システムの中央プラグイン ホストとして使用し、他のすべての単一ホスト HANA システムの HANA データベース ホストにプラグインを展開するなどです。

SnapCenterでは、HANA リソースを自動検出するか、手動で構成することができます。HANA および Linux プラグインがデータベース ホストにデプロイされるとすぐに、HANA システムがデフォルトで自動検出されます。SnapCenter の自動検出では、同じホスト上の複数の HANA インストールはサポートされません。中央プラグイン ホストを使用して管理される HANA システムは、 SnapCenterで手動で構成する必要があります。また、非データ ボリュームは、デフォルトでは手動で構成されたリソースです。

SnapCenter はHANA システムの中央プラグイン展開をサポートしていますが、プラットフォームと機能のサポートには制限があります。中央プラグイン ホストで構成された HANA システムでは、次のインフラストラクチャ構成と操作はサポートされません。

SAP では、全体的なバックアップ戦略に定期的な HANA ブロック整合性チェックを含めることを推奨しています。従来のファイルベースのバックアップでは、このチェックはバックアップ操作ごとに実行されます。スナップショット バックアップでは、スナップショット バックアップ操作に加えて、たとえば週に 1 回、整合性チェックを実行する必要があります。

技術的には、ブロック整合性チェックを実行するには 2 つのオプションがあります。

HANA hdbpersdiag ツールは HANA インストールの一部であり、オフライン HANA データベースに対してブロック整合性チェック操作を実行できます。したがって、既存のスナップショット バックアップを hdbpersdiag に提示できるスナップショット バックアップと組み合わせて使用するのに最適です。

2 つのアプローチを比較すると、hdbpersdiag は HANA ブロック整合性チェックのファイルベースのバックアップに比べて大きな利点があります。1 つの次元は必要なストレージ容量です。ファイルベースのバックアップでは、各 HANA システムに対して少なくとも 1 つのバックアップのサイズが利用可能である必要があります。たとえば、永続サイズが 3 TB の HANA システムが 15 台ある場合、整合性チェックのためだけにさらに 45 TB が必要になります。hdbpersdiag では、既存のスナップショット バックアップまたは既存のスナップショット バックアップのFlexCloneに対して操作が実行されるため、追加のストレージ容量は必要ありません。2 番目の次元は、整合性チェック操作中の HANA ホストの CPU 負荷です。ファイルベースのバックアップでは HANA データベース ホストで CPU サイクルが必要になりますが、中央検証ホストと組み合わせて使用​​すると、hdbpersdiag 処理は HANA ホストから完全にオフロードできます。以下の表に主な特徴をまとめます。

NetApp、HANA ブロックの整合性チェックを実行するために hdbpersdiag を使用することを推奨しています。実装の詳細については、次の章を参照してください。 "SnapCenterによるブロック整合性チェック"。

SnapCenter と SAP HANA プラグインを設定する前に、各種 SAP システムの RTO と RPO の要件に基づいてデータ保護戦略を定義する必要があります。

一般的なアプローチとしては、本番システム、開発システム、テストシステム、サンドボックスシステムなどのシステムタイプを定義します。通常、システムタイプが同じ SAP システムのデータ保護パラメータはすべて同じです。

定義する必要があるパラメータは次のとおりです。

次の表は、システム タイプ運用、開発、テストのデータ保護パラメータの例を示しています。実稼働システムでは、高いバックアップ頻度が定義されており、バックアップは 1 日に 1 回セカンダリ バックアップ サイトに複製されます。テスト システムでは要件が低く、バックアップのレプリケーションは行われません。

次の表は、上記のデータ保護パラメータに対して構成する必要があるポリシーとスケジュールを示しています。

以下の図は、スケジュールとバックアップの保持期間をまとめたものです。SnapCenterを使用してログ バックアップの保持を管理する場合、最も古いスナップショット バックアップよりも古いログ バックアップはすべて削除されます。つまり、ログ バックアップは、利用可能なすべてのバックアップを最新の状態に回復するために必要な期間保持されます。

HANA 永続暗号化を使用する場合は、標準のデータ バックアップに加えて、ルート キーのバックアップを作成することが重要です。データ ボリュームと HANA インストール ファイル システムが失われた場合に HANA データベースを回復するには、ルート キーのバックアップが必要です。詳細については、 "『 SAP HANA Administration Guide 』をご覧ください"。

SnapCenter は、単一または複数のテナントを持つ HANA MDC システムのスナップショット バックアップ操作をサポートします。SnapCenter は、HANA MDC システムの 2 つの異なる復元操作もサポートしています。システム全体、システム DB、およびすべてのテナントを復元することも、1 つのテナントだけを復元することもできます。SnapCenter がこれらの操作を実行できるようにするには、いくつかの前提条件があります。

MDC システムでは、テナント構成は必ずしも静的ではありません。テナントを追加したり、テナントを削除したりできます。SnapCenter は、HANA データベースがSnapCenterに追加されたときに検出された構成に依存できません。単一テナントの復元操作を有効にするには、 SnapCenter は各スナップショット バックアップに含まれるテナントを認識する必要があります。さらに、スナップショット バックアップに含まれる各テナントに属するファイルとディレクトリを認識する必要があります。

したがって、バックアップ操作ごとに、 SnapCenter はテナント情報を識別します。これには、テナント名と対応するファイルおよびディレクトリ情報が含まれます。単一テナントの復元操作をサポートできるようにするには、このデータをスナップショット バックアップ メタデータに保存する必要があります。

アプリケーション自動検出のもう 1 つのステップは、HANA システム レプリケーション (HSR) のプライマリ ノードまたはセカンダリ ノードの検出です。HANA システムが HSR で構成されている場合、バックアップ SQL コマンドが HSR プライマリ ノードで実行されるように、 SnapCenter は各バックアップ操作でプライマリ ノードを識別する必要があります。参照 "『SAP HANA System Replication - Backup and Recovery with SnapCenter』"。

SnapCenter はHANA データ ボリューム構成も検出し、それをファイル システムとストレージ リソースにマッピングします。このアプローチにより、 SnapCenter はHANA ボリューム構成の変更 (複数のパーティションやボリュームの移行などのストレージ構成の変更など) を処理できます。

次のステップは、スナップショット バックアップ操作そのものです。この手順には、HANA データベース スナップショット、ストレージ スナップショット バックアップをトリガーする SQL コマンド、および HANA スナップショット操作を終了する SQL コマンドが含まれます。close コマンドを使用することで、HANA データベースはシステム DB と各テナントのバックアップ カタログを更新します。

データバックアップの保持管理と HANA のバックアップカタログ管理のために、 SnapCenter では、最初の手順で特定されたシステムデータベースとすべてのテナントデータベースに対してカタログ削除処理を実行する必要があります。ログバックアップの場合と同様に、 SnapCenter ワークフローは、バックアップ処理の一部であった各テナントに対して実行する必要があります。

次の図に、バックアップワークフローの概要を示します。

データバックアップ保持管理とログバックアップの不要ファイルの削除は、次の保持管理を含む 5 つのメイン領域に分割できます。

次の図は、各種ワークフローの概要と各処理の依存関係を示しています。以降のセクションでは、さまざまな処理について詳しく説明します。