SCI-CD

h1.  Перенос виртуальной машины на другую vg

h2. Виртуальная машина на одном узле

Данная операция является потенциально опасной, следует выполнять ее только при полном понимании описываемых операций и последствий.

Данная операция требует остановки машины на все время копирования содержимого.

h3. Подготовка

Получить информацию о машине:

<pre>

gnt-instance info ИМЯ 

</pre>

Больше всего будет интересовать информация о диске:

Например:

<pre>

  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

</pre>

Выключить машину

<pre>

gnt-instance shutdown ИМЯ

</pre>

На мастер узле остановить ganeti-watcher, ganeti:

<pre>

service ganeti-watcher stop

service ganeti stop

</pre>

Сделать резервную копию конфига ganeti.

<pre>

cp /var/lib/ganeti/config.data ~/

</pre>

берем имя тома из информации об инстансе, после /

<pre>

в нашем случае это 8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0

</pre>

Копируем в буфер обмена

Также из информации об инстансе берем точный размер тома

создаем том с таким же именем на новой vg (здесь она будет называться ssd)

<pre>

lvcreate -L10G -n 8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0 ssd

</pre>

открываем файл /var/lib/ganeti/config.data, ищем по данному имени, находим блок наподобие этого (json упакован без отступов и перевода строки, читать неудобно, так что нужно пользоваться поиском по подстроке):

<pre>

"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}]

</pre>

вот указание vg и имени тома:

<pre>

{"logical_id": ["xenvg", "8aea288f-37ad-4cd0-8a76-1e36f4da32cb.disk0"],

</pre>

В нем меняем vg "xenvg" на "ssd"

Сохраняем файл.

Запускаем ганети:

<pre>

service ganeti start

</pre>

Если в кластере более одного узла, то запускаем копирование конфигурации:

<pre>

gnt-cluster redist-conf

</pre>

проверяем, применились ли изменения, с помощью команды info:

<pre>

gnt-instance info ИМЯ

</pre>

Если все в порядке, то запускаем машину и ganeti-watcher

<pre>

gnt-instance startup ИМЯ

service ganeti-watcher start

</pre>

h2. Виртуальная машина на двух узлах

Возможны два варианта производства этой операции: с остановкой и без.

Вариант без остановки более сложный и трудоемкий.

h2. Перенос с остановкой

машину следует перед переносом остановить и перевести в plain (сделать ее машиной на одном узле):

<pre>

gnt-instance shutdown ИМЯ

gnt-instance modify -t plain ИМЯ

</pre>

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

по завершении переноса машина переводится в drbd режим:

<pre>

gnt-instance modify -t drbd -n gnt2 ИМЯ

</pre>

где gnt2 - имя нового secondary узла

h2. Перенос без остановки

Данная операция является потенциально опасной, следует выполнять ее только при полном понимании описываемых операций и последствий.

h3. Подготовка 

получаем информацию об инстансе, интересует то, на каком узле он запущен и информация о дисках:

<pre>

gnt-instance info ИМЯ

</pre>

<pre>

  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

</pre>

Итак, мы видим, что машина запущена на gnt2, устройство /dev/drbd1, lvm том /dev/ssd/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data

Далее, нужно запустить мастер на узле, который является *SECONDARY* для виртуальной машины, заходим на него и gnt-cluster master-failover

затем останавливаем ganeti-watcher НА ОБОИХ узлах:

<pre>

service ganeti-watcher stop

</pre>

Далее, переходим на узел, где машина secondary (в нашем случае это мастер, gnt1)

Далее, нужно отцепить drbd от текущего тома старой vg:

<pre>

drbdsetup resource1 down

</pre>

где resource1 - это аналог /dev/drbd1

Переименовываем том в старой vg, а также это будет наш бэкап:

<pre>

lvrename ssd 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data gate-disk0

</pre>

затем заново активируем drbd:

<pre>

gnt-instance activate-disks ИМЯ

</pre>

после этого проверяем, что диск проиницализировался заново и он считается Diskless, запускаем команду drbd-overview:

<pre>

 1:??not-found??  Connected Secondary/Primary Diskless/UpToDate 

</pre>

Также видим, что диск считается degraded, missing disk в выводе gnt-instance info:

<pre>

 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

</pre>

h3. непосредственно перенос

Останавливаем ganeti на мастере, делаем резервную копию конфига

<pre>

service ganeti stop

cp /var/lib/ganeti/config.data ~

</pre>

открываем конфиг, находим по имени тома секцию конфига, относящуюся к диску (там json без отступов и переводов строки, так что пользуемся поиском по подстроке):

<pre>

[{"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"],

</pre>

нас интересует то, что относится к _data, не _meta:

<pre>

{"dev_type": "plain", "logical_id": ["ssd", "590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data"], "params": {}, "uuid": "4a24c9fb-cd8e-4034-b908-18d3d83c246d", "size": 10240}

</pre>

меняем в конфиге имя vg на новую (вместо "ssd" - "xenvg"), только для _data, не для _meta

сохраняем конфиг

затем, на узле, где машина сейчас запущена (т.е. не на том, который сейчас мастер и где мы сейчас редактировали конфиг), создаем том в новой vg.

В нашем примере это узел gnt2.

<pre>

lvcreate -L10G -n 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data xenvg

</pre>

запускаем ganeti:

<pre>

service ganeti start

</pre>

делаем gnt-instance info, вывод:

<pre>

  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

</pre>

ганети считает, что drbd собран на /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data, при этом он отсутствует на secondary. На primary том присутствует, но он пока не используется, он только для обмана ganeti.

Теперь можно запустить процедуру пересоздания томов для drbd:

<pre>

gnt-instance replace-disks -a ИМЯ

</pre>

она проверит, присутствуют ли все тома для этого диска на обоих нодах. У нас отсутствует том _data на secondary ноде, он его создаст, подцепит к drbd, отсинкает.

После завершения процедуры у нас окажется, что на узле, где крутится машина, drbd собран на старой vg, а на вторичном узле - уже на новой, и все штатно работает. смотрим:

drbd-overview:

<pre>

</pre>

gnt-instance info:

<pre>

</pre>

drbdsetup resource1 show на gnt2 (где запущена машина):

<pre>

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

            }

        }

    }

}

