Markus

Manager Presales - Public Sector, EMC Deutschland

SAP HANA aus Sicht der IT-Produktion

Nachdem nun SAP mit dem Produkt HANA einen sehr innovativen Schritt in Richtung In-Memory-Datenbank gemacht hat, habe ich diese Technologie im Rahmen unserer gemeinschaftlichen (Cisco/EMC) Appliance bei einem Kunden jetzt live im Einsatz.

SAP zertifiziert das HANA-Konzept der jeweiligen Appliance (Server) Hersteller. Diese Appliances gibt es in bekannten T-Shirt-Größen. Dabei ist die XL-Scale-Out-Appliance die größte, welche bis zu einer HANA-Datenbank mit 8-Terabyte-In-Memory-Größe ausgelegt ist. Wir als EMC haben zusammen mit Cisco seit Anfang 2013 die Appliance in Version 2, welche jetzt voll auf das Fibre Channel Protokoll setzt. Welche Vorteile dies bietet, erläutere ich später noch im Detail.

SAP HANA treibt am Anfang aber dennoch manche Menschen in die Verwirrung: insbesondere wenn Fragen kommen, weshalb eine HANA-Datenbank, die In-Memory läuft, auf einem Speichersystem betrieben werden sollte. Der Grund hierfür nennt sich Disk Persistenz. Hierbei wird der Inhalt des Arbeitsspeichers eines Servers kontinuierlich auf Festplatten verschoben, denn heutige Server verfügen über einen großen Arbeitsspeicher. Mit der Disk Persistenz wird sichergestellt, dass alle fünf Minuten der Inhalt des RAMs bzw. der In-Memory-Datenbank auf die Platte festgeschrieben wird.

Seit ich an diesem Projekt und der Umsetzung dieses Konzeptes beteiligt bin, stelle ich fest, dass hierzu ein SAP-Vokabular wichtig ist, um die ganze HANA-Architektur zu verstehen. Dies sind:

HANA Aktive Worker Node:

Die Worker Nodes bilden mit ihrem Memory-Anteil den Teilbereich der In-Memory-Datenbank. Hierbei spricht man immer von aktiven Worker Nodes (Knoten), welche in der Cisco/EMC Appliance den Server Blades entsprechen und im SAP HANA HA (High Availability) Modell betrieben werden.

HANA Standby Worker Node:

Im Falle eines Defekts wird ein Standby Worker Node eingesetzt, der als Ersatz für einen Aktive Worker Node dient. Das gleicht einem Betriebsmodell wie bei einem Hotsparing in einem Speichersubsystem. Hier zeigt die Blade Technologie seine Stärken gegenüber der Standard-19-Zoll-Server -Technik, welche auch gerne IT-umgangssprachlich den Namen Pizza Box trägt.

HANA HA (High Availability):

Die SAP HANA High-Availability-Funktion sorgt dafür, dass innerhalb einer HANA Appliance die Umschaltung von einem Aktiven auf einen Standby Worker Node automatisch erfolgt. Getauschte Serverhardware wird anschließend in das Konstrukt eingefügt und zu einem aktiven Standby Worker Node umgebaut.

Die auf Cisco UCS-System-Basis zum Einsatz kommende Servertechnik ist hiermit die innovativste, die es am Markt gibt. Cisco hat verstanden, die UCS Server-Bestandteile von der Physik zu abstrahieren und das eben über mehrere UCS Blade-Gehäuse hinweg.

Dabei muss eben nicht der defekte einzelne HANA-Worker aus dem Rack extrahiert werden, was in manchen Racks sich dennoch als umständlich erweist, vor allem, wenn nicht auf die Rackverkabelung geachtet wird. Mit zwei Handgriffen kann das Serverinnenleben repariert beziehungsweise vollständig ausgetauscht werden, indem der Servereinschub nach vorne weg aus dem Chassis gezogen wird. Der physikalische Serverwechsel gleicht dem Bedienen einer kapselbasierten Espressomaschine. Wir haben das im Abnahmetest durchgeführt – dabei wurde ein Serverblade aus einem HANA-Testsystem rausgezogen und in die HANA eingesteckt, während der Standby Worker Node lief. Dafür haben wir rund 15 Minuten gebraucht. Machen Sie das mal mit einer verkabelten Pizza Box. Also los… Richtig, haben Sie sich gemerkt auf welcher Höheneinheit im Rack die Pizza Box betroffen ist? Sie müssen aber zuerst die Kabel auf der Rückseite abziehen – also zweimal ums Eck gehen und hoffentlich alle Kabel am “defekten” HANA Worker Node ziehen. Dann wieder ums Rack herum gehen, Schrauben lösen, Server herausziehen, neuen Server in den freien Slot schieben und festschrauben. Wieder ums Rack herum, verkabeln und eventuell notwendige Softwareanpassungen an der neuen Serverphysik durchführen…

