DRBD Proxy / WAN

Я хотел бы рассмотреть использование DRBD для репликации данных между первичным и вторичным местоположением. Первоначальный план заключается в создании VPN-туннеля между ними; первичный конец, использующий часть двойной линии T1 и вторичный параметр местоположения на кабеле / ​​линии DSL.

Вторичный сервер будет существовать только для DR - он никогда не будет реплицироваться обратно на первичный.

Кто-нибудь сделал / устал / использовал что-то подобное и каков ваш опыт с этим.

У Linbit также есть (Платный) продукт DRBD Proxy, который, как предполагается, предназначен для работы через каналы типа WAN (сжатие, несколько узлов). Кто-нибудь пробовал это?

Я не могу говорить о DRBD Proxy, но обычному DRBD это не понравится.

Даже при ограниченной активности вы можете легко насытить двойной T1 (2x 1,5 Мбит / с; для круглых чисел 300 КБ / с). 300 КБ / с может быть занято только регистрацией приложений, не говоря уже о том, чтобы делать что-нибудь интересное на вашем сервере. Это исключает синхронную репликацию ( протокол C ), не говоря уже о добавлении задержки в vpn в уравнение.

Асинхронная репликация ( протокол A ) может технически работать, но я ожидаю, что вторичное устройство будет настолько устаревшим, что его нельзя будет использовать в случае сбоя (реплика может задерживаться на несколько часов в течение дня)

Синхронизация памяти ( протокол B ) не поможет, поскольку она все еще ограничена пропускной способностью.

Я ожидаю, что DRBD Proxy все еще будет страдать от подобных проблем, в первую очередь вызывая задержку репликации из-за ограниченной пропускной способности.

Я рекомендую вам пересмотреть свою стратегию аварийного восстановления, чтобы понять, против чего вы боретесь; аппаратный сбой или сбой сайта.

В случае защиты от сбоев на площадке вы можете получить лучшее преимущество от переносов с более низкой пропускной способностью / более высокой плотностью в случае одного (или обоих) сайта с ограниченной пропускной способностью. Некоторыми примерами этого метода являются rsync (беспроводные передачи ограничены изменениями в файлах между прогонами, а не отдельными изменениями для каждого изменения - плюс некоторые издержки протокола; может выполняться по SSH для шифрования и дальнейшего сжатия трафика) и доставка журналов базы данных (передача сжатых журналов базы данных для воспроизведения на блоке DR может использовать меньшую пропускную способность, чем передача полного дампа базы данных).

Если вы защищаете от аппаратных сбоев, локальная реплика DRBD, связанная с кроссовером GigE, будет работать нормально, позволит выполнять полностью синхронные обновления и позволит выполнять онлайн-проверку для подтверждения согласованности данных на обоих узлах. Вы по-прежнему можете комбинировать эту опцию с ограниченной репликацией файлов на сайт DR для защиты от сбоя основного сайта.

DRBD-Proxy будет работать нормально при условии, что вы не насыщаете каналы T1 все время. Мы отправляем много файлов размером 2 ТБ по соединению DRBD-Proxy (предоставляется со 100-мегабитной ссылкой) без проблем. Если у вас достаточно оперативной памяти для прокси-сервера и количество записей не так велико, ваш T1 не может справиться с этим, он должен работать нормально. Вы хотели бы использовать асинхронный режим для репликации, хотя.