KVM HA Cluster on 2 Nodes Mode

 

KVM HA Cluster построен на 2х серверах с KVM(Настройка KVM здесь не описывается, в сети навалом статей) поверх Debian 8.6.
High Availability построено на основе Pacemaker c Live Migration. СХД NFS - based.
Здесь VM можно создавать и использовать и в безкластерном режиме(Live Migration в нем также поддерживается, но нет HA), при необходимости - перенести в кластер.
Для управления средой виртуализации необходимо использовать virsh(консольный менеджер) или virt-manager(gui-менеджер) и crm (CRM shell for the pacemaker cluster manager).

kvm1: IP 10.10.10.4/24, IPMI 192.168.0.4/24

kvm2: IP 10.10.10.5/24, IPMI 192.168.0.5/24

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

Установка пакетов и настройка нод кластера.

# aptitude install bridge-utils qemu qemu-kvm libvirt-bin virtinst openipmi

Типовая настройка сетевых интерфейсов нод(отличаются толко ip адресом).

# cat /etc/network/interfaces 
# This file describes the network interfaces available on your system 
# and how to activate them. For more information, see interfaces(5). 
source /etc/network/interfaces.d/* 
# The loopback network interface 
auto lo 
iface lo inet loopback 
# The primary network interface 
#allow-hotplug eth0 
auto eth0 
iface eth0 inet static 
address 10.10.10.4 
netmask 255.255.255.0 
gateway 10.10.10.1 
auto eth1 
#iface eth1 inet manual 
auto eth1.20 
iface eth1.20 inet manual 
vlan-raw-device eth1 
auto eth1.300 
iface eth1.300 inet manual 
vlan-raw-device eth1 
auto eth1.405 
iface eth1.405 inet manual 
vlan-raw-device eth1 

Подключаем репозиторий jessie-backports.

cat > /etc/apt/sources.list.d/jessie-backports.list << "EOF"
deb http://http.debian.net/debian jessie-backports main
EOF

Устанавливаем кластерные пакеты

# apt-get update 
# apt-get install -t jessie-backports pacemaker crmsh 

Генерируем ключ 

# corosync-keygen

Копируем его на  kvm2

root@kvm1:~# scp /etc/corosync/corosync.conf root@kvm2:/etc/corosync/corosync.conf 
root@kvm1:~# scp /etc/corosync/authkey root@kvm2:/etc/corosync/authkey

Конфигурируем corosync

kvm 1 

# egrep -v '#|^$' /etc/corosync/corosync.conf 
totem { 
version: 2 
cluster_name: debian 
token: 3000 
token_retransmits_before_loss_const: 10 
clear_node_high_bit: yes 
crypto_cipher: aes256 
crypto_hash: sha1 
interface { 
ringnumber: 0 
bindnetaddr: 10.10.10.0 
mcastaddr: 239.255.1.1 
mcastport: 5405 
ttl: 1 
} 
} 
logging { 
fileline: off 
to_stderr: no 
to_logfile: no 
to_syslog: yes 
syslog_facility: daemon 
debug: off 
timestamp: on 
logger_subsys { 
subsys: QUORUM 
debug: off 
} 
} 
quorum { 
provider: corosync_votequorum 
two_node: 1 
expected_votes: 2 
} 

 

kvm 2 

root@kvm2:~# egrep -v '#|^$' /etc/corosync/corosync.conf totem { 
version: 2 
cluster_name: debian 
token: 3000 
token_retransmits_before_loss_const: 10 
clear_node_high_bit: yes 
crypto_cipher: aes256 
crypto_hash: sha1 
interface { 
ringnumber: 0 
bindnetaddr: 10.10.10.0 
mcastaddr: 239.255.1.1 
mcastport: 5405 
ttl: 1 
} 
} 
logging { 
fileline: off 
to_stderr: no 
to_logfile: no 
to_syslog: yes 
syslog_facility: daemon 
debug: off 
timestamp: on 
logger_subsys { 
subsys: QUORUM 
debug: off 
} 
} 
quorum { 
provider: corosync_votequorum 
two_node: 1 
expected_votes: 2 
}  

Стартуем и добавляем в автозагрузку

# systemctl start corosync.service 
# systemctl start pacemaker.service 
# systemctl enable corosync.service 
# systemctl enable pacemaker.service 
# crm status

NFS

root@nfs1:~# cat /etc/exports 
/data/nfs    10.10.10.4(rw,sync,no_subtree_check,no_root_squash)  10.10.10.5(rw,sync,no_subtree_check,no_root_squash)

На kvm1 и kvm2 NFS директории монитруются средствами KVM(Здесь не описывается, в сети навалом статей).

Создание новой VM - vm1(Стандартным для KVM способом).

virt-install -n vm1 --ram 1024 --arch=x86_64 --vcpus=2 --cpu host --check-cpu \ 
--os-type linux --os-variant=rhel7 --cdrom /home/Centos7.iso --disk pool=guest_images_dir,size=50,bus=virtio \ 
--network=bridge:br1.20 --graphics vnc,listen=0.0.0.0,keymap=ru,password=pass --noautoconsole \ 
--watchdog default,action=reset --virt-type=kvm 

После успешного выполнения команды проверяем и добавляем в автозапуск.

root@kvm1:~# virsh list --all
Id Name State
—————————————————-
20 vm1 running
root@kvm1:~# virsh autostart vm1

Подключаемся на консоль VM при помощи virt-manager и проводим установку ОС. Дальнейшее изменение конфигурации VM делать стандартно или virsh или virt-manager(классика). Для вступления изменений в силу в большинстве случаев требуется перезапуск VM.

Live Migration

Для работоспособности данного функционала диск(и) должны располагаться на NFS, и у  VM необходимо изменить режим кеширования, переведя его в none.

Также неоходимо выставить владельцем файла виртуального HDD пользователя и группу libvirt-qemu, разумеется uid и gid должны совпадать на обеих нодах кластера.

root@kvm1:~# chown libvirt-qemu:libvirt-qemu /data/nfs/nfs1/kvm/guest_images/vm1.qcow2
root@kvm1:~# ls -la /data/nfs/nfs1/kvm/guest_images/
***
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 40437088256 Jan  9  2017 vm1.qcow2
***
root@kvm2:~# ls -la /data/nfs/nfs1/kvm/guest_images/
 
***
-rw-r--r-- 1 libvirt-qemu libvirt-qemu 40437088256 Jan  9  2017 vm1.qcow2
***
root@nfs1:~# ls -la /data/nfs/kvm/guest_images/
 
***
-rw-r--r-- 1 kvm-images kvm-images 40437088256 Jan  9 08:58 vm1.qcow2
 
***

На NFS сервере необходимо создать отдельного пользователя и группу вручную, их uid и gid должны совпадать с  uid и gid  нод кластера.

Ниже приведены фрагменты файлов /etc/passwd для наглядности.

root@kvm1:~# grep qemu /etc/passwd
libvirt-qemu:x:108:114:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false
root@kvm2:~# grep qemu /etc/passwd
libvirt-qemu:x:108:114:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false
root@nfs1:~# grep kvm /etc/passwd
kvm-images:x:108:115::/home/kvm-images:/bin/false

Миграция выполняется следующей командой(здесь 10.10.10.5 - куда мигрируем(KVM2)): 

root@kvm1:~# virsh migrate --live vm1 qemu+ssh://10.10.10.5/system 

VM переедет «без остановки».

Перенос VM в HA Pacemaker

Для переноса в Pacemaker.

primitive vm1 VirtualDomain \ 
params config="/data/nfs/nfs1/kvm/guest_images/qemu_config/vm1.xml" hypervisor="qemu:///system" migration_transport=ssh \ 
meta allow-migrate=true priority=100 target-role=Started is-managed="true" \ 
op start timeout=120s interval=0 \ 
op stop timeout=120s interval=0 \ 
op monitor timeout=30 interval=10 depth=0 \ 
op migrate_from interval=0 timeout=120s \ 
op migrate_to interval=0 timeout=120s 

При выходе из режима конфигурации crm запросит commit, жмем у. Далее запускаем vm1. 

resource start vm1
  1. VM необходимо остановить(virsh shutdown vm1).
  2. Перенести файл hdd на NFS(nfs1) и файл конфигурации, в нашем случае новый путь на NFS /data/nfs/nfs1/kvm/guest_images/qemu_config/vm1.xml.
  3. Удаляем определение VM(virsh undefine vm1).
  4. Проверяем, что с исходного места(/etc/libvirt/qemu/) файл конфигурации удалился.
  5. Запускаем crm на любой ноде(root@kvm1:~#crm), переходим в режим конфигурации(crm→configure).
  6. Создаем новый ресурс.
  7. Смотрим статус.

    root@kvm1:~#crm status 

Теперь при падении 1ноды кластера(kvm1) все VM будут запущены на оставшейся ноде(kvm2). При возвращении в строй 1 ноды(kvm1) все VM, которые на ней выполнялись переедут обратно на нее.(failback). Тоже и при падении 2 ноды(kvm2).

Дальнейшее изменение конфигурации VM(лично мне удобнее) делать в следующем порядке:

  1. Редактируем параметры VM во включенном состоянии при помощи virt-manager, по завершении создастся файл конфигурации в /etc/libvirt/qemu/.
  2. Заменяем новым конфигом файл конфигурации, хранящийся на NFS( /data/nfs/nfs1/kvm/guest_images/qemu_config/vm1.xml)
  3. С исходного места(/etc/libvirt/qemu/) файл конфигурации удаляем.
  4. Перезапускаем VM только через crm.
crm(live)# resource restart vm1

Управление VM в кластере

Эти команды без комментариев.

crm(live)# resource start vm1
crm(live)# resource restart vm1
crm(live)# resource stop vm1

live-migration
Допустим vm1 выполняется на ноде kvm1. Чтобы перенести ее на kvm2 без остановки(online) необходимо через crm выполнить.

resource move vm1 kvm2

SplitBrain STONITH

Если ноды теряют связь по heartbeat,  то обе выстрелят друг в друга через IPMI reboot,  обе будут перезагружаться, пока heartbeat между ними не восстановится(Нештатная ситуация, например  случайно закрыли порт heartbeat в iptables).

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

В crm

primitive impi-fencing-kvm2 stonith:external/ipmi \
params hostname="kvm2" \
ipaddr="192.168.0.5" \
userid="ADMIN" passwd="ADMIN" \
op monitor interval=0 timeout=30s 
 
location impi-fencing-kvm2_loc impi-fencing-kvm2 rule -inf: \#uname ne kvm1

 

primitive impi-fencing-kvm1 stonith:external/ipmi \
params hostname="kvm1" \
ipaddr="192.168.0.4" \
userid="ADMIN" passwd="ADMIN" \
op monitor interval=0 timeout=30s 
 
location impi-fencing-kvm1_loc impi-fencing-kvm1 rule -inf: \#uname ne kvm2

 

Здесь stonith ресурсы привязываются к нодам перекрестно(ключевой момент).

 На этом все, критику и замечания прошу в комменты:)!

Категории: