Die Rolle von Ethernet Fabrics in virtualisierten Umgebungen

4 Kommentare Drucken

Der aktuelle Gartner Report „Emergence of Ethernet Fabric Will Push Users to Rethink Their Data Center Physical Switch Networks“ (16. Okt. 2013) beginnt mit dem Satz, Netzwerk-Profis sollten sich (endlich) auf den Weg zu höherer Effizienz und Automatisierung in ihren RZ-Netzen machen, und kommt schließlich zu dem Schluss, dass Netzwerke in Rechenzentren mit Ethernet Fabrics besser als mit allen anderen Optionen vereinfacht und automatisiert werden können.

Man muss den ersten Satz zweimal lesen: „Netzwerk-Profis sollten sich auf den Weg zu höherer Effizienz und Automatisierung in ihren RZ-Netzen machen.“ Was ist los in der Netzwerkbranche? Womit vertreiben die sich ihre Zeit? Liegt etwa die ganze Brache im tiefen Dornröschenschlaf? Ein Argument, das immer wieder stereotyp wiederholt wird, ist: „Die Netze funktionieren, warum etwas ändern“. Jetzt soll sich was ändern! Aber was? Und wie?

Die Fakten sind hinlänglich bekannt: Traditionelle Architekturen mit der klassischen Aufteilung in Access-, Aggregation- und Core-Layer erfüllen die Anforderungen moderner Rechenzentren nicht mehr:

  • Die Netzwerkkomponenten müssen im Wesentlichen einzeln, Gerät für Gerät administriert werden. Das ist aufwändig, kostet viel Zeit und ist darüber hinaus fehleranfällig. Die manuelle Eingabe mehrzeiliger CLI-Kommandos ist ein Anachronismus, den man sich zukünftig einfach nicht mehr leisten kann.
  • Das gleiche gilt, wenn neue Systeme ausgerollt werden müssen. Fragen wie „Passen die neuen Geräte in die bestehende Architektur?“, „Müssen zuerst Firmware-Updates eingespielt werden?“, „Welche der alten Systeme müssen angepackt werden?“, „Welche Auswirkungen hat das auf das gesamte Netzwerk?“ lassen sich nicht in ein paar Minuten beantworten.
  • Aber selbst (oder gerade !) wenn „nur“ neue Dienste, neue Server integriert werden sollen, ist mittlerweile das Netzwerk-Team der Engpass. Die Server- und Storage-Mannschaften haben in der Regel ihre Hausaufgaben gemacht und können dank Virtualisierung vieles voll- oder teilautomatisch ausrollen, das Netzwerk-Team hinkt da doch oft signifikant hinterher, von einer automatisierten Provisionierung sind wir weit entfernt.
  • Das klassische Drei-Ebenen-Modell des Netzwerks ist beim Einsatz moderner Software-Architekturen kontraproduktiv. Die Hauptlast im Rechenzentrum läuft nicht mehr in vertikaler Richtung zwischen den Servern und der Welt außerhalb des Rechenzentrums, sondern in horizontaler Richtung zwischen den einzelnen Servern und zwischen Servern und Storage.
  • Vor diesem Hintergrund ist es klar, dass es sehr schwierig ist, in solchen Infrastrukturen Netzwerkdienste flexibel zu gestalten. Aber gerade in virtualisierten Umgebungen wächst die Anforderung virtuelle Server mehr oder weniger freizügig im Netz wandern zu lassen. Das Netzwerk muss damit umgehen können, muss Policies zusammen mit der virtuellen Maschine bewegen, muss schlicht und einfach Konnektivität ermöglichen auch wenn die Maschine beispielsweise über die Grenzen des Rechenzentrums hinaus verschoben wurde.
  • Auch beim Thema Cloud Computing versagen klassische Architekturen auf der ganzen Linie. Cloud Computing verspricht Services „on-demand“ bereitzustellen! Aber ohne eine entsprechende Unterstützung im Netzwerk, ohne automatisierte Provisionierung, ohne eine deutliche Vereinfachung des Netzwerkmanagements bleibt dieses Versprechen wirkungslos.

Damit haben wir drei der wesentlichen Treiber für eine andere, modernere Netzwerkarchitektur im Rechenzentrum genannt:

  • die Mobilität virtueller Server
  • der zunehmende Ost-West-Verkehr im RZ und
  • Cloud Computing.

Darüber hinaus müssen wir natürlich dringend weg vom Spanning Tree und gerade aus großen Rechenzentren kommt außerdem die Anforderung mehr Mandantennetze als die 4.095, die mit VLANs möglich sind, aufbauen zu können.

