Das neue V-LAN Management erlaubt es uns jetzt auch V-LANs unserer Kunden über unser vServer Panel zu verwalten. Die Implementierung der Funktion war an dieser Stelle deutlich aufwändiger als erwartet. Das Hauptproblem dabei bestand darin, dass wir die Kanalisierung des Kundentraffic bislang mit dem Linux Boardmittel Proxy-Arp durchgeführt haben. Die Kanalisierung des Traffics ist essentiell, damit die verschiedenen vServer nicht den Traffic anderer vServer mitlesen können, da die Kommunikation über die Selbe Netzwerkschnittstelle erfolgt. Proxy-Arp ist an dieser Stelle scheinbar nicht für den Einsatz mit V-LANs bzw. mehreren Schnittstellen geeignet, zumindest hat Proxy-Arp immer versucht den Traffic zwischen den V-LANs zu routen. Wir sind daher wieder zurückgekehrt auf die Verwaltung der V-LANs mit Hilfe von Netzwerk Bridges. Dies hat ebenfalls den Vorteil, dass wir problemlos weitere V-LANs im laufenden Betrieb hinzufügen können und ebenfalls keine IP-Adresse aus dem V-LAN pro vServer Host benötigen. Die Kanalisierung des Traffics konnten wir mit Hilfe von iptables Regeln festlegen, ebenso die Bindung der IP-Adresse an die MAC-Adresse des vServers.
Von der Webinterface Topologie her haben wir alle IP-Netze an ein V-LAN gebunden. Die IP-Netze selbst sind dann auf bestimmte Reseller beschränkt. Ebenfalls wird festgelegt, welches IP-Netz auf welchen vServer Hostsystemen bereitgestellt werden kann. Damit wird ein Reseller spezifisches IP-Subnetz und V-LAN Management gewährleistet und verhindert, dass die IP-Adressen ggf. durch andere Reseller ebenfalls verwendet werden können. In welchem V-LAN sich der jeweilige vServer befindet, wird unter Anderem im vServer Resellerbereich bei den vServer Informationen angezeigt.
Das V-LAN Management ist die Grundvoraussetzungen für die Einführung unserer Storage vServer im ersten Quartal 2017. Wir können so unseren Rootserver Kunden mit eigenem V-LAN die Möglichkeit bieten zum Beispiel eine Backup virtuelle Maschine im eigenen Netzwerk zu platzieren um die Backups über ein internes IP Subnetz durchführen zu können statt diese über die öffentlichen IP-Netze zu übertragen.
