Управление кластером Xen с помощью Ganeti на Debian Lenny

Опубликовано Mixa – 21.12.2009

Автор: Xen Cluster Management With Ganeti On Debian Lenny
Перевод: Сгибнев Михаил

 Ganeti — это система управления кластерной виртуализацией на базе Xen. В этом руководстве мы рассмотрим, как создать виртуальную машину Xen (instance) на кластере двух физических машин, как управлять этой виртуальной машиной и как обеспечить ее отказоустойчивость.

 Как обычно, не дается никаких гарантий и вы предупреждены о возможных последствиях.

 (1) Предварительное примечание

Мы будем использовать две физические ноды node1.example.com и node2.example.com:

  • node1.example.com: IP address 192.168.0.100; является главной в кластере.
  • node2.example.com: IP address 192.168.0.101; является главной нодой для виртуальной машины (aka instance).

 Обе ноды имеют жесткие диски по 500GB, из которых 20GB используются под корневой раздел и 1GB для swap. Остальное пространство не размечено и будет использоваться Ganeti (минимум 20GB!). Конечно, вы можете разбить диски по собственному усмотрению, только помните о минимальных требованиях по свободному месту.

 Кластер, который мы создадим, будет называться cluster1.example.com и иметь IP адрес 192.168.0.102. Кластерный адрес 192.168.0.102 будет привязан к владельцу кластера, таким образом, что вы не зная, какая нода в настоящий момент является владельцем, всегда сможете получить к ней доступ по SSH.

 Виртуальная машина Xen (называемая instance в терминах Ganeti) будет называться inst1.example.com и будет иметь адрес 192.168.0.105. inst1.example.com будет зеркалирована на обеих нодах с помощью DRBD — сетевой разновидности RAID1.

 Как вы видите, node1.example.com является мвладельцем кластера, то есть машиной, с которой вы управляете кластером. node2.example.com является первой нодой кластера inst1.example.com, таким образом, inst1.example.com запущен на node2.example.com(все изменения inst1.example.com зеркалируются на node1.example.com с помощью DRBD), пока не упадет одна из нод. Такая конфигурация известно как active-passive.

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

 Очень важно то, чтобы все используемые имена разрешались между всеми хостами. Для этого вы должны воспользоваться DNS или
внести соответствующие записи в /etc/hosts всех хостов(наш случай).

 Все ноды кластера должны использовать одинаковый сетевой интерфейс (например eth0), так как используя на нодах разные
интерфейсы (например, на одной ноде eth0, а на второй eth1), Ganeti может работать некорректно.
 Ну, приступим.

 (2) Подготавливаем ноды:

 Я использую на node1 статический адрес 192.168.0.100, который указан в файле /etc/network/interfaces. Обратите внимание, что я заменил allow-hotplug eth0 на auto eth0, иначе не работает перезапуск сети и нам придется перезагружать саму ноду:

vi /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
#iface eth0 inet dhcp
auto eth0
iface eth0 inet static
address 192.168.0.100
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1

 После того, как мы внесли в файл изменения, перезапускаем сетевые интерфейсы:

/etc/init.d/networking restart

 Наш файл /etc/hosts нужно отредактировать, чтобы он выглядел подобным образом:

127.0.0.1 localhost.localdomain localhost
192.168.0.100 node1.example.com node1
192.168.0.101 node2.example.com node2
192.168.0.102 cluster1.example.com cluster1
192.168.0.105 inst1.example.com inst1

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

 Для проверки выполним команды hostname и hostname -f. Если мы не получили полное имя хоста ( (node1.example.com)), то выполним команду:

echo node1.example.com > /etc/hostname
/etc/init.d/hostname.sh start

 После чего повторим проверку командой hostname.

 Обновляем систему:

aptitude update
aptitude safe-upgrade

 После этого повторяем все теже действия с node2.

 (2) Настраиваем LVM на свободном пространстве:

 Посмотрим на наши диски:

node1:~# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00023cd1

