BEWÄHRTE VORGEHENSWEISEN BEI DER · PDF fileHANA-HWC-ES-1.1 für VMAX3TM und VMAX...

Lösungsleitfaden

BEWÄHRTE VORGEHENSWEISEN BEI DER SPEICHERKONFIGURATION FÜ R DIE SAP HANA TAILORED DATA CENTER INTEGRATION (TDI) AUF EMC VMAX

VMAX 10K, 20K, 40K

VMAX3 (100K, 200K, 400K)

VMAX All Flash 250F/FX, 450F/FX, 850F/FX

EMC Lösungen

Zusammenfassung

Dieser Lösungsleitfaden beschreibt ein Konzept, das Beschränkungen des SAP High Performance Analytical Appliance(HANA)-Modells überwindet. Mithilfe einer maßgeschneiderten Integration des Rechenzentrums (TDI, Tailored Data Center Integration) auf EMC® VMAX® -, VMAX3TM- und VMAX® -All-Flash-Speichersystemen können Kunden HANA in einer vorhandenen, gut etablierten Rechenzentrumsinfrastruktur integrieren und dabei von verschiedenen Vorteilen profitieren.

Oktober 2016

Copyright

2 Bewährte Vorgehensweisen bei der Speicherkonfiguration für die SAP HANA-TDI auf EMC VMAX Lösungsleitfaden

Copyright © 2016 EMC Corporation. Alle Rechte vorbehalten. Veröffentlicht in Deutschland.

Veröffentlicht im Oktober 2016

EMC ist der Ansicht, dass die Informationen in dieser Veröffentlichung zum Zeitpunkt der Veröffentlichung korrekt sind. Die Informationen können jederzeit ohne vorherige Ankündigung geändert werden.

Die Informationen in dieser Veröffentlichung werden ohne Gewähr zur Verfügung gestellt. Die EMC Corporation macht keine Zusicherungen und übernimmt keine Haftung jedweder Art im Hinblick auf die in diesem Dokument enthaltenen Informationen und schließt insbesondere jedwede implizite Haftung für die Handelsüblichkeit und die Eignung für einen bestimmten Zweck aus. Für die Nutzung, das Kopieren und die Verteilung der in dieser Veröffentlichung beschriebenen EMC Software ist eine entsprechende Softwarelizenz erforderlich.

EMC2, EMC, Data Domain, VMAX, VMAX3, VMAX All Flash, Virtual Provisioning und das EMC Logo sind eingetragene Marken oder Marken der EMC Corporation in den USA und/oder anderen Ländern. Alle anderen in diesem Dokument erwähnten Marken sind das Eigentum der jeweiligen Inhaber.

Eine aktuelle Liste der Produkte von EMC finden Sie unter EMC Corporation Trademarks auf emc.com.

Lösungsleitfaden „Bewährte Vorgehensweisen bei der Speicherkonfiguration für die SAP HANA Tailored Data Center Integration (TDI) auf EMC VMAX“

Art.-Nr. XXXX

Haftungsausschluss: Der Inhalt des vorliegenden Dokuments kann vom Inhalt des veröffentlichten Dokuments abweichen.

http://germany.emc.com/legal/emc-corporation-trademarks.htm

Inhalt


Inhalt

Zusammenfassung ................................................................................................................................ 4

Einführung ............................................................................................................................................. 6

Verwenden von EMC VMAX-Arrays für SAP HANA: Allgemeine Aspekte .................................................. 7

Speicherdesignprinzipien für SAP HANA auf VMAX-(10K, 20K, 40K)-Arrays ....................................... 13

Speicherdesignprinzipien für SAP HANA auf VMAX3- und VMAX All Flash-Arrays (100K, 200K, 400K, 250F/FX, 450F/FX, 850F/FX) ............................................................................................................... 17

Speicherkonfiguration und Installation eines HANA-Scale-out-Clusters auf einem VMAX All-Flash-Array: Beispiel .................................................................................................................................... 22

Fazit ................................................................................................................................................... 37

Referenzen ......................................................................................................................................... 38

Zusammenfassung


Zusammenfassung

SAP HANA ist eine In-Memory-Plattform, die lokal (vor Ort) oder in der Cloud bereitgestellt werden kann. Diese bahnbrechende Plattform ist hervorragend für die Durchführung von Echtzeitanalysen und die Entwicklung und Bereitstellung von Echtzeitanwendungen geeignet. Kern dieser Echtzeitdatenplattform ist die HANA-Datenbank.

HANA besteht aus verschiedenen SAP-Softwarekomponenten, die für bewährte Hardware von SAP-Hardwarepartnern optimiert wurden. Vor Ort kann sie in zwei verschiedenen Modellen bereitgestellt werden, wie in Abbildung 1 gezeigt.

Abbildung 1. Das SAP HANA-Appliance-Modell im Vergleich zum TDI-Modell (Bild © SAP SE)

Eine HANA-Appliance umfasst standardmäßig integrierte Speicher-, Rechner- und Netzwerkkomponenten. Die Appliance wird von SAP zertifiziert, durch einen HANA-Hardwarepartner erstellt und mit allen vorinstallierten Softwarekomponenten, einschließlich der Betriebssysteme und der HANA-Software, an die Kunden geliefert.

Der TDI-Ansatz ist offener als das Appliance-Bereitstellungsmodell und bietet mehr Flexibilität. Die HANA-Server müssen nach wie vor die HANA-Anforderungen erfüllen und entsprechend zertifiziert sein. Die Netzwerk- und Speicherkomponenten jedoch können in den Kundenumgebungen gemeinsam genutzt werden. Auf diese Weise können Kunden ihre vorhandenen Unternehmensspeicherarrays für HANA weiterverwenden und HANA nahtlos in den bestehenden Rechenzentrumsbetrieb integrieren (z. B. Disaster Recovery, Datensicherheit, Monitoring und Management), wodurch die Time-to-Value, die Risiken und die Kosten für eine allgemeine Einführung von HANA reduziert werden.

Die in HANA TDI-Bereitstellungen verwendeten Unternehmensspeicherarrays werden von SAP zertifiziert. So ist sichergestellt, dass sie die Performance- und die funktionalen Anforderungen von HANA erfüllen1. Mithilfe des HANA Hardware

1 EMC VMAX-, VMAX3- und VMAX-All-Flash-Arrays sind von SAP zertifiziert.

Geschäftsvorgang

Lösungsüberblick

Zusammenfassung


Configuration Check Tool (hwcct) hat EMC umfassende Tests auf der EMC® VMAX® -Produktreihe und den VMAX® All Flash-Speichersystemen in Ü bereinstimmung mit den folgenden SAP-Zertifizierungsszenarien durchgeführt:

HANA-HWC-ES 1.0für VMAX

HANA-HWC-ES-1.1für VMAX3TM und VMAX All-Flash

Basierend auf den Testergebnissen enthält dieser Lösungsleitfaden Empfehlungen zur Speicherkonfiguration für die VMAX-, VMAX3- und VMAX-All-Flash-Arrays, um die Performanceanforderungen von SAP (d. h. die SAP HANA-TDI-Key-Performance-Indikatoren für Datendurchsatz und Latenz) zu erfüllen und die höchste Verfügbarkeit für die Datenbankpersistenz auf Festplatte sicherzustellen.

Hinweis: SAP empfiehlt, dass TDI-Kunden das hwcct-Tool in ihrer Umgebung ausführen, um sicherzustellen, dass ihre spezifische Implementierung von HANA-TDI die Performancekriterien von SAP erfüllt.

Dieser Lösungsleitfaden beschreibt HANA-TDI-Bereitstellungen in physischen Umgebungen. Wenn Sie vorhaben, HANA in virtualisierten VMware-Umgebungen mit vSphere zu verwenden, finden Sie im EMC Dokument Lösungsleitfaden für die VMware-Virtualisierung von SAP HANA auf EMC Speicher weitere Informationen.

Kunden mit HANA-TDI auf VMAX, VMAX3 und VMAX All-Flash können:

HANA in ein vorhandenes Rechenzentrum integrieren.

mit VMAX Unternehmensspeicher gemeinsam nutzen, um auf bereits verfügbare Konzepte mit mehreren Standorten zurückzugreifen und von etablierten Automatisierungs- und Betriebsprozessen zu profitieren.

ohne großen Aufwand von einem Appliance-basierten Modell auf die VMAX-basierte TDI-Architektur umsteigen und dabei die EMC Services nutzen, um Risiken zu minimieren.

auf bestehende Betriebsprozesse, Kompetenzen und Tools zurückgreifen und die erheblichen Risiken und Kosten im Zusammenhang mit betrieblichen Veränderungen vermeiden.

die Performance- und Skalierungsvorteile von VMAX zur Gewinnung von Echtzeiteinblicken in das gesamte Unternehmen nutzen.

EMC und die Autoren dieses Dokuments begrüßen Ihr Feedback zu der Lösung und Lösungsdokumentation. Senden Sie Ihre Kommentare an [email protected].

Autoren: Werner Katzenberger, Aighne Kearney

Die wichtigsten Vorteile

Wir wissen Ihr Feedback zu schätzen!

mailto:[email protected]

Einführung


Einführung

Vor der Einführung des HANA-TDI-Bereitstellungsmodells galten für Kunden mit dem Appliance-Modell folgende Einschränkungen:

Begrenzte Auswahl an Servern, Netzwerkkomponenten und Speicher

Nutzung der vorhandenen Rechenzentrumsinfrastruktur und der betrieblichen Prozesse nicht möglich

Feste Größen für HANA-Speicherkapazitäten (Speicher war Teil der Appliance)

Wenig Wissen und Kontrolle über die zentralen Komponenten in der HANA-Appliance

Feste Größen für HANA-Server und Speicherkapazitäten, was aufgrund fehlender Kapazität und der Unfähigkeit zur schnellen Reaktion auf unerwarteten Wachstumsbedarf zu höheren Kosten führte

In diesem Leitfaden wird eine Lösung beschrieben, bei der HANA im Rahmen eines TDI-Bereitstellungsszenarios auf VMAX-, VMAX3- und VMAX-All-Flash-Unternehmensspeicher verwendet wird. Die Lösung reduziert die Hardware- und Betriebskosten, senkt die Risiken und bietet mehr Flexibilität bei der Auswahl des Server- und Netzwerkanbieters.

Der Leitfaden enthält Konfigurationsempfehlungen, die auf den SAP-Anforderungen für hohe Verfügbarkeit sowie auf den Performancetests und -ergebnissen basieren, die zur Erfüllung der SAP-Key-Performance-Indikatoren (KPI) für HANA-TDI erforderlich sind.

