Прямо сейчас я использую DRBD для репликации двух каталогов (/ var / www и / var / spool / mail) на двух разных VPS XEN, и они находятся на расстоянии 7000 миль друг от друга! Кроме того, я использую прозрачный туннель IPSec VPN для подключения обоих узлов на частном уровне, это не кажется честным, я знаю, прямо сейчас я помещаю папки (www и mail) в каталог DRBD и просто мягко -Свяжите их с каждой машиной, она работает и реплицируется, но поскольку у меня слишком большая нагрузка на сетевом уровне (расстояние и безопасность), скорость чтения / записи на мой диск ужасна, я открываю веб-страницу за 6 минут и даже больше, у меня есть почта задержки, и в конце дня я сталкиваюсь с (двойным разделением мозга), и оба узла перезапускаются, поэтому, когда DRBD переносит оба узла в качестве вторичных, процесс монтирования никогда не произойдет, что приведет к отсутствию активного корневого документа для запуска apache и именно в этот момент избыточность убивает доступность!
Я пытаюсь снять нагрузку с раздела DRBD, чтобы немного ускорить процесс, поэтому я скопировал оба каталога обратно в их исходное местоположение и сделал мягкую ссылку на каждый из них в разделе DRBD, но это никогда не сработало, прямо сейчас мне нужно хорошие предложения! (Я использую OCFS2 BTW для раздела DRBD)
А как насчет «не реплицируйте для начала более 7000 миль медленного канала с высокой задержкой».
Репликация на уровне DRDB имеет свое место, но вы в основном злоупотребляете ею: она была разработана ТОЛЬКО для сценариев с низкой задержкой и высокой пропускной способностью. Вы также можете использовать его «асинхронно» в сценарии аварийного восстановления, когда допустимо потерять некоторые данные, поскольку репликация отстает и догоняет.
Если вы не находитесь в одном из этих двух сценариев, просто забудьте об использовании чего-то вроде drdb. Организуйте локальные данные в центрах обработки данных и используйте репликацию и резервное копирование для разумной работы.
Например, не имеет смысла копировать почтовый ящик. Веб-тупик (сайты и т. Д.) - тоже бессмысленно, поскольку вы можете использовать другие инструменты для распространения этих данных.
Если вы возьмете особую технологию использования, игнорируйте ограничения и поместите ее в ситуацию, которая не предназначена, потому что вы получите именно ту катастрофу, которую описываете здесь.
DRDB - это функция высокой доступности для локальных машин. Это позволяет заменить файловую систему в случае сбоя машины. Он не предназначен для обработки сценариев WAN, если вы не используете асинхронный режим, а это «выписывание» (т. Е. Создание копии во внешнем расположении). И даже в этом случае у вас все еще должна быть пропускная способность, чтобы справиться с этим - а это может быть обременительным (например, 1 Гбит +).
Как указали TomTom и ThatGrameGuy, ваше проектное предположение (что вы можете добиться желаемого с помощью DRBD) ошибочно. DRBD полезен для синхронизации блочных устройств (так говорится в названии: Distributed Replicated Заблокировать устройство). Вы мог теоретически используйте его в своем текущем сценарии, как описывает TomTom (асинхронный режим, для случаев, когда можно потерять некоторые данные), но вы не описываете ничего, где могла бы существовать такая ситуация.
Также кажется, что вы делаете это намного сложнее, чем должно быть: похоже, вам просто нужна простая «первичная / вторичная» среда.
Для веб-материалов
Веб-сайты периодически меняются. Достаточно легко сделать резервную копию веб-сайта, которую можно восстановить на удаленном сервере (или сохранить все в системе контроля версий, или использовать систему управления конфигурацией, чтобы «протолкнуть» веб-сайт на несколько серверов).
Для баз данных
В наши дни веб-сайты часто опираются на базы данных (обычно это единственная часть, которая изменяется «постоянно»), но каждый механизм базы данных, который стоит использовать, имеет какую-то возможность репликации (вы говорите, что уже используете это).
Правильно настроенная репликация БД путь лучше, чем DRBD для репликации баз данных, потому что удаленный механизм БД гарантирует тот же уровень ACID, что и главный сервер.
Для электронной почты
Как сказал TomTom в своем ответе, нет смысла копировать вашу исходящую почту.
Если вы потеряете главный сервер с одним или двумя электронными письмами в очереди, ваши пользователи могут повторно отправить их, и в любом случае это крайний случай, потому что, если сервер получателя не отключен, электронная почта отключится от вашей системы через несколько секунд. Не о чем беспокоиться.
Еще одна история с почтовыми ящиками людей: вот и захочешь резервные копии (или почтовая система, поддерживающая репликацию). Это может означать, что есть час или день, когда люди не имеют доступа к своей старой электронной почте, когда вы переключаетесь на вторичный сервер (пока вы восстанавливаете старое сообщение), но обычно это нормально, потому что они получают свои ток электронные письма. Если время восстановления неприемлемо, вы можете непрерывно восстанавливать резервные копии на вторичный сервер (или использовать что-то вроде rsync для синхронизации почтовых ящиков каждые несколько часов).
В том, что я описал выше, есть пара крайних случаев, о которых вам следует знать.
Во-первых, если ваши серверы «очень заняты», вам может потребоваться правильно сбалансировать нагрузку (используя что-то вроде HAProxy для распределения веб-запросов между «интерфейсными» серверами и перемещения почты и БД на их собственные серверы). Вот как правильно масштабировать.
Техническое объяснение компьютерной науки: взлом DRBD, требования к пропускной способности с DRBD близки к O (N ^ 2), где N = количество узлов, решение, которое я обрисовал, составляет примерно O (N), где N = количество DR сайтов - а количество DR-сайтов вряд ли превысит 2).
Во-вторых, если ваши веб-серверы записывают данные в локальную файловую систему, вам нужно будет перестроить это решение (хранить файлы в базе данных или в базе данных NoSQL, такой как MongoDB, или на центральном сервере хранения (через NFS или что-то подобное). , и, возможно, репликация ЭТОГО с помощью Async DRBD в ваше удаленное местоположение для аварийного восстановления в режиме, близком к реальному времени) - в основном какое-то решение, гарантирующее, что записи в локальный файл станут доступными для всех других «клиентских» серверов.