Broadcom BCM 56640 1/10/40/100 GbE-Switch-ASIC: das Schweizer Taschenmesser für die VM-Kommunikation

Kommentieren Drucken
Teil 10 von 11 aus der Serie "Chip, Chip, Hurra"

Speicherbasierende Switch-ASICs sind das technische Rückgrat der nächsten Netzgenerationen. Abgesehen vom reinen Ethernet-Durchsatz entwickeln sie sich hinsichtlich der höherwertigen Funktionen immer weiter. Der BCM 56640 ist hierfür ein hervorragendes Beispiel. Neben vielfältigen in einem RZ-Umfeld sinnvollen und mächtigen Funktionen unterstützt er auch die Bildung von Overlay-Netzen in Hardware. Er hat so viele spannende Funktionen, dass wir zwei Folgen für ihn benötigen.

Der BCM 56640 ist Broadcoms mittlerweile achte Generation des Strata XGS ® Multilayer Ethernet-Switches. Das Faszinierende an diesem Chip ist, dass er nicht nur für Anwendungen im RZ, sondern auch für Campus-Netze und Service-Provider-Funktionen eingesetzt werden kann. In vielen Artikeln habe ich immer wieder darauf hingewiesen, dass Provider-Technik und die Technik, die in privaten Netzen von Unternehmen und Organisationen verwendet wird, zusammen wachsen werden. Dieser Chip ist ein weiterer Beleg dafür.

Seine Funktionsvielfalt erlaubt den Einsatz für

  • Carrier Ethernet Aggregation
  • Aggregation in Unternehmensnetzen und Rechenzentren
  • 10/40/100 GbE Line Card für Metro- und RZ-Switches

Die Festlegungen von IEEE 802.3ba im Standard für 40 und 100 GbE definieren das sog. Skalierbare Ethernet. Basis dieser Skalierbarkeit ist die Aufspaltung höherer Datenraten, die von CMOS-Logik gar nicht verarbeitet werden können, in sog. Lanes geringerer Datenrate, z.B. die Zerlegung von 10 GbE in 4 X 2,5 GbE oder die von 40 GbE in 16 X 2,5 GbE. Die einzelnen Lanes werden nach der Zerlegung, die direkt in den Schnittstellen-Ports geschieht, einzeln parallel verarbeitet und nach Beendigung der Verarbeitung wieder synchronisiert und zu einem geeigneten Ausgangssignal zusammengefasst.

Genau hier kann man Moore´s Law nutzen. Alle ca. 18 Monate verdoppelt sich die Anzahl der für einen integrierten Schaltkreis auf einer Fläche zur Verfügung stehenden Transistoren. Genau wie dies bei Prozessoren zu mehr Cores pro Prozessor und bei Halbleiter-Speichern zu einer Verdichtung des Speicherplatzes führt, bringt es Moore´s Law mit sich, dass in einem speicherbasierten Switch-ASIC mit der Zeit immer mehr Lanes parallel bearbeitet werden können. Gleichzeitig steigt natürlich auch die verfügbare Prozessor-Kapazität, die man für Bearbeitung höherwertiger Funktionen benötigt.

Der BCM 56640 nutzt dies aus und kann daher als 1/10/40/100 GbE-Switch mit ausgedehnten L2/L3- und ACL-Funktionen basierend auf einem einzigen TCAM aufweisen.

Zusätzlich besitzt der Chip schon selbst eine große Forwarding-Tabelle, die durch externen Speicher erweitert werden kann.

Folgende Funktionen werden neben dem blockierungsfreien L2-Switching mit Line Rate Performance (auch 100 G!) angeboten:

  • vorwiegend für den Einsatz in Carrier-Ethernet-Umgebungen und ambitionierten Campus-Netzen:
    • MPLS/VPLS, MPLS-TP
    • PBB/PBB-TE
    • VLAN-Translation nach TR-101/156
    • MEF-Compliance in Schwellwerten und Zählern
    • Lineares und Ring-Protection-Switching
    • OAM-Support für IEEE 802.1ag CFM, Y.1731 und BFD
    • L1 Clock Recovery
    • L2 Netzwerk Time Synchronization und Clock Recovery
    • Erweiterte IPv6 LPM-Unterstützung
    • hierarchisches QoS
  • vorwiegend für den Einsatz in RZ-Netzen:
    • Data Center Bridging DCB mit
      • IEEE 802.1 Qau (QCN)
      • IEEE 802.1 Qaz (ETS)
      • IEEE 802.1 Qbb (PFC)
    • VM-Switching mit Smart-NV
    • TRILL
    • AppAware ® Flow Recognition und QoS
    • Dynamische Lastbalancierung
    • Multistage Content Aware ® Engine
    • Network HiGig ®-Support
    • Broadcom Smart Buffer Technologie
  • vorwiegend für den Einsatz in WLAN-Controllern für Multi-Gigabit-WLANs
    • CAPWAP Tunnel Support
    • Energy Efficient Ethernet EEE

