SDN – aber bitte im Applikationslayer

Seit SDN zum Liebling der Netzwerkbranche geworden ist, gab es eine Menge Kopfnicken und ergänzende Bemerkungen darüber, das Services der Layer 4-7 letzten Endes Teil des Gesamt-Konstrukts werden. Allerdings gab es nicht viele Diskussionen über die Herausforderungen, mit denen man es zu tun bekommt, wenn man diese Services in ein Modell einbringt, das in der Praxis zum Standard geworden ist: ein zentraler Controller, der den Paketfluss im Netzwerk steuert.

Das ist eine große Herausforderung, denn wenn Sie den Netzwerkstapel nach oben befördern, kommt es zu einer natürlichen Evolution. Sie steuern keine Pakete mehr, sondern verwalten den Datenfluss und für das Management des Datenflusses gelten völlig andere Funktionalitäten. Das liegt daran, dass das Netzwerk zwangsläufig umso zustandsorientierter werden muss, je näher Sie dem Layer 7 kommen. Es kann keine einzelnen Pakete mehr bearbeiten, sondern muss diese Pakete sammeln, und das auch noch oft ‑ erheblich öfter, als bei der Bearbeitung der Layer 2 und 3 des Netzwerkstapel vorausgesetzt wird.

Stellen Sie sich vor: in einem Router muss 1 Paket von jeweils 1 Million Paketen an den Controller weitergeleitet werden. In einem Switch liegt dieses Verhältnis bei 1 zu 1 Milliarde. Bei TCP sinkt dieses Verhältnis auf lediglich 1 von jeweils 10 Paketen. Wenn Sie im Netzwerkstapel ein Stück höher in Layer 7 gehen, können Sie davon ausgehen, dass jedes Paket ein Kandidat für die Weiterleitung an den Controller ist.

Bei einem SDN-Modell, auf dem heutzutage die meisten Lösungen basieren, geht man davon aus, dass die meisten Pakete nicht vom Controller untersucht werden müssen. Daher können sie die Kabelgeschwindigkeit skalieren und aufrechterhalten, während den unteren Schichten des Netzwerks Flexibilität und Programmierbarkeit hinzugefügt wird.

Für SDN im Applikationslayer ist ein anderes Modell erforderlich, um sicherzustellen, dass Flexibilität und Performance beibehalten werden können, während gleichzeitig von den Vorteilen der Applikationsintelligenz und -programmierbarkeit profitiert wird. Die SDN-Netzwerk-Fabric (Layer 2-3) arbeitet unter der Voraussetzung einer zentralen Steuerung und Ausführung. Die SDN-Applikations-Services-Fabric (Layer 4-7) muss unter der Voraussetzung einer zentralen Steuerung und dezentralen Ausführung arbeiten, um skalieren zu können. Jedoch ohne die vielen Vorteile zustandsorientierter Netzwerkgeräte zu opfern, die aktuelle Modelle für Netzwerkarchitekturen bieten, beispielsweise sicherheitsrelevante Funktionen, Fehlertoleranz und -analyse und performancesteigernde Services.

Je ausgereifter SDN wird, desto mehr wird der Schwerpunkt darauf liegen, den Netzwerkstapel nach oben zu verschieben, hin zu den Applikationsschichten. Die programmierbaren, skalierbaren Services der Applikationsschicht, die die Applikations-Services-Fabric bilden, sind notwendig, um die Vorteile von SDN und softwaredefinierten Datenzentren nutzen zu können, insbesondere in Umgebungen, bei denen die Virtualisierung von Netzwerkfunktionen (Network Functions Virtualization, NFV) als Strategie für maximale Flexibilität verfolgt wird. NFV benötigt nicht nur die verbesserte Performance der heutigen modernen x86-Hardwareplattformen, sondern auch Software, die eine bedarfsorientierte Skalierung unterstützt, während gleichzeitig eine optimale Performance sichergestellt und ein hohes Maß an Programmierbarkeit für eine erstklassige softwaredefinierte Steuerung über das Netzwerk geboten wird.

Programmierbarkeit wird gebraucht, um durch Automatisierung und zentrale Steuerung Betriebskosten zu reduzieren, aber auch, um Kunden in die Lage zu versetzen, innovative, applikationsspezifische Services zu entwickeln, die in Übereinstimmung mit SDN-Architekturen arbeiten. Entscheidend für den Erfolg dieser Architekturen sind Sicherheit, Beschleunigung, Optimierung und Routing-Services auf der Ebene der Applikationsschichten, die moderne Erwartungen hinsichtlich Flexibilität, Skalierung und Performance erfüllen können. 

F5 macht SDN auf dem Applikationslayer mit einer programmierbaren, skalierbaren Plattform möglich. Die Plattform unterstützt nicht nur bedarfsorientierte Skalierung und erfüllt Performance-Erwartungen auf Standard-x86-Hardware, sondern ist darüber hinaus auch noch hochprogrammierbar. Genau genommen wurde sie ausdrücklich dafür entwickelt programmiert zu werden, um speziell entwickelte Geschäfts- und Betriebslogik in Hochgeschwindigkeit auszuführen. Die Architektur ist proxy-basiert, ähnlich wie die des Application Delivery Controllers von F5, der BIG-IP und bietet als Kernkompetenz etwas, das ich nur als “Extreme Programming” bezeichnen kann. Anstatt unmaßgebliche Regeln in die Datenebene einzufügen, wie dies bei SDN-Fabrics der Layer 2-3 üblich ist, fungieren die F5 SDN-Services als unabhängig arbeitende Service-Knoten, die die Skalierungseigenschaften gewährleisten, die von SDN-Lösungen und modernen, hochverfügbaren Architekturen erwartet werden. Das heißt, im Gegensatz zu der zentralen SND-Controller-Architektur ist ein dezentrales Ausführungsmodell sogar dann fehlertolerant, wenn der Status gehalten wird, ein Muss für die Applikations-Services-Fabric.

Während sich Netzwerke zunehmend zu einem Standardprodukt entwickeln, werden die Services für die Applikationslayer innerhalbt des SDNs einemUnternehmen den Wettbewerbsvorteil liefern, den diese brauchen. Unternehmen, die eigene Services auf den Markt bringen wollen, brauchen einen programmierbaren Datenpfad, der skalierbar und schnell sein muss, da sie zu Recht nicht bereit sind, Kompromisse bei der Performance einzugehen. F5 bietet eine solche Plattform und die Erweiterung des Produktportfolios von F5 um eben genau dieses Produkt, bekräftigt einmal mehr die führende Rolle von F5 im Bereich Networking in dem Applikationslayer für traditionelle und SDN-Applikationslayer Architekturen.

Published Jan 22, 2014
Version 1.0

Was this article helpful?

No CommentsBe the first to comment