Eine der Voraussetzungen für Serverkonsolidierung ist die Virtualisierung als Weiterentwicklung der Partitionierung.

´

In der Informationstechnologie ist das Thema Konsolidierung derzeit so aktuell wie facettenreich. Aktuell, weil sich nach Ansicht von Experten durch synergiesteigerndes Zusammenfassen von IT-Ressourcen erhebliche Kostensenkungspotentiale erschließen lassen. Und facettenreich, weil sich zahlreiche Arten der Konsolidierung ausgeprägt haben, die sich einerseits ergänzen und die andererseits miteinander konkurrieren. So sind Outsourcing und Out-Tasking Formen der Konsolidierung, bei denen ein Partner beauftragt wird das Rechenzentrum eines Unternehmens zu betreiben. Dieser Outsourcing-Partner ist auf Informationstechnologie spezialisiert und betreibt die IT für mehrere Kunden. Dadurch erzielt er »Economies of Scale«, also Einsparungen durch Synergien. Außerdem kann er die IT-Bedürfnisse seiner Kunden wesentlich flexibler und kostengünstiger abdecken als diese selbst, deren Kernkompetenzen normalerweise auf anderen Gebieten liegen.

Konzernrechenzentren betreiben mit oft erheblichem Verwaltungsaufwand Serverfarmen aus Tausenden von kleinen und mittleren Servern. Hier lässt sich die Administration erheblich kostengünstiger gestalten, wenn man konsolidiert, das heißt die Server in wenige virtualisierte Super-Server überführt. Preiswerte Miniserver – sogenannte Blades – relativieren jedoch den Trend zum virtualisierten Groß-Server, da damit kostengünstig und platzsparend hohe Leistung erzielt werden kann, indem man sein Rechenzentrum mit zahlreichen Blades füllt. Bei rechenintensiven Application-Workloads (Edge, Java, http, ERP) sind Blades günstiger als Highend-Server, verursachen allerdings auch einen deutlich höheren Administrationsaufwand.

Konsolidierung mit virtualisierten Super-Servern

Eine der Voraussetzungen für Serverkonsolidierung und untrennbar damit verbunden ist die Virtualisierung als Weiterentwicklung der Partitionierung. Darunter versteht man die Aufteilung eines großen Multiprozessor-Servers, eines »Super-Servers«, in viele große und kleine virtuelle Sub-Server, in denen Anwendungen unabhängig voneinander auf die Rechnerressourcen zugreifen. Die Sub-Server verhalten sich wie kleine Einzel-Server, Virtualisierung ist damit der natürliche Wettbewerber des Blade-Konzepts.

Als Super-Server kommen beispielsweise die Mainframes der IBM-«zSeries« zum Einsatz. Diese bieten ausgereifte Virtualisierungsmöglichkeiten.

• Logische Partitionierung (LPAR) beispielsweise unter zOS, Linux oder CICS: Im Gegensatz zur physikalischen Partitionierung (PPAR) auf Systemboard-Architekturen erlaubt das LPAR-Konzept auch Rechnerresourcen, die nicht zusammenhängen, also beispielsweise CPUs oder Hauptspeicher, dynamisch zu verwalten.

• »True« LPARs: Ein System mit neun Prozessoren kann beispielsweise in 15 logische Partitionen unterschiedlicher Größe mit Prozent-Granularität aufgeteilt werden. Innerhalb einer LPAR können unter VM Hunderte von weiteren Betriebssystemen wie Linux laufen.

• »Intelligent Resource Director«: Dieser verschiebt LPAR-Grenzen automatisch in Abhängigkeit von der Last, das heißt eine überlastete logische Partition bekommt automatisch CPU-Ressourcen von einer anderen LPAR zugeteilt, die momentan nicht genutzt wird.

• Virtual-I/O: Mehrere LPARs teilen sich die I/O-Ressourcen.

• Hypersockets: Dies ist eine schnelle TCP/IP-Verbindung zwischen LPARs über den gemeinsamen Hauptspeicher hinweg unter Umgehung eines externen Gigabit-Ethernet-Netzwerks.

