アーキテクチャ
変更を提案
PDF
SAP HANA ホストは、冗長 10GbE 以上のネットワークインフラを使用して、ストレージコントローラに接続されます。SAP HANA ホストとストレージコントローラ間のデータ通信は、 NFS プロトコルに基づいています。スイッチまたはネットワークインターフェイスカード（ NIC ）の障害に備え、耐障害性に優れた SAP HANA ホスト / ストレージ接続を実現するには、冗長スイッチングインフラが必要です。
スイッチは、ポートチャネルを使用して個々のポートのパフォーマンスを集約し、ホストレベルでは単一の論理エンティティとして認識される場合があります。
AFF システム製品ファミリーのさまざまなモデルをストレージレイヤで混在させることができるため、拡張が必要になったり、パフォーマンスや容量のニーズが異なる場合があります。ストレージシステムに接続できる SAP HANA ホストの最大数は、 SAP HANA のパフォーマンス要件と、使用されているネットアップコントローラのモデルによって定義されます。必要なディスクシェルフの数は、 SAP HANA システムの容量とパフォーマンスの要件によってのみ決まります。
次の図は、 8 台の SAP HANA ホストをストレージハイアベイラビリティ（ HA ）ペアに接続した構成例を示しています。
次の図は、 VMware vSphere を仮想化レイヤとして使用した例を示しています。
アーキテクチャは、次の 2 つの側面で拡張できます。
-
既存のストレージに SAP HANA ホストとストレージ容量を追加で接続することで、ストレージコントローラが現在の SAP HANA の主要パフォーマンス指標（ KPI ）を満たす十分なパフォーマンスを提供する場合。
-
追加の SAP HANA ホスト用にストレージ容量を追加したストレージシステムを追加する
次の図は、追加の SAP HANA ホストをストレージコントローラに接続した場合の構成例を示しています。この例では、 SAP HANA ホスト 16 台分の容量とパフォーマンスの要件を満たすために、さらにディスクシェルフが必要です。合計スループット要件に応じて、 10GbE 以上の接続をストレージコントローラに追加する必要があります。
次の図に示すように、導入した 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 テクノロジを使用すると、一方のストレージシステムで作成された Snapshot コピーを、 SnapCenter で制御されるセカンダリバックアップストレージシステムにレプリケートできます。その後、プライマリストレージ上のバックアップセットごと、およびセカンダリストレージシステム上のバックアップセットごとに、異なるバックアップ保持ポリシーを定義できます。SnapCenter Plug-in for SAP HANA は、不要なバックアップカタログの削除を含め、 Snapshot コピーベースのデータバックアップとログバックアップの保持を自動的に管理します。また、 SnapCenter Plug-in for SAP HANA では、ファイルベースのバックアップを実行することで、 SAP HANA データベースのブロック整合性チェックを実行できます。
次の図に示すように、 NFS マウントを使用して、データベースログをセカンダリストレージに直接バックアップできます。
ストレージベースの Snapshot バックアップは、従来のファイルベースのバックアップに比べて大きなメリットをもたらします。たとえば、次のような利点があります。
-
高速バックアップ（数分）
-
ストレージレイヤでのリストア時間（数分）が大幅に短縮され、バックアップの頻度が向上するため、 Recovery Time Objective （ RTO ；目標復旧時間）が短縮されます
-
バックアップとリカバリの処理中、 SAP HANA データベースのホスト、ネットワーク、またはストレージのパフォーマンスが低下することはありません
-
ブロックの変更に基づいて、スペース効率と帯域幅効率に優れたセカンダリストレージへのレプリケーションを実行します
|
SAP HANAのバックアップとリカバリのソリューションの詳細については、を参照してください "TR-4614 ：『 SAP HANA Backup and Recovery with SnapCenter 』"。 |
SAP HANA ディザスタリカバリ
SAP HANA ディザスタリカバリ（ DR ）は、 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 は常にゼロです。
MetroCluster に基づくストレージレプリケーション
次の図は、解決策の概要を示しています。各サイトのストレージクラスタがローカルで高可用性を実現し、本番環境のワークロードに使用されます。各サイトのデータはもう一方のサイトに同期的にレプリケートされ、災害のフェイルオーバー時に使用できます。