Dieses Dokument enthält die folgenden Informationen:

Bewährte Vorgehensweisen und Tipps für die Bereitstellung der HANA-Datenbank auf VMAX-, VMAX3- und VMAX-All-Flash-Speichersystemen.

Vorstellung der wichtigsten Technologien der Lösung.

Beschreibung der Konfigurationsanforderungen und Speicherdesignprinzipien für VMAX-, VMAX3- und VMAX-All-Flash-Speicher mit HANA.

Beispiel einer HANA-Scale-out-Installation mithilfe von VMAX-All-Flash-Speichergeräten.

Dieses Dokument richtet sich an Systemintegratoren, System- oder Speicheradministratoren, Kunden, Partner und Mitglieder der EMC Professional Services, die ein VMAX-, VMAX3- oder VMAX-All-Flash-Speicherarray zur Verwendung in einer TDI-Umgebung für HANA konfigurieren müssen.

Zweck der Lösung

Umfang

Zielgruppe

Verwenden von EMC VMAX-Arrays für SAP HANA: Allgemeine Aspekte



In diesem Abschnitt werden allgemeine Aspekte beschrieben, die beim Verbinden von HANA mit VMAX-Arrays beachtet werden sollten. Festplatten, Pools und LUNs werden auf VMAX-Systemen bzw. VMAX3- oder VMAX-All-Flash-Systemen unterschiedlich konfiguriert. Folgendes gilt jedoch für alle Plattformen:

HANA-Kapazitätsanforderungen

Ü berlegungen zum SAN-Netzwerk

HANA-I/O-Muster

Ü berlegungen zur SRDF-Speicherreplikation

Die SAP HANA-Unternehmensspeicherzertifizierung nutzt für VMAX (10K, 20K, 40K) nicht dieselben Zertifizierungsszenarien wie für VMAX3 und VMAX All Flash-Arrays. In diesem Abschnitt werden die Unterschiede beschrieben.

Jeder HANA-Node benötigt für die folgenden Zwecke Speichergeräte und Speicherkapazität:

Betriebssystem-Boot-Image

HANA-Installation

HANA-Persistenz (Daten- und Protokolle)

Backup


Wenn die HANA-Nodes von einem Volume auf dem VMAX-Array starten (d. h. es wird vom Storage Area Network bzw. SAN gestartet), muss die für das Betriebssystem erforderliche Kapazität in die Berechnung der Gesamtkapazität für die HANA-Installation einfließen. Jeder HANA-Node benötigt ca. 100 GB Kapazität für das Betriebssystem. Diese Kapazität umfasst das Verzeichnis /usr/sap/.

Wenn von einem SAN gestartet wird, befolgen Sie die im Abschnitt „Booten von einem SAN“ des EMC Host Connectivity Guide for Linux beschriebenen bewährten Vorgehensweisen.

HANA-Installation (/hana/shared/)

Jeder HANA-Node erfordert Zugriff auf ein Dateisystem, das unterhalb des lokalen Mount-Punkts, /hana/shared/, gemountet ist, und in dem die HANA-Binärdateien sowie Konfigurationsdateien, Traces und Protokolle installiert werden. In einem HANA-Scale-out-Cluster wird ein einziges, gemeinsam genutztes Dateisystem benötigt, das auf jedem Node gemountet werden muss. Die meisten HANA-Installationen verwenden zu diesem Zweck ein NFS-Dateisystem. VMAX3- und VMAX-All-Flash-Arrays können dieses Dateisystem mit der eNAS-Option bereitstellen. Sie können die Größe des Dateisystems /hana/shared/ mit der Formel im Whitepaper Speicheranforderungen für SAP HANA berechnen. In Version 2.7 dieses Whitepapers (Februar 2016) werden die folgenden Formeln verwendet:

HANA-Kapazitätsanforderungen



Einzelner Node (Scale-up):

GrößeInstallation (einzelner Node) = MIN (1 x RAM; 1 TB)

Mehrere Nodes (Scale-out):

GrößeInstallation (Scale-out) = 1 x RAM_eines_aktiven_Node pro 4 aktive Nodes

HANA-Persistenz (Daten und Protokoll)

Die HANA-In-Memory-Datenbank benötigt Festplattenspeicher für die folgenden Zwecke:

Aufrechterhalten der Persistenz der In-Memory-Daten auf der Festplatte, um einen Datenverlust infolge eines Stromausfalls zu verhindern, und automatisches Host-Failover, wobei in Scale-out-Installationen ein Stand-by-HANA-Host die In-Memory-Daten eines ausgefallenen aktiven Hosts übernimmt

Protokollieren von Informationen über Datenänderungen (Redo-Protokoll)

Jeder HANA-Node (Scale-up) und aktive Node (Scale-out) benötigt zwei Festplatten-Volumes, um die In-Memory-Datenbank auf Festplatte (Daten) zu speichern und ein Redo-Protokoll (Protokoll) zu führen. Die Größe dieser Volumes hängt vom angenommenen Gesamtspeicherbedarf der Datenbank und der RAM-Ausstattung des Node ab. Um Ihnen bei der Festplattendimensionierung zu helfen, stellt SAP im Whitepaper Speicheranforderungen für SAP HANA Referenzen auf entsprechende Tools und Dokumente bereit. In Version 2.7 des Whitepaper vom Februar 2016 wird folgende Formel zur Berechnung der Größe des Datenvolume angegeben:

GrößeDaten = 1,2 x Nettofestplattenspeicherplatz für Daten

wobei der Nettofestplattenspeicherplatz für Daten dem voraussichtlichen Gesamtspeicherbedarf der Datenbank plus 20 % freier Speicherplatz entspricht.

Wenn die Datenbank über mehrere Nodes in einem Scale-out-Cluster verteilt ist, teilen Sie den Nettofestplattenspeicherplatz durch die Anzahl der aktiven HANA-Nodes im Cluster. Angenommen, der Nettofestplattenspeicherplatz beträgt 2 TB und das Scale-out-Cluster besteht aus vier aktiven Nodes, dann muss jedem Node ein Datenvolume von 616 GB zugewiesen werden (2 TB / 4 = 512 GB x 1,2 = 616 GB).

Wenn der Nettofestplattenspeicherplatz zum Zeitpunkt der Speicherdimensionierung nicht bekannt ist, empfiehlt EMC, für die Kapazität des Datendateisystems die RAM-Größe des Node plus 20 Prozent freien Speicherplatzes zu verwenden.

Die Größe des Protokollvolume hängt von der RAM-Größe des Node ab. Im Whitepaper Speicheranforderungen für SAP HANA wird die folgende Formel zur Berechnung der Mindestgröße des Protokollvolume empfohlen:



[Systeme ≤ 512 GB ] GrößeRedo-Protokoll = 1/2 x RAM

[Systeme > 512 GB ] GrößeRedo-Protokoll(min) = 512 GB

Backup

HANA unterstützt Backups auf ein Dateisystem oder die Verwendung von SAP-zertifizierten Drittanbietertools. EMC unterstützt Datensicherheitsstrategien für HANA-Backups mit EMC Data Domain® und Networker® . Obwohl es möglich ist, ein HANA-Backup in einem NFS-Dateisystem auf einem VMAX3- oder VMAX All Flash-Array zu erstellen, rät EMC davon ab, die HANA-Datenbank auf demselben Speicherarray zu sichern, auf dem sich auch die primäre Persistenz befindet. Wenn Sie HANA in einem NFS-Dateisystem auf einem anderen VMAX3- oder VMAX All Flash-Array sichern möchten, finden Sie im SAP-Whitepaper zu den Speicheranforderungen weitere Informationen über die Dimensionierung des Backupdateisystems. Die Kapazität hängt nicht nur von Datenvolumen und Häufigkeit der Änderungsvorgänge in der Datenbank ab, sondern auch von den Backupgenerationen, die auf Festplatte vorgehalten werden.

Allgemeine Aspekte der SAN-Konnektivität

Die SAN-Konnektivität, die Host-HBAs, SAN-Ports, Switche und Front-end-Arrayports umfasst, erfordert eine sorgfältige Planung. Die SAP HANA-KPI für TDI-Bereitstellungen erfordern eine maximale Bandbreite von 400 MB/s pro HANA-Node. Wenn beispielsweise 10 Nodes in einem SAN mit einem VMAX-Array verbunden sind, ist eine Gesamtbandbreite von 4.000 MB/s erforderlich. Unter der Annahme, dass ein Front-end-Port mit 8 Gbit/s eine Bandbreite von rund 750 MB/s bereitstellt, sind mindestens 6 dedizierte Front-end-Ports mit 8 Gbit/s erforderlich, um 10 HANA-Nodes zu unterstützen (6 x 750 MB/s = 4.500 MB/s). Bei Verwendung von Front-end-Ports mit 16 Gbit/s sind 3 Ports erforderlich.

Dieser maximale Bandbreitenbedarf tritt nur in dem unwahrscheinlichen Fall ein, dass alle Nodes diesen Bedarf gleichzeitig anmelden, aber die Fähigkeit des Speicherarrays, diese Spitzen-Workload aufrechtzuerhalten, zählt zu den SAP HANA-Zertifizierungskriterien.

Diese Anforderung wirkt sich nicht nur auf die Speicher-Front-end-Konfiguration aus. In diesem Beispiel mit 10 Nodes muss der vollständige Pfad durch das SAN-Netzwerk so konfiguriert werden, dass die maximale Bandbreite unterstützt wird. In einem Multihop-SAN, bei dem mehrere Switche über Inter-Switch Links (ISLs) verbunden sind, muss die Bandbreite der ISLs ebenfalls die erforderliche maximale Bandbreite unterstützen.

Speicherports

Wenn Sie die Speicherkonnektivität unter der Maßgabe von Performance und Verfügbarkeit planen, empfiehlt EMC „in die Breite anstatt in die Tiefe zu gehen“, was bedeutet, dass es besser ist, Speicherports unterschiedlicher Engines und Directors zu verbinden2, anstatt alle Ports eines einzigen Director zu verwenden. Auf diese 2 Jede VMAX-Engine hat zwei redundante Directors.

Ü berlegungen zum SAN-Netzwerk



