Erfolgsgeschichte eines Servervirtualisierungsprojekts

Das kürzlich abgeschlossene Virtualisierungsprojekt des Westminster College ist der zweite Teil dessen, was vor einiger Zeit als Ad-hoc-Methode zur Stilllegung einiger kritisch alternder Server begann. Die Server hosten immer noch Webanwendungen, die wir gerade auslaufen ließen. Aus diesem Grund wollten wir keine neuen Server kaufen und diese Dienste nicht vollständig neu bereitstellen. Daher haben wir einige VMware ESX (3 & 3.5) -Server eingerichtet und die Physical-to-Virtual-Software (P2V) von PlateSpin verwendet, um das Potenzial auszuschalten von Hardwarefehler aus der Gleichung.

Ich werde am Anfang beginnen

Anfang 2007, kurz nach meiner Ankunft am Westminster College, stellte sich heraus, dass mein Plan, eine bestehende Portalanwendung auslaufen zu lassen, viel länger dauern würde, als ich gehofft hatte. Die unterstützten Dienste waren in vielen verschiedenen Prozessen miteinander verflochten. Tatsächlich führen wir drei Jahre später immer noch eine der Anwendungen in der Produktion aus, aber es ist die letzte. Diese Portalanwendung wurde von einigen wirklich, wirklich alten Servern unterstützt, deren Garantieablauf weit überschritten war. Darüber hinaus war die vollständige Neubereitstellung der Portalanwendung eines der letzten Dinge, die ich tun wollte, da sie nur wenig zusammengehalten wurde und die Leute, die die Lösung implementiert hatten, längst verschwunden waren und nur grundlegende Dokumentation zurückgelassen hatten. Ich wollte auch die Anzahl der Server reduzieren, die wir in unserem kleinen Rechenzentrum betreiben. Sogar die älteren Server waren nur zu einem Bruchteil ihrer Kapazität ausgelastet, mussten jedoch in einem bestimmten Zyklus ausgetauscht und an Steckdosen angeschlossen werden, die Strom verbrauchen.

Der Wunsch, auf neuere Hardware umzusteigen, ohne die Bank zu sprengen, den Stromverbrauch zu senken und nicht alle vorhandenen Dienste neu bereitstellen zu müssen, führte zur Einführung der ersten Phase der Virtualisierung. Sobald wir diese Lösung installiert hatten, liefen wir eine Weile in dieser Konfiguration. Im Laufe der Zeit haben wir auch eine Reihe neuerer Server virtualisiert, auch mit der P2V-Methode. Da neue Dienste online gestellt wurden, haben wir sie im Allgemeinen auf einem der virtuellen Hosts bereitgestellt.

Die Hosts waren einfache Container für virtuelle Maschinen und nicht mit einem SAN verbunden. Der gesamte Speicher war lokal. Dies waren jedoch die ersten Schritte von Westminster in VMware und sie erreichten zu diesem Zeitpunkt die erforderlichen Ziele.

Weiter zu den nächsten Schritten

Im Laufe der Jahre habe ich fest an das Motto "Alles wann immer möglich virtualisieren" geglaubt. Der große Erfolg der ersten Phase veranlasste mich, die Virtualisierung so zu erweitern, dass sie alles umfasst, was wir konnten, aber ich wollte dies viel robuster tun.

Bei unserem ersten Versuch wurden keine Verfügbarkeitsmethoden implementiert, was für diesen Zweck in Ordnung war. Als wir jedoch in den Modus "Alles virtualisieren" wechselten, benötigten wir SAN-gestützte ESX-Server und etwas mehr Robustheit. Um unsere Verfügbarkeitsziele zu erreichen, wollten wir sicherstellen, dass wir keine einzelnen Fehlerquellen haben. Zu diesem Zweck ist alles redundant und wir haben mehr Server bereitgestellt, als zur Unterstützung unserer aktuellen virtuellen Workloads erforderlich sind. Wir haben Raum für Wachstum, das wir brauchen werden.

Auch hier sind wir eine kleine Umgebung, daher ist die Architektur ziemlich einfach, aber wir haben Folgendes:

  • Ein EMC AX4 SAN - iSCSI, zwei Controller, 12 x 300 GB SAS + 12 x 750 GB SATA. Vollständig und 100% redundant.
  • 3 x Dell M600 Blade-Server, 2 x 2, 66 GHz Quad Core Intel Xeon-Prozessoren, jeweils 32 GB RAM, jeweils 6 Netzwerkkarten (Gehäuse enthält 6 x Dell M6220-Switches - 1 für jede Netzwerkkarte in jedem Server)
    • 2 x Netzwerkkarten für Front-End-Konnektivität
    • 2 x NICs für die Verbindung zu AX4 (iSCSI)
      • Jedes davon ist mit einem separaten Ethernet-Switch verbunden.
      • Jede Netzwerkkarte ist mit einem anderen Speicherprozessor auf dem AX4 verbunden.
      • Jede Speicherverbindung befindet sich auf einer anderen physischen Netzwerkkarte.
    • 1 x Netzwerkkarte für vMotion
    • 1 x Netzwerkkarte für Fehlertoleranz
Wir führen 28 virtuelle Maschinen auf diesen drei Hosts aus. Von den Verarbeitungsressourcen, die wir in diesem Cluster mit drei Hosts haben, verbrauchen wir durchschnittlich etwa 10% der uns zur Verfügung stehenden Rechenleistung ( Abbildung A ), sodass genügend Raum für Wachstum vorhanden ist und wir uns keine Sorgen machen müssen Leistung, wenn einer der physischen Hosts ausfällt. Auf der RAM-Seite verwenden wir etwas mehr als 30% des gesamten im Cluster verfügbaren RAM, aber ich denke, wir können dies reduzieren, indem wir mehr darauf achten, wie einzelne virtuelle Maschinen bereitgestellt werden ( Abbildung B ). Abbildung A.

Wir verbrauchen ungefähr 10% unserer Computerressourcen. (Klicken Sie auf das Bild, um es zu vergrößern.)
Abbildung B.

Wir verwenden etwas mehr als 30% der RAM-Ressourcen des Clusters. (Klicken Sie auf das Bild, um es zu vergrößern.)

Beachten Sie in den Abbildungen A und B, dass in zwei Zeiträumen ein Problem mit vCenter aufgetreten ist, das sich auf die Erfassung von Statistiken ausgewirkt hat. Während jeder Computer über 32 GB RAM verfügt, ist auf einem unserer Hosts die RAM-RAID-Funktion von Dell aktiviert, wodurch der Host bei einem RAM-Problem geschützt wird. Infolgedessen meldet dieser Server nur 24 GB verfügbaren RAM. Aufgrund der Redundanz auf Hostebene wird diese Funktion während eines Wartungsfensters deaktiviert, um die vollen 32 GB RAM nutzen zu können.

In Abbildung C sehen Sie einen Blick auf die gesamte Infrastruktur. Die 50 und 51 sind einfach interne Bezeichner. Abbildung C.

Die gesamte ESX-Umgebung. (Klicken Sie auf das Bild, um es zu vergrößern.)

In diesem Sommer werden wir einige Änderungen an unserer Umgebung vornehmen, um die Gesamtverfügbarkeit zu erhöhen, darunter:

  • Eine Migration von unserem Exchange 2007-System mit einem Server (physisch) zu einer Exchange 2010-Umgebung mit mehreren Servern (virtuell). Der einzige Dienst, der physisch bleibt, ist Unified Messaging.
  • Wir verwenden SharePoint für viele Dinge, einschließlich unserer öffentlich zugänglichen Website. Unsere vorhandene SharePoint-Umgebung besteht aus zwei Servern: einem dedizierten Datenbankserver und dem MOSS-Server, auf dem die anderen Komponenten ausgeführt werden. Bei der Erkundung von SharePoint 2010 werden wir höchstwahrscheinlich auch von der physischen SharePoint-Infrastruktur abwandern.

Selbst wenn ich zusätzliche ESX-Hosts hinzufügen muss, um neuere Initiativen zu unterstützen (obwohl ich nicht glaube, dass ich das tun werde), sind die Verfügbarkeitsvorteile zu groß, um sie zu ignorieren.

Das Virtualisierungsprojekt in Westminster hat alle meine ursprünglichen Ziele übertroffen. Wir konnten die Lebensdauer alternder Anwendungen sehr einfach verlängern, den Stromverbrauch senken, die Verfügbarkeit erhöhen und das Budget für den Austausch von Geräten im Rechenzentrum erheblich einschränken.

Möchten Sie mit den Beiträgen von Scott Lowe auf TechRepublic auf dem Laufenden bleiben?

  • Melden Sie sich automatisch für den Server- und Speicher-Newsletter an
  • Abonnieren Sie den Server- und Speicher-RSS-Feed
  • Folgen Sie Scott Lowe auf Twitter

© Copyright 2021 | pepebotifarra.com