Device Boot Start End Blocks Id System
/dev/sda1 * 1 62 497983+ 83 Linux
/dev/sda2 63 6141 48829567+ 8e Linux LVM
node1:~#

 Создаем на обоих нодах раздел /dev/sda3, используя свободное дисковое пространство:

node1:~# fdisk /dev/sda

The number of cylinders for this disk is set to 60801.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): <-- n Command action e extended p primary partition (1-4) <-- p Partition number (1-4): <-- 3 First cylinder (6142-60801, default 6142): <-- ENTER Using default value 6142 Last cylinder or +size or +sizeM or +sizeK (6142-60801, default 60801): <-- ENTER Using default value 60801 Command (m for help): <-- t Partition number (1-4): <-- 3 Hex code (type L to list codes): <-- L 0 Empty 1e Hidden W95 FAT1 80 Old Minix be Solaris boot 1 FAT12 24 NEC DOS 81 Minix / old Lin bf Solaris 2 XENIX root 39 Plan 9 82 Linux swap / So c1 DRDOS/sec (FAT- 3 XENIX usr 3c PartitionMagic 83 Linux c4 DRDOS/sec (FAT- 4 FAT16 <32M 40 Venix 80286 84 OS/2 hidden C: c6 DRDOS/sec (FAT- 5 Extended 41 PPC PReP Boot 85 Linux extended c7 Syrinx 6 FAT16 42 SFS 86 NTFS volume set da Non-FS data 7 HPFS/NTFS 4d QNX4.x 87 NTFS volume set db CP/M / CTOS / . 8 AIX 4e QNX4.x 2nd part 88 Linux plaintext de Dell Utility 9 AIX bootable 4f QNX4.x 3rd part 8e Linux LVM df BootIt a OS/2 Boot Manag 50 OnTrack DM 93 Amoeba e1 DOS access b W95 FAT32 51 OnTrack DM6 Aux 94 Amoeba BBT e3 DOS R/O c W95 FAT32 (LBA) 52 CP/M 9f BSD/OS e4 SpeedStor e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a0 IBM Thinkpad hi eb BeOS fs f W95 Ext'd (LBA) 54 OnTrackDM6 a5 FreeBSD ee EFI GPT 10 OPUS 55 EZ-Drive a6 OpenBSD ef EFI (FAT-12/16/ 11 Hidden FAT12 56 Golden Bow a7 NeXTSTEP f0 Linux/PA-RISC b 12 Compaq diagnost 5c Priam Edisk a8 Darwin UFS f1 SpeedStor 14 Hidden FAT16 <3 61 SpeedStor a9 NetBSD f4 SpeedStor 16 Hidden FAT16 63 GNU HURD or Sys ab Darwin boot f2 DOS secondary 17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fd Linux raid auto 18 AST SmartSleep 65 Novell Netware b8 BSDI swap fe LANstep 1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid ff BBT 1c Hidden W95 FAT3 75 PC/IX Hex code (type L to list codes): <-- 8e Changed system type of partition 3 to 8e (Linux LVM) Command (m for help): <-- w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 16: Device or resource busy. The kernel still uses the old table. The new table will be used at the next reboot. Syncing disks. node1:~#
 Снова посмотрим на состояние диска:

node1:~# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00023cd1

Device Boot Start End Blocks Id System
/dev/sda1 * 1 62 497983+ 83 Linux
/dev/sda2 63 6141 48829567+ 8e Linux LVM
/dev/sda3 6142 60801 439056450 8e Linux LVM
node1:~#

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

 После перезагрузки мы устанавливаем LVM (вероятно, что все уже установлено, но лучше подстраховаться):

aptitude install lvm2

 После перезагрузки мы подготавливаем /dev/sda3 под LVM на обеих нодах и добавляем раздел в группу xenvg:

pvcreate /dev/sda3
vgcreate xenvg /dev/sda3

(4) Устанавливаем Ganeti и Xen:

 Оба продукта устанавливаются одной командой:

aptitude install ganeti

 В ответ на вопрос MD arrays needed for the root file system необходимо ответить all. Затем, откройте файл /etc/xen/xend-config.sxp и отредактируйте следующие параметры:

[...]
(xend-relocation-server yes)
[...]
(xend-relocation-port 8002)
[...]
(xend-relocation-address '')
[...]
(network-script network-bridge)
[...]
#(network-script network-dummy)
[...]
(vif-script vif-bridge)
[...]
(dom0-min-mem 0)
[...]

 Затем откройте файл /boot/grub/menu.lst и найдите строки # xenhopt= и # xenkopt=
(не удаляйте символ #).

[...]
## Xen hypervisor options to use with the default Xen boot option
# xenhopt=dom0_mem=256M

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 nosmp
[...]

 Объем используемой памяти устанавливается в зависимости от объема RAM на dom0.

 Параметр nosmp используйте только в случае, если CPU имеет несколько ядер. Если у процессора только одно ядро, то уменьшения нагрузки вы не получите. Посмотреть информацию о процессорах можно командой cat /proc/cpuinfo.

 Обновим загрузчик GRUB:

/sbin/update-grub

 После чего перезагрузим систему. Загрузившись, убедимся, что используем ядро Xen:

node1:~# uname -r
2.6.26-1-xen-686
node1:~#

 Если вы не указали используемое ядро командой gnt-instance add, то чтобы по умолчанию использовать ядро /boot/vmlinuz-2.6-xenU и /boot/initrd-2.6-xenU выполните следующую команду:

cd /boot
ln -s vmlinuz-`uname -r` vmlinuz-2.6-xenU
ln -s initrd.img-`uname -r` initrd-2.6-xenU

 (5) Устанавливаем DRBD:

 Устанавливаем DRBD:

aptitude install drbd8-modules-`uname -r` drbd8-utils

 Загружаем модуль ядра:

echo drbd minor_count=64 >> /etc/modules
modprobe drbd minor_count=64

 Я рекомендую конфигурировать LVM таким образом, чтобы не просматирвать устройства DRBD. Для этого откройте файл /etc/lvm/lvm.conf и замените строку filter как показано ниже:

vi /etc/lvm/lvm.conf

[...]
filter = [ "r|/dev/cdrom|", "r|/dev/drbd[0-9]+|" ]
[...]

(6) Инициализируем кластер:

 Принимая наши исходные данные, имя кластера cluster1.example.com, в качестве владельца выступает нода node1.example.com. Поэтому на node1.example.com выполняем команду:

gnt-cluster init -b eth0 -g xenvg --master-netdev eth0 cluster1.example.com

 Ganeti по умолчанию считает, что имя логической группы xenvg, поэтому вы можете опустить параметр -g xenvg, но если имя группы отличается, то параметр -g обязателен, с указанием имени группы.

 Xen 3.2 и 3.3 больше не использует интерфейс моста xen-br0, вместо него используется eth0. Поэтому мы должны указать -b eth0 и --master-netdev eth0.

 (7) Добавляем ноду node2.example.com в кластер

 Теперь, когда нода node1 является владельцем кластера, все действия по управлению кластером осуществляются с нее. Для добавления node2.example.com в кластер, выполните командуgnt-node add node2.example.com:

node1:~# gnt-node add node2.example.com
-- WARNING --
Performing this operation is going to replace the ssh daemon keypair
on the target machine (node2.example.com) with the ones of the current one
and grant full intra-cluster ssh root access to/from it

The authenticity of host 'node2.example.com (192.168.0.101)' can't be established.
RSA key fingerprint is 62:d3:d4:3f:d2:9c:3b:f2:5f:fe:c0:8a:c8:02:82:2a.
Are you sure you want to continue connecting (yes/no)? <-- yes root@node2.example.com's password: <-- node2's root password node1:~#
 Проверим правильность выполнения команды:

node1:~# gnt-node list
Node DTotal DFree MTotal MNode MFree Pinst Sinst
node1.example.com 428764 428764 3839 256 3535 0 0
node2.example.com 104452 104452 1023 256 747 0 0
node1:~#

 (8) Поднимаем Instance

 Теперь создадим нашу первую виртуальную машину - inst1.example.com. Мы будем использовать DRBD, node2 будет первой нодой, виртуальная машина будет иметь 5 GB hard drive, 256 MB swap и 256 MB RAM. На node1.example.com выполняем следующие команды:

gnt-instance add -t drbd -n node2.example.com:node1.example.com -o debootstrap -s 5g --swap-size 256 \
-m 256 --kernel /boot/vmlinuz-`uname -r` --ip 192.168.0.105 inst1.example.com

 Процесс займет несколько минут. Вывод результатов работы будет напоминать примерно следующее:

node1:~# gnt-instance add -t drbd -n node2.example.com:node1.example.com -o debootstrap -s 5g --swap-size 256 \
-m 256 --kernel /boot/vmlinuz-`uname -r` --ip 192.168.0.105 inst1.example.com
* creating instance disks...
adding instance inst1.example.com to cluster config
- INFO: Waiting for instance inst1.example.com to sync disks.
- INFO: - device sda: 3.90% done, 971 estimated seconds remaining
- INFO: - device sdb: 17.00% done, 42 estimated seconds remaining
- INFO: - device sda: 9.00% done, 746 estimated seconds remaining
- INFO: - device sdb: 100.00% done, 0 estimated seconds remaining
- INFO: - device sda: 9.30% done, 727 estimated seconds remaining
- INFO: - device sda: 22.10% done, 786 estimated seconds remaining
- INFO: - device sda: 35.10% done, 224 estimated seconds remaining
- INFO: - device sda: 48.00% done, 205 estimated seconds remaining
- INFO: - device sda: 61.00% done, 183 estimated seconds remaining
- INFO: - device sda: 73.90% done, 120 estimated seconds remaining
- INFO: - device sda: 86.90% done, 36 estimated seconds remaining
- INFO: - device sda: 94.80% done, 344 estimated seconds remaining
- INFO: Instance inst1.example.com's disks are in sync.
creating os for instance inst1.example.com on node node2.example.com
* running the instance OS create scripts...
* starting instance...
node1:~#

 Всё, Ganeti создал полностью готовую виртуальную машину.


[ad name="Google Adsense"]



 (9) Конфигурируем Instance

 Для получения доступа к inst1.example.com, находясь на ноде node1, выполните команду:

gnt-instance console inst1.example.com

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

Checking file systems...fsck 1.41.3 (12-Oct-2008)
done.
Setting kernel variables (/etc/sysctl.conf)...done.
Mounting local filesystems...done.
Activating swapfile swap...done.
Setting up networking....
Configuring network interfaces...done.
INIT: Entering runlevel: 2
Starting enhanced syslogd: rsyslogd.
Starting periodic command scheduler: crond.

 Выключаем instance:

gnt-instance shutdown inst1.example.com

 И запускаем его с параметром --extra "xencons=tty1 console=tty1" (каждый раз при старте):

gnt-instance startup --extra "xencons=tty1 console=tty1" inst1.example.com

 Снова подключаемся к консоли:

gnt-instance console inst1.example.com

 Входим в систему. Логин root, без пароля. Пароль, не теряя времени, создаем командой passwd.

 Создаем строку eth0 в файле /etc/network/interfaces, так как сейчас сетевых интерфейсов, кроме как lo0, на машине inst1.example.com нет.

vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.105
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1

 Перезапускаем сеть:

/etc/init.d/networking restart

 Обновляем систему:

aptitude update
aptitude safe-upgrade

 После обновления устанавливаем OpenSSH и vim-nox:

aptitude install ssh openssh-server vim-nox udev

 Перед подключением к серверу inst1.example.com через SSH, открываем файл /etc/fstab...

vi /etc/fstab

 И добавляем строку (иначе, мы получим ошибку Server refused to allocate pty):

[...]
none /dev/pts devpts gid=5,mode=620 0 0

 Затем выполним команду mount -a.

 Теперь вы можете воспользоваться люблым SSH клиентом для подключения к адресу 192.168.0.105.

 Для выхода из консоли нажмите CTRL+], или CTRL+5 if если вы используете PuTTY.

 (10) Получение справки по командам Ganeti

 Для получения дополнительной информации по Ganeti, воспользуйтесь следующими командами:

man gnt-instance
man gnt-cluster
man gnt-node
man gnt-os
man gnt-backup
man 7 ganeti
man 7 ganeti-os-interface

 Также полезно будет обратиться к Ganeti installation tutorial.

 Запуск instance:

gnt-instance startup inst1.example.com

 Останов instance:

gnt-instance shutdown inst1.example.com

 Вход на консоль:

gnt-instance console inst1.example.com

 Failover instance на вторую ноду (instance должен быть остановлен перед операцией!):

gnt-instance failover inst1.example.com

 Миграция на вторую ноду:

gnt-instance migrate inst1.example.com

 Удаление:

gnt-instance remove inst1.example.com

 Список доступных instance:

node1:~# gnt-instance list
Instance OS Primary_node Status Memory
inst1.example.com debootstrap node2.example.com running 256
node1:~#

 Получение более детальной информации по instance:

node1:~# gnt-instance info
Instance name: inst1.example.com
State: configured to be up, actual state is up
Considered for memory checks in cluster verify: True
Nodes:
- primary: node2.example.com
- secondaries: node1.example.com
Operating system: debootstrap
Kernel path: /boot/vmlinuz-2.6.26-1-xen-686
initrd: (default: /boot/initrd-2.6-xenU)
Hardware:
- VCPUs: 1
- memory: 256MiB
- NICs: {MAC: aa:00:00:b5:00:8d, IP: 192.168.0.105, bridge: eth0}
Block devices:
- sda, type: drbd8, logical_id: (u'node2.example.com', u'node1.example.com', 11000)
primary: /dev/drbd0 (147:0) in sync, status ok
secondary: /dev/drbd0 (147:0) in sync, status ok
- type: lvm, logical_id: (u'xenvg', u'9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data')
primary: /dev/xenvg/9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data (253:2)
secondary: /dev/xenvg/9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data (253:2)
- type: lvm, logical_id: (u'xenvg', u'4ffe2d67-584e-4581-9cd6-30da33c21b04.sda_meta')
primary: /dev/xenvg/4ffe2d67-584e-4581-9cd6-30da33c21b04.sda_meta (253:3)
secondary: /dev/xenvg/4ffe2d67-584e-4581-9cd6-30da33c21b04.sda_meta (253:3)
- sdb, type: drbd8, logical_id: (u'node2.example.com', u'node1.example.com', 11001)
primary: /dev/drbd1 (147:1) in sync, status ok
secondary: /dev/drbd1 (147:1) in sync, status ok
- type: lvm, logical_id: (u'xenvg', u'4caff02e-3864-47b3-ba58-b71854a7b7c0.sdb_data')
primary: /dev/xenvg/4caff02e-3864-47b3-ba58-b71854a7b7c0.sdb_data (253:4)
secondary: /dev/xenvg/4caff02e-3864-47b3-ba58-b71854a7b7c0.sdb_data (253:4)
- type: lvm, logical_id: (u'xenvg', u'51fb132b-083e-42e2-aefa-31fd485a8aab.sdb_meta')
primary: /dev/xenvg/51fb132b-083e-42e2-aefa-31fd485a8aab.sdb_meta (253:5)
secondary: /dev/xenvg/51fb132b-083e-42e2-aefa-31fd485a8aab.sdb_meta (253:5)
node1:~#

 Получение информации о кластере:

node1:~# gnt-cluster info
Cluster name: cluster1.example.com
Master node: node1.example.com
Architecture (this node): 32bit (i686)
Cluster hypervisor: xen-3.0
node1:~#

 Проверка кластера:

node1:~# gnt-cluster verify
* Verifying global settings
* Gathering data (2 nodes)
* Verifying node node1.example.com
* Verifying node node2.example.com
* Verifying instance inst1.example.com
* Verifying orphan volumes
* Verifying remaining instances
* Verifying N+1 Memory redundancy
* Other Notes
* Hooks Results
node1:~#

 Поиск владельца кластера:

node1:~# gnt-cluster getmaster
node1.example.com
node1:~#

 Failover владельца кластера, если тот упал (выдаст ошибку, если выполняется на самом владельце):

gnt-cluster masterfailover

 Информация о разделах instance на кластерах:

node1:~# gnt-node volumes
Node PhysDev VG Name Size Instance
node1.example.com /dev/sda2 vg0 root 28608 -
node1.example.com /dev/sda2 vg0 swap_1 952 -
node1.example.com /dev/sda3 xenvg 4caff02e-3864-47b3-ba58-b71854a7b7c0.sdb_data 256 inst1.example.com
node1.example.com /dev/sda3 xenvg 4ffe2d67-584e-4581-9cd6-30da33c21b04.sda_meta 128 inst1.example.com
node1.example.com /dev/sda3 xenvg 51fb132b-083e-42e2-aefa-31fd485a8aab.sdb_meta 128 inst1.example.com
node1.example.com /dev/sda3 xenvg 9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data 5120 inst1.example.com
node2.example.com /dev/hda2 vg0 root 28608 -
node2.example.com /dev/hda2 vg0 swap_1 952 -
node2.example.com /dev/hda3 xenvg 4caff02e-3864-47b3-ba58-b71854a7b7c0.sdb_data 256 inst1.example.com
node2.example.com /dev/hda3 xenvg 4ffe2d67-584e-4581-9cd6-30da33c21b04.sda_meta 128 inst1.example.com
node2.example.com /dev/hda3 xenvg 51fb132b-083e-42e2-aefa-31fd485a8aab.sdb_meta 128 inst1.example.com
node2.example.com /dev/hda3 xenvg 9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data 5120 inst1.example.com
node1:~#

 Удаление ноды с кластера:

gnt-node remove node2.example.com

 Информация об ОС, поддерживаемых кластером (в настоящее время только debootstrap):

node1:~# gnt-os list
Name
debootstrap
node1:~#

 (11) Пример Failover

 Давайте предположим, что вы решили провести обслуживание ноды node2.example.com и поэтому хотите перенести inst1.example.com на node1 (обратите внимание на то, что inst1.example.com будет выключен на время переноса).

 Просмотрим наши instances:

node1:~# gnt-instance list
Instance OS Primary_node Status Memory
inst1.example.com debootstrap node2.example.com running 256
node1:~#

 Как вы видите - node2 является первой нодой. Перенос inst1.example.com на node1 осуществляется следующей командой:

gnt-instance failover inst1.example.com

 Процесс происходит так:

node1:~# gnt-instance failover inst1.example.com
Failover will happen to image inst1.example.com. This requires a
shutdown of the instance. Continue?
y/[n]/?: <-- y * checking disk consistency between source and target * shutting down instance on source node * deactivating the instance's disks on source node * activating the instance's disks on target node * starting the instance on the target node node1:~#
 После переноса выполним команду:

gnt-instance list

 И убедимся в том, что node1 является первой нодой:

node1:~# gnt-instance list
Instance OS Primary_node Status Memory
inst1.example.com debootstrap node1.example.com running 256
node1:~#

 inst1.example.com можно запускать сразу после переноса, необходимо только исправить проблему консоли (раздел (9)):

gnt-instance shutdown inst1.example.com
gnt-instance startup --extra "xencons=tty1 console=tty1" inst1.example.com

 Теперь роняем node2:

shutdown -h now

 После выключения node2 вы можете попробовать подключиться к inst1.example.com - все должно работать.

 После проведения технического обслуживания node2, необходимо снова вернуть ноде статус первой. Для этого, на node1 выполняем команду:

gnt-instance failover inst1.example.com

 Но нас ждет подвох: HDD inst1.example.com на node2 поврежденd (то есть не синхронизирован).

node1:~# gnt-instance failover inst1.example.com
Failover will happen to image inst1.example.com. This requires a
shutdown of the instance. Continue?
y/[n]/?: <-- y * checking disk consistency between source and target Node node2.example.com: Disk degraded, not found or node down Failure: command execution error: Disk sda is degraded on target node, aborting failover. node1:~#
 Для исправления этой ошибки мы заменим диск inst1.example.com на node2 зеркальным диском с текущей первой ноды, node1:

gnt-instance replace-disks -s inst1.example.com

 В результате, inst1.example.com должен заработать:

node1:~# gnt-instance replace-disks -s inst1.example.com
STEP 1/6 check device existence
- INFO: checking volume groups
- INFO: checking sda on node2.example.com
- INFO: checking sda on node1.example.com
- INFO: checking sdb on node2.example.com
- INFO: checking sdb on node1.example.com
STEP 2/6 check peer consistency
- INFO: checking sda consistency on node1.example.com
- INFO: checking sdb consistency on node1.example.com
STEP 3/6 allocate new storage
- INFO: creating new local storage on node2.example.com for sda
- INFO: creating new local storage on node2.example.com for sdb
STEP 4/6 change drbd configuration
- INFO: detaching sda drbd from local storage
- INFO: renaming the old LVs on the target node
- INFO: renaming the new LVs on the target node
- INFO: adding new mirror component on node2.example.com
- INFO: detaching sdb drbd from local storage
- INFO: renaming the old LVs on the target node
- INFO: renaming the new LVs on the target node
- INFO: adding new mirror component on node2.example.com
STEP 5/6 sync devices
- INFO: Waiting for instance inst1.example.com to sync disks.
- INFO: - device sda: 1.80% done, 560 estimated seconds remaining
- INFO: - device sdb: 12.40% done, 35 estimated seconds remaining
- INFO: - device sda: 5.80% done, 832 estimated seconds remaining
- INFO: - device sdb: 89.30% done, 3 estimated seconds remaining
- INFO: - device sda: 6.40% done, 664 estimated seconds remaining
- INFO: - device sdb: 98.50% done, 0 estimated seconds remaining
- INFO: - device sda: 6.50% done, 767 estimated seconds remaining
- INFO: - device sdb: 100.00% done, 0 estimated seconds remaining
- INFO: - device sda: 6.50% done, 818 estimated seconds remaining
- INFO: - device sda: 19.30% done, 387 estimated seconds remaining
- INFO: - device sda: 32.00% done, 281 estimated seconds remaining
- INFO: - device sda: 44.70% done, 242 estimated seconds remaining
- INFO: - device sda: 57.30% done, 195 estimated seconds remaining
- INFO: - device sda: 70.00% done, 143 estimated seconds remaining
- INFO: - device sda: 82.70% done, 74 estimated seconds remaining
- INFO: - device sda: 95.40% done, 20 estimated seconds remaining
- INFO: - device sda: 99.80% done, 3 estimated seconds remaining
- INFO: Instance inst1.example.com's disks are in sync.
STEP 6/6 removing old storage
- INFO: remove logical volumes for sda
- INFO: remove logical volumes for sdb
node1:~#

 Повторяем процедуру переноса, выполняя следующую команду на node1:

gnt-instance failover inst1.example.com

 Проверяем список:

node1:~# gnt-instance list
Instance OS Primary_node Status Memory
inst1.example.com debootstrap node2.example.com running 256
node1:~#

 Запускаем instance:

gnt-instance shutdown inst1.example.com
gnt-instance startup --extra "xencons=tty1 console=tty1" inst1.example.com

 (12) Пример живой миграции

 Одной из самых замечательных функций Ganeti является возможность живой миграции instance (данный функционал доступен только при использовании DRBD 0.8).

 Для миграции inst1.example.com с node2 на node1 выполните команду:

gnt-instance migrate inst1.example.com


node1:~# gnt-instance migrate inst1.example.com
Instance inst1.example.com will be migrated. Note that migration is
**experimental** in this version. This might impact the instance if
anything goes wrong. Continue?
y/[n]/?: <-- y * checking disk consistency between source and target * identifying disks * switching node node1.example.com to secondary mode * changing into standalone mode * changing disks into dual-master mode * wait until resync is done * migrating instance to node1.example.com * switching node node2.example.com to secondary mode * wait until resync is done * changing into standalone mode * changing disks into single-master mode * wait until resync is done * done node1:~#
 Убедимся, что inst1.example.com действительно работает на node1:

node1:~# gnt-instance list
Instance OS Primary_node Status Memory
inst1.example.com debootstrap node1.example.com running 256
node1:~#

 Мигрируем обратно на node2:

node1:~# gnt-instance migrate inst1.example.com
Instance inst1.example.com will be migrated. Note that migration is
**experimental** in this version. This might impact the instance if
anything goes wrong. Continue?
y/[n]/?: <-- y * checking disk consistency between source and target * identifying disks * switching node node2.example.com to secondary mode * changing into standalone mode * changing disks into dual-master mode * wait until resync is done * migrating instance to node2.example.com * switching node node1.example.com to secondary mode * wait until resync is done * changing into standalone mode * changing disks into single-master mode * wait until resync is done * done node1:~# gnt-instance list node1:~# gnt-instance list Instance OS Primary_node Status Memory inst1.example.com debootstrap node2.example.com running 256 node1:~#
 (13) Создание резервной копии Instance

 Для создания резервной копии inst1.example.com на node1 выполните следующие действия (instance должен быть остановлен перед этой операцией, команда выполняется на node1):

gnt-backup export -n node1.example.com inst1.example.com

 Резервная копия будет сохранена в каталоге /var/lib/ganeti/export/inst1.example.com/.

node1:~# ls -l /var/lib/ganeti/export/inst1.example.com/
total 108788
-rw-r--r-- 1 root root 111279899 2009-02-26 17:30 9c923acc-14b4-460d-946e-3b0d4d2e18e6.sda_data.snap
-rw------- 1 root root 391 2009-02-26 17:30 config.ini
node1:~#

 Для экспорта бэкапа на другую ноду кластера, например node3, выполните команду:

gnt-backup import -n node3.example.com -t drbd --src-node=node1.example.com \
--src-dir=/var/lib/ganeti/export/inst1.example.com/ inst1.example.com

 (14) Masterfailover

 Давайте предположим, что владелец кластера по какой-либо причине вышел из строя. Чтобы сделать node2 новым владельцем, мы должны выполнить на node2 следующую команду:

gnt-cluster masterfailover
gnt-cluster getmaster

Проверим, что node2 является владельцем кластера

node2:~# gnt-cluster getmaster
node2.example.com
node2:~#

 После поднятия node1 мы получим ситуацию, когда у нас два владельца кластера:

node1:~# gnt-cluster getmaster
node1.example.com
node1:~#

 node1 по прежнему считает себя владельцем кластера, в то время, как реальный владелец - node2. Для того, чтобы исправить данную ситуацию, отредактируем файл /var/lib/ganeti/ssconf_master_node на node1:

chmod 600 /var/lib/ganeti/ssconf_master_node
vi /var/lib/ganeti/ssconf_master_node


node2.example.com


chmod 400 /var/lib/ganeti/ssconf_master_node

 После этого проверим результат:

node1:~# gnt-cluster getmaster
node2.example.com
node1:~#

 Для назначения владельцем node1, выполните на node1 команду:

gnt-cluster masterfailover

Используемая литература:
Ganeti: http://code.google.com/p/ganeti
Xen: http://xen.xensource.com
DRBD: http://www.drbd.org
LVM: http://sourceware.org/lvm2
Debian: http://www.debian.org


[ad name="Google Adsense"]



 Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

CAPTCHA

*