1. Другая сторона
виртуализации
Sergey Vasilenko

2. Готовимся к переезду в облако
Возьмем проект
Visitor
WEB-frontend
business logic
database
Три сервера8
Задача — перенести в облако, для:8
• увеличения масштабируемости8
• уменьшения времени простоя при обслуживании8
• повышения отказоустойчивости8
• оптимизации расходов на содержание проекта8
8
Напрашивается решение — начать с трех VM в облаке.

3. Готовимся к переезду в облако
WEB-frontend
ext.IP
business logic
database
int.IP-addr
int.IP-addr
Business logic.
software
Database
int.IP
HTTP-server
Для нормальной работы нашим серверам надо:8
• сетевая связанность (IP адреса, внутренняя сеть, канал в Internet)8
• Среда исполнения основной задачи8
8
>> Мы что-то забыли???

4. Готовимся к переезду в облако
WEB-frontend
business logic
database
int.IP-addr
int.IP-addr
HTTP-server
Business logic.
software
Database
storage
storage
storage
ext.IP
int.IP
Да! Мы забыли дисковую подсистему. 8
8
8
Плохая идея:8
• использовать дисковые разделы виртуальных машин в облаке8
8
Хорошая идея:8
• воспользоваться сетевым облачным хранилищем

5. Переезд в облако
WEB-frontend
business logic
database
int.IP-addr
int.IP-addr
net.storage+FS
net.storage+FS
net.storage+FS
HTTP-server
Business logic.
software
Database
ext.IP
int.IP

6. Переезд в облако
Что еще мы можем получить от облака:8
• мониторинг состояния VM8
• регулярные бэккапы8
• балансировку входящего траффика8
• защиту от DDOS атак8

7. Переезд в облако
Что еще мы можем получить от облака:8
• мониторинг состояния VM8
• регулярные бэккапы8
• балансировку входящего траффика8
• защиту от DDOS8
8
Чего нам облако не даст:8
• резервирования всего того, что крутится внутри
наших VM

8. Велосипед давно
изобретен!
Примерно с 2004 года при активном участии компаний
RedHat и Linbit разрабатывается кластерный ресурсменеджер с открытым кодом.
8
Для решения нашей задачи мы можем
использовать связку
Pacemaker / Corosync

9. Resource-manager
Отвечает за своевременный запуск/остановку:8
• в нужной последовательности8
• с соблюдением зависимостей между ресурсами8
• распределяя нагрузку между нодами кластера8
8
Обеспечивает отказоустойчивость:8
• мониторя запущенные ресурсы8
• контролируя состояния нод8
• отслеживая кворум8
8
Облегчает масштабирование:8
• обеспечивая работу групповых ресурсов8
• реализуя событийную модель

