Вы не совсем меня правильно поняли. Я не имел ввиду бэкап в обычном смысле - это совершенно отдельное действие и к кластеру отношения не имеет.
Вы хотите получить отказоустойчивость. Это значит, что какие-то ресурсы выделяются под обеспечение избыточности. То есть у Вас есть три сервера, но на них используется 60% ресурсов, остальные резервируются в предположении что один из серверов сляжет и сайты переедут на оставшиеся. Соответственно каждый сайт должен иметь копию базы и файлов на другом сервере. Такие копии можно сделать для mysql блокированием таблиц и rsync (хотя тут надо не забыть проверять не только размер и даты), для файлов тоже rsync но в ускоренном варианте.
Я не уверен, что такая схема сработает для очень больших объёмов достаточно быстро, но во всяком случае, в отличии от бэкапа, перенос сайта на резервный сервер будет происходить очень быстро - время уйдёт на копирование конфигурации и добавление виртуальных хостов в апач. Бэкапить , кстати, возможно будет проще с резервных копий - они не задействованы и их не нужно дополнительно блокировать.
Схема не совсем реализует отказоустойчивый кластер, она не делает мгновенной копии всего сервера, скорее это продвинутый бэкап. Но скорость восстановления после падения будет очень большой.
Мне кажется, что на рынке хостинга дикая конкуренция, поэтому хостинг на одном-двух серверах вообще нет смысла проектировать. Следовательно, надо либо большие деньги привлекать, либо просто настроить бэкап и делать его почаще на резервный компьютер.
этих форков путти вагон, вот только живут они недолго - авторы быстро понимают что поддерживать трудно и смысла нет - желающих перелезть с putty мало.
if failed port 7717 then restart
наверно, поэтому перегружает?
Всё ниже моё ИМХО. На эту тему можно дискутировать долго.
Вкратце - без внешнего хранилища это можно сделать только если есть на постоянную работу грамотный администратор. Судя по всему, уровнем несколько выше форумных админов... Путь тупиковый, если речь не идёт о большом проекте. ПО бесплатное, админ очень даже платный. Это будет ориентированный конкретно на Вашу задачу кластер. Думаю, что первые кластеры хостеры именно так и делали. Выделить mysql серверы в отдельную группу, как-то их синхронизировать. Файловые системы либо реплицировать время от времени полностью, либо копировать только пользовательские данные - потери будут, без потерь будут с кластерными файловыми системами но с ними тоже непросто да и небесплатно. Если серверов много, в конце концов придётся разбивать их на отказоустойчивые группы... в общем задача сложная и не очень надёжная без постоянного обслуживания.
Сейчас кластеры развиваются в сторону модного слова "облако". С внешним хранилищем это сделать уже проще - XenServer (платный) , например, обеспечит почти из коробки отказоустойчивость, причём будет решение с одной стороны простое и шаблонное, с другой стороны надо будет всё же очень хорошо понять что же получается и где ждать подводные камни. Но это уже не столько сложно в плане администраторском, сколько в финансовом - системы хранения, тем более с отказоустойчивость, стоят дорого. Можно сделать самодельную iSCSI систему за копейки, но о её надёжности говорить всерьёз нельзя.
Вообще есть, конечно, Xen Cloud - и там требования прописаны, тоже не бюджетно.
Требования надо бы привести в нормальный вид без фантастики (внешне это должно быть в виде одной единой машины - это фантастика).
Про стоимость никто не скажет без описания задачи - 2 сервера это одно, 3 сервера это другое, а линейный апгрейт - это уже совсем другая задача.
вообще говоря ftp - нормальный по скорости протокол, для бинарных файлов ssh будет медленнее. Если скорость критична, используется специальный софт для передачи файлов там и многопоточность, и изменение размеров пакетов, и UDP вместо TCP.
Наверно, тут терминологическая путаница. То, что может слушать трафик - это не кейлоггер, это снифер. А кейлоггер - это то, что ставится у вас в локальной системе.
lkl ? Только под виртуалками и на боевых серверах не надо запускать.
там не только ребут, но и пересборка не нужна.
может быть, проще сделать список каталогов которые будут копироваться, и воспользоваться, например, для debian --get-selection для копирования системы.
