Перенос физической машины в кластере ProxmoxVE2(3) с DRBD на новое железо

Имея кластер из двух серверов стоящих на Proxmox с объединенным по DRBD хранилищем, бывает нужно обновить узел в этом кластере, без остановки работы машин в нем. Задача не сложная, но некоторые моменты не всегда вспоминаешь в процессе.
Поэтому, для себя, действия были записаны для будущего копипаста в консоль. Ну а раз уже написаны, почему бы не поделиться с людьми?
P.S. В конце небольшой бонус про расширение блочного устройства по имени DRBD, тюнинг и полезные ссылки.


Приступим.

1. Мигрируем все виртуальные машины на один узел который остаётся живым (PM2).
2. Заходим консолью на PM2 от привилегированного пользователя. Разрешаем находиться в кластере одному узлу:
pvecm expected 1

3. Смотрим узлы в кластере:
pvecm nodes

4. Удаляем переезжающий узел из кластера:
pvecm delnode pm1

5. Останавливаем синхронизацию DRBD:
drbdadm disconnect all

и проверяем статус StandAlone командой
cat /proc/drbd

6. Удаляем записи о старой машине в /etc/pve/priv/{autorized_keys, know_hosts}, а также аналогично в /root/.ssh
7. Устанавливаем на новую машину (PM1) ProxmoxVE2, указав при установке размеры разделов, написав в приглашении
boot: linux ext4 maxroot=8 swapsize=1 maxvz=10 (есть еще ключ minfree=200)
8. Заходим в консоль свежей PM1, обновляемся:
apt-get update && apt-get dist-upgrade

9. Добавляемся в кластер:
pvecm add 192.168.0.12
(192.168.0.12 это IP адрес PM2)
10. Установим утилиты для работы с DRBD:
apt-get install drbd8-utils

но т. к. в репозитории дебиан старые утилиты нам нужно обновить их на аналогичные в ядре:
dpkg -i drbd8-utils_8.3.13-0_amd64.deb

(в Proxmox 3 основаном на Debian 7 версия актуальна, поэтому пропускаем этот пункт)
11. Создаем/копируем файл с PM2 /etc/drbd.d/r0.res для примера следующего содержания:
resource r0 {
protocol C;
  startup {
    wfc-timeout  0;
    degr-wfc-timeout 600;
    become-primary-on both;
  }
  syncer {
    rate 500M;
  }
  net {
    cram-hmac-alg sha1;
    shared-secret "my-secret";
    allow-two-primaries;
    after-sb-0pri discard-zero-changes;
    after-sb-1pri discard-secondary;
    after-sb-2pri disconnect;
    sndbuf-size 0;
    no-tcp-cork;
    unplug-watermark 16;
    max-buffers 8000;
    max-epoch-size 8000;
  }
  on pm1 {
    device /dev/drbd0;
    disk /dev/pve/drbd;
    address 192.168.0.11:7788;
    meta-disk internal;
  }
  on pm2 {
    device /dev/drbd0;
    disk /dev/pve/drbd;
    address 192.168.0.12:7788;
    meta-disk internal;
}


12. Создаем логический раздел размером точь в точь как на рабочей машине:
lvcreate -L450G -n drbd0 pve

и смотрим что мы наделали командой
lvscan

13. Стартуем drbd:
/etc/init.d/drbd start

14. Создаём метадату:
drbdadm create-md r0

15. На всякий случай делаем вторичным
drbdadm secondary r0

и отключаемся от всех
drbdadm disconnect r0

16. Говорим что на нашей машине хранилище в не актуальном состоянии командой:
drbdadm -- --discard-my-data connect r0

и перезагружаем машину
17. В консоли первого сервера смотрим статус синхронизации командой:
watch cat /proc/drbd

18. В web интерфейсе в сторадже кластера разрешаем у хранилища с drbd наши узлы

Bonus: Расширение объема DRBD

Это все актуально для мета диска external.
1. Мы добавили объём дисков в рэйде. Расширяем раздел на котором лежит drbd:
lvextend  -L+250G /dev/pve/drbd0

2. На пустой машине сделаем хранилище вторичным:
drbdadm secondary r0


3. Расширяем drbd, запустив на машине где крутятся виртуалки, т.к. диск на второй машине временно стопорнётся.:
drbdadm resize r0


4. Расширение устройства drbd увеличит только это блочное устройство, но не pv, чтобы увеличить его:
pvresize /dev/pve/drbd0


Если диск internal то придется на время или навсегда перенести метаданные на отдельный диск. Без остановки это можно сделать в два этапа
1. На одном из серверов:
a) Cтопорим drbd:
drbdadm down r0

затем меняем в конфиге строчки
meta-disk internal
на
meta-disk /dev/”ваше устройство для метаданных”[0]
для которого очень рекомендуется ssd диск, но на время можно создать lvm раздел.
b) Затем на другой машине
drbdadm -- --overwrite-data-of-peer primary r0

а на текущей
drbdadm up r0

и смотрим процес синхронизации
watch cat /proc/drbd 

После завершения процесса у нас на этом сервере метаданные вынесены на отдельное устройство.
2. Повторяем пункт 1 на другом сервере.

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

Перед любыми действиями вполне естественно делать резервные копии, а сделать их быстрее поможет строчка в файле /etc/vzdump.conf:
bwlimit: 100000

которая сделает ограничение скорости в 100 мегабит, по умолчанию стоит всего 10, что для 100 мегабитной сети вполне нормально, но для гигабит(а) слишком мягко.

Полезные ссылки:
Сайт Proxmox
Proxmox wiki
Proxmox форум
Скачать образ для инсталляции

UPD: Поздравляю с релизом Proxmox 3.0 на основе Debian Wheezy
Поделиться публикацией
Комментарии 2
    0
    Все же drbd не лучшее решение для proxmox.
      0
      Имея ограниченное количество серверов для виртуализации, в данном случае два, это вполне нормальное решение, дающее возможность без перерывов в работе обслуживать железо. А так да, более правильное решение использовать кластерное хранилище, например поддерживаемое Proxmox'ом RBD.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое