☰

MAAS- und Juju-Post-Bootstrap-Verbindungsfehler

tag-icon • tag-icon server juju maas
MAAS- und Juju-Post-Bootstrap-Verbindungsfehler

Ich arbeite mit einem ziemlich seltsamen Problem bei der Verwendung von MAAS und Juju, bei dem ich nach der erfolgreichen Erstellung des Bootstraps, Maschine „0“, keine Dienste bereitstellen kann, indem ich eine einfache ausstelle juju deploy mysql. Um einen kurzen Überblick über die Umgebung zu geben: Ich verwende MAAS auf Ubuntu Server 13.04 mit der IP 10.0.0.10 und jujuund juju-corelaufen auf demselben Server. Dies alles wird auch in einem lokalisierten Testlabor ausgeführt. Die Ausgabe einer juju statuszeigt Folgendes:

root@maas:~# juju status
2013-04-30 10:24:32,876 INFO Connecting to environment...
2013-04-30 10:24:33,439 INFO Connected to environment.
machines:
  0:
    agent-state: not-started
    dns-name: test4.master
    instance-id: /MAAS/api/1.0/nodes/node-ee044686-b100-11e2-9927-52540089abb8/
    instance-state: unknown
  5:
    instance-id: pending
services:
  mysql:
    charm: cs:precise/mysql-19
    relations: {}
    units:
      mysql/0:
        agent-state: pending
        machine: 5
        public-address: null
2013-04-30 10:24:33,496 INFO 'status' command finished successfully

Die Instanz verbleibt pendingauf unbestimmte Zeit in einem bestimmten Zustand und ein Blick auf das Debugprotokoll zeigt, dass keine Verbindung zum Bereitstellen der Instanz hergestellt wird:

2013-04-30 10:27:26,562: juju.agents.provision@ERROR: Cannot get machine list
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/juju/agents/provision.py", line 175, in process_machines
    provider_machines = yield self.provider.get_machines()
ProviderInteractionError: Unexpected ConnectionRefusedError interacting with provider: Connection was refused by other side: 111: Connection refused.

Da dieser Fehler auf dem Rechner „0“ etwa jede Minute auftritt, habe ich mir einen TCPdump angesehen, um herauszufinden, was los war. Nach einigem Suchen bin ich genau zu dem Zeitpunkt, als der Fehler protokolliert wurde, auf Folgendes gestoßen:

10:27:26.561631 IP 127.0.0.1.33607 > 127.0.0.1.80: Flags [S], seq 1222093882, win 32792, options [mss 16396,sackOK,TS val 454628 ecr 0,nop,wscale 6], length 0
10:27:26.561651 IP 127.0.0.1.80 > 127.0.0.1.33607: Flags [R.], seq 0, ack 1222093883, win 0, length 0

Da Maschine „0“ mit MAAS über Juju bereitgestellt wurde, glaube ich nicht, dass sie auch MAAS ausführen würde. Um das Problem zu beheben, habe ich auf Maschine „0“ einen SSH-Tunnel erstellt, der auf Port 80 (localhost) auf Port 80 des MAAS-Servers lauscht, z. B. 80:MAAS-Server-IP:80. Danach juju statushabe ich die Änderung vorgenommen, um die neue Maschine aus dem Wartezustand zu zeigen:

  5:
    agent-state: not-started
    dns-name: test5.master
    instance-id: /MAAS/api/1.0/nodes/node-fe882bb2-b100-11e2-ba1c-52540089abb8/
    instance-state: unknown

All dies, um zu sagen, kann mir bitte jemand helfen zu verstehen, warum die bereitgestellte Maschine „0“ versucht, eine Verbindung zum lokalen Port 80 und nicht zum MAAS-Server herzustellen? Liegt das daran, dass ich Juju und MAAS auf demselben Server ausführe?

Antwort1

Beim Bootstrapping einer Umgebung müssen Sie auf den Hostnamen in der Datei environments.yaml achten, da dieser anscheinend an nachfolgende Rechner weitergegeben wird. In meinem Fall hatte ich den Server auf eingestellt http://localhost:80/MAAS, wodurch Rechner „0“ und alle anderen Rechner versuchten, eine Verbindung zu localhost und nicht zur IP/zum Hostnamen des MAAS-Servers herzustellen. Nachdem ich meine Umgebung zerstört und sie erneut mit dem Server gebootet hatte http://10.0.0.10:80/MAAS, schien alles korrekt bereitgestellt zu werden. Dies ist ein reines Versehen meinerseits.

verwandte Informationen