Serverkonsolidierung der etwas anderen Art

Wenn der Begriff Serverkonsolidierung fällt, denkt man in der Regel an große Systemkonfigurationen, bei denen eine Menge von Anwendungen auf einem partitionierbaren System zusammengefasst werden. Nicht selten findet man dann Systeme wie PRIMEPOWER 2500, Sun Fire E25K oder IBM pseries 690. Serverkonsolidierung kann aber schon in viel kleinerem Rahmen stattfinden. Der Artikel beschreibt die Konsolidierung einer Kunden-DMZ (DMZ = demilitarisierte Zone), bei der die ORDIX AG mitwirkte.

Die Ausgangssituation: Eine schnell gewachsene Webserver-Farm

Abb. 1: Die Systemarchitektur beim Kunden nach der Konsolidierung.

Zur Realisierung der Internetpräsenz (bestehend aus ca. 50 Internetangeboten) wurde eine Vielzahl von unterschiedlichen Systemen mit jeweiligen Datenbank- und http-Prozessen eingesetzt. Als Plattform diente eine heterogene Rechnerlandschaft, bestehend aus ca. 25 Systemen auf Basis von Linux und Solaris.

Die Datenhaltung erfolgte ebenfalls mit unterschiedlichen Datenbank Systemen (Oracle, MySql, PostgreSql). Eine Hochverfügbarkeit der einzelnen Dienste war nicht gewährleistet.

Der Ausfall eines Internetangebots hätte nicht ohne größere Ausfallzeiten abgefangen werden können, was zu einem entsprechenden Image-Verlust geführt hätte. Wie viele Webserver-Farmen, ist auch diese im Laufe der Jahre "unkontrolliert" und mit vielen "Insel-Lösungen" gewachsen.

Primäres Ziel war bisher die möglichst schnelle Bereitstellung eines Webdienstes. Administrationskosten, leichte Pflegbarkeit, Backup- und Verfügbarkeit spielten bis dato eher eine untergeordnete Rolle.

Die Ziele

Aus dieser etwas unbefriedigenden Situation haben die Mitarbeiter der ORDIX AG in Zusammenarbeit mit dem Kunden folgende Ziele festgelegt:

• Hochverfügbarkeit
  Der Ausfall einer Hardware-Komponente darf nicht zum Ausfall einer Internetpräsenz führen.
  
  
• Lastverteilung
  Bei Bedarf und erhöhter Nachfrage müssen entsprechende Kapazitäten zur Verfügung stehen, die vom Internet-Anwender transparent genutzt werden können. Es soll verhindert werden, dass einige Systeme unter Volllast laufen, während andere "unterbeschäftigt" sind.
  
  
• Verringerung der Serveranzahl
  Weniger Systeme, die – wenn möglich – identisch aufgebaut sind, sollen zu einer Minimierung der administrativen Aufgaben führen.
  
  
• Zentraler Storage
  Durch einen zentralen, externen Storage sollen Speicherplatz-Engpässe flexibler behoben werden können. Eine jeweils lokale Plattennachrüstung entfällt. Die zentrale Datenhaltung ist weiterhin für die Hochverfügbarkeit der Anwendung von großer Bedeutung.
  
  
• Skalierbarkeit
  Steigende Anforderungen sollen durch Auf- oder Nachrüstung möglich sein, ohne dass die anderen Ziele davon betroffen sind.
  
  
• Stabilität
  Die Lösung sollte insbesondere für die wichtigen, zentralen Komponenten Stabilität garantieren.
  
  
• Kosten
  Die bisher genannten Ziele müssen so weit wie möglich mit geringen Kosten realisiert werden. Daher ist der Einsatz von Open Source Lösungen wie auch von preisgünstiger Hardware zu prüfen.

Die Analyse erbrachte eine logische Aufteilung

Im ersten Schritt haben die ORDIX Mitarbeiter die Struktur der einzelnen Anwendungen analysiert, woraufhin sie dann die Internet-Angebote in zwei Basisdienste aufteilten:

• http-server
  Die meisten Webdienste wurden auf Basis des Apache-Servers betrieben. Die Datenhaltung erfolgt nicht auf lokalen Filesystemen, sondern auf einer Datenbank. Dadurch ist es möglich, die Webserver parallel zu betreiben, was das Erreichen des Ziels "Loadbalancing" vereinfacht.
  
  
• Datenbank
  Alle veränderbaren Daten der Webdienste werden auf jeweils eigenen Datenbanken gehalten.

... in Webserver

Durch den Einsatz von "gleich aussehenden" Linux-Blades (mit SLES 8) wird eine vereinfachte Administration der Systeme erreicht. Auf den Blades befinden sich nur "Betriebssystem-Komponenten", die für den Einsatz der Webanwendungen notwendig sind. Die Blades können jederzeit durch einen zentralen "Installations-Blade" automatisch und identisch eingerichtet bzw. vervielfältigt werden.

Die Webanwendungen selbst befinden sich auf einem zentralen Storage (NAS) und werden von den einzelnen Linux-Blades eingebunden. Durch entsprechende Start-/Stopp-Skripte ist es möglich, jede Anwendung auf jedem Blade laufen zu lassen.

Durch einen vorgeschalteten Loadbalancer (BigIP) wird die geforderte Skalierbarkeit erreicht. Engpässe können durch das einfache Hinzufügen eines weiteren Blades überbrückt werden.

Durch den Loadbalancer wird ebenfalls eine gewisse Hochverfügbarkeit garantiert, da dieser bei Ausfall eines Blades die Anforderungen an einen anderen, laufenden Blade mit gleicher Anwendung weiterreicht. Um trotz eines Ausfalls eines gesamten Rechenzentrums die Verfügbarkeit zu garantieren, sind die beiden Enclosures (die die Blades enthalten) in unterschiedlichen Gebäuden aufgestellt worden.

... und Datenbankserver.

Zur einfacheren Administration werden ebenfalls alle Datenbanken zentral unter Oracle auf einem System zusammengeführt. Eine Parallelisierung wie bei den Linux-Blades ist an dieser Stelle nicht möglich.

Auf Grund der zentralen Funktion (und somit der Möglichkeit des Single Point of Failure) erhöht sich die Anforderung an die Verfügbarkeit. Der Einsatz eines Clusters mit stabilen und redundanten Komponenten ist hier unbedingt notwendig:

• Zwei Sun Fire Server bilden jetzt die beiden Zwei-Knoten-Cluster. Betriebssystemmäßig ist die Entscheidung für Solaris 8 gefallen.
  
  
• Die Datenbanken selbst werden in einem externen SAN-Storage abgelegt. Die eingesetzte EMC-Box ist über Fibre Optik redundant angeschlossen.
  
  
• OSL Storage Cluster: Auch bei der Auswahl des Clusters ist von den großen und bekannten HV-Lösungen (wie z. B. Veritas-Cluster, Sun-Cluster, PrimeCluster, ...) Abstand gehalten worden.
  Ziel war es, eine Lösung zu finden, die einerseits kostengünstig ist (Lizenz und Wartung), anderseits aber auch die geforderte Stabilität und Robustheit liefert. Um den Administrationsaufwand gering zu halten, sollte sich die Lösung auf die reine Systemverfügbarkeit konzentrieren. Die Entscheidung fiel auf den OSL Storage Cluster, der auch gleich einen Volume Manager beinhaltet.

Fazit

Die ORDIX AG hat in diesem Projekt maßgeblich sowohl in beratender als auch in ausführender Funktion mitgewirkt. Von der Konzepterstellung, über die Auswahl der einzelnen Komponenten bis hin zur Durchführung der Konsolidierung haben die ORDIX Mitarbeiter ihren Kunden begleitet.

Bei der Realisierung der Systemarchitektur wurde eine Referenzanwendung ausgewählt, die von ORDIX komplett auf die neuen Systeme installiert und migriert wurde. Die restlichen Anwendungen werden nun schrittweise vom Kunden selbst in die neue, konsolidierte Welt umgestellt.

Antonio Salguero (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen