Flow-Prozessoren – Teil 2

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

Zur Beschleunigung von L5- l7-Funktionen einschließlich Sicherheitsfunktionen
bei Hochgeschwindigkeitsnetzwerken wie wir sie hier betrachten, benötigt eine CPU, die Deep Packet Inspection machen möchte, die Hilfe externer Beschleuniger. Ein Anwendungsbeispiel, bei dem externe Beschleunigung erforderlich wird, ist die Implementierung von Sicherheitsfunktionen, die auf der Grundlage der Inspektion Regulärer Ausdrücke durchgeführt werden.

MACSec oder IEEE 802.1ae ist ein Sicherheitsprotokoll, was von IEEE 802 für die Realisierung von Sicherheitsfunktionen auf der Schicht 2 (MAC) definiert wurde. IPSec ist z.B. für die Sicherheit auf der Netzwerk-Schicht zuständig und wird z.B. im Rahmen von VPN-Verbindungen benutzt. Zusätzlich gibt es weitere Sicherheits-Protokolle auf höheren Schichten wie TLS (Transport Layer Security) oder SSL (Secure Sockets Layer).

Als Konsequenz sind üblicherweise im Rahmen z.B. eines Web-Zugriffs mehrere dieser Protokolle gleichzeitig aktiv und jede Art der Paketverarbeitung muss auf einem einzigen Paket gleich mehrere sicherheitsrelevante Funktionen ausüben.

Es wird sofort intuitiv klar, dass bestehende General Purpose CPUs damit völlig überlastet sind, wenn es um hohe Datenraten ab 10 GbE geht. Auch der Gedanke, diese Bearbeitung auf VMs auszulagern, ist völlig absurd. Die benötigten Prozesswechsel sind ohne jede weitere Funktion schon langsamer, als das für diese Zwecke hingenommen werden könnte.

Damit Paket-basierte Manipulationen bei höheren Datenraten ab 10 Gbps überhaupt funktionieren, müssen, um es einfach zu sagen, die konvergierten Datenströme wieder zerlegt werden.

Bei der L2 – Bearbeitung ist das Konzept des skalierbaren Ethernet hilfreich. Schnelle Datenströme werden in parallele Lanes unterteilt, die dann unabhängig parallel bearbeitet und schließlich wieder zusammengefügt werden. (siehe Bild 1)

Das hatte ich ja in den Teilen 4 und 5 ausführlich dargestellt.

Für L3 – L7 benötigen wir etwas mit ähnlicher Wirkung auf einer anderen Basis. Nahe liegend ist es hier, aus dem konvergierten Datenstrom die gemultiplexten Flows zu vereinzeln, damit sie anschließend unabhängig voneinander bearbeitet werden können, bevor die betreffenden Pakete wieder auf Ausgangsleitungen gemultiplext werden.

Für die Identifikation eines Flows können grundsätzlich alle Informationen hinzugezogen werden, die sich außer dem eigentlichen Inhalt in einem Datenpaket befinden, also z.B. Quell- und Zieladressen für die Schichten 2,3, und 4 sowie weitere Informationen zu Priorisierung/QoS oder weiteren Eigenschaften, wie sie in den IEEE 802.1 und .3-Standards festgelegt sind. Darüber hinaus kann man auch noch weitere Informationen verwerten, die z.B. beim konvergierten Speicherverkehr vorliegen, wo FC-Pakete in FCoE-Pakete enkapsuliert wurden oder Informationen, die sich z.B. im Rahmen eines Overlay-Verfahrens wie VXLAN ergeben. Hier sind die Möglichkeiten fast grenzenlos.

Blicken wir jetzt auf Bild 2. Der gemultiplexte, konvergierte Datenstrom kommt also über eine 10, 40 oder 100 GbE-Leitung am Flow-Demultiplexer an. Die Aufgabe des Flow-Demultiplexers ist es, die ankommenden Pakete nach den Flows zu sortieren. In diesem Zusammenhang sollte er natürlich Mustererkennung beherrschen, denn nur so kann er in angemessener Geschwindigkeit arbeiten. Wichtig ist natürlich auch die Möglichkeit, dem Flow-Demultiplexer neue Muster für neue Flows beibringen zu können. Diese Arbeitsweise wird in der Literatur auch als „Flow-Klassifizierung“ bezeichnet.

Die einzelnen Datenpakete, die jeweils zu einem Flow gehören, werden an einen Prozessor weitergeleitet, dessen Aufgabe es einzig und alleine ist, bestimmte, für diesen Flow spezifische Aufgaben auszuüben. Zu diesen Aufgaben kann es auch gehören, ein neues Ziel für ein Paket festzulegen. Ist der Prozessor mit der Verarbeitung eines Paktes fertig, schickt er es an die Queueing-Stufe einer Switching-Einheit. Diese Stufe ist in konvergierten Netzen nach ETF/DCB organisiert. Erst aus dieser Stufe kommen die Pakete in die eigentliche Switching-Matrix.

Wir haben hier den Einsatz von Flow-Prozessoren direkt in einem Switch dargestellt. Es gibt auch noch andere Möglichkeiten, aber zur Verdeutlichung des Prinzips sollte das ausreichen.