Diese Technologien hat IBM zunächst für den Mainframe entwickelt, sie kommen jetzt aber auch verstärkt den Serverlinien der »pSeries« und »iSeries« zugute. So ist beispielsweise die dynamische logische Partitionierung derzeit schon auf der »pSeries« und der »iSeries« möglich.

Virtualisierung ist kein Selbstzweck. Sie hilft Administrationskosten zu sparen. So steigt normalerweise der Verwaltungsaufwand mit der Anzahl der zu betreuenden Server beziehungsweise bei partitionierbaren Rechnern mit der Anzahl der Partitionen oder LPARS. Bedingt durch die schiere Leistungsfähigkeit heutiger Super-Server können die LPARs entsprechend groß gewählt werden, wodurch sich die Anzahl der zu wartenden Betriebssystem-Images auf ein Minimum reduziert.

Wenn die LPARs intern per TCP/IP kommunizieren und sich die I/O-Pfade nahtlos teilen, erlaubt das einen flexibleren Betrieb, so dass ein Administrator schneller und ganz nach Bedarf auf unvorhergesehene Anforderungen reagieren kann. Durch das lastgesteuerte automatische Zuordnen von Rechnerressourcen zu den entsprechenden LPARs (»Intelligent Resource Director«) reduziert sich auch das Performance-Management auf ein Minimum.

Zudem ermöglicht das Workload-Balancing zwischen LPARs eine effektivere, das heißt höhere CPU-Auslastung – ohne Nebenwirkungen auf die Antwortzeiten. Die mittlere CPU-Auslastung von monolithischen Entry-Servern liegt typischerweise bei 15 bis 20 Prozent. Einen Super-Server mit Virtualisierungseigenschaften kann man dagegen zu nahezu 95 Prozent sättigen, ohne negative Performanceeffekte zu fürchten. Man kann ihn somit knapper dimensionieren: Wird beispielsweise ein OLTP-Anwendungsmix – beispielsweise relationale Datenbanken –, auf traditionellen Servern zu 100000 tpm geschätzt, reicht es bei einem virtualisierten Server häufig schon aus 70000 tpm zur Verfügung zu stellen. Bei einer typischen Application-Server-Workload liegt das Undersizing-Potential sogar noch deutlich höher.

Selbst wenn nur 32-Bit-Workloads konsolidiert werden sollen, ist ein 64-Bit-System als Konsolidierungs-Plattform empfehlenswert, da sich die Adressräume der zu konsolidierenden Anwendungen auf dem Host addieren und somit schnell die 4-GByte-Grenze erreicht ist. Einige 32-Bit-Architekturen unterstützen zwar mit speziellen Betriebssystemmodifikationen einen Adressraum von 4 GByte pro Prozess und insgesamt 64 GByte Hauptspeicher. Wenn jedoch viele dieser Prozesse parallel laufen, kommt es in der Regel zu einem CPU-intensiven Adressraum-Paging, das die Leistungsfähigkeit des Rechners negativ beeinflusst. 32-Bit-Anwendungen auf 64-Bit-Servern zu konsolidieren macht natürlich nur Sinn, wenn 32-Bit-Anwendungen – mit native 64-Bit-Workloads – auch unmodifiziert und performant auf der 64-Bit-Konsolidierungsplattform laufen, ein Feature, welches beispielsweise die IBM-Power4-Architektur zur Verfügung stellt.

Auf großen virtualisierten Multiprozessorsystemen läuft zwangsläufig eine größere Anzahl unterschiedlicher Betriebssysteme, die es zu verwalten gilt. Die Produktivität des Administrators kann durch den Einsatz eines Network-Install-Managers (NIM) deutlich erhöht werden, der die vielen LPAR-Konsolen zu einer virtuellen Konsole zusammenfasst. Ein solches System ist beispielsweise der AIX-Cluster-System-Manager. Dieser erlaubt es auch, Betriebssystem-Patches und Updates weitgehend automatisiert einzuspielen.

