Serverkonsolidierung
oder: Aus "Alt" mach "Neu"

Nahezu jedes größere IT-Projekt wird mit der folgenden Erfahrung "konfrontiert": Die Ressourcen-Grenzen sind weitestgehend ausgereizt, die CPUs zu langsam, eine Erweiterung mit zusätzlichen CPUs ist auch nicht mehr möglich; von dem stetig steigenden Speicherbedarf neuer Anwendungen ganz zu schweigen. Und zu guter Letzt kann es auch noch passieren, dass der Lieferant die Wartung und Weiterentwicklung der eingesetzten Systeme für die nahe Zukunft "ab"kündigt. Als Trost bleibt nur, dass die Systeme wahrscheinlich schon lange abgeschrieben sind.

Neben den rein technischen Aspekten gibt es noch einen weiteren Grund für den Plattformwechsel, der zur Zeit vielen IT-Abteilungen "zu schaffen" macht: Während vor ein paar Jahren Projekte noch mit einer Vielzahl von unterschiedlichen Systemen realisiert wurden, geht man heute gerne den Weg der Serverkonsolidierung.

Anstatt "eigenständige" Systeme für die einzelnen Projekte einzusetzen, liegt es im Trend, viele Projekte in einem System unterzubringen. Dies soll neben den Infrastruktur-Kosten (Stellplatz, Strom, etc.) auch die Administrationskosten senken helfen.

Vor diesem Hintergrund ist es für die IT-Abteilung selbstverständlich, sich rechtzeitig nach anderen Lösungs-Plattformen umzuschauen. Die ORDIX AG hat bereits diverse Kunden in dieser Phase der Konsolidierung unterstützt - von der Ausarbeitung eines Konzeptes bis hin zu dessen späterer Realisierung. In diesem Artikel möchten wir unsere Projekterfahrung darstellen und beispielhaft den Werdegang eines Projektes von der Konzepterstellung bis zur Realisierung/Migration aufzeigen.

Vor der Migration

Dazu ein kleines Schaubild über eine mögliche Systemarchitektur vor der Migration (siehe Abbildung 1). Die Gesamtanwendung verteilt sich über sechs Standorte hinweg auf jeweils vier Cluster. Jedes Cluster besteht aus zwei Knoten mit insgesamt zwei Systemschränken und zwei Plattenschränken.

Abb. 1: Verteilte Infrastruktur auf 6 Standorte vor der Migration.

... wurde ein Anforderungskatalog erarbeitet

Von Anfang an werden alle beteiligten Personen aus Entwicklung, Fachseite, Anwendungsbetreuung und Betrieb an der Ausarbeitung der zukünftigen Systemarchitektur beteiligt. Im ersten Schritt werden in mehreren Workshops die Anforderungen an die zukünftige Systemarchitektur erarbeitet und in einem Anforderungskonzept festgehalten. Im Vordergrund steht dabei natürlich vor allem der Kostenaspekt. Nachfolgend ein Auszug der wichtigsten Anforderungen:

Standort-Faktoren:

• Reduzierung der sechs Standorte auf zwei Standorte. Das soll die Standort-Kosten senken und den Netzverkehr innerhalb der Systeme von einem kostenintensiven WAN auf eine kostengünstige LAN-Strecke verlegen.
• Drei der bestehenden Systeme sollen zu einem neuen System zusammengeführt werden, um die Anzahl der Systeme zu minimieren. Die Reduzierung der Systeme und der damit einhergehende geringere Administrationsaufwand zielen ebenfalls darauf ab, die Kosten zu senken.
• Es ist eine räumliche Trennung innerhalb der Standorte angestrebt. Eine Feuerschutzwand soll im Katastrophenfall das Übergreifen eines Brandes von einem Raum in den anderen verhindern und so die Verfügbarkeit sicherstellen.

Hardware-Ressourcen:

