Unter den Wolken

Großen Einfluss auf das Design von Netzwerken für Cloud-Umgebungen hat die Virtualisierung von Servern wie auch von Speicherressourcen. In Netzwerken von Unternehmen kann man dabei in der Regel den Speicherbedarf für einen definierten Zeitraum relativ gut vorhersagen. Daher ist es hier in absehbarer Zukunft durchaus opportun, mit getrennten Front- und Backend-Netzen – also einem dedizierten Datennetz und einem separaten Storage-Netzwerk – zu arbeiten. Die beiden Netze werden zwar mittel- bis langfristig beide auf Ethernet basieren, müssen dabei aber nicht zwangsläufig zusammenwachsen.

 

Im Netzwerk eines Cloud-Providers sieht das jedoch anders aus. Denn hier lässt sich der zukünftige Bedarf an Storage-Kapazitäten nur sehr schwer bis gar nicht vorhersagen. Für ein skalierbares Design einer Cloud-Umgebung ist daher eine Voraussetzung, dass auch die virtualisierten Storage-Ressourcen einfach erweiterbar sind. Dieses erreicht man bei dem Design einer neuen Umgebung am effektivsten, indem sowohl alle Nutz- als auch alle Storage-Daten über dasselbe Ethernet-Netzwerk laufen.

 

Veränderte Verkehrsflüsse

 

Um die Auswirkungen der Virtualisierung auf das Design eines Cloud-Netzwerks zu erkennen, muss man zunächst die dort zu erwartenden Verkehrsströme betrachten. In einem klassischen Unternehmens-RZ findet Datenverkehr überwiegend zwischen den Clients der Mitarbeiter und den Servern im Datacenter statt. In einer hoch virtualisierten Cloud-Umgebung hingegen verbleibt ein Großteil des Verkehrs im RZ – insbesondere wenn man mit virtualisierten Storage-Ressourcen arbeitet. Denn dann wird das Netz sozusagen zum neuen Systembus, bei dem Server mit „ihrer Festplatte“ nicht mehr über den internen Bus ihrer Motherboards kommunizieren, sondern über das Netzwerk beispielsweise mit iSCSI-Storage-Systemen. Zudem führen die Hochverfügbarkeit virtueller Server sowie das Wandern virtueller Maschinen von einer Hardware zur anderen zu wachsendem Datenverkehrsaufkommen im RZ, als „Ost-West“-Verkehr bezeichnet. Ein skalierbares Netzwerkdesign für Clouds muss dem steigenden Anteil des Ost-West-Verkehrs Rechnung tragen.

 

Frage der Performance

 

Des Weiteren ist die Performance innerhalb des Netzes ein wichtiger Punkt. Stand heute ist hier der Anschluss von Servern mit 10 Gigabit pro Sekunde (über 10 Gigabit Ethernet, 10GbE) die Regel. Im Uplink sollten Switches dann vorzugsweise 40 Gigabit Ethernet und in absehbarer Zeit auch 100 Gigabit Ethernet verwenden. Entsprechend sollte ein Betreiber eines solchen Netzes bei der Auswahl seiner Switches auf eine hohe Portdichte bei 40GbE sowie zumindest auf einen schon heute definierten Migrationspfad zu 100GbE achten.

 

Viele Server und Applikationen in Cloud-Rechenzentren benötigen eine große und schnelle Layer-2-Netzwerkumgebung. Dies erfordert Mechanismen zur Schleifenunterdrückung und zur Redundanz im Fehlerfall eines Links. Der klassische Spanning Tree genügt heutigen Anforderungen nicht mehr, da das Redundanzprotokoll alle aktiven Links bis auf einen blockiert. Dies wiederum macht eine Vollvermaschung unter Ausnutzung aller aktiven Links unmöglich. Um diesen Mangel zu beheben, haben sowohl Standardisierungsgremien als auch einzelne Hersteller neue Protokolle und Techniken entwickelt, die eine nähere Betrachtung verdienen.

 

TRILL und SPB

 

Von der Internet Engineering Task Force (IETF) stammt Transparent Interconnect of Lots of Links (TRILL), während das Institute of Electrical and Electronics Engineers (IEEE) Shortest Path Bridging (SPB) entwickelt. Beide Verfahren sind sich in der Grundidee ziemlich ähnlich: Über ein Link-State-Protokoll – in diesem Fall das Intermediate System to Intermediate System Protocol (IS-IS) – bauen die beteiligten Switches eine Datenbank über alle verfügbaren Wege auf. Mit deren Hilfe können sie dann im Einzelfall entscheiden, welchen Weg ein Paket nehmen soll. Dabei sind alle beteiligten Links gleichzeitig aktiv, ohne dass es zu einer Schleifenbildung kommt.

 

