Flow-Prozessoren – Teil 1

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

Um den ständig steigenden Anforderungen in Netzen auch in den nächsten Jahren gerecht werden zu können, benötigt man ein grundlegend neues Hardware-Design. Die speicherbasierten Switch-ASICs sind hier sicher ein erster Schritt in die richtige Richtung, der aber perspektivisch betrachtet nicht ausreichen wird. Nach 48, 64 oder 96 10/40/(56) Gbps-Ports ist eine weitere Steigerung der L2-Switching-Kapazität zunächst wenig sinnvoll. Also sollten die zusätzlich möglichen Transistorfunktionen möglichst für die Hardware-Unterstützung höherwertiger Funktionen genutzt werden. In den folgenden Teilen der Serie sehen wir uns das einmal für verschiedene Funktionsbereiche an. Wir beginnen mit den Flow-Prozessoren.

Ein Vorschlag für die Realisierung höherwertiger Funktionen ist eine heterogene Multi-Chip, Multi-Prozessor Architektur, die sich für die Bedarfe der Implementierung von L2-L7-Funktionen an den Flows in einem Netz orientiert und mit einer Menge von NFPs (Network Flow Multi-Core Processor) arbeitet, die durch einen oder mehrere General Purpose Multi-Core-Prozessoren ergänzt wird. Designs auf dieser Grundlage ermöglichen den Geräte-Herstellern die Realisierung von flexiblen, feld-programmierbaren Geräten, die eine längere produktive Lebenszeit haben können als dies mit anderen Konstruktionen möglich ist. Das ist nicht nur für Service-Provider, sondern auch für alle anderen Netzbetreiber interessant. Es gibt Hersteller, die schon länger Flow-Prozessoren als eigenständige Komponenten anbieten. Um zu verstehen, die das Konzept arbeitet, sehen wir uns zunächst einmal diese Form der Implementierung an. Die Tendenz ist aber, mittelfristig die Flow-Prozessoren mit den Switch-ASICs zusammen auf einem singulären Substrat zu implementieren.

Herausforderungen durch Konvergenz und Geschwindigkeit
Die Konvergenz unterschiedlicher Netzwerkdienstleistungen in ein gemeinsames Transportsystem ist ein Trend, der uns schon seit vielen Jahren begleitet. Begonnen hat diese Entwicklung streng genommen mit der Abbildung analoger Telefondienstleistungen auf digitale Netze, z.B. mit ISDN. Mit der Zeit sind weitere Voice, Video und Wireless-Dienste hinzugekommen, die bei Providern mittels Ethernet-Transport, IP und Protokollen wie SIP integriert werden. RZ-Betreiber haben zusätzlich die Vorteile der Konvergenz von Daten- und Speicherverkehr für sich entdeckt und nach einigen Jahren sind auch die dazu notwendigen Basistechnologien wie DCB oder FCoE Standard geworden. Letztlich kann man auch den Standpunkt einnehmen, dass Virtualisierung ein Konvergenzthema ist, weil die Konsolidierung von Servern und Speichern auf moderne Server auch hier eine Konvergenz der bisher von den singulären Servern benötigten Datenströme auf einer gemeinsamen, entsprechend leistungsfähigeren technischen Basis erfordert.

Als Resultat dieser Entwicklungen ist der notwendige Grad von Intelligenz in den Netzwerk-Einrichtungen gestiegen, wobei einige Knotentypen, besonders an den Rändern eines Netzes ganz erhebliche Steigerungen der programmierbaren Intelligenz benötigen, um die komplexen Dienste bei immer weiter steigenden Datenraten implementieren zu können.

Nun bedeutet Konvergenz keineswegs, dass Services ohne weitere Dienstleistungen einfach auf Leistungen gemischt und zusammen übertragen werden. Vielmehr bedeutet grade die Konvergenz die Notwendigkeit von Funktionen, die die Datenflüsse der einzelnen Dienste, die auf einem Übertragungssystem gemischt behandelt werden, weiterhin begleiten und auf dem Wege Funktionen ausüben, die nicht nur die Integrität, sondern auch den ursprünglichen Charakter der Dienste bewahren. Durch die Konvergenz für ein Netz hinzutretende Arbeitsbereiche sind mindestens:

  • Service-Definition und Aggregierung
  • Service-Priorisierung
  • QoS
  • Security

