SAP-Virtualisierung – Der Blick unter die Haube

Die Vorteile der Virtualisierung im SAP- Umfeld sind bekannt. Kostensenkungen, kürzere Releasezyklen, eine höhere Flexibilität und das Klonen selbst großer SAP-Systeme innerhalb von Minuten zur Vorbereitung und Implementierung von Upgrades etc. sind im Grunde unschlagbare Argumente.

Und dennoch zweifeln viele App-Owner an deren Gewicht, da sie vor allem die Leistungsdaten im laufenden Betrieb und den Schutz vor Datenverlusten vor Augen haben.

Und sie haben nicht unrecht damit, denn schließlich kommt es entscheidend darauf an, dass die Anwender produktiv mit den verschiedenen SAP-Apps arbeiten und die geschäftlichen Aufgaben erfüllen können.

Eine virtualisierte SAP-Landschaft muss daher beweisen, dass die Bedenken der Applikationsverantwortlichen unbegründet sind. Das gilt auch für SAP-Systeme inklusive Hana-, S/4- und NetWeaver-Umgebungen, die auf der HCI-Software von Nutanix aufsetzen.

Es lohnt sich deshalb ein Blick sozusagen „unter die Haube“, um besser zu verstehen, dass die oben skizzierten Vorteile der virtualisierten SAP-Landschaften nicht zulasten der Performance im laufenden Betrieb gehen.

In der Nutanix-Software lassen sich beliebige Anwendungskombinationen im eigenen Rechenzen­trum betreiben und diese können zudem in Größenordnungen skalieren, wie sie ansonsten nur beim Betrieb in einer Public Cloud möglich sind.

Dabei liefert die Plattform sehr hohe Werte in Bezug auf den Ein-/Ausgabedurchsatz (gemessen in IOPS, also Ein-/Ausgabeoperationen pro Sekunde) und gleichzeitig nur sehr geringe Verzögerungen bei den Antwortzeiten.

Messungen bei Nutanix haben belegt, dass es besser ist, die Anzahl der virtuellen Maschinen (VMs) mit Datenbanken zu erhöhen, um so alle Vorteile aus der Performance der Plattform zu ziehen, anstatt eine große Anzahl von Datenbankinstanzen in einer einzelnen VM zum Einsatz zu bringen.

Was den Ein-/Ausgabedurchsatz angeht, liefert Nutanix über seine „Distributed Storage Fabric“ (DSF) die nötigen Durchsatzwerte und Transaktionsanforderungen selbst von sehr komplexen Transaktions- und Analytikdatenbanken inklusive Hana.

Skalierung und Datenlokalität

Die komplette Architektur der hyperkonvergenten Softwareinfrastruktur von Nutanix folgt einem „Web-Scale“-Ansatz (vgl. Abbildung 1, Seite 47): Es kommen Knoten mit sehr hoher Rechenleistung, sprich Server zum Einsatz. Auf den Knoten arbeiten Standard-Hypervisoren.

Dazu zählen VMwares vSphere/ESXi, Microsofts Hyper-V oder der für NetWeaver, Hana und S/4 zertifizierte Hypervisor Nutanix AHV. Die Hardware eines derartigen Knotens besteht aus Prozessoren, Arbeitsspeicher und lokalen Speicherkomponenten – das können Flash-basierte SSDs sein und/oder SATA-Festplatten sowie NVMe-Storage mit hohen Speicherkapazitäten.

Auf jedem dieser Knoten laufen virtuelle Maschinen, ganz so wie bei einem üblichen Hostsystem für VMs. Zudem ist aber noch eine Control-VM pro Knoten im Einsatz, die alle Nutanix-relevanten Funktionen bereitstellt.

Diese Zwischenschicht bildet die DSF und ist damit verantwortlich, dass alle lokalen Storage-Komponenten allen Knoten sozusagen in Form eines einheitlichen Pools bereitgestellt werden.

