Schnittstellen im RZ: einfacher oder komplexer?

1 Kommentar Drucken

Mit der Servervirtualisierung übernahm die Virtualisierungslösung eine Netzfunktionalität, nämlich das Bereitstellen von virtuellen Switch Ports für die virtuellen Maschinen (VMs). Daher hat der Marktführer VMware diese Funktionalität als den sogenannten vSwitch implementiert. Später wurde zwischen dem in Standard Switch umbenannten einfachen vSwitch und dem Distributed vSwitch unterschieden. Die Idee beim Distributed vSwitch ist, dass mehrere vSwitches zu einer logischen Einheit zusammengefasst und an einer Stelle, in der Regel im Rahmen der Managementlösung für die ganze Virtualisierungsumgebung, konfiguriert und administriert werden.

Cisco Systems entwickelte für die zentrale Konfiguration mehrerer virtuellen Switches die Software Nexus 1000V. Damit ist es möglich, an zentraler Stelle alle virtuellen Switches so zu konfigurieren, als ob sie Bestandteile eines großen modularen Cisco-Switches wären.

Ähnlich wie VMware Distributed vSwitch bzw. Nexus 1000V sieht der in diesem Jahr verabschiedete Standard IEEE 802.1Qbg eine Methode vor, die Netzintelligenz auf dem einzelnen Virtualisierungshost zu minimieren. Der in diesem Standard definierte sogenannte Virtual Ethernet Port Aggregator (VEPA) ist ein Modus, bei dem der Virtualisierungshost alle Pakete der VMs, also auch jene von einer VM zur anderen, zum externen Hardware-Switch sendet und dieser die Pakete an andere VMs auf demselben physikalischen Port zum Virtualisierungshost zurückschickt. Somit wird die Switching-Konfiguration weitgehend vom Virtualisierungshost in Richtung Hardware Switch verlagert. Dass der Virtualisierungshost als VEPA fungiert, muss dem Hardware Switch bekannt sein, denn der bisherige Bridging-Standard schickt ein Paket niemals über einen Port zurück, über den es empfangen wurde.

Im Unterschied zum VMware Distributed Switch setzt der Standard IEEE 802.1Qbg auf die Implementierung der Edge Virtual Bridge (EVB) auf der Adapterkarte des Virtualisierungshosts. Bemerkenswert war die Abwesenheit der Hersteller von Virtualisierungslösungen wie VMware in der Standardisierung von VEB/VEPA.

Der Autor verfolgt mit Interesse die Diskussion der letzten Jahre über die Implementierung der Switch-Funktionalität für Virtualisierunhslösungen. Es sind nun ein paar Jahre seit der erstmaligen Verfügbarkeit von VMware Distributed Switch und Nexus 1000V vergangen. Ohne Anspruch auf die statistische Signifikanz der eigenen Beobachtungen stellt der Autor fest, dass der simple vSwitch bzw. Standard Switch weit mehr verbreitet ist als der Distributed Switch oder Nexus 1000V. Woran liegt das? Und was lernen wir daraus für die zukünftige Akzeptanz von VEB/VEPA?

Unterschiedliche Anforderungen

Servervirtualisierung ist eine Technologie, die mittlerweile in fast allen Rechenzentren präsent ist, von sehr kleinen mit einer Handvoll bis zu sehr großen mit tausenden physikalischer Server. Die Wahrheit ist, dass die Anforderungen dieser Anwender sehr unterschiedlich sind. Hier ein Versuch der Kategorisierung:

In sehr kleinen Rechenzentren, die kleine bis mittlere Unternehmen für die eigenen Zwecke betreiben, ist oft die Zuständigkeit für Server und Netz in einer Hand. Hier suchen die Verantwortlichen für die Server- und Netzinfrastruktur nach Lösungen, die möglichst automatisiert und ohne großen Aufwand funktionieren. Es wäre hier kein Problem, eine enge Integration und Interaktion von Server- und Netzhardware vorzusehen. Andererseits sind in solchen Umgebungen die Anforderungen an die Leistungsfähigkeit der Infrastruktur nicht so hoch, dass sie eine Implementierung aller virtuellen Switchfunktionen in der Virtualisierungssoftware verbieten würden.

