Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3

[awsswa59]

Отличная статья.
Рекомендации к прочтению и настройки для системных администраторов:
по подключению дисковой полки
соединения серверов
дисковой настройки

[rionnagel]

Очень неплохо, как и предыдущая статья. С нетерпением ждём продолжения.

[BNKT0P]

спасибо :)
думаю недели через 2-3 будет продолжение

[Naves]

Виртуальные диски для ВМ могут быть двух типов — QCOW2 или RAW. Диски могут быть «тонкими» или «толстыми». Снэпшоты всегда создаются как «тонкие».
…
В случае подключений через FC, oVirt использует что-то наподобие кластерного LVM.

Ovirt может создавать снапшоты и тонкие диски на таком кластерном LVM?
Например, тот же proxmox не может так, и связано это с принципом работы самого LVM.

[BNKT0P]

Овирт делает для любого диска (тонкого, толстого, снэпшота) свой отдельный lvm на хостах кластера.

[Naves]

эммм. вот смотрите мою конфигурацию

lsblk

Такая конфигурация на каждом узле кластера.
sda — локальный диск, на котором есть LVM раздел, на котором можно делать и снапшоты и тонкие диски. Но если умрет хост-нода кластера, то образ диска пропадет, и никакого HA у нас нет.
sdb, sdc диски подключенные через iscsi, объединенные в mpath, на котором уже развернута Cluster LVM.
При гибели узла, эти самые образы дисков vm--XXX--disk благополучно используются другой нодой. При этом для этих образов нельзя делать снапшоты.
Так же они занимают на хранилище всегда все выделеное место для одного виртуального диска. Те в такой конфигурации не может появиться ситуация, когда одна виртуалка решила заполнить целиком весь свой виртуальный диск, образ разросся, заполнил все место на ФС хоста, и весь сервер виртуализации остановился.

[BNKT0P]

На нодах овирта примерно тоже самое с дисками для ВМ.
Диски sdb и sdi (не показан в выводе команды) подключены через FC и также объединены через multipath:

[root@host1 ~]# multipath -ll
3600a098000e4b4b3000003175cec1840 dm-2 DELL    ,MD38xxf
size=2.0T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:1  sdb 8:16  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:1  sdi 8:128 active ready running

lsblk - host1

lsblk - host2

И также при отказе одного из узлов, ВМ благополучно перезапускаются на втором хосте, куда через LVM монтируются образы их дисков.
Правда не понял почему снэпшоты делать нельзя в proxmox — в овирте снэпшоты спокойно делаются, неважно какой диск у ВМ, в формате qcow2 или RAW.

[Naves]

потому что вот так
www.redhat.com/archives/linux-lvm/2015-August/msg00013.html
Там вопрос задан в другом контексте, но сам proxmox умеет в онлайне мигрировать виртуалки с узла на узел, но без снапшотов.
stuff.mit.edu/afs/athena/project/rhel-doc/5/RHEL-5-manual/Cluster_Logical_Volume_Manager/snapshot_command.html

LVM snapshots are not cluster-aware, so they require exclusive access to a volume.

[BNKT0P]

Наверное не очень понял вопроса, поэтому немного опишу механику создания снэпшотов в овирте.
Итак, имеется рабочая ВМ с диском размером 11 Гб

вывод lsblk до добавления снэпшота для ВМ

[root@host2 ~]# lsblk
...
sdb                                                                                     8:16   0     2T  0 disk
└─3600a098000e4b4b3000003175cec1840                                                   253:6    0     2T  0 mpath
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-metadata                                 253:7    0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-outbox                                   253:8    0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-xleases                                  253:9    0     1G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-leases                                   253:10   0     2G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-ids                                      253:11   0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-inbox                                    253:12   0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-master                                   253:13   0     1G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-a8b0e4e0--2e9d--4b51--9f7c--98179cb4e3f4 253:23   0    25G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-bf6335db--0ab7--4556--89eb--9bdc3a787e40 253:24   0    10G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-6a170859--689d--4428--9ef8--9c085c09660a 253:26   0    10G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-052bfc78--6805--46a2--9e79--9f4c67e9346c 253:27   0    20G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-d057c535--5943--488b--89e3--6f7446c0962e 253:37   0  33.1G  0 lvm
  └─2639f482--7c6b--48db--bddb--9bae82c7660b-d935fe8f--8dc9--479a--a716--a2fce6bb0b84 253:38   0    11G  0 lvm

Делаем снэпшот для этой ВМ из админпортала.

В консоли овирта после его добавления, диски ВМ выглядят так:

Вывод lsblk после добавления снэпшота для ВМ:

sdb                                                                                     8:16   0     2T  0 disk
└─3600a098000e4b4b3000003175cec1840                                                   253:6    0     2T  0 mpath
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-metadata                                 253:7    0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-outbox                                   253:8    0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-xleases                                  253:9    0     1G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-leases                                   253:10   0     2G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-ids                                      253:11   0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-inbox                                    253:12   0   128M  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-master                                   253:13   0     1G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-a8b0e4e0--2e9d--4b51--9f7c--98179cb4e3f4 253:23   0    25G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-bf6335db--0ab7--4556--89eb--9bdc3a787e40 253:24   0    10G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-6a170859--689d--4428--9ef8--9c085c09660a 253:26   0    10G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-052bfc78--6805--46a2--9e79--9f4c67e9346c 253:27   0    20G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-d057c535--5943--488b--89e3--6f7446c0962e 253:37   0  33.1G  0 lvm
  ├─2639f482--7c6b--48db--bddb--9bae82c7660b-d935fe8f--8dc9--479a--a716--a2fce6bb0b84 253:38   0    11G  0 lvm
  └─2639f482--7c6b--48db--bddb--9bae82c7660b-a823137a--6843--4563--b342--bb69829ca807 253:39   0     1G  0 lvm

Когда я писал про кластерный LVM, то не зря отметил, что "oVirt использует что-то наподобие кластерного LVM", т.е. lvmlockd в явном виде не используется, и сам внутренний механизм процесса снятия снэпшотов в документации не описан.

Вывод lvscan

[root@host2 ~]# lvscan | grep bb69829ca80
  WARNING: lvmlockd process is not running.
  Reading without shared global lock.
  ACTIVE            '/dev/2639f482-7c6b-48db-bddb-9bae82c7660b/a823137a-6843-4563-b342-bb69829ca807' [1.00 GiB] inherit
  Reading VG lvm_storage1_backup1_vg without a lock.

[root@host2 ~]# lvscan | grep a2fce6bb0b84
  WARNING: lvmlockd process is not running.
  Reading without shared global lock.
  ACTIVE            '/dev/2639f482-7c6b-48db-bddb-9bae82c7660b/d935fe8f-8dc9-479a-a716-a2fce6bb0b84' [11.00 GiB] inherit
  Reading VG lvm_storage1_backup1_vg without a lock.