@stvorl

Репликация диска по DRBD через медленную сеть, или иное решение?

Добрый день.

Имеется два сервера, соединенные медленной сетью (100Mb/s или еще хуже, через реальный интернет).
Один из серверов - основной, из второго хочется сделать что-то вроде "теплой" замены.

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

Виртуалкам нарезаны логические тома из LVM, LVM уложен на исходном разделе размером, допустим, 2 Тб.
Хочется сделать так, чтобы этот раздел постоянно копировался на резервный сервер "как есть", со всеми данными и метаданными LVM внутри.

Логичным решением представилось DRBD. Был заведен ресурс, на основном сервере он объявлен Primary, на резервном - Secondary. В случае сбоя основного сервера предполагается просто включить резервный, объявить на нем раздел Primary и запустить все виртуалки.

Технически все заработало, но проблема оказалась в сети - она медленная. В тестовом примере 100Mbit/s, в реальности будет 30-50. Все изменения, которые пишутся на Primary раздел, пытаются онлайн втащиться на Secondary. В результате, скорость IO записи на Primary падает до 11MB/s, и латентность тоже слишком высокая. На минуточку, сам физический диск - SSD, который примет 500MB/s, а тут - 11.
А на одной из виртуалок - база 1С, которой нужна высокая скорость записи. С 11 MB/s она просто не будет шевелиться.

Меня бы устроил вариант, при котором Primary принимал бы от пользователей данные со скоростью дисковой подсистемы, а на Secondary они бы передавались по мере возможности. Допустим, если раз в сутки-двое сойдутся звезды, и синхронизация догонит актуальное состояние диска, меня устроит. Волатильные данные копируются иным способом, ценна сама упряжка из виртуалок, и операционных систем на них. Для обеспечения консистентности Secondary, DRBD умеет создавать снапшоты между моментами полной синхронизации (пока еще не тестировал, и в конфиге этого нет).

Я могу, допустим, выключать Secondary, и включать его только на ночь. Тогда, когда Secondary отключен, скорость записи на Primary просто превосходна, а затем Secondary включается и принимает разницу. Но тогда будет низкая скорость записи ночью, что приведет к дискомфорту пользователей.

Вроде бы, с 8.4, DRBD умеет режим отложенной синхронизации AHEAD/BEHIND, который позволяет Primary уходить вперед, за счет временной неконсистентности Secondary. Но я хоть убей - не могу его настроить. Все равно запись на Primary осуществляется со скоростью сети, и устройства синхронны - отрыва в AHEAD/BEHIND не происходит.

Помогите, пожалуйста. Я сломал всю голову. Что я делаю не так?

Конфиг тестовой среды:

resource data {
    device /dev/drbd1;

    syncer {
        rate 80M;
    }

    startup {
        wfc-timeout 10;
        degr-wfc-timeout 10;
    }

    on XVMS0 {  // тут Primary
        address 192.168.0.248:7789;
        disk /dev/sdf;
        meta-disk /dev/vgaux/drbd_meta_sdf;
    }

    on XVMS1 {
        address 192.168.0.249:7789;
        disk /dev/vgmain/drbd_test;
        meta-disk /dev/vgaux/drbd_meta_test;
    }

    disk {
        al-extents 25600;
    }

    net {
        protocol A;
        on-congestion pull-ahead;
        congestion-fill 10G;
        congestion-extents 100;  // пробовал и большие значения, ближе к al-extents.
        data-integrity-alg sha1;
    }
}


Может быть вообще есть другие решения, не DRBD?

У меня есть мой скрипт для дифференциальной синхронизации блочных устройств по сети. Он прекрасно бы подошел, если бы синхронизация нужна была бы раз в месяц. Проблема в том, что он приводит к вычитыванию обоих устройств, что для 2 Тб HDD неоправданно долго, почти 10 часов. Хочется именно той фишки DRBD, которая помечает записанные области для передачи разницы, а не выявляет ее параллельным считыванием двух устройств.

Заранее спасибо.
  • Вопрос задан
  • 235 просмотров
Решения вопроса 1
@stvorl Автор вопроса
Грустно все, короче, и плохо.

DRBD будет работать в желаемом мной "полностью асинхронном" режиме только через DRBD-proxy. Который - коммерческий продукт от LINBIT, и стоит он столько, что они даже не выкладывают ценник, а предпочитают выставлять коммерческие по почте.
По разрозненной информации - единицы тысяч долларов в год. Для моего случая это неоправданно дорого.

Пришел к выводу, что повышу размер активной области, и буду подключать второстепенную ноду по ночам, когда почти никто не работает. Через гигабитный линк, т.к. от разнесения нод через интернет придется отказаться из за того, что синхронизация за ночь, высоковероятно, успевать выполниться не будет.

Других решений, которые позволяют синхронизировать блочные устройства (не файлы) дифференциально, я не нашел.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
@rPman
Не помогу с онлайн репликацией файловой системы, но вот значительно (на порядки) ускорить процесс резервного коприрования и получения дифов - использование btrfs и его снапшоты

Делаете регулярные снапшоты, хоть поминутные (но лучше интегрировать их создание как то в логику приложения, например когда не происходит записи, так как момент создания снапшота не требует времени, это не повлияет значительно на работу программы, но зато сам снапшот бьудет содержать консистентные данные), затем сравниваете самый ранний неотосланные с последним на primary:
btrfs send --no-data -p /snapshots/parent /snapshots/child

получаете стрем, которые отправляете на backup сервер и разворачиваете:
btrfs receive /backup/snapshots

https://serverfault.com/questions/399894/does-btrf...
Ответ написан
@Drno
Виртуалки квм?
Сделайте репликацию, как в proxmox к пррмеру
Ответ написан
@mayton2019
Ent. Software engineer. Oracle. SQL. BigData.
1) Очень сильно удивлен тем что делает автор. Категорически нельзя бэкапить базы данных через реплики образов. Или на это время БД нужно останавливать. Есть риск что всё что накопировал автор - будет бесполезным хламом т.к. после восстановления БД не поднимется. Будет много corruped block. И неконсистетных данных.

Поэтому вопрос - автор ты вообще пробовал восстановить весь комплекс с такого неконсистентного бэкапа?

2) Если база 1С стоит на MySQL или на PG то надо использовать коробочные утилиты дампа my*, pg* dump.
Ответ написан
FoxCloud
@FoxCloud
Хостинг и облачные сервисы
Здравствуйте!
От простого к сложному, попробуйте следующее:

1. Сбросить настройки bios по умолчанию.
Зайдите в BIOS (F2 или DEL), нажмите сбросить настройки, сохраните и выйдите.
Нажмите F12 или F11, чтобы вызвать меню выбора загрузки. Проверьте, возможно, флешка будет видна.
2. В BIOS переведите режим с EUFI или Legacy на =>> Dual Boot.
3. Включите распознавание USB в BIOSе
Точно где эта функция находится в вашем BIOS не известно, но она есть где-то.

Желаем победить данную проблему!
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы