Das Rechenzentrum im Auge des Sturms

Nachdem nun die meisten Großunternehmen ihre Rechenzentren konsolidiert haben, richtet sich der Fokus der IT darauf, aus der großen Zahl von Servern und Speicher-Arrays die bestmögliche Leistung herauszukitzeln. Da sich der Betrieb von Servern und Speichersystemen verändert hat, müssen sich auch die zugehörigen Netzwerke der Rechenzentren ändern. Bestehende Best Practices, die vor ein paar Jahren noch gültig waren, sind teilweise nicht mehr angemessen – sei es in Punkto L2- oder L3-Switching, der Zahl der Switching-Layer , in Fragen der Sicherheit oder Zoning, empfohlenen Topologien, Bandbreitenanforderungen oder dem Netzwerkmanagement.

Einer der wichtigsten Einflussfaktoren für die Veränderung in Rechenzentrumsnetzwerken hängt mit der Server-Konnektivität zusammen. In den meisten konsolidierten Rechenzentren von Großunternehmen erleben Server eine Zweiphasen-Entwicklung:

Server-Phase 1: Die Virtual Machine

Nachdem die Unternehmen eine große Anzahl von Servern in konsolidierte Rechenzentren verlagert hatten, wurde bald offensichtlich, dass die durchschnittliche Auslastung der Rechner lediglich 10 Prozent oder noch weniger betrug. Auch wenn die meisten Server in den Rechenzentren heute auf gängigen Intel-PCs beruhen und nicht mehr auf traditionellen Mainframes oder Minicomputern, so summieren sich Kauf und Unterhalt von Tausenden von Servern doch zu stattlichen Beträgen. Man erkannte daher, dass sich erhebliche Einsparungen erzielen lassen, wenn man das Applikationsportfolio eines Unternehmens auf einer geringeren Zahl von Servern laufen lässt und damit die durchschnittliche Server-Auslastung erhöht.

Die Technologie für dieses Unterfangen – die Hypervisor-Software Virtual Machine (VM) – gab es bereits seit den 70er Jahren mit VM/370 auf IBM Mainframes. Ein VM Hypervisor macht es bekanntermaßen möglich, dass auf einem einzelnen physischen Server eine Vielzahl von “Gast”-Kopien eines Betriebssystems laufen – oder eine Kombination verschiedener Betriebssysteme. Ein Hypervisor verschafft jedem der Gast-Betriebssysteme (und den damit verbundenen Applikationen und Daten) Zugang zu einer anderen Virtual Machine, statt zum darunter liegenden “echten” Computer. Mit anderen Worten, das Gast-Betriebssystem, das auf der jeweiligen VM läuft, wird “getäuscht” und glaubt, dass es “auf authentischer Hardware” läuft – während es in Wirklichkeit auf der Hypervisor-Software aufsitzt (die die physische Hardware kontrolliert). Der Hypervisor teilt jeder VM je nach Bedarf seinen eigenen “Zeitabschnitt” für die Anforderungen der Applikationsprozesse zu – eine Form des Timesharing und eine Legacy-Computertechnik.

Durch Installation moderner VM Hypervisor-Produkte wie VMware ESX, Microsoft Hyper-V oder Open Source Xen (auf dem der XenServer von Citrix Systems sowie der Hypervisor von Virtual Iron Software aufbauen), können Unternehmen mehrere VMs pro Intel-Server laufen lassen. Wenn etwa drei VMs auf jedem Server installiert sind, kann die Gesamtmenge der erforderlichen Hardware-Server in einem Rechenzentrum um zwei Drittel reduziert werden – bei Hunderten oder Tausenden von installierten Servern bedeutet dies eine gewaltige Reduktion der erforderlichen Systeme.

Für das Netzwerk heißt das: Server mit Hypervisors und multiplen VMs erhöhen die Netzwerkkomplexität. Jede der VMs auf einem Host-Server benötigt in der Regel seine eigene Layer 3 Internet Protocol (IP) Adresse und eine eigene Layer 2 virtual Ethernet (vEnet) Domain. Dadurch können Datenpakete oder Frames, die an eine bestimmte VM adressiert sind (oder von ihr stammen) identifiziert werden; jede VM auf einem Server kann zudem, zum Zwecke der Einbindung in bestimmte Sicherheitszonen oder Aufgaben im Rahmen eines Quality of Service (QoS) Level, einem anderen Virtuellen LAN (VLAN) zugeordnet sein. Weil sich VMs jedoch die physische Netzwerkhardware auf dem Server teilen müssen – darunter Ethernet Network Interface Cards (NICs) und Ports – wird der Zugang der multiplen VMs zu diesen Netzwerk-Ressourcen üblicherweise von der Hypervisor-Software geregelt. Der Host Hypervisor kann auch eine direkte Kommunikation von VM zu VM auf demselben Server erlauben, wobei der Hypervisor lokal als Ethernet Bridge/Hub oder Switch fungiert.