Я хотел бы рассмотреть возможность использования DRBD для репликации данных между первичным и вторичным местоположением. Первоначальный план - установить VPN-туннель между ними; первичный конец, использующий часть двойного канала T1 и настройку вторичного местоположения на линии кабеля / DSL.
Вторичный будет существовать только для аварийного восстановления - он «никогда» не будет реплицироваться обратно на первичный.
Кто-нибудь делал / устал / использовал что-то подобное, и каков ваш опыт с этим.
Linbit также имеет (платный) продукт DRBD Proxy, который должен быть разработан для работы через ссылки типа WAN (сжатие, несколько одноранговых узлов). Кто-нибудь пробовал это?
Я не могу говорить о DRBD Proxy, но обычному DRBD это не понравится.
Даже при ограниченной активности вы можете легко заполнить двойной T1 (2x 1,5 Мбит / с; для круглых чисел 300 КБ / с). 300 КБ / с может быть занято только ведением журнала приложений, не говоря уже о том, чтобы делать что-нибудь интересное на вашем сервере. Это исключает синхронную репликацию (Протокол C), не говоря уже о добавлении в уравнение задержки при передаче через VPN.
Асинхронная репликация (Протокол А) технически может работать, но я ожидаю, что вторичный будет настолько устаревшим, что его нельзя будет использовать в случае сбоя (реплика может отставать на несколько часов в течение дня)
Память синхронная (Протокол B) не поможет, так как все еще ограничена пропускной способностью.
Я ожидаю, что прокси DRBD по-прежнему будет страдать от подобных проблем, в первую очередь вызывающих задержку репликации из-за ограниченной пропускной способности.
Я рекомендую вам пересмотреть свою стратегию аварийного восстановления, чтобы понять, против чего вы боретесь; аппаратный сбой или отказ сайта.
В случае защиты от сбоя сайта вы можете получить лучший результат за счет передачи с более низкой пропускной способностью / более высокой плотностью в случае одного (или обоих) сайтов с ограниченной пропускной способностью. Некоторыми примерами этого метода являются rsync (передача по сети ограничивается изменениями файлов между запусками, а не отдельными изменениями для каждого изменения, плюс некоторые накладные расходы протокола; может выполняться через SSH для дальнейшего шифрования и сжатия трафика) и доставка журналов базы данных (передача сжатых журналов базы данных для воспроизведения на блоке аварийного восстановления может использовать меньшую полосу пропускания, чем передача полного дампа базы данных).
Если вы защищаете от аппаратного сбоя, локальная реплика DRBD, подключенная к кроссоверу GigE, будет работать нормально, обеспечивать полностью синхронные обновления и разрешать онлайн-проверку, чтобы доказать, что данные согласованы на обоих узлах. Вы по-прежнему можете комбинировать этот вариант с ограниченной репликацией файлов на сайт аварийного восстановления для защиты от сбоя основного сайта.
DRBD-Proxy будет работать нормально при условии, что вы не загружаете все время ссылки T1. Мы отправляем множество файлов размером 2 ТБ через соединение DRBD-Proxy (предоставлено 100-мегабитное соединение) без проблем. Если у вас достаточно ОЗУ для прокси, а количество операций записи не так велико, ваш T1 не может справиться с этим, все должно работать нормально. Однако вы можете использовать асинхронный режим для репликации.