Ganeti – это система управления кластерной виртуализацией на базе Xen. В этом руководстве мы рассмотрим, как создать виртуальную машину Xen (instance) на кластере двух физических машин, как управлять этой виртуальной машиной и как обеспечить ее отказоустойчивость.
Как обычно, не дается никаких гарантий и вы предупреждены о возможных последствиях.
(1) Предварительное примечание
Мы будем использовать две физические ноды node1.example.com и node2.example.com:
Обе ноды имеют жесткие диски по 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 interfaceauto 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 -lDisk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00023cd1Device 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/sdaThe 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 -lDisk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00023cd1Device 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 itThe 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 создал полностью готовую виртуальную машину.
(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.
Интересное
Всем всем, для кого буквы C&C не пустой звук – Фан-сайт Command & Conquer. Самая полная информация о игре.
Создаем строку eth0 в файле /etc/network/interfaces, так как сейчас сетевых интерфейсов, кроме как lo0, на машине inst1.example.com нет.
vi /etc/network/interfacesauto lo
iface lo inet loopbackauto 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 infoCluster 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 getmasternode1.example.com node1:~#
Failover владельца кластера, если тот упал (выдаст ошибку, если выполняется на самом владельце):
gnt-cluster masterfailover
Информация о разделах instance на кластерах:
node1:~# gnt-node volumesNode 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 listName debootstrap node1:~#
(11) Пример Failover
Давайте предположим, что вы решили провести обслуживание ноды node2.example.com и поэтому хотите перенести inst1.example.com на node1 (обратите внимание на то, что inst1.example.com будет выключен на время переноса).
Это полезно:
Если вам понадобиться эвакуатор в москве, советую заказать его тут: эвакуатор.
Просмотрим наши instances:
node1:~# gnt-instance listInstance 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.comFailover 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 listInstance OS Primary_node Status Memory inst1.example.com debootstrap node1.example.com running 256 node1:~#
inst1.example.com можно запускать сразу после переноса, необходимо только исправить проблему консоли (раздел (9)):
gnt-instance shutdown inst1.example.comgnt-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.comFailover 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.comSTEP 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 listInstance OS Primary_node Status Memory inst1.example.com debootstrap node2.example.com running 256 node1:~#
Запускаем instance:
gnt-instance shutdown inst1.example.comgnt-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.comInstance 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 listInstance OS Primary_node Status Memory inst1.example.com debootstrap node1.example.com running 256 node1:~#
Мигрируем обратно на node2:
node1:~# gnt-instance migrate inst1.example.comInstance 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 masterfailovergnt-cluster getmaster
Проверим, что node2 является владельцем кластера
node2:~# gnt-cluster getmasternode2.example.com node2:~#
После поднятия node1 мы получим ситуацию, когда у нас два владельца кластера:
node1:~# gnt-cluster getmasternode1.example.com node1:~#
node1 по прежнему считает себя владельцем кластера, в то время, как реальный владелец – node2. Для того, чтобы исправить данную ситуацию, отредактируем файл /var/lib/ganeti/ssconf_master_node на node1:
chmod 600 /var/lib/ganeti/ssconf_master_nodevi /var/lib/ganeti/ssconf_master_node
node2.example.com
chmod 400 /var/lib/ganeti/ssconf_master_node
После этого проверим результат:
node1:~# gnt-cluster getmasternode2.example.com node1:~#
Для назначения владельцем node1, выполните на node1 команду:
gnt-cluster masterfailover
Источник: howtoforge.com
Перевод: Сгибнев Михаил. Оригинал перевода