Netzwerk-Design in Zeiten von 10/40/100 Gbit: Wie sieht die Zukunft aus?

Kommentieren Drucken

Aktuelle Trends in der Kommunikations-Entwicklung verändern das das Netzwerk-Design. Dies gilt sowohl für den Data Center als auch den Campus und Access Bereich. 10 Gbit Technologie ist Legacy geworden. 40 Gbit Technologie ist in den meisten etablierten Produktlinien vorhanden, 100 Gbit stellt derzeit die Technologie-Spitze dar. Modernes Netzwerk-Design reduziert sich jedoch nicht nur auf Datenraten sondern nutzt auch intelligente und neue Technologien. Hat die Lebenszeit von sternförmigen Spanning Tree Strukturen somit ihr Ende erreicht? Der nachfolgende Beitrag befasst sich mit grundlegenden Design-Aspekten und ihrer Umsetzung in der Welt der 10/40/100 Gbit Komponenten und Produkte. Er erläutert, welche herstellereigenen und standardbasierten Nachfolgertechnologien aktuell in Entwicklung sind und welche Marktgruppen diese Technologien nach vorne tragen wollen.


1. Aktuelle Trends

Anwendungstrends
Mobilzentrische Applikationen und Nutzerschnittstellen: Das Zeitalter von Fensteroberflächen, Icons und Menüs nähert sich seinem Ende. Weboberflächen, Touchscreens und Gestenbedienung oder Sprach¬steue¬rung bestimmen das kommende Zeitalter. Applikationen werden einfacher und vielfältiger werden. Verteilte Appstores werden das klassische Rechenzentrum zumindest ergänzen. Mit Web 2.0, HTML5 und WebRTC / RTC-Web werden auch Web-Applikationen multimediafähig werden.

Cloud Computing: Wurden in 2012 noch 111 Mrd. USD für Cloud Computing ausgegeben, so wurden für 2013 schon 131 Mrd. USD geschätzt, was einem Wachstum von 18,5% entspricht (Quelle: Gartner, 02/2013). Damit hat sich der anfängliche Einsatz in 2011 zu einem deutlichen Boom vergrößert. 451 Research sieht von 2011 bis 2016 ein CAGR von 36% für Cloud Dienste (19,5 Mrd. USD Umsatz in 2016; Quelle: TheInfoPro Wave 5 Cloud Computing Study, 1. Hj. 2013).

Fortschreitende Konvergenz: Multimediaunterstützung auf vielen bis allen Endgeräten wird zum verstärkten Einsatz von Voice und Video in Kombination mit IT-Applikationen sowie zur Anreicherung aller etablierten Applikationen mit Kommunikations-Funktionen führen (Stichwort: WebRTC).

Trends im Nutzerbereich
Mobilität: Hand in Hand mit BYOD geht der Trend zur Mobilität: „Always on“ ist das neue Schlagwort, und Smartphone oder Tablet machen es möglich. Auch der Laptop-Formfaktor wird immer transportabler. Mobilität wird ebenfalls neue Anforderungen an die Zugangs-Administration des Netzwerks stellen.

Multimedia: Der moderne Nutzer gibt sich nicht mehr mit PC und Telefon zufrieden. Aus dem Trend zur Mobilität wird der Trend zur mobilen Multifunktionalität: IT und UC – d.h. Daten, Kontakte, Terminkalender, Anwendungen, Voice und Video in einem Gerät und überall.

BYOD: Bring Your Own Device wird zu einer weiter erhöhten Vielfalt von Endgeräten im Netzwerk führen. Dies stellt völlig neue Herausforderungen an die Zugangs-Administration und wird die Einführung neuer Sicherheits-Konzepte bedingen.

Die genannten Trends werden mit IEEE 802.11ac und IEEE 802.11ad und den resultierenden hohen möglichen Datenraten auch auf Wireless LAN Infrastrukturen durchschlagen.

Data Center Trends
Server-Virtualisierung: Server werden zunehmend virtualisiert und somit in weiten Teilen unabhängig von der Hardware, auf der sie gerade laufen; dies beinhaltet auch Servermobilität über mehrere RZs hinweg. Im Gegensatz zur Netzwerk-Virtualisierung, die noch in den Kinderschuhen steckt, hat sich Servervirtualisierung in den letzten 3 Jahren massiv durchgesetzt: X86 Server sind inzwischen weltweit schon mit deutlich über 50% virtualisiert (451 Research TheInfoPro, 2013), über alle Server betrachtet ist die Workload schon zu 60% virtualisiert (Quantum Survey, 2013). Allerdings stießen dabei viele IT-Manager in der Umsetzung auf unerwartete Schwierigkeiten, nur 10 Prozent fanden die Umstellung problemlos (Quantum Survey, Cisco Survey, siehe auch Bild 1). Zunehmend leistungsfähigere Hardware bedingt höhere Datenraten, 10 Gbit wird Legacy Technologie zur Serveranbindung.

Extreme Datenvolumen: Größe, Format-Komplexität und Zugriffsgeschwindigkeit wachsen in einem Maß, das aktuelle Technologien und das „Single Warehouse“ Paradigma an ihre Grenzen bringt. Zukünftig werden Nutzer sehr großer Unternehmen ihre Daten aus verteilten Speicherzentren abrufen.

Data- / Storage Konvergenz: SAN-Umgebungen werden zunehmend mit dem RZ-LAN integriert. FCoE hat zwar keinen echten Durchbruch erreicht, aber mit zunehmenden Datenraten (10 Gbit, 40 Gbit, 100 Gbit Ethernet) bietet iSCSI eine Alternative. Die Integration von Verkehrslasten für Speicher-Zugriffe mit Applikations- und Nutzerzugriffen stellt neue Herausforderungen an die RZ-LAN Infrastruktur. (siehe Bild 1)

Netzwerktrends
40/100 Gbit Ethernet: 1 Gbit am Endgerät ist bereits Legacy-Technologie; 10 Gbit wird Legacy-Technologie für Server, Backbone und Serverswitch-Uplinks werden schrittweise auf 40 Gbit und 100 Gbit hochgerüstet.

IoT (Internet of Things): Das Internet der Dinge (Haushalts-Zähler, Kfz-Leitsysteme, Lieferungs-Tracking etc.) wird ein Push-Faktor für IPv6 werden.

Steigender Managementbedarf: Integriertes zentrales Management für Storage, LAN und WLAN, für physische und virtuelle Ports ist die Aufgabe, die die Hersteller lösen müssen. Konfiguration, Administration und Monitoring muss zentral bereitgestellt werden. Der Trend geht vom historischen Monitoring zum Online-Monitoring, insbesondere auch mit dem Ziel eines proaktiven Managements.

2. Resultierende Anforderungen an moderne Netzwerke

Applikations-Anforderungen
Cloud Computing bedeutet hochdynamische Bereitstellung von Server- und Netzwerk-Ressourcen inklusive der hierfür notwendigen Leistungsbedingungen für Bandbreite, Delay und Verlust-Minimierung.

Gleiches gilt für Multimedia-, Web- und mobilzentrische Applikationen, die zusätzlich sehr unterschiedliche QoS-Bedarfe und variable Bandbreitenbedarfe bei Datenzugriff und Echtzeit-Video / UC generieren.

Anforderungen im Nutzer- / Access-Bereich
Mobilität verschiedenster Endgeräte wie Tablets, Laptops oder Smartphones wird die feste Zuordnung von Nutzern und Geräten zu spezifischen Netzwerkports beenden. Gleiches gilt für den immer stärkeren Einsatz von Multimedia-Endgeräten (PC, Laptop, „UC-Telefone“, iPad, Android Tablet, Smartphone und weitere).

Multimedia-Fähigkeit und -Einsatz führt zu steigenden und sehr variablen Datenraten am Endgerät und am Etagen-Uplink. QoS-Zuordnung muss applikationsbezogen und nicht mehr geräte- / VLAN-bezogen erfolgen. Einer Studie von Information Week (03/2010) zufolge ist Paketverlust immer noch ein Problem in aktuellen Netzwerken: 7,5% der Uplinks von 20 untersuchten Unternehmen hatten Fehlerpakete und Input Discards. Es wurden durchschnittlich 745 Paketverluste je Interface pro Stunde gemessen. Für Hochqualitäts-Video ist dies nicht mehr akzeptabel, zumal es sich nicht immer um Einzelverluste handelt sondern bei Eingangs-Überlasten auch Burst-Verluste auftreten können.

BYOD wird ebenfalls die (von uns immer wieder kritisierte) Netzwerk-Trennung nach Gerätetypen (Telefon-VLAN, PC-VLAN, Drucker-VLAN) endgültig ad absurdum führen. Die für Mobilität und BYOD erforderlichen neuen Sicherheits-Konzepte werden auch Einfluss auf das VLAN-Design haben.

Zusammenfassend muss ein modernes Netzdesign folgende Aspekte und Anforderungen im Access Bereich berücksichtigen und abdecken:

  • Mobilität, dynamische Anschaltung desselben Nutzers an wechselnden Netzwerkports
  • Seiteneffekte campusweiter VLANs (Beispiel: Gast WLANs, Ethernet VLAN für Externe)
  • Beseitigung des Bottlenecks zentrale Steuerung (Beispiel: WLAN VLANs)
  • dynamische Bereitstellung von Ressourcen
  • Bedarf nach Automatisierung
  • Netzwerk Access übernimmt bisher zentrale Kontrollfunktionen
  • Netzwerk Access kann beliebig Switch oder Access Point sein
  • Authentisierung, NAC und QoS-Implementierung am Edge
  • keine zwingende Trennung von drahtgebundener und drahtloser Kommunikation mehr „hinter“ dem Access-Punkt
  • Management-Integration von Wired und Wireless

Data Center Anforderungen
Die fortschreitende Server-Virtualisierung bringt eine Reihe von Herausforderungen mit sich: Dynamische Bereitstellung des Kommunikations-Kontexts (IP-Adresse, VLAN) über zwei oder mehr Data Center Standorte hinweg, dynamisch geänderte MAC-Adressen, Handhabung virtueller MAC-Adressen und virtueller serverinterner Switches, hochdynamische Verkehrslasten und Online-Überwachung dynamisch bewegter Server- und Kommunikationskontexte. Massives Tracking einer hohen Anzahl von MAC-Adressen und IP-Adressen wird erforderlich. Link Aggregierung, verteilte Link Aggregierung, NIC Teaming und Bonding müssen in Switches und Servern zueinander passend konfiguriert und überwacht werden.

Virtuelle Switches sowie gegebenenfalls auch andere virtuelle Netzkomponenten (Router, Firewalls, Loadbalancer), die auf den Hostsystemen implementiert werden, müssen netzwerktechnisch und managementseitig in die Netzwerk-Infrastruktur integriert werden.

Die Verbindung von n-Tier-Architekturen mit Sicherheits-Zonen sowie die zunehmende Server-Mobilität (z.B. vMotion) und dynamische Serverbereitstellung führt Im Rechenzentrum zu neuen Netzwerk- und VLAN-Designanforderungen.

Die Verbindungs-Infrastruktur zwischen Speichermedien und Servern wird zunehmend mit der Server-Server-Verbindungs-Infrastruktur integriert, RZ-LAN und RZ-SAN konvergieren zu einer gemeinsamen Ethernet-basierten Infrastruktur.

Vielfältige Server-Server-Verkehrsströme in Verbindung mit massiven Speicherzugriffen führen zum Bedarf nach eklatant höherer Ost-West Bandbreite und vermaschten Infrastrukturen, da Stern-strukturen hinsichtlich Delay und Leistung an den Konzentrationspunkten überlastet werden.

Zusammenfassend muss ein modernes Netzdesign folgende Aspekte und Anforderungen im Data Center berücksichtigen und abdecken:

  • Mobilität, dynamische Anschaltung desselben (Virtuellen) Servers an wechselnden Netzwerkports
  • Einsatz kritischer Applikationen hinsichtlich Bandbreite und Latenzzeit
  • dynamische Bereitstellung von Ressourcen
  • dynamische Bereitstellung von QoS Policies und ACLs für Basis-Sicherheit auf Basis physischer Ports
  • Bedarf nach Automatisierung
  • Seiteneffekte RZ-übergreifender VLANs (Beispiel: HA, Cluster, Heartbeats, Management)
  • 2-Tier Hierarchie anstelle einer 3-Tier oder mehr-Tier Hierarchie
  • Ausdehnung von Layer-2 über DCs hinweg
  • Nutzung effizienterer Schaltverfahren mit Lastverteilung zur Erreichung der Verfügbarkeitsanforderungen
  • Core-Switches mit hoher bis sehr hoher Portkonzentration
  • Niedrige Überbuchungsraten für DC Uplinks
  • „Lossles“ Ethernet, Data Center Bridging (DCB) Verfahren
  • Overlay-Netze und VLANs zur Connectivity und Kontrolle der Broadcast-Domänen
  • Haupt-Verkehrslast: Server – Server = Ost – West → Optimierung des Ost-West Verkehrs (Server-Server Verkehrslast)
  • integriertes / konvergentes Design für Daten- und Speicherzugriff

Anforderungen im Campus-Bereich
Der Campus-Bereich stellt die Verbindungs-Infrastruktur zwischen den Gebäuden bzw. dem nutzerseitigen Access-Bereich und dem Data Center beziehungsweise den Servern und Daten bereit, das heißt er muss die Endgeräte sinnvoll und zuverlässig mit den verschiedensten Servern verbinden.

Für die Anbindung der einzelnen Gebäude ist jeweils zu entscheiden, wie über das Campus-Netzwerk einerseits eine angemessene Datenrate und Dienstgüte hinsichtlich Latenzzeit, Jitter und Verlustraten, andererseits angemessene Redundanz realisiert werden soll. Benötigt das Gebäude 10G, 40G oder 100G als Campus-Zugang? Wird es nicht-redundant, mit zwei Interfaces redundant oder mit zwei Gebäudeswitches redundant an den Campus angebunden?

Für die RZ-Anbindung wird typischerweise eine HA-Redundanz vorgesehen, da dies einer der kritischsten Netzwerk-Infrastruktur-Bereiche ist: Kein RZ-Zugang, kein Server- und Daten-Zugriff … Zu entscheiden ist jedoch, mit welcher Datenrate, respektive Überbuchung das Rechenzentrum an den Campus anzubinden ist. Dies sollte natürlich in Relation zur Summenbandbreite der Gebäude-Anschaltungen geplant werden.

Zusammenfassend muss ein modernes Netzdesign folgende Aspekte und Anforderungen im Access Bereich berücksichtigen und abdecken:

  • angemessene Datenrate und Dienstgüte für die Gebäudezugänge
  • angemessene Redundanz für die Gebäudezugänge
  • angemessene Datenrate und Dienstgüte für die Verbindungs-Infrastruktur zwischen Gebäuden und Data Center
  • angemessene Redundanz für die Verbindungs-Infrastruktur zwischen Gebäuden und Data Center
  • angemessene Datenrate und Dienstgüte für den Data Center Zugang
  • HA-Redundanz für den Data Center Zugang

Fazit: Welche Designziele ändern sich, welche bleiben erhalten?
Wir halten fest: Die aktuellen Trends von IT und Kommunikation verändern das Gesicht unserer Netzwerke. Mehrere lang gehegte Design-Prinzipien lassen sich zukünftig nicht mehr ohne weiteres aufrechterhalten. Aktuelle Redesign-Überlegungen betreffen entsprechend die Designziele

  • Minimierung der VLAN-Anzahl
  • kleine Brodadcast-Domänen
  • sternförmige Designstrukturen
  • statische Provisionierung von Bandbreite und QoS
  • statische IP Subnetzstrukturen
  • statische NAC-Vorgaben

Die zunehmende Anwendungsvielfalt und IT-Durchdringung steigert nach wie vor die Abhängigkeit vom Netzwerk. Einige seit Jahren bekannte Anforderungen bleiben daher mit steigender Relevanz erhalten:

  • Netzwerk-Skalierbarkeit
  • Netzwerk-Robustheit
  • Fehlerabschottung
  • Fehlertoleranz
  • Redundanzauslegung
  • automatisierte Fehlerumschaltung
  • schnelle Fehlerumschaltung
  • Beherrschbarkeit des Betriebs
  • Überwachbarkeit
  • Sicherheit

Was ändert sich? Die etablierten Layer-2 Redundanzverfahren und resultierenden sternförmigen Strukturen sind nicht mehr zeitgerecht. Ring-Strukturen haben mit Spanning Tree hinsichtlich Durchsatz und Delay eine schlichtweg grauenhafte Leistung und kommen daher nicht zum Einsatz. Einfache Link Aggregierung hat den Totalausfall eines Switches als Single Point of Failure. Sternstrukturen führen an den zentralen Konzentrationspunkten zu potenziellen Bottlenecks, aufgrund der hohen Switchkaskaden zu erhöhten Delays und aufgrund der ungenutzten Redundanzen zu erhöhten Investkosten. Die tatsächliche Ausnutzung einer hochredundanten sternförmigen Netzwerkinfrastruktur und das resultierende Bottleneck-Risiko zeigt Bild 2.

Geroutete Ringstrukturen haben zwar eine bessere Leistung als mit Spanning Tree, sind jedoch bei campusweiten VLANs nur bedingt einsetzbar und effizient, da sie für die campusweiten VLANs mit Spanning Tree überlagert werden müssen. Wir gehen an späterer Stelle nochmals näher auf dieses Design ein.

Der Wunsch nach besserer Ressourcen-Ausnutzung sowie der Bedarf nach höherer Summen-bandbreite und ständig niedrigerem Delay führt insbesondere im Data Center Bereich zum Bedarf für verteilte und vermaschte Netzarchitekturen. Hier etablieren sich neue Technologien im Markt. Verteilte und und vermaschte Netzarchitekturen können aber auch im Access und Campus Bereich Vorteile bringen und werden sich daher langfristig auch in diesen Bereichen etablieren. Potenzielle Kandidaten sind:

  • Verteilte Link Aggregierung (IRF, MC-LAG, Bonding, Virtuelles Chassis, VSS)
  • Layer-2 Multipath (TRILL, SPBM)
  • Fabric-Architekturen (Cisco VPC, Brocade VCS, Juniper QFabric)
  • Netzwerk-Virtualisierung (SDN, OpenFlow)

Nachfolgend werden wir anhand von Design-Beispielen die Vorteile und Nachteile von Design-Elementen diskutieren, die sich aus den zuvor genannten Verfahren ergeben, und darstellen, welche Hersteller welche Technologien favorisieren.

3. Design-Elemente: Baum-/ Sternförmige Designs

Nicht nur beeinflusst durch den Spanning Tree haben sternförmige Netzwerk-Designs die letzten 20 Jahre geprägt. Auch in gerouteten Umgebungen sind sternförmige Designs oft eine leistungsstarke Alternative zur aufwändigen Vollvermaschung. Baum- oder Sternstrukturen sind übersichtlich und gut durchschaubar, was die spezifische Leistung (Datenrate) an einem bestimmten Netzwerk-Punkt betrifft. Allerdings hat eine reine Sternstruktur den Nachteil fehlender Redundanz. Trotzdem kann sie bei entsprechend moderaten Verfügbarkeitsanforderungen aus Kostengründen im Access Bereich zum Einsatz kommen: Die Endgeräte werden über nichtmodulare Access Switches sternförmig an einen Gebäude-Konzentrator (Switch) angeschaltet. Dieser hat wiederum eine Anbindung an das Campus-Netzwerk, respektive einen Core-Switch (siehe Bild 3).

Mit zunehmender Gbit-Fähigkeit der Endgeräte migriert der Access Switch Uplink in Richtung 10 Gbit. Die sinnfällige Anbindung des Gebäude-Konzentrators an das Campus-Netzwerk ist bei mehr als 4 Access Switches dann 40 Gbit. Sind die Lasten erkennbar niedrig, kann natürlich eine Gebäude-Anbindung mit 10G oder 2-fach 10G LAG erfolgen, was die Kosten für Gebäude-Konzentrator und Core/Campus-Netzwerk deutlich senken wird. Bei entsprechender Gebäude-Größe (mehr als 250 bis 500 Endgeräte) macht es Sinn, das Gebäude mit Layer-3 vom Campus/Backbone-Netz abzukoppeln, in diesem Fall kommt im Beispiel-Szenario am Gebäude-Campus-Übergang ein Layer-3 Switch zum Einsatz.

Ein sternförmiges Data Center Design sieht im einfachsten Fall so aus wie in Abbildung 4 gezeigt. Aufgrund der vorherigen Überlegung, dass nicht-redundante RZ-Designs wenig sinnvoll sind, zeigt das Beispiel die vollredundante Anbindung der Server/Storage Access Switches an (mindestens) zwei Core Switches, die die Anbindung des RZ an den Campus realisieren. Unterstellen wir, dass moderne Server/Hosts mit 10 Gbit an die Server/Storage Access Switches (ToR) angeschaltet sind, so muss der Serverswitch Uplink mindestens 40 Gbit oder je nach Anzahl und Power der angeschalteten Hosts 100 Gbit erhalten.

