Virtualisierte Controller für Multi-Gigabit-WLANs

Kommentieren Drucken

Es ist ein allgemeiner aktueller Trend, darüber nachzudenken, ob man Funktionen eines Netzwerks nicht vollständig in Software implementieren kann, die dann im Rahmen einer passenden Virtualisierungslösung auf einer oder mehreren VMs läuft. Ein derartiger Ansatz hätte auch erhebliche Vorzüge für 802.11ac und 802.11ad Wireless-Infrastrukturen. Die Frage ist, ob das auch funktionieren könnte.

Wesentliche Vorzüge einer virtualisierten Lösung sind:

  • Mobilität (Unabhängigkeit vom tatsächlichen physikalischen Server)
  • Nutzung meist ohnehin vorhandener Server-Infrastruktur im RZ
  • Redundanz und Ausfallsicherheit durch Standard-Mechanismen der Virtualisierungssoftware, daher keine Notwendigkeit des Hinzukaufens von eigentlich nicht benötigten Geräten
  • in Summe erhebliche Kostenvorteile möglich.

Bei geeigneter Konstruktion der Software ergibt sich darüber hinaus:

  • Skalierbarkeit und Elastizität in weitem Bereich

Wie wir bei der Betrachtung anderer Software-Lösungen im Netzumfeld aber lernen mussten, werden grade diesen beiden Punkte gegebenenfalls durch suboptimale Lösungen im Rahmen der Virtualisierungssoftware, z.B. zu langsame VM-Kommunikation und VM-Migration an völlig unnötigen Stellen Grenzen gesetzt.

Letztlich hängt die mögliche Leistung einer software-basierten virtualisierten Lösung von der Anzahl der VMs, die sie benutzen darf und von der Grundqualität der Virtualisierungslösung ab.

WLAN-Controller selbst sind relativ bescheiden in ihren Anforderungen. Sehen wir uns dazu einmal als Beispiel das Wireless-Virtual Gateway 2110 und die NAC-Appliance von Enterasys an. Mit einem Durchsatz von 500 Mbit/s. kann es nach Angaben des Herstellers bis zu 120 APs bzw. 500 Clients verwalten. Es wird genau so konfiguriert wie ein Hardware-Controller. Die Anforderungen sind bescheiden: 4 Virtuelle CPUs, 2 GByre RAM und 25 GByte Disk Space unter VMware ESX/ESXi 4.1 Server, also im Klartext deutlich weniger als ein guter Heim-PC.

Auch Cisco hat mit dem Virtual Wireless Controller ein entsprechendes Angebot. Das Modell ist allerdings primär für Filialen gedacht und unterstützt Lokales Bridging für bis zu 200 FlexConnect-APs/3000 Clients ebenfalls mit 500 Mbit/s. Bei den Hardware-Anforderungen ist es noch bescheidener: 1 virtuelle CPU, 2 GByte RAM und 8 GByte Disk. Allerdings wird dann in der Filiale ein virtualisierter Server benötigt.

Die Entwicklung virtueller WLAN-Controller steckt noch in den Anfängen, ist aber für meine Begriffe der vielversprechendste Ansatz, weil hier das Skalierbarkeitsproblem elegant gelöst wird. Wenn eine Software heute sagen wir einmal 200 11n-APs mit einer oder zwei VMs versorgen kann, kann sie für 11ac einfach dadurch weiterentwickelt werden, indem sie zwei, vier oder sechs VMs und entsprechend mehr Speicher zugeteilt bekommt. Letztlich werden Tunnel erzeugt, benutzt und verwaltet. Alle diese Funktionen sind hochgradig parallelisierbar und weisen keine Abhängigkeiten untereinander auf, eine wichtige Voraussetzung für die beschriebene Skalierbarkeit.

Heute dokumentierte Grenzen für Netzwerk-Funktionen in Software liegen nicht in der Größenordnung von einigen Hundert Mbit/s., sondern in der von 10 Gbit/s mit Perspektive auf 40 Gbit/s. Als Beispiel verweise ich in diesem Zusammenhang auf das Stingray Application Delivery System von Riverbed. Natürlich kann dann eine solche Software ein ganzes, hoch leistungsfähiges Server-Blade mit Beschlag belegen, wenn ein solcher Durchsatz gefragt ist. Zum Vergleich: das zum Zeitpunkt der Manuskripterstellung leistungsfähigste Hardware-Controller-Modell von Cisco hat einen Forwarding-Durchsatz von 60 Gbit/s und kann damit bis zu 1000 11ac-APs mit bis zu 12.000 Benutzern verwalten.

Das gibt mir auch ein weiteres Stichwort, nämlich zur Weiterentwicklung von WLAN-Controllern überhaupt. Sie sind heute noch sehr in einer L2/L3-Welt und dem Wunsch nach möglich exakter Nachbildung von fest verdrahteten Versorgungsstrukturen verhaftet. Mittelfristig sehe ich aber durchaus die Perspektive, dass sich das ändern kann. Worum geht es denn eigentlich ? Um die Bereitstellung von Leistungen für mobile Endgeräte. Das bedeutet, dass es eine Instanz geben muss, die die wireless übermittelten Datenpakete von den APs übernimmt und sie genau an die Stelle leitet, wo sie z.B. mit einer Web-Applikation bearbeitet wird. Sehen wir einmal von den Firewalls ab, haben wir heute auf diesem Wege neben der Switching-Infrastruktur dafür zwei von einander völlig unabhängige Instanzen, nämlich das ADS und den WLAN-Controller.

Sind diese beiden Komponenten nun als Software virtualisiert, spricht nichts dagegen, sie zu einer einheitlichen Komponente zusammenzufassen, die ich einmal „Wireless Application Delivery Controller WADC“ taufe. Festanschlüsse werden in Zukunft immer bedeutungsloser und werden letztlich wie die Terminals selig fast vollständig verschwinden. Sobald ganze Bereiche eines Unternehmens davon betroffen sind, benötigt man um es vereinfacht auszudrücken eine Instanz, die nach beiden Seiten Mobilität unterstützt: auf der Seite der Benutzer und auf der Seite der VMs, denn diese sind ja aktuell auch dabei, von statischen in mehr dynamisierte Umgebungen zu gelangen, weil nur auf diese Weise in RZs wirklich fortschrittliche Betriebskonzepte durchgesetzt werden können.

Hardware-Controller haben immer den großen Nachteil, dass man sie bei schwer wiegenden technologischen Änderungen eigentlich nur noch wegwerfen kann. Software-Lösungen sind hier deutlich flexibler.

Selbst wenn Unternehmen in einigen Jahren in die von Dr. Suppan heraufbeschworene Situation kommen, dass APs nach 11ad die neuen Datensteckdosen mit Multi-Gigabit-Leistung werden, haben sich ja in dieser Zeit auch Server, Speicher und Virtualisierungslösungen weiterentwickelt. Die Unterstützung geeigneter WLAN-Controller durch Software dürfte also auch in diesem extremen Umfeld keinerlei wirkliche Probleme aufwerfen.

Ärgerlich bleibt eigentlich nur die Lizensierungspolitik von VMware, die zu einem erheblichen Maß zu den Gesamtkosten einer virtualisierten Lösung beiträgt. Hier wäre es wünschenswert, wenn sich Hersteller von Software im Netzwerk-Umfeld nicht nur auf diesen Hersteller von Virtualisierungssoftware konzentrieren würden.

Eine weitere in diesem Zusammenhang stehende Diskussion dreht sich um die Nutzung von SDN-Konzepten für die Verbesserung von WLAN-Controllern, ist aber noch etwas „dünn“. Aktuell gibt es nur einen Vorschlag namens „Odin“: OpenFlow Framework for Enterprise WLANs. Der ist aber im Status einer werdenden Dissertation.

Kern der Problemstellung ist, dass APs, WLAN-Controller, Management-Systeme, Mobility Manager, Load Balancer, Systeme zur automatischen Rekonfigurierung von Kanälen und Durchsetzung von Sicherheitsverfahren heute weitest gehend proprietär sind.

Der Einsatz einer unabhängigen, nach den SDN-Prinzipien konstruierten Steuerungssoftware verspricht bessere Orchestrierung des Netzes sowie höhere Flexibilität in der Control Plane.

Die Kernidee ist eine Verlagerung von Funktionen. Die Basis dabei sind so genannte Light Virtual APs, die am Ende preiswerter sein könnten als die bestehenden Modelle und die Steuerung dieser relativ funktionsarmen APs mit Open Flow und einem entsprechenden Controller. (siehe Abbildung 2)

Es bestehen eigentlich keinerlei Bedenken hinsichtlich der möglichen Funktionsfähigkeit dieser Konstruktion, aber die Hersteller haben in den letzten zwanzig Jahren wenig Neigung zu einer Kooperation gezeigt. Vielmehr haben sie sich Wettbewerbsvorteile durch eine mehr oder minder geschickte Integration der WLAN-APs und Controller in ihre bestehenden Switching-Systemwelten verschafft. Es ist nicht zu erwarten, dass sie davon abrücken, dazu fehlt ein wirklicher Grund.

Gegen die Light Virtual Access Points spricht aber vor allem die Entwicklung bei den Access Routern, die für die Versorgung privater Haushalte im Rahmen z.B. einer DSL-Unterverteilung gedacht sind. Auch ihre Prozessoren bekommen im Laufe der Zeit immer mehr Leistung und Funktionsumfang. Rein vom möglichen Verkaufsvolumen ist eine sinnige Weiterentwicklung für die Hersteller hier wesentlich attraktiver. Standards wie Carrier Ethernet schaffen eine „natürliche“ Multi-Mandantenumgebung. Provider, die ja bereits ausgedehnte Mobilfunkstrukturen mit 3G und LTE aufgebaut haben, neigen dazu, die Techniken, die sie hier erfolgreich zur Steuerung einsetzen, auch auf die DSL/WLAN-Versorgungsbereiche auszudehnen.

Letztlich ist das Ganze auch noch nicht wirklich durchdacht. Was ist, wenn das Infrastruktur-Netz auch mit Open Flow und entsprechenden Controllern arbeitet und wir die Controller redundant ausführen. Brauchen wir dann einen Controller für die Kontrolle der Controller?

Die Weiterentwicklung privater WLAN-Versorgungsstrukturen wird also eher dadurch gekennzeichnet sein, dass die Access Points selbst immer alleine durch die benötigte Stückzahl in den Provider-Versorgungsbereichen immer preiswerter werden und dennoch immer mehr Leistung und funktionale Möglichkeiten bekommen, die von den Herstellern schlicht dazu genutzt werden können, erfolgreiche Methoden aus dem Provider-Bereich auch auf privat betriebene WLAN-Versorgungsstrukturen auszudehnen.

Sollten sich SDN-Konzepte auch auf anderen Netzwerkbereichen erfolgreich durchsetzen, was sicherlich in den nächsten Jahren so sein wird, spricht nichts dagegen, dass dann auch auf die Kontrolle mobiler Umgebungen auszuweiten, aber eben nicht umgekehrt!

zugeordnete Kategorien: LAN, Virtualisierung, WLAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.