Bleiben wir aber bei der Virtualisierung und der damit hand-in-hand gehenden Forderung nach mehr Automatisierung und schneller Provisionierung.

Gartner nennt traditionelle Netzwerkarchitekturen „VM transparent“, da sie zwischen virtuellen und physischen Servern und Diensten nicht unterscheiden können. Im Grunde würde „VM ignorant“ die Haltung vieler Netzwerker in den vergangenen Jahren und der Branche allgemein noch besser umschreiben. Wäre man schneller und deutlicher auf die speziellen Anforderungen virtueller Maschinen eingegangen, würde die Welt heute anders aussehen (Erinnern Sie sich: Virtuelle Switche mussten allein aus dem Grund eingeführt werden, weil das klassische Netzwerk keine Konnektivität zwischen virtuellen Maschinen auf demselben Host ermöglicht hat – in vielen Netzen ist das bis heute so!).

Netzwerk-Architekturen, die virtuelle Maschinen und ihre spezifischen Anforderungen ignorieren, können aber frühestens nachträglich reagieren, wenn VMs verschoben werden und Policys dynamisch zugewiesen werden müssen.

Wenn sich das Netzwerk aber jetzt wiederum weigert, simple Konnektivität zwischen virtuellen Maschinen herzustellen, nur weil die eine Maschine über eine Layer-3-Grenze hinweg verschoben wurde, dann muss sich niemand wundern, wenn die Hypervisor-Hersteller, allen voran VMware, wiederum die Sache selbst in die Hand nehmen. Overlay-Technologien wie VXLAN und NVGRE werden ja bereits ausgeliefert.
Wohin geht also der Weg?

  1. Wir müssen weg vom STP und brauchen Netzwerke, die Multi-Pathing unterstützen und in denen Multi-Pathing auch tatsächlich möglich ist – z.B. durch eine entsprechende Punkt-zu-Punkt-Verkabelung.

    An TRILL glaube ich persönlich in diesem Zusammenhang nicht mehr, im Grunde gibt es ja auch lediglich eine Reihe TRILL-ähnlicher, aber letztlich proprietärer Implementierungen – und der Einsatz proprietärer Protokolle ist immer mit der Gefahr verbunden, dass der eine einzige Hersteller die Weiterentwicklung dieses Protokolls einstellt.

    Bleiben die beiden Alternativen SPB und MC-LAG. SPB bietet sicher mehr Flexibilität, auch im Hinblick auf einen möglichen Einsatz im Campus und zwischen Rechenzentren. MC-LAG ist da mehr etwas für Traditionalisten, die allzu viel Flexibilität scheuen, außerdem skaliert MC-LAG natürlich nicht in großen Netzen.

    Eine herstellerübergreifende Interoperabilität sollten Sie übrigens trotz Konformität zu IEEE-Standards in beiden Fällen vorerst nicht erwarten.

  2. Wir brauchen Netzwerke, die „VM aware“ sind – sowohl um die Mobilität virtueller Maschinen zu unterstützen als auch um deren automatisierte Bereitstellung zu ermöglichen. Im Klartext bedeutet das die Zusammenarbeit zwischen dem Management der virtuellen Maschinen und dem Netzwerkmanagement.

    Setzt man stattdessen weiterhin auf VM-ignorante Netze, d. h. baut man dienstneutrale, rein auf den Transport optimierte Netze, überlässt man nahezu automatisch die Steuerung der Verkehrsflüsse den VM-Managementsystemen, die nach heutigem Stand der Technik Overlay-Netze über das zugrunde liegende Transportnetz spannen werden.

  3. Das Management der Netze muss einfacher werden. „Single-touch Management“ und „Zero-touch Deployment“ lauten die Marketing-Begriffe: Einheitliches Management der gesamten Fabric als ein einziger, alles umfassender Switch und automatische Selbstkonfiguration im Falle einer Erweiterung.

Gartner sieht Ethernet Fabrics als am besten geeignet, zum jetzigen Zeitpunkt ein Rechenzentrum zu modernisieren. Und tatsächlich unterstützen die meisten Fabrics, die heutzutage auf dem Markt sind, alle drei Forderungen. Punkt 3 kann man dabei fast als Definition des Begriffs „Fabric“ nehmen: ein Netzwerk, das auf Layer 2 und Layer 3 (mitunter auf Basis proprietärer Protokolle) sowohl von außen betrachtet als auch aus Administrationssicht aussieht, handelt und bedient wird wie ein einziger großer Switch: Ein Paket kommt an einen Rand in die Fabric und am anderen Ende wieder raus, diese Ports an den Rändern müssen gegebenenfalls konfiguriert werden, alles innerhalb der Fabric passiert automatisch.

