Flow-Prozessoren – Teil 3

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

Nachdem wir in den letzten Folgen die Grundidee der Aufspaltung konvergierter Datenströme und die grundsätzlichen Anforderungen an eine konstruktive Lösung dargestellt haben, kommen wir heute zu einer Referenzarchitektur und konkretisieren das Anwendungsbeispiel der Bearbeitung Regulärer Ausdrücke weiter.

Ein NFP muss eine in höchstem Maße flexible und optimierte Pufferarchitektur unterstützen, damit seine Anwendungen auch bei hohen Datenraten funktionieren. Eine solche Architektur sollte effiziente Mechanismen für die Alloziierung und Freigabe von Speicher, parallelen Zugriff auf Deskriptoren und Inhalte von Paketen und die Möglichkeit, Paketköpfe hinzuzufügen oder zu löschen besitzen. Sie sollte natürlich auch Packet-Queuing, Multicast und Jumbo-Frames unterstützen. Um Pakete innerhalb eines 10G-Systems in dieser Weise manipulieren und bewegen zu können, müssen die Schnittstellen, internen Busse und Speichercontroller mit sehr hoher Bandbreite arbeiten können. Eine typische Netzwerkanwendung, die das Store-and-Forward Modell benutzt, ist für mindestens folgende vier Datenbewegungen verantwortlich:

  • Bewegung des Pakets vom Media Interface zum Speicher
  • Lesen der Paket-Header aus dem Speicher
  • Bearbeiten der Paket-Header und Schreiben in den Speicher
  • Paket aus dem Speicher zum Ausgangs-Media-Interface bringen

Das bedeutet, dass die Speicherbandbreite (typischerweise SDRAM) mindestens 4X so hoch sein muss wie die Datenrate, also z.B. 40 Gbps (5 Gbps) für 10 GbE und 160 Gbps (20 Gbps) für 40 GbE. Für 10 GbE kommt man mit Elementen der DDR3-Speicherfamilie aus, deren Leistung bis ca. 12 Gbps reicht. Das wäre für 40 GbE-Lösungen aber deutlich zu wenig. Erst der seit kurzem lieferbare DDR4-Speicher mit einer Taktrate von 333 MHz und einem I/O-Takt von 1333 MHz erreicht hier die dafür notwendige Leistung. Die Latenz liegt grob bei 10 ns.

Leistungsbetrachtungen
Bei steigender Datenrate ist die Forderung, alle Pakete in Line-Rate bearbeiten zu können, wirklich massiv. Wir betrachten das einmal am Beispiel eines normalen Ethernet-Pakets mit einer minimalen Länge von 64 Bytes und einer maximalen Längen von 1518 Bytes. Die Anforderungen sind dann am höchsten, wenn nur kleine Pakete hintereinander kommen. Wegen der Inter Frame Gap von 12 Bytes und der Präambel von 8 Bytes kommen wir auf die Gesamtlange von 84 Bytes für ein minimal langes Paket.

Die Anzahl der zu bearbeitenden Pakete pro Sekunde PPS ergibt sich schlicht aus der Datenrate dividiert durch die Anzahl von Bits in einem Paket.

Bei einer Datenrate von 10 Gbps hat eine Switching-Lösung nur 51,2 nsec. Zeit für die Bearbeitung, bei 40 Gbps sind es nur noch 12,8 und bei 100 Gbps erschreckende 5,12 ns.

Blicken wir nochmals zurück auf die Speicher, sehen wir, dass die Datenrate von 40 GbE an der Grenze des heute mit Standard-Technologie Machbaren steht.

Nun kommt den Lösungen ja das Prinzip des skalierbaren Ethernet, wie es in IEEE 802.3ae festgeschrieben wurde, zu Hilfe. Ein ankommender Datenstrom wird sofort in Lanes zerlegt, die eine individuelle Datenrate haben, die ein Vielfaches von 2,5 Gbps darstellt. So kann man einen 10 GbE-Datenstrom in 4 X 2,5, einen 40 GbE Datenstrom in 4 X 10 oder 8 X 50 und einen 100 GbE-Datenstrom z.B. in 10 X 10 GbE aufspalten.

Im Gegenzug bedeutet das aber auch, dass sämtliche Komponenten in der durch die Zerlegung bedingten Anzahl mehrfach benötigt werden.

Geeignete und ungeeignete Lösungen
Bestehende Lösungen wie Netzwerk-Prozessoren oder Kommnunikations-Koprozessoren sind ungeeignet für Datenraten von 10 GbE und mehr, besonders wenn es die Notwendigkeit gibt, auch Funktionen der höheren Schichten auszuüben. Netzwerk-Prozessoren arbeiten auf L2 – L4 und ihnen fehlen normalerweise die Beschleunigungsfunktionen, die zur Unterstützung von L5 – L7-Funktionen benötigt werden. Kommunikations-Koprozessoren, bei denen üblicherweise eine GP-CPU mit Hardware-Beschleunigern (die einen festgelegten Funktionsumfang haben) auf einem Chip kombiniert werden, können sowohl Aufgaben auf der Daten- als auch auf der Anwendungsebene implementieren, sind aber in ihrer Leistung deutlich unter 10 GbE eingeschränkt. Die Anforderung, Deep Packet Inspection bei Line-Rate vorzunehmen, können sie definitiv nicht bewältigen. Letztlich wird man eine 2-Chip-Lösung benötigen, die das Beste aus beiden Welten kombiniert.

Das wesentliche Problem, welches GP-CPUs haben, ist ihre Cache-basierte Arbeitsweise. Cache-Mechanismen erzeugen Lokalitäten in Zeit und Raum und traditionelle Caches arbeiten aus folgenden Gründen bei schnellem Datenverkehr schlecht:

  • Paket-Daten und der Status pro Paket sind für jedes Paket vollständig neu. Daher müssen sie jeweils neu in den Cache bewegt werden, wenn ein neues Paket kommt.
  • Die meisten Pakete in einem kurzen Zeitfenster gehören zu unterschiedlichen Flows, wie das schon weiter oben ausgeführt wurde.

Auch mit einem Cache benötigen Speicherzugriffe rund 100 CPU-Zyklen, Zugriffe auf einen normalen Speicher benötigen sogar rund 300 CPU-Zyklen, wenn die CPU mit 1 GHz Taktrate arbeitet.

Referenzarchitektur
Nach diesen Vorbereitungen kommen wir zu einer Referenzarchitektur (Bild 1).

Links sehen wir den unstrukturierten, gemultiplexten an der Schnittstelle ankommenden Datenstrom. Eine entsprechende I/O-Schnittstelle erledigt die bekannten und durch die Standardisierung festgelegten Aufgaben, zu denen auch eine Zerlegung des Datenstroms in unterschiedliche Lanes gehören kann.

Die nächste Stufe nimmt Funktionen vor, die sich aus der Flow-Klassifizierung ergeben, primär den Demultiplex und das Load Balancing. Hier entscheidet sich auch, ob Pakete Funktionen implizieren, die durch eine GP-CPU erledigt werden müssen.

Die Komponenten der nächsten Stufe sind Hardware-Beschleuniger für spezielle Funktionen sowie multiple Speicherbänke sowie die Cache-basierten GP-CPUs.

Die Implementierung dieser Referenzarchitektur führt zu der rechten Seite der Abbildung. Aus Gründen der Skalierbarkeit trennt man die Aufgaben, die oberhalb der L2- L7-Funktionen liegen und nur durch GP-CPUs bearbeitet werden können, von denen für die eigentliche Baarbeitung des Datenstroms durch die Flow-Prozessoren, die in Clustern angeordnet werden können. Ein NFP integriert verschiedene spezialisierte Prozessor-Kerne (für die weiter oben angegebenen Treads), Kerne für spezielle Sicherheitsfunktionen und eine GP-CPU für Aufgaben wie Bootstrapping, Exception Handling, Diagnose und Debugging.

