PuppetDB: Не удалось отправить 'команду' фактов замены
можно сбалансировать входящий трафик к веб-серверу на обеих бледных строках с входящей подсистемой балансировки нагрузки. Существует подсистема балансировки нагрузки с сервером DNS в них (www.alvaco.com), подсистема балансировки нагрузки соединится и со строками WAN и со стороной локальной сети подсистемы балансировки нагрузки, может соединиться с Вашим брандмауэром или непосредственно в Вашу LAN. Домен для Вашего веб-сайта должен быть размещен в lb, таким образом делая lb SOA или родительским сервером DNS для того домена. Это выполняется путем движения в регистратор доменных имен, и наличие их изменяет Родителя DNS для домена к дюйм/с, которые завершаются в подсистеме балансировки нагрузки. От той точки на любой запрос относительно любого A или другой записи прибудет в подсистему балансировки нагрузки, которая будет разрешена. Так как подсистема балансировки нагрузки имеет также 2 бледных строки, подключенные к нему, это предложит IP строки, которая является лучшей для него. Баланс загрузки будет входящее выравнивание нагрузки и обработка отказа (если одна строка снизится, то это не предложит тот IP).
Я понял, но не могу сказать точно какие шаги были необходимы или нет.
Эта проблема возникла из-за того, что проверка подлинности на нескольких хостах была медленной или зависала и, по-видимому, была связана с проблемами контроллера домена / кеша DNS. Удаление записи domain mydomain.com из / etc / resolv. conf на мастере марионеток и агенты решили проблему, но это создало проблемы с существующими сертификатами марионеток. Я запустил puppet cert clean --all на главном сервере, чтобы попытаться воссоздать все сертификаты, но это не помогло PuppetDB.
Решение
Очистить старые сертификаты на главном сервере:
puppet cert clean --all
Очистить старые сертификаты для всех агентов:
rm -rf / var / lib / puppet / ssl
Восстановить хранилища ключей PuppetDB:
facter fqdn недоступен после удаление домена foo.com из /etc/resolv.conf . Это приводит к тому, что puppetdb-ssl-setup завершает работу без уведомления.
Отредактируйте / usr / sbin / puppetdb-ssl-setup , добавьте фрагмент кода, чтобы использовать только имя хоста facter , если facter fqdn пусто:
# near line 10
fqdn=`facter fqdn`
# add this "if" section
if [ ! -n "$fqdn" ] ; then
fqdn=`facter hostname`
fi
Исправление разрешений:
chown -R puppetdb:
Возникла аналогичная проблема. Решение:
1.) Удалите pid-файл pe-puppetdb на главном сервере. 2.) остановить службу pe-puppetdb на мастере 3.) запустить службу pe-puppetdb на мастере подождите 30 секунд.
Это также происходит, когда ваши настройки памяти для puppetdb слишком малы.
vim /etc/default/puppetdb
Измените строку
JAVA_ARGS="-Xmx192m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof -Djava.security.egd=file:/dev/urandom"
, которая должна стать
JAVA_ARGS="-Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/puppetdb/puppetdb-oom.hprof -Djava.security.egd=file:/dev/urandom"
, и перезапустите puppetdb
sudo service puppetdb restart
У меня была аналогичная проблема после обновления мастера марионеток (включая puppetdb с 1.6.3 до 2.3.8) с 3.7.x до 3.8.x и появилось следующее сообщение об ошибке:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for puppet-client to PuppetDB at puppetmaster:8081: Connection refused - connect(2)
Решением для этого было, с одной стороны, перезапуск puppetdb, а с другой стороны, также перезапуск клиента марионеточного агента. После этого агент смог продолжить свою работу.