SDN & OpenStack. Eine Einführung. Martin Gerhard Loschwitz hastexo Professional Services GmbH. All rights reserved.

Transkript

1 SDN & OpenStack Eine Einführung Martin Gerhard Loschwitz 2014 hastexo Professional Services GmbH. All rights reserved.

2 Wer?

3

4

5

6

7

8

9

10

11

12

13

14 Cloud Computing

15 Konventionelle Netze basieren auf einem statischen Design.

16 Erste Prämisse: Das Netzwerk ist zentral verwaltet.

17 Zweite Prämisse: Server gehören spezifischen Kunden

18

19

20 Dritte Prämisse: Wenig bis kein Bedarf für Scale-Out

21 Cloud Computing? Extrem skalierte Setups? Reality Check

22 Erste Prämisse: Das Netzwerk ist zentral verwaltet. Netzwerk-Management obliegt dem Kunden

23 Zweite Prämisse: Server gehören spezifischen Kunden Server hosten VMs. Die VMs jedes Kunden müssen auf jedem Server laufen.

24 Dritte Prämisse: Wenig bis kein Bedarf für Scale-Out In Clouds ist Scale-Out notwendig, und es muss einfach erreichbar sein.

25 Klassische Netzwerkdesigns bieten all diese Funktionen nicht oder nur auf Umwegen.

26 Erste Konsequenz: Bei Netzwerk-Equipment sind Hardware und Software voneinander zu trennen ( decouple )

27 Zweite Konsequenz: Die Cloud muss sich selbst um ihr Netzwerk kümmern.

28 Dritte Konsequenz: Die Cloud-Software muss wissen, wie sie das erreicht.

29

30 In Clouds begegnen uns zwei Arten von Traffic!

31 Traffic zwischen VMs des gleichen Kunden:

32 Traffic zwischen VMs und anderen Netzen:

33 Virtueller L2-Traffic

34 Open vswitch (+OpenFlow), VMware NSX, Midonet, OpenContrail, PLUMGrid

35 Open vswitch (+OpenFlow), VMware NSX, Midonet, OpenContrail, PLUMGrid

36 OpenFlow: Virtuelle Forwarding Plane auf jedem beteiligten Host

37 Open vswitch: Baut SDNs auf Basis von Open Flow, ist Front-End zur Konfiguration der Forwarding Plane

38 Open vswitch verwirklicht auch die Trennung von SDN- und Nicht-SDN-Traffic (GRE, VLAN, VXLAN)

39

40 Jede VM bekommt eine virtuelle NIC (TAP device)

41 Open vswitch verwaltet virtuelle Switches (Bridges), die den Weg von Paketen im LAN bestimmen.

42

43 Die TAP-Devices der VMs sind direkt mit den virtuellen Switches verbunden. Über OpenFlow-Regeln ist festgelegt, wohin Pakete in den virtuellen Switches gehen.

44

45

46

47 Bob: # ovs-vsctl show Bridge br-int "Port patch-tun " "Interface patch-tun " "options: {peer=patch-int} "Port "tape4dbc657-c4 " "tag: 1 " "Interface "tape4dbc657-c4 "Port br-int " "Interface br-int"

48 Bob (cont.): # ovs-vsctl show [ ] Bridge br-tun Port br-tun Interface br-tun Port patch-int Interface patch-int options: {peer=patch-tun} Port "gre-1" Interface "gre-1" options: {in_key=flow, local_ip=" ", \ out_key=flow, remote_ip=" "} "

49 Daisy: # ovs-ofctl dump-flows br-tun [ ] cookie=0x0, duration= s, table=10, \ n_packets=1537, n_bytes=359538, \ idle_age=25, priority=1 \ actions=[ ],output:1 "

50 Daisy (cont.): # ovs-ofctl show br-tun 1(patch-int): addr:76:7c:cb:84:54:f3 [...] 2(gre-2): addr:16:14:65:eb:26:8c [...] LOCAL(br-tun): addr:1e:5e:83:65:02:4e [...]

51 Daisy (cont.): # ovs-vsctl show Bridge br-tun [...] Port patch-int Interface patch-int options: {peer=patch-tun} [...] "

52 Daisy (cont.): # ovs-vsctl show [...] Bridge br-int Port "tap6dcc748c-17" tag: 1 [...] Port patch-tun options: {peer=patch-int} "

53 Traffic zwischen VMs und anderen Netzen:

54 VMs sollen im Hinblick auf Internet-Zugriff zentral verwaltbar sein. Dienste wie Firewalling, virtuelles Routing und LBaaS setzen das voraus.

55 Internet-Traffic nutzt Network Nodes zur Sicherstellung der zentralen Verwaltung.

56

57

58 Der Packet Flow zwischen den Network Nodes und den Hypervisor-Knoten funktioniert wie gehabt.

59

60 Auf auf den Network Nodes müssen Pakete von Kunden strikt getrennt bleiben.

61 Auf den Network Nodes kommen dazu Network Namespaces zum Einsatz.

62

63 Zur Erinnerung: SDN muss aus der Cloud-Umgebung heraus konfigurierbar sein.

64 Willkommen bei OpenStack Neutron

65 Modulares Design

66 Neutron Server

67 Neutron Plugins

68 Neutron Agents

69

70 Neutron Key Features

71 Virtuelle Layer2-Netzwerke auf dem Layer 3 mit echter Trennung von Kundenpaketen

72 Kunden bestimmen ihre Netzwerktopologie selbst

73 Nahtlos integrierter Internet-Zugriff für VMs (Layer 3-Networking)

74 Support für diverse SDN-Lösungen Open vswitch, VMware NSX, Ryu, Midonet

75 Support für Hardware-basierte Lösungen (über Plugins) Cisco, Juniper, Brocade, Mellanox

76 In OpenStack Icehouse: Verschiedene Plugins (Layer 2) zur gleichen Zeit

77 Konfiguration mittels eines intuitiven Webinterfaces (OpenStack Dashboard)

78

79 Firewall as a Service (FWaaS, seit OpenStack Havana)

80

81 Load Balancer as a Service (LBaaS, seit OpenStack Havana)

82

83 VPN as a Service (VPNaaS, seit OpenStack Havana)

84

85 Neutron integriert SDN nahtlos in eine OpenStack-Cloud

86 Herausforderungen

87 Wahl der richtigen SDN-Implementation

88 Hoher Lernaufwand, steile Lernkurve

89 Mit dem Netz muss sich die interne Organisation erheblich verändern

90