In mittleren bis großen Rechenzentren, welche von großen Unternehmen für die eigenen Zwecke betrieben werden, ist die Zuständigkeit für Server und Netz fast immer getrennt. Der Grund ist einleuchtend: Die Netzverantwortlichen sind meistens nicht nur für die RZ-Netzinfrastruktur, sondern für das gesamte Netz des Unternehmens zuständig. Die Gemeinsamkeiten des erforderlichen Wissens für den Betrieb des RZ- und des restlichen Netzes sind immer noch viel größer als die Schnittmenge des erforderlichen Know-hows für den Netz- und den Serverbetrieb. In den letzten Jahren hat es immer wieder die Prognose gegeben, dass die Zuständigkeiten für den Server- und RZ-Netzbetrieb in eine Hand gehören. Die großen Unternehmen haben solche Prognosen kaum beeindruckt. Heute finden wir in den meisten mittleren bis großen Rechenzentren immer noch dieselbe organisatorische Arbeitsteilung wie vor zehn Jahren vor: Hier die Server und da das Netz. Der physikalische Switch- bzw. Endgeräteport ist Übergabepunkt und Schnittstelle zwischen den Zuständigkeiten der beiden Kompetenzbereiche.

In sehr großen Rechenzentren, welche von Cloud-Providern betrieben werden, unterscheidet sich die Situation grundlegend von den privaten RZ-Netzen. Die Public-Cloud-Betreiber sind mit anderen Herausforderungen konfrontiert. Bei einem Infrastructure as a Service (IaaS) kommt es zum Beispiel darauf an, zahlreiche Kunden, welche die RZ-Infrastruktur gleichzeitig nutzen, in die Lage zu versetzen, eigenständig und ohne Eingriff des Providers virtuelle Maschinen in Betrieb zu nehmen oder zu deaktivieren. Daher ist gleichzeitig ein Höchstmaß an Mandantenfähigkeit und Automatisierung gefordert. Derselbe Virtualisierungshost beherbergt gleichzeitig VMs vieler verschiedener Kunden, die gegenseitig nicht sichtbar sein dürfen. Ferner kommen laufend neue Kunden bzw. VMs hinzu oder sie entfallen. Ein solcher RZ-Betreiber kommt mit der Anzahl von 4.096 Gruppen, die mittels herkömmlicher VLAN IDs unterschieden werden müssen, nicht sehr weit. Ferner sind die Anforderungen an die Leistungsfähigkeit der Infrastruktur sehr hoch. Je mehr Kunden der Provider mit einer bestimmten Infrastruktur bedienen kann, umso mehr Umsatz und Rendite können erzielt werden.

Wozu mehr Komplexität?

Es ist unmöglich, eine Lösung zu finden, die gleichzeitig solch unterschiedliche Anforderungen optimal erfüllt. Leider bleibt in der öffentlichen Diskussion häufig die obige Unterscheidung zwischen verschiedenen RZ-Kategorien aus.

Vielleicht ist das der Grund, weshalb sich einige Lösungen, über die viel diskutiert und gestritten wird, für viele Rechenzentren als irrelevant erweisen. Über drei Jahre nach der Verfügbarkeit der ersten Versionen von VMware ESX, welche den Distributed Switch ermöglichten, ist dieser Ansatz für die meisten Betreiber der unternehmensinternen Rechenzentren kein Thema. Warum? Weil in solchen Rechenzentren die kritische Masse an ESX Hosts, die den komplexen Mechanismus der Integration mehrerer vSwitches zu einer logischen Einheit rechtfertigen würde, gar nicht zusammenkommt. Die Konfiguration von vSwitches auf den meisten ESX Hosts ist doch nicht so komplex, dass sie für die RZ-Betreiber einen sehr großen Aufwand verursachen würde, zumal VMware den isolierten vSwitch (Standard Switch) so robust und fehlertolerant gestaltet, dass die Fälle, in denen Serveradministratoren mit einer fehlerhaften vSwitch-Konfiguration das gesamte RZ-Netz lahmlegen kann, sehr selten sind.

Nach Ansicht des Autors gilt das, was für den VMware Distributed Switch galt, auch für VEB/VEPA. Dieser neue Standard erhöht die Komplexität der Schnittstelle zwischen den administrativen Domänen Server und Netz. Warum muss man sich diese erhöhte Komplexität einhandeln? Was gewinnt man dafür. Zumindest für den Fall der Rechenzentren, die dem Autor bekannt sind, sind keine Anforderungen ersichtlich, die den Einsatz von VEB/VEPA notwendig machen würden.