Man kann sich die DSF auch als eine Art virtuelles Speichergerät vorstellen, das die lokalen SSDs und Festplatten allen Knoten (über das NFS- oder das SMB-Protokoll) für die Ablage der Daten aus den verschiedenen VMs anbietet. Die einzelnen VMs in einem Cluster schreiben die Daten in die DSF, als ob es sich dabei um einen normalen gemeinsamen Speicher handeln würde.

Dabei verfolgt die DSF eine wichtige Aufgabe: Sie legt die Daten immer möglichst „nahe“ an der betreffenden VM ab. Das wird durch die möglichst lokale Speicherung erledigt: Läuft eine VM auf dem Knoten A, werden üblicherweise auch die zugehörigen Daten von dieser VM auf dem Knoten A gespeichert.

Das führt dazu, dass eine möglichst hohe Zugriffsgeschwindigkeit auf die Daten erzielt wird, ohne dass dazu hohe Aufwände bei den Storage- Komponenten anfallen.

Ergänzt wird dieses Prinzip der Datenlokalität um eine redundante Datenhaltung, wenn die Daten hochverfügbar sein sollen und deshalb auf mehreren Knoten abgelegt werden.

Die Infrastruktur auf Basis der HCI-Software von Nutanix skaliert aufgrund dieses Konzepts linear von einer Konfiguration mit nur drei Knoten bis hin zu beliebig großen Knotenzahlen.

Das bringt den Unternehmen große Vorteile, denn durch das Hinzufügen von weiteren Knoten kann mit nur wenigen Klicks der Verbund extrem weiter anwachsen, ohne dass man sich zusätzliche Überlegungen für die Verbindung der Knoten untereinander machen müsste.

Zudem bietet die DSF eine Vielzahl von wichtigen Datenverwaltungsfunktionalitäten, wie etwa das Cluster-weite „Data Tiering“, bei dem die Daten je nach Zugriffshäufigkeit – „hot data“ versus „cold data“ – auf schnellere oder langsamere Speichergeräte automatisch verlagert werden.

Datenfluss und Speicherfunktionen

Wer den Ein-/Ausgabepfad beim Zugriff auf die Daten in der DSF skizzieren möchte, der erkennt drei logische Bereiche: das OpLog, den Extent Store und den Content Cache (auch als Unified Cache bezeichnet; vgl. Abbildung 2, Seite 48).

Der OpLog-Bereich liegt sozusagen über der SSD- und NVMe-Speicherebene, der Extent Store deckt einen Teil des SSD- sowie NVMe- und einen Teil des Festplattenspeichers ab. Der Content Cache dagegen liegt über dem SSD- sowie NVMe- und dem Arbeitsspeicherbereich.

Der Bereich des OpLogs agiert als ein Schreibpuffer für die Ein-/Ausgabeaufträge (vergleichbar mit einem Dateisystem-Journal), die zum Beispiel von den VMs auf einem Knoten ausgegeben werden. Diese I/O-Aufträge werden somit im Bereich des SSD-basierten Speichers abgelegt.

Damit werden diese Schreibaufträge mit hoher Geschwindigkeit abgewickelt. Zudem werden sie vom OpLog aus auch auf andere Knoten in einem Cluster repliziert. Das sorgt für zuverlässige Datenverfügbarkeit – auch wenn zum Beispiel ein Knoten komplett ausfällt.

Der OpLog-Bereich erlaubt es zudem, dass Burst-artige Random-Schreib­aufträge angenommen und mit anderen Schreibaufträgen zusammengefügt werden, um sie danach sequentiell an den „Extent Store“ zu übergeben. Dieser Bereich umfasst SSD-, NVMe- und Festplattenspeicher und hier werden auch alle Speicheraktionen ausgeführt.

