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

NetApp FlexGroup Volumeの使用はSAP HANAではサポートされていません。SAP HANAのアーキテクチャ上、FlexGroup Volumeを使用してもメリットはなく、パフォーマンスの問題が発生する可能性があります。

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

QoS を使用すると、特定の SAP HANA システムまたは非 SAP アプリケーションのストレージスループットを共有ユースコントローラ上で制限できます。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 システムの起動時に、予測不可能なパフォーマンスが発生します。

FabricPool や SnapMirror デスティネーションなどのバックアップターゲットで、 Snapshot のみの階層化ポリシーと SnapVault を併用できます。

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

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

一般に、使用するディスクシェルフやディスクテクノロジ（ SSD または HDD ）に関係なく、コントローラごとに 2 つのアグリゲートを設定する必要があります。この手順は、使用可能なすべてのコントローラリソースを使用できるようにするために必要です。

次の図は、 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 に必要なパフォーマンスを確保します。

ストレージクラスタ構成内に、 1 つのネットワークインターフェイス（ LIF ）を作成して専用の FCP ポートに割り当てる必要があります。たとえば、パフォーマンス上の理由から 4 つの FCP ポートが必要な場合は、 4 つの LIF を作成する必要があります。次の図は、SVMに設定された8つのLIFのスクリーンショットを示しています。

ONTAP System Managerを使用したSVMの作成時には、必要なすべての物理FCPポートを選択でき、物理ポートごとに1つのLIFが自動的に作成されます。

igroup は、サーバごとに、または LUN へのアクセスを必要とするサーバのグループに対して設定できます。igroup の構成には、サーバの World Wide Port Name （ WWPN ）が必要です。

「 anlun 」ツールを使用して次のコマンドを実行し、各 SAP HANA ホストの WWPN を取得します。

igroupは、ONTAPクラスタのCLIを使用して作成できます。

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

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

次の表に、シングルホストシステムのマウントポイント構成例を示します。

Linux LVM を使用すると、パフォーマンスを向上させ、 LUN サイズの制限に対処できます。LVM ボリュームグループの各 LUN は、別のアグリゲートおよび別のコントローラに格納する必要があります。次の表に、ボリュームグループごとに 2 つの LUN を使用する例を示します。

次の表に示すように、 SAP HANA ホストで、ボリュームグループと論理ボリュームを作成してマウントする必要があります。

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

「 /hana/shared 」ボリュームは、すべての HANA ホストからアクセスできる必要があり、 NFS を使用してエクスポートされます。「 /hana/shared 」ファイルシステムには特定のパフォーマンス KPI がありませんが、 10Gb のイーサネット接続を使用することを推奨します。

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

次の表に、アクティブな SAP HANA ホストが 4 台あるマルチホストシステムの構成とマウントポイントを示します。

Linux LVM を使用すると、パフォーマンスを向上させ、 LUN サイズの制限に対処できます。LVM ボリュームグループの各 LUN は、別のアグリゲートおよび別のコントローラに格納する必要があります。

次の表に、 2+1 の SAP HANA マルチホストシステムのボリュームグループあたり 2 つの LUN の例を示します。

次の表に示すように、 SAP HANA ホストで、ボリュームグループと論理ボリュームを作成してマウントする必要があります。

NetApp ONTAP System Managerを使用してストレージボリュームとLUNを作成し、それらをサーバとONTAP CLIのigroupにマッピングすることができます。このマニュアルでは、CLIの使用方法について説明します。