Добрый день, коллеги.

Интересует следующая тематика - механизмы/тулзы/архитектурные решения и прочее относящееся к управлению (администрирование, обновление) кластеров, состоящих из большого количества application серверов (10-20), да и большого количества самих кластеров (каждому клиенту понадобится собственный кластер, и таких клиентов - десятки).
Буду благодарен за любую информацию по этой теме - может кто-то имеет соответствующий опыт или знает подходящие статьи/книги или просто хочет поделиться идеями? 
Application server - JBoss 4.2. 
Желание заказчика - ес-сно, работа 24x7.

В частности, интересуют вопросы обновления, хотдеплоймента серверов. Мы в определённый момент отказались от поддержки полноценного хотдеплоймента (уж очень трудозатратен в отношении времени разработчиков, да и вообще, не всегда он возможен в принципе) - часть компонентов по-прежнему допускает горячее обновление, часть требует перезапуска сервера. Предполагаем обновление кластера как поочерёдную остановку/обновление/запуск каждого из узлов. В случае JBoss здесь сразу видна следующая проблема - при остановке узла, на котором запущены singleton-сервисы (например, JMS) - сам кластер на некоторое время перестаёт быть полнофункциональным, т.к. имеется довольно-таки существенный временной интервал (до нескольких минут), когда сервисы уже остановлены на старом "главном" узле, а на новом ещё не стартовали. Существуют ли какие-то стандартные решения подобных проблем? Кто как борется?  Самое напрашивающееся решение - вынести синглетон-компоненты на отдельный узел, на котором будет минимум других сервисов, соответственно, обновлять его нужно будет реже. В связи с этим ещё более частный вопрос - как можно влиять на выбор "главного узла" в кластере JBoss?

Похожая проблема с базами данных - как правильно обновлять их у разных клиентов, отслеживать что здесь поменяли, здесь нет и прочее. Может быть существуют автоматизированные тулзы, обновляющие бд, отслеживающие разные версии структуры данных и т.п.?

Возможно ли вообще, в принципе, при увеличении кол-ва узлов/кластеров избежать пропорционального увеличения обслуживающего технического персонала?