Im Extent Store befindet sich der ILM, der Information Lifecycle Manager. Dieser ist dafür verantwortlich, den optimalen Speicherplatz für die Daten zu finden. Diese Entscheidung wird abhängig vom Ein-/Ausgabeaktionsmuster und der Häufigkeit des Zugriffs getroffen.

Ältere oder „erkaltete“ Daten, auf die nicht mehr oft zugegriffen wird, legt der ILM im Festplattenbereich ab. Das macht Platz auf der teureren SSD- und NVMe-Ebene frei, hier können dann neuere – und „heißere“ – Daten vorgehalten werden.

Der OpLog-Bereich lässt sich aber auch umgehen. Das ergibt Sinn, wenn Arbeitslasten mit einem sequentiellen Zugriffsmuster (also keine „Random IOs“) auf den Speicher zugreifen.

Hier würde ein Zusammenfassen von mehreren Schreibaufträgen keine Verbesserung bringen – daher wird dabei direkt auf den Extent Store geschrieben.

Im Lesepfad ist vor allem der Content Cache zu nennen. Er legt die Daten dedupliziert ab – auch wenn verschiedene VMs auf dieselben Daten zugreifen, hält der Content Store folglich nur eine Instanz dieser Daten vor.

Zudem liegt der Content Store zu einem Teil im Arbeitsspeicher und zum anderen Teil im SSD- sowie NVMe-Bereich. Dadurch lassen sich in der Regel alle Lesezugriffe auf die Daten erfüllen.

Falls bei einer Leseoperation die Daten jedoch nicht im Content Cache liegen, holt sie das System aus dem Extent Store und somit unter Umständen von den Festplatten. Bei jedem darauffolgenden Zugriff auf diese Datenbereiche wird der Lesezugriff dann aber aus dem Content Cache abgedeckt.

Eine wichtige Speicherfunktion ist die Kompression der Daten. Nutanix verwendet diese Funktionalität, um die Dateneffizienz auf den Laufwerken zu erhöhen. Dabei bietet die DSF sowohl die Inline- als auch die Post-Process-Kompression an.

Das führt dazu, dass je nach Anforderung der Applikationen und der Datentypen die optimale Methode angewendet wird: Beim Inline-Ansatz werden sequentielle Datenströme oder große Ein-/Ausgabeblöcke im Arbeitsspeicher komprimiert, ehe sie auf die Festplatten geschrieben werden.

Dagegen werden bei der Post-Process-Kompression die Daten gewöhnlich zunächst unkomprimiert abgelegt. Erst danach kümmert sich das auf dem MapReduce-Algorithmus basierende Curator-Framework des Nutanix-Knotens um eine Cluster-weite Datenkompression.

Wenn die Inline-Kompression bei wahl­freien, also „Random“-I/O-Schreibzugriffen zum Einsatz kommt, schreibt das System die Daten zunächst in das OpLog. Dort werden sie zusammengefasst und dann im Arbeitsspeicher komprimiert, ehe sie in den Extent Store geschrieben werden.

Ausfallsicherheit

Zu den wichtigen Speicherfunktionen gehört zudem das redundante Ablegen von Daten: Sie müssen gegen den Ausfall eines Knotens geschützt und somit auf mehreren Knoten abgelegt werden. Dazu gibt es bei Nutanix den Replication Factor, kurz: RF, der sich auch als Resilience Factor verstehen lässt.

Zusammen mit einer Prüfsumme für die Daten wird garantiert, dass Datenredundanz und Hochverfügbarkeit selbst beim Ausfall von Knoten oder von Festplatten vorliegen.

Hier spielt das OpLog als persistenter Schreibpuffer eine wichtige Rolle: Es agiert als Sammelpunkt für alle eintreffenden Schreibzugriffe auf den SSD-Bereich, der sich durch geringe Zugriffszeiten auszeichnet.

Wenn Daten auf das lokale OpLog eines Knotens geschrieben werden, lassen sich diese Daten synchron an ein, zwei oder drei andere OpLogs auf CVMs anderer Knoten replizieren, je nachdem, wie hoch der RF eingestellt ist. CVMs sind die Controller-VMs von Nutanix, eine Steuerungszentrale der HCI-Software.

Erst wenn von diesen OpLogs eine Schreibbestätigung kommt, gilt der Schreibzugriff als erfolgreich absolviert. Auf diese Weise wird sichergestellt, dass die Daten mindestens in zwei oder mehreren unabhängigen Stellen vorliegen. Im Ergebnis wird damit das Ziel der Fehlertoleranz erreicht.

Der Replication Factor für die Daten wird mithilfe der Verwaltungskonsole Nutanix Prism konfiguriert. Alle Knoten werden bei der OpLog-Replikation mit einbezogen, sodass es keine „besonders belasteten“ Knoten gibt – sprich die zusätzliche Schreiblast aufgrund der Replikation wird bestmöglich verteilt. Damit erzielt das komplette Konstrukt auch eine entsprechende lineare Skalierung in Bezug auf die Schreibperformance.

Wenn die Daten in das OpLog geschrieben werden, berechnet das System eine Prüfsumme für diese Daten und speichert diese Prüfsumme in den Metadaten ab. Danach werden die Daten aus dem OpLog asynchron in den Extent Store gesendet und liegen anschließend dort vor – je nach gewünschtem RF auch entsprechend oft repliziert, da jedes OpLog seine Informationen in den Extent Store schreibt.

Falls nun ein Knoten oder auch nur eine Disk ausfällt, werden die Daten erneut unter den verbliebenen Knoten im Cluster repliziert, sodass der gewünschte RF wieder eingehalten wird.

Beim Lesezugriff auf diese Daten wird die Prüfsumme berechnet und mit dem Wert verglichen, der in den Metadaten gespeichert ist. Sollte die Prüfsumme nicht passen, werden die Daten von einem anderen Knoten gelesen – bei dem die Prüfsumme zu den gewünschten Daten passt. Diese Daten ersetzen dann die nicht passenden. Somit wird sichergestellt, dass es sich um valide Daten handelt.

Storage Tiering

Eine wichtige Aufgabe der DSF ist das Aggregieren der Speicherkapazität aller Knoten in einem Cluster. Dabei wird der komplette Speicherbereich für alle Knoten zur Verfügung gestellt. Ermöglicht wird dieses „Disk Tiering“ durch spezielle „Tiering“-Algorithmen.

Mit ihrer Hilfe stehen die SSDs und die Festplatten in einem Cluster für alle Knoten zur Verfügung und das Information Lifecycle Management (ILM) der DSF sorgt dafür, dass die Daten auf der SSD- oder Festplattenebene abgelegt werden – je nachdem, wie häufig auf sie zugegriffen wird. Diese speziellen Storage Events werden automatisch ausgelöst und die Daten dann entsprechend verschoben.

Um beim Storage Tiering das Prinzip der Datenlokalität einzuhalten, gilt: Auch wenn alle SSDs in einem Cluster prinzipiell für alle Knoten im Verbund zur Verfügung stehen, so bekommt dennoch für die lokalen Ein-/Ausgabeoperationen die SSD-Schicht im lokalen Knoten die höchste Priorität.

Erweitert wird dieses Vorgehen, wenn ein definierter RF vorgibt, dass Daten hochverfügbar – also auf mehreren Knoten – abzulegen sind. Da die DSF alle SSDs und Festplattenlaufwerke zu einer Cluster-weiten Speicherschicht zusammenführt, steht für jeden Knoten – egal ob lokal oder remote – prinzipiell die komplette aggregierte Speicherkapazität dieses logischen Speichers zur Verfügung. Alle Aktionen im Zuge des ILM erfolgen zudem, ohne dass der Administrator explizit Aktionen ausführen muss.

