Best PracticesDiensteInfrastrukturLinuxToolsWeb

Verbinde Server in unterschiedlichen RZs per vSwitch

Am 04. September 2018 hat Hetzner ein neues Feature seinen Kunden zur Verfügung gestellt:

Ein vSwitch ist ein Switch, der per SDN (Software-defined Networking) Host in unterschiedlichen Rechenzentren (DCs) in einem Netz zusammenbringen kann.

Was für einen Vorteil hat dies? Manchmal benötigt man ein privates Netzwerk zwischen einzelnen Server, um z.B. Cluster funktionen abbilden zu können (z.B. einen Proxmox Cluster für HA).

Bislang war es notwendig, wenn man einzelne Server in einem privaten Netzwerk verbinden zu wollen, dies mit anderen Mitteln (z.B. Tinc) zu tun. Die Einrichtung war bei mehreren beteiligten System sehr komplex, da Tinc ein Mesh basiertes VPN ist. Zudem wurde der Traffic über das öffentliche Netzwerkinterface geroutet, welches zum einen sehr langsam war und zum anderen in das normale Trafficlimit eingangen ist.

Das neue vSwitch Feature kann als Hetzner Kunde kostenlos verwendet werden. Soll auch externer Traffic über den vSwitch betrieben werden – hierzu später mehr – greift ein Traffic-Limit für ausgehende Daten von 1TB/Monat. Danach fallen die üblichen Traffickosten an – aktuell 1,19 € für jedes zusätzliche ausgehende TB.

Vorwort

Die Einrichtung erfolgt über den Hetzner Robot. Unter der Rubrik Server existiert nun ein weiterer Eintrag vSwitches.

Ich möchte nun anhand eines Beispieles beschreiben, wie zwei Server, welche in zwei unterschiedlichen DCs betrieben werden, über einen vSwitch in einem gemeinsammem privaten Netzwerk verbunden werden können.

Die folgende Beschreibung ist aus dem offiziellen Eintrag im Hetzner Wiki abgeleitet. Das zu Grunde liegene OS ist in beiden Fällen die default Debian Installation von Hetzner. Diese wird Nachfolgend dann noch auf Proxmox aktualisiert. Dies wird aber in einem nächsten Post beschrieben werden.

Gegeben sind zwei Server host2 und host3 in zwei unterschiedlichen Rechenzentren (FSN1-DC5 und FSN1-DC10). Beide Server besitzen schon eine externe IP, über welche Sie aus dem Internet erreichbar sind (144.xyz.xyz.149, host2 und 46.xyz.xyz.134, host3)

Wir möchten nun erreichen, dass sich beide Server über einen interne IP im Netzwerk von vSwitch erreichen können (10.10.10.2, host2 und 10.10.10.3, host3).

Zudem lassen sich an einen vSwitch auch IP-Blöcke für externe IPs binden, welche dann frei an alle Server im vSwitch Netzwerk verteilen lassen (142.xyz.xyz.162, host2 und 142.xyz.xyz.163, host3). Das folgende Bild veranschaulicht den Aufbau:

 

Setup

Als erstes legen wir einen vSwitch an:

Die VLAN-ID habe ich auf 4000 gelassen. Man kann nun einzelne Server anhand des Hostnamens oder der Server ID suchen und hinzufügen. Wie das UI zeigt, lassen sich maximal 100 Server in maximal 100 vSwitches zusammenfassen.

Setup der lokalen IPs

Die Netzwerkonfiguration muss auf allen Systemen erfolgen, die Teil des vSwitch Netzwerk sein sollen. Wir fangen mit der Konfiguration der lokalen IPs an.

Beginnen wir als mit unserem ersten System: host2. Das initial Netzwerk sieh folgendermaßen aus:

Wichtig ist der Name des Netzwerk Devices (enp2s0). Hiervon wird unser neues vSwitch Device abgeleitet. Wir erstellen nun unser vSwitch Device (die MTU wir auf 1400 gesenkt, die VLAN-ID ist 4000). Die lokale IP wird auf 10.10.10.2 gesetzt:

Die neue Konfiguration sieht nun wie folgt aus:

Gleiches erfolgt nun für Host3:

Wir erstellen nun auch hier das vSwitch Device. Man beachte das andere Netzwerk Device enp3s0.

Es sollte nun möglich sein, von host2 die IP 10.10.10.3 zu erreichen und umgekehrt:

public IPs

Wie bereits erwähnt, ist es möglich, an einen vSwitch mehrere public IP Adressen zu binden. Dies passiert ebenfalls per Robot:

Am aktuellen vSwitch hängt ein /29 subnet. Jeder (aber nur einer!) Server, der im vSwitch Netzwerk hängt, kann nun eine dieser IPs verwenden.

Wir begeben uns wieder ins Terminal auf host2 und fügen eine neue Route hinzu:

In der neuen Netzwerkkonfiguration sollte nun die neue IP auch auftauchen:

Auf host3 erfolgt die Konfiguration identisch:

Beide Server sollten nun über beide öffentlichen IPs erreichbar sein (e.g. ein installierter nginx sollte im Browser erreichbar sein).

Benchmark

Es stellt sich die Frage, welche use cases mit so einem SDN umgesetzt werden können. Abschließend also eine einfache Benchmark. Wir wollen ein ubuntu ISO Image jeweils über die unterschiedlichen Verbindungen von einem Server auf den anderen übertragen:

Wie wir sehen, ist das Image gut 800Mb groß.

Zuerst übertragen wir das Image über die privaten IPs (10.10.10.2 zu 10.10.10.3).

Der Vollständigkeit halber auch noch mal in Gegenrichtung:

Als nächstes verwenden wir die beiden externen IPs, die über den vSwitch erreichbar sind:

Als nächstes verwenden wir die externen IPs der Host System (der DNS Eintrag host3.foo.bar löst auf die externe IP 46.xyz.xyz.134 auf)

Wir können erkennen, dass die Verbindung über das interne SDN deutlich schneller ist. Zudem wird dieser Traffic weder vom Limit der Server, noch vom Limit des vSwitches abgezogen.

Fazit

Hetzner bietet mit dem neuen vSwitch Feature eine interessante Erweiterung, um auch komplexeres Use Cases abbilden zu können. Vom Aufsetzen eines internen Management Netzwerks, über eine Backup Verbindung bis zu einem automatisiertem Fail-Over Verhalten lassen sich unterschiedliche Konfigurationen erstellen.

Natürlich wird erst die Zeit sagen können, wie stabil und performant diese neue SDN Funktion tatsächlich ist.

 


Cover Image: https://www.pexels.com/photo/eight-electrical-metric-meters-942316/

Leave a Reply

Your email address will not be published. Required fields are marked *

Check Also

Close
Back to top button
Close