Я использовал такие инструменты, как марионетка, для управления отдельными системами, и в целом с большим успехом. Марионетка падает из-за того, что она не годится для управления зависимостями вне отдельного сервера.
Например, на сервере MySQL я настраиваю puppet для выполнения следующих действий:
В этом наборе шагов решен ряд зависимостей - например, я не могу запустить службу базы данных, пока не установил пакеты, чего я не могу сделать, если репозиторий apt не настроен правильно.
Этот сервер MySQL представляет собой одну коробку в настройке репликации master-> master. В идеальном мире марионетка (или другой подобный инструмент) позволила бы мне представить тот факт, что серверу B нужно дождаться, пока сервер A станет доступен, а затем попытаться установить с ним отношения репликации.
Здесь много текста - в основном я спрашиваю: есть ли какие-нибудь инструменты, такие как марионетка, которые могут управлять такими межмашинными зависимостями?
Если вы используете Puppet, тогда экспортированные ресурсы (и поэтому сохраненные конфигурации) являются инструментом для работы. Это позволяет вам обмениваться информацией между узлами. Включая фактические настройки репликации, если необходимо.
В качестве альтернативы, и хотя я сам не являюсь подписчиком, некоторые люди считают свои манифесты / прогоны недетерминированными. Это означает, что один запуск не обязательно объявляет полный результат узла. Может потребоваться два или более прогона, прежде чем узел достигнет желаемого состояния.
Поскольку настройка ведомого MySQL до того, как ведущий станет доступным, не будет полностью фатальной, вы можете пойти по этому пути. На мой взгляд, это не так уж и "умно".
Я не являюсь марионеточным пользователем, я уверен, что другие подскажут более подходящие ответы, но похоже, что сценарий оболочки может быть относительно легко реализован, который проверяет перед запуском службы.
Puppet прекрасно справляется с этим. Попросите каждый сервер экспортировать ресурс, чтобы настроить другой соответствующий сервер (-ы) для выполнения необходимых действий после того, как они будут запущены. У меня нет примера для MySQL, но мы настраиваем много (например, около 80, по текущему подсчету) таким образом ресурсы DRBD, а также все наши конфигурации Nagios.
Уровень контроля вполне может быть то, что вам нужно. Вы можете использовать его вместе с марионеткой, поэтому кривая обучения не должна быть слишком крутой.