Mustererkennung für Reguläre Ausdrücke (RegEx)
Wissen Sie, was Reguläre Ausdrücke sind ? Musste ich ehrlich gesagt auch nachschlagen. Nach Wikipedia ist ein Regulärer Ausdruck (Regular Expression, kurz RegEx) „eine Zeichenkette, die der Beschreibung von Mengen von Zeichenketten mit Hilfe bestimmter syntaktischer Regeln dient. Reguläre Ausdrücke können als Filter in der Textsuche verwendet werden, indem der Text mit dem Muster des Regulären Ausdrucks abgeglichen wird. Dieser Vorgang wird auch Pattern Matching genannt.“ Schön, aber wo braucht man das ? In vielen Netzwerk- und Security-Anwendungen ist die Möglichkeit des RegEx-Matchings eine essentielle Anforderung, so z.B. für alle Anwendungen, die Deep Packet Inspection machen müssen, wie Intrusion Detection und Prevention Systeme, für Content-basierte Firewalls, für Virus Scanning und Anwendungen gegen Datenverlust. Man kann RegEx auch sozusagen umgekehrt einsetzen, um aus einem Grundmuster Varianten zu erzeugen. Das ist z.B. praktisch für eMail Spam Filter.

Man kann also sagen, dass alle Anwendungen in dieser Richtung das gemeinsame Problem haben, dass RegEx Matching performant implementiert werden muss.

Die Hersteller derartiger Anwendungen werden also laufend mit der Frage konfrontiert, wie sie dies nun mit spezieller Hardware machen oder das Problem auf eine Software-Realisierung mit einem x86-Prozessor verschieben sollen. Dafür gibt es Software-Pakete und Librarys, wie z.B. die Pearl Compatible Regular Expression (PCRE) Library.

In beiden Fällen wird aber zusätzlich noch spezielle Beschleunigungs-Hardware benötigt, um die Ziele, die man hinsichtlich 10 und 40 GbE-Übertragung hat, erreichen zu können. In den meisten Fällen, besonders bei Standard-LINUX-Implementierungen bevorzugen die Entwickler aus zwei Gründen eine Library-basierte Lösung. Zum einen ist dies ein weithin akzeptiertes Hilfsmittel in der Open Source Community und in der Sicherheits-Szene, zum anderen ist die Technologie im Gegensatz zu spezieller RegEx-Hardware kostenlos. Die Herausforderung bei einer Software-Lösung liegt in der Performance. Hersteller entwickeln heute Netzwerk- und Security Appliances mit Leistungen zwischen 5 und 10 Gbps. Das Problem ist nur, dass sich die Datenraten im Markt mit hoher Geschwiondigkeit auf 40 und 100 Gbps zubewegen. Das würde die Hersteller wieder in Richtung spezieller RegEx Hardware bewegen.

Wegen erheblicher Weiterentwicklungen bei den Intel-Prozessoren und der Entwicklung der Flow-Prozessoren und Beschleuniger-Plattformen gibt es jedoch eine weitere Alternative.

Viele aktuelle Appliance-Designs basieren auf Xeon ® Quad-Prozessoren mit einem oder zwei Sockeln, die etwa bei 3,0 GHz Taktfrequenz arbeiten. Der x86 Befehlssatz ist ideal für komplexe Datenverarbeitung, so wie RegEx Matching. Diese Designs untestützen RegEx Matching mit Geschwindigkeiten zwischen 1 und 3 Gbps ohne die Hinzunahme weiterer Hilfsmittel wie Flow-Prozessoren. Fügt man auf dem Wege eines PCIe-Busanschlusses hinzu, steigt der Durchsatz nicht, da die I/O derartiger Systeme begrenzt ist. Mit den Westmere Xeon CPUs, die sechs Cores mit je zwei Threads haben, kann die Leistung ohne wesentliche Kostensteigerung verdreifacht werden, allerdings bleibt die I/O nach wie vor ein Problem. Mit etwas Glück ist eine solche Lösung also grade noch für 10 GbE zu brauchen. Die tatsächliche Herausforderung, die es heute gibt, ist es, die Leistung der I/O so weit heraufzusetzen, dass das volle Bearbeitungs-Potential dieser Prozessoren genutzt werden kann. Hierzu benötigt man eine heterogene Architektur.

