Disk replication for DRBD over a slow network, or another solution?

Good afternoon.

There are two servers connected by a slow network (100Mb/s or even worse, through the real Internet).
One of the servers - the main, from the second I want to do something like a "warm" replacement.

On the server, eventually, collected, concatenated in a clever system, and the spinning of different virtual machines on which users are working around the clock, but at night - very little, and sometimes nothing at all.

Virtualcom sliced logical volumes from LVM, LVM stacked on the original partition size, say 2 TB.
I want to make sure that this section is regularly copied to the backup server "as is", with all data and metadata LVM inside.

The logical solution was presented by DRBD. Was opened the resource on the primary server it is declared to be Primary, backup - Secondary. In the event of a failure of the server it is supposed to just include backing, to declare it a Primary partition and run all new path.

Technically it worked, but the problem was the network - it's slow. In the test example, 100Mbit/s, in reality it will be 30-50. All changes are written to the Primary partition, try online to Vasilisa on Secondary. As a result, IO speed of entry to Primary drops to 11MB/s, and latency is also too high. For a moment, the underlying physical disks - SSD, which will take 500MB/s, but here - 11.
And one of virtuallock - base 1S, which need a high write speed. With 11 MB/s it just won't move.

I would have made a variant in which a Primary would take users data with the speed of the disk subsystem, and the Secondary they would be transferred to the extent possible. For example, if times in a day or two will meet the stars, and the sync will catch up with the current status of the disc will suit me. Volatile data is copied in a different way, the very valuable team of virtualos, and operating systems on them. To ensure consistency Secondary, DRBD is able to create snapshots between moments of complete synchronization (not yet tested, and in the config it is not).

I can, for example, to turn off the Secondary, and turn it on only at night. When the Secondary is disconnected, the recording speed is just excellent Primary, Secondary and then turns on and takes the difference. But then there is the low write speed of night, that will cause discomfort to users.

Like, 8.4, DRBD is able the deferred timing AHEAD/BEHIND, which allows the Primary to go forward, due to the temporary consistently Secondary. But I for the life of me - cannot configure. Still recording on the Primary is with the speed of the network and the device simultaneous separation in the AHEAD/BEHIND is not happening.

Help, please. I broke his head. What am I doing wrong?

Configuration test environment:

resource data {
 device /dev/drbd1;

 syncer {
 rate 80M;

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

 on XVMS0 { // then Primary
 disk /dev/sdf;
 meta-disk /dev/vgaux/drbd_meta_sdf;

 on XVMS1 {
 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; // tried larger values, closer to al-extents.
 data-integrity-alg sha1;

May be there are other solutions, not DRBD?

I have my script for the differential synchronization block devices over the network. It perfectly would fit if the sync would need once a month. The problem is that it leads to the subtraction of the two devices that 2TB HDD unreasonably long time, almost 10 hours. I want the chips DRBD, which annotates recorded area to transfer the difference, but does not reveal her parallel reading of the two devices.

Thanks in advance.
April 19th 20 at 12:14
5 answers
April 19th 20 at 12:16
Sadly all, in short, bad.

DRBD will work in the desired me "fully asynchronous" mode only using DRBD-proxy. Which is a commercial product from LINBIT, and it costs so much that they even don't post a price tag, but prefer to put the commercial in the mail.
On scattered information - units of thousands of dollars a year. For my case it's unreasonably expensive.

Came to the conclusion, which will increase the size of the active region, and will be connected to a secondary node at night when almost no one is working. Via Gigabit link, since posting the nod via the Internet will have to give up due to the fact that synchronization is per night, probable, time will not be executed.

Other solutions that allow you to synchronize the block devices (not files) differential, I have not found.
April 19th 20 at 12:18
Will not help with the online replication of the file system, but significantly (by orders of magnitude) to speed up the process of backing kopirovanija and receive Divov - the use of btrfs and its snapshots

Doing regular snapshots, even minute-by-minute (but better to integrate their creation as it is in the application logic, for example when there is record, as the moment of the snapshot creation does not require time, it will not impact significantly on the program, but he is indeed budet contain consistent data), then compare the earliest unsent with the latest on primary:
btrfs send --no-data-p /snapshots/parent /snapshots/child

get the Strom, which is sent to the backup server and deploy:
btrfs receive /backup/snapshots

Thanks for the advice. Otherwise would have used. Here, the replicated section on LVM, VG, LV on it the cut under the new path, and new path they are constantly occupied, plus there are dmcrypt... in short, this sandwich is no place for btrfs. :-)

You can, of course, on btrfs to put the virtual disks in files and to reduce the problem to yours, but the performance from the disk file (in my experience) will be lower, plus xen 4.11, suddenly, has a joint, which prevents the use of virtual disks in files. 4.8 fall don't want to wait for 4.13, where it is corrected once, bekarov under debian / ubuntu I have not found, recompile with the patch to do can not, in short forks :-) - henriette_Torp commented on April 19th 20 at 12:21
Oh, Yes problem.
from xen seems to have their own mechanisms of snapshots, can view. is it possible bakapit defy between them? just remember for example the kvm were some mechanisms for obtaining the patch, almost the RAM of the machine to move to a neighboring host and the data is what it is. - Rolando_Ba commented on April 19th 20 at 12:24
I have not XenServer (which is a stack of technologies and solutions related to the overall integration out of the box), and bare Xen. He just gets the resources (including virtual disc from device or file) and feeds them to the context of the virtual machine.

Itself with images he can not do anything. - henriette_Torp commented on April 19th 20 at 12:27
April 19th 20 at 12:20
The path of the CME?
Do the replication, like in proxmox to Primero
New path under xen. As I understand it. in proxmox replication is done using zfs, if the file container of virtual disks. Zfs itself isn't working for me, see answer Rolando_Ba below, and for a short time to learn proxmox and collect production solution I don't have time, plus there are other reasons why I won't be able to use it. - henriette_Torp commented on April 19th 20 at 12:23
April 19th 20 at 12:22
1) Very surprised that the author does. Absolutely can not backup a database using the replica images. Or the time the DB needs to be stopped. There is a risk that all that nakopirovali the author will be useless junk because once the database is restored will not rise. There will be many corruped block. And consisteth data.

So the question is - by you even tried to restore the entire complex with such inconsistentname backup?

2) If the 1C is on MySQL or PG it is necessary to use box utility dump my*, pg* dump.
That's the part I stipulated in the original question.

For example, if times in a day or two will meet the stars, and the sync will catch up with the current status of the disc will suit me. Volatile data is copied in a different way, the very valuable team of virtualos, and operating systems on them.

Of course, there are database backups, otherwise. When commissioning a backup server, the database will be inflated known working backup. - henriette_Torp commented on April 19th 20 at 12:25
April 19th 20 at 12:24
From simple to complex, try the following:

1. To reset the bios settings to default.
Go into the BIOS (F2 or DEL) press to reset the settings, save and exit.
Press F12 or F11 to bring up the menu to boot. Check to see if the flash drive will be visible.
2. In the BIOS switch the mode from EUFI or Legacy on =>> Dual Boot.
3. Enable USB detection in Woe
Exactly where this feature is in your BIOS is not known, but it is there somewhere.

Wish to win this issue!

Find more questions by tags DRBDSystem administrationLinux