SDN/OpenFlow ist eine mögliche Methode zur Definition von Flows, aber in keinster Weise ausschließlich für das Konzept. Letztlich kann eigentlich jeder Betreiber Flows definieren, wie er möchte oder die Definition automatischen Mechanismen überlassen.

Zur Erklärung haben wir bislang angenommen, dass ein Flow nur von einem Prozessor bearbeitet wird. Das ist natürlich eine grobe Vereinfachung, denn:

  • es kann notwendig sein, auf einem Flow mehrere Funktionen hintereinander auszuführen (Pipelining)
  • es kann sein, dass die auf einem Flow auszuübende Funktion zu umfangreich ist, um von einem Prozessor in angemessener Zeit bearbeitet werden zu können. In diesem Fall müssen für diesen Flow mehrere parallele Prozessoren zur Verfügung stehen

Wir sehen das in Bild 3 beispielhaft. Jeder Flow muss durch eine für ihn spezifische Sicherheitsinspektion, die durch die orangenen und magentafarbenen Flow-Prozessoren implementiert wird. Erst dann können die weiteren für die jeweiligen Flows definierten Aktionen durchgeführt werden. Im Falle des gelben Flows sind sie komplexer, und es muss ein kleines Cluster aus Flow-Prozessoren zum Einsatz kommen.

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.

Flexibilitäts- und Leistungs-Ansprüche an eine Lösungsachitektur
In der letzten Folge haben wir gesagt, dass eine Lösungsarchitektur aus zwei Gruppen von Komponenten besteht: spezialisierte Netzwerk-Flow-Prozessoren und General Purpose CPUs. Wie auch immer die Architektur am Ende aussieht, ist es nötig, dass Elemente dieser beiden Gruppen in unterschiedlichen Rollen zusammenspielen können. Diese Methoden der Zusammenarbeit werden in der Literatur auch als „In-Line“ oder „Look-aside“ bezeichnet.

Im Look-aside-Modus ist die GP-CPU der Master und kann die Arten von Aufgaben auswählen, die durch zusätzliche Hilfsprozessoren wie NFPs implementiert werden sollen, wie z.B. Beschleunigungsfunktionen. Im In-Line-Modus ist der Hilfsprozessor der Master und schickt z.B. nur vorverarbeitete Pakete an die GP-CPU. In diesem Modus kann ein Hilfsprozessor entscheiden, ob ein Paket überhaupt zur Bearbeitung an eine GP-CPU geschickt werden muss, oder ob es ohne weitere Bearbeitung weitergeleitet werden kann.

Ein NFP benötigt geeignete Schnittstellen, um beide Modi unterstützen zu können. Letztlich muss ein NFP z.B. zwischen einem Eingangs-Port und einer Switching-Fabric, zwischen einer Switching Fabric und einem Ausgangs-Port oder neben der Switching Fabric sitzen können.

Ein NFP benötigt multiple programmierbare Packet Processing Engine (PPE) Cores, die leistungsintensive Aufgaben auf einem niedrigen Niveau, wie z.B. Bearbeitung eingehender Pakete oder Header, Table Lookup, Packet Forwarding oder Bearbeitung ausgehender Pakete bewältigen können. Das günstigste Konstruktionsprinzip für einen PPE-Core ist eine gepipelinete RISC Multi Thread Architektur, die deshalb schnell arbeiten kann, weil ihre Operanden in allgemeinen lokalen Registern liegen. Da der PPE mehrere Threads unterstützt, muss bei einem Thread-Wechsel ein Kontext-Switching für den Zugriff auf einen externen Speicher möglich sein, wenn der Thread das benötigt.

Die Aufgaben im Rahmen einer Protokoll-Bearbeitung durch einen Thread sind in modulare funktionale Blocks zerlegt, die von den Datenfluss-Mechanismen zwischen ihnen isoliert werden, damit der Thread sich nur auf die Protokoll-spezifischen Bearbeitungsaufgaben konzentrieren kann. Das erlaubt auch die Wiederverwendung des Codes für die funktionalen Blocks. Jeder Thread für die Paketverarbeitung cached den Paket-Header oder Deskriptor in lokalem Speicher oder einem Register, damit er von unterschiedlichen funktionalen Blocks benutzt werden kann.

Ein NFP benötigt ein Modell für die Anwendungsprogrammierung, welches die Leistung optimieren kann, die Wiederverwendung von Code ermöglicht und es erlaubt, dass Anwendungen hin zu höheren Übertragungsraten skalieren. Es hat sich als günstig erwiesen, hardware-spezifischen Code wie Senden, Empfangen oder Queue-Management vom Code für die Bearbeitung protokollspezifischer Aufgaben zu trennen und die unterschiedlichen Programme auch auf unterschiedlichen Threads laufen zu lassen. Diese Trennung erleichtert die Portabilität und die Wiederverwendung von Code. Der Grundgedanke, mehrere Threads an einem Paket parallel arbeiten zu lassen, wird ebenfalls auf diese Weise durchgesetzt.

« Teil 6: Flow-Prozessoren – Teil 1Teil 8: Flow-Prozessoren – Teil 3 »


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.

*

.