Der Chip ist für den Einsatz im Access Bereich gedacht, also in ToR-Switches, Blade Switches oder EoR-Switches in der Leaf-Ebene eines Fat Trees. Von daher benötigt er viele Funktionen, von denen wir die interessantesten noch besprechen werden, aber nicht so viele Ports und auch nicht so einen hohen Gesamt-Durchsatz wie ein Switch auf der Spine-Ebene. Es sind Ende 2012 unterschiedliche Modelle mit 24 – 48 Ports, unterschiedlichen Zuordnungen von Datenraten zu Ports und 1/10/40-Datenraten lieferbar, die einen aggregaten Gesamt-Durchsatz von rund 500 Gbit/s. haben. In 2013 kommen Modelle, die auch die 100 G-Datenrate beinhalten und daher auch einen Durchsatz im Bereich 1-2 Tbit/s.

Von den vielen Eigenschaften sind zwei besonders interessant und auch auf der Hardware-Ebene recht neuartig: Flow-Bewusstsein bzw. Content-Awareness sowie Hardware-Unterstützung für VM-Switching und Overlay-Netze.

Content-Awareness bzw. Flow-Bewusstsein
Eine wichtige treibende Kraft für die Notwendigkeit von mehr Intelligenz in einem Netz ist Content-Awareness. Der digitale Datenverkehr repräsentiert nicht nur Daten, sondern auch Sprache, Video, Messages, UC und andere Services. Um diese angemessen bedienen zu können, benötigt das Netz Filter-Mechanismen, differenzierte Priorisierung und QoS, damit öffentliche und private Dienstleister (in Unternehmensnetzen) die in Aussicht gestellten SLAs spezifisch für jeden Dienst einhalten können. Zusätzlich müssen die intelligenten Netze wissen, welche Art von Dienst vorliegt, also z.B. Email, Web-Services oder Multimedia-Services. Das ist nötig, damit Load Balancer auf dem Application Level oder spezielle Dienst-spezifische Sicherheitsmaßnahmen überhaupt arbeiten können.

In den Teilen 6,7 und 8 hatten wir diese Problematik ja hinsichtlich der Flow Prozessoren betrachtet. Gleichzeitig wurde darauf hingewiesen, dass es auch andere technische Möglichkeiten gibt, das zu lösen. Der BCM 56640 ist hierfür ein hervorragendes Beispiel.

Der BCM 56640 erledigt alle die in Teil 6 beschriebenen Aufgaben für L2 – L4 komplett in Hardware mit Hilfe gegenüber einfachen Switches erheblich erweiterten Tabellen mit speziell entwickelten Algorithmen, die auf den integrierten Kontroll-Prozessoren implementiert wurden.

Anforderungen an eine Hardware-Unterstützung von Virtualisierungskonzepten
Die Nutzung von Virtualisierungskonzepten in Unternehmen zieht Anforderungen hinsichtlich der optimalen Server-Auslastung und der automatischen dynamischen Provisionierung nach sich, um sich den ständig ändernden Geschäfts-Anforderungen
Erfolgreich stellen zu können. Dabei entstehen neue Anforderungen an die Switching-Infrastruktur. Die gleiche virtualisierte Switching- und Server-Infrastruktur muss z.B. nicht nur leistungsintensive Anwendungen (DB, Business Logic Server), sondern auch solche, die keine derartigen Ansprüche haben, gleichermaßen sinnvoll unterstützen. Das betrifft die Auslegung hinsichtlich der Netzwerk-Leistung aber auch die VM-Migration, um eine optimale Rack-Performance und – Auslastung zu erzielen.

Im Gegensatz zu nativen Servern bringt die Nutzung von Virtualisierungstechniken erst einmal eine „Bestrafung“ im Rahmen möglicher Leistungs-Engpässe bei der Kommunikation mit sich. Das liegt zum einen an der Notwendigkeit der Verwendung virtueller Software-Switches und zum anderen daran, dass prinzipiell auf jedem Weg der Protokollstack zweimal durchlaufen werden muss, nämlich einmal im Hypervisor und dann in der VM. Neben speziellen Standard-basierten Alternativen wie SR-IOV oder VEB/VEPA gibt es eine Reihe herstellerspezifischer Lösungen, um die Leistungseinbußen zu minimieren und die Skalierbarkeit der virtualisierten Anwendungen zu verbessern. Leider gehen dabei manchmal ausgerechnet wünschenswerte Funktionen (wie z.B. vMotion bei der Nutzung von Direct Path) verloren. Die Implikationen derartiger Technologien auf die Netzwerk-Switches können als „VM-Switching“ zusammengefasst werden.

Smart-NV von Broadcom besteht aus einer Anzahl von einzelnen Funktionsbereichen, ist aber letztlich eine komplette Hardware-Unterstützung des VM-Switchings.

VM-Switching stellt folgende Anforderungen an die Switches der Access-Ebene, wie ToR-Switches, Blade-Switches oder End-of-Row-Switches:

  • Unterstützung einer großen Anzahl von Virtual Switch Ports (VSPs), die die VMs, die auf einem Server laufen, der an den Access Switch angeschlossen ist, direkt bedienen. Nehmen wir einmal an, dass in einem Rack 40 Server montiert sind, auf denen jeweils 20 VMs laufen können. Ein ToR-Switch muss in diesem Falle ungefähr 1k VSPs, ein EoR-Switch sogar 8k VSPs unterstützen können, wenn z.B. 8 Server-Racks von ihm versorgt werden.
  • Unterstützung einer angemessenen Anzahl von Warteschlangen, die einzeln mit den VSPs assoziiert werden können, um QoS und Traffic Shaping durchführen zu können. Selbst ein ToR-Switch benötigt je nachdem mehrere Tausend Queues, die den VSPs nach Bedarf zugeordnet werden können.
  • Unterstützung von Funktionen wie Link Aggregation, Load Balancing, Traffic Mirroring und Counter für alle VSPs genau in der gleichen Weise, wie diese Funktionen sonst für physikalische Ports implementiert werden können. Solche Funktionen erlauben den Betrieb von VMs mit dem gleichen Grad von Zuverlässigkeit, Leistung und Überwachung wie wir dies bei nativen Servern gewohnt sind.
  • Unterstützung einer adäquaten Anzahl von ACL-Regeln, so dass diese pro VM angewendet werden können. Nimmt man z.B. an, dass man 10 ACL-Regeln pro VM erlaubt, 20 VMs pro Server existieren können und 40 Server in einem Blade-System verbaut sind, bedeutet das, dass ein Access Switch rund 10.000 ACL Regeln und ein EoR-Switch (bei 8 Blade-Systemen) 80.000 ACL Regeln unterstützen können muss.

Die Bild 1 zeigt, wie Smart-NV die genannten Funktionsbereiche in Hardware unterstützt.

Es wäre eine Schande, die in der Nähe der Server gewonnene Leistung in einem historisch strukturierten Netz wieder vergehen zu lassen. Deshalb unterstützt Broadcom Smart-NV gefaltete Clos-Netze mit folgenden Verfahren in Hardware:

  • L2: TRILL und SPB
  • L3: OSPF und ECMP, für ausgedehnte ECMP-Strukturen, wie sie in Mega-Scale-Netzen benötigt werden, wird eine große Anzahl von L3 Forwarding Einträgen und ECMP-Routen unterstützt.

Der Begriff „flache Netze“ wird oft mit Netzen verbunden, die zwischen Pods oder Sites in einem RZ oder sogar über RZ-Grenzen hinweg ein reines L2-Netz aufbauen. Ist das zugrunde liegende Netz aber ein L3-Netz, kann man mit Tunnel-Technologien wie VXLAN, L2GRE oder NVGRE ein flaches virtuelles Netz über sie aufbauen. Und dann ist es entscheidend, dass die gleichen Switches auch diese Strukturen angemessen, skalierbar und leistungsfähig komplett in Hardware und mit Line-Rate unterstützen.

Für die Hardware-Unterstützung der VM-Kommunikation geht Broadcom davon aus, dass größere RZ-Netze aus betrieblichen Gründen, Gründen der Skalierbarkeit und Gründen der Leistung bis in die Access-Stufe hinein L3 unterstützen, was im Rahmen des Smart-NV-Konzeptes durch vergleichsweise große L3-Tabellen und stabile L3-Funktionalität unterstützt wird. Für die Uplinks zu Aggregations-Switches werden möglichst „fette“ konvergierte Datenströme mit Load-Balancing unterstützt. Es können mehrere Tausend ECMP-Links auf eine konvergierte Verbindung abgebildet werden.

Nach Beaobachtung des Herstellers kommen reine L2-Strukturen nur in vergleichsweise kleinen RZs vor. Die bisherigen Technologien zur Unterstützung von VM-Kommunikation und VM-Migration wie SR-IOV oder VEB/VEPA/EVB seien entweder nur in kleinem Maßstab aufgebaut worden oder würden teure, spezifische Hardware erfordern. Zudem zeige sich deutlich, dass Direktzugriffsverfahren wie Direct Path von den Herstellern von Virtualisierungssoftware nicht dauerhaft unterstützt würden und letztlich die VM-Live-Migration behindern.

« Teil 9: Weitere Hardware-Entwicklungen


zugeordnete Kategorien: LAN
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.

*

.