On-premise-Infrastrukturen für Hana

Hana ist die meistdiskutierte SAP-Innovation der letzten Jahre – mit mehr als 3.200 Kunden und mehr als 1.200 am Aufbau von Anwendungen beteiligten Start-ups aus 57 Ländern.

Hana ist ein in-memory-relationales Datenbank-Management-System und eine Anwendungsplattform, welche Transaktionen und Analysen auf einer einzigen Datenkopie durchführen kann und Echtzeit-Erkenntnisse in einer vereinfachten IT-Landschaft gewährt.

Sie kann sowohl strukturierte und unstrukturierte Daten als auch Datenströme verarbeiten. Zusätzlich umfasst sie fortschrittliche Datenverarbeitungsfunktionen wie die Suche und Analyse von räumlichen, prädiktiven, grafischen und textuellen Daten.

Darüber hinaus bietet Hana auch ELT-Funktionen, Datenreplikationen und die Integration von Hadoop. Hana ist weder eine reine Datenbank noch eine reine SAP-Anwendung. Sie ist eine vollständige Plattform, deren zugrunde liegende In­frastruktur ein komplexes Themengebiet darstellt.

Wie bei jeder wohldefinierten Roadmap müssen bei der Einführung neuer Technologien mehrere Faktoren wie Architektur-, Infrastruktur- und betrieblich verbundene Fragen berücksichtigt werden – Hana bildet hierbei keine Ausnahme.

Damit unsere Kunden die richtigen Entscheidungen über die Architektur, Technologie und betrieblichen Sachverhalte treffen können, entwickelte Infosys Consulting die Anbieter-Bewertung von On-premise-Infrastrukturen für Hana.

Derzeit gibt es für die Hana-Infrastruktur 13 Anbieter mit verschiedenen Konzepten rund um die CPU-Architektur, die Speicherung, konvergierende Infrastrukturen, und Scale-out- oder Scale-up-Varianten.

Die Bereitstellungsoptionen decken jetzt sowohl Appliance-ähnliche Modelle, welche vom Hardware-Partner vollständig konfiguriert, geliefert und betreut werden, als auch maßgeschneiderte Rechenzen­trums-Integrationen (TDI) ab, welche eine flexible Möglichkeit bereitstellen, zertifizierte Hana-Hardware an eigene Rechenzentren und Speicherkonzepte anzuhängen.

TDI Mix and Match

Anstelle eines Black-Box-Modells, welches getrennt und isoliert vom Rest des Rechenzentrums besteht, tendieren Kunden vermehrt zur TDI-Option, da sie in ihr eine natürliche Integration von Hana in bestehende Rechenzentren und Betriebsmodelle sehen.

TDI-Implementierungen stellen aber auch in der Regel zertifizierte Hardware bereit, jedoch in einem Mix-and-Match-Ansatz: Der Kunde ist nicht weiter an das volle Stack eines Anbieters gebunden, aber kann ganz gezielt zertifizierte Blades oder Racks mit zertifiziertem Speicher wählen.

Da die Bereitstellung von Hana sehr arbeitsintensiv ist, ist es sehr empfehlenswert, professionelle Dienstleistungen in Anspruch zu nehmen. Eine Hardware-Überprüfung und das Mitteilen der Ergebnisse an SAP werden für die Validierung nicht mehr benötigt, jedoch aber empfohlen, damit der Kunde die technischen Grenzen der Bereitstellung besser nachvollziehen kann.

Der Appliance-Ansatz bringt eine vollständig konfigurierte Hana-In­stallation mit dem notwendigen Support durch den Hardware-Anbieter mit sich. Abhängig vom Dienstleistungsvertrag kann aber der Kunde, standardgemäß, immer noch für das Patchen und Aktualisieren der Appliance auf Grundlage von Empfehlungen des Herstellers verantwortlich sein.

Wir haben eine Vielzahl wichtiger Aspekte, welche für moderne Rechenzentren von Relevanz sind, analysiert: Management, Implementierung und Integration in bestehende Rechenzentren, Support, Systemflexibilität und Skalierbarkeit, hohe Verfügbarkeit und Ausfalltoleranz (Disaster Tolerance) in unternehmenskritischen Umgebungen.

Die meisten Kunden interessieren sich für Hardware-Optionen basierend auf unterstütztem Arbeitsspeicher, die Skalierbarkeit von Funktionen oder die Integration in ein Rechenzentrum.