Eine gemeinsame Ethernet-Anbindung von Server- und Storage-Komponenten ist nur dann möglich, wenn das SAN über FCoE oder iSCSI realisiert ist. Bei FCoE Einsatz zur Speicher-Anbindung müssen die Ethernet Switches dieses Verfahren unterstützen.

In Bild 4 ist deutlich erkennbar, dass der Data Center Core eine hohe Anzahl 40 Gbit oder 100 Gbit Ports benötigt, was für die Beschaffung entsprechend hohe Kosten generiert. Da die Serverseite vom Campus-Netz schon aus Sicherheits- und Fehlerabschottungs-Gründen mit Layer-3 vom Campus abgekoppelt sein sollte, zeigt auch das RZ-Designbeispiel Layer-3 Switches zur Data Center Anbindung an das Campus-Netzwerk.

Ein resultierendes Gesamt-Design zeigt Bild 5. Je nach Größe des Netzwerks hinsichtlich Server- und Gebäude-Anzahl werden zwei Core / Campus- Switches nicht mehr ausreichend sein. Die erste Maßnahme ist dann vielfach eine Aufteilung in RZ-Core und Campus-Core Switches, die wiederum mit angemessen hohen Datenraten miteinander verbunden werden müssen. Für die gezeigten Access und RZ-Beispiele kann hier sinnfälliger weise nur n-mal 40 Gbit oder 100 Gbit zum Einsatz kommen. Bei sehr großen Geländenetzwerken lässt sich eine weitere Konzentrator-Stufe einfügen, die im Regelfall dann die Überbuchung zwischen Gebäude-Summenlast und RZ erhöht. Mehrere Gebäude werden in Bereichs-Netzen (Areal-Netzen) gebündelt, die Areal-Netze werden über Core-Konzentratoren gebündelt. Ein Beispiel-Szenario mit einer Kaskadentiefe von 6 zeigt Bild 7. Für ein solches n-Tier Design ist natürlich eine entsprechende Geländeverkabelung erforderlich.

Höhere Verfügbarkeits-Anforderungen für einzelne oder alle Gebäude erfordern ein redundantes Design, bei dem zumindest jedes Gebäude vom Gebäude-Konzentrator aus an zwei Core / Campus Switches angeschaltet wird, um den RZ-Zugang sicher zu stellen, falls ein Campus / Core Switch ausfällt. Ob der Gebäude-Campus-Zugang mit zwei Gebäude-Konzentratoren ebenfalls vollredundant ausgelegt werden muss, ist im Einzelfall zu entscheiden. Typischerweise spielt hier die Gebäudegröße (hinsichtlich Anzahl angebundener Anschlüsse) sowie Wichtigkeit der dort betriebenen Anwendungen respektive angebundenen Anwender eine Rolle. Sofern die maximale Wiederherstellungszeit unter 1,5 bis 2 Stunden liegen soll, empfiehlt sich eine vollredundante Bestückung der Gebäude-Campus-Anbindung mit zwei Gebäude-Konzentratoren. Dieses vollredundante Stern-Design ist in Bild 6 gezeigt. Bei Betrachtung der Grafik wird sofort klar, dass dieses Design sowohl hohe Datenraten als auch hohe Verfügbarkeit bereitstellt, jedoch auch eine hohe Anzahl an 10/40/100Gbit Interfaces und LWL-Fasern erfordert. Ringförmige oder sternförmige Trassenführung im Gelände spielt hier eine untergeordnete Rolle, da sich auch über eine ringförmige Trasse sternförmige Patchungen vornehmen lassen.

In Bild 8 ist eine Bewertungsübersicht von Stern-Designs dargestellt.

Mehrfach-Stern: Fat Tree Design

Fat Tree Designs kommen typischerweise im Data Center zum Einsatz, da sie darauf optimiert sind, eine maximale Durchsatzleistung und minimale Kaskade zwischen zwei Endpunkten zu realisieren. Wie der Name schon sagt, ist das Design ein „in die Breite gezogener“ Mehrfach-Baum, der die Leistung eines einzelnen Baumes einfach vervielfältigt. Dies ist im Gelände sowohl aufgrund der benötigten Anzahl Interfaces als auch insbesondere verkabelungstechnisch meistens viel zu aufwändig sprich: unbezahlbar teuer. Während im Gelände bei sehr hoher Gebäudezahl mehr Konzentrator-Ebenen installiert werden (3-Tier oder 4-Tier), wird im RZ der Stern oder hier besser Baum in die Breite vervielfältigt.

Das Beispiel aus Bild 9 zeigt einen Fat Tree mit 4-fach Stern beziehungsweise vier Core Switches, die mit jeweils 160 Gbit Summenleistung eine beliebige Server-Server- oder Server-Storage-Verbindung mit einer Kaskade von zwei Hops ermöglichen. Ein zweiter Blick auf das Fat Tree Design zeigt, dass hier auf keinen Fall Spanning Tree zum Einsatz kommen kann, da dieser drei von vier Verbindungen für den Datenverkehr abschalten würde! Fat Tree Designs arbeiten auf der Basis von Multi-Chassis Link Aggregierung, Layer-2 Multipath Verfahren wie TRILL oder SPBM oder proprietäre Varianten der Layer-2 Multipath Verfahren.

Eine gemeinsame Ethernet-Anbindung von Server- und Speicher-Komponenten ist nur dann möglich, wenn das SAN über FCoE oder iSCSI realisiert ist. Bei FCoE Einsatz zur Speicher-Anbindung müssen die Ethernet Switches dieses Verfahren unterstützen.

In Bild 10 ist eine Bewertungsübersicht des Fat Tree Designs dargestellt.

Stern-Designs sind hinsichtlich Durchsatz-Leistung leicht kalkulierbar, kosten jedoch vergleichsweise viele Switch-Interfaces und erfordern vielfach den Einsatz modularer das heißt teurerer Konzentrator-Komponenten.

4. Design-Elemente: Ringförmige Designs

Ringförmige Designs haben traditionell einen Gegenpool zu Sterndesigns gebildet, denken wir an Token Ring, FDDI und auch Ringe aus Produktionsumgebungen und Metro-Netzen mit sehr niedrigen Schaltzeit-Anforderungen unter 50 ms wie EAPS, HiPER Ring oder MRP. Wie schon erwähnt, sind Ring-Designs mit Spanning Tree sehr nachteilig, da der Ring nicht lastverteilt arbeitet und sehr lange Wege entstehen (siehe Bild 11). Mit neuen Technologien wie Layer-2 Multipath, gegebenenfalls kombiniert mit Routing im Campus, werden Ring-Designs, unter anderem aus Kostengründen, jedoch wieder interessant, da diese Verfahren den Ring in jeder Richtung und zielbezogen lastverteilt nutzen (siehe Bild 12).

Im Access Bereich kann das Ring Design bei kleiner Switch-Anzahl den Gebäude-Konzentrator einsparen. Im Beispiel-Szenario aus Bild 13 lassen sich an jedem gebäudeinternen Switch Endgeräte anschalten. Die zusätzliche Querverbindung in Gebäude 4711 optimiert die Lastverteilung im Fehlerfall (Ausfall einer Campus-Verbindung oder eines Campus-Switches).

