Skalierbare virtuelle Netz-Testbeds für Lehr- und Forschungsumgebungen mit VIRL

Transkript

1 Skalierbare virtuelle Netz-Testbeds für Lehr- und Forschungsumgebungen mit VIRL 10. DFN-Forum Kommunikationstechnologien, 2017, Berlin Sebastian Rieger, Hochschule Fulda, Fachbereich Angewandte Informatik

2 Agenda Problemstellung Vor- und Nachteile von Netz-Emulatoren Virtual Internet Routing Lab (VIRL) Beispiele für virtuelle Netz-Topologien Herausforderungen in Bezug auf die Skalierung Evaluation Fazit und Ausblick 2

3 Netzwerk-Labor NetLab an der Hochschule Fulda 3

4 Netzwerk-Labor NetLab an der Hochschule Fulda 4

5 Problemstellung Praxisnahe Übungen/Praktika, Forschungsprojekte im Bereich Netztechnologien und -dienste Verschiedene Hard- und Softwarelösungen für Netz-Testbeds im Einsatz Zunehmende Praxisnähe: großer Aufwand/Komplexität, Fokus auf Theorie: zunehmend abstrakt Weitere Aspekte: z.b. Eignung für Lehre (Skalierbarkeit, Collaboration/E-Learning, Vor- /Nachbereitung) Mittelweg: Virtuelle Testbeds (vgl. weitere Paper DFN-Forum 2016/2017) und Emulation von Netzen 5

6 Vor-/Nachteile von Netz-Emulatoren Vorteile der Emulation Vgl. z.b. Paper aus Forschungsgruppe um Nick McKeown zu mininet (siehe Table 1 rechts) Integration reale Netze/Tools/Images, geringe Vor-/Nachbereitungszeit bei Übungen vgl. mit virtuellen oder physikalischen Testbeds Nachteile der Emulation Virtuelle Images von realen Netzkomponenten brauchen viele Ressourcen (RAM, CPU) Teilweise höhere Komplexität (Verwendung und Administration) Trade-off: Ressourcen vs. Praxisnähe 6

7 Verwendete Netz-Emulatoren im NetLab Verschiedene Software-Lösungen für Netz-Emulation getestet bzw. noch im Einsatz: Enterprise Network Simulation Platform (ensp): primär auf Huawei Komponenten ausgerichtet IOS on Unix (IOU): nur Cisco-intern verfügbar Emulated Virtual Environment Next Generation (EVE-NG): Alpha-Status mininet: primärer Fokus SDN, Netz-Konfiguration über Python API, keine VMs/Images Graphical Network Simulator 3 (GNS3): interessante Alternative, Marketplace, OpenSource bieten keinen Cluster/Load Balancing, scale-out und zentrale Administration eingeschränkt teilweise Collaboration-Funktionen und verfügbare Images ebenfalls eingeschränkt 7

8 Verwendete Netz-Emulatoren im NetLab (2) Seit 2015 im Test - Virtual Internet Routing Lab (VIRL) von Cisco (Version ) Netz-Virtualisierungs- und Orchestrierungsplattform Lokale Installation oder zentral bzw. VIRL Cluster (bietet scale-out) Automatische Konfiguration für Netz-Design (AutoNetKit) Integration reale Netze (Layer-2 flat, NAT), OpenVPN in virtuelle Testbeds, reale Geräte-Konfigs Cisco Images IOS, IOS Layer-2, IOS XE/XR, NX-OS, ASA, 3rd Party: Arista, Juniper, FortiNet, Cumulus Open Source als Basis: Ubuntu, OpenStack, KVM und LXC, linux-bridge (VXLAN) Eclipse-basierter Client (frei, auch von zu Hause für Studierende nutzbar), Web-Interface, REST-API Nachteile: Lizenz (in den letzten Jahren freie F&L-Lizenz), geplant max. 20 Cisco Nodes Einzelplatzlizenz, Weiterentwicklung bzgl. Cisco Modeling Labs (CML) 8

9 Beispiele für verwendete Topologien im NetLab a) 4 Arista veos diamond shape Virtuelle Version von Arista EOS, fast alle Layer-2/3/Management Features Spanning Tree Protocol (STP) Link-Aggragation (LACP) Multi-Chassis Link Aggregation (MLAG) b) Leaf-Spine Architektur (2 Spines, 4 Leaves) BGP Fabric (IOSv, NX-OSv), Equal Cost Multi-Path (ECMP) Linux Container (LXC) mit iperf Verwendung regulärer IOS und Linux Commands Wireshark für Traffic Capture Nodes/Links up/down setzbar, QoS Emulation (Delay, Loss, ) 9

10 Beispiele für verwendete Topologien im NetLab c) SDN Topologie OpenDaylight Controller, Definition von Flow für client und server Arista veos OpenFlow Switch d) Beispiel für einfachere Topologie im Bachelor Troubleshooting (u.a. ping, traceroute/mtr, Wireshark) Fehler z.b.: ARP, Routing/Switching, Delay/Packet Loss, Port Status Zugriff auf Server B (Ubuntu mit Apache) aus Lab (OpenVPN) ISP nutzt WAN-Emulation, bindet Topology per NAT an Internet an Alle Topologien per Git bereitgestellt, Zugriff in VIRL integriert Weitere Images in VIRL: Docker, kali, ostinato, vyatta, 10

11 Herausforderungen Teaching/Collaboration Komplexität für Verwendung und Administration Kann durch zentrale Bereitstellung/Vorkonfiguration und Tutorials abgefedert werden Skalierbarkeit Topologien brauchen aufgrund realitätsnaher VMs mehrere Minuten für Start (Simulator/mininet braucht nur wenige Sekunden, aber geringerer Funktionsumfang) Hohe Anforderung an Ressourcen (z.b. 1-2 GB RAM, 1-2 vcpu Cores pro Node in Topologie) VIRL Benchmarking und Perfomance-Optimierung Cluster aus 4x VIRL Host, 64 GB RAM, 32 vcpus als VM in VMware vsphere 6.5 (nested virtualization) Test: Paralleler Start von mehreren Topologien mit 4 Arista veos Nodes per REST-API 11

12 Evaluation 2-Node Cluster Topologie 4x Arista veos (8 GB RAM, 4 vcpus pro Topologie) Paralleler Start mehrerer Topologien über VIRL REST-API Automatisierter Test/Python-Skript, Mittelwert aus 10 Tests Start Time: Zeitpunkt nachdem REST-API Start quittiert hat Active Time: VMs für Arista veos starten (KVM) Usable Time: alle Topologien und darin enthaltene Experimente laufen, Konsole aller virtuellen Nodes nutzbar Startzeit 4 Arista veos Topologie 2-Node Cluster 12

13 Evaluation 4-Node Cluster und Optimierung von OpenStack Konfiguration 4-Node Cluster erlaubt >10 parallele Topologien, ca. 45 sec weniger bei 10 vgl. mit 2-Node Cluster Rechts: manuelle Erhöhung Worker Processes OpenStack (Nova, Neutron) zus. ca. 90 sec weniger 13

14 Diskussion, Grenzen und Alternativen Cluster Größe erlaubt erwartungsgemäß größere/mehr Topologien SSD/ramdisk von Cisco empfohlen, im Test bei <20 Topologien jedoch kaum relevant, da Images eh im Cache, Verlust an RAM kritischer Bei < 10 Topologien in Evaluation leichter Zuwachs von Usable Time (Scheduling, Management in VIRL und OpenStack), darüber >20% Reduktion möglich Optimierung Worker Prozesse Neutron (Anlegung virtueller Netze) und Nova (Virtuelle Maschinen) bringt ~11% Reduktion (z.b. 1 Neutron-Server in VIRL standard, erhöht auf 10) OpenStack/VIRL Overhead hat massiven Einfluss, braucht selbst viele Ressourcen, weitere Optimierung möglich 14

15 Fazit und Ausblick Zukunft VIRL Probleme Lizenz, akademische Lizenz (79 /Jahr) seit gestrichen, Umstieg Cisco Modeling Labs unattraktiv, Lösung ggf.: Einzellizenz (199 /Jahr max. 20 Cisco Nodes, beliebig viele Arista etc.) Weiterentwicklung stockt seit Oktober?, Strategie-Wechsel bei Cisco? Alternative: GNS3 (seit 5/2017 Version 2.0, viele Verbesserungen), EVE-NG, Großes Potenzial, GNS3 zudem bereits einige Vorteile zu VIRL, aber kein scale-out inkl. Lastverteilung Im Bereich SDN bleibt mininet die primäre Alternative Ausblick auf weitere Entwicklung und Lösung im NetLab VIRL Scheduler für automatisches Starten vor Lehrveranstaltung, ggf. Erweiterung GNS3 etc. Weitere Performance-Steigerungen: Kernel Samepage Merging (KSM), Optimierung OpenStack Konfig Tools (Benchmark, Scheduler), Topologien: Vielen Dank für die Aufmerksamkeit! Gibt es Fragen? 15