Durch diese Technik garantiert die DSF, dass es zu einem einheitlichen und effizienten Ausnutzen der Speichergeräte im Rahmen der einzelnen Schichten kommt. Läuft der SSD-Bereich eines lokalen Knotens voll, balanciert die DSF die Geräteauslastung aus: Die weniger häufig zugegriffenen Daten werden von der lokalen SSD auf andere SSDs im Cluster verschoben.

Damit wird auf dem lokalen Knoten wieder SSD-Bereich freigeschaufelt. Damit kann der lokale Knoten erneut auf die lokalen SSDs schreiben und muss nicht über das Netzwerk auf den SSD-Bereich eines anderen Knotens gehen. Alle Controller-VMs und die SSDs unterstützen remote Ein-/Ausgabeoperationen.

Damit lassen sich Flaschenhälse vermeiden und man handelt sich keine Nachteile ein, wenn die Ein-/Ausgabeoperationen über das Netzwerk laufen müssen.

Leistung

Durch die Nutanix-Architektur und -Technik lassen sich auch in einer komplett virtualisierten SAP-Landschaft höchste Leistungsdaten erreichen, und zwar in ihrer Gesamtheit. Denn es geht auch nach Ansicht von SAP nicht um einzelne Parameter, sondern um die Gesamtleistung.

Diese messen die Walldorfer in einer standardisierten Einheit, dem sogenannten SAP Application Performance Standard (SAPS). Diese Einheit ist eine hardwareunabhängige Messgröße. Sie beschreibt die Leistung einer Systemkonfiguration in einer SAP-Umgebung und ist vom Sales and Distribution Benchmark abgeleitet.

Nach diesem Benchmark sind 100 SAPS als 2000 Auftragspositionen definiert, die in einer Stunde vollständig abgearbeitet werden. Um die Leistungsfähigkeit einer komplett virtualisierten SAP-Umgebung auf Basis von Nutanix im Vergleich mit herkömmlichen Implementierungsoptionen zu veranschaulichen, bietet sich die von der SAPS-Einheit abgeleitete Performance- Dichte an:

So lassen sich mithilfe von hyperkonvergenten Nutanix-Knoten pro Höheneinheit im Rack 104.670 SAPS erzielen, während eine vergleichbar mit Rechen- und Speicherressourcen ausgestattete konvergente Lösung auf 30.058 SAPS pro Höhen­einheit kommt.

Mit anderen Worten: Um auf gleiche Leistung zu kommen, benötigt eine komplett virtualisiere SAP-Umgebung auf Basis von Nutanix nur ein Drittel des Platzes im Rechenzentrum (vgl. Abbildung 3, unten). Angesichts der bei Weitem nicht erschöpfend geschilderten Eigenschaften der Infrastruktursoftware von Nutanix erscheinen Bedenken gegenüber virtualisierten SAP-Umgebungen nicht mehr gerechtfertigt.

Dieser Befund gibt SAP-Entscheidern die Freiheit, ihre Infrastruktur strikt nach geschäftlichen Kriterien auszurichten. Niedrigere Infrastrukturkosten um bis zu 60 Prozent, reduzierter Strom- und Kühlungsbedarf um bis zu 90 Prozent, eine radikale Senkung des administrativen Aufwands mittels Automatisierung, höhere Freiheitsgrade bei der Wahl der Hardwareangebote und Kompatibilität mit den gängigen Public-Cloud- Stacks für hybride Szenarien etc. – all das sind wichtige Vorteile, die sich mit traditionellen Infrastrukturen nur sehr eingeschränkt erzielen lassen.

Virtualisierte SAP-Umgebungen auf Basis der HCI-Software von Nutanix helfen nicht nur, kurzfristig Kosten zu sparen, sondern die Gesamtbetriebskosten aktueller wie künftiger SAP-Umgebungen zu reduzieren und den Umstieg auf die neue Produktgeneration aus Walldorf zu erleichtern.