Настройка отказоустойчивого кластера OpenNebula
Виртуализация / KVM
24 минуты read (About 3591 words)

Настройка отказоустойчивого кластера OpenNebula

Настройка High Available кластера на базе OpenNebula

Данная статья является продолжением серии предыдущих постов.
Я буду использовать pacemaker, corosync и crmsh.

Отключим автозапуск демонов OpenNebula на всех серверах

systemctl disable opennebula opennebula-sunstone opennebula-novnc
Добавим ha-clustering репозиторий

/etc/yum.repos.d/network\:ha-clustering\:Stable.repo

[network_ha-clustering_Stable]
name=Stable High Availability/Clustering packages (CentOS_CentOS-7)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/repodata/repomd.xml.key
enabled=1

Установим необходимые пакеты

yum install corosync pacemaker crmsh resource-agents -y

Если конфликтуют пакеты при установке resource-agents, установим дополнительно:

sudo yum install cifs-utils psmisc lvm2

На основном сервере KVM-1, редактируем файл corosync.conf и приводим его к следующему виду:

totem {
        version: 2
        crypto_cipher: none
        crypto_hash: none
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.2.0
                broadcast: yes
                mcastport: 5405
                ttl: 1
        }
}
logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        logfile: /var/log/cluster/corosync.log
        to_syslog: yes
        debug: off
        timestamp: on
        logger_subsys {
                subsys: QUORUM
                debug: off
        }
}
quorum {
        provider: corosync_votequorum
}
service {
name: pacemaker
ver: 1
}
nodelist {
        node {
                ring0_addr: KVM-1
                nodeid: 1
        }
        node {
                ring0_addr: KVM-2
                nodeid: 2
        }
        node {
                ring0_addr: KVM-3
                nodeid: 3
        }
}

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

cd /etc/corosync
corosync-keygen

Копируем конфигурационные файлы на другие сервера кластера:

scp /etc/corosync/{corosync.conf,authkey} oneadmin@KVM-2:/etc/corosync
scp /etc/corosync/{corosync.conf,authkey} oneadmin@KVM-3:/etc/corosync

Запускаем сервисы:

sudo systemctl start pacemaker corosync
sudo systemctl enable pacemaker corosync

Если сервис стартует с ошибкой: 

-- Unit corosync.service has begun starting up.
Aug 29 12:59:49 H1Ceph-node01 corosync[400894]:   [MAIN  ] Corosync Cluster Engine ('2.3.4'): started and ready to provide service.
Aug 29 12:59:49 H1Ceph-node01 corosync[400894]:   [MAIN  ] Corosync built-in features: dbus systemd xmlconf snmp pie relro bindnow
Aug 29 12:59:49 H1Ceph-node01 corosync[400894]:   [MAIN  ] Can't autogenerate multicast address
Aug 29 12:59:49 H1Ceph-node01 corosync[400894]:   [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1250.
Aug 29 12:59:49 H1Ceph-node01 corosync[400888]: Starting Corosync Cluster Engine (corosync): [FAILED]
Aug 29 12:59:49 H1Ceph-node01 systemd[1]: corosync.service: control process exited, code=exited status=1
Aug 29 12:59:49 H1Ceph-node01 systemd[1]: Failed to start Corosync Cluster Engine.

Выполняем даунгрейд sudo yum downgrade corosync corosynclib

Проверяем статус работы:

sudo crm status
Last updated: Fri Apr  8 13:25:09 2016          Last change: Fri Apr  8 13:24:50 2016 by hacluster via crmd on KVM-2
Stack: corosync
Current DC: KVM-2 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
3 nodes and 0 resources configured

Online: [ KVM-1 KVM-2 KVM-3 ]

Full list of resources:

Отключим STONITH (механизм добивания неисправной ноды)
(В конце статьи присутствует ссылка на материал об этом). 

crm configure property stonith-enabled=false

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

crm configure property no-quorum-policy=stop

Создаем ресурсы:

crm

configure

primitive ClusterIP ocf:heartbeat:IPaddr2 params ip="192.168.2.111" cidr_netmask="24" op monitor interval="30s"

primitive opennebula_p systemd:opennebula op monitor interval=60s timeout=20s op start interval="0" timeout="120s" op stop  interval="0" timeout="120s"

primitive opennebula-sunstone_p systemd:opennebula-sunstone op monitor interval=60s timeout=20s op start interval="0" timeout="120s" op stop  interval="0" timeout="120s"

primitive opennebula-novnc_p systemd:opennebula-novnc op monitor interval=60s timeout=20s op start interval="0" timeout="120s" op stop  interval="0" timeout="120s"

group Opennebula_HA ClusterIP opennebula_p opennebula-sunstone_p opennebula-novnc_p

exit

В данном случае мы создали виртуальный адрес 192.168.2.111, добавили три сервиса OpenNebula в кластер и объеденили их в группу Opennebula_HA.

Проверяем состояние:

sudo crm status
Last updated: Fri Apr  8 13:32:44 2016          Last change: Fri Apr  8 13:32:10 2016 by root via cibadmin on KVM-1
Stack: corosync
Current DC: KVM-2 (version 1.1.13-10.el7_2.2-44eb2dd) - partition with quorum
3 nodes and 4 resources configured

Online: [ KVM-1 KVM-2 KVM-3 ]

Full list of resources:

 Resource Group: Opennebula_HA
     ClusterIP  (ocf::heartbeat:IPaddr2):       Started KVM-1
     opennebula_p       (systemd:opennebula):   Started KVM-1
     opennebula-sunstone_p      (systemd:opennebula-sunstone):  Started KVM-1
     opennebula-novnc_p (systemd:opennebula-novnc):     Started KVM-1

Настройка OpenNebula

На данном этапе необходимо добавить ноды, хранилище и виртуальные сети в наш кластер.

Веб-интерфейс Sunstone будет доступен по адресу http://192.168.2.111:9869:

1) Создаем кластер;
2) Добавляем ноды;

Если в процессе добавления хостов появится ошибка, то исправляем её повторной установкой /usr/share/one/install_gems, либо запускаем onehost sync --force.

Fri Apr 8 13:40:47 2016 : Error monitoring Host H1-KVM-1 (0):

Все ноды должны быть активны:

3) Добавляем виртуальную сеть:

cat << EOT > ovs.net
NAME="Management"
BRIDGE="ovs-br0"
DNS="192.168.2.6"
GATEWAY="192.168.2.1"
NETWORK_ADDRESS="192.168.2.0"
NETWORK_MASK="255.255.255.0"
VLAN="NO"
VLAN_ID=""
EOT
onevnet create ovs.net

4) Добавляем Ceph хранилище:

4.1) На Frontend ноде (KVM-ADMIN) создаем Ceph пользователя для работы с OpenNebula хостами. В данном примере имя пользователя client.libvirt (само имя пользователя libvirt, префикс client указывает на пользователя в Ceph).

4.2) Создаем пользователя с полными правами rwx для пула TEST:

ceph auth get-or-create client.libvirt mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=TEST'

4.3) Генерируем ключи:

ceph auth get-key client.libvirt | tee client.libvirt.key
ceph auth get client.libvirt -o ceph.client.libvirt.keyring
[client.libvirt]
        key = AQB64QdXqZ5aFBAAH/00usPIZf35tZOt68N00g==

4.4) Теперь нам необходимо скопировать все файлы ключей на OpenNebula хосты.

  • ceph.client.libvirt.keyring должен быть размещен в директории /etc/ceph (на всех серверах в том числе и frontend).
  • client.libvirt.key может быть размещен в любом месте, где пользователь oneadmin имеет привилегии доступа и сможет создать секретные ключи libvirt.
for i in 2 3; do
    scp ceph.client.libvirt.keyring root@KVM$i:/etc/ceph
done
for i in 2 3; do
    scp client.libvirt.key oneadmin@KVM$i:/var/lib/one
done

4.5) Генериреум UUID конмадой uuidgen, полученное значение будет далее использоваться как $UUID.

[ceph@KVM-ADMIN ~]$ uuidgen
3c52b00c-f574-4c1c-af7f-2d4a483bf7b4

4.6) Создаем файл secret.xml

$UUID меняем на полученное значение из предыдущего пункта;

<secret ephemeral='no' private='no'>
  <uuid>$UUID</uuid>
  <usage type='ceph'>
          <name>client.libvirt secret</name>
  </usage>
</secret>

Копируем файл secret.xml между всеми KVM нодами OpenNebula.

4.7) Следующие команды должны быть выполнены на всех KVM нодах от пользователя oneadmin в директории с файлами secret.xml и client.libvirt.key.

Например: 

[oneadmin@KVM-2 ~]$ virsh -c qemu:///system secret-define secret.xml
Секрет 3c52b00c-f574-4c1c-af7f-2d4a483bf7b4 создан
[oneadmin@KVM-2 ~]$ virsh -c qemu:///system  secret-set-value --secret $UUID --base64 $(cat client.libvirt.key)
Значение установлено

Проверить установленные значения можно следующей командой: 