Bild 1 zeigt die wichtigsten Kräfte, die hinter den intelligenten Netzen der nächsten Generation sowohl bei Service-Providern als auch im Enterprise-Bereich stehen.

Das Verkehrsaufkommen ist generell durch Consumer-Breitband-Dienste, Datenverkehr zwischen den Unternehmen und neuere IP-Dienste wie IPTV dramatisch gewachsen und angesichts von Trends wie Cloud Computing ist auch nicht zu sehen, dass sich das ändern sollte. Mit der Explosion von Internet-basierten Diensten sind die Bandbreite-Anforderungen an jedem Punkt eines Netzes erheblich gestiegen und als Resultat haben sich die Line Speeds auf Fernverbindungen etwa alle fünf Jahre vervierfacht. In Unternehmen und hier besonders in Rechenzentren ist die Steigerung noch deutlicher: waren vor fünf Jahren durchaus noch 1 GbE-Anschlüsse in der Lage, Server zu bedienen, ist heute 10 GbE das Minimum. Es gehört nur wenig Prognosekraft dazu, 100 GbE als das Minimum für ca. 2018 vorherzusagen.

Eine weitere 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.

Sicherheit ist ein weiterer Bereich, der erhebliche Anforderungen an die „Intelligenz“ eines Netzes stellt. Wachsende Sicherheitsanforderungen treiben die Notwendigkeit für „Deep Packet Inspection“ und Security Processing. Netzwerk-Sicherheit war immer ein wichtiges Thema, aber durch Tendenzen wie SaaS oder Web 2.0-Anwendungen nimmt die Menge der über ein Netz übertragenen sensiblen Informationen deutlich zu. Wichtige Treiber für den Sicherheits-Markt von Heim-Netzen über die Netze in Unternehmen und Organisationen bis hin zu Provider-Netzen sind:

  • Steigende Zahl der Angriffe
  • Anstieg des Volumens von unproduktivem oder schädlichem Verkehr
  • Sicherheits-bedingte Down-Time, die an der Produktivität nagt
  • Regulatorische oder andere gesetzliche Zwänge zum besseren Datenschutz
  • Datenverlust (führt zu Investitionen bei Verschlüsselung, Intrusion Prevention und Zugriffskontrolle)

Die Virtualisierung führt in Rechenzentren zu gesteigerter Leistung, höherer Effizienz und geringerem Energieverbrauch, aber nur dann, wenn auch die Konzepte für Verwaltung, Betrieb und Sicherheit „stimmen“. IT-Manager und Sicherheits-Architekten benutzen die Virtualisierung zunehmend dazu, die Auslastung der wertvollen Server zu verbessern. War Virtualisierung in den ersten Jahren für das Netz primär durch die gemeinsame Benutzung geteilter Ressourcen charakterisiert, führt die im Rahmen neuer Betriebskonzepte zunehmende Dynamisierung von Virtualisierungsumgebungen zu völlig neuen Anforderungen.

Wie können die Anforderungen erfüllt werden?
Um die charakterisierten Anforderungen in Zukunft erfüllen zu können, benötigt man mit Sicherheit einen völlig neuen konstruktiven Ansatz für die Gestaltung intteligenter Netze. Solche Systeme müssen Traffic auf L2 – L7 behandeln und auf jeder Schicht spezielle Aufgaben ausführen können, müssen dabei aber gleichzeitig Durchsatzraten von 10 Gbps oder mehr aushalten. Dabei kann die Kombination aus Netzwerk Flow Prozessoren und General Purpose Prozessoren helfen. Ein NFP ist ein spezialisiertes Multi-Core Gerät für die Realisierung von Aufgaben in L2 – L4 und die Unterstützung bzw. Beschleunigung von Aufgaben in L5 – L7.

L2 – L4 Packet Processing
Die Funktionen auf L2 – L4 müssen mit besonders hoher Geschwindigkeit ausgeführt werden. Man kann die Funktionen nach solchen für eingehende (ingress) und ausgehende (egress) Pakete differenzieren. Funktionen für eingehende Pakete sind:

  • Fehlererkennung und – Korrektur
  • Sicherheits-Verifizierung, einschließlich evtl. Blockierung eingehender Pakete
  • De-Enkapsulierung und Ent-Tunnelung für z.B. VPNs oder IP über MPLS
  • Flow-Klassifizierung
  • Verkehrsmessung
  • Durchsetzung von Regeln
  • Adress-Lookup und Forwarding
  • Header-Modifikation
  • Wieder-Zusammensetzen von Paketen und Terminierung von Flows
  • Forwarding, Queing und Scheduling (z.B. für differenzierte Priorisierung)

