"Если ты молоток - весь мир кажется гвоздями". А поделитесь опытом сношения ~1Тб баз mysql, xtrabackup, и костылями в виде bacula вокруг этого. Также поделитесь временем восстановления, а я скажу сколько этот простой будет стоить в деньгах, для одной конкретной компании.
PS: "Например" != "для этого"
В xml файле который является экспортированной картой сетей, есть названия изображений которых нет в zabbix (в который импортируется карта). Поэтому любые изображения внедрить - не поможет. Нужны картинки с конкретными именами (см. выше). Изображения добавляются через web морду zabbix, в администрировании.
Ну вообще rs.conf() не конфигурирует текущий мастер, а конфигурирует replicaset. А на текущем мастере необходимо запустить для распространение новых настроек replicaset на все ноды реплики.
Что значит ручная работа? В данной схеме, при выходе мастера 0 из строя, мастером станет 1 или 2, после возвращения мастера и актуализации на нем данных мастером станет 0. Это будет происходить в автоматическом режиме. rs.reconfig(cfg, { force: true } ) принудительно, после расстановки приоритетов, делает мастером 0. Если принудилово не нужно или просто добавились еще ноды достаточно — rs.reconfig(cfg)
Облако даст гибкие возможности по замене физического железа, по миграции нагруженных хостов между физическими машинами и конечно более высокую плотность размещения, но не по объединению памяти/cpu в единый массив.
Вы совсем не поняли тех букв, что я написал выше.
Еще раз, проблемы у вас возникнут когда хост, на котором закончилась память, захочет в нее записать еще, условно, 4гб которые должны будут передаться по сети на ноду кластера. Пропускная способность сети в 50-150 раз меньше пропускной способности памяти. Это означает, что для записи и считывания 4гб в локальную (физическую память) потребуется ~0,4сек, а при использовании кластера эта-же операция займет ~32сек И это грубая математика, т.к. сюда вмешается время на tcp/ip + возможно io операции. Именно по этой причине, по причине не целесообразности создания подобных решений вы не можете найти их реализаций.
В таком случае выход один — балансировщик с обратной связью.
Все пишется в одну очередь.
Эту очередь читает 1 консьюмер, задача которого — получение информации о загруженности серверов и маршрутизация в 2 очереди srv1q и srv2q.
На серверах srv1, srv2 висит по консьюмеру на соответствующих очередях.
Проблема в том, что ситуация на серверах может меняться очень быстро и через секунду информация может быть не актуальной.
Прежде чем городить что-то монструозное, рекомендую ознакомиться с этой статьей одного из моих коллег, вполне может быть, что это и есть решение habrahabr.ru/post/153431/
PS: "Например" != "для этого"