Inline-Deduplizierung, Inline-Deduplizierung, Inline-Komprimierung und Inline-Data-Compaction werden von SAP HANA in einer SSD-Konfiguration unterstützt.

Die Aktivierung von Storage-Effizienzfunktionen in einer HDD-basierten Konfiguration wird nicht unterstützt.

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 bestimmte SAP HANA Systeme oder andere 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.

Die Verwendung der „nur-Snapshots“ Tiering-Politik ist möglich sowie generell die Verwendung von FabricPool an einem Backup-Ziel wie einem SnapVault oder SnapMirror Ziel.

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 sollte die Option „Tiering-minimum-cooling-days“ auf einen Wert gesetzt werden, der Log-Backups, die routinemäßig für die Wiederherstellung benötigt werden, auf der lokalen fast Storage Tier platziert.

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 müssen bereits die Verbindungen zwischen den Storage-Ports (10 GbE oder schneller) und dem Netzwerk vorhanden sein.

Mit HDDs können maximal zwei DS2246 Festplatten-Shelfs oder vier DS224C Festplatten-Shelfs mit einem SAS-Stack verbunden werden, um die erforderliche Performance für die SAP HANA-Hosts zu liefern, wie in der folgenden Abbildung dargestellt. Die Festplatten in jedem Shelf müssen gleichmäßig auf beide Controller des HA-Paars verteilt werden.

Bei SSDs kann maximal ein Platten-Shelf mit einem SAS-Stack verbunden werden, um die erforderliche Performance für die SAP HANA-Hosts zu liefern, wie in der folgenden Abbildung dargestellt. Die Festplatten in jedem Shelf müssen gleichmäßig auf beide Controller des HA-Paars verteilt werden. Mit dem DS224C Festplatten-Shelf können auch Quad-Path-SAS-Verkabelung verwendet werden, ist aber nicht erforderlich.

Im Allgemeinen müssen zwei Aggregate pro Controller konfiguriert werden, unabhängig vom verwendeten Festplatten-Shelf oder der Festplattentechnologie (SSD oder HDD). Für Systeme der FAS2000 Serie genügt ein Datenaggregat.

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 bei der Erstellung einer neuen SVM automatisch ein QoS-Profil erstellt und zugewiesen wurde, entfernen Sie das automatisch erstellte Profil aus der SVM, um die erforderliche Performance für SAP HANA bereitzustellen:

Für SAP HANA Produktionssysteme müssen unterschiedliche LIFs zum Mounten des Daten-Volumes und des Protokoll-Volumes vom SAP HANA-Host verwendet werden. Daher sind mindestens zwei LIFs erforderlich.

Die Daten- und Protokoll-Volume-Mounts verschiedener SAP HANA Hosts können einen physischen Storage-Netzwerk-Port mithilfe derselben LIFs oder mithilfe individueller LIFs für jeden Mount gemeinsam nutzen.

Die maximale Anzahl an Daten- und Protokoll-Volume-Mounts pro physische Schnittstelle sind in der folgenden Tabelle aufgeführt.

Entwicklungs- und Testsysteme können mehr Daten und Volume-Mounts oder LIFs auf einer physischen Netzwerkschnittstelle verwenden.

Für Produktions-, Entwicklungs- und Testsysteme liefert /hana/shared Das Filesystem kann dieselbe LIF wie das Daten- oder Protokoll-Volume verwenden.

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 jeden SAP HANA DB-Host, ein Daten-Volume, ein Protokoll-Volume und ein Volume für /hana/shared Werden konfiguriert. Die folgende Tabelle zeigt eine Beispielkonfiguration für SAP HANA-Systeme mit einem Host.

Die folgende Tabelle zeigt ein Beispiel für die Mount-Point-Konfiguration für ein System mit einem einzelnen Host. Um das Home-Verzeichnis des zu platzieren sidadm Benutzer auf dem zentralen Speicher, der /usr/sap/SID Dateisystem sollte vom gemountet werden SID_shared Datenmenge:

Die folgende Abbildung zeigt die Volume-Konfiguration eines 4+1 SAP HANA-Systems. Die Daten- und Protokoll-Volumes jedes SAP HANA-Hosts werden auf verschiedene Storage-Controller verteilt. Beispiel: Volume SID1_data1_mnt00001 Wird auf Controller A und Volume konfiguriert SID1_log1_mnt00001 Ist auf Controller B konfiguriert

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 mehreren Hosts und vier aktiven Hosts.

Die folgende Tabelle zeigt die Konfiguration und die Bereitstellungspunkte eines Systems mit mehreren Hosts mit vier aktiven SAP HANA Hosts. Um die Home-Verzeichnisse des zu platzieren sidadm Benutzer jedes Hosts im zentralen Speicher, der /usr/sap/SID Dateisysteme werden über eingebunden SID_shared Datenmenge:

Sie müssen die in der folgenden Tabelle aufgeführten Volume-Optionen auf allen SVMs überprüfen und festlegen. Bei einigen Befehlen müssen Sie in den erweiterten Berechtigungsebene in ONTAP wechseln.

Die in der folgenden Tabelle aufgeführten NFS-Optionen müssen verifiziert und auf allen Storage Controllern eingestellt werden.

Für einige der angezeigten Befehle müssen Sie in den erweiterten Berechtigungsebene in ONTAP wechseln.

Die in der folgenden Tabelle aufgeführten NFS-Optionen müssen verifiziert und auf allen SVMs eingestellt werden.

Bei einigen Befehlen müssen Sie in den erweiterten Berechtigungsebene in ONTAP wechseln.

Bei Einsatz von SAP HANA Systemen mit mehreren Hosts und automatischem Host-Failover müssen die Failover-Parameter innerhalb angepasst werden nameserver.ini Wie in der folgenden Tabelle dargestellt. Halten Sie das Standard-Wiederholungsintervall von 10 Sekunden in diesen Abschnitten ein.

Wenn ein Volume erstellt wird, muss das Volume im Namespace gemountet werden. In diesem Dokument gehen wir davon aus, dass der Name des Verbindungspfads dem Namen des Volumes entspricht. Standardmäßig wird das Volume mit der Standardrichtlinie exportiert. Die Exportpolitik kann bei Bedarf angepasst werden.