DRBD Proxy / WAN

9

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

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

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

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

Джефф Хенгесбах
источник

Ответы:

6

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

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

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

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

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

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

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

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

Грег Ворк
источник
Спасибо Грег. Я фактически говорил с Линбитом с момента публикации вопроса, и прокси-продукт звучит очень многообещающе. В частности, рассматриваются задержки, потеря соединения и каналы с низкой пропускной способностью. Они используют его внутри США и за границей через линию задержки 200 мс (хотя и не уверены в пропускной способности). У меня есть демо на следующей неделе, чтобы узнать больше. Решение должно быть на уровне блоков, чтобы ssh / rsync не подходил.
Джефф Хенгесбах
Мне было бы очень интересно услышать результаты вашей демонстрации. Удачи!
Грег Ворк
2
Прокси-продукт представляет собой «более-менее» буфер на основе ОЗУ со сжатием. Ключ имеет достаточно оперативной памяти (и пропускной способности) для обработки скорости изменения данных. Таким образом, отличная идея для офисных документов, баз данных с низким уровнем транзакций и небольших данных, вероятно, не подходит для мультимедиа, образов виртуальных машин и других больших изменений данных.
Джефф Хенгесбах
1

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

davidgo
источник