ベストプラクティス
アーキテクチャ
変更を提案
PDF
SAP HANA ホストは、冗長 FCP インフラとマルチパスソフトウェアを使用してストレージコントローラに接続されます。スイッチまたはホストバスアダプタ（ HBA ）で障害が発生した場合に、耐障害性に優れた SAP HANA ホスト / ストレージ接続を実現するには、冗長 FCP スイッチインフラが必要です。すべての HANA ホストがストレージコントローラ上の必要な LUN にアクセスできるように、スイッチで適切なゾーニングを設定する必要があります。
AFF システム製品ファミリーのさまざまなモデルをストレージレイヤで混在させることができるため、拡張が必要になったり、パフォーマンスや容量のニーズが異なる場合があります。ストレージシステムに接続できる SAP HANA ホストの最大数は、 SAP HANA のパフォーマンス要件と、使用されているネットアップコントローラのモデルによって定義されます。必要なディスクシェルフの数は、 SAP HANA システムの容量とパフォーマンスの要件によってのみ決まります。
次の図は、 8 台の SAP HANA ホストをストレージ HA ペアに接続した構成例を示しています。
このアーキテクチャは、次の 2 つの側面で拡張できます。
-
既存のストレージに SAP HANA ホストとストレージ容量を追加で接続することで、ストレージコントローラが現在の SAP HANA KPI を満たす十分なパフォーマンスを提供する場合
-
追加の SAP HANA ホスト用にストレージ容量を追加したストレージシステムを追加する
次の図は、追加の SAP HANA ホストをストレージコントローラに接続した場合の構成例を示しています。この例では、 16 台の SAP HANA ホストの容量とパフォーマンスの要件を満たすために、さらにディスクシェルフが必要です。合計スループット要件に応じて、ストレージコントローラへの FC 接続を追加する必要があります。
次の図に示すように、導入した AFF システムとは関係なく、認定済みのストレージコントローラを追加することで、 SAP HANA 環境を拡張して希望するノード密度に合わせることもできます。
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 マウントを使用して、データベースログをセカンダリストレージに直接バックアップできます。
ストレージベースの 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 テストサーバに接続されます。
同期レプリケーションで StrictSync モードが提供されます。何らかの理由でセカンダリストレージへの書き込みが完了しないと、アプリケーション I/O が失敗し、プライマリストレージシステムとセカンダリストレージシステムが同一になります。プライマリへのアプリケーション I/O は、 SnapMirror 関係のステータスが InSync に戻るまで再開されません。プライマリストレージで障害が発生した場合は、フェイルオーバー後にデータ損失なしでアプリケーション I/O をセカンダリストレージで再開できます。StrictSync モードでは、 RPO は常にゼロです。
NetApp MetroCluster に基づくストレージレプリケーション
次の図は、解決策の概要を示しています。各サイトのストレージクラスタがローカルで高可用性を実現し、本番環境のワークロードに使用されます。各サイトのデータはもう一方のサイトに同期的にレプリケートされ、災害のフェイルオーバー時に使用できます。
