Das Zauberwort heißt Entkopplung
Typische Netzwerkkomponenten wie Switches bestehen aus mehreren Teilen. Die Data Plane ist dafür verantwortlich, Pakete von einem Switch-Port hin zu einem anderen zuzustellen. Die Management-Fähigkeiten leistet hingegen die Control Plane. SDN basiert auf der Idee, die beiden Komponenten - Data und Control Plane - voneinander zu trennen: Switches liefern noch immer Pakete von einem Port zu einem anderen, doch die Control Plane und sämtliche zu ihr gehörende Funktionalität ist separiert von der Netzwerkhardware. Um das Ziel zu erreichen, teilen praktisch alle gängigen Lösungen am Markt das Netz in zwei Schichten auf: das Underlay und das Overlay.
Das Underlay bilden zusammen alle Hosts, die innerhalb des SDN-Setups einen Dienst betreiben (auch eine virtuelle Maschine gilt als solcher Dienst). Im Hintergrund sind die beteiligten Hosts mittels einer Tunnel-Technologie zu einem logischen Netzwerk-Segment verbunden, GRE (die Abkürzung steht für Generic Routing Encapsulation, also ein Tunnel-Protokoll) oder VXLAN (Virtual Extensible LAN, eine Weiterentwicklung des VLAN-Konzepts) sind hier Mittel der Wahl.
Auf dem Underlay basiert das Overlay: Innerhalb des Overlays sorgt die gewählte SDN-Lösung dafür, dass die Trennung zwischen den Kunden funktioniert, dass Pakete den Weg von einer VM zu einer anderen VM (auch auf einem anderen Hypervisor) finden und dass Dienste wie das Kommunikationsprotokoll DHCP und Internet in den VMs verfügbar sind. Kunden-VMs sind mit einer virtuellen Bridge im Overlay verbunden. Und weil praktisch alle SDN-Lösungen das Overlay komplett selbst verwalten, sind in ihm beliebige Konfigurationen möglich. Die physischen Switches sind in solchen Setups zu bloßen Data Planes degradiert, die Control Plane lebt im Overlay der SDN-Lösung.
Anforderungen auf der Software-Seite
Um den gewünschten Zustand zu erreichen, kombinieren marktübliche SDNs eine Vielzahl verschiedener Technologien. Die Wichtigste ist Open Flow, ein Standard für in Software implementierte Control Planes. Von Open Flow gibt es verschiedene Versionen, die Version 1.0 ist aber bis heute die mit der weitesten Verbreitung.
Allerdings ist Open Flow tatsächlich nur ein Standard, eine konkrete Implementierung ist in diesem nicht enthalten. Theoretisch wäre es also möglich, die Control Planes in Netzwerk-Switches per Open Flow zu steuern - doch entsprechende Geräte sind äußerst rar. Open vSwitch springt auf Linux-Systemen als Alternative ein: Neben diversen anderen Standards implementiert Open vSwitch vorrangig Open Flow 1.0 nebst diversen Erweiterungen auf marktüblicher Server-Hardware.
Die Abkürzung vSwitch steht für Virtual Switch: Auf Systemen, auf denen Open vSwitch zum Einsatz kommt, entstehen also virtuelle Switches mit eigener Control Plane. Sie hängen einerseits am physischen Interface, über das von anderen Hosts via GRE- oder VXLAN-Tunnel Pakete eingehen. Auf der anderen Seite docken die virtuellen Netzwerkkarten von VMs an diesen Switches an, um eingehende Pakete anderer Hosts zu empfangen. Im Underlay findet sowohl bei GRE als auch bei VXLAN ein Tagging statt, das klassischen VLAN-Tags ähnlich ist - allerdings heißen diese bei Open vSwitch IDs.
Im virtuellen Switch ist für jeden Port hinterlegt, zu welcher ID er gehört. Kommt also aus dem GRE- oder VXLAN-Tunnel ein Paket für die ID 15, leitet der Open-vSwitch-Switch auf dem Host das Paket nur an jene virtuellen Hosts weiter, deren Ports diese ID haben. In die andere Richtung funktioniert das Konzept auch: Das Paket einer VM, deren Port die ID 23 hat, bekommt von Open vSwitch die Tunnel-ID mit auf den Weg und geht dann durch das Underlay zum Ziel.
Auf diese Weise ist die Trennung auf Netzwerk-Ebene implementiert, die sonst per VLAN auf den Switches umgesetzt wäre. Tatsächlich bietet Open vSwitch das absolute Basis-Set an Funktionalität, um die typischen Cloud-Dienstleistungen zu realisieren.
Open vSwitch ist in Linux übrigens ein eigenes Kernel-Modul, das bereits im Upstream-Kernel enthalten ist. Jede halbwegs aktuelle Linux-Distribution ist deshalb in der Lage, Teil eines auf Open vSwitch basierten SDNs zu werden.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Cloud-Computing: Was ist eigentlich Software Defined Networking? | Am konkreten Beispiel: Openstack |
Lol Hetzner :) naja billig issa Ansonsten kann man auch mal bei Rackspace und consorten...
OP wünscht sich einen Stillstand in der Entwicklung damit er mit seinem begrenztem Wissen...
der gute arbeitet, wie sehr gut sichtbar unten bei syseleven ist daher selber...