IT-Markt - Fachartikel
Software Defined Networking in der Cloud.
Von der virtuellen Maschine zum virtuellen Rechenzentrum.
Seit einigen Jahren ist es möglich gesamte IT-Umgebungen zu virtualisieren. Wie profitiert man davon wie auch von kommerziellen Vorteilen der geteilten Hardware-Nutzung?
Von der virtuellen Maschine zum virtuellen Rechenzentrum.
Wollte man früher eine Applikation in der Cloud laufen lassen, standen einzelne virtuelle Maschinen (VM) bei Hosting Providern zur Verfügung. Diese VM waren mit einer öffentlichen IP-Adresse direkt an das Internet angeschlossen. Der Administrator musste sich im Betriebssystem einer VM selbst um deren Sicherheit kümmern.
Danach kamen erste Angebote für ganze virtuelle Rechenzentren (VDC). Ein VDC ist viel mehr als eine einzelne virtuelle Maschine. Es ist vergleichbar mit einem physischen Datacenter, worin beliebig viele VM hochgefahren werden können. Zusätzlich können virtuelle Netzwerke (SDN) abgebildet werden. Es war also plötzlich möglich, gesamte IT-Umgebungen zu virtualisieren und von den kommerziellen Vorteilen der geteilten Hardware-Nutzung zu profitieren.
Die Challenge der physischen Welt.
Schon als die ersten Hypervisors reif wurden, konnten virtuelle Netzwerke eingesetzt werden. Virtuelle Maschinen haben schon sehr früh über abgeschottete, private Netzwerke kommuniziert, was sehr praktisch war. Selbstverständlich wuchs gleichzeitig der Bedarf, diese privaten Netzwerke unter den verschiedenen Computern, die auf dem Hypervisor betrieben wurden, aufzuteilen.
Eine virtuelle Maschine auf Host A musste mit einer VM auf Host B kommunizieren können und zwar so sicher und privat wie auf einem einzelnen Host. Die Hosts waren physisch via Switches miteinander verbunden. Dementsprechend mussten diese die notwendige "Privatsphäre" einzelner, virtueller Netzwerke unterstützen. Jahrelang war die einzige Möglichkeit, diesem Bedürfnis nachzukommen, sogenannte VLAN auf Ethernet-Switches zu konfigurieren. Ein virtuelles Netzwerk im Hypervisor entsprach einem VLAN auf dem Switch.
Klingt einfach und ist es auch, sofern man von einer kleinen Umgebung mit einer geringen Anzahl Netzwerke spricht. Wird jedoch eine grössere Umgebung betrieben, rückt die Herausforderung der Skalierbarkeit und des Verwaltungsaufwandes sehr schnell in den Vordergrund. In sehr vielen Unternehmungen werden Ethernet-Switches und Hypervisors von verschiedenen Teams betrieben. Soll das Hosting-Team ein neues, virtuelles Netzwerk in Betrieb nehmen, muss das entsprechende VLAN beim Netzwerkteam bestellt werden, was einige Zeit in Anspruch nehmen kann. Zudem ist die VLAN-Technologie schon veraltet und entspricht nicht mehr den heutigen Bedürfnissen einer modernen Cloud-Plattform. Allein die maximale Anzahl VLAN auf einem einzelnen Switch (4096) wird zu einem Problem. Auch die Verwaltung und die Konfiguration der einzelnen VLAN ist ohne Automatisierung fehleranfällig und zeitintensiv.
Wer kennt das nicht: Wird ein VLAN nicht mehr benötigt, wird es häufig nicht gelöscht. Dafür gibt es verschiedene Gründe wie unter anderem eine unklare Dokumentation, mangelnde Kommunikation zwischen den Teams, zu wenig Zeit sowie den Stressfaktor.
Die Challenge des Self-Service.
Wenn es heute darum geht, Infrastruktur zu konsumieren, werden häufig Ressourcen bei Cloud-Providern gemietet, anstatt selber Server-Farms und schnelle Netzwerke zu bauen. Diese werden als IaaS (Infrastructure as a Service) Provider bezeichnet, da sie die Grundinfrastruktur anbieten. Darunter fallen Server, Netzwerke und Storage. In vielen Fällen möchte ein IaaS-Kunde selber auf die Infrastruktur einwirken können, neue VM hochfahren, verschiedene Storage-Tiers damit verknüpfen und auch neue Netzwerke konfigurieren, um diese VM auf private Art und Weise miteinander kommunizieren zu lassen. Spätestens hier stellt man fest, dass der Einsatz von VLAN und die dezentrale Verwaltung der Switches nicht mehr funktionieren. Der Kunde muss per Maus-Klick virtuelle Netzwerke anlegen können, welche über die ganz grossen Netzwerke und Server-Pools automatisch und zeitnah provisioniert werden. Da kommt die Software ins Spiel, ohne welche dies nicht funktioniert. Alles muss automatisiert werden. Alte Technologien wie VLAN müssen mit moderneren ersetzt werden.
Software Defined Networking (SDN).
SDN-Plattformen erlauben die programmatische Konfiguration von Netzwerkdiensten. D.h. eine Software kümmert sich um die Provisionierung wie auch um die Deprovisionierung von Netzwerkkomponenten. Es braucht keine Administratoren mehr dafür. Somit werden u.a. Cloud-Umgebungen, Netzwerk-Fabriken, Cores und Router zentral und automatisch konfiguriert. Die Inbetriebnahme neuer Dienste verläuft schnell und fehlerfrei. Die Administratoren können sich um die Weiterentwicklung der Plattformen kümmern, anstatt repetitiv Konfigurationsänderungen vorzunehmen.
SDN-Lösungen verfolgen das Ziel, neben der Automatisierung auch die Vielfalt der darunterliegenden Technologien hersteller-unabhängig zu reduzieren. Es soll keine Rolle mehr spielen, welcher Hypervisor, welche Ethernet-Fabrik und welcher Router im Einsatz sind. Jede SDN-Lösung hat jedoch Grenzen und Spezialitäten, daher ist die Auswahl der richtigen SDN-Plattform sehr anspruchsvoll.
Virtuelle Netzwerkfunktionen (NFV).
Die virtuellen Netzwerkfunktionen sind mit denen der physischen Welt identisch: irewalls, NAT Gateways, DHCP-Server, VPN Gateways, Router u.v.m. Mit der Virtualisierung dieser Funktionen ist gemeint, diese virtuell, vollständig zentralisiert und automatisch konfigurierbar zu betreiben. Einige SDN-Hersteller bieten die entsprechenden Tools für NFV.
Virtuelle Netzwerkfunktionen werden oft in Zusammenhang mit virtualisierten Serverumgebungen gebracht, sind jedoch nicht nur dort vorhanden. Auch die physische Core-Infrastruktur wird immer häufiger ausgestattet. Sogar der Router beim Kunden (CPE) bietet immer vermehrt solch zentral verwaltete Funktionen, vCPE (virtual Customer Premise Equipment), an. Neben Firewall, DHCP, VPN und NAT gehören auch Traffic Management und QoS zu den virtuellen Netzwerkfunktionen.
SDN und NFV in der Cloud.
SDN wird am häufigsten dort gebraucht, wo die Anzahl Konfigurationsänderungen hoch ist und die Provisionierung durch systemfremde Entitäten (Kunden, Apps, API) gesteuert werden muss. Eine Cloud-Plattform ist somit prädestiniert für SDN.
Zusammen mit SDN kommen auch Technologien zum Einsatz, welche die darunterliegende Hardware und deren Einschränkungen abstrahieren. Nehmen wir die VLAN als Beispiel. Es wäre denkbar gewesen, einer SDN Software beizubringen, alle Switches einer Fabrik mit neuen VLAN automatisch zu provisionieren. Alle Nachteile eines VLAN wären aber erhalten geblieben: maximale Anzahl 4096, ist auf Layer-2 gebunden und kann nicht geroutet werden. Es werden also nicht mehr VLAN eingesetzt, sondern es wird ein sogenanntes Netzwerk-Overlay verwendet. Dabei handelt es sich um eine virtuelle Netzwerk-Schicht, die sich über dem physischen Netz (Underlay) befindet. Auch dafür gibt es verschiedene Technologien, vielfach werden die Netzwerkpakete in Protokollen wie VXLAN und IPSec VPNs enkapsuliert, um die privaten Netze von A nach B zu transportieren. So sieht das Core-Netzwerk keine VLAN-Tags mehr, sondern ganz normale IP-Pakete, die geroutet werden können. Dies bringt auch den Vorteil, dass Layer-2-Netzwerke über geroutete Umgebungen wie das Internet ausgeweitet werden können.
Auch in Multi-Cloud-Umgebungen können gewisse Funktionen zentral konfiguriert werden. Es ist heutzutage üblich, ein virtuelles LAN zwischen der eigenen virtualisierten Umgebung und Microsoft Azure oder auch Amazon (AWS) zu teilen und zentral zu konfigurieren. Dazu kommen virtuelle Router des jeweiligen SDN-Herstellers zum Einsatz.
Need for Speed.
In einer virtualisierten Umgebung spielen SDN und NFV noch eine weitere, wichtige Rolle. Eine dramatisch hohe Leistung im Routing- und Firewalling-Bereich wird gefordert. Typischerweise bleiben in einer virtualisierten Umgebung ca. 70% des gesamten Netzwerkverkehrs lokal. Es handelt sich um den sog. Ost-West Verkehr zwischen den Servern respektive den VM. Als Nord-Süd-Verkehr bezeichnet man den Datentausch zwischen der eigenen Umgebung und fremden Netzwerken wie z.B. dem Internet.
Wenn man bedenkt, dass jeder Server heutzutage üblicherweise mit mindestens 20 Gbit/s angeschlossen ist und jeder Top-of-the-Rack-Switch 1 Tbit/s weiterleiten kann, stellt man relativ schnell fest, dass keine Firewall und kein Router den gesamten Verkehr aufnehmen kann - weder physisch noch virtuell. Eine einzelne Instanz, egal wie gross und teuer sie ist, wird den gesamten Ost-West-Verkehr einer bedeutenden Plattform nicht bearbeiten können. Da hilft der Einsatz von verteilten, virtuellen Routern und Firewalls.
Ist die SDN/NFV-Lösung im Hypervisor integriert, können diese Funktionen unter allen Hosts geteilt werden. Die Firewalling- und Routing-Funktionen sind auf jedem Host vorhanden und identisch konfiguriert. Damit kann jeder Host selbstständig und direkt an der Quelle entscheiden, ob ein Paket weitergeleitet oder verworfen werden soll, und dies unabhängig davon, auf welchem Host gerade welche VM läuft. So erhält quasi jede VM eine eigene Firewall direkt an der Netzwerkschnittstelle. Neben einem viel höheren Durchsatz erlaubt dieses Modell auch die Mikrosegmentierung der VM. Gemeint ist damit, dass eine verteilte Firewall den Netzwerkverkehr zwischen zwei VM, welche sich im gleichen IP-Netz befinden, kontrollieren kann.
SDN at Cyberlink.
Seit 2013 setzt Cyberlink AG in ihrer eigenen Cloud-Umgebung SDN erfolgreich ein. Nebst SDN ist auch SDS (Software-defined-Storage) auf einer hyperkonvergenten Infrastruktur im Einsatz. Cyberlink setzt für ihre Cloud auf VMware mit ESXi, NSX, VSAN und vCloud Director.