Назад | Перейти на главную страницу

Повторение DRBD Dual Primary

Это старая информация, что невозможно использовать файловую систему, не поддерживающую кластер, такую ​​как ext4 в Linux с DRBD в режиме двойного первичного доступа.

Например, как говорится в руководстве Linbit «Dual Primary - подумайте дважды»:

DRBD replicates the changes from node A to node B and the other way around. 
It changes the contents of the physical storage device. However - as DRBD resides 
под the mentioned Ext4 filesystems, the filesystem on the physical disk of 
node A does not notice the changes coming from node B (and vice versa). 
This process is called a concurrent write. Starting from now, the actual content 
of the storage device differs from what the filesystem there thinks it should be. 
The filesystem is corrupt."

У меня вопрос - почему это?

Потому что, если МЕТАДАННЫЕ этой файловой системы хранятся на одном устройстве DRBD, любое изменение, подобное описанному выше, также будет синхронизироваться между двумя узлами DRBD, и поэтому файловые системы на обоих концах (которые состоят из данных + метаданных не так ли?) полностью синхронизированы. Правда, то, что написал узел 1, было перезаписано узлом 2, но если я введу команду «dir» на узле 1, я увижу, что есть другой файл, а не только что скопированный узел 1. То же самое происходит с простыми общими папками, такими как общие папки Windows CIFS. Это не приводит к повреждению файловой системы.

Так в чем же проблема? Почему все говорят, что файловая система будет повреждена? Означает ли это, что файловые системы ext4 НЕ хранят метаданные на самом устройстве, а хранят их в другом месте, например в корневой файловой системе? Судя по тому, что я могу прочитать об устройстве ext4 FS, это не так. (Должен сказать, что я не вдавался в подробности о ext4).

Но должно быть примерно так:

Node1 writes a new file to block 34098 (and updates the directory entry as well):

Node 1
 - Directory Entry: /data/myfile1.txt  34098
 -----> block 34098 contains: myfile1.txt

At the "same time", Node2 writes the following to block 34098. It can never be "at the same time", so we assume it is when DRBD has just completed above sync.

Node2
 - Directory Entry: /data/other.txt  34098
 -----> block 34098 contains: other.txt

DRBD should now sync again the block 34098 back to node1, both the directory entry and the block 34098.

Наряду с записью файла "other.txt" в blocck 34098 файловая система на узле node2 также обновит блок, содержащий запись каталога (который является просто другим файлом), указывающий на блок 34098. Таким образом, он всегда должен быть синхронизирован или нет. ?

Ядро имеет в памяти образ состояния, в котором, по его мнению, находится файловая система, и не проверяет диск, чтобы узнать, не изменился ли он, потому что это не может случиться, поскольку только локальному ядру разрешено изменять файловую систему, и оно знает, что делает, и не нуждается в проверке. Если вы внесете изменения на втором узле, структуры на диске будут отличаться от ожидаемых ядром, и потеря данных почти гарантирована.

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