использование марионеточной панели инструментов как enc
Я обычно не одобряю RRDNS как механизм увеличения отказоустойчивости. Если Вы действительно хотите большую сеть, то Вы имеете, должен запуститься с твердых стандартных блоков для начала..
Ваши серверы имеют разнообразный маршрут к Интернету? У них есть независимые источники электропитания? Если Вы говорите об истинной отказоустойчивости, то необходимо запустить, много опускают цепочку.
- Двойной (несколько) диски в расположении RAID, которое не является RAID 0.
- Двойные источники питания, обеспеченные двойным избыточным разнообразным кабелем питания.
- Двойной NICs к отдельным коммутаторам
- Двойной Брандмауэр/Маршрутизаторы
- Двойной (или несколько) интернет-поставщики транзита/пиринга, предоставляя маршруты Интернету через BGP
Затем можно начать рассматривать несколько центров обработки данных, который является абсолютно отдельным чайником рыбы. Я являюсь не совсем неблагоприятным RRDNS как решение увеличить дублирование и устойчивость, но начальный материал должен быть на первом месте.
У Вас все еще будут большие проблемы, связанные с ISPs перезапись короткого DNS TTLs, которые требуются для обработки отказа быстрого выхода другому поставщику DNS. Я провел много недель, проводя исследование о лучшем способе гарантировать время работы системы с помощью комбинации устойчивости сетевого уровня, с помощью BGP, а также нескольких записи в DNS и RRDNS. В конце мы решили, что Dynect были лучшим поставщиком DNS для наших потребностей, но YMMV, как всегда.
Всегда стоит выглядеть немного глубже, чем просто IP-адрес Вашего сервера, гарантировать, что отказы оборудования могут быть вынесены комбинацией RAID или несколькими серверами позади подсистемы балансировки нагрузки, и затем можно начать действительно смотреть на масштабируемость/дублирование. Если Вы только получили один сервер с одним диском, и одним nic и одним переключателем, то это - весь немного бессмысленный взгляд мимо этого. Просто обновление всего, чтобы быть парой принесет некоторое душевное спокойствие.
Как системный инженер, я теперь не могу рассчитать немного ниже, чем 2.
Мне удалось это исправить. Как только вся конфигурация была правильной, все работало нормально.
Основными областями были - externode_node должен быть на всех мастерах марионеток и на сервере панели инструментов марионеток. Расположение сертификатов должно быть тем, что создается инструментами rake при включении https на панели управления. Вы можете увидеть их в файле settings.yml на сервере панели инструментов. Убедитесь, что в DASHBOARD_URL вы используете общее имя в сертификате, созданном инструментом rake, в большинстве случаев приборной панелью. Вам может потребоваться настроить c-name для панели инструментов или A-record, если хотите. Убедитесь, что рабочий сценарий external_node скопирован на все главные серверы марионеток и является одинаковым. Я использовал расположение / usr / share / puppet-dashboard / bin / external_node. Убедитесь, что это https: // dashboard или cn сертификата приборной панели. В противном случае вы получите SSL-имя не соответствует certname error
В файле puppet.conf на каждом главном сервере есть 2 строки для включения ENC. Это выглядит следующим образом:
node_terminus = exec
external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=https:// dashboard/usr/share/puppet-dashboard/bin/external_node
См. Имя панели мониторинга - это то же самое, что имя CN в сертификате панели мониторинга. Убедитесь, что вы перезапускаете httpd на каждом мастере марионеток. Если вы все еще читаете это, удачи!