Weise kann der Speicher weiterhin Host-I/Os bedienen, selbst wenn eine Komponente ausfällt. Eine neue Funktion der VMAX3- und VMAX-All-Flash-Arrays ist die dynamische Core-Zuteilung. Jeder VMAX3-Director stellt Services bereit, z. B. Front-end-Konnektivität, Back-end-Konnektivität oder Datenmanagement. Jeder dieser Services verfügt auf den einzelnen Directors über einen eigenen Satz von Cores. Die Cores werden in Pools zusammengefasst, um CPU-Ressourcen bereitzustellen, die nach Bedarf zugeteilt werden können. Auch wenn zum Beispiel Host-I/Os über einen einzigen Front-end-Port auf dem Director eingehen, steht der Front-end-Pool mit allen CPU-Cores zur Verfügung, um diesen Port zu bedienen. Da I/Os, die bei anderen Directors eingehen, eigene Core-Pools haben, um höchste Performance und Verfügbarkeit zu bieten, empfiehlt EMC, jeden Host mit Ports unterschiedlicher Directors zu verbinden, bevor zusätzliche Ports auf demselben Director verwendet werden.

SAP verlangt, dass der HANA-Workload von HANA-fremden Anwendungen isoliert wird. EMC empfiehlt daher, für HANA dedizierte Front-end-Ports zu verwenden und diese Ports nicht mit HANA-fremden Anwendungen zu teilen.

HBA-Ports

Jeder Hostbusadapter(HBA)-Port (Initiator) erstellt einen Pfad für I/Os zwischen dem Host und dem SAN-Switch, der wiederum mit dem VMAX-Speicher verbunden ist. Es sind immer zwei HBA-Ports erforderlich, vorzugsweise an zwei separaten HBAs. Zwei Ports bieten mehr Konnektivität und ermöglichen außerdem das native Multipathing (DM-MPIO) von Linux für den Lastausgleich und das Failover zwischen HBA-Pfaden.

Persistente HANA-Geräte weisen verschiedene I/O-Muster auf. Weitere Informationen entnehmen Sie dem Whitepaper Speicheranforderungen für SAP HANA.

Datenvolume

Der Zugriff auf das Datenvolume erfolgt hauptsächlich zufällig, wobei die Blockgrößen zwischen 4 K bis 64 M rangieren. Die Daten werden mit parallelen I/Os asynchron auf das Datendateisystem geschrieben. Im Normalbetrieb handelt es sich bei den meisten I/Os auf das Datendateisystem um Schreibvorgänge, nur beim Neustart der Datenbank, bei HANA-Backups, einem automatischen Host-Failover oder dem Lade-/Neuladevorgang einer Spaltenspeichertabelle werden Daten aus dem Dateisystem gelesen.

Protokollvolume

Der Zugriff auf das Protokollvolume erfolgt hauptsächlich sequenziell und mit Blöckgrößen zwischen 4 K bis 1 M. HANA hält einen Puffer von 1 M für das Redo-Protokoll im Arbeitsspeicher bereit. Wenn der Puffer voll ist, wird er synchron auf das Protokollvolume geschrieben. Wenn eine Datenbanktransaktion übernommen wird, bevor der Protokollpuffer voll ist, wird ein kleinerer Block auf das Dateisystem geschrieben. Da Daten synchron auf das Protokollvolume geschrieben werden, ist für die I/O auf das Speichergerät eine niedrige Latenz wichtig, insbesondere für die kleineren Blockgrößen 4 K und 16 K.

HANA-I/O-Muster



Wie beim Datenvolume handelt es sich im normalen Datenbankbetrieb bei den meisten I/Os auf das Protokoll-Volume um Schreibvorgänge. Nur beim Datenbankneustart, einem HA-Failover, einem Protokollbackup und einer Datenbankwiederherstellung werden Daten vom Protokoll-Volume gelesen.

HANA-I/Os können für bestimmte Speicherumgebungen optimiert werden. Die für VMAX-Arrays spezifische Optimierung wird in Optimierung von Datei-I/Os nach der Installation von HANA beschrieben.

HANA unterstützt zwei Replikationstechnologien: die Replikation der Speicher-Volumes mit der Speicherreplikation und die anwendungsbasierte Replikation mit der HANA-Systemreplikation.

EMC hat die Speicherreplikation mithilfe der Symmetrix Remote Data Facility (SRDF) validiert, wie in den folgenden EMC Lösungsleitfäden beschrieben ist:

Business Continuity und Disaster Recovery mit EMC VMAX3 für SAP HANA-TDI-Bereitstellungen

Business Continuity Best Practices für SAP HANA-TDI mit EMC Symmetrix VMAX

Obwohl eine synchrone Speicherreplikation mithilfe von SRDF/S validiert wurde und in HANA-Umgebungen unterstützt wird, ist eine sorgfältige Analyse der Auswirkungen auf die HANA-Protokoll-I/O-Latenz erforderlich. Je nach Entfernung und Netzwerkinfrastruktur zwischen den SRDF/S-Standorten überschreitet die I/O-Latenz möglicherweise den zulässigen Schwellenwert, was die Transaktionsverarbeitung deutlich verlangsamt und in manchen Fällen zu Unterbrechungen oder Out-of-Memory-Situationen führen kann.

SAP nennt für die Latenz bei Speicherreplikationen für I/Os mit kleinen Blöcken (4 K und 16 K) keinen expliziten Schwellenwert, EMC rät jedoch dazu, dass diese Latenzen die von SAP definierten KPI für nicht replizierte Umgebungen nicht erheblich übersteigen sollten.

Wenn die Latenz über SRDF/S in einer Kundenumgebung höher ist und Benutzer Probleme mit der HANA-Performance melden, empfiehlt EMC, auf die asynchrone Replikation über SRDF/A zu wechseln, sofern ein Recovery Point Objective (RPO) über null akzeptabel ist.

Seitdem SAP das TDI-Bereitstellungsmodell eingeführt hat, wurden zwei verschiedene Zertifizierungsszenarien verwendet, um die Performance der HANA-Persistenz (Daten und Protokoll) zu testen und zu validieren, dass das Speicherarray die SAP-KPI für Bandbreite (MB/s) und Latenz (Mikrosekunden) einhält.

HANA-HWC-ES 1.0

Das Zertifizierungsszenario HANA-HWC-ES 1.0 war das erste von SAP bereitgestellte Szenario. Es verwendete das zugrunde liegende Tool fstest zum Erstellen und Validieren von I/O-Vorgängen auf den Dateisystemen. Aus Sicht des Dateisystems führte fstest sequenzielle und zufällige I/O-Vorgänge durch, während die meisten der

Storage-Replikation mit der Symmetrix Remote Data Facility

SAP HANA-Zertifizierungsszenarien

http://germany.emc.com/collateral/technical-documentation/h14466-continuity-vmax3-hana-sg.pdf


http://germany.emc.com/collateral/white-paper/h13149-business-continuity-best-practices-sap-hana.pdf




zufälligen Dateisystem-I/Os vom Speicherarray als sequenzielle I/Os behandelt wurden. So war es möglich, die SAP-KPI mit einer kleineren Anzahl von Festplatten zu erreichen.

Die VMAX 10K-, 20K- und 40K-Arrays wurden mit dem Szenario HANA-HWC-ES 1.0 zertifiziert. Die in diesem Leitfaden aufgeführten Konfigurations- und Skalierbarkeitsempfehlungen für diese Modelle basieren auf dem Szenario HANA-HWC-ES 1.0. Bei der erneuten Validierung eines VMAX 10K, 20K oder 40K an einem Kundenstandort konsultieren Sie den SAP-Hinweis 1943937.

HANA-HWC-ES 1.1

Mit SAP HANA 1.0 SPS 10 und höher hat SAP ein neues Szenario für die Zertifizierung von Unternehmensspeicher eingeführt. Version 1.1 verwendet das zugrunde liegende Tool fsperf zur Ü berprüfung der Dateisystemperformance. Bei fsperf erforderten zufällige I/O-Vorgänge zusätzliche Ressourcen und die KPI ließen sich nur durch Hinzufügen weiterer Festplatten (HDD) oder mit Flash-Laufwerken erzielen.

Die VMAX3-Arrays wurden ursprünglich mit HANA-HWC-ES 1.0 zertifiziert und später dann zusammen mit den VMAX-All-Flash-Arrays mit dem Szenario HANA-HWC-ES 1.1 erneut zertifiziert. Die in diesem Leitfaden aufgeführten Konfigurations- und Skalierbarkeitsempfehlungen basieren auf dem Szenario HANA-HWC-ES 1.1. Bei der erneuten Validierung von VMAX3- oder VMAX-All-Flash-Arrays an einem Kundenstandort konsultieren Sie den SAP-Hinweis 1943937.

Speicherdesignprinzipien für SAP HANA auf VMAX-(10K, 20K, 40K)-Arrays



Die folgenden Konfigurationsempfehlungen gelten für HANA-Produktionssysteme, die auf VMAX 10K-, 20K- und 40K-Unternehmensspeicherarrays bereitgestellt werden. HANA-Produktionssysteme in TDI-Umgebungen müssen den SAP-Performanceanforderungen (KPI) entsprechen und Sie müssen die nachfolgend beschriebenen speziellen Konfigurationsanforderungen erfüllen.

Tabelle 1 enthält Richtlinien für die Schätzung der Anfangszahl von HANA-Produktionshosts, die verbunden werden können. Die Schätzung basiert auf Performancetests, die wir auf einer einzigen VMAX 10K-Engine mit dem SAP-hwcct-Tool (für Szenario HANA-HWC-ES 1.0) durchgeführt haben.

Hinweis: Wir bestimmten die Skalierbarkeit von höheren Modellen und zusätzlichen Engines durch Extrapolieren der VMAX 10K-Testergebnisse für die Performancemerkmale der höheren Modelle.

Die tatsächliche Zahl an HANA-Hosts, die mit einem VMAX-Array in einer Kundenumgebung verbunden werden können, kann abhängig vom tatsächlichen Workload höher oder niedriger als die in Tabelle 1 aufgeführte Anzahl sein. EMC empfiehlt, das HANA-hwcct-Tool aus Szenario HANA-HWC-ES 1.0 in Kundenumgebungen zu verwenden, um die HANA-Performance zu überprüfen und die maximal mögliche Anzahl an HANA-Hosts auf einem bestimmten Speicherarray zu bestimmen.

Tabelle 1. Skalierbarkeit von VMAX 10K, 20K und 40K

VMAX-Modell

Anzahl der verfügbaren Engines

Anzahl der aktiven HANA-Hosts

10K 1 12

2 18

3 24

4 30

20K 1 12

2 20

