So konfigurieren Sie SAP HANA Storage richtig

Einzelner Host oder Cluster?

Eine erweiterbare Installation auf Basis eines einzigen Hosts ist aus der Perspektive einer Speicherzuordnung und eines Verzeichnisplans äußerst einfach. Alternativ kann die Software als ein verteilter skalierbarer Cluster installiert werden – entweder auf physikalischen Servern oder virtuellen Maschinen (VMs).

Ein verteilter Cluster ist potentiell geeigneter (obwohl auch ein einzelner Host skalieren kann), gestaltet aber das Speicher-Management komplex. Für jeden Installationstyp gilt darüber hinaus, dass die Speicheranforderungen durch die Notwendigkeit, Datensicherung hinzuzufügen, komplizierter werden.

Standardmäßig benutzt SAP HANA Speicher für mehrere Zwecke. Die wichtigsten sind die folgenden:

• Das Boot-Image des Betriebssystems – HANA läuft auf Linux (SUSE Linux Enterprise Server oder Red Hat Enterprise Linux).
• Die HANA-Installation – die Laufzeiten ihrer Binärcodes, Skripte, Konfigurationsdateien und so weiter. Dies ist auch der Ort, an dem Trace-Dateien und Profile in der Regel abgelegt werden. In verteilten Systemen besitzt jeder Host seine eigenen Kopien von diesen Daten sowie Informationen über Scale-out-Konfigurationen und deren Entwicklung.
• Daten der Speicherdauer – jeder HANA-Dienst oder -Prozess sorgt für anhaltende In-Memory-Daten, indem geänderte Daten in der Form von Savepoint-Blöcken auf freie Speicherplätze geschrieben werden. Standardmäßig geschieht dies alle fünf Minuten.
• Log-Daten zur Wiederherstellung (re-do Log Files) – jeder HANA-Service zeichnet jede Transaktion auch in seinem eigenen Log-File auf, um die Wiederherstellung der Datenbank ohne Datenverlust zu garantieren.
• Backup – Backups werden in einem regelmäßigen Rhythmus gemacht.

Shared Storage oder Storage auf der Serverseite?

Die Entscheidung, welcher Speichertyp sich am besten für einen langen Lebenszyklus der Daten eignet, ist aus zwei Gründen kompliziert.

Erstens: Die Savepoint-Blöcke und re-do Log Files können deutlich unterschiedliche Blockgrößen benutzen – bis zu 16 MB (oder sogar 64 MB für besonders große Blöcke) für die Savepoint-Blöcke und bis zu ein MB für die re-do Log Files.

Zweitens: Beide, Blöcke und Files, sind Latency-empfänglich und verfügen über unterschiedliche Zugangsmuster, wobei der Datenzugang hauptsächlich willkürlich und der Log-Zugang sequentiell geschieht. Beide sind schreibintensiv, außer während Neustarts, Backups, Reloads und so weiter.

Verteilte Cluster

Das läuft alles darauf hinaus, dass man schnellen und flexiblen Storage benötigt. Oft wird deshalb Flash auf Serverseite (PCIe SSD) empfohlen. Man sollte jedoch beachten, dass Storage auf der Serverseite in einem verteilten Cluster Funktionen wie automatisches Load Balancing und Failover beeinflussen kann – besonders in einer virtualisierten Umgebung. Man kann jedoch auch zu anderen Maßnahmen greifen, wie zum Beispiel zu Virtualisierung und Pooling von Storage auf Serverseite.

Da dies logisch betrachtet ein Shared-Nothing-Ansatz ist, bei dem jeder HANA-Service seine eigenen langfristigen Daten verwaltet, kann man alternativ auch ein Shared Array oder Subsystem verwenden.

Scale-out Cluster sind sowohl share-nothing als auch see-everything: Jeder Knoten hat exklusiven Zugang zu seinen eigenen Daten und den angeschlossenen langfristigen Volumes, aber alle anderen Knoten müssen weiter in der Lage sein, diese Volumes zu sehen. Dies muss so sein, da Auto-Failover auf dem Host darauf beruhen, die Volumes des ausgefallenen Knoten zu einem Standby-Knoten zu verschieben.

Größenanforderungen

Die richtige Memory-Größe zu finden ist eine komplizierte Angelegenheit: Das liegt unter anderem an dem erforderlichen Platz für Zeilen- und Spaltendaten, an Objekten, die dynamisch zur Laufzeit erzeugt werden (wie solche für zeitweilige Tabellen-Duplizierung während Operationen von Delta-Differenzen), an Softwarecode und Caching.