</pre>

см. "disk"

drbdsetup resource1 show на gnt1 (вторичный узел):

<pre>

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

            }

        }

    }

}

</pre>

Таким образом, половина операции завершена.

h3. Миграция и перенос второго узла.

первым делом на узле, где крутится машина, удаляем диск, который мы создавали перед заменой vg (т.е. у нас это gnt2):

<pre>

lvremove /dev/xenvg/590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data

</pre>

Если он говорит, что том занят, значит вы удаляете не то и не там.

Распространяем обновленную конфигурацию ганети по кластеру (запускается с мастера, все еще gnt1):

<pre>

gnt-cluster redist-conf

</pre>

Мигрируем машину на secondary узел:

<pre>

gnt-instance migrate ИМЯ

</pre>

После миграции машины переводим мастер на новый вторичный узел (у нас это будет gnt2, с него только что уехала машина)

<pre>

gnt-cluster master-failover

</pre>

на нем же отцепляем том в старой vg от drbd, переименовываем (еще один бэкап):

<pre>

drbdsetup resource1 down

lvrename ssd 590d122d-57bb-4a3d-a6d4-95542d42cf26.disk0_data gate-disk0

</pre>

инициализируем drbd в diskless:

<pre>

gnt-instance activate-disks ИМЯ

</pre>

проверяем drbd-overview:

<pre>

1:??not-found??  Connected Secondary/Primary Diskless/UpToDate

</pre>

проверяем gnt-instance info:

<pre>

  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

</pre>

запускаем создание томов и ресинк:

<pre>

gnt-instance replace-disks -a ИМЯ

</pre>

после завершения процесса проверяем, что drbd подцеплен к нужным дискам, на обоих нодах:

gnt1 drbdsetup resource1 show:

<pre>

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

            }

        }

    }

}

</pre>

gnt2 drbdsetup resource1 show

<pre>

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

            }

        }

    }

}

</pre>

gnt-instance info:

<pre>

  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

</pre>

если все хорошо, запускаем watcher НА ОБОИХ нодах:

<pre>

sudo service ganeti-watcher start

</pre>

через некоторое время тома в старой vg можно удалить.