Funktionen für ausgehende Pakete sind

  • Hinzufügung von Fehler-erkennendem Code
  • Adresss-Lookup und Packet Forwarding
  • Paket-Segmentierung
  • Traffic Shaping
  • Timing, Scheduling, Queuing und Zwischenspeicherung
  • Header Modifikation
  • Einkapselung und Tunnelung
  • Sicherheitsbearbeitung für ausgehende Pakete

In der Vergangenheit wurden diese Funktionen mit einer Kombination eines Cross-Bar basierten ASICs mit einem General Purpose-Prozessor erledigt. Das ist vor dem Hintergrund von 10 GbE Line Rates deutlich zu langsam. Auch wenn die neuen speicherbasierten Switch-ASICs hier deutliche Verbesserungen bringen und auch insgesamt mehr Funktionen haben, kommen sie in den meisten Fällen heute noch nicht ohne einen zusätzlichen Prozessor aus. Bevor wir das weiter diskutieren, sehen wir uns erst einmal an, welche Möglichkeiten zur Optimierung der Paketverarbeitung bestehen.

Optimierung der Paketverarbeitung
Ein Weg zur Verbesserung der Leistung der Paket-Verarbeitung ist die Benutzung einer so genannten Fluss-Klassifizierung. Anstatt jedes einzelne Paket ohne weiteren Zusammenhang zu bearbeiten, wird der Verkehr in Flows zerlegt. Diese Flows haben zunächst einmal nichts mit den Flows wie sie z.B. in SDN/OpenFlow definiert werden, zu tun, einen möglichen Zusammenhang diskutieren wir später. Nehmen wir als Beispiel eine Hash-Funktion, die auf einem ankommenden Pakt ausgeführt werden muss, um die Bestimmung eines Flows zu ermitteln. Diese Funktion kann auch Zustandsinformationen und Aktions-Listen für einen Flow verwalten und bestimmen, die in der Folge für alle Pakete gelten, die dem gleichen Flow angehören.

Eine weitere Methode zur Optimierung der Paketverarbeitung ist die Parallelisierung. Betrachten wir die in einem kurzen Zeitfenster an einem Netzwerk-Gerät ankommenden Pakete. Mit hoher Wahrscheinlichkeit gehört der größte Teil der ankommenden Pakete jeweils zu anderen Flows, die z.B. durch unterschiedliche Dienste, die auf der betreffenden Leitung konvergiert wurden, gehören, also Paket 1 gehört z.B. zu einem Speicherverkehr, Paket 2 zu einer I/O einer VM, Paket 3 ist ein VoIP-Paket usw. Genau das passiert, wenn man z.B. mit einer Funktion wie ETF aus DCB Pakete, die ursprünglich zu unterschiedlichen Übertragungsdiensten gehören, multiplext. Hat man jetzt in einer architekturellen Lösung viele Cores von spezialisierten Netzwerk-Prozessoren, können diese die Pakete unabhängig voneinander parallel bearbeiten. Bezogen auf eine Line-Rate, die man erreichen bzw. unterstützen möchte, kann man auf diese Weise das mögliche „Processing Budget“, was für ein Paket zur Verfügung steht, erheblich steigern.

Eine weitere Methode, um das „Processing Budget“ für jedes einzelne Paket zu erhöhen, ist die Bereitstellung mehrerer Cores, die in einer Pipe angeordnet sind, wobei jeder Core eine spezifische Aufgabe auf dem Paket ausführt. In diesem Fall wird die Bearbeitung in Subtasks zerlegt, wobei jeder Stufe der Pipeline eine Subtask zukommt. Manche der Stufen in einer solchen Pipeline können durch feste Hardware-Einheiten, andere durch programmierbare Funktionen realisiert werden.

Um die Ressourcen auf einem Chip optimal auszunutzen, ist es am Besten, alle drei Methoden (Flow-Klassifizierung, Parallelisierung und Pipelining) gleichzeitig anzuwenden.

« Teil 5: Konvergente Multiprotokoll Switch-ASICsTeil 7: Flow-Prozessoren – Teil 2 »


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.

*

.