Insbesondere dort, wo die Zuständigkeiten für Netz und Server nach wie vor getrennt sind, kommt es ganz dringend auf einfache Schnittstellen an. Vielleicht erinnern sich die Leser an einige chronische Krankheiten, unter denen die IT in vielen Unternehmen zu leiden hatte:

  • Nicht abgestimmte und nicht funktionierende Einstellungen des Duplex-Modus beim Anschluss von Endgeräten an Ethernet Switches
  • Nicht abgestimmte und teilweise das ganze Netz in Mitleidenschaft ziehende Einstellungen der Link Aggregation Groups auf Servern und Switches
  • Destabilisierungen ganzer Netze durch die Flutung von Paketen aufgrund von problematischen Verfahren wie Microsoft Network Load Balancing
  • Schleifen mit katastrophalen Folgen für das ganze Netz, die durch fehlerhafte Konfiguration von Blade Switches in Server Blade Enclosures hervorgerufen wurden

Die wichtigste Lehre aus solchen Problemen war, das die Schnittstelle Endgerät-Netz vor allem einfach und robust sein muss, auch in dem Sinne, dass fehlerhafte Einstelllungen auf der Endgeräteseite maximal das Endgerät selbst beeinträchtigen sollten. Die große Akzeptanz für den Minimalmodus eines virtuellen Switches, der weder Spanning Tree spricht noch in der Lage ist, Schleifen im Netz zu verursachen, erklärt sich durch die o. g. oder ähnliche Erfahrungen.

Die wenigsten RZ-Betreiber sind bereit, diese wichtige Lehre in den Wind zu schlagen und sich auf zu komplexe Interaktionen zwischen Endgeräten und dem Netz einzulassen.

zugeordnete Kategorien: Data Center, LAN, Virtualisierung
zugeordnete Tags: , , , , ,

Sie fanden diesen Beitrag interessant? Sie können



Ein Kommentar zu "Schnittstellen im RZ: einfacher oder komplexer?":

  1. Dr.Kauffels schreibt:

    Der Wunsch nach einer möglichst einfachen und übersichtlichen Schnittstelle zwischen Netz und Endgeräten ist grundsätzlich zu unterstützen, die vielfältigen heute diskutierten Software-Komplikationen fügen nicht nur erheblichen Management-Aufwand hinzu, sondern können auch die Performance sehr negativ beeinflussen. Aus meiner Perspektive ist VEB/VEPA völlig unbrauchbar. Hier haben sich Netzwerk-Standardiseure zusammengesetzt, in die Hände geklatscht und gesagt: „heute definieren wir einen Betriebssystem-Mechanismus“, so etwa wie bei der Vorstandssitzung der 08/15-Bank. Und am Ende gab es Kuchen. Die VM-Kommunikation ist ein BS-Mechanismus und eine Standardisierung dafür kann von Netzwerk-Leuten gar nicht geliefert werden! Die Abwesenheit der Hersteller von Virtualisierungssoftware bei diesem historischen Ereignis ist zum einen dadurch zu begründen, dass sie sich nicht antun wollten, den LAN-Kollegen zu erklären, was ein Betriebssystem ist und wie es funktioniert. Zum anderen gibt es natürlich den Wunsch, aus Marketing-Gründen die VM-Kommunikation herstellerspezifisch zu belassen, was aus Sicht eines Betreibers natürlich zu verwerfen ist. Letztlich ist das eine Patt-Situation, was die Top-500 RZs und einen Großteil der Fortune-2000 RZ-Betreiber dazu gebracht hat, die VM-Kommunikation auf RDMA aufzusetzen, meist mit Infiniband als Übertragungstechnik, CEE wäre aber auch möglich. Das ist relativ einfach, schnell und niemand von den Virtualisierungsherstellern traut sich, es nicht zu unterstützen. Im Artikel werden jetzt drei Klassen von RZs unterschieden. Was ich aber überhaupt nicht verstehe ist, wieso denn private RZs nicht genauso von den Segnungen der Automatisierung und Mandantenfähigkeit profitieren können wie die Cloud-Provider. Vielleicht alles eine Nummer kleiner, aber eben in der gleichen Richtung. Die Perspektive dabei wäre, dass ein privater Betreiber eben eine private Cloud aufbaut und der Cloud-Provider eine öffentliche. Alleine der Wandel bei den Endgeräten und Tendenzen wie BYOD könnten das durchaus rechtfertigen.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.