SAP-Konsolidierungsoptionen

Große virtualisierte Super-Server eignen sich insbesondere als Host für ERP-Workloads, die über eine horizontal skalierende Application-Server-Komponente und eine im allgemeinen vertikal skalierende Datenhaltungskomponente verfügen. So variiert beispielsweise

bei »mySAP.com« das Verhältnis von R/3-Applikation-Server (APS) zu R/3-Datenbank-Server (DBS) innerhalb der gleichen Instanz je nach Modul zwischen 1 zu 1 und 14 zu 1. R/3-Applikation-Server-Blades und der Datenbank-Server müssen daher auf einem vertikal skalierenden HA-Cluster erheblich überdimensioniert werden, um Lastspitzen auf beiden Seiten abzudecken. Die Implementierung einer zentralen R/3-Instanz auf einem virtualisierten Super-Server mit APS und DBS in der gleichen LPAR und Shared-Memory-Kommunikation dazwischen ermöglicht einen ultraschnellen Datenaustausch und automatischen Lastausgleich zwischen APS und DBS. Dies reduziert das Netzwerk und die Anzahl der zu wartenden Betriebssysteme erheblich.

Um die Anzahl von Betriebssystemen noch weiter zu reduzieren und die CPU-Auslastung innerhalb der Server / LPARs zu optimieren, sind viele IT-Provider dazu übergegangen, mehrere kleine R/3 in nur einer LPAR unter der Ägide eines Workload-Managers auf nur einem Betriebssystem zu fahren.

Die bisher betrachteten Konsolidierungsoptionen kommen ohne Anwendungsmodifikation aus. Die entsprechenden Workloads können eins zu eins aus der Serverfarm in die LPAR der Konsolidierungsplattform übertragen werden. Einige R/3-Betreiber sind der Frage nachgegangen, ob sich nicht die Anzahl von Betriebssystemen noch radikaler reduzieren ließe, indem man viele kleine R/3-Instanzen in wenige große überführt. Da eine Datenbank sich nur entweder in Richtung OLTP oder OLAP optimieren lässt, müssen die ERP- und BW-Komponenten getrennt konsolidiert werden. Eine R/3-Anwendungskonsolidierung führt zwangsläufig zu einem vergleichsweise aufwändigen Reengineering der Anwendung, welches in der Regel nicht innerhalb eines Wochenendes umzusetzen ist. Als Zielplattform wird ein vertikal skalierendes Cluster von Super-Servern benötigt, bei dem es naturgemäß weniger auf Virtualisierung als auf Hochverfügbarkeit ankommt. Selbst wenn die einzelnen Anwendungskomponenten an sich nicht »mission-critical« waren, in ihrer Gesamtheit sind sie es, da nun ein bedeutender Teil der Unternehmensprozesse auf einem einzigen Server-Cluster abgebildet ist. Wegen der nun viel größeren Datenbank müssen zusätzliche Redundanzen (Spiegelung), eine skalierbare Datensicherung, ein schnelleres Recovery (Flashcopy, Triple-Mirroring) und Katastrophensicherung (Schattendatenbank) implementiert werden.

»Multiple Component on one Database«, kurz MCOD, nennt die SAP einen Konsolidierungsansatz, bei dem mehrere R/3-Instanzen an eine Datenbank »berichten«, das heißt es werden nur die Datenbankanteile aber nicht die R/3-Instanzen zusammengeführt. Auch hier gilt, dass sich eine Datenbank nur entweder in Richtung OLTP oder Data-Warehousing optimieren lässt, weshalb für beide Komponenten getrennte Datenbanken zu implementieren sind. Da die R/3-Anwendung nicht angefasst wird, ist der Reengineering-Aufwand überschaubar. Für die nun entstehende große Datenbank sind aber wiederum vertikal skalierende Cluster von Super-Servern notwendig – mit allen Konsequenzen in Richtung Redundanz, Datensicherung, Recovery und Katastrophensicherung.

