アーキテクチャ
変更を提案
PDF
SAP HANA ホストは、冗長 10GbE 以上のネットワークインフラを使用して、ストレージコントローラに接続されます。SAP HANA ホストとストレージコントローラ間のデータ通信は、 NFS プロトコルに基づいています。
スイッチまたはネットワークインターフェイスカード（ NIC ）に障害が発生した場合に、耐障害性に優れた SAP HANA ホスト / ストレージ接続を実現するために、冗長スイッチングインフラを推奨します。スイッチは、ポートチャネルを使用して個々のポートのパフォーマンスを集約し、ホストレベルでは単一の論理エンティティとして認識される場合があります。
FAS システム製品ファミリーのさまざまなモデルをストレージレイヤで混在させることができるため、拡張が必要になったり、パフォーマンスや容量のニーズが異なる場合があります。ストレージシステムに接続できる SAP HANA ホストの最大数は、 SAP HANA のパフォーマンス要件と、使用されているネットアップコントローラのモデルによって定義されます。必要なディスクシェルフの数は、 SAP HANA システムの容量とパフォーマンスの要件によってのみ決まります。次の図は、 8 台の SAP HANA ホストをストレージハイアベイラビリティ（ HA ）ペアに接続した構成例を示しています。
次の図は、 VMware vSphere を仮想化レイヤとして使用した例を示しています。
アーキテクチャは、次の 2 つの側面で拡張できます。
-
既存のストレージに SAP HANA ホストやストレージ容量を追加で接続することで、ストレージコントローラが現在の SAP 主要パフォーマンス指標（ KPI ）を満たす十分なパフォーマンスを提供する場合
-
追加の SAP HANA ホスト用にストレージ容量を追加したストレージシステムを追加する
次の図は、追加の SAP HANA ホストをストレージコントローラに接続した場合の構成例を示しています。この例では、 SAP HANA ホスト 16 台分の容量とパフォーマンスの両方の要件を満たすために、さらにディスクシェルフが必要です。合計スループット要件に応じて、ストレージコントローラへの 10GbE （以上）接続を追加する必要があります。
導入した FAS システムとは関係なく、任意の認定済みストレージコントローラを追加して、希望するノード密度に合わせて 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 データベースのホスト、ネットワーク、またはストレージのパフォーマンスが低下することはありません
-
ブロックの変更に基づいて、スペース効率と帯域幅効率に優れたセカンダリストレージへのレプリケーションを実行します
SnapCenterを使用した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 レプリケーションを使用してローカルのディザスタリカバリデータセンターにデータをレプリケートする 3 サイトのディザスタリカバリ解決策と、非同期 SnapMirror を使用してリモートのディザスタリカバリデータセンターにデータをレプリケートする様子を示します。
同期 SnapMirror を使用したデータレプリケーションでは、 RPO がゼロになります。プライマリとローカルのディザスタリカバリデータセンター間の距離は約 100km です。
プライマリとローカルの両方のディザスタリカバリサイトで障害が発生した場合の保護は、非同期 SnapMirror を使用して、第 3 のリモートディザスタリカバリデータセンターにデータをレプリケートすることで実現されます。RPO は、レプリケーションの更新頻度と転送速度によって異なります。理論的には距離は無制限ですが、転送が必要なデータ量とデータセンター間の接続によって制限は異なります。通常の RPO の値は、 30 分から数時間です。
どちらのレプリケーション方法の RTO も、主に、 HANA データベースをディザスタリカバリサイトで開始してデータをメモリにロードするのに必要な時間に左右されます。1000Mbps のスループットでデータが読み取られることを前提とし、 1TB のデータをロードするには約 18 分かかります。
通常の運用中は、ディザスタリカバリサイトのサーバを開発 / テストシステムとして使用できます。災害が発生した場合は、開発 / テストシステムをシャットダウンし、ディザスタリカバリ本番用サーバとして起動する必要があります。
どちらのレプリケーション方法でも、 RPO と RTO に影響を与えることなくディザスタリカバリのワークフローテストを実行できます。FlexClone ボリュームはストレージ上に作成され、ディザスタリカバリテスト用サーバに接続されます。
同期レプリケーションで StrictSync モードが提供されます。何らかの理由でセカンダリストレージへの書き込みが完了しないと、アプリケーション I/O が失敗し、プライマリストレージシステムとセカンダリストレージシステムが同一になります。プライマリへのアプリケーション I/O は、 SnapMirror 関係のステータスが InSync に戻るまで再開されません。プライマリストレージで障害が発生した場合は、フェイルオーバー後にセカンダリストレージでアプリケーション I/O を再開できます。データ損失は発生しません。StrictSync モードでは、 RPO は常にゼロです。
MetroCluster に基づくストレージレプリケーション
次の図は、解決策の概要を示しています。各サイトのストレージクラスタがローカルで高可用性を実現し、本番環境のワークロードに使用されます。各サイトのデータはもう一方のサイトに同期的にレプリケートされ、災害のフェイルオーバーが発生した場合に使用できます。
