Dieser Artikel im August 2015 geschrieben worden
Gestern Abend habe ich mich ein wenig in die Netzwerkfähigkeiten von SmartDatacenter/Triton eingelesen. Im Grunde haben alle Softwareprojekte, die Infrastruktur für eine "Cloud" bereitstellen wollen, eine Herausforderung im Netzwerk (egal ob es sich um VMWare, OpenStack oder ein anderes Projekt handelt): Sie müssen virtuelle Netzwerke für ihre Kunden bereitstellen, die voneinander getrennt sind, wenn sie wirklich mandantenfähig sein wollen. Eine Antwort für diese Herausforderung ist das VLAN. Wenn jeder Kunde ein VLAN bereitgestellt bekommt, sind die Kunden sehr gut voneinander isoliert. Leider ist die Anzahl der VLANs in einer Switchumgebung begrenzt (je nach Technologie sind es wohl 4096 pro Ethernet). Eine Möglichkeit, diese Grenze zu umgehen, ist das Konzept des Overlay-Netzwerks (oder virtuellen VLANs). Im Wesentlichen gibt es zwei Standards, für virtuelle VLANs: VXLAN und NVGRE (wobei vor Kurzem "Geneve" herausgekommen ist, um beide zu vereinen). VMWares NSX liegt VXLAN zu Grunde. OpenStack unterstützt verschiedene Standards. Default sind normale GRE-Tunnel aber es geht alles, was sich durch openvswitch verwalten lässt.
SmartDatacenter/Triton hat sich für VXLAN entschieden. Die folgende Zeichnung zeigt das "normale" Triton-Setup (ohne virtuelle VLANs):
+---------------------------------------------------------------------+
| Compute Node |
| +------------------+ +------------------+ +------------------+ |
| | Zone 0 | | Zone 1 | | Zone 2 | |
| | +------+------+ | | +------+------+ | | +------+------+ | |
| | | net0 | net1 | | | | net0 | net1 | | | | net0 | net1 | | |
| +------------------+ +------------------+ +------------------+ |
| | | | | | | |
| +------+--------------+------+--------------+--+----+ |
| | |
| +--------+ +-------------+ | |
| | Agents | | GZ Services | +-----------+ +------+----+ |
| +--------+ +-------------+ | Admin | | Customer | |
| | | | Interface | | Interface | |
| +--------------+---------| ixgbe0 | | ixgbe1 | |
+---------------------------------+-----------+---+-----------+-------+
Ein Compute Node hat zwei Netzwerkinterfaces. Dabei ist eins komplett für die Administration und das andere komplett für Kundentraffic vorgesehen. Möchte man/Kann man keine virtuellen VLANs verwenden, würde man auf dem Customer Interface tagged VLANs für jeden Kunden bereitstellen.
Möchte man virtuelle VLANs bereitstellen, ändert sich die Konfiguration wie folgt:
+---------------------------------------------------------------------+
| Compute Node |
| +------------------+ +------------------+ +------------------+ |
| | Zone 0 | | Zone 1 | | Zone 2 | |
| | +------+------+ | | +------+------+ | | +------+------+ | |
| | | net0 | net1 | | | | net0 | net1 | | | | net0 | net1 | | |
| +------------------+ +------------------+ +------------------+ |
| | | | | | | |
| | | | | | | |
| | +-----------+ | +-----------+ | +-----------+ |
| | | overlay23 | | | overlay24 | | | overlay25 | |
| | +-----------+ | +-----------+ | +-----------| |
| | | | |
| +---------------------+---------------------+--+ |
| | |
| +-------+ +-----------+ | |
| | varpd | | underlay0 |--+ | |
| +-------+ +-----------+ | | |
| | | | |
| +--------+ | +-------------+ | | |
| | Agents | | | GZ Services | +-----------+ +------+----+ |
| +--------+ | +-------------+ | Admin | | Customer | |
| | | | | Interface | | Interface | |
| +-----+--------+---------| ixgbe0 | | ixgbe1 | |
+---------------------------------+-----------+---+-----------+-------+
Das net0 Interface der Zone wäre das "öffentliche" Netz des Kunden - das net1 Interface das "interne/private" Netz des Kunden. Um virtuelle VLANs abzubilden wird zunächst ein Underlay-Netzwerk benötigt, welches von Kunden nicht erreichbar ist und über welches jeder Compute Node jeden anderen Compute Node eines DataCenters erreichen kann. Das muss nicht auf Layer-2 Ebene aufgespannt sein, es kann auch geroutet sein. Idealerweise hat es eine MTU-Size von 9000 (Jumbo Frames), um die Probleme zu umgehen, die durch die VXLAN-Encapsulation entstehen und um in Kunden-VLANs ggfs. auch größere MTUs verwenden zu können. Um den Weg aus einem Overlay-Netzwerk auf einem Compute Node zu dem selben Overlay-Netzwerk auf einem anderen Compute Node zu ermöglichen wird zusätzlich (unter anderem) der varp-Daemon benötigt, der ARP-Requests in den Overlay-Netzen bearbeitet und über sein Backend herausfindet, wo die gesuchte MAC-Adresse sich befindet.
+-------------------------------+ +-------------------------------+
| Compute Node A | | Compute Node B |
| +--------------------------+ | | +--------------------------+ |
| | Zone 0 | | | | Zone 1 | |
| | +------+ 10.2.3.4/24 | | | | +------+ 10.2.3.5/24 | |
| | | net0 | de:ad:be:ef:0:0 | | | | | net0 | de:ad:be:ef:0:1 | |
| +--------------------------+ | | +--------------------------+ |
| | | | | |
| +-----------+ | | +-----------+ |
| | overlay42 | | | | overlay42 | |
| +-----------+ +------------+ | | +-----------+ +------------+ |
| +-------+ | underlay0 | | | +-------+ | underlay0 | |
| | varpd | |172.6.7.8/24| | | | varpd | |172.6.7.9/24| |
| +-------+ +------------+ | | +-------+ +------------+ |
| | | | | | | |
| +-----------+ +-----------+ | | +-----------+ +-----------+ |
| | Admin | | Customer | | | | Admin | | Customer | |
| | Interface | | Interface | | | | Interface | | Interface | |
| | ixgbe0 | | ixgbe1 | | | | ixgbe0 | | ixgbe1 | |
+-------------------------------+ +-------------------------------+
Natürlich sind das nicht die einzigen Vorbereitungen, die man treffen muss (und natürlich sind die nicht im Nu getroffen), aber ich hoffe, dass dies schonmal einen guten Eindruck vom Konzept der virtuellen VLANs in Triton gibt. Was mir beim Betrachten noch klar geworden ist: Wenn man mit "normalen" VLANs arbeitet, kann man auch die "normalen" Endpoints dieser VLANs benutzen (hier "normale" Loadbalancer, Firewalls und Router). Wenn man auf virtuelle VLANs setzt, muss man auch für diese Endpoints bereitstellen (hier ausgesuchte Compute Nodes), die per NAT-Pool den Weg in die "wirkliche" Welt herstellen. Zum Schluß auch noch ein Vortrag (Video und Folien) von 2014 zu dem Thema.
Links
Triton virtual networking design and architecture
Triton networking and fabric operations guide
Setting up Triton virtual networking and fabrics
Software Defined Networking for illumos
Performance Testing virtual Networks (auch die Kommentare lesen!)