Bestimmung der Hardware-Anforderungen für SAP HANARichtiges Sizing spart Kosten

Wie soll eine Migration auf SAP HANA abgewickelt werden? Will man zuerst die bestehende Umgebung konsolidieren, dann die „Simplifizierung“ ausführen und dann ein passendes Gesamtsystem definieren – dann sind einige Aspekte für das Sizing der Hardware zu beachten. Wichtig ist dabei vor allem die Skalierbarkeit der Hardware – hier kann IBMs Power-Architektur punkten.

Zu lange Antwortzeiten der Applikationen, die Komplexität der IT-Landschaft sowie Performance-Engpässe gehören in vielen Kernanwendungen zum Alltag der Unternehmen. Hier hat SAP mit der Architektur seiner HANA-Technologie und den darauf basierenden Anwendungssuiten das Tor aufgestoßen zu den enormen Möglichkeiten im Bereich er Business Analytics sowie den Innovationen bei den Anwendungen.

Der Einsatz von HANA als Datenmanagementebene bildet die Grundlage für die Anwendungsentwicklung. Entscheidungen über das Sizing für HANA haben Auswirkungen auf die gesamte Anwendung — bis hin zu der Performance, die der Endbenutzer „sieht“. Daher kann sich dieses Sizing auf die IT-Servicelevels auswirken und sogar zu einem Gradmesser für die Reputation des gesamten Unternehmens werden.

Um den Umfang der benötigten Ressourcen an unterschiedliche Rechenanforderungen anzupassen, müssen die Systemverantwortlichen ein klares Verständnis der Arbeitslasten, ihre zeitliche Verteilung und der erwarteten Reaktionszeiten besitzen. Um hier eine passende Lösung präsentieren zu können, gilt es die beiden typischen In-Memory-Arbeitslasten zu berücksichtigen.

• Transaktionale Workloads: Bei dieser Arbeitslast kann es sich um ein einfaches Abrufen eines kleinen Transaktionsdatensatzes aus einem größeren Datensatz handeln. Ein einfaches und gängiges Beispiel, das eine nahezu sofortige Reaktionszeit erfordert, wäre das Abrufen von Details zu einem Auftrag, einem Kunden oder einem Datensatz basierend auf einem Kriterienkatalog.
• Analytische Workloads: Dazu gehört das Durchsuchen großer Informationsmengen zur Erzeugung von Informationsverbünden, das Vergleichen anderer vordefinierter Kombinationen oder das Ausführen bestimmter logischer oder wissenschaftlicher Funktionen. Zu den einfachen Beispielen gehören das Aggregieren und der Vergleich der Umsätze pro Monat oder Region für ein bestimmtes Jahr oder die Identifizierung von Produkten, die eine „zeitnahe“ Ausführung erfordern. Beide Aufgabenstellungen erfordern eine nahezu sofortige Reaktionszeit, abhängig vom Ausmaß der Benutzerinteraktion in den Prozessen.

Bei der Beschaffung von Hardware-Ressourcen gilt für alle IT-Verantwortlichen, dass sie die TCO der Hardware berücksichtigen. Doch zudem sollten sie zwei wesentliche Aspekte beachten:

• Eine unterdurchschnittliche Performance der IT kann die Kosten in letzter Konsequenz sogar erhöhen. Denn die Gesamtkostengleichung, die der letzte Maßstab für den Erfolg ist, umfasst mehr als nur die Kosten für die reine Hardware. Es treten oft versteckte Kosten im Zusammenhang mit leistungsschwachen Systemen auf, die schnell die Anschaffungskosten der ursprünglichen Hardware übersteigen.
• Überkapazitäten der Hardware können die Kosten hochtreiben: Eine höhere Rechenleistung als die Arbeitslasten benötigen, führt zu Unterauslastung der Systeme und somit zu überhöhten Kosten. Allerdings darf man eines nicht vergessen: Es kann im Betrieb zu unerwarteten Spitzenbelastungen kommen.

Im Hinblick auf die Gesamtbetriebskosten sollten IT-Manager bedenken, dass SAP HANA gleichzeitig Transaktionen und Analysen auf einer einzigen Datenkopie ermöglicht und über erweiterte Analysefunktionen verfügt. Durch die Bereitstellung einer „In-Memory“ Business-Data-Plattform trägt SAP HANA dazu bei, die TCO auf breiter Front zu senken. Denn es sind in vielen Fällen keine eigenständigen Data Warehouses mehr nötig. Im Kontext der Kosten ist aber auch zu berücksichtigen, dass das Sizing und die Kosten stark von der Systemlandschaft jedes Kunden abhängen.

Generell gibt es vom Prinzip her zwei Möglichkeiten, auf SAP HANA zu wechseln:

• Man kann jedes bestehende SAP-System einzeln migrieren, oder
• führt zuerst eine Konsolidierung der Systeme durch und erst danach die Transformation auf die neue Technologie.

Der zweite Ansatz in Richtung SAP HANA kann im Vergleich zur „einzelnen Migration individueller Systeme“ bietet Möglichkeiten für eine stärkere Optimierung zwischen den Systemen. Anwender sollten daher den gesamten Umfang ihrer gewünschten zukünftigen Landschaft sorgfältig abwägen, bevor sie sich an das Sizing wagen. Zudem wird ein mehrfaches Sizing (auf der Ebene der einzelnen Systeme) kaum so genau sein wie eine optimierte, richtig dimensionierte und konsolidierte Landschaft mehrerer SAP-Systeme. Die In-Memory-Funktionen, die Column-orientierte Tabellenstruktur der HANA-Datenbank, die Datenkompression, die Datenvirtualisierung, das mehrstufige Datenmanagement und viele andere innovative Funktionen von SAP HANA bieten viele Möglichkeiten, bestehende Landschaften in eine kleinere Anzahl konsolidierter Systeme zusammenzufassen. Damit werden viele Aktionen, wie etwa Daten- und Systemkopien, überflüssig.

Bei richtigen Sizing profitieren die Anwenderunternehmen stark von der Vereinfachung durch SAP HANA. Für komplexere Szenarien ist eine kompetente Sizing-Beratung durch SAP oder deren Partner sinnvoll. Generell sind Unternehmen damit in der Lage, redundante Daten zu eliminieren, schnellere Berichte zu ermöglichen und die Produktivität zu steigern – das alles mit einfacher Datenmodellierung und einer vereinfachten IT-Landschaft.

Skalierbarkeit als Trumpfkarte für die Power-Familie

Mit den Power Enterprise Pools der Enterprise-Servern von IBM (der Baureihe E870/ E880 respektive E980), kommen mehr Flexibilität und gleichzeitig kostengünstige Effizienz ins Spiel. Ein derartiger Pool besteht aus einer Gruppe von Power-Systemen, die mobile Kapazität (Mobile Capacity on Demand – CoD) in Bezug auf Prozessor- und Memory-Ressourcen teilen kann. Innerhalb des Pools können die Ressourcen mithilfe von HMC-Befehlen (Hardware Management Console) verschoben werden.

Bei Wartungsarbeiten oder Nichtverfügbarkeit von Systemen können deren Ressourcen auf anderen verfügbaren Servern im Pool aktiviert werden, sofern diese ausreichend nicht aktivierte Ressourcen installiert haben. Dies ermöglicht ein Re-Balancing von Ressourcen, die Verschiebung von Workloads und erleichtert die HA/DR-Planung und Umsetzung im Betrieb.

Alle produktiven HANA-Datenbanken sollten, Stand heute, auf Basis der Richtlinie der SAP „dedicated donating“ (Cores) betrieben werden. Die nicht genutzte Prozessorkapazität wird mithilfe des „Donating“- Mechanismus an den Shared Pool abgegeben. Diese Shared-Pool-Kapazität kann von zugehörigen SAP-Applikationsservern genauso wie von den nicht produktiven HANA-Instanzen sowie jeder anderen Art von Workload, die dem Shared Pool zugeordnet ist, genutzt werden.

SAP Hana unterstützt mehrere isolierte Datenbank-Instanzen in einem (physischen) SAP-Hana-System. Sie werden als sogenannte Tenant-Datenbanken bezeichnet. Das Prinzip selbst wird als MDC (Multi-Tenant Database Containers) bezeichnet. Ab Hana 2.0 SPS01+ werden HANA-Systeme standardmäßig als MDC-Systeme installiert. (rhh)

Hier geht es zu IBMs HANA-Site