Da Hana vermehrt an Präsenz gewinnt, sind einige Funktionen auch zum Standard in allen Lösungen geworden, wie zum Beispiel High Availability (integriert in Hana) oder Virtualisierung (von SAP auch für Multi-VM-Architekturen unterstützt).

Allerdings sind nicht alle Standardfunktionen in Hana auch nahtlos integriert, weder im Speicher (für Back­upAPI zum Beispiel wird ein getrenntes Zertifizierungsverfahren benötigt, siehe http://scn.sap.com/docs/DOC-62799)noch in der Lösung (Virtualisierung mit VMWare – nicht alle Anbieter bieten integrierte Werkzeuge, um es zu verwalten).

Disaster-Toleranz, ein Muss für eine Enterprise-Level-Lösung, wird über Speicherunterstützung oder Hana-Replikation zur Verfügung gestellt. Speicheranbieter bieten eine synchrone oder asynchrone Replikation mit eigenen Technologien, und manche Anbieter bieten Whitepapers, um Kunden bei der Implementierung ihrer Lösung zu helfen (z. B. HP, Cisco/VCE, Fujitsu, Hitachi, SGI).

Es wird dringend empfohlen, mit Infosys Consulting oder dem Speicheranbieter einem geeigneten Hana-Setup nachzugehen. Wir haben die maximal zugelassenen Knoten (Servers) jedes Hardwareanbieters aufgelistet.

Die Zahlen waren stark von der verwendeten Speichertechnik abhängig. Der Mangel an internem Speicher bedeutet in der Regel, dass es nur Blade Support gibt. Wir merken auch die Tendenz, dass Hardware Hersteller, die eigene Speicher Lösungen anbieten, diese auch bevorzugen und ungenügend Unterstützung für andere Systeme anbieten.

IBM-Lösungen – ein Fall für sich

Die IBM-Lösungen fallen unter ein besonderes Kapitel, da sie nicht dem Mainstream mit x86-Angeboten folgen. Stattdessen entschied IBM, sich auf seine PowerPC-Linie zu konzentrieren, mit produktivem Support für Power8 und Nicht-Produktions-Systeme, die auch auf Power7 erlaubt sind.

Hana auf PowerPC ist nicht eine native Installation, aber funktioniert auf SLES oder RHEL in VM- Containern (Power oder KVM). Die CPUs müssen vollständig an die Hana-Partitionen (ähnlich wie x86 VMWare) zugewiesen werden.

Während x86- und Linux-Anbieter in der Regel xfs oder nfs für ihre Dateisysteme wählen, konzentrierte sich IBM darauf, das eigene GPFS (General Parallel File System) zu verwenden.

GPFS ermöglicht ein einfaches Scale-out von einem Node mit internem Speicher, sodass der Kunde nicht externe Speicher auf die Hana-Landschaft zuweisen muss. Einzelne Node-Installationen können xfs verwenden.

Das richtige Werkzeug?

Verglichen mit der Frage „was ist das richtige Werkzeug für welchen Job“ gibt es keine pauschale Antwort auf die Frage „wer ist schneller“. Alles hängt vom Business Case, den Prozessen und den SAP-Anwendungen ab.

Als Konstrukt parallelisiert BWoH besser (also Scale-out) als eine einzige Full-Memory Machine, wohingegen SoH eindeutig eine Scale-up-Lösung ist. Basierend auf geografischen Regionen und Stärken ist es verständlich, dass einige der Anbieter globale Lösungen anbieten, während andere (vor allem APAC-Region-Anbieter) sich meist vor allem wegen des Supports auf ihre lokalen Länder oder Regionen fokussieren (NEC, Huawei, SGI). IBM bleibt seiner Power-Architektur treu.

Basierend auf den Informationen über die Verfügbarkeit von spezifischen Hana- oder Rechenzentrums-Funktionen haben wir den Reifegrad und die Bereitschaft der verschiedenen Lösungen analysiert.

Innovation führt nicht automatisch zu Marktakzeptanz oder Support für die Durchführung oder Integration. Marktreife wiederum könnte zu einer langsamen Entwicklung von Innovationen führen.

Der Schlüssel zu einer erfolgreichen Rechenzentrums-Implementierung von Hana ist das Finden der richtigen Balance zwischen Innovation, Support, Dokumentation verschiedener Lösungen, Marktreife und auch der Integration mit SAP-Landschaften, die bereits im Einsatz sind.