Добрый день.
Имеется два сервера, соединенные медленной сетью (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, которая помечает записанные области для передачи разницы, а не выявляет ее параллельным считыванием двух устройств.
Заранее спасибо.
