Ich hatte hier schon über Möglichkeiten geschrieben, Komponenten eines Netzwerklabors automatisch als LXC-Container aufzusetzen. Nachdem ich neulich mit einem Kollegen über Testszenarien für GlusterFS philosophiert habe, habe ich nunmehr versucht, diese Fragmente zu konsolidieren...

Anforderungen

Die Subnetze untereinander sind durch spezielle Appliances zu verbinden, mit denen die QoS auf den Verbindungen zwischen den Subnetzen gesteuert werden kann

Idealerweise wird anschließend eine Dokumentation generiert, die die Informationen zu den Subnetzen enthält, ebenso wie Informationen darüber, wie die einzelnen Appliances erreicht und gesteuert werden können.

Bauteile

Weiterhin existiert ein Skript zur Einrichtung eines "intelligenten" steuerbaren Netzwerkkabels (steuerbar, was QoS angeht). Damit ist eine weitere der genannten Anforderungen umsetzbar.

Beide Skripte müssen mehrfach aufgerufen werden, um die skizzierte Laborumgebung zu realisieren.

Skizze der Umgebung ohne QoS

Es werden drei Subnetze eingerichtet - Diese werden in einer Hierarchie organisiert: Eines der Subnetze wird direkt mit dem Internet verbunden, die anderen beiden werden mit diesem zentralen Subnetz verbunden. Damit müssen Verbungen aus einem dieser beiden Subnetze heraus ins Internet über zwei Router-Appliances laufen.

In einer späteren Ausbaustufe wird in dem Subnetz, das in der Hierarchie am weitesten oben angesiedelt ist ein dedizierter Nameserver eingerichtet. Dieser ist dazu da, das Internet zu simulieren: Hier können später zentrale Dienste wie zum Beispiel EMail registriert werden.

Ohne diesen dedizierten Nameservice kann die Erstellung der drei Subnetze durch den dreimaligen Aufruf des Skripts setup_router.sh aus diesem Repository erfolgen.

Dabei ist zu beachten, dass die Interfaces beim Aufruf jeweils Bridges sein müssen - existieren sie nicht, werden sie eingerichtet. Das Subnetz, welches in der Hierarchie ganz oben sein soll, muss als externes Interface eine Bridge zugeordnet bekommen, an der ebenfalls ein physisches Interface konfiguriert ist, über das eine Verbindung ins Internet möglich ist.

Die externen Interfaces der beiden anderen Subnetze müssen die gleichen Bridges sein, wie das interne Interface des obersten Subnetzes der Hierarchie.

Damit besteht das Netzwerklabor zu diesem Zeitpunkt aus vier Bridges und drei Containern (drei Router).

QoS Überlegungen

Sollen jetzt noch die QOS Appliances hinzugefügt werden, ist es wichtig, zu entscheiden, wie und wo die schlechten Netzwerkverbindungen simuliert werden sollen: Man könnte die QOS für einzelne Server im oberen Subnetz einrichten oder die Verbindungen zwischen den jeweils untergeordneten Subnetzen und dem übergeordneten Subnetz pauschal über eine solche Appliance laufen lassen. Dieser Fall würde bedeuten, dass alle Rechner innerhalb desselben Subnetzes eine ungestörte, segr schnelle verbindung untereinander haben und nur bei Kommunikation über Subnetzgrenzen hinweg Störungen (je nach Konfiguration der Appliances) auftreten können. Eine solche Konfiguration könnte man sich über ein Szenario erklären, das die zwei untergeordneten Subnetze als zwei geographisch getrennte Standorte eines Unternehmens modelliert.

Skizze der Umgebung mit QoS

Es werden drei Subnetze eingerichtet - Diese werden in einer Hierarchie organisiert: Eines der Subnetze wird direkt mit dem Internet verbunden, die anderen beiden werden mit diesem zentralen Subnetz verbunden. Damit müssen Verbungen aus einem dieser beiden Subnetze heraus ins Internet über zwei Router-Appliances laufen.

In einer späteren Ausbaustufe wird in dem Subnetz, das in der Hierarchie am weitesten oben angesiedelt ist ein dedizierter Nameserver eingerichtet. Dieser ist dazu da, das Internet zu simulieren: Hier können später zentrale Dienste wie zum Beispiel EMail registriert werden.

Ohne diesen dedizierten Nameservice kann die Erstellung der drei Subnetze durch den dreimaligen Aufruf des Skripts setup_router.sh aus diesem Repository erfolgen.

Dabei ist zu beachten, dass die Interfaces beim Aufruf jeweils Bridges sein müssen - existieren sie nicht, werden sie eingerichtet. Das Subnetz, welches in der Hierarchie ganz oben sein soll, muss als externes Interface eine Bridge zugeordnet bekommen, an der ebenfalls ein physisches Interface konfiguriert ist, über das eine Verbindung ins Internet möglich ist.

Das Setup der zwei QoS-Appliances erfolgt durch den zweimaligen Aufruf des Skripts setup_schlechtesnetz.sh aus diesem Repository.

Die Server-Interfaces der beiden Appliances müssen die gleichen Bridges sein, wie das interne Interface des obersten Subnetzes der Hierarchie.

Die externen Interfaces der beiden anderen Subnetze müssen die gleichen Bridges sein, wie das Consumer-Interface jeweiligen QoS-Appliance.

Damit besteht das Netzwerklabor zu diesem Zeitpunkt aus sechs Bridges und fünf Containern (drei Router, zwei QoS-Appliances).

Beispiel

brctl addbr intnet0
ifconfig intnet0 up
./setup_router.sh router br0 intnet0 10.100.0.254 255.255.255.0 192.168.10.2 intnet0.lab
brctl addbr intnet1
ifconfig intnet1 up
brctl addbr badintnet1
ifconfig badintnet1 up
./setup_schlechtesnetz.sh badintnet1 br0 badintnet1 intnet0
./setup_router.sh router1 badintnet1 intnet1 10.100.1.254 255.255.255.0 10.100.0.254 intnet1.lab 10.100.0.1 255.255.255.0

Damit haben wir ein Subnetz geschaffen, das über eine Verbindung konfigurierbarer Qualität am übergeordneten Subnetz hängt und darüber wiederum mit dem Internet verbunden ist. (Die letzten beiden Parameter beim Aufruf von setup_router.sh hätte man auch weglassen können, dann würde die Appliance statt der angegebenen IP-Adresse für das externe Interface versuchen, eine per DHCP zu bekommen.) Man kann sich jetzt mittels lxc-attach -n badintnet1 -- mit der Appliance verbinden und entweder eines der vorgefertigten Scripte unter /scripts benutzen, um die verbindungsparameter anzupassen oder selbst neue Konfigurationen erstellen.

Weitere Subnetze können durch Wiederholung der Anweisungen erstellt werden. Ein Beispiel dafür sieht man hier:

brctl addbr intnet2
ifconfig intnet2 up
brctl addbr badintnet2
ifconfig badintnet2 up
./setup_schlechtesnetz.sh badintnet2 br0 badintnet2 intnet0
./setup_router.sh router2 badintnet2 intnet2 10.100.2.254 255.255.255.0 10.100.0.254 intnet2.lab 10.100.0.2 255.255.255.0

Auch hier wurde durch die beiden optionalen Parameter für setup_router.sh eine feste IP-Adresse für das externe Interface konfiguriert.

Zugriff auf Container in den Subnetzen

Prinzipiell sind alle Container natürlich immer über lxc-attach -n containername -- administrierbar. Außerdem haben alle QoS-Appliances bereits einen SSH-Server installiert. Für die Router muss dieser Dienst erst noch installiert werden, sollte er benötigt werden. In allen Containern sind Nutzer mit dem Nutzernamen ubuntu angelegt. Um sie nutzen zu können, muss allerdings erst ein Passwort gesetzt werden. das kann geschehen mittels lxc-attach -n containername -- passwd ubuntu.

Ausblick

Von hier aus kann man nunmehr aber schnell weitere Szenarien entwickeln. Es ist zum Beispiel möglich, in den Subnetzen Docker-Hosts zu virtualisieren und die Dienste in den Docker-Containern des einen mit denen des anderen Subnetzes zu verbinden.

Damit Rechner aus dem einen mit Rechnern des anderen Subnetzes reden dürfen ist noch die Einrichtung eines Tunnels oder VPN nötig. Das soll hier nicht Teil der Veranstaltung werden.

Alternativ ist es auch immer möglich, Container innerhalb eines Subnetzes zusammenzuschalten und die Qualität der Verbindungen jedes einzelnen Containers über eine Appliance - wie oben bereits angedeutet - steuerbar zu machen.

Links

Links

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )