А какую логику закладывать в менеджер кластеризации, если делать таковой? Только по количеству коннектов на узел ориентироваться или с учетом загруженности узла? Или и то и другое вместе?
Если с загруженностью узла связываться, то надо оперировать какой-то системной статистикой. Ибо, завалили узел OLAP-кубом каким-то единственным, а ему ещё пытаются коннектов навязать, мол "бездельничает с одним коннектом"...

Не, ну под Линухом элементарно собирается статистика (под виндой - не в курсе) даже просто через парсинг вывода uptime, free и iostat. Скрипты в cron располагаю с достаточным интервалом запуска. Я со своих серваков в табличку складываю всякое выуженное (длины очередей, количество тех или иных процессов, количество открытых TCP/UDP коннектов на тех или иных портах, количество запущенных процессов тех или иных служб и пр.) и пока графики просто красивые строю, чтоб отслеживать пики нагрузки на службы.
Но можно это применять и для иных целей. Например, для таких вот обсуждаемых: опираться при принятии решения о том, кому физически отдать коннект на обслуживание, как раз на эту вот собранную статистику по загруженности серверов, ориентируясь на последние актуальные длины очереди заданий процессоров и дисковой очереди, утилизацию диска и на свободную память.
Придумать какую-то функцию и весовые коэффициенты предусмотреть в настройках, чтоб гибко управлять логикой менеджера соединений.

Ессессно, жесть "все со всеми" и "облако из облаков" и прочий Адъ адовый можно только приветствовать ;)
Безумству храбрых поём мы песню.
Мне лично пока кластер не нужен. Пока... это тут ключевое, вестимо.