3 28

4 36

5 44

6 52

7 60

Skalierbarkeit



VMAX-Modell

Anzahl der verfügbaren Engines

Anzahl der aktiven HANA-Hosts

8 68

40K 1 12

2 22

3 32

4 42

5 52

6 62

7 72

8 82

Zusätzlich zu den Angaben im Abschnitt Speicherports gelten besondere Anforderungen, wenn Sie HANA-Nodes mit den Front-end-Director-Ports (FA-Ports) eines VMAX 10K-, 20K- oder 40K-Arrays verbinden.

Auf einem VMAX-Director teilen sich zwei FA-Ports einen dedizierten CPU-Core. Angenommen, FA-1E:0 und FA-1E:1 teilen sich denselben Core. Um eine maximale I/O-Performance für HANA-Bereitstellungen zu erreichen, verwenden Sie auf dem I/O-Modul nur einen FA-Port pro CPU-Core. Sie könnten beispielsweise FA-1E:0 verwenden und FA-1E:1 ungenutzt lassen. Verwenden Sie den benachbarten Port nicht für HANA-fremde Anwendungen. Abbildung 2 und Abbildung 3 zeigen die Rückansicht der VMAX-Engines mit 4-Port-Fibre-Channel-I/O-Modulen (8 Gbit/s) für die Hostverbindung. Die vier Ports heißen 0, 1, 2 und 3. EMC empfiehlt, für die HANA-Konnektivität die mit einem gelben Rechteck gekennzeichneten I/O-Ports (Port 0 und Port 2) zu verwenden, da sich Port 0 und 1 bzw. Port 2 und 3 jeweils einen CPU-Core teilen. Lassen Sie die benachbarten Ports ungenutzt.

Abbildung 2. Rückansicht der VMAX 10K-Engine

FA-Director-/Port-Anforderungen



Abbildung 3. Rückansicht der VMAX 20K- und 40K-Engine

Die VMAX 10K-, 20K- und 40K-Arrays stellen einer Anwendung mithilfe von EMC Virtual ProvisioningTM Speicherkapazität bereit. Die Kapazität wird mithilfe von Thin-Datengeräten (TDATs) zugeteilt und in Thin-Pools auf Grundlage der verwendeten Festplattentechnologie und des RAID-Typs zur Verfügung gestellt. Thin-Geräte (TDEVs) sind für den Host zugängliche Geräte, die an Thin-Pools gebunden und für höchste Performance nativ über den Pool verteilt sind (Striping).

Fully Automated Storage Tiering for Virtual Pools (FAST VP)

FAST verschiebt die Daten in einer VMAX zur Optimierung von Performance und Effizienz von einem Storage Tier auf einen anderen. Die am häufigsten verwendeten Daten werden auf dem schnellsten (und teuersten) Storage Tier gespeichert, die am seltensten verwendeten Daten auf dem langsamsten (und kostengünstigsten) Storage Tier. In HANA-Umgebungen können diese Datenverschiebungsalgorithmen unerwartete Ergebnisse zur Folge haben. HANA verändert Daten im Arbeitsspeicher der Server und schreibt diese, wenn ein Speicherpunkt auf dem Dateisystem erstellt wird, möglicherweise an einen anderen Speicherort im Dateisystem, selbst wenn die Daten im Arbeitsspeicher nicht geändert wurden.

Daher bringt die Verwendung von FAST VP keinen Vorteil bei der HANA-Persistenz, weshalb ein einziger Storage Tier auf einer 10K- oder 15K-Festplatte die bevorzugte Option auf VMAX 10K-, 20K- und 40K-Arrays ist. Die Verwendung von SSDs für den HANA Storage Tier ist optional und nicht erforderlich, um die Performanceanforderungen für das HANA-HWC-ES-1.0-Zertifizierungsszenario zu erfüllen.

Festplatten und Festplattengruppen

Festplattengruppen in einem VMAX-Array bestehen aus Festplatten derselben Technologie, d. h. Fibre Channel , SAS oder SSDs. Festplattengruppen sind im Array vorkonfiguriert oder werden erstellt, wenn Laufwerke zum Array hinzugefügt werden, um die verfügbare Kapazität zu erhöhen. Die Erstellung von Festplattengruppen muss durch den EMC Customer Service erfolgen.

Um den HANA-Workload auf einem gemeinsam genutzten Array weiter von Nicht-HANA-Anwendungen zu isolieren, können Sie eine dedizierte Festplattengruppe für HANA einsetzen. Wägen Sie die Wahl zwischen Workload-Isolierung und Performance

Virtual Provisioning – Ü berlegungen



sorgfältig ab und vermeiden Sie dedizierte HANA-Festplattengruppen mit weniger als 40 Festplatten (HDDs).

Jeder aktive HANA-Node erfordert mindestens zehn Festplatten (HDDs mit 10.000 U/min oder 15.000 U/Min), um die IOPS-Anforderungen basierend auf dem Zertifizierungsszenario SAP HANA-HWC-ES 1.0 zu erfüllen. Für Konfigurationen mit optimaler Performance sollte bei Verwendung von HDDs die Anzahl der Festplatten in einer Festplattengruppe durch 8 teilbar sein.

RAID-Ü berlegungen

Um die beste Schreibperformance für die HANA-Persistenz zu ermöglichen, empfiehlt EMC eine gespiegelte RAID-1-Konfiguration für die TDATs auf Festplatten mit 10.000 U/min oder 15.000 U/min. Bei Verwendung von SSDs wird RAID5 3 + 1 empfohlen.

Thin-Pools

EMC empfiehlt, einen Thin-Pool für alle HANA-Datenvolumes und einen zweiten Thin-Pool für die HANA-Protokollvolumes in der VMAX zu erstellen. Wenn jedoch eine begrenzte Anzahl an Festplatten in kleineren HANA-Umgebungen verfügbar ist, können Sie die Leistung verbessern, indem Sie einen einzigen Thin-Pool für beide Arten von Volumes verwenden. Thin-Pools bestehen aus TDATs. Die Anzahl und Größe der TDATs in einem Thin-Pool hängt von den SAP-HANA-Kapazitätsanforderungen ab und muss gemäß den Best Practices für die VMAX-Konfiguration konfiguriert werden.

Achten Sie beim Erstellen von TDATs darauf, dass 8 Hyper-Volumes (Teilungen) auf jeder Festplatte zugewiesen werden. Passen Sie die TDAT-Größe gemäß der nutzbaren Festplattenkapazität an. Stellen Sie außerdem sicher, dass TDATs auf allen verfügbaren Festplatten erstellt werden.

Beispiel:

64 Festplatten sind verfügbar 512 Hyper-Volumes (64 x 8 = 512)

1 RAID-1-TDAT verfügt über 2 Hyper-Volumes 256 TDATs erstellen (512:2 = 256)

Die Größe der TDATs sollte der nutzbaren Kapazität einer Festplatte geteilt durch 8 entsprechen.

Erstellen Sie Thin-Pools für Daten- und Protokolldateien anhand der Anzahl der TDATs, die die Kapazitätsanforderungen erfüllen.

Meta-Volumes für Daten und Protokoll

Jeder aktive HANA-Host erfordert ein Datenvolume und ein Protokollvolume für die persistenten Dateisysteme. Die Volume-Größen hängen von den HANA-Kapazitätsanforderungen.

Erstellen Sie ein TDEV-Meta-Volume für HANA-Daten mit 32 Mitgliedern.

Erstellen Sie ein TDEV-Meta-Volume für HANA-Protokoll mit 8 Mitgliedern.

Speicherdesignprinzipien für SAP HANA auf VMAX3- und VMAX All Flash-Arrays (100K, 200K, 400K, 250F/FX, 450F/FX, 850F/FX)


VMAX nutzt Masking-Ansichten, um einem Host Speicher zuzuweisen. EMC empfiehlt die Erstellung einer einzigen Masking-Ansicht für jeden HANA-Host (Scale-up) bzw. jedes HANA-Cluster (Scale-out). Eine Masking-Ansicht umfasst Folgendes:

Initiatorgruppe

Portgruppe

Speichergruppe

Initiatorgruppe

Die Initiatorgruppe enthält die Initiatoren (WWNs) der Hostbusadapter (HBAs) auf dem HANA-Host. Verbinden Sie jeden HANA-Host mit dem VMAX-Array mit mindestens 2 HBA-Ports für Redundanz.

Portgruppe

Die Portgruppe enthält die Front-end-Director-Ports, mit denen die HANA-Hosts verbunden sind. Informationen zur Bestimmung der Anzahl der erforderlichen Ports für die HANA-Installation finden Sie unter Speicherports und FA-Director-/Port-Anforderungen.

Speichergruppe

Ein HANA-Scale-out-Cluster nutzt das Shared-Nothing-Konzept für die Persistenz der Datenbank, wobei jeder aktive HANA-Host sein eigenes Paar von Daten- und Protokollvolumes verwendet und während des normalen Betriebs exklusiven Zugriff auf diese Volumes hat. Wenn ein aktiver HANA-Host ausfällt, wird die HANA-Persistenz des ausgefallenen Hosts auf einem Stand-by-Host verwendet. Dies erfordert, dass alle persistenten Volumes für alle HANA-Hosts sichtbar sind, da jeder Host ein aktiver Host oder Stand-by-Host werden kann.

Die VMAX-Speichergruppe einer HANA-Datenbank muss alle persistenten Geräte des Datenbankclusters enthalten. Der HANA-Name-Server und die HANA-Storage-Connector-API verarbeiten Persistenz-Mounting und I/O-Fencing, wodurch sichergestellt wird, dass immer nur ein Node Zugriff auf ein bestimmtes Paar an Daten- und Protokollvolumes hat.

SAP HANA-Installation auf VMAX 10K-, 20K-, 40K-Arrays

Anweisungen hierzu finden Sie unter Vorbereitung der HANA-Nodes und Installieren des HANA-Scale-out-Clusters. Diese Abschnitte beschreiben eine HANA-Installation auf einem VMAX-All-Flash-Array, aber sie können auch als Beispiel für eine Installation auf VMAX 10K-, 20K- und 40K-Arrays verwendet werden.


Die in diesem Abschnitt beschriebenen Konfigurationsempfehlungen gelten für HANA-Systeme, die auf VMAX3- und VMAX All Flash-Unternehmensspeicherarrays

Masking-Ansicht



bereitgestellt werden. HANA-Produktionssysteme in TDI-Umgebungen müssen den SAP-KPIs entsprechen und die nachfolgend aufgeführten Konfigurationsanforderungen erfüllen.

Basierend auf den Performancetests, die wir auf einer VMAX 100K mit einer einzigen Engine und einer VMAX 450F mit einem einzigen V-Brick-Baustein mithilfe des SAP-hwcct-Tools (für HANA-HWC-ES-1.1-Zertifizierung) durchgeführt haben, liefert Tabelle 2 Richtlinien für die Schätzung der anfänglichen Zahl HANA-Produktionshosts, die verbunden werden können.

Hinweis: Wir bestimmten die Skalierbarkeit von höheren Modellen und zusätzlichen Engines und V-Brick-Bausteinen durch Extrapolieren der VMAX 100K- und 450F-Testergebnisse für die Performancemerkmale der höheren Modelle.

Die tatsächliche Zahl der HANA-Hosts, die mit einem VMAX-Array in einer Kundenumgebung verbunden werden können, kann über oder unter der Angabe in Tabelle 2 liegen. Verwenden Sie das HANA-hwcct-Tool mit Szenario HANA-HWC-ES 1.1 in Kundenumgebungen, um die HANA-Performance zu überprüfen und die maximal mögliche Anzahl an HANA-Hosts auf einem bestimmten Speicherarray zu bestimmen.

Tabelle 2. VMAX3- und VMAX-All-Flash-Skalierbarkeit

VMAX3-Modell Engines oder V-Brick-

Bausteine Anzahl der aktiven HANA-Hosts

100K und 250F/FX 1 12

2 20

200K und 450F/FX

1 16

2 28

3 40

4 52

400K und 850F/FX

1 20

2 32

3 44

4 56

5 68

6 80

7 92

8 104

Skalierbarkeit



FAST in VMAX3

Mit VMAX3 wird Fully Automated Storage Tiering (FAST) erweitert und bietet sowohl intelligente Speicherbereitstellung als auch Performancemanagement mithilfe von Service-Level-Zielen (SLOs). SLOs automatisieren die Zuweisung und Verteilung von Anwendungsdaten in den richtigen Datenpool und Storage Tier ohne manuelle Intervention. Im Gegensatz zu FAST VP auf der VMAX 10K, 20K oder 40K, bei denen Datenverschiebung durch Datenalterung ausgelöst wird, sind VMAX3-SLOs mit einer erwarteten durchschnittlichen I/O-Latenz für Lese- und Schreibvorgänge verknüpft. Daher werden sowohl die anfängliche Bereitstellung als auch die laufende Anwendungsperformance automatisch gemessen und basierend auf Compliance mit Storage Tiers und Performancezielen gemanagt. FAST prüft die Speicheraktivität alle 10 Minuten und verschiebt bei Bedarf Daten mit Sub-LUN-Granularität von FAST (5,25 MB – 42 Vielfache von 128 KB). SLOs können jederzeit dynamisch geändert werden (herauf- oder herabgestuft) und FAST überwacht und passt den Datenspeicherort bei Sub-LUN-Granularität über die verfügbaren Storage Tiers an die angegebenen Performanceziele kontinuierlich an. All dies erfolgt automatisch im VMAX3-Speicherarray und erfordert keine komplexe Anwendungs-ILM3-Strategie oder Verwendung von Hostressourcen für die Migration von Daten aufgrund von Performanceanforderungen. Ein Storage Resource Pool (SRP) ist eine Sammlung von Datenpools, die FAST eine Domain für das Management von Kapazität und Performance bereitstellt. Standardmäßig wird ein einziger Standard-SRP ab Werk vorkonfiguriert. Die von FAST vorgenommenen Datenverschiebungen erfolgen innerhalb des SRP. HANA erfordert keinen separaten SRP und kann parallel mit Nicht-HANA-Anwendungen im selben SRP verwendet werden, wenn ordnungsgemäße SLOs eingesetzt werden, wie in Best Practices für SLO und Workload-Typ für HANA beschrieben. Der SRP ist eine Sammlung von Datenpools, die FAST eine Domain für das Management von Kapazität und Performance bereitstellt. Standardmäßig wird ein einziger Standard-SRP ab Werk vorkonfiguriert. Die von FAST vorgenommenen Datenverschiebungen erfolgen innerhalb des SRP.

Es gibt fünf Service-Level-Ziele, die sich in Bezug auf die erwarteten durchschnittlichen Antwortzeitziele unterscheiden (siehe Tabelle 3). Ein zusätzliches optimiertes SLO ist verfügbar, mit dem keine explizite Zielsetzung bei den Antwortzeiten verknüpft ist.

3

Information Lifecycle Management (ILM) bezieht sich auf eine Strategie für das Management von Anwendungsdaten basierend auf Policies. Es umfasst in der Regel komplexe Datenanalyse, Zuordnung und Nachverfolgung.

Service-Level-Ziel-basiertes Provisioning

Service-Level-Ziele und Workload-Typen



Tabelle 3. SLO-Informationen

SLO Erwartete durchschnittliche Antwortzeit

Diamond 0,8 – 2,3 ms

Platinum 3,0 – 4,4 ms

Gold 5,0 – 6,5 ms

Silver 8,0 – 9,5 ms

Bronze 14,0 – 15,5 ms

Optimized (Standardwert)

-

Wenn Sie ein SLO (kein optimiertes SLO) auswählen, können Sie es weiter nach Workload-Typ qualifizieren: Online Transaction Processing (OLTP) oder Decision Support System (DSS). Der OLTP-Workload konzentriert sich auf die Optimierung der Performance für I/Os von kleinen Blöcken, der DSS-Workload konzentriert sich auf die Optimierung der Performance für I/Os von großen Blöcken. Der Workload-Typ kann auch angeben, ob Overhead im Zusammenhang mit Replikation (lokal oder remote) berücksichtigt werden soll. Die Workload-Typqualifizierer für Replikations-Overhead sind OLTP_Rep und DSS_Rep, wobei „Rep“ für repliziert steht. Tabelle 4 führt die verfügbaren Workload-Typen auf.

Tabelle 4. VMAX3-Workload-Typen

Workload Beschreibung

OLTP I/O-Workload (kleiner Block)

OLTP mit Replikation I/O-Workload großer Block mit lokaler oder Remotereplikation

DSS I/O-Workload (großer Block)

DSS mit Replikation I/O-Workload großer Block mit lokaler oder Remotereplikation

Die folgenden SLO-Konfigurationen werden für HANA-Installationen empfohlen. Beachten Sie, dass VMAX All Flash-Arrays nur ein einziges Top-Tier-Diamond-Service-Level bereitstellen.

Best Practices für SLO und Workload-Typ für HANA



HANA-Persistenz (Daten und Protokoll) für HANA-Produktionsinstallationen

Für HANA-Produktionsinstallationen empfiehlt EMC die Verwendung des Diamond-SLO für die HANA-Persistenz (Daten- und Protokoll-Volumes). Obwohl HANA verschiedene Blockgrößen verwendet, empfehlen wir, den OLTP-Workload-Typ anzugeben. Dies sorgt dafür, dass die VMAX3 versucht, die Latenz unter 1 ms zu halten, was eine SAP-Anforderung für kleine Blockgrößen auf dem Protokollvolume ist (4K und 16K). Die Verwendung des Diamond-SLO mit All-Flash-Geräten bietet die folgenden Vorteile für HANA-Produktionsinstallationen:

Reduzierte HANA-Startzeiten, wenn Daten aus dem Datenvolume in den Speicher gelesen werden

Reduzierte automatische Failover-Zeiten für den HANA-Host bei Scale-out-Bereitstellungen, wenn ein Stand-by-Node die Daten von einem ausgefallenen aktiven Node übernimmt

Reduzierte HANA Backupzeiten, wenn der Backupprozess die Daten aus dem Datenvolume lesen muss

Latenzen unter einer Millisekunde für kleine Blockgrößen auf dem Protokollvolume

HANA-Persistenz (Daten und Protokoll) für HANA-Nicht-Produktionsinstallationen

Auch wenn die SAP-Performance-KPI für HANA-Nicht-Produktionsinstallationen nicht gelten, sind diese Installationen wichtige Komponenten in einer SAP-Gesamtlandschaft. EMC empfiehlt die Verwendung des Gold-SLO für alle HANA-Nicht-Produktionsinstallationen.

HANA-Installation (/hana/shared/)

Ein Bronze-SLO ist ausreichend, wenn Sie eNAS in einem VMAX3-Array verwenden, um das NFS-Share für das HANA-Installationsdateisystem bereitzustellen.


Das Betriebssystem-Boot-Image kann sich auch in einem Bronze-SLO befinden.

Was ist, wenn eine vorhandene VMAX3 Diamond-SLO nicht unterstützt?

Wenn ein neues VMAX3-Array für HANA-Umgebungen konfiguriert ist, werden die SSDs mit der angeforderten Kapazität automatisch hinzugefügt, um das Diamond-SLO für HANA-Produktionsinstallationen zu aktivieren. Kunden möchten jedoch eventuell vorhandene VMAX3-Arrays ohne SSDs für HANA verwenden. In diesen Umgebungen können die HANA-Leistung und -Reaktionszeiten beeinträchtigt werden und Vorgänge wie Neustarts, das erneute Laden von Tabellen oder Backups können langsamer als erwartet erfolgen. Auch die Anzahl der HANA-Produktions-Nodes, die mit dem Array verbunden werden können (wie in Tabelle 1 gezeigt) ist niedriger. Verwenden Sie in solchen Fällen den höchsten verfügbaren SLO für HANA.

Speicherkonfiguration und Installation eines HANA-Scale-out-Clusters auf einem VMAX All-Flash-Array: Beispiel


SLO-Ü berlegungen für leistungshungrige Anwendungen und konkurrierende Workloads

In hochgradig konsolidierten Umgebungen konkurrieren HANA und andere Datenbanken und Anwendungen um Speicherressourcen. FAST kann jeder von ihnen die entsprechende Performance bereitstellen, wenn SLOs und Workload-Typen angegeben sind. Durch Verwendung verschiedener SLOs für jede dieser Anwendungen (oder Gruppe von Anwendungen) ist es einfach, eine solche konsolidierte Umgebung zu managen und die SLOs anzupassen, wenn sich die geschäftlichen Anforderungen ändern. Im folgenden Abschnitt werden zusätzliche Arten der Performancesteuerung in einer konsolidierten Umgebung beschrieben.

Host-I/O-Limits und Mehrmandantenfähigkeit

