Ключевые слова:xen, cluster, virtual, debian, linux, (найти похожие документы)
From: Сгибнев Михаил <msgibnev(ого-го какая собака)gmail.com>
Date: Mon, 15 Jan 2010 17:02:14 +0000 (UTC)
Subject: Управление кластером Xen с помощью Ganeti на Debian Lenny
Оригинал: http://dreamcatcher.ru/linux/006_xen.html
Автор: Xen Cluster Management With Ganeti On Debian Lenny
Перевод: Сгибнев Михаил
Ganeti - это система управления кластерной виртуализацией на базе
Xen. В этом руководстве мы рассмотрим, как создать виртуальную
машину Xen (instance) на кластере двух физических машин, как управлять
этой виртуальной машиной и как обеспечить ее отказоустойчивость.
Как обычно, не дается никаких гарантий и вы предупреждены о возможных
последствиях.
Предварительное примечание
Мы будем использовать две физические ноды 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 может работать
некорректно. Ну, приступим.
Подготавливаем ноды
Я использую на 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.
Настраиваем 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): <-- ENTE
R
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
Устанавливаем 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
Устанавливаем 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]+|" ]
[...]
Инициализируем кластер:
Принимая наши исходные данные, имя кластера 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.
Добавляем ноду 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:~#
Поднимаем 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 создал полностью готовую виртуальную машину.
Конфигурируем 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.
Получение справки по командам 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 root28608 -
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:~#
Пример 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 можно запускать сразу после переноса, необходимо
только исправить проблему консоли:
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
Пример живой миграции
Одной из самых замечательных функций 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:~#
Создание резервной копии 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
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
Спасибо автору, хорошо "для затравки". Добавлю пару хинтов:
1. Чтобы завести на clvm (при наличии фибового/iscsi/etc хранилища), можно поправить plain-модель, а именно class LUInstanceMove(LogicalUnit) в cmdlib.py. Просто закоментить там создание/копирование/удаление. Это даст хотя бы возможность перемещать instance (иначе move убьет раздел).
Текущий код проекта сильно "сцепленный", поэтому описать свое хранилище, не будучи профессиональным питонистом, для меня не реально.
2. Чтобы нормально стартовали xen-pvs (c pygrub), делаем примерно так (centos 5):
gnt-cluster modify --enabled-hypervisors xen-pvm,xen-hvm --hypervisor-parameters xen-hvm:device_model=/usr/lib64/xen/bin/qemu-dm,vnc_password_file=/var/gfs/GANETI/vnc_password_file --hypervisor-parameters xen-pvm:use_bootloader=True
Вот это я бы в FAQ внес, вместо кочующих по инету извращений (не в обиду автору).
Теперь просто создаем инстанс с пустым разделом
gnt-instance add --no-install --disk-template plain --node n1 --disk 0:size=8G --no-ip-check --no-name-check --net 0:mode=bridged,link=br22 --backend-parameters memory=512,vcpus=2 --os-type debootstrap gn1.example.org
Заливаем в созданный раздел какой-нибудь pvs-шаблон:
dd if=/var/gfs/IMG/ubuntu10.xen of=/dev/clvm0/802a7b58-0998-45e4-b911-4a2f16f0e4a6.disk0 bs=8M
И все. Стартуем
gnt-instance start gn1
gnt-instance console gn1
gnt-instance move -n n3 gn1
Fri Oct 7 16:21:02 2011 - INFO: Shutting down instance gn1.example.org on source node n1.example.org
Fri Oct 7 16:21:08 2011 - INFO: Copying data for disk 0
Fri Oct 7 16:21:08 2011 - INFO: Removing the disks on the original node
Fri Oct 7 16:21:08 2011 - INFO: Starting instance gn1.example.org on node n3.example.org
