headermask image

Управление кластером Xen с помощью Ganeti на 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 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

    Перевод: Сгибнев Михаил. Оригинал перевода

    Print This Post Print This Post
    Похожие посты
  • Как пересобрать deb-пакет
  • Использование iSCSI на Debian Lenny (Initiator и Target)
  • Управление групповыми политиками с помощью Advanced Group Policy Management (AGPM) v4, часть 2
  • Живая миграция OpenVZ контейнера
  • Включаем Aero в Windows 7 с помощью реестра
  • Управление групповыми политиками с помощью Advanced Group Policy Management (AGPM) v4, часть 3
  • Миграция с Windows XP в Windows 7 с помощью MDT 2010
  • Удаленное подключение к рабочему столу Linux из Windows с помощью Xming и SSH
  • Debian vs Ubuntu: еще один великолепный миф?
  • Установка и настройка SSHD в среде chroot при помощи makejail