Die QoS-Funktion (Quality of Service), die Host-I/O-Vorgänge begrenzt, wurde in der vorherigen VMAX-Arraygeneration eingeführt. Sie bietet VMAX3-Kunden die Möglichkeit, einer Speichergruppe bestimmte IOPS- oder Bandbreitenlimits aufzuerlegen, unabhängig vom SLO, das dieser Gruppe zugewiesen ist. Das Zuweisen eines Host-I/O-Limits für IOPS zu einer Speichergruppe einer leistungshungrigen HANA-Anwendung mit niedrigen Performanceanforderungen kann beispielsweise sicherstellen, dass Spitzen beim I/O-Bedarf den HANA-Workload und die HANA-Performance nicht beeinträchtigen.


Dieser Abschnitt erläutert:

das Erstellen und Konfigurieren des persistenten Speichers (Daten und Protokoll) auf einem VMAX-All-Flash-Array für ein HANA-Scale-out-Cluster mit drei aktiven Nodes und einem Stand-by-Node (3+1)

das Vorbereiten der HANA-Hosts

das Installieren des HANA-Clusters mithilfe des SAP-Lifecycle-Management-Befehlszeilentools hdblcm

Die Speicherkonfiguration auf VMAX3 100K-, 200K- und 400K-Arrays folgt denselben Schritten. Der einzige Unterschied ist bei der Service-Level-Auswahl, wenn die Speichergruppe erstellt wird. VMAX3-Arrays bieten zusätzliche Service-Level-Optionen für HANA-Installationen: Wählen Sie ein Diamond-Service-Level für Produktionsinstallationen und ein Gold-Service-Level für Nicht-Produktionsinstallationen.



Wir haben die grafische Benutzeroberfläche (GUI) von Unisphere for VMAX verwendet, um alle Speichergeräte, Speichergruppen, Portgruppen, Hostgruppen und die Masking-Ansicht für das HANA-Scale-out-Cluster zu konfigurieren. Führen Sie die folgenden Schritte aus:

1. Melden Sie sich bei Unisphere an und navigieren Sie zum Speichergruppen-Dashboard, wie in Abbildung 4 gezeigt.

Abbildung 4. Speichergruppen-Dashboard

2. Klicken Sie auf die Kachel Total, um die vorhandenen Speichergruppen anzuzeigen (siehe Abbildung 5).

Abbildung 5. Vorhandene Speichergruppen

3. Klicken Sie auf Create SG, um eine neue Speichergruppe für unser HANA-Cluster zu erstellen, wie in Abbildung 6 gezeigt.

Konfiguration des VMAX All-Flash-Arrays



Abbildung 6. Erstellen einer neuen Speichergruppe

Für unser 3+1-HANA-Cluster benötigten wir drei Datenvolumes mit jeweils 1,5 TB und drei Protokoll-Volumes mit jeweils 512 GB. Dafür haben wir eine kaskadierte Speichergruppe mit einer Gruppe auf oberster Ebene (HANA_ABC), eine Untergruppe für alle Datenvolumes (HANA_ABC_D) und eine zweite Untergruppe für alle Protokoll-Volumes (HANA_ABC_L) erstellt. Wir mussten dann die Anzahl und Größe der zu erstellenden Volumes angeben. Bei einem VMAX-All-Flash-Array ist das einzige verfügbare Servicelevel Diamond. Auf VMAX3-Hybrid-Arrays (100K, 200K, 400K) würden wir das Servicelevel Diamond für HANA-Produktionsinstanzen und Gold für HANA-Nicht-Produktionsinstanzen auswählen.

4. Klicken Sie bei Add to Job List auf den Pfeil nach unten und auf Run Now. Die neue kaskadierte Speichergruppe wird erstellt, wie in Abbildung 6 gezeigt.

Abbildung 7. Kaskadierte Speichergruppe

5. Wählen Sie die Speichergruppe HANA_ABC_D aus und klicken Sie auf View Details, um Informationen über die erstellten Volumes anzuzeigen, wie in Abbildung 8 gezeigt.



Abbildung 8. Erstellte Volumes

6. Klicken Sie auf Volumes – 3 im Bereich RELATED OBJECTS, um die Liste der Datenvolumes anzuzeigen. Abbildung 9 zeigt ein Beispiel.

Abbildung 9. Liste der Datenvolumes

7. Notieren Sie sich den WWN des Volume.

8. Wiederholen Sie diesen Schritt für all Ihre Daten- und Protokollvolumes. Der HANA Storage Connector (FcClient) nutzt den WWN zum Identifizieren eines Speicher-LUN. Der WWN ist in der HANA-Datei global.ini angegeben.

Festlegen von Initiatoraliasnamen (Hostnamen und HBAs)

Wählen Sie Host > Initiators. Klicken Sie mit der rechten Maustaste auf den Initiator, wählen Sie Rename Alias aus und geben Sie einen Alias für jeden HANA-Host und HBA-Port (Initiator) an, wie in Abbildung 10 gezeigt. Machen Sie dies nur einmal für jeden Initiator, auch wenn ein Initiator mit mehreren Speicherports verbunden ist.



Abbildung 10. Festlegen von Initatoraliasnamen

In diesem Beispiel ist jeder HBA mit einem Port auf jedem Director (1D und 2D) des VMAX All-Flash-V-Brick-Bausteins verbunden. Notieren Sie sich die Ports, auf denen Ihre Initiatoren angemeldet sind.

Wenn Sie die Initiator-WWNs Ihrer HANA-Nodes nicht kennen, können Sie den folgenden Linux-Befehl auf dem jeweiligen Node ausführen, um die Informationen zu finden:

# systool -c fc_host -v | grep -i port_name

port_name = "0x10000090fa53fd1c"

port_name = "0x10000090fa53fd1d"

Erstellen einer Hostgruppe

1. Wählen Sie Host > Create Host Group aus. Geben Sie einen Namen im Format HANA_ABC ein, wählen Sie die Hosts, die zum HANA-Cluster gehören, aus und klicken Sie auf Add, wie in Abbildung 10 gezeigt.

Abbildung 11. Erstellen von Hostgruppen

2. Klicken Sie bei Add to Job List auf den Pfeil nach unten und wählen Sie Run Now aus. Die Hostgruppe wird erstellt, wie in Abbildung 12 gezeigt.



Abbildung 12. Erstellte Hostgruppe

Erstellen einer Portgruppe

1. Wählen Sie Hosts > Port Groups > Create Portg Group aus. Geben Sie einen Namen ein (z. B. HANA_ABC), wie in Abbildung 13 gezeigt, und markieren Sie die Ports, bei denen Ihre Initiatoren angemeldet sind, indem Sie die STRG-Taste gedrückt halten.

Abbildung 13. Erstellen einer Portgruppe

2. Klicken Sie auf OK. Die in Abbildung 14 gezeigte Warnmeldung wird möglicherweise angezeigt.



Abbildung 14. Warnmeldung zu Portgruppen

3. Klicken Sie aufOK, um zu bestätigen, dass Sie über mehrere Ports vom gleichen Director in der Portgruppe verfügen – in diesem Beispiel FA-1D:28, FA1D:30 und FA-2D:28, FA-2D:30.

Für einen einzelnen Host wird eine 1:1-Beziehung zwischen einem Host-HBA und einem Speicher-Front-end-Port empfohlen. Wir haben jedoch eine Portgruppe für ein HANA-Cluster erstellt und benötigten deshalb den Durchsatz und die Bandbreite für mehrere Hosts.

Erstellen einer Masking-Ansicht

Eine VMAX-Masking-Ansicht kombiniert die Speichergruppe, Portgruppe und Hostgruppe und ermöglicht Zugriff von den HANA-Nodes auf die Speicher-Volumes.

1. Wählen Sie Hosts > Masking View > Create Masking View aus.

2. Geben Sie einen Masking-Ansichtsnamen ein (HANA_ABC) und wählen Sie die Hostgruppe, Portgruppe und Speichergruppe aus, die Sie in den vorherigen Schritten erstellt haben, wie in Abbildung 15 gezeigt.

Abbildung 15. Erstellen einer Masking-Ansicht

Klicken Sie auf OK. Der Masking-Ansicht wird erstellt, wie in Abbildung 16 gezeigt.



Abbildung 16. Masking-Ansicht

Die HANA-Nodes haben nun Zugriff auf die Speicher-Volumes.

Wir haben ein HANA-Scale-out-System mit drei aktiven Nodes und einem Stand-by-Node (3+1) erstellt. In einem HANA-Cluster mit vier Nodes muss jeder Node auf jedes HANA-Gerät zugreifen können. Während des HANA-Starts übernimmt der HANA-Namensserver zusammen mit dem HANA Storage Connector fcClient das Mounten4 der Volumes auf dem richtigen HANA-Node und I/O-Fencing. Das erfordert eine ordnungsgemäße Vorbereitung der HANA-Nodes und der HANA-Datei global.ini vor Durchführung der eigentlichen HANA-Installation. Im folgenden Abschnitt werden diese Schritte erläutert.

In diesem Beispiel wird vorausgesetzt, dass zuvor die Basisinstallation und -konfiguration auf den HANA-Nodes erfolgt ist:

Das Betriebssystem ist installiert und ordnungsgemäß konfiguriert anhand der SAP-Empfehlungen (in diesem Beispiel verwendeten wir SUSE Linux 12 für SAP-Anwendungen)

