Frage Juju LXC Container bekommen falsches DHCP?


Ich verwende eine ähnliche Vernetzung wie diese: http://www.openstackbasement.com/maas-network-hardware

Wenn ich renne:

juju deploy --to lxc: 0 mysql juju deploy --to lxc: 0 Keystone etc...

Nach Marco's Anweisungen hier: http://marcoceppi.com/2014/06/deploying-openstack-with-just-two-machines/

Ich komme mit meinen LXC-Computern, die auf DHCP in dem falschen Netzwerk (192.168.1.0) statt (10.207.39.0) heraufkommen. Die IP-Adresse auf juju-br0 ist 10.207.39.2, daher bin ich überrascht, dass die LXC-Container eine 192.168.1.x-IP über DHCP erhalten.

Das Endergebnis ist, dass die Container ständig in einem ausstehenden Status bleiben, beispielsweise:

Dienstleistungen:   Asche:     Charme: cs: trusty / cinder-34     ausgesetzt: falsch     Service Status:       Aktuell: unbekannt       Nachricht: Wartet auf die Initialisierung des Agenten zum Beenden       seit: 02. Februar 2016 13: 33: 00-06: 00     Beziehungen:       Cluster:       - Asche     Einheiten:       Asche / 0:         Workload-Status:           Aktuell: unbekannt           Nachricht: Wartet auf die Initialisierung des Agenten zum Beenden           seit: 02. Februar 2016 13: 33: 00-06: 00         Agentenstatus:           Aktuell: Zuweisen           seit: 02. Februar 2016 13: 33: 00-06: 00         Agentenstatus: ausstehend         Maschine: 0 / lxc / 6

Wie bekomme ich die LXC-Container, um ihren DHCP von den MAAS-dhcp / dns zu erhalten? Beachten Sie, dass die physischen Knoten (Dell PowerEdge 2850) IP-Adressen erhalten und sich in MAAS DNS / DHCP befinden:

Suche vom Maas Controller Server:

orabuntu @ maas1: ~ $ nslookup unverschämt-niesen Server: 10.207.39.100 Adresse: 10.207.39.100 # 53

Name: unerhört-niesen.maas Adresse: 10.207.39.2

orabuntu @ maas1: ~ $

Suche nach unerhört-Niesen selbst:

ubuntu @ unverschämt-niesen: ~ $ nslookup unverschämt-niesen Server: 10.207.39.100 Adresse: 10.207.39.100 # 53

Name: unerhört-niesen.maas Adresse: 10.207.39.2

ubuntu @ unverschämt-niesen: ~ $

Ich habe verschiedene Einstellungen in /etc/network/interfaces.d/eth0.cfg, / etc / network / interfaces, /etc/dhcp/dhclient.conf ausprobiert, um resolv.conf zu verwenden

Nameserver 10.207.39.100 suche maas

ubuntu @ unverschämt-niesen: ~ $ cat /etc/resolv.conf hash Dynamische Datei resolv.conf (5) für glibc resolver (3) generiert von Hash resolvconf (8) BEARBEITEN SIE DIESE DATEI NICHT MIT DER HAND - IHRE ÄNDERUNGEN WERDEN ÜBERSCHRIEBEN Nameserver 10.207.39.100 suche maas ubuntu @ unverschämt-niesen: ~ $

Aber alle LXC-Container erhalten immer 192.168.1.x dhcp-Adressen, und ich bin mir ziemlich sicher, dass sie im 10.207.39.x-Netzwerk funktionieren sollten, damit sie korrekt funktionieren und dass sie deshalb stecken bleiben und die Bereitstellung nicht abschließen.

Vielen Dank, Gilbert


1
2018-02-02 20:42


Ursprung




Antworten:


Also habe ich diese Probleme selbst gelöst und wenn es anderen hilft, schreibe ich hier meine Schritte. Ich habe das funktioniert perfekt, aber es brauchte einige Verbesserungen für meine Einrichtung, die ich hier teilen werde für den Fall, dass es jemand anderem hilft. Die oben gestellte Frage war, wie ich die LXC-Container in das MAAS-LAN-DHCP-Netzwerk (10.207.39.0/24) statt in das ROUTER WAN-DHCP-Netzwerk (192.168.1.0/24) bringen konnte.

Nach vielen Versuchen und Irrtümern wurde klar, dass ich den Weg dazu nicht finden konnte und keine Antworten gefunden wurden. Also ging ich weiter, um zu sehen, wie mein OpenStack funktioniert und die LXC-Container in ihr bevorzugtes WAN-Netzwerk gelangen.

In diesem Szenario war das Problem, dass ich für eine geraume Zeit lief, dass die Juju Charms, die in LXC-Containern eingesetzt wurden, ständig im Status "Ausstehend" in der Juju-GUI und natürlich im gleichen Status im "Juju-Status" waren. Ich hoffe, dass ich alle Schritte erfasst habe, die erforderlich waren, um dieses ausstehende Statusproblem vollständig zu beheben. Ich werde hier updaten, wenn ich etwas verpasst habe, und ich hoffe, das hilft anderen.

Die grundlegende Strategie besteht darin, diese Änderungen an mehreren Dateien im Dateisystem / var / lib / lxc / juju-trusty-lxc-template / rootfs vorzunehmen, BEVOR Sie mit der Bereitstellung von LXC-Containern beginnen. Diese Änderungen wirken sich global auf alle nachfolgend bereitgestellten Container aus. Ersetzen Sie im Folgenden einfach Ihre Schnittstellennamen und Ihr LAN-Netzwerk, und es sollte funktionieren.

Mein Maas Server Setup ist:

Dell PowerEdge 2850, BIOS spätestens A07 rev und Dell BMC Firmware, v.1.83, A10 (diese BIOS- und Firmware-Aktualisierungen sind erforderlich)
15.10 Ubuntu Server Edition auf dem Maas Server; Alle eingetragenen Bare-Metal-Knoten verwenden das 14.04-Trusty-Image von maas.
2 x 1 GB Netzwerkports
enp6s7 192.168.1.37 statische IP
enp7s8 10.207.39.100 statische IP

Meine Bare-Metals sind ebenfalls Dell PowerEdge 2850. Das Dell BMC IPMI ist auf DHCP eingestellt und ruft Adressen im Netzwerk 192.168.1.0/24 ab. Die Bare-Metal-Maas-Netzknoten werden im Netzwerk 10.207.39.0/24 bereitgestellt.

Tweak 1: Da ich zwei Netzwerke nutze, musste ich das Netzwerk 10.207.39.0/24 über das WAN auf 192.168.1.0/24 routen, um von der Außenwelt auf den Maas-Bare-Metal herunterladen zu können LXC-Host (s) über "das Internet". Dies wurde wie folgt erreicht, indem diese Regeln dem Maas-Server hinzugefügt wurden:

sudo iptables -A FORWARD -s 10.207.39.0/24 -o enp6s7 -j AKZEPTIEREN
sudo iptables -A FORWARD -d 10.207.39.0/24 -m Zustand --Status ESTABLISHED, RELATED -i enp6s7 -j ACCEPT
sudo iptables -t nat -Ein POSTROUTING -s 10.207.39.0/24 -o enp6s7 -j MASQUERADE
sudo iptables-save | sudo tee /etc/iptables.sav

Sobald die oben genannten Regeln festgelegt sind, sollte es möglich sein, "nslookup google.com" und "ping -c 3 google.com" von den Maas-eingetragenen Bare-Metal-LXC-Hosts, die auf der 10.207.39.0/24 sind Netzwerk.

Hinweis 1: Enp6s7 ist hier die "internet-connected" Schnittstelle auf dem Maas Server im 192.168.1.0/24 Netzwerk (dh die geht zu dem Router, der von meinem Breitband Internet Service Provider bereitgestellt wird), und 10.207.39.0/24 ist der privates LAN-Netzwerk an der enp7s8-Schnittstelle, die das Netzwerk ist, das Maas und seine Maas-angeworbenen Bare-Metal-Server verwenden.

Hinweis 2: Die Regeln werden auf dem Maas-Server während der Neustarts durch die folgende Zeile permanent gemacht, die vor der Zeile "exit 0" in /etc/rc.local hinzugefügt wurde, wie unten gezeigt:

sudo iptables-restore </etc/iptables.sav
beenden Sie 0

Hinweis 3: Überprüfen Sie, ob die Regeln nach dem Neustart des Maas-Servers wie folgt angewendet wurden: gstanden @ ubuntu: ~ $ sudo iptables -S

-P EINGABE AKZEPTIEREN
-P VORWÄRTS AKZEPTIEREN
-P OUTPUT ACCEPT
-A FORWARD -s 10.207.39.0/24 -o enp6s7 -j AKZEPTIEREN
-A FORWARD -d 10.207.39.0/24 -i enp6s7 -m Status --status VERBINDET, VERBINDET -j ACCEPT

gstanden @ ubuntu: ~ $

Tweak 2: Aktivieren Sie DNS-Lookups auf dem MAAS-Server. Verwenden Sie / etc / network / interfaces (weil ich versucht habe, dies mit /etc/dhcp/dhclient.conf zu tun, und das würde nicht funktionieren), aber es funktioniert mit / etc / network / interfaces. Fügen Sie die Einträge "DNS-Nameserver" und "DNS-Suche" wie unten gezeigt hinzu. Hinweis: Ich habe festgestellt, dass sie zur enp6s7-Spezifikation hinzugefügt werden sollten. Das Hinzufügen zur enp7s8-Spezifikation funktionierte nicht für mich.

gstanden @ ubuntu: ~ $ cat / etc / network / interfaces (Kommentar) Diese Datei beschreibt die auf Ihrem System verfügbaren Netzwerkschnittstellen (Kommentar) und wie man sie aktiviert. Weitere Informationen finden Sie unter Schnittstellen (5).

Quelle /etc/network/interfaces.d/*

(Kommentar) Die Loopback-Netzwerkschnittstelle
automatisch lo
iface Lo inet Loopback

(Kommentar) Die primäre Netzwerkschnittstelle
auto enp6s7
iface enp6s7 inet statisch
    Adresse 192.168.1.37
    Netzwerk 192.168.1.0
    Netzmaske 255.255.255.0
    Gateway 192.168.1.1
    Sendung 192.168.1.255
    dns-suche maas <- füge diesen Eintrag hinzu
    DNS-Nameserver 10.207.39.100 <- füge diesen Eintrag hinzu 

(Kommentar) Die MAAS-Netzwerkschnittstelle
Auto enp7s8
iface enp7s8 inet statisch
    Adresse 10.207.39.100
    Netzwerk 10.207.39.0
    Netzmaske 255.255.255.0
    Gateway 10.207.39.100
    Sendung 10.207.39.255

gstanden @ ubuntu: ~ $

Es gibt eine weitere Optimierung auf dem Maas-Server: Bearbeiten Sie /etc/sysctl.conf auf dem Maas-Controller-Server (nicht auf dem lxc-Bare-Metal-Host), so dass der folgende Befehl das Ergebnis wie folgt liefert:

gstanden @ ubuntu: ~ $ sudo sysctl -p
net.ipv4.ip_forward = 1
gstanden @ ubuntu: ~ $

Hinweis 1: Damit können nslookups und Pings von eingetragenen Bare-Metal-Servern auf dem Maas-Knoten im Netzwerk 10.207.39.0/24, die zu diesem Maas gehören, funktionieren.

Tweak 3: Mehrere Verbesserungen sind notwendig, um stabile Netzwerkdienste innerhalb der LXC-Container selbst zu etablieren. Diese Änderungen an der lxc-Vorlage werden Probleme beim Herunterladen der juju-Tools vom Bare-Metal-lxc-Host beheben und Probleme beheben, die die WAN-Adressen (192.168.1.0/24) lösen und Probleme beheben, die Adressen auf der 10.207.39.0/24 lösen Netzwerk).

Hinweis 1: Das Problem, das aufgetreten ist, war / war, dass Container unabhängig davon, wie die Datei / var / lib / lxc / machine / config optimiert wurde, IMMER eine Adresse im 192.168.1.0/24 Netzwerk erhalten, obwohl sie die juju-br0 Brücke, die eine 10.207.39.0/24 Adresse hat! (Spaß, nicht wahr?); Bei diesem Zwei-Netzwerk-LAN / WAN-Setup ist jedoch letztlich eine Vernetzung mit beiden Netzwerken erforderlich, weshalb in diesem Szenario Routing verwendet wird.

Tweak 3a: ssh ubuntu @ Portly-Beine (Portly-Beine ist der Eintrag Name, die Maas zu meinem Maas-Bare-Metal-lxc-Host gab)

Sudo su -

cd /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/network/interfaces.d/

vi eth0.cfg und füge die folgenden Zeilen zur Datei eth0.cfg hinzu (füge die Zeilen "up ip route ..." und "dns-search maas" hinzu).

Automatisch eth0
iface eth0 inet dhcp
IP-Route hinzufügen 10.207.39.0/24 über 192.168.1.37
dns-suche maas

Die IP-Route-Leitung wird ssh / ping / scp-Konnektivität usw. von den lxc-Containern auf 192.168.1.0/24 (eth0 im LXC-Container) zu dem maas-eingetragenen Bare-Metal-lxc-Host im 10.207.39.0/24-Netzwerk herstellen . Die "dns-search maas" -Zeile ist Teil davon, wie Maas-DNS-Lookups in den LXC-Containern verfügbar gemacht werden, so dass die vollständige DNS-Auflösung einschließlich des Maas-Netzwerks funktioniert. Dies ist besonders wichtig, wenn die lxc-Container auf dem Maas-eingetragenen bare-metal-lxc-Host juju-Tools holen - die lxc-Container werden versuchen, dies vom Bare-Metal-lxc-Host zu holen (in diesem Beispiel ist es 10.207.39.152 was ist portly-legs.maas) und ohne dieses Routing, die Werkzeuge ziehen von der lxc-Host um .152 wird fehlschlagen. Sie können, was dies erfolgreich / fehlschlägt, indem Sie sich in den lxc-Container einloggen und "tail -f /var/log/cloud-init.log" ausführen und Sie sehen, dass die Tools entweder fehlgeschlagen oder erfolgreich ausgeführt werden.

Tweak 3b: Bearbeiten Sie die Datei /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/dhcp/dhclient.conf und fügen Sie diese Zeile hinzu (Sie können die Beispielzeile auskommentieren und ändern):

Domain-Name-Server voranstellen 10.207.39.100;

Anmerkung 1: Dies könnte wahrscheinlich alternativ in /var/lib/lxc/juju-trusty-lxc-template/rootfs/etc/network/interfaces.d/eth0.cfg mit einem Eintrag "dns-nameservers 10.207.39.100" geschehen. aber ich habe in diesem Fall dhclient.conf verwendet.

Ich denke, das ist alles. Sobald alle diese Optimierungen vorgenommen wurden, kann man OpenStack-Komponenten in LXC-Containern in diesem Dual-Netzwerk-Setup bereitstellen und sie kommen so schnell aus dem anstehenden Zustand und in den Bereitschaftszustand wie Flapjacks vom Rost! Bitte lassen Sie mich wissen, wenn ich irgendwelche Schritte verpasst habe, und ich werde versuchen, diese auch zu überprüfen. Aber ich denke, das ist es.

Wenn alle diese Schritte ausgeführt wurden, versuchen Sie, eine OpenStack-Komponente für LXC bereitzustellen und den Fortschritt zu überwachen:

(vom Terminal auf dem Maas-Server als der Benutzer, der die maas-Bereitstellung besitzt): ssh ubuntu @ (IP-Adresse eines Containers)

auf dem Behälter: sudo su - auf dem Container: tail -f /var/log/cloud-init.log und / oder tail -f /var/log/cloud-init-output.log

Wenn Sie eine Nachricht wie diese sehen, sind Sie wahrscheinlich alle gut:

Versuch 1, Werkzeuge von -ttps herunterzuladen: //10.207.39.152: 17070 / tools / 1.25.3-trusty-amd64 ... + curl -sSfw-Tools von% {url_effective} heruntergeladen: HTTP% {http_code}; Zeit% {time_total} s; Größe% {Größe_Download} Bytes; Geschwindigkeit% {Geschwindigkeit_Download} Bytes / s --noproxy * --insecure -o /var/lib/juju/tools/1.25.3-trusty-amd64/tools.tar.gz -ttps: //10.207.39.152: 17070 / Werkzeuge / 1.25.3-trusty-amd64 Werkzeuge von -ttps: //10.207.39.152: 17070 / tools / 1.25.3-trusty-amd64 heruntergeladen: HTTP 200; Zeit 1.698s; Größe 18722171 Bytes; Geschwindigkeit 11026214.000 Bytes / s + Echo Tools erfolgreich heruntergeladen. Tools wurden erfolgreich heruntergeladen.

Wenn Probleme mit dem Netzwerk in den LXC-Containern auftreten, schlägt dies bei mehreren Versuchen fehl. Die obigen Optimierungen sollten diese Probleme vollständig beheben und werden auch innerhalb des LXC-Containers vollständige DNS-Lookups für Bare-Metal-Maas-Server im Maas-Netzwerk bereitstellen (die LXC-Hosts und einzelne Produkt-Hosts wie nova-compute). Container sollten in weniger als 5 Minuten in den Bereitschaftsstatus "Bereit" versetzt werden. Ich bringe sie einzeln nacheinander an und warte darauf, dass jeder den Bereitschaftsstatus erreicht. YMMV, HTH, Gilbert Standen, St. Louis, MO 11. Februar 2016, 1:25 PM CT


1
2018-02-11 23:15