Перенос виртуальной машины на другую vg » История » Версия 7
« Предыдущее -
Версия 7/8
(Разница(diff)) -
Следующее » -
Текущая версия
Владимир Ипатов, 03.03.2021 23:36
Перенос виртуальной машины на другую vg¶
Виртуальная машина на одном узле¶
Данная операция является потенциально опасной, следует выполнять ее только при полном понимании описываемых операций и последствий.
Данная операция требует остановки машины на все время копирования содержимого.
Подготовка¶
Получить информацию о машине:
gnt-instance info ИМЯ
Больше всего будет интересовать информация о диске:
Например:
Disks:
- disk/0: plain, size 10.0G
access mode: rw
logical_id: xenvg/8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0
on primary: /dev/xenvg/8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0 (253:9)
name: None
UUID: 3c7fb626-21d2-4e99-9365-6639a13456b5
Выключить машину
gnt-instance shutdown ИМЯ
На мастер узле остановить ganeti-watcher, ganeti:
service ganeti-watcher stop service ganeti stop
Сделать резервную копию конфига ganeti.
cp /var/lib/ganeti/config.data ~/
берем имя тома из информации об инстансе, после /
в нашем случае это 8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0
Копируем в буфер обмена
Также из информации об инстансе берем точный размер тома
создаем том с таким же именем на новой vg (здесь она будет называться ssd)
lvcreate -L10G -n 8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0 ssd
открываем файл /var/lib/ganeti/config.data, ищем по данному имени, находим блок наподобие этого (json упакован без отступов и перевода строки, читать неудобно, так что нужно пользоваться поиском по подстроке):
"disks": [{"logical_id": ["xenvg", "8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0"], "uuid": "3c7fb626-21d2-4e99-9365-6639a13456b5", "dev_type": "plain", "params": {}, "mode": "rw", "iv_name": "disk/0", "size": 10240}]
вот указание vg и имени тома:
{"logical_id": ["xenvg", "8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0"],
В нем меняем vg "xenvg" на "ssd"
Сохраняем файл.
Запускаем ганети:
service ganeti start
Если в кластере более одного узла, то запускаем копирование конфигурации:
gnt-cluster redist-conf
проверяем, применились ли изменения, с помощью команды info:
gnt-instance info ИМЯ
Если все в порядке, то запускаем машину и ganeti-watcher
gnt-instance startup ИМЯ service ganeti-watcher start
Виртуальная машина на двух узлах¶
Возможны два варианта производства этой операции: с остановкой и без.
Вариант без остановки более сложный и трудоемкий.
Перенос с остановкой¶
машину следует перед переносом остановить и перевести в plain (сделать ее машиной на одном узле):
gnt-instance shutdown ИМЯ gnt-instance modify -t plain ИМЯ
После этого машина останется только на primary узле, дальнейшие операции проводятся так же, как для машины на одном узле, см. выше.
по завершении переноса машина переводится в drbd режим:
gnt-instance modify -t drbd -n gnt2 ИМЯ
где gnt2 - имя нового secondary узла
Перенос без остановки¶
Данная операция является потенциально опасной, следует выполнять ее только при полном понимании описываемых операций и последствий.
Подготовка¶
получаем информацию об инстансе, интересует то, на каком узле он запущен и информация о дисках:
gnt-instance info ИМЯ
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt2, minor=1
nodeB: gnt1, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status ok
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:4)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:4)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
Итак, мы видим, что машина запущена на gnt2, устройство /dev/drbd1, lvm том /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
Далее, нужно запустить мастер на узле, который является SECONDARY для виртуальной машины, заходим на него и gnt-cluster master-failover
затем останавливаем ganeti-watcher НА ОБОИХ узлах:
service ganeti-watcher stop
Далее, переходим на узел, где машина secondary (в нашем случае это мастер, gnt1)
Далее, нужно отцепить drbd от текущего тома старой vg:
drbdsetup resource1 down
где resource1 - это аналог /dev/drbd1
Переименовываем том в старой vg, а также это будет наш бэкап:
lvrename ssd 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data gate-disk0
затем заново активируем drbd:
gnt-instance activate-disks ИМЯ
после этого проверяем, что диск проиницализировался заново и он считается Diskless, запускаем команду drbd-overview:
1:??not-found?? Connected Secondary/Primary Diskless/UpToDate
Также видим, что диск считается degraded, missing disk в выводе gnt-instance info:
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt2.pproduct, minor=1
nodeB: gnt1.pproduct, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status *DEGRADED* *MISSING DISK*
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:4)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
непосредственно перенос¶
Останавливаем ganeti на мастере, делаем резервную копию конфига
service ganeti stop cp /var/lib/ganeti/config.data ~
открываем конфиг, находим по имени тома секцию конфига, относящуюся к диску (там json без отступов и переводов строки, так что пользуемся поиском по подстроке):
[{"logical_id": ["8db85567-d4d7-427d-916e-382ab6d9448b", "05ddeac2-8a00-42a5-bf8c-68a440d29d49", 11001, 1, 1, "6adc50aa8fda95beb7b1565c3eb2fd688a9e8a47"], "uuid": "4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2", "dev_type": "drbd", "params": {}, "mode": "rw", "children": [{"dev_type": "plain", "logical_id": ["ssd", "590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data"], "params": {}, "uuid": "4a24c9fb-cd8e-4034-b908-18d3d83c246d", "size": 10240}, {"dev_type": "plain", "logical_id": ["ssd", "590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta"],
нас интересует то, что относится к _data, не _meta:
{"dev_type": "plain", "logical_id": ["ssd", "590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data"], "params": {}, "uuid": "4a24c9fb-cd8e-4034-b908-18d3d83c246d", "size": 10240}
меняем в конфиге имя vg на новую (вместо "ssd" - "xenvg"), только для _data, не для _meta
сохраняем конфиг
затем, на узле, где машина сейчас запущена (т.е. не на том, который сейчас мастер и где мы сейчас редактировали конфиг), создаем том в новой vg.
В нашем примере это узел gnt2.
lvcreate -L10G -n 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data xenvg
запускаем ganeti:
service ganeti start
делаем gnt-instance info, вывод:
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt2.pproduct, minor=1
nodeB: gnt1.pproduct, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status *DEGRADED* *MISSING DISK*
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
ганети считает, что drbd собран на /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data, при этом он отсутствует на secondary. На primary том присутствует, но он пока не используется, он только для обмана ganeti.
Теперь можно запустить процедуру пересоздания томов для drbd:
gnt-instance replace-disks -a ИМЯ
она проверит, присутствуют ли все тома для этого диска на обоих нодах. У нас отсутствует том _data на secondary ноде, он его создаст, подцепит к drbd, отсинкает.
После завершения процедуры у нас окажется, что на узле, где крутится машина, drbd собран на старой vg, а на вторичном узле - уже на новой, и все штатно работает. смотрим:
drbd-overview:
1:??not-found?? Connected Secondary/Primary UpToDate/UpToDate
gnt-instance info:
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt2.pproduct, minor=1
nodeB: gnt1.pproduct, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status ok
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
on secondary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:20)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:20)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
drbdsetup resource1 show на gnt2 (где запущена машина):
resource resource1 {
options {
}
net {
max-buffers 8000;
cram-hmac-alg "md5";
shared-secret "";
after-sb-0pri discard-zero-changes;
after-sb-1pri consensus;
}
_remote_host {
address ipv4 10.101.200.11:11001;
}
_this_host {
address ipv4 10.101.200.12:11001;
volume 0 {
device minor 1;
disk "/dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data";
meta-disk "/dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta";
disk {
size 20971520s; # bytes
resync-rate 122880k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
}
}
}
}
см. "disk"
drbdsetup resource1 show на gnt1 (вторичный узел):
resource resource1 {
options {
}
net {
max-buffers 8000;
cram-hmac-alg "md5";
shared-secret "";
after-sb-0pri discard-zero-changes;
after-sb-1pri consensus;
}
_remote_host {
address ipv4 10.101.200.12:11001;
}
_this_host {
address ipv4 10.101.200.11:11001;
volume 0 {
device minor 1;
disk "/dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data";
meta-disk "/dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta";
disk {
size 20971520s; # bytes
resync-rate 122880k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
}
}
}
}
Таким образом, половина операции завершена.
Миграция и перенос второго узла.¶
первым делом на узле, где крутится машина, удаляем диск, который мы создавали перед заменой vg (т.е. у нас это gnt2):
lvremove /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
Если он говорит, что том занят, значит вы удаляете не то и не там.
Распространяем обновленную конфигурацию ганети по кластеру (запускается с мастера, все еще gnt1):
gnt-cluster redist-conf
Мигрируем машину на secondary узел:
gnt-instance migrate ИМЯ
После миграции машины переводим мастер на новый вторичный узел (у нас это будет gnt2, с него только что уехала машина)
gnt-cluster master-failover
на нем же отцепляем том в старой vg от drbd, переименовываем (еще один бэкап):
drbdsetup resource1 down lvrename ssd 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data gate-disk0
инициализируем drbd в diskless:
gnt-instance activate-disks ИМЯ
проверяем drbd-overview:
1:??not-found?? Connected Secondary/Primary Diskless/UpToDate
проверяем gnt-instance info:
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt1.pproduct, minor=1
nodeB: gnt2.pproduct, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status *DEGRADED* *MISSING DISK*
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:20)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:5)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
запускаем создание томов и ресинк:
gnt-instance replace-disks -a ИМЯ
после завершения процесса проверяем, что drbd подцеплен к нужным дискам, на обоих нодах:
gnt1 drbdsetup resource1 show:
resource resource1 {
options {
}
net {
max-buffers 8000;
cram-hmac-alg "md5";
shared-secret "";
after-sb-0pri discard-zero-changes;
after-sb-1pri consensus;
}
_remote_host {
address ipv4 10.101.200.12:11001;
}
_this_host {
address ipv4 10.101.200.11:11001;
volume 0 {
device minor 1;
disk "/dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data";
meta-disk "/dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta";
disk {
size 20971520s; # bytes
resync-rate 122880k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
}
}
}
}
gnt2 drbdsetup resource1 show
resource resource1 {
options {
}
net {
max-buffers 8000;
cram-hmac-alg "md5";
shared-secret "";
after-sb-0pri discard-zero-changes;
after-sb-1pri consensus;
}
_remote_host {
address ipv4 10.101.200.11:11001;
}
_this_host {
address ipv4 10.101.200.12:11001;
volume 0 {
device minor 1;
disk "/dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data";
meta-disk "/dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta";
disk {
size 20971520s; # bytes
resync-rate 66560k; # bytes/second
c-plan-ahead 0; # 1/10 seconds
}
}
}
}
gnt-instance info:
Disks:
- disk/0: drbd, size 10.0G
access mode: rw
nodeA: gnt1.pproduct, minor=1
nodeB: gnt2.pproduct, minor=1
port: 11001
on primary: /dev/drbd1 (147:1) in sync, status ok
on secondary: /dev/drbd1 (147:1) in sync, status ok
name: None
UUID: 4dd153b6-f975-4c3f-a2f7-9dddbd6a3dc2
child devices:
- child 0: plain, size 10.0G
logical_id: xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data
on primary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
on secondary: /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data (253:19)
name: None
UUID: 4a24c9fb-cd8e-4034-b908-18d3d83c246d
- child 1: plain, size 128M
logical_id: ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta
on primary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:20)
on secondary: /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_meta (253:20)
name: None
UUID: 37dc4222-a29a-42d0-a1a5-3e2c9b0aec8a
если все хорошо, запускаем watcher НА ОБОИХ нодах:
sudo service ganeti-watcher start
через некоторое время тома в старой vg можно удалить.