Ein gemeinsam genutztes HANA-Dateisystem (/hana//shared/) wurde auf einem NAS-System, z. B. einem VMAX3 oder VMAX All-Flash mit eNAS-Funktion, erstellt und auf allen HANA-Nodes gemountet

Natives Linux-Multipathing (DM-MPIO) ist auf den HANA-Nodes installiert

Alle Netzwerkeinstellungen und Bandbreitenanforderungen für die Kommunikation zwischen Nodes sind gemäß den SAP-Anforderungen konfiguriert

SSH-Schlüssel wurden zwischen allen HANA-Nodes ausgetauscht

Systemzeitsynchronisation wurde mit einem NTP-Server konfiguriert

Die HANA-Installations-DVD-ISO-Datei wurde von der SAP-Website heruntergeladen und auf einem gemeinsam genutzten Dateisystem zur Verfügung gestellt

Hinweis: SAP HANA kann nur auf zertifizierter Serverhardware installiert werden. Die Installation muss von einem zertifizierten HANA-Experten ausgeführt werden.

In den folgenden Abschnitten navigieren Sie durch die Schritte für:

Speicherkonfiguration auf den HANA-Nodes

Vorbereiten der HANA-Datei global.ini

Installieren einer HANA-Scale-out-Instanz mit dem HANA-Datenbank-Lifecycle-Management-Befehlszeilentool hdblcm über die Speicher-Volumes, die in den vorherigen Schritten erstellt wurden.

4

Bei Verwendung des HANA Storage Connectors fcClient darf das Gerät nicht automatisch mit /etc/fstab gemountet werden.

Vorbereitung der HANA-Nodes



Natives Linux-Multipathing (DM-MPIO)

Verwenden Sie die folgenden Einträge in der Datei /etc/multipath.conf:

defaults {

user_friendly_names no

}

devices {

device {

vendor "EMC"

product "SYMMETRIX"

getuid_callout "/lib/udev/scsi_id -g -u -d /dev/%n"

features "0"

hardware_handler "0"

path_selector "round-robin 0"

path_grouping_policy "multibus"

rr_weight "uniform"

no_path_retry "fail"

rr_min_io "100"

path_checker "directio"

prio "const"

prio_args ""

flush_on_last_del yes

fast_io_fail_tmo off

dev_loss_tmo 120

}

}

Starten Sie Multipathing nach der Änderung der Datei /etc/multipath.conf mit dem folgenden Befehl:

# service multipath restart

Initialisieren der HANA-Persistenz

Die HANA-Persistenz muss für jeden Node im HANA-Cluster sichtbar sein.

Verwenden Sie entweder den Befehl rescan-scsi-bus.sh oder starten Sie jeden Node neu.

Um zu überprüfen, ob die Volumes sichtbar sind, verwenden Sie die folgenden Befehle auf einem der Nodes:

Auflistung aller 1,5-TB-Datenvolumes:

# multipath -ll | grep -B1 -A5 1.5T

360000970000197000112533030303338 dm-6 EMC,SYMMETRIX

size=1.5T features='1 queue_if_no_path' hwhandler='0' wp=rw

`-+- policy='service-time 0' prio=1 status=active

|- 0:0:0:11 sdm 8:192 active ready running

|- 0:0:4:11 sdcs 70:0 active ready running

|- 1:0:7:11 sdlk 68:288 active ready running

`- 1:0:0:11 sdfs 130:224 active ready running

--

360000970000197000112533030303337 dm-5 EMC,SYMMETRIX



|- 0:0:0:10 sdl 8:176 active ready running

|- 0:0:4:10 sdcr 69:240 active ready running

|- 1:0:7:10 sdlj 68:272 active ready running

`- 1:0:0:10 sdfr 130:208 active ready running



--

360000970000197000112533030303336 dm-18 EMC,SYMMETRIX



|- 0:0:0:9 sdk 8:160 active ready running

|- 0:0:4:9 sdcq 69:224 active ready running

|- 1:0:7:9 sdli 68:256 active ready running

`- 1:0:0:9 sdfq 130:192 active ready running

Auflistung aller 512-GB-Protokollvolumes:

# multipath -ll | grep -B1 -A5 512G

360000970000197000112533030303339 dm-4 EMC,SYMMETRIX

size=512G features='1 queue_if_no_path' hwhandler='0' wp=rw


|- 0:0:0:12 sdn 8:208 active ready running

|- 0:0:4:12 sdct 70:16 active ready running

|- 1:0:7:12 sdll 68:304 active ready running

`- 1:0:0:12 sdft 130:240 active ready running

360000970000196701016533030313841 dm-47 EMC,SYMMETRIX



|- 0:0:1:15 sdaf 65:240 active ready running

|- 0:0:5:15 sddi 71:0 active ready running

|- 1:0:5:15 sdjj 8:464 active ready running

`- 1:0:2:15 sdgu 132:160 active ready running

360000970000197000112533030303342 dm-7 EMC,SYMMETRIX



|- 0:0:0:13 sdo 8:224 active ready running

|- 0:0:4:13 sdcu 70:32 active ready running

|- 1:0:7:13 sdlm 68:320 active ready running

`- 1:0:0:13 sdfu 131:0 active ready running

Die eindeutige Geräte-ID des Multipath-Geräts mit einer vorangehenden 3 muss mit dem WWN der in Unisphere erstellten Volumes übereinstimmen.

Als Nächstes initialisieren Sie die Geräte und erstellen das Linux-XFS-Dateisystem auf jedem der Geräte mit dem folgenden Beispielbefehl:

# mkfs.xfs /dev/mapper/360000970000197000112533030303341

Nachdem alle Dateisysteme erstellt wurden, können Sie das HANA-Scale-out-Cluster installieren.

Bevor Sie das Installationsskript ausführen, bereiten Sie die folgenden beiden Konfigurationsdateien vor:

Eine Datei global.ini mit einem speicherbezogenen Abschnitt, der die HANA-Speicherpartitionen, Mount-Optionen und den zu verwendenden Storage Connector beschreibt

Eine Installationsparameterdatei, die vom hdblcm-Befehlszeilenskript mit angepassten Installationsparametern verwendet wird

Installieren des HANA-Scale-out-Clusters



Vorbereiten der Datei global.ini

Die Installation nutzt die Datei global.ini zum Beschreiben der HANA-Speicherpartitionen und des verwendeten Storage Connectors. Die HANA-zertifizierten EMC Speicherplattformen nutzen alle fcClient, das Bestandteil der SAP-Softwaredistribution ist.

Stellen Sie sicher, dass die Datei global.ini folgenden Inhalt umfasst:

[storage]

ha_provider = hdb_ha.fcClient

partition_*_*__prtype = 5

partition_*_data__mountoptions = -o inode64

partition_*_log__mountoptions = -o inode64,nobarrier

partition_1_data__wwid = 360000970000197000112533030303336

partition_1_log__wwid = 360000970000197000112533030303339





Stellen Sie sicher, dass die Partitionseinträge mit der angezeigten eindeutigen Geräte-ID übereinstimmen. Verwenden Sie dazu den Befehl multipath –ll mit einer vorangehenden 3.

Platzieren Sie die Datei global.ini (dieser Name ist obligatorisch) in einem Verzeichnis auf dem /hana/shared /-Dateisystem, z. B. in /hana/shared/ABC_cfg. Größere HANA-Scale-out-Installationen erfordern zusätzliche Partitionseinträge.

Vorbereitung der Installationsparameterdatei

SAP HANA SPS 07 führte den SAP-HANA-Datenbank-Lifecycle-Manager ein, der durch die gleichzeitige Installation aller Komponenten hohe Effizienz ermöglicht, die Installation automatisiert und Kunden mehr Flexibilität bietet. Im folgenden Beispiel verwendeten wir die hdblcm-Befehlszeilenoberfläche zur Installation unserer HANA 3+1-Scale-out-Cluster.

1. Rufen Sie im gemeinsam genutzten Dateisystem das Verzeichnis HDB_LCM_LINUX_X86_64, in das die HANA-Installations-DVD-ISO-Datei extrahiert wurde, mit dem folgenden Befehl auf:

# cd /<installation media>/DATA_UNITS/HDB_LCM_LINUX_X86_64

2. Erstellen Sie eine Vorlagen-Installationsparameterdatei mit dem folgenden hdblcm-Befehl:

# ./hdblcm --action=install --

dump_configfile_template=ABC_install.cfg

3. Nachdem die Vorlage erstellt wurde, passen Sie die folgenden Parameter in dieser Datei an unsere Umgebung an:

# Directory root to search for components

component_root=/SAPShare/software/SAP_HANA_SPS11_IM/51050506

/



# Components ( Valid values: all | client | es | ets |

lcapps | server | smartda | streaming | rdsync | xs | studio

| afl | pos | sal | sca | sop | trd | udf )

components=server,client

# Installation Path ( Default: /hana/shared )

sapmnt=/hana/shared

# Local Host Name ( Default: server06 )

hostname=C240-08W

# Directory containing a storage configuration

storage_cfg=/hana/shared/ABC_cfg

Hinweis: Die oben genannten Parameter verweisen auf das Verzeichnis, in das Sie die angepasste Datei global.ini abgelegt haben.

# SAP HANA System ID

sid=ABC

# Instance Number

number=00

# System Administrator User ID

userid=1001

# ID of User Group (sapsys)

groupid=79

# Action to be performed ( Default: exit; Valid values:

install | update | extract_components )

action=install

# Additional Hosts

addhosts=C240-03E:storage_partition=2:role=worker,C240-

02C:storage_partition=3:role=worker,C240-2M2:role=standby

Hinweis: Der oben genannte Parameter beschreibt die zusätzlichen Hosts und ihre Rollen in der Scale-out-Installation.

4. In der Parameterdatei können Sie Passwörter für den root-Benutzer, den SAP-Host-Agent-Benutzer (sapadm), den Systemadministrator-Benutzer (<sid>adm) und den Datenbankbenutzer (SYSTEM) angeben. Sie können auch verschlüsselte Passwörter verwenden. Weitere Informationen finden Sie im Installations- und Upgradehandbuch für SAP HANA. Fehlende Passwörter oder Parameter werden vom hdblcm-Installationsverfahren abgefragt.

5. Gehen Sie die gesamte Vorlagendatei durch und geben Sie zusätzliche Parameter an, die möglicherweise für Ihre spezielle Umgebung erforderlich sind.



Installieren des SAP HANA-Scale-out-Clusters mithilfe der hdblcm-Befehlszeile

Nachdem Sie die Datei global.ini und die Installationsparameterdateien erstellt und an Ihre Anforderungen angepasst haben, können Sie die Installation mit folgendem Befehl starten:

# ./hdblcm --action=install –-configfile=ABC_Install.cfg

SAP HANA Lifecycle Management - SAP HANA 1.00.110.00.1447753075

***************************************************************

Scanning Software Locations...

Detected components:

SAP HANA Database (1.00.110.00.1447753075) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_SERVE

R_LINUX_X86_64/server

SAP HANA AFL (incl.PAL,BFL,OFL,HIE) (1.00.110.00.1447766426)

in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_AFL_L

INUX_X86_64/packages

SAP TRD AFL FOR HANA (1.00.110.00.1447766426) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_TRD_A

FL_LINUX_X86_64/packages

SAP HANA Database Client (1.00.110.00.1447753075) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_CLIEN

T_LINUX_X86_64/client

SAP HANA Studio (2.2.8.000000) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_STUDI

O_LINUX_X86_64/studio

SAP HANA Smart Data Access (1.00.6.001.0) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/SAP_HANA_

SDA_10_LINUX_X86_64/packages

SAP HANA XS Advanced Runtime (1.0.9.258635) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/XSA_RT_10

_LINUX_X86_64/packages

XS Monitoring 1 (1.001.1) in

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/XSA_CONTE

NT_10/XSAC_MONITORING-1.1.1.zip

XS Services 1 (1.001.0) in


NT_10/XSAC_SERVICES-1.1.0.zip

SAP Hana Demo Model for XS Advanced 1.0 (1.001.4) in


NT_10/XSAC_SHINE-1.1.4.zip

Collecting information from host 'c240-03e'...

Collecting information from host 'c240-02c'...

Collecting information from host 'c240-2m2'...

Information collected from host 'c240-03e'.

Information collected from host 'c240-2m2'.

Information collected from host 'c240-02c'.

Restrict maximum memory allocation? [n]: n

Enter Certificate Host Name For Host 'c240-08w' [c240-08w]:

Enter Certificate Host Name For Host 'c240-03e' [c240-03e]:

Enter Certificate Host Name For Host 'c240-02c' [c240-02c]:

Enter Certificate Host Name For Host 'c240-2m2' [c240-2m2]:



Enter System Administrator (abcadm) Password:

Confirm System Administrator (abcadm) Password:

Enter Database User (SYSTEM) Password:

Confirm Database User (SYSTEM) Password:

Summary before execution:

=========================

SAP HANA Components Installation

Installation Parameters

Remote Execution: ssh

Installation Path: /hana/shared

Local Host Name: c240-08w

Root User Name: root

Directory containing a storage configuration:

/hana/shared/ABC_cfg

SAP HANA System ID: ABC

Instance Number: 09

Database Mode: single_container

System Usage: custom

Location of Data Volumes: /hana/data/ABC

Location of Log Volumes: /hana/log/ABC

Certificate Host Names: c240-08w -> c240-08w, c240-2m2 ->

c240-2m2, c240-03e -> c240-03e, c240-02c -> c240-02c

System Administrator Home Directory: /usr/sap/ABC/home

System Administrator Login Shell: /bin/sh

System Administrator User ID: 1010

ID of User Group (sapsys): 79

Software Components

SAP HANA Database

Install version 1.00.110.00.1447753075

Location:

/SAPShare/software/SAP_HANA_SPS11_IM/51050506/DATA_UNITS/HDB_SERVE

R_LINUX_X86_64/server

SAP HANA AFL (incl.PAL,BFL,OFL,HIE)

Do not install

SAP TRD AFL FOR HANA

Do not install

SAP HANA Database Client

Do not install

SAP HANA Studio

Do not install

SAP HANA Smart Data Access

Do not install

SAP HANA XS Advanced Runtime

Do not install

Additional Hosts

c240-2m2

Role: Database Standby (standby)

Storage Partition: N/A

c240-03e

Role: Database Worker (worker)

Storage Partition: 2

c240-02c

Role: Database Worker (worker)

Storage Partition: 3

Do you want to continue? (y/n): y



[….]

SAP HANA system installed

You can send feedback to SAP with this form: https://c240-

08w:1129/lmsl/HDBLCM/ABC/feedback/feedback.html

Log file written to '/var/tmp/hdb_ABC_hdblcm_install_2016-04-

17_17.09.22/hdblcm.log' on host 'C240-08W'.

Grundlegend stellt HANA stellt zwei Datei-I/O-Schnittstellen bereit:

Simple FileFür kleine, einfache I/O-Anfragen zu Konfigurationsdateien, Traces usw. Diese Schnittstelle verwendet einfache, plattformunabhängige Wrapper rund um Systemaufrufe.

FileFactory & FileFür große, komplexe Streams von I/O-Anfragen auf den Daten- und Protokollvolumes und für Backup und Recovery. Diese Schnittstelle verwendet synchrone und asynchrone I/O-Vorgänge.

Sie können die HANA-Datei-I/O-Ebene mit Konfigurationsparametern zur Optimierung der Datei-I/Os für ein bestimmtes Speicherarray und Dateisystem (das XFS-Dateisystem von Linux wird auf allen EMC Speicher-LUNs für die HANA-Persistenz verwendet) konfigurieren.

1. Nach der Installation der HANA-Persistenz auf VMAX-LUNs legen Sie für eine optimale I/O-Verarbeitung die folgenden Parameter für die Datei-I/O-Ebene fest:

max_parallel_io_requests=256

async_read_submit=on

async_write_submit_blocks=all

2. Nehmen Sie die Parametereinstellung nach Abschluss der Erstinstallation von HANA vor und verwenden Sie den HANA-Befehl hdbparam als <sid>adm in der Linux-Shell:

# su - <sid>adm

# hdbparam –p # lists current parameter setting

# hdbparam –-paramset fileio.max_parallel_io_requests=256

# hdbparam –-paramset fileio.async_read_submit=on

# hdbparam –-paramset fileio.async_write_submit_blocks=all

Hinweis: Der obigen Anweisungen für die Optimierung der Datei-I/O-Parameter basieren auf SAP HANA 1.0 SPS 11. Bei zukünftigen Versionen von SAP HANA lassen sich diese Parameter möglicherweise in den Konfigurationsdateien festlegen. Informationen zu Updates entnehmen Sie der aktuellen Dokumentation zu SAP HANA.

Optimierung von Datei-I/Os nach der Installation von HANA

Fazit


Fazit

Die Verwendung von SAP HANA in TDI-Bereitstellungen mit EMC VMAX, VMAX3 und VMAX All-Flash-Unternehmensspeicherarrays bietet viele Vorteile, unter anderem eine Reduzierung der Hardware- und Betriebskosten, weniger Risiken und eine Verbesserung der Verfügbarkeit und Performance sowie mehr Flexibilität bei der Auswahl des Hardwareanbieters.

Alle VMAX-Arrays sind von SAP zertifiziert und können für die folgenden HANA-Installationen verwendet werden: Produktions- und Nicht-Produktions-, Single-Node (Scale-up)- und Scale-out-Systeme.

Während unserer Tests mit HANA auf VMAX-Arrays haben wir Folgendes beobachtet:

Das Zertifizierungsszenario SAP HANA-HWC-ES 1.0 erfordert weniger Festplattenressourcen, wie in Speicherdesignprinzipien für SAP HANA auf VMAX-(10K, 20K, 40K)-Arrays beschrieben.

Das Zertifizierungsszenario SAP HANA-HWC-ES 1.1 stellt hinsichtlich der Festplattenkonfiguration höhere Anforderungen.

HANA-Produktionsinstallationen auf VMAX3 und VMAX All-Flash-Systemen setzen SSDs für die HANA-Persistenz voraus.

Die Verwendung von SSDs für die HANA-Persistenz bietet unter anderem folgende große Vorteile:

Die anfängliche Array- und Festplattenkonfiguration kann kapazitätsbasiert erfolgen, ohne sich Gedanken über die Festplattenanzahl machen zu müssen.

HANA startet schneller und das automatische Host-Failover geht ebenfalls schneller vonstatten.

HANA-Backupzeiten werden verkürzt.

Zusammenfassung

Ergebnisse

Referenzen


Referenzen

Die folgenden Dokumente auf germany.emc.com oder im EMC Online Support bieten weitere und relevante Informationen. Der Zugriff auf diese Dokumente hängt von Ihren Anmeldedaten ab. Falls Sie auf ein Dokument nicht zugreifen können, wenden Sie sich an Ihren EMC Vertriebsmitarbeiter.

Leitfaden für die Symmetrix VMAX-Produktreihe (Symmetrix VMAX 10K (Seriennummer xxx987xxxx), VMAX 20K, VMAX 40K)

Produkthandbuch für die VMAX3-Produktreihe mit HYPERMAX OS VMAX 100K, VMAX 200K, VMAX 400K

EMC VMAX All Flash-Produktreihe VMAX 250F, 450F, 850F

Produkthandbuch für VMAX All-Flash für VMAX 450F, VMAX 450FX, VMAX 850F, VMAX 850F mit HYPERMAX OS

Unisphere for VMAX 8.0.3 – Dokumentationssatz

Business Continuity und Disaster Recovery mit EMC VMAX3 für SAP HANA-TDI-Bereitstellungen

Business Continuity Best Practices für SAP HANA-TDI mit EMC Symmetrix VMAX

Lösungsleitfaden für mit VMware virtualisiertes SAP HANA mit EMC Speicher

EMC Hostverbindungsleitfaden für Linux

Die folgende Dokumentation auf der SAP-Website enthält weitere relevante Informationen:

SAP HANA-Masterleitfaden

SAP HANA-Server – Leitfaden für Installation und Aktualisierung

SAP HANA Studio – Leitfaden für Installation und Aktualisierung

Technisches Betriebshandbuch für SAP HANA

SAP HANA-Administrationshandbuch

Webressourcen

Speicheranforderungen für SAP HANA

SAP HANA-Appliance

SAP HANA One

SAP HANA Enterprise Cloud

SAP HANA-TDI (Tailored Data Center Integration)

Hinweis: Die folgende Dokumentation erfordert die Eingabe eines SAP-Benutzernamens und -Passworts.

SAP Hinweis 1943937 – Hardware Configuration Check Tool – zentraler Hinweis

EMC Dokumentation

SAP HANA-Dokumentation

http://germany.emc.com/

https://support.emc.com/

https://germany.emc.com/collateral/TechnicalDocument/docu47591.pdf




https://germany.emc.com/auth/rcoll/dataandspecsheet/h14892-vmax-af-ss.pdf



http://germany.emc.com/collateral/TechnicalDocument/docu59482.pdf






http://germany.emc.com/collateral/technical-documentation/h14721-vmware-virtualized-sap-hana-emc-storage-sg.pdf


http://help.sap.com/hana/

http://scn.sap.com/docs/DOC-62595

http://help.sap.com/hana_appliance

http://help.sap.com/hana_one

http://www.saphana.com/entcloud

http://help.sap.com/saphelp_hanaplatform/helpdata/en/0b/15a92d554c4941a452c9ca127f8c70/content.htm

https://service.sap.com/sap/support/notes/1943937

https://service.sap.com/sap/support/notes/1943937

BEWÄHRTE VORGEHENSWEISEN BEI DER · PDF fileHANA-HWC-ES-1.1 für VMAX3TM und VMAX...

Documents

Transcript of BEWÄHRTE VORGEHENSWEISEN BEI DER · PDF fileHANA-HWC-ES-1.1 für VMAX3TM und VMAX...