Hierfür sind jedoch Access Switches erforderlich, die mehr als zwei 10 Gbit Interfaces bereitstellen können (zum Beispiel vier fixe 10G Schnittstellen oder ein Uplink-Modul mit mehr als zwei 10G Schnittstellen. Soweit das Gebäude als einzelner Ring implementiert ist, macht es keinen Sinn, die Campus-Verbindung mit mehr als 10 Gbit zu bestücken, da ja die Ringleistung nicht mehr als 10 Gbit erbringt.

Soll der Ring innerhalb des Gebäudes abgeschlossen werden oder sollen mehrere Ringe im Gebäude implementiert werden, was sich bei einer größeren Anzahl Switches anbietet, können am Gebäude-Campus-Übergang nichtmodulare Layer-3 Switches zum Einsatz kommen, die Layer-2 Multipath zum Campus hin terminieren. Werden mehrere Ringe implementiert, kann die Campus-Anbindung bei entsprechendem Leistungsbedarf mit 40 Gbit bestückt werden – hier ist wiederum ein nichtmodularer Switch mit entsprechenden Schnittstellen-Möglichkeiten (mehrere 10G und mindestens eine 40G Schnittstelle) erforderlich.

Durch die ringförmige Verteilung der Gebäude-Campus-Anbindung auf mehrere Switches anstelle zweier zentraler Core Switches, lassen sich statt großer modularer Switches geeignete nichtmodulare Komponenten einsetzen, wobei jeder Campus-Switch mehrere Gebäude über 10 Gbit anbindet und der Campus-Ring mit n x 10G oder n x 40G ausgelegt ist, je nach Möglichkeit der eingesetzten Switches. Sofern das Gelände eine Ringtrasse für die Verkabelung hat, ist der Ring auch hinsichtlich Bedarf an LWL-Fasern optimal implementierbar.

Auch im Rechenzentrum lassen sich mit Layer-2 Multipath Verfahren Sternstrukturen durch Ringe ersetzen, was wiederum den Einsatz teurer modularer Konzentrator-Switches einsparen kann. Das Beispiel aus Bild 14 zeigt, wie durch eine Ring-Schaltung von Top-of-Rack (ToR) Switches mit 1fach 100Gbit die End-of-Row (EoR) Konzentrator-Switches vermieden werden. Eine Anbindung der ToR-Ringschaltung an den Campus Core ließe sich realisieren, indem die Core Switches einfach in den Ring eingefügt werden. Dies bedeutet jedoch, dass einige aktive Wege auch die Core Switches für Server-Server Verkehr mit nutzen, sofern diese nicht mittels hoher Kostensetzung „unbrauchbar“ gemacht werden. Letzteres führt jedoch für die Nachbar-Switches der Cores wieder zu recht ungünstigen Wegen. Um beides: ungünstige Wege und Belastung der Cores mit Server-Server Verkehrslasten zu vermeiden, wird der Ring zwischen Server Access Switches geschlossen, und im Regelfall zwei, bei höherem Leistungsbedarf auch mehr Server Access Switches erhalten eine separate Anbindung an die Campus Core Switches, wie Bild 16 zeigt.

Da 40G zur Zeit in mehr Produkten verfügbar ist als 100G, zeigt das nächste Design-Beispiel ein 40 Gbit Design: In Bild 15 sind mehrere Server Access Switches mit einem 40G oder mehrfach 40G Ring verbunden. Solche Ringe können mit entsprechenden LWL-Interfaces auch über zwei Rechenzentren an verschiedenen Campus-Standorten verteilt werden. Je nach Routing-Bedarf kommen hier nichtmodulare Layer-2 oder Layer-3 Switches zum Einsatz. Eine Übersichtsgrafik mit Ring-Design für RZ und Campus ist in Bild 16 dargestellt.

In Bild 17 ist eine Bewertungsübersicht des Fat Tree Designs dargestellt.

Ring-Designs sind hinsichtlich der definierten Durchsatz-Leistung zwischen jeweils zwei Ring-Elementen schwerer kalkulierbar, kosten jedoch vergleichsweise wenige Switch-Interfaces und ermöglichen den Einsatz nichtmodularer Konzentrator-Komponenten. Sie stellen daher eine kostengünstige Alternative zum Baum-/Stern-Design dar.

5. Design-Elemente: Masche, Hybrid-Design
Wie der Name Hybrid-Design schon nahelegt, sind vermaschte Netzdesigns eine im Prinzip beliebige Kombination von Quer-Verbindungen, die je nach Leistungsbedarf und Verkabelungs-Möglichkeiten – hier gibt es hauptsächlich im Campus ja vielfältige Einschränkungen hinsichtlich Trassenführung, Fasernzahl und OM Fasernklasse – völlig flexibel konfiguriert werden können. In diesem Sinne lassen sich auch Fat Tree Designs zu den Maschen-Designs rechnen.

Genau wie Ring-Designs sind vermaschte Designs nur beim Einsatz von Multipath-Verfahren sinnvoll nutzbar. Ein klassisches Multipath Verfahren ist beispielsweise OSPF ECMP bei gerouteten Verbindungen, für Layer-2 Bereiche stehen SPBM und TRILL als Layer-2 Multipath Standards zur Verfügung.

Besonders interessant sind vollvermaschte Designs (Matrix-Designs), da sie die höchste Leistung und höchste Blockierungsfreiheit ermöglichen. Trotzdem erfordern sie nicht zwingend den Einsatz teurer modularer Komponenten. Bild 18 zeigt eine vollvermaschte Konfiguration mit sechs nichtmodularen Serverswitches, die jeweils fünf Verbindungen zu den jeweils fünf anderen Serverswitches haben (das konkrete Produkt unterstützt sechs Uplinks, da ja auch noch die Core- / Campus-Verbindung erforderlich ist. Bei 40 Gbit Uplinks sind dies in Summe 200 Gbit fdx Querverbindungs-Leistung. Die Überbuchung ist durch die Anzahl angebundener Server bestimmt: Da die Server vorzugsweise redundant an jeweils zwei Serverswitches angeschaltet werden, rechnen wir mit einer Uplink-Leistung von 400 Gbit (zwei Switches mit jeweils 5-fach 40 Gbit). Unterstellen wir, dass jeder physische Server (Host) mit 2-fach 10 Gbit angeschaltet ist, so können 20 Server acitive / active oder 40 Server active / passive angeschaltet werden. Auch bei Ausnutzung von 48 Serverports (das ist die typische Switchbestückung) liegt mit Faktor 1,2 eine sehr moderate Überbuchung vor, die sich in den allermeisten Fällen problemlos verhalten wird.

Auch Fat Trees sind ein vermaschtes Netzdesign, das insbesondere blockierungsfreie 2-Tier Konnektivität zwischen allen angeschlossenen Endsystemen (im Regelfall Server) leistet. Bei einer hohen Anzahl angeschlossener Serverswitches müssen die Aggregierungs-Switches jedoch vielfach wegen der erforderlichen hohen Portkonzentration modulare Komponenten sein (siehe auch Bild 19). In diesem Fall ist der Fat Tree die teurere Variante im Vergleich zur nichtmodularen Vollvermaschung, die zuvor beschrieben wurde.

Da eine Vollvermaschung eine vergleichsweise hohe Anzahl physischer Querverbindungen erfordert, sind in Gebäude- und Campus-Bereichen die Verkabelungs-Voraussetzungen meistens nicht gegeben, insbesondere im Campusbereich wären zudem aufgrund der hohen Entfernungen die 40 Gbit Verbindungen aufgrund der erforderlichen Single Mode Interfaces vergleichsweise teuer. Ein Maschenkonzept im Campus ist eher als Ring-Stern mit einer sternförmigen Anschaltung der Gebäude an den Campus Core / RZ-Zugang sowie Ringschaltung der Gebäude unterneinander für Peer-Verkehr (Voice, Video, UC) denkbar. Natürlich können einzelne Verbindungen je nach Leistungsbedarf gedoppelt oder in der Datenrate erhöht werden (zum Beispiel von 40 Gbit auf 100 Gbit). Ein Gesamt-Netzwerk mit Kombination von Vollvermaschung im Rechenzentrum und Bedarfs-Vermaschung im Campus zeigt Bild 20. In diesem Beispiel wurden die Gebäude 011 und 013 aufgrund eines erhöhten Leistungsbedarfs mit einer doppelt so hohen Datenrate an den Campus / Core angeschaltet wie die anderen Gebäude. Die Gebäude-Anbindung an den Campus / Core ist mit 320 Gbit nicht überbucht, da der Core zum Rechenzentrum eine Leistung von 4-fach 100 Gbit hat. Eine Anschaltung von 1-fach 100 Mbit beider Cores würde zu einer Überbuchung von Faktor 1,6 führen, was sicherlich in vielen Fällen ebenfalls problemlos funktioniert. Bei einer einheitlichen Ausstattung mit 40 Gbit und folglich Core-Anschaltung an das Rechenzentrum mit 2-fach 40 Gbit ergibt sich eine Überbuchung von Faktor 2,0; auch hier sind im Regelfall keine Probleme zu erwarten. Die einheitliche Ausstattung mit 40 Gbit kann mangels Verfügbarkeit von 100 Gbit in einigen Produktlinien erforderlich oder aufgrund der Preispolitik für 100 Gbit sinnvoll sein.

In Bild 22 ist eine Bewertungsübersicht für vermaschte Designs dargestellt.

Als Sparvariante lassen sich in hybriden Design-Konzepten Maschen- und Ring-Konfigurationen sinnvoll miteinander kombinieren, insbesondere dann, wenn die Server-Server Verkehrslast erheblich höher ist als die Client-Server Verkehrslast. Ein entsprechendes Beispiel-Design zeigt Bild 21.

6. Design-Regeln, generische Planung

Für ein gut funktionierendes Ende-zu-Ende Design ist insbesondere die Überbuchungs-Situation zu betrachten. Eine erste Daumenregel ist die 1:1 Regel: Die Summenleistung der RZ-Anbindung an das Campus-Netzwerk sollte etwa der Summendatenrate der Gebäude-Campus-Zugänge entsprechen: Bei einer Ausgangslage von 95% Client-Server Verkehrslast im Campus wird die Leistung des Campusnetzwerks im Wesentlichen nicht höher als die Server-Zugangsleistung sein, egal wie hochkarätig Sie das Campus Netzwerk auslegen!

Bei großen Netzwerken ist diese 1:1 Regel aus Kostengründen oft nicht mehr haltbar. Je größer die Gebäudezahl ist, desto höher kann die Überbuchung der Gebäude-Summenrate zum RZ-Zugang gewählt werden, da empirisch und unter Berücksichtigung der Warteschlangen-Theorie nicht davon auszugehen ist, dass alle Gebäude gleichzeitig einen Lastpeak generieren. Je größer die Serverzahl ist, desto höher lässt sich die Überbuchung des Server-Access Bereichs zum Campus Netzwerk planen, da sich typischerweise auch nicht alle Server gleichzeitig in einer Peaklast-Situation zu den Clients befinden. Die Netzwerk-Infrastruktur innerhalb des Data Centers ist so auszulegen, dass die Server-Server Verkehrslasten parallel oder zusätzlich zu den Client-Server Verkehrslasten bedienbar sind.

Access Bereich
Im Access Bereich etabliert sich 1 Gbit am Endgerät, 1 Gbit am WLAN AP (zukünftig mit 802.11ac 10 Gbit) kombiniert mit 10 Gbit Uplinks (siehe auch Bild 23). Als Sparvariante ist 1 Gbit am Endgerät / WLAN AP mit n-fach 1 Gbit Uplink an den Gebäude-Konzentrator oder Campus denkbar. Nach wie vor ist eine gute Einsetzbarkeit von Stack-Konzepten gegeben, bei Bedarf mit Link Aggregierung oder Ringschaltung. Im Access Bereich ist eine Überbuchung von 15:1 bis 30:1 in den meisten Fällen gut machbar, natürlich sollten die Uplinks entsprechend auf zu hohe Auslastung überwacht werden (mehr als 80% Auslastung legt eine Hochrüstung nah, konservative Netzbetreiber können die Schwelle auch niedriger setzen).

Wer Echtzeit-Anwendungen (VoIP, Video, UC) nutzen will, sollte sich an folgende Eckwerte halten:

  • Voice / Video Delay: One Way Ende-zu-Ende 2 ms bis 100ms
  • Jitter: One Way Ende-zu-Ende 1 ms
  • Verlustrate: nahezu 0%
  • PoE: die typische Leistung von kostengünstigen Switches ist nach wie vor 7,5W bis 15W pro Port, auch wenn einzelne Ports bis 30W einspeisen können

Campus Bereich
Als Aggregation / Distribution Switches im Gebäude kommen 10 Gbit Konzentratoren zum Einsatz. Die Gebäude-Anbindung wird auf n x 10 Gbit oder 40 Gbit migriert, wie in Bild 24 gezeigt. Überbuchungs-Faktoren von 2:1 bis 4:1 sind im Regelfall gut verkraftbar. Für Echtzeit-Anwendungen gelten wiederum die zuvor genannten Dienstgüte-Anforderungen hinsichtlich Delay, Jitter und Verlustrate.

Data Center
Die typische Netzwerk-Anbindung eines Host / Servers wird mit 1-fach bis n-fach 10 Gbit am Server geplant, somit lassen sich jeder VM n x 1 Gbit zuordnen. Auch hier gibt es für ältere Modelle noch die Sparvariante: n-fach 1 Gbit am Server, n x 1 Gbit Uplink am Server-Switch. Typischerweise kommen aber inzwischen n-fach 10 Gbit Uplinks oder 40 Gbit Uplinks am Server Access Switch zum Einsatz. Auch der einfache 10 Gbit Uplink am Server Access Switch ist inzwischen als Sparvariante zu bezeichnen. Überbuchungen von 2:1 bis 6:1 sind in den meisten Fällen gut realisierbar. Auslastungs-Überwachung der Uplinks schützt auch hier vor bösen Überraschungen. Eine Übersicht zeigt Bild 25.

Als kritisches Hochleistungs- und Anwendungs-Beispiel geben wir hier die Dienstgüte-Anforderungen für Cluster-Computing, Parallel Processing (MPP, Hadoop) an; der geneigte Leser wird feststellen, sie sind noch restriktiver als die Anforderungen für Echtzeit-Anwendungen:

  • Delay 10 – 20 µs bis wenige ms
  • Jitter: wenige µs
  • Verlustrate: nahezu 0%

Netzwerk Core
Das klassische sternförmige Design erfordert Konzentratoren mit sehr hoher Portdichte für 10 Gbit und hoher Portdichte für 40 Gbit (siehe auch Bild 26). 1 Gbit Ports am Core kommen nur noch marginal zum Einsatz. Die Core-Querverbindung steigt auf n x 40 Gbit oder n x 100 Gbit; hierbei wären 100 Gbit in vielen Fällen sinnvoll, scheitern aber gegebenenfalls an der Verfügbarkeit oder am Preis. Insbesondere bei Einsatz von mehr als 2 Core Switches ist auf eine entsprechend hohe Kapazität der Querverbindung aller Core Switches zu achten! Wie sich anstelle des Stern-Designs mit Ring-Konfigurationen Kosten sparen lassen, wurde in den vorhergehenden Kapiteln dargelegt.

Grundsätzlich gilt: Bei jedem überbuchten Design sollte der Netzbetreiber an den Uplinks Lastschwellwerte setzen, bei deren Erreichen ein Alarm getriggert wird. Dies ist in jedem etablierten Switch über RMON möglich.

Abschließend sei nochmals eine Übersicht gegeben, welche Design-Elemente sich in welchen Netzwerk-Bereichen sinnvoll einsetzen lassen (siehe Bild 27).

Planung der RZ und Core Komponenten
Je nach gewünschtem Überbuchungsfaktor lässt sich die Auslegung beziehungsweise Anforderung an die Core Komponenten rechnerisch planen. Im umgekehrten Ansatz lässt sich bei Limitierungen der Portkonzentration bestimmter Hersteller-Produkte die resultierende Überbuchung oder bei einer festgesetzten akzeptierten Überbuchungsrate die Anzahl anschließbarer Server berechnen. Nachfolgend werden anhand entsprechender Planungs-Formeln Beispiele für eine 40 Gbit Planung aufgezeigt. Betrachten Sie hierfür Bild 28, so haben die Abkürzungen folgende Bedeutung:

  • P = Anzahl Serverports (10G)
  • U = Anzahl 40G Ports (4fach 10 G LAGs) je DC Core Switch
  • f = Überbuchungsrate
  • C = Anzahl DC Core Switches
  • A = Anzahl DC Access Switches
  • Cam = Anzahl 40G Verbindungen zum Campus
  • CQ = Anzahl 40G Verbindungen zwischen je zwei DC Core Switches
  • PCA = Anzahl 40G Verbindungen je Core Switch zum DC Access Layer
  • PAC = Anzahl 40G Verbindungen je Access Layer Switch zum DC Core
  • AQ = Anzahl 40G Verbindungen zwischen je zwei DC Access Switches (ToR)

Für die Core Switches ergibt sich hinsichtlich der Anzahl erforderlicher 40 Gbit Ports folgende Formel:

U = (P / 4Cf) + Cam + CQ

Ohne Überbuchung (f=1) bei 4 Core Switches, 16-fach 40 Gbit Anbindung je Core an den Campus und 16-fach Core Querverbindung ergibt sich beispielsweise bei 1536 Servern mit je 2 aktiven Ports als 40 Gbit Portkonzentration je Core:

U = (3072/(4*4*1)) + 16 + 16 = 224

Da eine solche Planung viele Hersteller, Anbieter ebenso wie unternehmensinterne Budgetverantwortliche zum Hyperventilieren bringen würde, nachfolgend ein moderateres Beispiel: Mit Überbuchungsfaktor 3:1 (f=3), mit 4 Core Switches, 16-fach 40 Gbit Anbindung je Core an den Campus ohne Core Querverbindung ergibt sich bei 1536 Servern mit je 2 aktiven Ports eine erheblich friedlichere 40 Gbit Portkonzentration je Core:

U = (3072/(4*4*3)) + 16 + 0 = 80

Die Formel für die anschließbaren Serverports ergibt sich zu:

P = 4 * C * f * PCA

Planen wir in Anlehnung an das obige Beispiel 4 Core Switches mit Überbuchungsfaktor 3:1 und jeweils acht Modulen mit 8 Ports 40 Gbit, so resultieren 3072 anschließbare Serverports, respektive 1536 Server mit jeweils 2 aktiven Ports:

P = (4*4*3) * (8*8) = 3072

Migrationsschritte
Soll eine Hochrüstung des Gesamtnetzwerks erfolgen, so macht es Sinn, zuerst den leistungsfähigeren Backbone zu in-stallieren, um im Verbindungsnetzwerk zwischen Clients und Servern jeden Engpass zu vermeiden, da ein Leistungs-Engpass im Campus vergleichsweise hohe Seiteneffekte zur Folge haben kann.

Im zweiten Schritt sollte die Data Center und Server-Hochrüstung erfolgen, da die Server im Fall von Client-Server Verkehrslasten von den Clients getriggert sind und somit auch bei eigener Ausstattung mit hohen Datenraten keine Client-Überlastung erzeugen werden. Zudem stellt aktuell oft das RZ-Netzwerk den dringenderen Engpass dar als das Client-Acces-Netzwerk.

Die Hochrüstung des Client-Netzwerks bietet sich im dritten und letzten Schritt an, da bei Vertauschung von Schritt zwei und drei die Clients die Server überfordern und so Degradierungs-Phänomene hervorrufen könnten.

Überalterte Komponenten, die sich dem End-of-Service Stadium nähern, sind grundsätzlich in allen Bereichen ein zwingender Anlass für sehr zügiges Handeln (!).

7. Einbindung virtueller Netzkomponenten

Im Rahmen der Evolution von Virtualisierung lassen sich aktuell auf Hostsystemen nicht nur virtuelle Switches (vSwitches, vSw) sondern auch virtuelle Router (vRouter, vR), virtuelle Load Balancer (vLB) oder virtuelle Firewalls (vFW) installieren. Sichtbar werden solche Switches über Management-Anpassungen bzw. Zusatzmodule der Netzwerk-Hersteller für die etablierten Virtualisierungs-Umgebungen, hauptsächlich VMware und Hypervisor.

Nach außen sichtbar und mit Anschluss an einen physischen Netzwerk-Switch sind nur die physischen NICs (phyNIC). Diesen werden gegebenenfalls – oder auch nicht – Ports der vSwitches zugeordnet, über die sie nach draußen kommunizieren können. Auf die host-interne Kommunikationsfähigkeit hat der physische Netzwerk-Access Switch im Regelfall keine Einflussmöglichkeit. Der vSwitch kann ähnlich wie ein physikalischer Switch konfiguriert sein und nach innen über vNICs die VMs anbinden, nach außen über zugeordnete phyNICs mit anderen Systemen kommunizieren.

Loop-Unterbindung erfolgt jedoch nicht mit Spanning Tree, sondern der vSwitch weiß per interner Software, welche MAC Adresse wo angebunden ist und wie Loops vermieden werden (siehe hierzu auch IEEE Standard 802.1bg). Link Aggregierung, Teaming oder Failover können jedoch wie bei phyNICs konfiguriert werden.

Ein Host-Administrator kann mit den hostinternen Konfigurationsmöglichkeiten soweit gehen, dass er einen hostinternen virtuellen Switch, an den alle VMs angeschaltet sind, mittels virtuellem Firewall weitestgehend von der Außenkommunikation abschirmt und die Konnektivität nach außen durch einen dem Firewall nachgeschalteten zweiten vSwitch realisiert wird wie in Bild 29 dargestellt.

Ähnliches gilt für die Konfiguration virtueller Router. Alle vSwitches innerhalb eines Hosts können gegenüber der physischen Netzwerk-Welt komplett durch virtuelle Router abgekoppelt werden, so dass alle Layer-2 Prozesse innerhalb des Hostsystems terminiert werden. Zwischen den vSwitches und vRoutern lassen sich vom Administrator analog zu physischen Netzkomponenten im Prinzip beliebige Verbindungen konfigurieren. Ein Beispiel zeigt Bild 30. Die Technik virtualisierter Load Balancer, Router und Firewalls ist noch jung, daher ist hinsichtlich der möglichen Funktionalität von Einschränkungen und gegebenenfalls Kinderkrankheiten auszugehen. Tatsächlich lassen sich aber mit virtuellen Netzkomponenten innerhalb eines Hosts komplette virtuelle Subnetzwerke bilden, auf die der Netzbetreiber vorab keinen oder nur bedingten Zugriff hat. Dieser erfolgt, soweit er gegeben ist, immer über spezielle Managementmodule oder Produkte zur Integration von physischem Netzwerk und Virtualisierungs-Umgebung, die meistens der Netzwerk-Hersteller entwickelt und anbietet, da sich die Virtualisierungs-Hersteller wenig um die Integration ins physische Netzwerk kümmern.

Im Prinzip gelten für virtuelle Netzkomponenten die gleichen Design-Prinzipien wie für physiche Netzkomponenten, insbesondere hinsichtlich Überbuchung und Failover.

8. Wo kommt welches Failover – Verfahren zum Einsatz?

Im Rahmen des Netzwerk-Designs ist in jedem Fall auch die Frage zu beantworten, wo welche automatischen Schaltverfahren zum Einsatz kommen sollen, soweit keine individuelle Netzwerk-steuerung mit SDN angestrebt ist – was jedoch in diesem praxis-orientierten Beitrag mangels breiter Verfügbarkeit und Erfahrungswerte außer Acht gelassen wird.
Zur Auswahl stehen aktuell:

  • Link Aggregierung
  • Multi-Chassis Link Aggregierung
  • Layer-2 Multipath (SPBM, TRILL)
  • Spanning Tree
  • FC FSPF (standardisiert im SAN / FC Umfeld)
  • Proprietäre Fabric Verfahren (FabricPath, VCS, QFabric und andere)
  • OSPF Routing
  • MPLS

FSPF ist standardisiert auf den Fibre Channel SAN-Bereich beschränkt, proprietäre Verfahren haben ihre Probleme im Trouble Shooting und im Migrationsfall, Spanning Tree ist tatsächlich in die Jahre gekommen und auch in der RST Variante inzwischen vielfach nicht mehr sehr geliebt, wenn auch wegen ihrer Bekanntheit und Etabliertheit immer noch im Einsatz.

Kümmern wir uns im Nachgang um die moderneren und zukünftig anstehenden Layer-2 Verfahren wie Link Aggregierung, Multi-Chassis Link Aggregierung, Layer-2 Multipath sowie OSPF und MPLS. Aufgrund der Einschränkung auf zwei parallel verbundene Systeme hat Link Aggregierung im Data Center stark an Bedeutung verloren. Hier kommen überwiegend lastverteilte Verfahren zum Einsatz, die Redundanz über mehrere Systeme ermöglichen. Im Campus und Gebäudebereich sind LAGs etabliert und gut einsetzbar.

Multi-Chassis Link Aggregierung ist unter der Bezeichnung DRNI (Distributed Resilient Network Interconnect, IEEE 802.1AX Maintenance Release) die Weiterentwicklung der Link Aggregierung, auch mit proprietären Vorläufern wie VSS, MEC, Bonding, IRF, SMLT und anderen. Hier gibt es wenige Einschränkungen in der Skalierbarkeit, das Verfahren ist im Prinzig beliebig kaskadierbar und in allen Layer-2 Bereichen gleichermaßen einsetzbar, wie seinerzeit der Spanning Tree.

Layer-2 Multipath ist grundsätzlich ein Layer-2 Verfahren, leistet also nicht die Verbindung verschiedener IP Subnetze / verschiedener VLANs. Da aber die Konfigurationsflexibilität sehr hoch und die Lastverteilung sehr gut ist, kann der Netzbetreiber zum Beispiel darüber nachdenken, das Campus Netzwerk anstelle von lauter OSPF Transit Links zu einem gemeinsamen Backbone-Subnetz mit Layer-2 Multipath zu konfigurieren und somit viele Transit-Netze einsparen. Daher gibt es für Layer-2 Multipath wie auch MC-LAG in allen Netzbereichen sinnvolle Einsatzszenarien. Zudem erlaubt Layer-2 Multipath die transparente und lastverteilte Verbindung gleicher VLANs und überlappender VLAN-IDs verschiedener Mandanten über einen Backbone hinweg. In diesem Sinn kann Layer-2 Multipath im Campus Backbone ein Ersatz von MPLS werden, das sich ja gerade zur Handhabung vieler und auch überlappender VLANs in den letzten Jahren in großen Campus-Netzwerken etabliert hat.

OSPF als Layer-3 Verfahren kommt innerhalb von Gebäuden überschaubarer Größe eher nicht zum Einsatz, ist aber im Gebäude-Campus-Übergang und für den Campus sehr gut geeignet. Da im RZ für HA-Konzepte vielfach Layer-2 Verbindungen erforderlich sind, ist OSPF als Layer-3 Verfahren nur bedingt und übergreifend zur Kopplung verschiedener Subnetze einsetzbar, und auch nur, wenn im RZ-Bereich eine einfache geroutete Kopplung als zulässig betrachtet wird und keine höherwertigen Schutzkonzepte implementiert werden.

Grundsätzlich gilt: Je einheitlicher die eingesetzten Verfahren in Accees, Campus und Data Center Bereich sind, umso übersichtlicher gestaltet sich der Netzbetrieb.

Bild 31 zeigt eine Übersicht über Redundanz- und Lastverteilungs-Verfahren und ihre jeweiligen Einsatzbereiche.

zugeordnete Kategorien: Archiv, Klassiker
zugeordnete Tags: , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.