Virtualisierung / Software- Defined Networks

Transkript

1 Fakultät Informatik, Institut für Systemarchitektur, Professur Rechnernetze Rechnernetzpraxis Virtualisierung / Software- Defined Networks marius.feldmann@tu-dresden.de

2 Problemfall: Geswitchtes Netzwerk MAC- Adressfilterung Switch 1 Switch 2 Software (Control-Plane) Hardware (Data Plane) Software (Control-Plane) Hardware (Data-Plane) VLAN-Konfiguration Einsatz von STP zur Vermeidung von Zyklen Software (Control-Plane) Hardware (Data Plane) Software (Control-Plane) Hardware (Data-Plane) Switch 3 Switch 4 VLAN-Konfiguration Weitere Netzwerkinfrastruktur mit dezentral vorliegenden Kontrollinformationen zu Schicht 2, 3 und 4 Administratoren müssen eine Vielzahl von Protokollen und ihr Zusammenspiel beherrschen Konfiguration der verschiedenen Protokolle aufwendig und fehleranfällig Verteilt vorhandene Konfigurationen (abgelegt in der Control-Plane ) müssen konsistent sein Switches verfügen über keine globale Perspektive auf das gesamte Netzwerk z.b. keine globale Überlastbehandlung Keine Interaktion mit Konfigurationsinformation weiterer Schichten 2 Data-Plane teils in Literatur auch als Forwarding-Plane bezeichnet

3 Problemfall: Virtualisierung Physischer Knoten 1 VM 1 VM 2 VM 3 VM 4 VM 5 VM 6 VM 7 VM 8 Bridge/ Switch Physischer Knoten 2 Physischer Knoten 4 Physischer Knoten 3 Physischer Knoten 5 Technische Realisierung? eth0 Switch Switch speichert MAC-Adressen aller Virtuellen Maschinen (VMs) Skalierungsprobleme Falls zwischen VMs VLANs ausgebildet werden, müssen diese ohne technologische Erweiterungen von dem angebundenen Switch unterstützt werden Zudem existieren die im Zusammenhang mit physischer, geswitchter Infrastruktur erwähnten Probleme in besonderem Maße 3

4 Inhalte 1. Software-Defined Networks Übersicht Northbound / Southbound API 2. OpenFlow Übersicht Paketverarbeitung Protokolldetails 3. VxLAN 4. Unterstützung von SDN in Hardware oder Software 5. Open vswitch Übersicht Architektur Verwendung auf der Kommandozeile 4

5 Software-Defined Networking - Übersicht Anwendung 1 Anwendung 2 Anwendung 3 Switch 1 Switch 2 Hardware (Data-Plane) Anwendungsebene SDN-Controller (Control-Plane) Kontrollebene Hardware (Data-Plane) Weitere Netzwerkinfrastruktur mit dezentral vorliegenden Kontrollinformationen zu Schicht 2, 3 und 4 SDN ist ein Ansatz zur Realisierung von Computernetzen, bei dem die Kontrolle über die Datenflüsse und die eigentliche Weiterleitung auf zentral zugreifbare Netzknoten ausgelagert wird SDN Separation von Control- und Data-Plane Ansatz geht auf Arbeiten der UC Berkeley und Stanford University zurück Infrastrukturebene 5

6 Northbound / Southbound API s Anwendung 1 Anwendung 2 Anwendung 3 Anwendungsebene SDN-Controller (Control-Plane) Kontrollebene Hardware (Data-Plane) Netzwerkinfrastruktur Northbound API API für Anwendungen, die die Funktionalität des Controllers nutzen Beispielsweise Zugriff durch Firewalls Load-Balancer Southbound API API für den Zugriff auf die Funktionalität der Hardware Neben Zugriff durch fokussierte Anwendungen wird Northbound API durch umfassende Virtualisierungslösungen verwendet; beispielsweise Zugriff durch OpenStack Neutron Schnittstellen inklusive zugehöriger Protokolle für die beiden Interaktionspunkte sollen durch Standards wohldefiniert werden Beispielsweise: OpenFlow (Southbound API) 6

7 Open Networking Foundation (ONF) / OpenFlow Open Networking Foundation (ONF) is a user-driven organization dedicated to the promotion and adoption of Software-Defined Networking (SDN) through open standards development. Zahlreiche große Unternehmen sind Mitglieder der Organisation, u.a.: Facebook, Deutsche Telekom, Google, Yahoo! und Microsoft Aktiv seit dem Hauptaktivitäten: Spezifikation einer Referenzarchitektur für SDN Pflege und Verwaltung der Spezifikation von OpenFlow, einem Kommunikationsprotokoll samt Architektur- und Schnittstellenbeschreibung für die Separation von Data- und Control- Plane Controller OpenFlow- Protokoll Flow-Tabellen: Beschreiben, welche Instruktionen für welchen Flow ausgeführt werden sollen Group-Tabelle: Ermöglicht die Angabe von mehreren auszuführenden Regeln Meter-Tabelle: Ermöglichen die Spezifikation von durchzuführenden Messungen zur Umsetzung von QoS-Operationen OpenFlow Channel OpenFlow Switch Flow Table Flow Table Flow Table Group Table Meter Table 7

8 OpenFlow Flow-Tabelle Jede Flow-Tabelle enthält eine Menge von Einträgen mit fester Struktur: Abzugleichende Informationen Priorität Zähler Instruktionen Timeouts Cookie Abzugleichende Informationen: Charakteristika auf die hin das eingehende Paket untersucht wird Priorität: Ermöglicht Selektion eines Eintrags bei mehreren passenden Einträgen Zähler: Hält Information, wie häufig Eintrag angewendet wurde Timeouts: Maximale Zeit oder Inaktivitätszeit bevor der Eintrag vom Switch entfernt wird Cookie: Eindeutiger Identifikator, der vom Controller zu Referenzzwecken verwendet wird Mögliche Instruktionen (= bestimmen Vorgehen bei der Auswertung des Pakets): enum ofp_instruction_type { OFPIT_GOTO_TABLE = 1, /* Gehe zur nächsten Tabelle in der Pipeline */ OFPIT_WRITE_METADATA = 2, /* Fülle das Metadaten-Feld für die nächste Tabelle */ OFPIT_WRITE_ACTIONS = 3, /* Schreibe eine Aktion / Aktionen in die Aktionsmenge */ OFPIT_APPLY_ACTIONS = 4, /* Wende die Aktionen sofort an */ OFPIT_CLEAR_ACTIONS = 5, /* Lösche die Aktionsmenge */ OFPIT_METER = 6, /* Wende einen Meter für z.b. Limitierung der Datenrate an */ OFPIT_EXPERIMENTER = 0xFFFF /* Für experimentelle Instruktionen */ }; Siehe S. 60 f. der OpenFlow-Spezifikation 8

9 OpenFlow - Paketverarbeitung Charakteristika von eingehenden Paketen werden mit Einträgen einer Flow-Tabelle abgeglichen und die zugehörigen Instruktionen bei erfolgreichem Abgleich angewendet Als Instruktion bei einem Match mit einem Eintrag kann das Paket zur weiteren Verarbeitung an eine weitere Tabelle übergeben werden, für deren Einträge ebenfalls ein sequentieller Abgleich erfolgt Pipeline-Verarbeitung Falls es keinen Match eines Pakets mit den Regeln einer Tabelle gibt, wird ein für diesen Fall vordefinierter Eintrag selektiert ( table-miss flow entry ); z.b. Optionen: Verwerfen des Pakets Weiterleitung an eine andere Tabelle Senden des Pakets an den Controller Aktionen bestimmen, was mit dem Paket gemacht werden soll (z.b. Weiterleitung) Eingehende Pakete Tabelle 0 Tabelle 1 Tabelle n Ausführung der Aktionen Ausgehende Pakete OpenFlowSwitch Optional, abhängig von selektierter Anweisung der vorherigen Tabelle Details siehe siehe OpenFlow-Spezifikation S. 14 ff. 9

10 OpenFlow - Paketverarbeitung Paket eingehend Beginne bei Tabelle 0 ja Match in Tabelle n? ja Aktualisiere Zähler Führe Instruktionen aus Sprung zu weiterer Tabelle? nein Existiert miss flow entry? ja Instruktionen: z.b. Aktualisierung der Aktionsmenge nein Führe gesammelte Menge von Aktionen aus nein Verwerfe Paket Für den Abgleich mit Tabelleneinträgen kann der Ingress-Port, die von einer vorherigen Tabelle dem Paket zugeordneten Metadaten und der Paketheader verwendet werden Pro Tabelle wird nur ein Eintrag (Eintrag mit höchster Priorität) selektiert Details siehe siehe OpenFlow-Spezifikation S. 16 ff. 10

11 OpenFlow - Protokoll OpenFlow- Switch Aufbau TCP-/TLS-Verbindung OpenFlow- Controller OFPT_HELLO OFPT_HELLO OpenFlow-Channel etabliert OFPT_FEATURES_REQUEST OFPT_FEATURES_REPLY... OFPT_ECHO_REQUEST OFPT_ECHO_REPLY Hello-Nachricht beinhaltet vom Sender maximal unterstützte OpenFlow-Version Controller ermittelt den Funktionsumfang des Switches und eine eindeutige ID (u.a. bestehend aus MAC-Adresse) für den durch den Switch bereitgestellten Data Path Lebendigkeit des Kanals wird über Echo-Request/-Reply- Nachrichten überprüft Bevor OpenFlow-Nachrichten ausgetauscht werden, wird ein OpenFlow- Channel etabliert Jeder Switch kann einen Channel zu mehreren Controllern aufbauen (z.b. zur Steigerung der Zuverlässigkeit) Bei mehreren Controllern kann einer der Controller als Master fungieren, dessen Anweisungen die höchste Priorität aufweisen 11

12 OpenFlow - Protokoll Nach Etablierung des Channels können Nachrichten aus drei verschiedenen Klassen ausgetauscht werden 1 Controller-zu- Switch-Nachrichten Vom Controller initiierte Nachrichten Beispiele: Ermittlung des Funktionsumfangs eines Switches Hinzufügen/Entfernen/Modifizieren von Einträgen der Flow-Tabelle 2 Asynchrone Nachrichten Nachrichten werden ohne vorherige Anfrage des Controllers vom Switch an den Controller gesendet Beispiele: Packet-In-Nachricht, kann bei Ankunft eines Pakets versendet werden Flow-Removed-Nachricht: Ein Eintrag wurde aus der Flow-Tabelle entfernt 3 Symmetrische Nachrichten Ohne Anfrage von einer der beiden Seiten versendet Realisieren überwiegend Hilfsfunktionalitäten Beispiele: Hello-Nachricht für die Etablierung des Channels Fehlermeldungen EchoRequest-/EchoReply-Nachrichten Für Details siehe Kapitel 7 ( The OpenFlow Protocol ) der Open-Flow-Spezifikation 12

13 OpenFlow Nachrichtenbeispiel Auslöser für Packet-In- Nachricht (z.b. kein Match in Flow-Tabellen für ein Paket) OpenFlow- Switch OpenFlow-Channel etabliert OFPT_PACKET_IN OFPT_PACKET_OUT... OpenFlow- Controller Controller erhält in Nachricht neben Ursache der Nachricht (z.b. OFPR_TABLE_MISS, OFPR_INVALID_TTL) Teile des betreffenden Pakets oder das gesamte Paket Controller entscheidet über Aktion für das Paket und weist den Switch an, das Paket über einen bestimmten Port weiterzuleiten Interaktion mittels Packet-In- und Packet-Out-Nachricht verdeutlicht die detaillierte Kontrolle, die der Controller über die Abläufe im Netzwerk besitzt Packet-Out-Nachricht gibt Buffer-ID an, die in Packet-In-Nachricht als Referenz in Paketspeicher des Switches angegeben wurde oder inkludiert das gesamte weiterzuleitende Paket Neben Angabe eines ausgehenden Ports können Header-Elemente des Pakets (z.b. IP-Quelladresse) verändert werden 13

14 VxLAN - Übersicht Virtual Extensible LAN (VxLAN) zielt auf die Beseitigung von Skalierbarkeitsproblemen in großen virtualisierten Infrastrukturen Spezifikation ist als informational RFC verfügbar (RFC 7348) Grundprinzip: Schicht-2-Daten werden über ein Schicht-3-Netz nur an diejenigen physischen Knoten übermittelt, die Mitglied eines Schicht-2-Overlay- Netzes (=VxLAN Segments) sind Dazu: Kapselung von Ethernet-Frames in UDP-Pakete, die einen eindeutigen Identifier (VNI) des VxLAN-Segments enthalten Physische Maschine ursprünglich von VM versendeter Frame; beinhaltet Nutzdaten beinhaltet VNI an VxLAN-Port adressiert Virtuelle Maschine VTEP Ethernet- Frame VxLAN- Header UDP- Header IP- Header Ethernet- Header Verwendung von VxLAN ist transparent für VM Datenstrom Virtual Tunnel End-Point kapselt Frame und ergänzt VxLAN Network Identifier (VNI), der den Gültigkeitsbereich eines VLANs definiert ( MAC-Adressen / VLANs müssen nur pro VNI eindeutig sein) 14

15 VxLAN VMs befinden sich im gleichen IP-Subnetz Physische Maschine Physische Maschine Virtuelle Maschine 1 1 VTEP Physischer 2 Switch 3 VTEP 4 Virtuelle Maschine Mitglieder von IP-Multicastadressen für die VNIs der lokalen VMs Virtuelle Maschine 1 sendet ARP-Broadcast, da sich das Ziel (Virtuelle Maschine 2) im selben IP-Subnetz befindet Der VTEP ergänzt den zu der VM gehörigen VXLAN VNI und sendet den Frame an eine für den VNI verfügbare IP-Multicastadresse; das Paket wird mittels UDP an den VxLAN-Port (gemäß IANA: 4789) adressiert VTEP der physischen Maschine, die die adressierte VM ausführt, nimmt UDP-Paket entgegen und entfernt die ergänzten Header, so dass nur das ursprüngliche Ethernet-Frame bleibt VTEP speichert eine Abbildung der Quell-MAC-Adresse des gekapselten Ethernet-Frames und der Quell-IP-Adresse des kapselnden IP-Headers Antwort an MAC-Adresse kann mittels IP-Unicast realisiert werden 4 Ethernet-Frame wird transparent an diejenigen VMs, die Mitglied des adressierten VxLAN-Segments sind, weitergeleitet 15

16 VxLAN Implementierungen verwenden für IPv4-Multicast-Gruppenverwaltung Internet Group Management Protocol (IGMP) IPv6-Multicast: Multicast Listener Discovery (MLD) VxLAN-Header besteht im Wesentlich aus einem 24-Bit-Feld für den VNI 4. Bit = 1, ansonsten reserviert für zukünftige Verwendung 0 31 Flags Reserved Virtual Network Identifier Reserved struct vxlanhdr { be32 vx_flags; be32 vx_vni; }; Struktur aus Linux-Kernel (include/net/vxlan.h) 16

17 Realisierung von SDN-Switches in Hardware oder Software Aktuell wird Positionierung einer SDN-Layer debattiert, wobei zwei fundamentale Optionen existieren: Verlagerung auf die Hardware Verlagerung auf die Software Untersuchungsergebnisse für Kommunikation zu einer lokalen VM mittels Software-Switch (durchgehende Linie) und vorgelagertem Hardware- Switch (gestrichelte Linie) Aus: 17

18 Open vswitch In Software realisierter, unter Apache- Lizenz stehender Multi-Layer-Switch Implementierungsfokus: Linux Unterstützt große Zahl an Standards und Funktionalitäten, u.a.: STP (IEEE 802.1D-1998) Bonding / IEEE 802.3ad sflow / NetFlow / IPFIX IPv6-Unterstützung VLANs nach IEEE 802.1Q OpenFlow eth0 Open vswitch vm1 vm2 vm3 Implementierung umfasst ein Kernelmodul, Daemonen-Programme und Kommandozeilenwerkzeuge für Konfigurations- und Monitoringzwecke Ausgewählte Werkzeuge: ovs vsctl: Werkzeug zur Statusabfrage und Konfiguration des OpenvSwitch-Daemons ovs dpctl: Werkzeug zur Konfiguration von Daten-Pfaden ( data paths ; vergleichbar zu den Konzepten von OpenFlow) ovs controller: Implementierung eines OpenFlow-Controllers ovs vlan test: Werkzeug zur Problemanalyse bei VLANs ovsdb-tool: Ermöglicht Zugriff auf die Open vswitch Datenbank 18 ovs ofctl: Ermöglicht Interaktion mittels OpenFlow-Protokoll mit Switch

19 Open vswitch - Übersicht zur Architektur OpenFlow-Werkzeug (z.b. ovs-ofctl) Sflow- Werkzeug Entferntes System ovs-vsctl ovsdb-client ovsdb-tool speichern ovs-vswitchd ovsdb-server ovsdb anwenden netlink User-Space Kernel-Space Open-vSwitch-Kernel-Modul Netzwerkstack und Netzwerkschnittstellen netlink: IPC-Mechanismus für die Kommunikation zwischen Kernel- und User-Space (siehe auch RFC 3549) Für Implementierungsdetails siehe: 19

20 Open vswitch Beispiel: Ausgabe von ovsdb-tool show-log m, nachdem: 1. mit ovs-vsctl add-br br0 eine Bridge angelegt wurde 2. mit ovs-vsctl add-port br0 eth0 die Bridge mit eth0 verbunden wurde #ovsdb-tool show-log -m record 0: "Open_vSwitch" schema, version="7.3.0", cksum=" " record 1: :21: "ovs-vsctl: ovs-vsctl --no-wait init" table Open_vSwitch insert row 6aef7b99: record 2: :23: "ovs-vsctl: ovs-vsctl add-br br0" table Port insert row "br0" (5d421d22): table Interface insert row "br0" (a40faf68): table Bridge insert row "br0" (0da81efb): table Open_vSwitch row 6aef7b99 (6aef7b99): record 3: :23: table Interface row "br0" (a40faf68): table Open_vSwitch row 6aef7b99 (6aef7b99): record 4: :23: "ovs-vsctl: ovs-vsctl add-port br0 eth0" table Port insert row "eth0" (5721baea): table Interface insert row "eth0" (22564baa): table Bridge row "br0" (0da81efb): table Open_vSwitch row 6aef7b99 (6aef7b99): record 5: :23: table Interface row "eth0" (22564baa): table Open_vSwitch row 6aef7b99 (6aef7b99): 20

21 Open vswitch Mit ovs-ofctl kann per OpenFlow mit dem Switch interagiert werden, um z.b. Informationen abzufragen Vergleiche für die unten angegebenen Felder der OFPT_FEATURES_REPLY- Nachricht Kapitel ( Handshake ) der Open-vSwitch-Spezifikation #sudo ovs-ofctl show br0 OFPT_FEATURES_REPLY (xid=0x2): dpid: e43ca n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE 1(eth0): addr:00:22:68:0e:43:ca config: 0 state: LINK_DOWN current: COPPER AUTO_NEG advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG supported: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG speed: 0 Mbps now, 1000 Mbps max LOCAL(br0): addr:00:22:68:0e:43:ca config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 21

22 Zusammenfassung Anwendung 1 Anwendung 2 Anwendung 3 Switch 1 Switch 2 Hardware / Software (Data-Plane) Anwendungsebene SDN-Controller (Control-Plane) Kontrollebene Hardware / Software (Data-Plane) Northbound API API für Anwendungen, die die Funktionalität des Controllers nutzen Beispielsweise Zugriff durch Firewalls Load-Balancer Southbound API API für den Zugriff auf die Funktionalität der Hardware Weitere Netzwerkinfrastruktur mit dezentral vorliegenden Kontrollinformationen zu Schicht 2, 3 und 4 Infrastrukturebene Virtual Extensible LAN (VxLAN) zielt auf die Beseitigung von Skalierbarkeitsproblemen in großen virtualisierten Infrastrukturen Open vswitch = in Software realisierter, unter Apache-Lizenz stehender Multi-Layer-Software-Switch Verwendung von OpenFlow, beispielsweise umgesetzt durch Open vswitch 22

23 Literatur / Quellen OpenFlow-Spezifikation (Version 1.4.0): Veröffentlichung zur Verwendung von Edge-Switches : Open Networking Foundation: Ressourcen zu Open vswitch: RFC der VxLAN-Spezifikation: 23