Netzwerke: Clustering mittels Routing & VXLAN

Hallo Freunde der Sonne,

in diesem Beitrag möchte ich Euch zeigen, wie man in größeren Umgebungen redundante Bereitstellungen aufbauen kann.

Netzwerke: Clustering mittels Routing & VXLAN

Bevor es zum bunten Bild geht, sollte man sich fragen ob die untenstehenden Gesichtspunkte interessant sind:

Strategische Gesichtspunkte 

  • Muss jedes Endgerät den kompletten Traffic seiner Partner mitlesen? (Bandbreite, Segmentierung)
  • Habe ich Netzwerke mit vielen Endgeräten die besser in getrennte Broadcast/Multicast aufgehoben sein sollten? (Bandbreite, Segmentierung)
  • Möchte ich redundante Wege zur Anbindung meiner Systeme haben? (Routing, LAGs)
  • Sollte der Einbau/die Bereitstellung neuer Geräte möglichst konfigurationslos erfolgen? (Kompetenzteilung, dynamisches Routing, DHCP, Autoconfig, Verzicht auf LAGs)
  • Möchte ich Dienste clustern zwecks Ausfallsicherheit? (Layer2-basierte Cluster-IP, VXLAN)

Mögliche Komponenten

  • Bandbreite, Segmentierung = Umstellung von einem Netzwerk auf mehrere Netzwerke via Routing
  • dynamisches Routing = OSPF oder ähnliche interne Routingprotokolle
  • DHCP = Dynamic Host Configuration Protocol, jeder eine IP durch Broadcastanfrage
  • Clustering = Überwachung mehrerer Server/Dienste und Vergabe einer gemeinsamen IP an einen Master
  • VXLAN = Tunneln (verkapseln) von IP-Paketen, zwecks Layer2-Verbindung (Bridging) über Layer3-Netzwerke (Routing)

Umsetzung

Die folgende Grafik stellt die Umsetzung der oben genannten Gesichtspunkte über die möglichen Komponenten dar.

  • virtuelle Container/VMs sind über einen VXLAN-Tunnel miteinander verbunden
  • die VMs sind im selben Layer2-Netzwerk und können daher einen Cluster bilden
  • die Server haben mehrere Schnittstellen zwecks Redundanz
  • es werden mehrere Layer3-Switche eingesetzt zwecks Redundanz
  • Irrwege & Loops werden vermieden durch dynamisches Routing (im Bild gehen Anfrage und Antwort getrennte Wege)

Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Intern0 Lxdbr0 Intern0 Lxdbr0 Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Container VM Container VM VXLAN - Layer2-Tunnel Switch1 Switch2 Server1 Server2 NIC2 - DHCP NIC2 - DHCP NIC1 - DHCP NIC1-DHCP Freihandzeichnungen Client Freihandzeichnungen DHCP Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Pacemaker Master Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Clientanfrage geroutet Freihandzeichnungen Freihandzeichnungen Freihandzeichnungen Virtuelle Ressourcen/Wege Physikalische Netzwerke mit DHCP/Routing Hardware

Zum technische Artikel, um es Mal in klein auszuprobieren, gehts hier weiter…

OpenStack

Für alle die VXLAN etc. in groß ausprobieren wollen, empfehle ich OpenStack.
Für den Unterbau ist jeder selbst verantwortlich, in wie weit man Server zu Routern macht um Redundanzen zu gewährleisten, muss jeder selbst wissen.

In meinem Beispiel sind es die Controller, die Compute-Nodes würde ich ehr einzeln pro Switch betreiben und durch Masse erschlagen.