ベストプラクティス
アーキテクチャ
変更を提案
PDF
SAP HANA ホストは、冗長 FCP インフラとマルチパスソフトウェアを使用してストレージコントローラに接続されます。スイッチまたはホストバスアダプタ（ HBA ）で障害が発生した場合に、耐障害性に優れた SAP HANA ホスト / ストレージ接続を実現するには、冗長 FCP スイッチインフラが必要です。すべての HANA ホストがストレージコントローラ上の必要な LUN にアクセスできるように、スイッチで適切なゾーニングを設定する必要があります。
ストレージレイヤでは、 FAS 製品ファミリーのさまざまなモデルを使用できます。ストレージに接続される SAP HANA ホストの最大数は、 SAP HANA のパフォーマンス要件によって定義されます。必要なディスクシェルフの数は、 SAP HANA システムの容量とパフォーマンスの要件によって決まります。
次の図は、 8 台の SAP HANA ホストをストレージ HA ペアに接続した構成例を示しています。
このアーキテクチャは、次の 2 つの側面で拡張できます。
-
ストレージコントローラが新しい負荷の下で十分なパフォーマンスを提供し、主要なパフォーマンス指標（ KPI ）を満たすことができると仮定して、 SAP HANA ホストとディスク容量をストレージに追加で接続する。
-
追加の SAP HANA ホスト用にストレージシステムとディスク容量を追加する
次の図は、追加の SAP HANA ホストをストレージコントローラに接続した場合の構成例を示しています。この例では、 16 台の SAP HANA ホストの容量とパフォーマンスの要件を満たすために、さらにディスクシェルフが必要です。合計スループット要件に応じて、ストレージコントローラへの FC 接続を追加する必要があります。
導入した FAS システムストレージモデルに関係なく、次の図に示すように、ストレージコントローラを追加することで SAP HANA 環境を拡張することもできます。
SAP HANA のバックアップ
NetApp ONTAP ソフトウェアには、 SAP HANA データベースをバックアップするための組み込みメカニズムが用意されています。ストレージベースの Snapshot バックアップは、 SAP HANA のシングルコンテナシステムや SAP HANA MDC のシングルテナントシステムで使用可能な、完全にサポートされた統合バックアップ解決策です。
ストレージベースの Snapshot バックアップは、 NetApp SnapCenter Plug-in for SAP HANA を使用して実装されます。このプラグインは、 SAP HANA データベースのインターフェイスを使用して、一貫したストレージベースの Snapshot バックアップを実現します。SnapCenter を使用すると、 Snapshot バックアップが SAP HANA バックアップカタログに登録され、 SAP HANA Studio 内で参照したり、リストアやリカバリ処理用に選択できるようになります。
NetApp SnapVault ソフトウェアを使用すると、プライマリストレージに作成された Snapshot コピーを、 SnapCenter で制御されるセカンダリバックアップストレージにレプリケートできます。プライマリストレージ上のバックアップとセカンダリストレージ上のバックアップには、異なるバックアップ保持ポリシーを定義できます。SnapCenter Plug-in for SAP HANA Database は、 Snapshot コピーベースのデータバックアップとログバックアップの保持について、不要なバックアップカタログの削除も含めて管理します。SnapCenter Plug-in for SAP HANA Database は、ファイルベースのバックアップを実行することで、 SAP HANA データベースのブロック整合性チェックの実行も可能にします。
次の図に示すように、 NFS マウントを使用して、データベースログをセカンダリストレージに直接バックアップできます。
ストレージベースの Snapshot バックアップは、ファイルベースのバックアップに比べて大きなメリットをもたらします。たとえば、次のような利点があります。
-
高速バックアップ（数分）
-
ストレージレイヤでの高速リストア（数分）
-
バックアップ中、 SAP HANA データベースホスト、ネットワーク、またはストレージのパフォーマンスが影響を受けることはありません
-
ブロックの変更に基づいて、スペース効率と帯域幅効率に優れたセカンダリストレージへのレプリケーションを実行します
SnapCenter を使用した SAP HANA のバックアップとリカバリの解決策の詳細については、を参照してください "TR-4614 ：『 SAP HANA Backup and Recovery with SnapCenter 』"。
SAP HANA ディザスタリカバリ
SAP HANA ディザスタリカバリは、 SAP システムレプリケーションを使用してデータベースレイヤで実行するか、ストレージレプリケーションテクノロジを使用してストレージレイヤで実行できます。次のセクションでは、ストレージレプリケーションに基づくディザスタリカバリソリューションの概要について説明します。
SnapCenter を使用した SAP HANA ディザスタリカバリ解決策の詳細については、を参照してください "TR-4646 ：『 SAP HANA Disaster Recovery with Storage Replication 』"。
SnapMirror に基づくストレージレプリケーション
次の図は、同期 SnapMirror レプリケーションを使用してローカル DR データセンターにデータをレプリケートし、非同期 SnapMirror を使用してリモート DR データセンターにデータをレプリケートする、 3 サイトのディザスタリカバリ解決策を示しています。
同期 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 に基づくストレージレプリケーション
次の図は、解決策の概要を示しています。各サイトのストレージクラスタは、ローカルで高可用性を実現し、本番環境のワークロードに使用されます。各サイトのデータはもう一方のサイトに同期的にレプリケートされ、災害のフェイルオーバー時に使用できます。