Dekonsolidierung mit Blades

Neben den Super-Servern spielt das neue Konzept der Blade-Server eine Rolle bei Überlegungen zur Konsolidierung. Blades sind kostengünstige Intel-IA32- oder IBM-Power-basierende Miniserver mit kompakter Verkabelung, von denen bis zu 84 Stück in einem 19-Zoll-Rack-Platz haben. Um sie workloadmäßig einordnen zu können, ist eine Unterscheidung zwischen zwei Anwendungsarten wichtig: Application-Server-Workloads generiert typischerweise die »WebSphere Application Suite«. Edge-Server (Firewalls, LDAP, Proxy, Dispatcher), http- und Java-Anwendungen beispielsweise als Teil eines Portals aber auch der R/3-Application-Server gehören in diese Kategorie.

Daten- und Transaktions-Server-Workloads sind charakteristisch für die Welt des Online-Transaction-Processing (OLTP). Reservierungs-, Logistik- und ATM-Systeme generieren ungezählte Transaktionen in Datenbanken unterschiedlichster Ausprägung. Die Anforderungen der beiden Workloads an die IT-Infrastruktur sind diametral verschieden. So können Application-Server-Workloads je nach Bedarf mit Hilfe eines Load-Levelers / Dispatchers auf viele kleine preisgünstige Server verteilt werden, sie sind somit partitionierbar und skalieren horizontal. Fällt ein Rechner aus, müssen Transaktionen nicht wiederhergestellt werden, der Load-Leveler wird die nachfolgenden Transaktionen auf den Pool der verbleibenden Rechner performanceoptimiert verteilen. Somit erübrigen sich aufwändige Hochverfügbarkeitslösungen. Blades sind damit ideal für Application-Server-Workloads geeignet. Für kleine OLTP-Instanzen werden sie bisher nur ausnahmsweise eingesetzt. Es ist allerdings nur noch eine Frage der Zeit, bis sie im Zusammenhang mit parallelen Datenbanken auch hochskalierende OLAP-Umgebungen treiben werden.

Blade-Server sind in der Anschaffung extrem günstig, aber im Betrieb vergleichsweise aufwändig, weil mehr Betriebssysteme gewartet werden müssen. Lösungen wie der bereits beschriebene NIM-Server ist deshalb absolute Voraussetzung für den effizienten Betrieb eines Bladecenters. Sobald künftig Tools zur Verfügung stehen, die on demand und automatisiert Blades in bestimmte Anwendungs-Pools allokieren und deallokieren, kann sich die Kostenstruktur zu Gunsten der Blades verbessern.

Obwohl eine horizontal skalierende Anwendungslandschaft, da partitionierbar, im Allgemeinen mit einem 32-Bit-Adressraum auskommt, geht auch bei den Blades die Tendenz deutlich in Richtung 64 Bit. Die meisten Prozessoren mit Taktfrequenzen zwischen 2 und 3 GHz sind heutzutage so stark, dass sie nur mit einer Hauptspeicherkapazität von mindestens 4 GByte, besser 6 GByte, ihre volle Leistungsfähigkeit »auf die Straße« bringen können. Blades sind so günstig, dass man sich, im Gegensatz zu virtualisierten Multiprozessorsystemen, nicht viele Gedanken um ihre Auslastung macht. Insofern ist Virtualisierung auf Blades zur Zeit noch kein Thema.

Wettkampf oder Mischform

Bei der Betrachtung der Gesamtkosten haben Blade-Server und virtualisierte Super-Server in unterschiedlichen Bereichen die Nase vorn. Während Blades mit niedrigen Anschaffungskosten für die Hardware punkten, liegen die Groß-Server mit geringen Verwaltungskosten vorn. Da beide Fragen für die Bestimmung der Gesamtkosten zentral sind, werden die beiden Design-Konzepte künftig mehr und mehr in Wettbewerb zueinander treten. Die Entscheidung für das eine oder das andere Konzept kann nur ganz individuell nach den Anforderungen des Unternehmens fallen.