The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Управление кластером Xen с помощью Ganeti на Debian Lenny (xen cluster ganeti debian)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: xen, cluster, ganeti, debian,  (найти похожие документы)
From: Сгибнев Михаил Date: Mon, 3 Feb 2010 17:02:14 +0000 (UTC) Subject: Управление кластером Xen с помощью Ganeti на Debian Lenny Оригинал: http://dreamcatcher.ru/linux/006_xen.html Оригинал на английском: http://howtoforge.com/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): <-- 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 Устанавливаем 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: 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: 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 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:~# Пример 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 Пример живой миграции Одной из самых замечательных функций 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

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру