In einer SSD-Konfiguration werden Inline-Deduplizierung, Inline-Deduplizierung, Inline-Komprimierung und Inline-Data-Compaction unterstützt.

Die Verwendung von NetApp FlexGroup Volumes wird für SAP HANA nicht unterstützt. Aufgrund der Architektur von SAP HANA bietet die Verwendung von FlexGroup Volumes keinen Vorteil und kann zu Performance-Problemen führen.

Die Verwendung von NetApp Volume Encryption (NVE) und NetApp Aggregate Encryption (NAE) wird bei SAP HANA unterstützt.

Mit QoS lässt sich der Storage-Durchsatz für spezifische SAP HANA Systeme oder für SAP Applikationen ohne SAP Applikationen auf einem gemeinsam genutzten Controller begrenzen. Ein Anwendungsfall wäre, den Durchsatz von Entwicklungs- und Testsystemen zu begrenzen, damit sie bei einem gemischten Setup keinen Einfluss auf die Produktionssysteme haben.

Während des Dimensionierungsprozesses sollten Sie die Performance-Anforderungen eines nicht für die Produktion verwendeten Systems ermitteln. Entwicklungs- und Testsysteme können mit niedrigeren Leistungswerten dimensioniert werden, typischerweise im Bereich von 20 % bis 50 % eines von SAP definierten Produktionssystems-KPI.

Ab ONTAP 9 wird QoS auf Storage-Volume-Ebene konfiguriert und verwendet maximale Werte für Durchsatz (MB/s) und I/O-Menge (IOPS).

Ein großer I/O-Schreibvorgang wirkt sich am stärksten auf die Performance des Storage-Systems aus. Daher sollte die QoS-Durchsatzbegrenzung auf einen Prozentsatz der entsprechenden KPI-Werte für die SAP HANA-Speicherleistung in den Daten- und Protokoll-Volumes gesetzt werden.

NetApp FabricPool darf nicht für aktive primäre Filesysteme in SAP HANA Systemen verwendet werden. Dazu gehören die Dateisysteme für den Daten- und Protokollbereich sowie die /hana/shared File-System. Dies führt zu unvorhersehbarer Performance, insbesondere beim Start eines SAP HANA Systems.

Sie können die reine Snapshot-Tiering-Richtlinie zusammen mit FabricPool an einem Backup-Ziel wie SnapVault oder SnapMirror Ziel verwenden.

FabricPool ist eine gute Option, um Log-Backups auf eine andere Storage Tier zu verschieben. Das Verschieben von Backups beeinträchtigt die für das Recovery einer SAP HANA Datenbank erforderliche Zeit. Daher die Option tiering-minimum-cooling-days Sollte auf einen Wert gesetzt werden, der Log-Backups auflegt, die routinemäßig für die Wiederherstellung nötig sind, auf der lokalen fast Storage Tier.

In der folgenden Übersicht sind die erforderlichen Schritte zur Storage-Konfiguration zusammengefasst. Jeder Schritt wird in den nachfolgenden Abschnitten näher beschrieben. In diesem Abschnitt wird die Storage-Hardware eingerichtet und die ONTAP Software bereits installiert. Außerdem muss die Verbindung der Storage FCP-Ports zur SAN-Fabric bereits vorhanden sein.

Im Allgemeinen müssen zwei Aggregate pro Controller konfiguriert werden, unabhängig davon, welches Platten-Shelf oder Festplattentechnologie (SSD oder HDD) zum Einsatz kommt. Dieser Schritt ist notwendig, damit Sie alle verfügbaren Controller-Ressourcen nutzen können. Für die Systeme der AFF A200 Serie reicht ein Datenaggregat aus.

Die folgende Abbildung zeigt eine Konfiguration mit 12 SAP HANA Hosts, die auf einem 12-GB-SAS-Shelf ausgeführt werden und mit ADPv2 konfiguriert sind. Sechs SAP-HANA-Hosts sind mit jedem Storage-Controller verbunden. Vier separate Aggregate, zwei an jedem Storage Controller, sind konfiguriert. Jedes Aggregat ist mit 11 Festplatten mit neun Daten und zwei Parity-Festplatten-Partitionen konfiguriert. Für jeden Controller stehen zwei Ersatzpartitionen zur Verfügung.

Mehrere SAP Landschaften mit SAP HANA Datenbanken können eine einzige SVM nutzen. Darüber hinaus kann jeder SAP-Landschaft bei Bedarf eine SVM zugewiesen werden, falls diese von verschiedenen Teams innerhalb eines Unternehmens gemanagt werden.

Wenn beim Erstellen einer neuen SVM ein QoS-Profil automatisch erstellt und zugewiesen wird, entfernen Sie dieses automatisch erstellte Profil aus der SVM, um die erforderliche Performance für SAP HANA zu gewährleisten:

Innerhalb der Storage-Cluster-Konfiguration muss eine Netzwerkschnittstelle (LIF) erstellt und einem dedizierten FCP-Port zugewiesen werden. Wenn beispielsweise vier FCP-Ports aus Performance-Gründen erforderlich sind, müssen vier LIFs erstellt werden. Die folgende Abbildung zeigt einen Screenshot der acht LIFs (mit dem Namen fc_*_*) Die auf dem konfiguriert wurden hana SVM:

Während der SVM-Erstellung mit ONTAP 9.8 System Manager können Sie alle erforderlichen physischen FCP-Ports auswählen und automatisch eine LIF pro physischem Port erstellt wird.

Ein FCP-Port-Satz wird verwendet, um zu definieren, welche LIFs von einer bestimmten Initiatorgruppe verwendet werden sollen. In der Regel werden alle für HANA-Systeme erstellten LIFs in demselben Portsatz platziert. Die folgende Abbildung zeigt die Konfiguration eines PortSatzes mit dem Namen 32g, der die vier bereits erstellten LIFs enthält.

Die folgende Abbildung zeigt die Volume-Konfiguration von vier SAP HANA-Systemen mit einem Host. Die Daten- und Protokoll-Volumes jedes SAP HANA Systems werden auf verschiedene Storage Controller verteilt. Beispiel: Volume SID1_data_mnt00001 Wird auf Controller A und Volume konfiguriert SID1_log_mnt00001 Ist auf Controller B konfiguriert Für jedes Volume wird eine einzelne LUN konfiguriert.

Für jeden SAP HANA-Host, ein Daten-Volume, ein Protokoll-Volume und ein Volume für /hana/shared Werden konfiguriert. Die folgende Tabelle zeigt eine Beispielkonfiguration mit vier SAP HANA Single-Host-Systemen.

Die folgende Tabelle zeigt ein Beispiel für die Mount-Point-Konfiguration für ein System mit einem einzelnen Host.

Der Linux LVM kann verwendet werden, um die Leistung zu steigern und um LUN-Größenbeschränkungen zu beheben. Die verschiedenen LUNs einer LVM Volume-Gruppe sollten in einem anderen Aggregat und einem anderen Controller gespeichert werden. Die folgende Tabelle enthält ein Beispiel für zwei LUNs pro Volume-Gruppe.

Beim SAP HANA-Host müssen Volume-Gruppen und logische Volumes erstellt und eingebunden werden, wie in der folgenden Tabelle angegeben.

Die folgende Abbildung zeigt die Volume-Konfiguration eines SAP HANA Systems mit 4+1 und mehreren Hosts. Die Daten-Volumes und Protokoll-Volumes jedes SAP HANA-Hosts werden auf verschiedene Storage-Controller verteilt. Beispiel: Das Volume SID_data_mnt00001 Wird für Controller A und Volume konfiguriert SID_log_mnt00001 Ist auf Controller B konfiguriert Eine LUN ist innerhalb jedes Volumes konfiguriert.

Der /hana/shared Das Volume muss von allen HANA-Hosts zugänglich sein und wird daher mithilfe von NFS exportiert. Obwohl es für die keine spezifischen Performance-KPIs gibt /hana/shared NetApp empfiehlt die Verwendung einer 10-Gbit-Ethernet-Verbindung.

Für jeden SAP HANA-Host werden ein Daten-Volume und ein Protokoll-Volume erstellt. Der /hana/shared Das Volume wird von allen Hosts des SAP HANA-Systems verwendet. Die folgende Tabelle zeigt eine Beispielkonfiguration für ein SAP HANA System mit 4+1 mehreren Hosts.

Die folgende Tabelle zeigt die Konfiguration und die Bereitstellungspunkte eines Systems mit mehreren Hosts mit vier aktiven SAP HANA Hosts.

Der Linux LVM kann verwendet werden, um die Leistung zu steigern und um LUN-Größenbeschränkungen zu beheben. Die verschiedenen LUNs einer LVM Volume-Gruppe sollten in einem anderen Aggregat und einem anderen Controller gespeichert werden.

Die folgende Tabelle zeigt ein Beispiel für zwei LUNs pro Volume-Gruppe für ein 2+1 SAP HANA System mit mehreren Hosts.

Beim SAP HANA-Host müssen Volume-Gruppen und logische Volumes erstellt und eingebunden werden, wie in der folgenden Tabelle angegeben.

Die in der folgenden Tabelle aufgeführten Volume-Optionen müssen geprüft und auf allen SVMs eingestellt werden.

Dieser Abschnitt zeigt eine Beispielkonfiguration mit der Befehlszeile mit ONTAP 9.8 für ein 2+1 SAP HANA mehrere Hostsysteme mit SID FC5 unter Verwendung von LVM und zwei LUNs pro LVM Volume-Gruppe: