Амулет/МААС в vSphere для тестирования OpenStack
Я имею ниже установки в моей лаборатории vSphere для тестирования развертывания OpenStack с амулетом.
- Сервер МААСА vm имеет 2 интерфейса [у каждого есть доступ в Интернет с помощью прокси и других внутренних 192.168 n/w для dhcp и DNS] (выпуск полный нетерпения)
- Узлы МААСА имеют один интерфейс в 192.168 n/w. (quantal выпуск)
- Имейте Локальное зеркало quantal для узла МААСА к начальной загрузке pxe.
Я могу, загружают мою среду амулета, и один узел под сервером МААСА был Выделен для этого. Поскольку WOL не доступен в vSphere vms, я загрузил тот определенный VM (node3.juju.local) вручную.
После того, как начальная загрузка pxe завершается.
Мои наблюдения
Не способный получить состояние амулета в сервере МААСА. застревание здесь
22.10.2013 6:18:27 ИНФОРМАЦИИ juju.state открытое go:68 вводное состояние; адреса монго: ["node3.juju.local:37017"]; объект""
Таким образом, я вошел в node3.juju.local машину.
последние несколько строк /var/log/cloud-init-output.log
21.10.2013 13:04:56 ОТЛАЖИВАЕТ juju.state, который повторит открытое go:88 отказавшее соединение: наберите tcp 127.0.0.1:37017:в соединении отказано
21.10.2013 13:04:57 ОТЛАЖИВАЕТ juju.state, который повторит открытое go:88 отказавшее соединение: наберите tcp 127.0.0.1:37017:в соединении отказано
21.10.2013 13:04:57 ОШИБКИ juju.agent агент go:470 не удалось инициализировать состояние: никакие достижимые серверы
21.10.2013 ОШИБОЧНЫЙ амулет 13:04:57 supercommand.go:282 никакие достижимые серверы
*21.10.2013 13:04:57 960 - util.py [ПРЕДУПРЕЖДЕНИЕ]: Неудавшееся рабочее 13:04:57/var/lib/cloud/instance/scripts/runcmd [1] 2013-10-21 962 - cc_scripts_user.py [ПРЕДУПРЕЖДЕНИЕ]: Не удалось выполнить пользователя сценариев модуля (сценарии в/var/lib/cloud/instance/scripts) *
21.10.2013 13:04:57 963 - util.py [ПРЕДУПРЕЖДЕНИЕ]: Рабочий пользователь сценариев () перестал работать
Облако-init v. 0,7 законченных в понедельник, 21 октября 2013 13:04:57 +0000. Источник данных DataSourceMAAS [http://192.168.124.10/MAAS/metadata/]. 1 532,83 секунды
Облако-init v. 0,7 выполнения, 'init-локальные' в понедельник, 21 октября 2013 15:53:08 +0000. 3,88 секунды.
Ясно, что MongoDB не запускается, я проверил это путем прохождения через runcmd (облачного-init) сценария и cloud-init-output.log
Версия Mongod установила 2.0.6, и mongod не имел ниже опций опций SSL:
- sslOnNormalPorts используют ssl на настроенных портах
- аргумент sslPEMKeyFile файл PEM для ssl
- аргумент sslPEMKeyPassword пароль файла PEM
который упоминается в runcmd сценарии (облако-init)
*должностное лицо/usr/bin/mongod - автор - dbpath =/var/lib/juju/db - sslOnNormalPorts - sslPEMKeyFile '/var/lib/juju/server.pem' - sslPEMKeyPassword проигнорированный - bind_ip 0.0.0.0 - порт 37017 - noprealloc - системный журнал - smallfiles*
- Какова могла быть проблема? является ли узел Мааса, не имеющий доступ в Интернет, проблемой?
Моя установка juju+LXC полная нетерпения хорошо работает так, я скопировал необходимые двоичные файлы монго с той машины на node3.juju.local машину и перезагрузил сервер на этот раз mongod, запустился, но состояние амулета не дало ниже ошибки (DNS, nslookup все являются надлежащими),
22.10.2013 6:18:27 ИНФОРМАЦИИ juju.state открытое go:68 вводное состояние; адреса монго: ["node3.juju.local:37017"]; объект""
22.10.2013 ОШИБОЧНЫЙ амулет 6:28:27 supercommand.go:282 Не могущий подключить к среде "Маас".
Проверьте свои учетные данные или использование 'начальная загрузка амулета' для создания новой среды.
Детали ошибки:
никакие достижимые серверы
2 ответа
У меня была такая же проблема в очень похожей среде (работала Juju и MAAS в VSphere). Сначала я также подумал, что проблема в MongoDB, поэтому я обновил версию на узле начальной загрузки. Но что решило проблему, так это наличие правильных настроек DNS на узле, на котором вы используете juju-core, потому что он использует FQDN при подключении к узлам. Поэтому убедитесь, что вы можете пропинговать узел начальной загрузки, используя полное доменное имя.
Как сказал Исеин, ваша проблема может быть связана с разрешением DNS для этого конкретного домена, которого нет на вашем сервере MAAS.
Чтобы проверить это, вы можете поместить строку в файл / etc / hosts на первое место:
nameserver <IP address you are using for managing DHCP/DNS on MAAS>
Мне удалось решить ту же проблему, что и ваша, таким образом. Чтобы получить эту модификацию постоянной, вы можете добавить эту строку в "/etc/resolvconf/resolv.conf.d/head"
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver <IP>
Этот файл будет использоваться при запуске resolvconf для создания вашего / etc / файл hosts.