Linux Cluster в Azure

Материал из Xgu.ru

Перейти к: навигация, поиск

Linux Cluster в Azure — множество виртуальных машин, работающих под управлением операционной системы Linux, размещённые в облачной системе IaaS-типа Microsoft Azure, и сконфигурированные для совместного решения одной задачи.

На этой странице рассматривается каким образом организовать работу кластера отказоустойчивости (high availability cluster) в облаке, какие задачи прежде всего необходимо для этого решить. Подробно рассмотрена настройка отказоустойчивого хранилища на основе DRBD, а также кластерного программного обеспечения Corosync и Pacemaker, предназначенного для организации слаженной работы узлов кластера. Кроме этого, на примере библиотеки STONITH подробно рассмотрена настройка системы огораживания сбойных узлов (fencing).

Особое внимание уделяется настройке всех компонентов для работы в облачной инфраструктуре Azure, однако в большей части инструкции верны и для построения кластера в других облачных системах, а так же и в системе традиционной архитектуры, без использования облака.

Youtube-big.jpeg

Материалы этой страницы дополнены специально подготовленным видео. Для того чтобы лучше разобраться с представленными здесь материалами, обязательно его посмотрите. Суммарная длительность видео: ~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

STONITH

Чтобы узлы могли управлять облаком, необходимо:

  1. Установить azure cli tools на них;
  2. Подключить к утилитам учётную запись 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:

Установка модуля:

$ 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 выключающие противоложный узел. Аналогично поступает второй узел. В результате оба узла выключают или перезагружают друг друга. Если после перезагрузки проблема взаимной видимости узлов не решена, процесс повторяется опять.

В физических инсталляциях проблема решается обеспечением избыточных сетевых связей между узлами. Задублированными сетевыми подключениями, задублированными сетевыми устройствами, задублированными сетевыми картами и так далее. В облачной инфраструктуре остаётся полагаться на надёжность сетевых коммуникаций, которая в зависимости от требований решаемой задачи может быть достаточной или не достаточной. Во втором случае обязательно предусмотреть решение проблемы взаимного выключения узлов.

Простейшим решением может быть искусственная приоритезация узлов, и внесение таймаута в узел с пониженным приоритетом. В этом случае если оба узла решают одновременно убить друг друга, второй просто не успевает это сделать.

Другие способы решения проблемы, как и другие причины к проблеме приводящие, можно найти здесь:

Подробнее о модуле 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 Обзор возможных дальнейших направлений настройки

[править] Дополнительная информация