アーキテクチャ
SAP HANA ホストは、冗長 FCP インフラとマルチパスソフトウェアを使用してストレージコントローラに接続されます。スイッチまたはホストバスアダプタ( HBA )で障害が発生した場合に、耐障害性に優れた SAP HANA ホスト / ストレージ接続を実現するには、冗長 FCP スイッチインフラが必要です。すべての HANA ホストがストレージコントローラ上の必要な LUN にアクセスできるように、スイッチで適切なゾーニングを設定する必要があります。
AFF システム製品ファミリーのさまざまなモデルをストレージレイヤで混在させることができるため、拡張が必要になったり、パフォーマンスや容量のニーズが異なる場合があります。ストレージシステムに接続できる SAP HANA ホストの最大数は、 SAP HANA のパフォーマンス要件と、使用されているネットアップコントローラのモデルによって定義されます。必要なディスクシェルフの数は、 SAP HANA システムの容量とパフォーマンスの要件によってのみ決まります。
次の図は、 8 台の SAP HANA ホストをストレージ HA ペアに接続した構成例を示しています。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image2.png)
このアーキテクチャは、次の 2 つの側面で拡張できます。
-
既存のストレージに SAP HANA ホストとストレージ容量を追加で接続することで、ストレージコントローラが現在の SAP HANA KPI を満たす十分なパフォーマンスを提供する場合
-
追加の SAP HANA ホスト用にストレージ容量を追加したストレージシステムを追加する
次の図は、追加の SAP HANA ホストをストレージコントローラに接続した場合の構成例を示しています。この例では、 16 台の SAP HANA ホストの容量とパフォーマンスの要件を満たすために、さらにディスクシェルフが必要です。合計スループット要件に応じて、ストレージコントローラへの FC 接続を追加する必要があります。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image3.png)
次の図に示すように、導入した AFF システムとは関係なく、認定済みのストレージコントローラを追加することで、 SAP HANA 環境を拡張して希望するノード密度に合わせることもできます。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image4.png)
SAP HANA のバックアップ
すべてのネットアップストレージコントローラに搭載された ONTAP ソフトウェアは、動作中にパフォーマンスに影響を与えることなく SAP HANA データベースをバックアップするための組み込みメカニズムを提供します。ストレージベースの NetApp Snapshot バックアップは、 SAP HANA の単一コンテナ、および単一のテナントや複数のテナントを使用する SAP HANA MDC システムで使用可能な、完全にサポートされた統合バックアップ解決策です。
ストレージベースの Snapshot バックアップは、 NetApp SnapCenter Plug-in for SAP HANA を使用して実装されます。これにより、 SAP HANA データベースに標準で搭載されているインターフェイスを使用して、整合性のあるストレージベースの Snapshot バックアップを作成できます。SnapCenter は、各 Snapshot バックアップを SAP HANA バックアップカタログに登録します。そのため、 SnapCenter で作成されたバックアップは、リストア処理とリカバリ処理用に直接選択できる SAP HANA Studio または Cockpit 内に表示できます。
NetApp SnapMirror テクノロジを使用すると、 1 つのストレージシステムで作成された Snapshot コピーを、 SnapCenter で制御されるセカンダリバックアップストレージシステムにレプリケートできます。その後、プライマリストレージ上のバックアップセットごと、およびセカンダリストレージシステム上のバックアップセットごとに、異なるバックアップ保持ポリシーを定義できます。SnapCenter Plug-in for SAP HANA は、不要なバックアップカタログの削除を含め、 Snapshot コピーベースのデータバックアップとログバックアップの保持を自動的に管理します。また、 SnapCenter Plug-in for SAP HANA では、ファイルベースのバックアップを実行することで、 SAP HANA データベースのブロック整合性チェックを実行できます。
次の図に示すように、 NFS マウントを使用して、データベースログをセカンダリストレージに直接バックアップできます。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image5.jpg)
ストレージベースの Snapshot バックアップは、従来のファイルベースのバックアップに比べて大きなメリットをもたらします。これには次のような利点がありますが、これらに限定されるわけではありません。
-
高速バックアップ(数分)
-
ストレージレイヤでのリストア時間(数分)が大幅に短縮され、バックアップの頻度も高まり、 RTO が短縮されます
-
バックアップとリカバリの処理中、 SAP HANA データベースのホスト、ネットワーク、またはストレージのパフォーマンスが低下することはありません
-
ブロックの変更に基づいて、スペース効率と帯域幅効率に優れたセカンダリストレージへのレプリケーションを実行します
SAP HANA のバックアップとリカバリの解決策の詳細については、を参照してください "TR-4614 :『 SAP HANA Backup and Recovery with SnapCenter 』"。
SAP HANA ディザスタリカバリ
SAP HANA ディザスタリカバリは、 SAP HANA システムレプリケーションを使用してデータベースレイヤで実行するか、ストレージレプリケーションテクノロジを使用してストレージレイヤで実行できます。次のセクションでは、ストレージレプリケーションに基づくディザスタリカバリソリューションの概要について説明します。
SAP HANA ディザスタリカバリソリューションの詳細については、を参照してください "TR-4646 :『 SAP HANA Disaster Recovery with Storage Replication 』"。
SnapMirror に基づくストレージレプリケーション
次の図は、同期 SnapMirror レプリケーションを使用してローカル DR データセンターに 3 サイトのディザスタリカバリ解決策を作成し、非同期 SnapMirror を使用してリモート DR データセンターにデータをレプリケートする方法を示しています。
同期 SnapMirror を使用したデータレプリケーションでは、 RPO がゼロになります。プライマリデータセンターとローカル DR データセンター間の距離は約 100km です。
非同期 SnapMirror を使用して、プライマリとローカルの両方の DR サイトで障害が発生した場合のデータ保護を実行します。RPO は、レプリケーションの更新頻度と転送速度によって異なります。理論的には距離は無制限ですが、転送が必要なデータ量とデータセンター間の接続によって制限は異なります。通常の RPO の値は、 30 分から数時間です。
どちらのレプリケーション方法の RTO も、主に DR サイトで HANA データベースを起動してメモリにロードするのに必要な時間に左右されます。1000Mbps のスループットでデータが読み取られることを前提とし、 1TB のデータをロードするには約 18 分かかります。
DR サイトのサーバは、通常運用時に開発 / テストシステムとして使用できます。災害が発生した場合は、開発 / テスト用システムをシャットダウンし、 DR 本番用サーバとして起動する必要があります。
どちらのレプリケーション方法でも、 RPO と RTO に影響を与えることなく DR ワークフローテストを実行できます。FlexClone ボリュームはストレージ上に作成され、 DR テストサーバに接続されます。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image6.png)
同期レプリケーションで StrictSync モードが提供されます。何らかの理由でセカンダリストレージへの書き込みが完了しないと、アプリケーション I/O が失敗し、プライマリストレージシステムとセカンダリストレージシステムが同一になります。プライマリへのアプリケーション I/O は、 SnapMirror 関係のステータスが InSync に戻るまで再開されません。プライマリストレージで障害が発生した場合は、フェイルオーバー後にデータ損失なしでアプリケーション I/O をセカンダリストレージで再開できます。StrictSync モードでは、 RPO は常にゼロです。
NetApp MetroCluster に基づくストレージレプリケーション
次の図は、解決策の概要を示しています。各サイトのストレージクラスタがローカルで高可用性を実現し、本番環境のワークロードに使用されます。各サイトのデータはもう一方のサイトに同期的にレプリケートされ、災害のフェイルオーバー時に使用できます。
![エラー:グラフィックイメージがありません](./../media/saphana_aff_fc_image7.png)