Natürlich gibt es Entwicklungen wie beispielsweise LISP, um einige Aspekte wie z. B. Konnektivität über Layer-3-Grenzen hinweg auch in klassische Netze zu bringen, aber wenn Sie auch Automatisierung und eine Vereinfachung Ihres RZ-Netzes anstreben, brauchen Sie eine Lösung, in der alle Komponenten auf eine einfache Weise zusammenspielen.

Fabrics sind daher, auch angesichts der Marktverfügbarkeit, der natürliche und sinnvolle nächste Entwicklungsschritt im Rechenzentrum.

Inwieweit SDN hier in Zukunft eine Rolle spielen kann, lässt sich im Moment nur schwer abschätzen. Zweifellos hat SDN das Potential, den doch sehr trägen und irgendwie auch innovationsfeindlichen Netzwerkmarkt aufzumischen und es ist durchaus möglich, dass sich daraus eine gemeinsame Alternative zu den VM-gesteuerten Overlay-Netzen, die nichts von der zugrundeliegenden Physik, und den reinen Transportnetzen, die nichts von den transportierten Inhalten wissen, entwickelt. Zurzeit gibt es aber an zu vielen Stellen noch große Fragezeichen und die traditionellen Switch-Hersteller verteidigen verbissen ihren Markt.

SDN kann die Zukunft sein, Fabrics sind die Gegenwart.

zugeordnete Kategorien: LAN, Virtualisierung
zugeordnete Tags: , ,

Sie fanden diesen Beitrag interessant? Sie können



4 Kommentare zu "Die Rolle von Ethernet Fabrics in virtualisierten Umgebungen":

  1. Markus Schaub schreibt:

    „im Grunde gibt es ja auch lediglich eine Reihe TRILL-ähnlicher, aber letztlich proprietärer Implementierungen – und der Einsatz proprietärer Protokolle ist immer mit der Gefahr verbunden, dass der eine einzige Hersteller die Weiterentwicklung dieses Protokolls einstellt.“
    Gilt dieses Argument nicht noch viel mehr für jede Art von Fabric?

    • Cornelius Höchel-Winter schreibt:

      Das ist immer die gleiche Frage: Vertraue ich eher den Versprechungen des Herstellers oder setze ich mehr auf standardsbasierende Protokolle. Die Erfahrung zeigt, dass Protokolle und Verfahren, die auf Standards basieren, eher langfristig unterstützt werden als proprietäre.

  2. Michael Grundl schreibt:

    Sehr informativer und gut recherchierter Artikel.

    Einzig die Aussage:

    „Eine herstellerübergreifende Interoperabilität sollten Sie übrigens trotz Konformität zu IEEE-Standards in beiden Fällen vorerst nicht erwarten.“

    möchte ich ein wenig aufweichen, denn …

    Avaya hat die SPB Interoperabilität schon mit Alcatel/Lucent, Huawei und in Teilen auch mit HP erfolgreich getestet. Einzig z.B. bei den Multicast-Erweiterungen sind die jeweiligen Herstellerspezifikas relevant.

    SPB wird erfolgreich im Backbone der Olympischen Winterspiele in Sotschi eingesetzt und war auch auf der letzten Interop in Las Vegas erfolgreich implementiert. Wir glauben fest an die Zukunft diese außerst spannenden Netzwerkprotokolls, das unter IEEE 802.1ah bzw. IEEE 802.1aq spezifiziert wird.

    Michael Grundl
    Sales Leader Avaya Networking

  3. Dr. Kauffels schreibt:

    SPB ist letztlich ein schon recht altes und überaus bewährtes Protokoll aus dem Bereich der Fernnetze. In leicht veränderter Variante ist es letztlich Grundlage für Carrier Ethernet. Ich verstehe seit Jahrzehnten nicht, warum für den RZ-Bereich immer Sonderlocken gewickelt werden müssen, bei denen das Rad zum tausendsten Mal neu erfunden wird. Was die Interoperabilität betrifft, stimme ich Herrn Grundl mindestens zu. Wie gesagt, ausserhalb des RZs ist das überhaupt keine Fragestellung mehr. SPB erscheint Vielen vielleicht nicht modern genug. Aber die haben sich wohl noch nicht detaillierter mit Konzepten wie NSX von VMware oder Cisco´s ACI auseinandergesetzt. Dagegen ist SPB eine hell glänzende strukturierte Schönheit. TRILL war meiner Ansicht nach immer relativ aussichtslos, weil es einfach überflüssig ist.

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.