10. Corosync
Нижний уровень комуникаций в кластере:8
L
Отслеживает состояния нод кластера, принимает
решение о наличии или отсутствии кворума (v2)8
L
Обеспечивает синхронизацию состояний ресурсов
кластера8
L
Предоставляет транспортный уровень для сервисных
служб более высокого уровня8
8
Имеет три режима работы с сетью: Multicast, Broadcast,
Unicast (c перечислением нод кластера в конфиге). 8
/etc/corosync/corosync.conf8
/etc/corosync/service.d/*

11. Corosync. Транспорт.
L
L
L
Unicast: все узлы перечислены в конфиге, сообщения
передаются от узла к узлу. Все просто, железобетонно.
Добавлять и удалять ноды в кластере — неудобно.
Broadcast: более удобный способ. Ноды кластера в
конфигах не перечисляются, добавляются автоматически. Авторизация — по ключу. Однако этот
способ работает только в случае, если все ноды
находятся в одном широковещательном ethernetдомене. Если единого L2 сегмента сети нет – этот метод
неприемлим.
Multicast: тоже удобен. Единый сегмент сети не нужен.
Однако коммутаторы должны правильно пропускать
мультикаст-траффик.

12. Pacemaker
L
Контролирует состояние ресурсов
L
Распределяет ресурсы по нодам кластера
L
Помогает производить выборы для master/slave ресурсов
L
Отслеживает кворум
L
Экстренно выключает ресурсы
8
Работает поверх Corosync.
Собственных конфигурационных файлов не имеет.
Конфигурируется через утилиты командной
строки с любого узла кластера.
Практически мгновенно синхронизирует свою
конфигурацию между узлами.

13. Пакеты и утилиты
L
Corosync 1.xx (1.4.6)
L
Pacemaker (1.1.10)
L
PCS (замена устаревшему crmsh)

14. В кластере
Ресурсы (все что исполняется на кластере):
L Имеют состояние (started, stopped, master...)
L Могут быть сгруппированы
L Могут зависеть один от другого
L Могут быть привязаны к каким-то определенным узлам кластера
L Могут иметь атрибуты
8
Ноды (узлы кластера):
L Могут иметь атрибуты
L Могут иметь состояние
8
Кворум
L Может присутствовать или отсутствовать.

15. OCF-скрипты
Ресурсы могут управляться:
L Upstart
L Systemd
L Service
L LSB
L OCF – родное средство Pacemaker
/usr/lib/ocf/resource.d/*

16. Ресурсы
Обычный ресурс
L
существует в одном экземпляре
L
на одной из нод кластера
L
в процессе жизнедеятельности может мигрировать на
другие ноды

17. Атрибуты ресурса
L
L
Обычные атрибуты
это параметры с которыми ресурс был создан. В
принципе на ресурс можно повесить любой атрибут, но
создать ресурс с атрибутом, который не упомянут в его
Metadata Pacemaker не даст.
Meta-атрибуты (служебные)
это атрибуты, которые имеют значение для Pacemaker’a,
но бессмысленны для самого ресурса. Они управляют
поведением.
Например с мета-атрибутом target-role=”Stopped” ресурс
будет создан, но не запустится автоматически.

18. Ресурс обыкновенный
Создается так:
#pcs resource create ClusterIP ocf:heartbeat:IPaddr2
ip=192.168.0.120 cidr_netmask=32
nic=eth0 mac=AA:BB:CC:00:11:22
op monitor interval=5s
#pcs status
#pcs resource show ClusterIP

19. Ресурсы. Clone.
L
Обычный ресурс
L
Clone
8
ресурс, который существует в нескольких экземплярах,
по одному на ноду.
8
8
Наиболее частый случай применения – существовать
везде.

20. Ресурсы. Clone.
#pcs resource create httpd ocf:heartbeat:nginx
configfile=/etc/nginx.conf port=80
meta target-role=”Stopped”
op monitor interval=10s
#pcs resource clone httpd
notify=true
ordered=true
clone-max=2
#pcs resource enable httpd
8
#pcs status
#pcs resource show httpd
#pcs resource show httpd-clone

21. Ресурсы. Master/slave.
L
Обычный ресурс
L
Clone
L
Master/slave
8
Специальный вид Клона, в котором один из ресурсов
назначается старшим.
Старшинство определяется выборами. Любой экземпляр
ресурса может выдвинуть свою кандидатуру. Но утверждает ее и назначает старшего – Pacemaker.

22. Ресурсы. Master/slave.
Создается так:
#pcs resource create httpd ocf:heartbeat:nginx
configfile=/etc/nginx.conf port=80
meta target-role=”Stopped”
op monitor interval=10s
op monitor interval=7s role=”Master”
#pcs resource master httpd
notify=true
master-max=1
master-node-max=1
#pcs resource enable httpd
8
#pcs status

23. Мина замедленного действия
#pcs resource create ntpd lsb:ntpd
meta target-role='Stopped'
op monitor interval='60'
#pcs resource clone ntpd
#pcs resource enable ntpd
8
8
!!! НЕ КЛОНИРУЙТЕ СИСТЕМНЫЙ SSH !!!

24. OCF — а что внутри?
Операции
L
L
L
L
L
L
L
L
L
L
meta-data
start
stop
monitor
notify
promote
demote
migrate_to
migrate_from
reload
Коды возврата
L
L
L
8
L
L
8
L
L
L
L
8
L
0: OCF_SUCCESS
7: OCF_NOT_RUNNING
8: OCF_RUNNING_MASTER
1: OCF_ERR_GENERIC
9: OCF_FAILED_MASTER
2:
3:
4:
5:
OCF_ERR_ARGS
OCF_ERR_UNIMPLEMENTED
OCF_ERR_PERM
OCF_ERR_INSTALLED
6: OCF_ERR_CONFIGURED
/usr/lib/ocf/resource.d/*

25. OCF: start/stop
Вызванный с этими аргументами ocf-скрипт должен
правильно стартовать/останавливать ресурс.
8
Например процесс остановки должен не только гасить
ресурс, но и проверять успешно ли прошло гашение.
Ждать если надо, и снова проверять. Если ничего не
помогает kill -TERM, или даже kill -KILL.

26. OCF: monitor
C этим аргументом ocf-скрипт регулярно вызывается для
проверки состояния ресурса. Случаи бывают разными. В
одном случае стоит всего лишь проверить, что процесс с
PIDом из PID-файла действительно запущен, в другом
имеет смысл убедиться, что процесс реально работает, а
не просто завис и занимает место в памяти.
У одного ресурса может быть несколько мониторов,
запускающихся через разные промежутки времени,
выполняющие различные действия. (depth=NN)

27. OCF: meta-data
Эту особую операцию Pacemaker применяет перед
стартом ресурса. Он расчитывает получить в ответ XML
с описанием
какие атрибуты есть у ресурса, какие
обязательны, какие операции к нему можно применять и
как часто нужно его мониторить. Частоту можно
переопределить при создании ресурса.
8
Ответ строго стардартизирован, примеры можно
посмотреть запустив OCF-скрипт руками
с этим
параметром:
8
#OCF_ROOT=/usr/lib/ocf OCF_RESOURCE_INSTANCE=test-1
/usr/lib/ocf/resource.d/xxx/test meta-data

28. Теория закончилась
Портативная лаборатория быстрого
развертывания
http://bit.ly/1fejrJS

29. Взаимодействие ресурсов
IP address
IP address
FS
FS
httpd
блочное устройство
запрашивается
изнутри VM
httpd
блочное устройство
запрашивается
через cloud-API, и
подается в VM как
pluggable device

30. Взаимодействие ресурсов
Цепочка ресурсов
# pcs resource create IPADDR ocf:heartbeat:Ipaddr2
ip=10.0.0.201 nic=eth1
# pcs resource create FS ocf:heartbeat:Dummy
# pcs resource create HTTPD ocf:heartbeat:nginx
# pcs constraint colocation add FS with IPADDR
# pcs constraint colocation add HTTPD with FS
#
#
#
#
pcs
pcs
pcs
pcs
constraint
constraint
constraint
constraint
order
order
order
order
start IPADDR then start FS
start FS then start HTTPD
stop HTTPD then stop FS
stop FS then stop IPADDR
8
# pcs status
# pcs resource enable/disable/move

31. Взаимодействие ресурсов
Множественная зависимость
# pcs resource create IPADDR ocf:heartbeat:IPaddr2
ip=10.0.0.201 nic=eth1
# pcs resource create FS ocf:heartbeat:Dummy
# pcs resource create HTTPD ocf:heartbeat:nginx
# pcs constraint colocation add HTTPD with IPADDR
# pcs constraint colocation add HTTPD with FS
# pcs constraint colocation add IPADDR with FS
#
#
#
#
pcs
pcs
pcs
pcs
constraint
constraint
constraint
constraint
order
order
order
order
start IPADDR then start HTTPD
start FS then start HTTPD
stop HTTPD then stop FS
stop HTTPD then stop IPADDR
8
# pcs resource delete XXX

32. Утилиты диагностики
Для мониторинга и отладки у нас есть:
L
crm_mon
L
pcs status
L
pcs config
L
pcs cluster edit
L
А для начала неплохо бы проверить сетевую
связанность между узлами кластера и синхронизацию
времени.

33. Итого: ….
Pacemaker – не волшебная таблетка “сделать
все хорошо” – это этакий init на стеройдах,
способный к эффективной коллективной
работе.
… включая НДС

34. СПАСИБО!
8
L
Pacemaker:
http://clusterlabs.org/
L
Corosync:
http://corosync.github.io/corosync/
L
Лаба:
http://bit.ly/1fejrJS
8
8
8
svasilenko@mirantis.com
Skype: xenolog13