Linux Cluster в Azure
Материал из Xgu.ru
Linux Cluster в Azure — множество виртуальных машин, работающих под управлением операционной системы Linux, размещённые в облачной системе IaaS-типа Microsoft Azure, и сконфигурированные для совместного решения одной задачи.
На этой странице рассматривается каким образом организовать работу кластера отказоустойчивости (high availability cluster) в облаке, какие задачи прежде всего необходимо для этого решить. Подробно рассмотрена настройка отказоустойчивого хранилища на основе DRBD, а также кластерного программного обеспечения Corosync и Pacemaker, предназначенного для организации слаженной работы узлов кластера. Кроме этого, на примере библиотеки STONITH подробно рассмотрена настройка системы огораживания сбойных узлов (fencing).
Особое внимание уделяется настройке всех компонентов для работы в облачной инфраструктуре Azure, однако в большей части инструкции верны и для построения кластера в других облачных системах, а так же и в системе традиционной архитектуры, без использования облака.
|
|
Материалы этой страницы дополнены специально подготовленным видео. Для того чтобы лучше разобраться с представленными здесь материалами, обязательно его посмотрите. Суммарная длительность видео: ~4 часа. |
[править] Запуск машин
Образ, который мы будем использовать:
IMG=b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-14_10-amd64-server-20150202-en-us-30GB
Создать виртуальную сеть для кластера:
azure network vnet create vnet1 -e 10.0.0.0 -l 'West Europe'
Создать виртуальные машины:
azure vm create -l 'West Europe' --ssh 22 -A availability-set -w vnet1 my-cluster-vm-1 $IMG azureuser 'R00tp@$$' azure vm create -l 'West Europe' --ssh 22 -A availability-set -w vnet1 my-cluster-vm-2 $IMG azureuser 'R00tp@$$'
В данном случае машины доступные снаружи под разными именами. Мы можем дать единое имя всему кластеру, тогда машины должны быть доступны на разных портах.
azure vm create -l 'West Europe' --ssh 22 -w vnet1 -n my-cluster-vm-1 my-first-cluster $IMG azureuser 'R00tp@$$' azure vm create -l 'West Europe' --ssh 23 -w vnet1 -n my-cluster-vm-2 -c my-first-cluster $IMG azureuser 'R00tp@$$'
После того как машины запустятся, можно приступать к настройке. Адреса, полученные машинами:
$ azure vm list info: Executing command vm list + Getting virtual machines data: Name Status Location DNS Name IP Address data: --------------- ---------------- ------------ ------------------------------ ------------ data: my-cluster-vm-1 ReadyRole West Europe my-first-cluster.cloudapp.net 10.32.0.4 data: my-cluster-vm-2 RoleStateUnknown West Europe my-first-cluster.cloudapp.net 10.32.0.5
[править] Инсталляция ключей
Определяем адреса машин (azure vm list), после этого инсталлируем на них SSH-ключи.
На одной из машин (в данном случае на первой машине, 10.32.0.4):
ssh-keygen -t dsa ssh-copy-id -i ~/.ssh/id_dsa.pub 10.32.0.5 ssh-copy-id -i ~/.ssh/id_dsa.pub 10.32.0.4 scp ~/.ssh/id_dsa 10.32.0.5:~/.ssh/
[править] Инсталляция необходимых программ на узлах кластера
sudo apt-get install corosync pacemaker drbd8-utils
[править] Подготовка отказоустойчивого хранилища
Вне узла:
azure vm disk attach-new my-cluster-vm-1 10
На узле:
$ sudo fdisk /dev/sdc
Welcome to fdisk (util-linux 2.25.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x2810cb0c.
Command (m for help): o
Created a new DOS disklabel with disk identifier 0xaeafd4f0.
Command (m for help): n
Partition type
p primary (0 primary, 0 extended, 4 free)
e extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-20971519, default 2048):
Last sector, +sectors or +size{K,M,G,T,P} (2048-20971519, default 20971519):
Created a new partition 1 of type 'Linux' and of size 10 GiB.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Аналогично для второй машины.
Вне узла:
azure vm disk attach-new my-cluster-vm-2 10
На узле:
sudo fdisk /dev/sdc
На обоих узлах создаём конфигурационные файлы ресурса DRBD.
Файл /etc/drbd.d/r0.res:
resource r0 {
on my-cluster-vm-1 {
device /dev/drbd1;
disk /dev/sdc1;
address 10.32.0.4:7789;
meta-disk internal;
}
on my-cluster-vm-2 {
device /dev/drbd1;
disk /dev/sdc1;
address 10.32.0.5:7789;
meta-disk internal;
}
}
Файл должен быть на обеих машинах.
После этого можно приступать к запуску DRBD.
На обоих узлах одновременно:
sudo /etc/init.d/drbd start
На первом узле:
sudo drbdadm create-md r0 sudo drbdadm attach r0 <pre> sudo drbdadm create-md r0 sudo drbdadm attach r0
На первой машине опять:
sudo drbdadm primary --force r0
Синхронизация началась:
$ cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
srcversion: 69A5E1D3708F09A9D055736
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:10520 nr:0 dw:0 dr:11432 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:10473860
[>....................] sync'ed: 0.2% (10228/10236)Mfinish: 1:20:49 speed: 2,104 (2,104) K/sec
[править] Инсталляция и настройка MySQL-сервера
Готовим файловую систему, на которой будут находиться данные MySQL-сервера. Файловая система будет размешена на нашем отказоустойчивом хранилище.
На первом узле это можно сделать так: отформатировать DRBD-устройство и примонтировать его в /var/lib/mysql. После этого установить MySQL-сервер. Его данные будут записаны в каталог /var/lib/mysql.
sudo mkfs.ext3 /dev/drbd1 sudo mkdir /var/lib/mysql sudo mount /dev/drbd1 /var/lib/mysql
Инсталлируем сервер:
sudo apt-get install mysql-server sudo update-rc.d mysql disable
На втором узле нужно или проинсталлировать mysql-сервер, а потом стереть его файлы данных, или подмонтировать временно другой каталог в /var/lib/mysql, а потом отмонитировать его. Настоящие данные уже находятся на DRBD-устройстве.
sudo mkdir /tmp/mysql sudo mount --bind /tmp/mysql /var/lib/mysql sudo apt-get install mysql-server sudo /etc/init.d/mysql stop sudo update-rc.d mysql disable
[править] Настройка кластерного программного обеспечения
Конфигурационный файл corosync /etc/corosync/corosync.conf
totem {
version: 2
crypto_cipher: none
crypto_hash: none
interface {
ringnumber: 0
bindnetaddr: 10.32.0.0
mcastport: 5405
ttl: 1
}
transport: udpu
}
logging {
fileline: off
to_logfile: yes
to_syslog: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
nodelist {
node {
ring0_addr: 10.32.0.4
nodeid: 1
}
node {
ring0_addr: 10.32.0.5
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
}
Файл должен находиться на обоих узлах.
После того как конфигурационный файл создан, можно запускать corosync. Чтобы после перезагрузки corosync запускался, нужно разрешить запуск в файле /etc/default/corosync:
sudo vim /etc/default/corosync
Запустить corosync:
sudo /etc/init.d/corosync start
Проверить, что узлы видят друг друга:
my-cluster-vm-2:~$ sudo corosync-quorumtool -l
Membership information
----------------------
Nodeid Votes Name
1 1 10.32.0.4
2 1 10.32.0.5 (local)
[править] Настройка Pacemaker
Запускаем Pacemaker (на обоих узлах):
$ sudo /etc/init.d/pacemaker start
Просматриваем текущую конфигурацию Pacemaker'а:
$ sudo crm configure show
node $id="1" my-cluster-vm-1
node $id="2" my-cluster-vm-2
property $id="cib-bootstrap-options" \
dc-version="1.1.10-42f2063" \
cluster-infrastructure="corosync"
Войти в режиме настройки crm:
sudo crm configure
В режиме настройки:
primitive res_drbd_r0 ocf:linbit:drbd params drbd_resource="r0" primitive res_fs ocf:heartbeat:Filesystem params device="/dev/drbd1" directory="/var/lib/mysql" fstype="ext3" ms ms_drbd_r0 res_drbd_r0 meta notify="true" master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" colocation c_r0_on_drbd inf: res_fs ms_drbd_r0:Master order o_drbd_before_nfs inf: ms_drbd_r0:promote res_fs:start property stonith-enabled=false property no-quorum-policy=ignore
Применить изменения в конфигурации:
commit
В данный момент crm управляет DRBD-устройством и файловой системой, работающий поверх него. Для управление MySQL-сервером необходимо создать соответствующий примитив и объединить его в группу с файловой системой:
(в режиме crm configure) primitive mysqld ocf:heartbeat:mysql group mysql res_fs mysqld
Сделанные изменения нужно применить командой commit.
Полезные команды:
- crm resource cleanup res_fs — очистить состояние ресурса res_fs;
- crm resource list — просмотреть список доступных ресурсов;
- crm node list — просмотреть список доступных узлов;
- crm node standby — перевести узел в состояние standby;
- crm node online — перевести узел в активное состояние.
[править] Настройка endpoint
Привязать MySQL к 0.0.0.0 в файле /etc/mysql/my.cnf:
[mysqld] bind-address = 0.0.0.0
Разрешение подключаться удалённо (лучше не под root'ом, здесь это только для демонстрации):
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'r00tp@$$' WITH GRANT OPTION;
Создать endpoint'ы:
$ azure vm endpoint create-multiple my-cluster-vm-1 3306:3306:tcp:false:MySQL:tcp:3306 $ azure vm endpoint create-multiple my-cluster-vm-2 3306:3306:tcp:false:MySQL:tcp:3306
Список endpoint'ов:
$ azure vm endpoint list my-cluster-vm-1 info: Executing command vm endpoint list + Getting virtual machines data: Name Protocol Public Port Private Port Virtual IP EnableDirectServerReturn Load Balanced data: ----- -------- ----------- ------------ -------------- ------------------------ ------------- data: MySQL tcp 3306 3306 191.233.84.226 false Yes data: ssh tcp 22 22 191.233.84.226 false No info: vm endpoint list command OK
[править] Настройка STONITH
Чтобы узлы могли управлять облаком, необходимо:
- Установить azure cli tools на них;
- Подключить к утилитам учётную запись Azure, от имени которой будет осуществляться управление.
Установить инструменты командной строки Azure:
$ sudo apt-get install npm $ sudo npm install -g azure-cli
Привязываем учётную запись (копируем привязку с текущего хоста на узел Azure):
$ rsync -a /home/igor/.azure/ azureuser@my-first-cluster0.cloudapp.net:~/.azure/
На узле, переносим данные на второй хост:
rsync -a .azure/ my-cluster-vm-2:~/.azure/
Используем STONITH-модуль для Azure:
- bureado/aztonith/azure-vm (англ.)
Установка модуля:
$ wget https://raw.githubusercontent.com/bureado/aztonith/master/azure-vm $ sudo mv azure-vm /usr/lib/stonith/plugins/external/ $ sudo chmod 700 /usr/lib/stonith/plugins/external/azure-vm
Проверка доступности модуля:
$ sudo stonith -L | grep azure external/azure-vm
Настройка модуля stonith в crm.
Просмотреть список конфигурационных параметров модуля:
$ sudo stonith -t external/azure-vm -n hostlist
Эти параметры будут переданы при конфигурировании stonith в crm.
Изнутри crm:
# ra info stonith:external/azure-vm
Теперь переносим
primitive st-azure stonith:external/azure \ params hostlist="my-cluster-vm1 my-cluster-vm2" \ clone fencing st-azure \ property stonith-enabled=true \ commit
Если всё успешно, в выводе crm_mon появится новая секция:
Clone Set: fencing [st-azure]
Started: [ my-cluster-vm-1 ]
Stopped: [ my-cluster-vm-2 ]
При настройке STONITH главное избежать ситуации, когда между узлами начинается рубилово не на жизнь, а на смерть. Такое может легко произойти, например, в ситуации, когда узлы перестали видеть друг друга, но видят внешнюю точку, через которую работает STONITH. В этом случае оба узла решают, что противоположный узел не работает и его надо добить (на самом деле, всё работает, просто узлы не видят друг друга), он инициирует механизмы STONITH выключающие противоложный узел. Аналогично поступает второй узел. В результате оба узла выключают или перезагружают друг друга. Если после перезагрузки проблема взаимной видимости узлов не решена, процесс повторяется опять.
В физических инсталляциях проблема решается обеспечением избыточных сетевых связей между узлами. Задублированными сетевыми подключениями, задублированными сетевыми устройствами, задублированными сетевыми картами и так далее. В облачной инфраструктуре остаётся полагаться на надёжность сетевых коммуникаций, которая в зависимости от требований решаемой задачи может быть достаточной или не достаточной. Во втором случае обязательно предусмотреть решение проблемы взаимного выключения узлов.
Простейшим решением может быть искусственная приоритезация узлов, и внесение таймаута в узел с пониженным приоритетом. В этом случае если оба узла решают одновременно убить друг друга, второй просто не успевает это сделать.
Другие способы решения проблемы, как и другие причины к проблеме приводящие, можно найти здесь:
- STONITH Deathmatch Explained (англ.)
Подробнее о модуле fencing'а в CRM:
Проверка:
на одном из узлов делаем:
$ sudo ifconfig eth0 down
На втором в логах corosync:
Apr 06 13:39:08 [44708] my-cluster-vm-1 stonith-ng: info: internal_stonith_action_execute: Attempt 2 to execute fence_legacy (reboot). remaining timeout is 23 Apr 06 13:39:10 [44707] my-cluster-vm-1 cib: info: crm_client_new: Connecting 0x7ff318c75660 for uid=0 gid=0 pid=45797 id=26c4a7bc-ddbf-48b0-8f57-166b61ec783d Apr 06 13:39:10 [44707] my-cluster-vm-1 cib: info: cib_process_request: Completed cib_query operation for section 'all': OK (rc=0, origin=local/crm_mon/2, version=0.34.6) Apr 06 13:39:10 [44707] my-cluster-vm-1 cib: info: crm_client_destroy: Destroying 0 events Apr 06 13:39:11 my-cluster-vm-1 stonith: [45780]: info: external_run_cmd: '/usr/lib/stonith/plugins/external/azure-vm reset my-cluster-vm-2' output: info: Executing command vm restart
[править] Видео
[править] Теория, первая часть: типы кластеров, кластер балансировки нагрузки
Ключевые точки:
- 00:00 Типы кластеров
- 06:30 Кластер балансировки нагрузки (load balancing)
- 11:07 Кластер отказоустойчивости (high availability)
- 14:40 Вычислительный кластер (HPC)
- 18:20 Кластер балансировки нагрузки в деталях
- 19:00 Уровни балансировки нагрузки
- 22:22 Балансировка на уровне 3/4
- 24:30 Балансировка на уровне 7
- 27:24 Балансировка с помощью DNS
[править] Теория, вторая часть: отказоустойчивый и вычислительный кластеры
Подробнее об устройстве кластера отказоустойчивости и вычислительного кластера.
Ключевые точки:
- 00:00 Кластер отказоустойчивости
- 01:50 Элементы двухузлового кластера отказоустойчивости
- 05:45 Heartbeat
- 06:20 Cluster Resource Manager
- 07:48 STONITH
- 10:30 Переключение мастера
- 11:30 Отказоустойчивое хранилище
- 18:48 Вычислительный кластер
- 23:10 IO-Bound и CPU-Bound вычислительные кластеры
- 23:56 MapReduce-кластеры
- 26:50 Обзор задачи построения кластера отказоустойчивости
[править] Практика, первая часть: Настройка кластера отказоустойчивости в облаке
Создание кластера отказоустойчивости в IaaS-облаке. Отказоустойчивое хранилище DRBD. Прикладное программное обеспечение: MySQL-сервер.
Ключевые точки:
- 00:00 Обзор архитектуры кластера
- 08:50 Выбор образа для машин кластера
- 11:30 Создание виртуальной сети и множества отказоустойчивости (availablity set)
- 15:30 Запуск машин кластера
- 28:00 Инсталляция и установка SSH-ключей внутри кластера
- 30:30 Создание внешнего диска для будущего отказоустойчивого устройства
- 35:30 Инсталляция и настройка DRBD
- 45:38 Создание файловой системы на отказоустойчивом хранилище
- 47:00 Инсталляция СУБД MySQL с использованием отказоустойчивого хранилища
- 53:25 Инсталляция систем Corosync и Pacemaker
- 59:00 Проверка работы Corosync
- 59:45 Настройка Pacemaker с помощью crm
- 1:10:00 Проверка правильности настройки Pacemaker'а
- 1:18:10 Обзор следующих шагов
[править] Практика, вторая часть: Настройка доступа к кластеру снаружи облака, настройка STONITH
Продолжение настройки кластера отказоустойчивости в IaaS-облаке.
Шаги:
- Проврека работоспособности кластера в различных режимах;
- Настройка множественного endpoint;
- Настройка STONITH и проверка правильности его работы.
Ключевые точки:
- 00:00 Краткий обзор существующей инсталляции
- 01:00 Обзор следующих шагов
- 05:35 Проверка работоспособности кластера в различных режимах
- 15:30 Настройка доступа к службе снаружи
- 21:30 Создание endoint'ов для доступа к службе
- 27:20 Проверка доступности службы с помощью hping
- 30:30 Эксперимент с кластером при доступе через endpoint
- 37:15 Настройка fencing'а с помощью STONITH
- 38:30 Настройка azure tools для использования со STONITH
- 45:35 Настройка Pacemaker для использования Azure tools
- 59:20 Обсуждение проблемы одновременного взаимного выключения узлов
- 1:04:23 Проверка правильности настройки STONITH
- 1:08:00 Обзор сделанных шагов
- 1:09:30 Обзор возможных дальнейших направлений настройки