HANA DT (Disaster Tolerance):

Disaster Tolerance basiert auf einem Aktiv-Passiv-Rechenzentrum-Betriebsmodell. Dies bedeutet, dass immer nur zu einem Zeitpunkt ein Rechenzentrum aktiv rechnet, die Remoteseite ist hierbei nur auf standby und empfängt alle Daten mittels Replikation. Die HANA Appliance hat den Vorteil, der Serverinfrastruktur auf der Failover-Seite eine komplett neue Identität zu geben.

Bei Disaster Tolerance ist das Ziel, SAP HANA an einem zweiten Rechenzentrum-Standort in synchroner Distanz (jedoch Stand heute nur 25km Entfernung), nach einem Katastrophenfall wieder anzufahren. Hierbei macht sich ein Speichersystem eine bewährte synchrone Replikationsmethodik zum Vorteil, welches die Datenblöcke an den Remote-Standort spiegelt.

Das SAP HANA Appliance-Modell ist ideal für die Produkte unseres Joint Venture Unternehmens VCE. In der SAP HANA Appliance von VCE werden alle Komponenten aufeinander abgestimmt und von SAP validiert. Diese Abstimmung aller Komponenten erweist sich als hilfreich, da man sich um kein unnötiges Abgleichen von Treibern auf unterschiedlichen Komponenten kümmern muss – Trial & Error gehören somit der Vergangenheit an. Zukünftige Patches im VBLOCK-Modell sind immer komplett aufeinander abgestimmt – vom Hypervisor über Server bis hin zur Festplatte im Speichersubsystem. Das ermöglicht sichere Patchdays bei Funktionserweiterungen oder Verbesserungen. Fingerpointing gehört zwischen Server, Netz und Storage der Vergangenheit an.

Bei dem heutigen Einsatz ist SAP HANA eine sehr effiziente Plattform für den SAP Business-Intelligence-Bereich. Was bisher in einigen Tagen gerechnet wurde, kann mit SAP HANA in wenigen Minuten oder Stunden gerechnet werden. Die Erkenntnis, in kürzerer Zeit zum Ergebnis zu kommen, ist wirtschaftlich hochinteressant, wenn Zahlungs- und Geldströme analysiert werden. Das Business-Intelligence-Thema wird dabei noch wichtiger. Der Appliance-Ansatz wurde von EMC mit bewährter Erfahrung aus dem Rechenzentrumsbetrieb mit eingebracht. Dabei wurde an die Erfahrung von EMC als Weltmarktführer im Enterprise-Storage mit dem ausgewogensten Produktportfolio an Big-Data-, Cloud– und Trust-Lösungen geknüpft. So ist die Umsetzung der SAP HANA Disaster-Tolerance-Lösung ein wichtiges Ziel für EMC.

Des Weiteren die Weiterentwicklung aus dem HANA Studio heraus auf hocheffiziente Backup-Appliances der Baureihe EMC DataDomain zu sichern, ist hier der richtige Schritt. Denn nur ein HANA-Backup einfach mittels Duplizierung auf ein NFS-Share ist sicherlich nicht die sinnigste Variante für ein Backup. Bei der NFS-Methode ist eben kein logisches Sichern möglich. Somit wären die etablierten Backup-Prozesse außen vor. Aus EMC Sicht wollen wir, dass Kunden hier auf konsistente Betriebsabläufe bereichsübergreifend in den Fachverfahren setzen.

Die Welt der SAP verändert sich, Business Intelligence findet den Weg in HANA.

Zusatzinformationen: Der eingangs von mir erwähnte Hinweis der FibreChannel Only Variante soll kurz erläutern, dass bei reiner Nutzung von NFS im HANA-Kontext zu High Availability sich ein potentieller Fehler im Handling von Aktiv zu Standby Worker Node und den NFS Schreibberechtigungen einschleichen könnte. Dazu hat SAP an der Entwicklung in Richtung HANA FibreChannel eines SCSI3 Commandos gearbeitet, um den “möglichen” NFS-Fehlerzustand definitiv ausschließen zu können.