Wir sehen uns einmal konkret an, was eine Kombination aus den Westmere x86ern mit Flow Prozessoren, konkret dem Modell NFP-3240 von Netronome, bringt. Der Flow-Prozessor entlastet den x86 von rechenintensiven Aufgaben, wie komplexes Flow Processing und die Verteilung von Paketen über CPU und Speicher, die alle die Gesamtleistung senken. In dieser Anordnung ist der Flow-Prozessor auch für die Anwendung hardware-getriebener Regeln auf den Flows verantwortlich, wie Load Balancing, Flow-Umleitung zu spezifischen Arbeitseinheiten z.B. für das Matching, Filterung oder CutThrough Operationen.

In dem betrachteten Beispiel werden die CPU und die Flow-Prozessoren über ein PCIe Gen2-Interface mit einer Brutto-Datenrate von 40 Gbps verbunden. Die Nutzung der Flow Prozessoren als Front End erlaubt es, Flow Preprocessing durchzuführen, bevor Matching oder Deep Packet Inspection für jeden Flow oder jedes Paket durchgeführt wird. Flow-Preprocessing in diesem Zusammenhang bezieht sich auf Identifizierung und Klassifizierung eines Flows basierend auf dem entsprechenden 5-, 7- oder 11-Tupel eines ankommenden Pakets und Anwendung der programmierbaren Aktion auf dem Flow. Flows können im Rahmen von Load Balancing über multiple parallele Anwendungs-Instanzen an die CPU geliefert oder an eine spezifische Instanz oder den CPU-Kern gebunden werden. Andere Aktionen umfassen das Verwerfen, das aktive Zurückweisen oder die Durchleitung eines Flows. Auf diese Weise können die Regeln oder Aktionen, die mit jedem Flow assoziiert sind, dynamisch geändert oder upgedated werden, z.B. als Reaktion auf RegEx-Verarbeitung, DPI, Signatur Matching oder anderer Analyse-Maßnahmen. Diese Art von Flexibilität ist wichtig in allen Situationen, in denen eine spezifische Portion eines Flow, wie z.B. die ersten 500 Bytes, genau inspiziert werden müssen, nach erfolgreicher Analyse z.B. durch RegEx Matching der Rest des Flow aber einfach ohne weitere Betrachtung „durchgewunken“ werden kann. So spart man wertvolle PCIe-Übertragungskapazität und CPU-Zyklen.

Eine andere Situation entsteht, wenn der Programmierer sich dazu entschieden hat, die Bearbeitung eines Flows in Abhängigkeit vom Ergebnis einer Analyse zu ändern. Bei Inline-Anwendungen kann ein Match zu dem Ergebnis führen, dass es sich bei dem Flow um eine Schad-Software handeln könnte. In diesem Fall könnte die Hardware-basierte Regel zur Flow-Bearbeitung bedeuten, dass alle Pakete des Flows vernichtet werden.

Eine weitere Möglichkeit zur Erhöhung der Effizienz ist die Klassifizierung eines Flows als bestimmte Anwendung und die Umleitung des Flows zu einer Signatur-Datenbank die mit Mustern befüllt ist, die von Anwendungen, die dem Flow entsprechen, gerne benutzt werden. Dieser Ansatz erlaubt dem System, viele Maschinen jede mit einer eigenen und speziellen Signatur-Datenbank zu betreiben, anstatt verschiedene Maschinen mit großen, einheitlichen Signatur-Datenbanken laufen zu lassen. Beispiel: eine DPI oder Klassifizierungs-Engine sollen Webmail-Verkehr untersuchen. Die Engine könnte in diesem Fall den Fluss zu einer anderen Engine weiterleiten, die speziell nach Dokumenten-Wasserzeichen oder anderen Zeichen dafür sucht, dass hier sensitive Daten über unautorisierte Kanäle wandern.

« Teil 7: Flow-Prozessoren – Teil 2Teil 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.

*

.