Im
ersten Artikel wollte ich zeigen, dass die FPGA-Entwicklung eine interessante Aufgabe ist und die Implementierung eines Stream-Encapsulators ein relativ einfaches Projekt ist, das sich gut als akademisches Projekt für Senior- oder Doktoranden eignet.
Auch wenn sich das Hardware-Design nur zum Spaß lohnt, möchte ich in diesem Artikel auf den praktischen Wert dieser Lektion eingehen. In unserem Gespräch geht es insbesondere um die Erstellung einer Netzwerkinfrastruktur für Telekommunikationsbetreiber mit dem auf FPGA implementierten Etherblade.net-Encapsulator.
Dieser Text gibt einen Einblick in Netzwerktechnologien. Um ein so umfangreiches Thema in einen Artikel aufzunehmen, habe ich mich dazu entschlossen, ihn im Rahmen eines Aktionsplans oder, falls gewünscht, der Antwort auf die folgende Frage zu verfassen: „Wie können Geräte mithilfe von FPGA und Open Source so effizient wie möglich ersetzt werden? von Cisco und Juniper. "
Also fangen wir an.
Das Konzept von SDN (Software Defined Networking) gegen große Anbieter
Traditionell werden Netzwerkgeräte seit Jahrzehnten von Giganten wie Cisco und Juniper hergestellt. Heute werden große Netzbetreiber, die ihre eigene Netzausrüstung entwickeln, zur neuen Norm. Das Ziel, das sie erreichen wollen, ist die Unabhängigkeit von Komponentenlieferanten und eine bessere Kontrolle über die Infrastruktur.
In Russland wird dieser Ansatz, der aus politischen Gründen mit dem Ersatz von Drittanbieterprodukten durch Systeme mit einem höheren Prozentsatz lokal entwickelter intellektueller Komponenten (Intellectual Property Blocks oder IP-Cores) verbunden ist, in der Regel als Importsubstitution bezeichnet.
Es versteht sich, dass große Unternehmen über eine enorme Menge an technischen Ressourcen verfügen und sich auf ein vertikal integriertes Entwicklungsmodell verlassen. Und was ist mit relativ kleinen Herstellern?
Fehlende Ressourcen können durch Open Source ausgeglichen werden. Und das Fehlen einer vertikalen Integration mit der richtigen Verteilung von Unteraufgaben auf kleinere Akteure.
Die Architektur von Netzwerkgeräten, die traditionell von großen Anbietern hergestellt werden, ist leicht zu segmentieren. Um den Prozess zu parallelisieren und einzelne Teilaufgaben hervorzuheben, schlägt das Konzept des SDN (Software Defined Networking) vor, die Architektur von Netzwerkgeräten in Ebenen zu unterteilen, insbesondere die Ebene des Netzwerkmanagements (Steuerebene) von der Ebene der Datenübertragungsgeräte (Datenebene) zu trennen.
Ich stelle fest, dass das SDN heute zu einem leistungsstarken Marketing-Tool für große Anbieter geworden ist, die es als eine Reihe von "neuen Funktionen" präsentieren, die für den Endbenutzer nützlich sind. Das Lustige ist, dass das Konzept von SDN historisch, wie ich bereits bemerkte, nur im Gegensatz zu den Giganten der Branche geschaffen wurde.
Daher bietet SDN ein Modell der Architektur eines Netzwerkrouters in disassemblierter Form. Unsere Aufgabe ist es, die für uns interessante Komponente in diesem Modell zu identifizieren und mit der Entwicklung zu beginnen.
"Fangen wir klein an" - Kapselung auf Routern und SDN-Overlay
Es ist selbstverständlich, alle Bedürfnisse der Welt auf einmal zu lösen. Daher ist es bei der Erstellung großer Systeme sinnvoll, klein anzufangen und das System erweiterbar zu machen, damit zusätzliche Funktionen eingeführt werden können, indem zusätzliche Blöcke integriert oder vorhandene geändert werden. Mit den Worten "klein anfangen" meine ich die Auswahl einer vollständigen Netzwerkfunktion, die ausreicht, um ein funktionierendes System aufzubauen.
Im Etherblade.net-Projekt wurde als solche Funktion beschlossen, einen Mechanismus zum Einkapseln des Netzwerkverkehrs zu implementieren.
Die Kapselung in Netzwerken ist eine gewöhnliche Sache. Lassen Sie uns den Router „desegregieren“ und betrachten, wie seine Komponenten mit den Komponenten des SDN-Modells übereinstimmen, und bestimmen, welchen Platz die Verkapselung in beiden Modellen einnimmt.
Nehmen Sie zum Beispiel einen der in der Abbildung ganz am Anfang des Artikels gezeigten Router und stellen Sie ihn in der folgenden Abbildung dar - jedoch bereits in einer „vorbereiteten“ Form.
In der gleichen Abbildung stellen wir dem Router ein alternatives „Overlay-SDN-Modell“ gegenüber, das ähnliche Funktionen bietet.
Die obere (grüne) Ebene ist die SDN-Steuerungs- / Orchestrierungsebene. Dies ist das Gehirn des Systems, in der Tat der Mikroprozessor, auf dem die steuernde Netzwerksoftware ausgeführt wird. In herkömmlichen Routern ist diese Komponente integriert. In SDN wird diese Funktionalität normalerweise an einen externen „Orchestrierungscontroller“ übertragen - einen Computer, der viele Netzwerkgeräte bedient.
Mittel (blau) Level - Weiterleitungspfad. Die Hauptaufgabe dieser Ebene ist die Bereitstellung des Netzverkehrs (Switching / Traffic Routing). In herkömmlichen Routern wird diese Funktionalität als interne Vermittlungseinheit implementiert. In unserem „SDN-Overlay“ -Modell kann die Rolle dieser „Switching“ -Komponente vollständig reduziert werden, indem die Edge-Geräte (Whitebox) direkt an das Transportnetz angeschlossen werden.
Untere (orange) - Kante / Zugangsebene. Auf diesen Komponenten finden alle Manipulationen mit Netzwerkverkehr wie Kapselung und andere Protokollkonvertierungen statt. Dieses Level zeichnet sich durch hohe Verarbeitungsgeschwindigkeit und deterministische Funktionalität aus - ein großartiger Ort für ASIC / FPGA. In herkömmlichen Routern ist diese Funktionalität auf linearen Modulen (Line-Cards) implementiert, in SDN sind dies die sogenannten „Whitebox-Geräte“.
Zusammenfassend können wir also sagen, dass Etherblade.net im Wesentlichen ein Projekt zur Entwicklung von "Whitebox" -Geräten für "SDN-Overlay" ist.
"Forward to Data Centers !!!" - Encapsulator als Funktion von NFV (Network Function Virtualization)
Nachdem wir herausgefunden haben, wie das System, das wir entwickeln, strukturell aussieht, ist es sinnvoll, über die Optionen für seine physische Verkörperung zu sprechen.
Auf der linken Seite befindet sich ein Etherblade-Encapsulator als separates CPE-Gerät (Campus-Version). Rechts ist der Etherblade-Encapsulator im Server implementiert (Option für Rechenzentren).Es ist interessant, dass durch die Implementierung eines Encapsulators auf einer Karte mit einer PCIe-Schnittstelle und das „Verstecken“ dieser Karte im Server die Illusion entsteht, diese Netzwerkfunktion zu virtualisieren. Dieser Ansatz wird als NFV - Network Function Virtualization bezeichnet.
Das Konzept von NFV sieht vor, externe Netzwerkgeräte wie Firewalls, Load-Balancer usw. aufgrund der Virtualisierung ihrer Funktionen innerhalb der Server zu entfernen. Durch die Implementierung des Encapsulators als NFV-Funktion können wir die physischen Edge-Router loswerden.
So ist NFV in Mode und bequem. Die Schwierigkeit besteht darin, dass die Eindämmung von PCIe im Hinblick auf das Hardware-Design nicht so einfach ist wie das Ethernet. Wenn Ethernet ein serielles serielles Protokoll ist, ist PCIe ein komplexes Transaktionsprotokoll mit vielen Endzuständen (im Wesentlichen ein in Hardware implementierter Netzwerkstapel). Vergessen Sie nicht, dass das Betriebssystem die entsprechenden Treiber benötigt, um mit dem PCIe-Gerät zu arbeiten.
Eine der elegantesten Lösungen für das Problem ist die Verwendung von FPGA-Karten, ähnlich der am Anfang des Artikels gezeigten. Die folgende Abbildung zeigt die Architektur der Karte und beide Optionen für die Implementierung des Encapsulators.
Wie Sie sehen, verfügt diese FPGA-Karte über integrierte „externe“ Netzwerkadapter, die im Wesentlichen Konverter zwischen Ethernet und PCIe sind. Die Implementierung des Encapsulators auf solchen Geräten ermöglicht es daher, NFV sofort einsatzbereit zu machen - ohne unnötige Probleme mit PCIe und Schreibtreibern.
Von "privat" zu "allgemein" - Erstellen eines offenen Repositorys von Netzwerk-IP-Cores
Man kann der Tatsache nicht widersprechen, dass es heute viele spezialisierte Netzwerk-ASICs (zum Beispiel von Broadcom) gibt, die ein solches Projekt in eine andere Geschichte aus der Serie „Enjoying Working with FPGA“ übersetzen können. Skepsis ist in diesem Fall angebracht, ich möchte Sie jedoch daran erinnern, dass das Etherblade.net-Projekt nicht auf die Erstellung eines separaten Netzwerkgeräts beschränkt ist. Das Hauptziel von Etherblade.net ist es, ein offenes Repository von parametrisierten und dokumentierten IP-Cores zu erstellen.
Dieses Repository kann eine effektive Basis für die Erstellung einer ganzen Reihe von Netzwerkgeräten (einschließlich der exotischsten) sein, die wiederum sowohl auf dem FPGA als auch in Form eines ASIC implementiert werden können.
Auf das - ich beende. Im nächsten Artikel werden wir uns direkt mit dem Hardware-Design
befassen , aber jetzt lade ich Sie ein, sich mit dem Projekt näher bei
etherblade.net vertraut zu
machen .