Beide Verfahren befinden sich noch in den Endphasen der Standardisierung und wurden bisher nur von einigen Herstellern umgesetzt. Das Gros dieser Hersteller setzt dabei auf TRILL. Allerdings hat dieses Protokoll auch einige Nachteile. So verändert TRILL das Frame-Format, da es einen zusätzlichen Header verlangt. Demzufolge wird TRILL von der heute installierten Hardware größtenteils nicht unterstützt. Nur Geräte der neuesten Generation können bereits jetzt das neue Frame-Format verarbeiten. Darüber hinaus ist der Layer-3-Übergang bei TRILL relativ schwierig, und ein TRILL-Netz ist nicht mandantenfähig.

 

Fabric-Phantasien

 

Einige Hersteller propagieren in letzter Zeit den Einsatz sogenannter Fabrics. Diese Fabrics kombinieren alle Switches eines Cloud-Netzwerks zu einer einzigen logischen Einheit und stellen sich nach außen wie ein einziger großer Switch dar. Das klingt zunächst verlockend, da das gesamte Netz fortan über eine einzige logische Instanz verwaltet werden kann. Entsprechend werben die Hersteller solcher Lösungen auch gerne mit dem Begriff „Single Hop Network“. Doch in der Praxis sind solche Versprechungen mit äußerster Vorsicht zu genießen. Denn zunächst handelt es sich bei allen verfügbaren Fabric-Lösungen ausschließlich um rein proprietäre Technik. Der Käufer einer entsprechenden Umgebung legt sich also auf einen einzigen Hersteller für seine Netzwerkkomponenten fest.

 

Zudem ist der Begriff „Single Hop Network“ genau betrachtet nicht mehr als eine Marketing-Floskel. Denn auch die Fabric-Netze arbeiten mit verschiedenen Ebenen. Wenn also ein Paket zum Beispiel von einem Top-of-Rack-(ToR-)Switch zu einem anderen geschickt werden soll, führt dessen Weg weiterhin über mehrere Ebenen. Der „Single Hop“ ist rein virtuell und hat in der Praxis weder einen positiven Einfluss auf die Überbuchung noch auf die Latenzzeiten im Netz. Zudem gestaltet sich die Fehlersuche in einem Fabric-Netz äußerst schwierig, da es nahezu keine manuellen Möglichkeiten gibt, das Verhalten der Fabric zu beeinflussen, und auch die Verkehrsströme in der Fabric folgen nicht mehr klar definierten Wegen und Regeln. Grundsätzlich ist also von der Verwendung solch proprietärer Lösungen abzuraten.

 

Offene Alternative

 

Einen vergleichbaren, dabei jedoch offenen Ansatz verfolgt die Open Network Foundation mit OpenFlow. Ziel dieser Architektur ist die Entkoppelung der Control-Plane von Switches von der Data-Plane. Die Weiterleitungsentscheidung wird dabei von einem externen Open-Flow-Controller auf Basis von Flows getroffen. Der Open Network Foundation gehören nahezu alle relevanten Netzwerkhersteller an, sodass man OpenFlow als gleichwertig mit einer standardisierten Lösung betrachten kann. Allerdings gibt es derzeit erst einige wenige Testumgebungen, hauptsächlich an Universitäten. Bis zur Marktreife von OpenFlow wird also noch einige Zeit vergehen. Doch dann kann diese Spezifikation sicherlich eine ernsthafte Alternative für Rechenzentrumsnetze darstellen.

 

Eine aus heutiger Sicht optimale Umsetzung einer Layer-2-Struktur für Cloud-Umgebungen baut auf die Kombination zweier bestehender Techniken: das Stacking mehrerer Top-of-Rack- Switches in Verbindung mit Multi-Switch Link Aggregation Groups (MLAG). Das Stacking verbindet mehrere (meistens bis zu acht) ToR-Switches zu einer logischen Einheit. Im Gegensatz zur Fabric erfolgt dies über einen dedizierten Bus mit bis zu mehreren hundert GBit/s an Bandbreite. Dieses Verfahren hat sich gerade für die Verbindung von ToR-Switchen bewährt, da es die Zahl zu verwaltender Switches reduziert und den Ost-West-Verkehr zwischen benachbarten Schränken über den internen Bus und nicht über den Core abwickelt.

 

Die Stacks verbindet man dann über MLAG-Gruppen mit dem Core. Eine MLAG-Gruppe ist dabei prinzipiell nichts anderes als eine klassische Link Aggregation Group nach IEEE 802.1AX (früher 802.3ad): Mehrere physische Links bilden einen logischen Link, um die Gesamtbandbreite zu erhöhen. MLAG verteilt diese logischen Links im Core jedoch auf zwei verschiedene Systeme. Nach außen erfolgt dies transparent: Der angeschlossene Server oder ToR-Switch erkennt nicht, dass er mit zwei verschiedenen Systemen verbunden ist, für ihn handelt es sich weiterhin um eine klassische Link Aggregation Group. Somit ist MLAG zwar streng genommen ebenfalls eine proprietäre Lösung, da die beiden Core-Systeme vom selben Hersteller sein müssen. Allerdings betrifft dies ausschließlich die Core-Ebene und ist nach außen nicht ersichtlich. Bereits die ToR-Switches können von jedem beliebigen Hersteller sein. Und selbst der Core ließe sich mit überschaubarem Aufwand durch Systeme eines anderen Herstellers ersetzen.

 

Praxisbeispiel

 

Wie sich diese Grundlagen einer Cloud-Infrastruktur in der Praxis umsetzen lassen, zeigt ein Designbeispiel, das Extreme Networks für einen großen Cloud-Hosting-Provider entwickelt hat. Da dessen Netzwerk hochskalierbar sein soll, ist das Design sehr modular aufgebaut. Die kleinste Einheit besteht dabei aus einem so genannten Portable Optimized Datacenter (POD). Ein POD besteht wiederum aus zwei Schränken (Racks). In jedem Schrank sind 20 Server und zirka 50 TByte iSCSI-Storage untergebracht. Außerdem befindet sich in jedem Schrank ein ToR-Switch mit 48 10GbE-Ports sowie vier 40GbE-Uplink-Ports (Bild 1). Server und Storage-Systeme sind mit MLAG-Gruppen an die beiden ToR-Switches angebunden. Reicht die Kapazität eines PODs nicht mehr aus, kommt einfach ein zweites hinzu. In diesem Fall bilden jeweils die linken und die rechten ToR-Switches einen Stack, also eine logische Einheit. Beide PODs haben also weiterhin nur zwei logische ToR-Switches (Bild 2).

 

Ist das Netzwerk auf vier PODs angewachsen, so entsteht eine Datacenter-Zone. Auch innerhalb der Zone sind die jeweils linken und rechten ToR-Switches zu einem Stack zusammengeschaltet (Bild 3). Also hat auch eine Zone nur zwei logische ToR-Switches. Die Stacking-Bandbreite zwischen den einzelnen ToR-Switches beträgt 160 GBit/s. Dieses Design hat den Vorteil, dass der Ost-West-Verkehr einer Zone diese nicht verlassen muss. Lässt sich die Storage-Virtualisierung auf jeweils eine Zone beschränken, muss der Ost-West-Verkehr dann nicht mehr über den Core fließen. Dies wirkt sich auch positiv auf die Überbuchung der Uplinks zum Core aus.

 

Distributionsebene ersatzlos gestrichen

 

An dem Design fällt auf, dass es keine End-of-Row- oder Distributionsebene gibt. Dies liegt daran, dass es bei den heute verfügbaren Port-Dichten von Core-Switches meist ausreicht, mit einer oder zwei Netzwerkebenen zu planen. Moderne Core-Switches stellen beispielsweise bis zu 768 10GbE-Ports oder bis zu 192 40GbE-Ports auf etwa 14 Höheneinheiten zur Verfügung. Mit solchen Port-Dichten lassen sich im POD-Design über MLAG-Gruppen bis zu 22 Zonen mit jeweils 320 GBit/s an den Core anbinden (Bild 4). Von jedem ToR-Switch geht ein Link mit 40 GBit/s zum Core. Alle acht Links sind zu einer logischen Verbindung zusammengefasst. In der Summe ergibt dies im Beispiel bis zu 176 Schränke mit insgesamt 3.520 Servern in einem rein zweistufigen Netz. Das Limit ist damit jedoch noch lange nicht erreicht: Theoretisch wäre ein Ausbau auf über 9.000 Server mit bis zu 128.000 virtuellen Instanzen möglich.

 

Fazit: Cloud benötigt hohe Skalierbarkeit

 

Das wichtigste Designelement von Cloud-Umgebungen ist die Skalierbarkeit virtualisierter Server, Storage-Ressourcen und des Netzwerks. Mit heute verfügbarer Netzwerktechnik wie 40GbE, MLAG und Stacking ist es möglich, eine von 40 bis auf über 9.000 Server skalierbare hochperformante Infrastruktur aufzubauen, ohne auf proprietäre Technik zurückgreifen zu müssen. Damit eignet sich dieses Design gleichermaßen für Rechenzentren mittelständischer Unternehmen wie für Betreiber großer Cloud-Umgebungen.

Weitere Artikel zu saperion AG

Weitere Artikel zu LG Electronics Deutschland GmbH