Die Dauer der Datenlebenszyklen für jeden Knoten (Savepoint-Blöcke und re-do Logs) kann durch die Analyse der Tabellen, die SQL benutzen, oder einfach durch die RAM-Kapazität des Knoten berechnet werden, wobei in jedem Fall 20 Prozent Reserve hinzugefügt werden sollten.

Mehr über SAP HANA

• Ob man sich für HANA On-Premises oder in der Cloud entscheidet, die Memory-Größe des Datenbankservers wird die Preisgestaltung beeinflussen.
• Es gibt viele Varianten von SAP HANA in der Cloud, und sie können verwirrend sein. Besonders wichtig sind die Unterschiede zwischen HANA Cloud Platform und HANA Enterprise Cloud sowie ihre Bedeutung für SAP-Installationen.

Bei der Storage-Anschaffung muss man mindestens die doppelte Kapazität für Backups hinzufügen, außerdem muss man Platz für die bereits erwähnten anderen Anforderungen berücksichtigen. Es kann nützlich sein, alle Backups von den Knoten innerhalb eines verteilten Systems auf das gleiche Speichergerät zu schicken. Man sollte sich aber davor hüten, die Backups eines HANA-Knoten auf das gleiche Array zu routen, auf dem seine langfristigen Daten liegen.

Insgesamt gilt: Wenn man die Memory-Kapazität aller Hosts in einem HANA-Cluster zusammenzählt, dann sollte man von der Faustregel ausgehen, dass das Speicher-Subsystem mindestens das Zweieinhalb- bis Dreifache der langfristigen Kapazität beträgt. Wenn man System- oder Speicherreplikation für Disaster Recovery hinzufügt, verdoppelt sich noch einmal die Speicheranforderung – grundsätzlich muss die gleiche Speicherkapazität ebenfalls an dem sekundären Ort zur Verfügung gestellt werden.

Latenz und Bandbreite

Besonders die Log-Prozesse sind bei SAP HANA latenzanfällig, was den Einsatz von synchroner Replikation auf langen Strecken und von Verbindungsmedien mit niedriger Latenz beschränkt. Die anwendungsbasierte Systemreplikation von HANA ist eine etwas teurere Alternative. Eine billigere besteht in der asynchronen Speicherreplikation – sofern man ohne sofortige Wiederherstellung der Daten leben kann.

SAP geht auch von einer Abtrennung des HANA-Workloads von anderen Speicherprozessen aus. Eine TDI-Installation erfordert 400 Mbps pro HANA-Knoten, was über das SAN-Netzwerk mit Overhed zwischen 4 und 5 Gbps bedeutet. Das entspricht etwa einem Inter-Switch-Link mit 16 Gbps Fibre Channel und einem Array-Port für drei Knoten. Während es unwahrscheinlich ist, dass alle Knoten zur gleichen Zeit eine solche Spitze erreichen, besteht SAP für eine HANA-Zertifizierung jedoch darauf.

Jeder Knoten erfordert zwei Fibre-Channel-Ports, vorzugsweise auf getrennten Host-Bus-Adaptern (HBAs), um Load Balancing und Redundanz/Failover auf mehreren Kanälen zu ermöglichen. Zudem wird man in einer Scale-out-Installation verschiedene Zonen einrichten müssen, von denen jede der Reihe nach unterschiedliche Netzwerke abdeckt.

Die erforderlichen Zonen werden für Clients (für die Anwendungsserver und End-User), intern (Datenverkehr auf den Knoten selbst und Replikation), für Storage (was auch das Backup abdeckt) und für Verwaltung (einschließlich der Boot- und vMotion-Netzwerke) benötigt. Für eine TDI-Installation wird man alle vier Zonen einrichten müssen, während eine SAP-HANA-Appliance mit bereits vorkonfigurierten internen und Speicherzonen ausgeliefert wird.

Zu guter Letzt

Man muss sich darüber im Klaren sein, dass SAP kontinuierlich HANA weiterentwickelt und verbessert. Das bedeutet, dass die Kapazitätsanforderungen für Storage und Arbeitsspeicher sich von einer zur nächsten Version ändern können und dass sie sich auch von einer Implementierung zu einer anderen je nach den Daten und den Workloads unterscheiden können.

Daher werden Projekte unterschiedlicher Größe wahrscheinlich externe professionelle Unterstützung benötigen, aber die oben dargestellten Informationen sollten erst einmal ausreichen, das Projekt zu entwerfen und mit den notwendigen professionellen Experten darüber zu verhandeln.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!