[oneadmin@KVM-2 ~]$ sudo virsh secret-list 
 UUID                                  Занято
--------------------------------------------------------------------------------
 3c52b00c-f574-4c1c-af7f-2d4a483bf7b4  ceph client.libvirt AQB64QdXqZ5aFBAAH/00usPIZf35tZOt68N00g==

В завершении добавляем Ceph хранилище в OpenNebula

cat << EOT > rbd.conf
NAME = "cephds"
DS_MAD = ceph
TM_MAD = ceph
DISK_TYPE = RBD
POOL_NAME = TEST
BRIDGE_LIST ="192.168.2.67 192.168.2.68 192.168.2.69"
CEPH_HOST ="192.168.2.67:6789 192.168.2.68:6789 192.168.2.69:6789"
CEPH_SECRET ="3c52b00c-f574-4c1c-af7f-2d4a483bf7b4"
CEPH_USER = libvirt
onedatastore create rbd.conf

Также можно добавить Ceph в качестве системного хранилища. 

NAME = "CephSystem"
TM_MAD = ceph
POOL_NAME = one
BRIDGE_LIST ="192.168.2.67 192.168.2.68 192.168.2.69"
CEPH_HOST ="192.168.2.67:6789 192.168.2.68:6789 192.168.2.69:6789"
CEPH_SECRET = "3c52b00c-f574-4c1c-af7f-2d4a483bf7b4"
CEPH_USER = libvirt
TYPE = SYSTEM_DS

Внимание! Данные действия будут работать только при условии активной cephx авторизации.

Драйвер Ceph работает нормально только с KVM.
По умолчанию используется формат RBD 2, пропишем данный параметр в конфигурационном файле ceph.conf 

[global]
rbd_default_format = 2

Обновим конфигурацию на всех серверах: 

ceph-deploy config push {host-name [host-name]...}

HA для виртуальных машин

Для настройки High Availability для виртуальных машин, следуем официальной документации OpenNebula

HOST_HOOK = [
    name      = "error",
    on        = "ERROR",
    command   = "ft/host_error.rb",
    arguments = "$ID -m -p 5",
    remote    = "no" ]

Аргументы:
-m - миграция виртуального сервера на другой хост. Только для хостов в одном хранилище.
-r - удаление и пересоздание виртуального сервера. Все данные будут утеряны.
-d - удаление виртуального сервера с хоста.
-p <n> - избегать повторного представления хоста, если хост возвращается в строй после N-циклов мониторинга.

В версии 5.2 добавлен функционал fencing.
Читать на docs.opennebula.org

Скопируем конфигурационный файл на другие ноды кластера: 

for i in 2 3; do
    scp /etc/one/oned.conf oneadmin@KVM$i:/etc/one/oned.conf
done

Troubleshooting

Если появляется ошибка вида:

Error copying image in the datastore: Error registering images/one-3

То исправляем её установкой или обновлением пакета ceph-devel.

Список испольуземых материалов:

# cluster, kvm, opennebula, virtualization
Полезные шаблоны конфигов и сниппеты для Nginx
Установка OpenvSwitch в CentOS 7

Комментарии

Подписаться

ссылки

недавние

теги

apache 3
archlinux 5
asterisk 2
backup 5
bareos 6
bind 1
centos 60
ceph 11
cisco 17
cluster 15
dns 5
elasticsearch 1
elementaryos 2
firewall 8
freebsd 1
gentoo 2
git 6
glusterfs 1
icinga 8
juniper 2
kibana 1
kvm 19
logstash 1
lsyncd 1
macos 4
monitoring 20
mysql 30
networks 40
nginx 23
observium 4
opennebula 14
openvswitch 4
postgresql 1
raid 11
redmine 1
security 43
troubleshooting 48
ubuntu 1
virtualization 40
vmware 18
vnc 2
vpn 6
vsan 1
vyos 6
windows 8
zabbix 2

недавние

теги

apache 3
archlinux 5
asterisk 2
backup 5
bareos 6
bind 1
centos 60
ceph 11
cisco 17
cluster 15
dns 5
elasticsearch 1
elementaryos 2
firewall 8
freebsd 1
gentoo 2
git 6
glusterfs 1
icinga 8
juniper 2
kibana 1
kvm 19
logstash 1
lsyncd 1
macos 4
monitoring 20
mysql 30
networks 40
nginx 23
observium 4
opennebula 14
openvswitch 4
postgresql 1
raid 11
redmine 1
security 43
troubleshooting 48
ubuntu 1
virtualization 40
vmware 18
vnc 2
vpn 6
vsan 1
vyos 6
windows 8
zabbix 2
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×