SSD 構成の SAP HANA では、インライン重複排除、ボリューム間インライン重複排除、インライン圧縮、インラインコンパクションがサポートされています。

SAP HANAでは、NetApp Volume Encryption（NVE）とNetApp Aggregate Encryption（NAE）の使用がサポートされています。

QoS を使用すると、特定の SAP HANA システムやその他のアプリケーションの共有使用コントローラにおけるストレージスループットを制限できます。1 つのユースケースとして、開発システムとテストシステムのスループットを制限し、混在環境で本番システムに影響を与えないようにすることが挙げられます。

サイジングプロセスでは、非本番システムのパフォーマンス要件を決定する必要があります。開発 / テスト用のシステムは、通常、 SAP で定義されている本番用システム KPI の 20~50% の範囲で、パフォーマンス値を低くしてサイジングすることができます。

ONTAP 9 以降では、ストレージボリュームレベルで QoS が設定され、スループット（ MBps ）と I/O 量（ IOPS ）に最大値が使用されます。

ストレージシステムのパフォーマンスに最大の影響があるのは、大きい書き込み I/O です。そのため、 QoS スループットの制限値として、データボリュームとログボリュームの対応する書き込み SAP HANA ストレージパフォーマンス KPI 値の割合を設定する必要があります。

SAP HANA システムのアクティブなプライマリファイルシステムには、 NetApp FabricPool テクノロジを使用しないでください。これには ' データとログ領域のファイル・システムと '/hana/shared-file システムが含まれますそのため、特に SAP HANA システムの起動時に、予測不可能なパフォーマンスが発生します。

「スナップショットのみ」の階層化ポリシーを使用することも、 NetApp SnapVault や SnapMirror デスティネーションなどのバックアップターゲットで FabricPool を一般的に使用することもできます。

FabricPool は、ログバックアップを別のストレージ階層に移動する場合に適しています。バックアップの移動は、 SAP HANA データベースのリカバリに要する時間に影響します。したがって、「 tiering-minimum-cooling-days 」オプションには、リカバリに必要なログバックアップをローカルの高速ストレージ階層に定期的に配置する値を設定する必要があります。

以下に、必要なストレージ構成手順の概要を示します。各手順の詳細については、以降のセクションで説明します。このセクションでは、ストレージハードウェアがセットアップされており、 ONTAP ソフトウェアがすでにインストールされていることを前提としています。また、ストレージポート（ 10GbE 以上）とネットワークの間の接続がすでに確立されている必要があります。

一般に、使用するディスクシェルフやドライブテクノロジ（ SAS SSD または NVMe SSD ）とは関係なく、コントローラごとに 2 つのアグリゲートを構成する必要があります。この手順は、使用可能なすべてのコントローラリソースを使用できるようにするために必要です。AFF A200 シリーズシステムでは、 1 つのデータアグリゲートで十分です。

次の図は、 ADPv2 を使用した、 12Gb の SAS シェルフで稼働する、 12 台の SAP HANA ホストの構成を示しています。6 台の SAP HANA ホストが各ストレージコントローラに接続されています。各ストレージコントローラに 2 つずつ、合計 4 つのアグリゲートが構成されています。各アグリゲートには、 9 つのデータパーティションと 2 つのパリティディスクパーティションを含む 11 本のディスクが構成されます。各コントローラで、 2 つのスペアパーティションを使用できます。

SAP HANA データベースを使用する複数の SAP ランドスケープでは、単一の SVM を使用できます。SVM は、社内の複数のチームによって管理される場合に備え、必要に応じて各 SAP ランドスケープに割り当てることもできます。

新しい SVM の作成時に自動的に作成されて割り当てられた QoS プロファイルがある場合は、自動的に作成されたこのプロファイルを SVM から削除して、 SAP HANA に必要なパフォーマンスを有効にします。

SAP HANA 本番システムでは、 SAP HANA ホストからデータボリュームとログボリュームをマウントするときに別々の LIF を使用する必要があります。したがって、少なくとも 2 つの LIF が必要です。

異なる SAP HANA ホストのデータボリュームマウントとログボリュームマウントは、同じ LIF を使用するか、マウントごとに個別の LIF を使用することで、物理ストレージネットワークポートを共有できます。

物理インターフェイスごとのデータボリュームマウントとログボリュームマウントの最大数を次の表に示します。

開発 / テスト用システムでは、物理ネットワークインターフェイス上で使用できるデータおよびボリュームのマウントや LIF を増やすことができます。

本番システム ' 開発システム ' およびテスト・システムでは '/hana/shared ファイル・システムは ' データ・ボリュームまたはログ・ボリュームと同じ LIF を使用できます

次の図は、 4 つのシングルホスト SAP HANA システムのボリューム構成を示しています。各 SAP HANA システムのデータボリュームとログボリュームは、異なるストレージコントローラに分散されます。たとえば、ボリューム「 ID1_data_mnt00001 」がコントローラ A で設定され、ボリューム「 ID1_log_mnt00001 」がコントローラ B で設定されているとします

各 SAP HANA ホストには、データボリューム、ログボリューム、「 /hana/shared 」のボリュームが構成されています。次の表は、シングルホスト SAP HANA システムの構成例を示しています。

次の表に、シングルホストシステムのマウントポイント構成例を示します。「 idadm 」ユーザのホーム・ディレクトリを中央ストレージに配置するには、「 /usr/sap/SID 」ファイル・システムを「 S ID_SHARED 」ボリュームからマウントする必要があります。

次の図は、 4+1 の SAP HANA システムのボリューム構成を示しています。各 SAP HANA ホストのデータボリュームとログボリュームは、異なるストレージコントローラに分散されます。たとえば、ボリューム「 ID1_data1_mnt00001 」がコントローラ A に設定され、ボリューム「 ID1_log1_mnt00001 」がコントローラ B に設定されているとします

各 SAP HANA ホストには、 1 個のデータボリュームと 1 個のログボリュームが作成されます。「 /hana/shared 」ボリュームは、 SAP HANA システムのすべてのホストで使用されます。次の表に、 4 つのアクティブホストを持つ、マルチホスト SAP HANA システムの構成例を示します。

次の表に、アクティブな SAP HANA ホストが 4 台あるマルチホストシステムの構成とマウントポイントを示します。各ホストの 'idadm' ユーザのホーム・ディレクトリを中央ストレージに配置するために '/usr/sap/SID' ファイル・システムは 'S ID_SHARED' ボリュームからマウントされます

すべての SVM について、次の表に示すボリュームオプションを確認して設定する必要があります。一部のコマンドについては、 ONTAP で advanced 権限モードに切り替える必要があります。

次の表に示す NFS オプションは、すべてのストレージコントローラで検証および設定する必要があります。この表に示す一部のコマンドについては、 advanced 権限モードに切り替える必要があります。

次の表に示す NFS オプションは、すべての SVM で検証および設定する必要があります。

この表の一部のコマンドについては、 advanced 権限モードに切り替える必要があります。

ホストの自動フェイルオーバーを備えたSAP HANAマルチホストシステムを使用している場合は、 nameserver.ini 次の表を参照してください。
これらのセクション内では、デフォルトの再試行間隔（10秒）を維持してください。

ボリュームを作成するときは、ボリュームをネームスペースにマウントする必要があります。このドキュメントでは、ジャンクションパス名がボリューム名と同じであると想定しています。デフォルトでは、ボリュームはデフォルトポリシーを使用してエクスポートされます。エクスポートポリシーは必要に応じて適用できます。