Как бы вы поддерживали идентичность .conf на резер. сервере

zubastiy	# 13 лет назад
Темы: 136 Сообщения: 548 Участник с: 18 сентября 2009	Добрый день. Хочу сделать HA сервер (nginx) Доступность по ip обеспечивается ucarp (и даже работает) nginx свои задачи выполняет согласно конфигурации. Осталось только придумать как поддерживать идентчность конфига на резервном сервере после внесения изменений на основном. Пока у меня мысль: повесить incron на отслеживание изменений файла на основном сервере, и в случае изменений копировать файл конфигурации на резервный сервер + релоад сервиса. Если сервер не основной, после изменений забрать конфиг с основного. В целом почти дописал скрипты, но может есть какойнить пакет обеспечивающий требуемый функционал? Ну и как бы делали вы?

# 13 лет назад

Сообщения: 548

Участник с: 18 сентября 2009

Добрый день.
Хочу сделать HA сервер (nginx)
Доступность по ip обеспечивается ucarp (и даже работает) nginx свои задачи выполняет согласно конфигурации.
Осталось только придумать как поддерживать идентчность конфига на резервном сервере после внесения изменений на основном.

Пока у меня мысль: повесить incron на отслеживание изменений файла на основном сервере, и в случае изменений копировать файл конфигурации на резервный сервер + релоад сервиса. Если сервер не основной, после изменений забрать конфиг с основного.
В целом почти дописал скрипты, но может есть какойнить пакет обеспечивающий требуемый функционал?
Ну и как бы делали вы?

sleepycat	# 13 лет назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	вообще вариантов несколько, учитывая разные положения (топологически) концов , взял бы за первую попытку схему rsync <== rsync. Есть и логика и сложность реализации не из области красноглазия. Хотя повторюсь, это не единственный вариант, лишь тот что лезет в голову первый ) . Если похожую задачу ставлю себе для служб, которые не читают свой конфиг переодически, просто ставлю задания в cron для переодического перезапуска демона. Ну понятно, потому что лень стругать скрипт для этого ))) . Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 13 лет назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

вообще вариантов несколько, учитывая разные положения (топологически) концов , взял бы за первую попытку схему rsync <== rsync. Есть и логика и сложность реализации не из области красноглазия. Хотя повторюсь, это не единственный вариант, лишь тот что лезет в голову первый ) . Если похожую задачу ставлю себе для служб, которые не читают свой конфиг переодически, просто ставлю задания в cron для переодического перезапуска демона. Ну понятно, потому что лень стругать скрипт для этого ))) .

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

zubastiy	# 13 лет назад
Темы: 136 Сообщения: 548 Участник с: 18 сентября 2009	эмм. до тех пор пока слейв, лезь на мастер, проверяй md5sum конфиг, если изменился, копируй конфиг себе и отправляй команду на “перечитать” конфиг службы. ставить в крон на повтор 1 (или 5) минуту. в целом понятно, да, но будет переодичная проверка … да, я параноик, но существует вероятность, что конфиг на мастере будет изменен, время для “синхронизации” еще не наступит, и мастер в этот момент свалится = на слейве старый конфиг. ….во! положу файл конфигурации где либо в другом месте, раз в 10 минут оба сервера будут туда лазить и проверять на предмет изменений. тестить конфиг, если конфиг годный, перезапускать сервис, если конфиг не годный, сервис не перазапускать, мейлрепортить. если конфиг не доступен репортить с переодичностью в 15 минут.

zubastiy

# 13 лет назад

Темы: 136

Сообщения: 548

Участник с: 18 сентября 2009

эмм. до тех пор пока слейв, лезь на мастер, проверяй md5sum конфиг, если изменился, копируй конфиг себе и отправляй команду на “перечитать” конфиг службы.
ставить в крон на повтор 1 (или 5) минуту.

в целом понятно, да, но будет переодичная проверка … да, я параноик, но существует вероятность, что конфиг на мастере будет изменен, время для “синхронизации” еще не наступит, и мастер в этот момент свалится = на слейве старый конфиг.

….во! положу файл конфигурации где либо в другом месте, раз в 10 минут оба сервера будут туда лазить и проверять на предмет изменений. тестить конфиг, если конфиг годный, перезапускать сервис, если конфиг не годный, сервис не перазапускать, мейлрепортить. если конфиг не доступен репортить с переодичностью в 15 минут.

ProFfeSsoRr	# 13 лет назад
Темы: 82 Сообщения: 948 Участник с: 14 мая 2009	Есть же Chef, Puppet… csync2 на худой конец!

zubastiy	# 13 лет назад
Темы: 136 Сообщения: 548 Участник с: 18 сентября 2009	ProFfeSsoRr Есть же Chef, Puppet… csync2 на худой конец! Я в “соседней” теме про делегирование прав пришел к этому же выводу )) но csync2 - ~~интересно тоже!~~ то что нужно для HA, спасибо, именно на такую тузлу я и надеялся.