• Die CPU-Leistung und der zur Verfügung stehende Speicher sollen die bisherigen Werte um 30 % übertreffen. Da der Plattform-Wechsel mit einem Release-Wechsel inklusive zusätzlicher Funktionalitäten einhergehen würde, war auch dieser erwartete Mehrbedarf mit einzukalkulieren.
• Die neuen Systeme sollen eine minimale Skalierbarkeitsreserve von 50 % beinhalten. Dies soll verhindern, dass die Systeme bereits nach kurzer Zeit wieder an ihre Ressourcen-Grenze stoßen und ein verfrühter Austausch nötig wird.
• Zur Behebung von Performance-Engpässen soll es zukünftig möglich sein, dynamische Rekonfigurationen der Hardware im laufenden Betrieb durchzuführen. Somit könnte man einen kurzfristig auftretenden CPU-Engpass durch das kurzfristige Erweitern mit zusätzlichen CPUs auffangen. Dies erlaubt also den individuellen, effizienteren und kostensparenderen Einsatz der zur Verfügung stehenden Ressourcen.

Software-Faktoren:

• Die bisher benutzten Software-Komponenten wie z. B. Datenbank System, Middleware (Applikationsserver, Kommunikationssysteme, Transaktionsmonitore) und System Management (Überwachung) sollen auf der neuen Plattform ebenfalls zur Verfügung stehen. Eine kostenintensive Migration auf ein anderes Produkt ist nicht vorgesehen.

Verfügbarkeits-Faktoren:

• Neben der Hochverfügbarkeit der Anwendung ist das oberste Ziel die Datenkonsistenz. Undefinierte Zustände, bei denen mehrere Knoten eines Clusters die gleiche Datenbasis verändern und somit zerstören, sind unbedingt zu vermeiden.
• Wie bei der bisher eingesetzten HV-Lösung ist die Verteilung der einzelnen Anwendungen und Ressourcen über eine Parametrisierungsdatei zu steuern. Voraussetzung dafür ist eine Trennung von Parametern und Skripten.
• Im Gegensatz zur bestehenden Lösung ist eine weitere Anforderung, auch einzelne Anwendungskomponenten zu überwachen und bei Ausfall zu reaktivieren.
• Das Erkennen und die Übernahme eines ausgefallenen Systems soll in möglichst kurzer Zeit durchführbar sein. Die Umschaltzeit der bisher eingesetzten Lösung von ca. 15 Minuten darf dabei nicht überschritten werden.
• Die Anforderung, dass der Cluster aus mehr als zwei Knoten bestehen soll, erlaubt eine kurzfristige und flexible Reaktion z. B. auf Last-Probleme. Je nach Last kann der Administrator eine Anwendung auf ein weniger beanspruchtes System umschalten.
• Das System sollte den Ausfall einzelner Hardware-Komponenten erkennen und auffangen, ohne den Betrieb zu unterbrechen. Zudem soll der Ausfall der Komponente zeitnah gemeldet werden, um entsprechende Maßnahmen einzuleiten.
• Die Komponenten sollen sich im Betrieb austauschen bzw. erweitern lassen können (Stichwort: Hot-Swap).
• Alle Datenpfade bzw. Daten-Controller wie auch alle Netzanbindungen werden redundant vorgehalten.

... und nach entsprechenden Lösungen gesucht

Auf Basis dieser Anforderungen holte man zunächst von unterschiedlichen Herstellern (HP, IBM, SUN, Fujisu Siemens) sowohl konzeptionelle als auch preisliche Angebote ein. Mehrere Arbeitsgruppen analysierten und bewerteten die verschiedenen Angebote in Bezug auf die Erfüllung der Anforderungen.

Abb. 2: Infrastruktur nach der Migration.

Nach Berücksichtigung der Kosten und der Anforderungskriterien erwählte man die in Abbildung 2 dargestellte Lösung als Plattform. Die Lösung basiert auf einer hochverfügbaren Systemarchitektur, bei der unter anderem auf die Redundanz sämtlicher Komponenten Wert gelegt wurde. Das Gesamtsystem wird über zwei Standorte verteilt. An jedem Standort sind zwei Brandschutzabschnitte berücksichtigt.

Diese Architektur beinhaltet pro Standort jeweils zwei Serversysteme und zwei Plattensubsysteme. Jedes Serversystem ist mit bis zu sechs Partitionen konfiguriert. Innerhalb des Standortes sorgt ein hochverfügbares SAN mit einer "dual fabric"-Struktur für die Anbindung der Plattensubsysteme an die Server.

Das Zusammenführen von mehreren Datenbanken zu einer erzielte eine Anwendungskonsolidierung von produktiven Datenbank-Anwendungen auf ein Drittel.

Jede der Anwendungen läuft nun auf einer Partition des Serversystems. Die einzelnen Partitionen erbringen die Performance von drei bisher eingesetzten Altsystemen "plus 30 %". Zum Sizing des CPU-Bedarfs wurden die SPEC-Werte der jeweiligen Systeme herangezogen. Dadurch ergab sich für die neuen Partitionen ein Bedarf von zwölf CPUs (im Vergleich zu den bisher benötigten 3x12 CPUs).

Bezüglich der Plattenanbindung hatte man darauf geachtet, die Controller über mehrere Systemboards einer Partition redundant zu verteilen. Dies erzielt eine bessere Lastverteilung und eine höhere Verfügbarkeit der Datenpfade. Ein Ausfall eines Systemboards führt somit nicht zu einem Ausfall der Plattenanbindung.

Für die dynamische Lastverteilung ist der Einsatz zusätzlicher Systemboards denkbar. Mit der "Enhanced Server Capacity on Demand" bietet sich die Möglichkeit, die Systeme mit zusätzlichen Komponenten auszurüsten, die später im laufenden Betrieb aktivierbar sind.

Als "Nachfolge-Produkt" für die bisherige 2-Knoten-HV-Software kommt nun ein acht bzw. sechs Knoten-Cluster zum Einsatz. So lassen sich bei Ausfall einer Partition die dort laufenden Anwendungen auf die restlichen, laufenden Partitionen verteilen.

... und realisiert.

Für die Umstellung auf eine neue Plattform genügt es nicht, nur die eigentliche Anwendung zu portieren. Auch die bisher eingesetzten Tools (Backup, Cronjobs, Überwachungs-Skripte, etc.) müssen an die neue System-Architektur angepasst werden. Allein der Einsatz einer neuen HV-Software führt dazu, dass ein Großteil der Skripte neu entwickelt wurde.

Im ersten Schritt erfolgte der Test der "Gesamt-Lösung" (inklusive Datenbank, Anwendung und HV-Software) auf einem gesonderten Abnahme-System "auf Herz und Nieren". Dann ging mit der Umstellung des Piloten das erste System der neuen "Lösung" in den Wirkbetrieb.

Nach dem erfolgreichen Pilot-Betrieb, konnten nun auch alle anderen Systeme umgestellt werden. Sowohl für den Roll Out (Anwendungs-Installation/Konfiguration) als auch für die Migration der Daten entwickelte das beteiligte Projektteam entsprechende Tools, damit die Daten und die Anwendungen innerhalb von drei Wochenenden quasi per Knopfdruck auf die neuen Systeme portiert werden konnten.

Nach jahrelanger Mitwirkung hatte das ORDIX-Team das Projekt auch in dieser Phase intensiv begleitet. Von der Konzeption, über die Auswahl und Einrichtung der neuen Lösung bis hin zur Migration der Anwendung unterstützen ORDIX Mitarbeiter den Kunden so, dass für ihn eine möglichst kostengünstige, hochverfügbare und effiziente Plattform realisiert werden konnte.

Seitenanfang

Seite drucken

Seite weiterempfehlen