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

DRBD на необработанном дисковом блочном устройстве

Я пытаюсь настроить DRBD на необработанном дисковом устройстве /dev/sdb без таблицы разделов и LVM-стека PV / VG / LV

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

Мое определение ресурса не может быть проще

resource data {
  device  /dev/drbd1;
  meta-disk internal;
  disk    /dev/sdb;
  on node1 {
    address 10.10.10.16:7789;
  }
  on node2 {
    address 10.10.10.17:7789;
  }
}

Создание метаданных работает

# drbdadm create-md data
initializing activity log
NOT initializing bitmap
Writing meta data...
New drbd meta data block successfully created.

Но операция присоединения не выполняется

 # drbdadm attach data
 1: Failure: (127) Device minor not allocated
 additional info from kernel:
 unknown minor
 Command 'drbdsetup-84 attach 1 /dev/sdb /dev/sdb internal' terminated with exit code 10

Сообщение об ошибке действительно звучит как команда ожидает индекс таблицы разделов как дополнительный код устройства.

Как мне подключить необработанное устройство к ресурсу DRBD?

drbdadm attach data Это не единственная команда, которую вы хотите использовать после создания метаданных.

Для включения устройства должна работать одна из следующих процедур:

# drbdadm create-md data
# drbdadm up data

-- или --

# drbdadm create-md data
# drbdsetup-84 new-resource data
# drbdsetup-84 new-minor data 1 0 
# drbdmeta 1 v08 /dev/sdb internal apply-al 
# drbdsetup-84 attach 1 /dev/sdb /dev/sdb internal
# drbdsetup-84 connect data ipv4:10.10.10.16:7789 ipv4:10.10.10.17:7789 --protocol=C

Как только вы это сделаете, у вас будет устройство с состоянием подключения «Подключено» и состоянием диска «Несогласованное / Несогласованное»; это будет всегда / только после того, как вы создадите новые метаданные на обоих узлах. Оттуда просто выберите один узел для повышения до первичного, что приведет к синхронизации DRBD из первичного -> вторичного:

# drbdadm primary data --force

Вам никогда не следует при обычных обстоятельствах использовать "--force" для продвижения вашего устройства DRBD с этого момента.

Однако вы также сказали:

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

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

В очень конкретном случае пакета Debian DRBD нет необходимости работать с «прикрепленными данными».

Вот минимальная последовательность действий для запуска DRBD с Debian:

  • Создайте свой файл ресурсов /etc/drbd.d/data.res на обоих узлах, обычно для определения /dev/drbd1 (напомните номер этого тома 1 для очистки растрового изображения!)
  • Вызвать drbdadm create-md data на обоих узлах
  • Запустите службу на обоих узлах, они должны дождаться готовности друг друга: systemctl start drbd.service
  • Подтвердить Connected государство с drbdadm cstate data. Если нет, не ходи дальше пока не будет решена проблема с запуском службы или подключением к сети.
  • На primary только узел, очистите растровое изображение, чтобы предотвратить бесполезную начальную синхронизацию: drbdadm -- --clear-bitmap new-current-uuid data/1 (помните последний параметр: resourceName/volumeNumber)
  • На primary только узел, продвигайте узел как primary: drbdadm primary data

С этого момента primary узел, /dev/drbd1 устройство доступно для любых обычных блочных операций, таких как blockdev или mkfs.

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