Как создать установку высокой доступности с помощью Corosync, Pacemaker и плавающих IP-адресов в Ubuntu 14.04

Вступление

Из этого туториала вы узнаете, как вы можете использовать Corosync и Pacemaker с плавающим IP для создания серверной инфраструктуры высокой доступности (HA) в DigitalOcean.

Corosync - это программа с открытым исходным кодом, которая предоставляет клиентским серверам возможности членства в кластере и обмена сообщениями, часто называемые слоем * messaging *. Pacemaker - это менеджер ресурсов кластера с открытым исходным кодом (CRM), система, которая координирует ресурсы и услуги, которыми управляет кластер и которые обеспечивают высокую доступность. По сути, Corosync позволяет серверам взаимодействовать как кластер, в то время как Pacemaker предоставляет возможность контролировать поведение кластера.

Goal

После завершения установка HA будет состоять из двух серверов Ubuntu 14.04 в активной / пассивной конфигурации. Это будет достигнуто путем указания плавающего IP-адреса, с помощью которого ваши пользователи будут получать доступ к вашей веб-службе, чтобы он указывал на основной (активный) сервер, если сбой не обнаружен. В случае, если Pacemaker обнаружит, что основной сервер недоступен, дополнительный (пассивный) сервер автоматически запустит сценарий, который переназначит плавающий IP самому себе через API DigitalOcean. Таким образом, последующий сетевой трафик с плавающим IP будет направляться на ваш вторичный сервер, который будет действовать как активный сервер и обрабатывать входящий трафик.

Эта диаграмма демонстрирует концепцию описанной установки:

изображение: https: //assets.digitalocean.com/articles/high_availability/ha-diagram-animated.gif [Активная / пассивная диаграмма]

Для достижения этой цели мы будем выполнять следующие шаги:

Создайте 2 капли, которые будут получать трафик
Создайте плавающий IP и назначьте его одной из капель
Установите и настройте Corosync
Установите и настройте Pacemaker
Настройка плавающего ресурса кластера переназначения IP
Тест на отказоустойчивость
Настройте ресурс кластера Nginx

Предпосылки

Чтобы автоматизировать переназначение плавающего IP, мы должны использовать API DigitalOcean. Это означает, что вам нужно сгенерировать персональный токен доступа (PAT), который является токеном API, который можно использовать для аутентификации в вашей учетной записи DigitalOcean, с доступом read и write, следуя https://www.digitalocean.com/community. / tutorials / how-to-use-the-digitalocean-api-v2 # how-to-generate-a-personal-access-token [Как сгенерировать личный токен доступа] в разделе учебника API. Ваш PAT будет использоваться в сценарии, который будет добавлен к обоим серверам в вашем кластере, поэтому обязательно держите его где-нибудь в безопасности, поскольку он предоставляет полный доступ к вашей учетной записи DigitalOcean для справки.

В дополнение к API в этом руководстве используются следующие функции DigitalOcean:

Пожалуйста, прочитайте связанные учебники, если вы хотите узнать о них больше.

Создать капли

Первым шагом является создание двух капель Ubuntu с включенной частной сетью в одном центре обработки данных, который будет действовать как основной и дополнительный серверы, описанные выше. В нашем примере настройки мы назовем их «основной» и «вторичный» для удобства. Мы установим Nginx на обе капли и заменим их индексные страницы информацией, которая однозначно их идентифицирует. Это позволит нам простой способ продемонстрировать, что установка HA работает. Для реальной установки на ваших серверах должен работать веб-сервер или балансировщик нагрузки по вашему выбору, например Nginx или HAProxy.

Создайте две капли Ubuntu 14.04, * основной * и * дополнительный *. Если вы хотите следовать настройке примера, используйте этот скрипт bash в качестве пользовательских данных:

Пример пользовательских данных

#!/bin/bash

apt-get -y update
apt-get -y install nginx
export HOSTNAME=$(curl -s http://169.254.169.254/metadata/v1/hostname)
export PUBLIC_IPV4=$(curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/ipv4/address)
echo Droplet: $HOSTNAME, IP Address: $PUBLIC_IPV4 > /usr/share/nginx/html/index.html

Эти пользовательские данные установят Nginx и заменят содержимое + index.html + на имя хоста и IP-адрес дроплета (путем ссылки на службу метаданных). Доступ к любой Droplet через ее общедоступный IP-адрес покажет основную веб-страницу с именем хоста и IP-адресом Droplet, которая будет полезна для проверки того, на что указывает Droplet с плавающим IP в любой момент.

Создать плавающий IP

На панели управления DigitalOcean нажмите * Сеть * в верхнем меню, затем * Плавающие IP-адреса * в боковом меню.

изображение: https: //assets.digitalocean.com/site/ControlPanel/fip_no_floating_ips.png [без плавающих IP-адресов]

Назначьте плавающий IP-адрес вашей * основной * капле, а затем нажмите кнопку * Назначить плавающий IP *.

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

http://

Вы должны увидеть страницу индекса вашей основной капли.

Настроить DNS (необязательно)

Если вы хотите иметь доступ к настройке HA через доменное имя, создайте запись * A * в DNS, которая указывает ваш домен на ваш плавающий IP-адрес. Если в вашем домене используются серверы имен DigitalOcean, выполните https://www.digitalocean.com/community/tutorials/how-to-set-up-a-host-name-with-digitalocean#step-three%E2%80%94configure. -your-domain [шаг третий] учебника Как настроить имя хоста с помощью DigitalOcean. Как только это распространяется, вы можете получить доступ к вашему активному серверу через доменное имя.

В качестве примера доменного имени мы будем использовать + example.com +. Если у вас нет доменного имени для использования прямо сейчас, вы будете использовать вместо этого плавающий IP-адрес для доступа к настройке.

Настроить синхронизацию времени

Всякий раз, когда у вас есть несколько серверов, взаимодействующих друг с другом, особенно с помощью программного обеспечения для кластеризации, важно обеспечить синхронизацию их часов. Мы будем использовать NTP (сетевой протокол времени) для синхронизации наших серверов.

На * обоих серверах * используйте эту команду, чтобы открыть селектор часового пояса:

sudo dpkg-reconfigure tzdata

Выберите нужный часовой пояс. Например, мы выберем + America / New_York +.

Затем обновите apt-get:

sudo apt-get update

Затем установите пакет + ntp + с помощью этой команды;

sudo apt-get -y install ntp

Часы вашего сервера теперь должны быть синхронизированы с использованием NTP. Чтобы узнать больше о NTP, ознакомьтесь с этим руководством: https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-ubuntu-14-04-servers#configure-timezones-and-network -time-protocol-synchronization [Настройка часовых поясов и синхронизации сетевого протокола времени].

Настроить брандмауэр

Corosync использует UDP-транспорт между портами + 5404 + и + 5406 +. Если вы используете брандмауэр, убедитесь, что связь между этими портами разрешена между серверами.

Например, если вы используете + iptables +, вы можете разрешить трафик на эти порты и + eth1 + (интерфейс частной сети) с помощью этих команд:

sudo iptables -A INPUT  -i eth1 -p udp -m multiport --dports 5404,5405,5406 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT  -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

Установите Corosync и Pacemaker

На * обоих серверах * установите Corosync и Pacemaker, используя apt-get:

sudo apt-get install pacemaker

Обратите внимание, что Corosync устанавливается как зависимость пакета Pacemaker.

Corosync и Pacemaker теперь установлены, но их необходимо настроить, прежде чем они сделают что-нибудь полезное.

Настроить Corosync

Corosync должен быть настроен так, чтобы наши серверы могли взаимодействовать как кластер.

Создать ключ авторизации кластера

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

На * основном * сервере установите пакет + hasged +:

sudo apt-get install haveged

Этот программный пакет позволяет нам легко увеличить количество энтропии на нашем сервере, что требуется для скрипта + corosync-keygen +.

На * основном * сервере запустите скрипт + corosync-keygen +:

sudo corosync-keygen

Это сгенерирует 128-байтовый ключ авторизации кластера и запишет его в + / etc / corosync / authkey +.

Теперь, когда нам больше не нужен пакет + hasged +, давайте удалим его с * основного * сервера:

sudo apt-get remove --purge haveged
sudo apt-get clean

На * основном * сервере скопируйте + authkey + на вторичный сервер:

sudo scp /etc/corosync/authkey @:/tmp

На * вторичном * сервере переместите файл + authkey + в нужное место и ограничьте его права доступа root:

sudo mv /tmp/authkey /etc/corosync
sudo chown root: /etc/corosync/authkey
sudo chmod 400 /etc/corosync/authkey

Теперь оба сервера должны иметь одинаковый ключ авторизации в файле + / etc / corosync / authkey +.

Настроить кластер Corosync

Чтобы запустить желаемый кластер, мы должны настроить эти

На * обоих серверах * откройте файл + corosync.conf + для редактирования в вашем любимом редакторе (мы будем использовать + vi +):

sudo vi /etc/corosync/corosync.conf

Вот файл конфигурации Corosync, который позволит вашим серверам взаимодействовать как кластер. Обязательно замените выделенные части соответствующими значениями. + bindnetaddr + должен быть установлен на частный IP-адрес сервера, на котором вы сейчас работаете. Два других выделенных элемента должны быть установлены на частный IP-адрес указанного сервера. За исключением + bindnetaddr +, файл должен быть одинаковым на обоих серверах.

Замените содержимое + corosync.conf + этой конфигурацией с изменениями, характерными для вашей среды:

/etc/corosync/corosync.conf

totem {
 version: 2
 cluster_name: lbcluster
 transport: udpu
 interface {
   ringnumber: 0
   bindnetaddr:
   broadcast: yes
   mcastport: 5405
 }
}

quorum {
 provider: corosync_votequorum
 two_node: 1
}

nodelist {
 node {
   ring0_addr:
   name: primary
   nodeid: 1
 }
 node {
   ring0_addr:
   name: secondary
   nodeid: 2
 }
}

logging {
 to_logfile: yes
 logfile: /var/log/corosync/corosync.log
 to_syslog: yes
 timestamp: on
}

Раздел * totem * (строки 1-11), который относится к протоколу Totem, который Corosync использует для членства в кластере, определяет, как члены кластера должны взаимодействовать друг с другом. В нашей настройке важными настройками являются + transport: udpu + (указывает режим одноадресной передачи) и + bindnetaddr + (указывает, к какому сетевому адресу должен быть привязан Corosync).

Раздел * quorum * (строки 13-16) указывает, что это кластер из двух узлов, поэтому для кворума требуется только один узел (+ two_node: 1 +). Это обходной путь того факта, что для достижения кворума требуется как минимум три узла в кластере. Этот параметр позволит нашему двухузловому кластеру выбрать координатор (DC), который является узлом, который управляет кластером в любой момент времени.

Раздел * nodelist * (строки 18-29) определяет каждый узел в кластере и способ доступа к каждому узлу. Здесь мы настраиваем как наши первичные, так и вторичные узлы и указываем, что с ними можно связаться через их соответствующие частные IP-адреса.

Раздел * logging * (строки 31-36) указывает, что журналы Corosync должны быть записаны в + / var / log / corosync / corosync.log +. Если у вас возникнут проблемы с остальной частью этого учебника, обязательно посмотрите здесь, пока вы устраняете неполадки.

Сохранить и выйти.

Далее нам нужно настроить Corosync для разрешения службы Pacemaker.

На * обоих серверах * создайте файл + pcmk + в каталоге службы Corosync с помощью редактора. Мы будем использовать + vi +:

sudo vi /etc/corosync/service.d/pcmk

Затем добавьте сервис Pacemaker:

service {
 name: pacemaker
 ver: 1
}

Сохранить и выйти. Это будет включено в конфигурацию Corosync и позволит Pacemaker использовать Corosync для связи с нашими серверами.

По умолчанию служба Corosync отключена. На * обоих серверах * измените это, отредактировав + / etc / default / corosync +:

sudo vi /etc/default/corosync

Измените значение + START + на + yes +:

/ И т.д. / по умолчанию / corosync

START=

Сохранить и выйти. Теперь мы можем запустить сервис Corosync.

На * обоих * серверах запустите Corosync с помощью этой команды:

sudo service corosync start

После запуска Corosync на обоих серверах они должны быть объединены в кластеры. Мы можем проверить это, выполнив эту команду:

sudo corosync-cmapctl | grep members

Выходные данные должны выглядеть примерно так, что означает, что основной (узел 1) и дополнительный (узел 2) присоединились к кластеру:

corosync-cmapctl output:runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip()
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip()
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined

Теперь, когда вы правильно настроили Corosync, давайте перейдем к настройке Pacemaker.

Запустите и настройте кардиостимулятор

Pacemaker, который зависит от возможностей обмена сообщениями в Corosync, теперь готов к запуску и настройке его основных свойств.

Включить и запустить кардиостимулятор

Служба Pacemaker требует, чтобы Corosync был запущен, поэтому он по умолчанию отключен.

На * обоих серверах включите Pacemaker для запуска системы при загрузке с помощью этой команды:

sudo update-rc.d pacemaker defaults 20 01

С помощью предыдущей команды мы установили приоритет запуска Pacemaker на «+ 20 ». Важно указать приоритет запуска, который выше, чем у Corosync (который по умолчанию равен « 19 +»), чтобы Pacemaker запускался после Corosync.

Теперь давайте запустим кардиостимулятор:

sudo service pacemaker start

Для взаимодействия с Pacemaker мы будем использовать утилиту + crm +.

Проверьте кардиостимулятор с помощью + crm +:

sudo crm status

Это должно вывести что-то вроде этого (если нет, подождите 30 секунд, затем повторите команду):

crm status:Last updated: Fri Oct 16 14:38:36 2015
Last change: Fri Oct 16 14:36:01 2015 via crmd on primary
Stack: corosync
Current DC: primary (1) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured


Online: [ primary secondary ]

Есть несколько вещей, которые нужно отметить об этом выводе. Во-первых, * Current DC * (назначенный координатор) должен быть установлен либо в + primary (1) +, либо в + primary (2) +. Во-вторых, должно быть настроено * 2 узла * и настроено * 0 ресурсов *. В-третьих, оба узла должны быть помечены как * онлайн *. Если они помечены как * офлайн *, попробуйте подождать 30 секунд и снова проверьте состояние, чтобы убедиться, что оно само себя исправляет.

С этого момента вы можете запустить интерактивный монитор CRM в другом окне SSH (подключенном к любому узлу кластера). Это даст вам в режиме реального времени обновления статуса каждого узла, и где каждый ресурс работает:

sudo crm_mon

Вывод этой команды выглядит идентично выводу + crm status +, за исключением того, что он работает непрерывно. Если вы хотите выйти, нажмите + Ctrl-C +.

Настроить свойства кластера

Теперь мы готовы настроить основные свойства Pacemaker. Обратите внимание, что все команды Pacemaker (+ crm +) можно запускать с любого сервера узлов, поскольку он автоматически синхронизирует все изменения, связанные с кластером, на всех узлах-членах.

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

sudo crm configure property stonith-enabled=false

Мы также хотим отключить сообщения, связанные с кворумом, в журналах:

sudo crm configure property no-quorum-policy=ignore

Опять же, этот параметр применяется только к 2-узловым кластерам.

Если вы хотите проверить свою конфигурацию Pacemaker, выполните эту команду:

sudo crm configure show

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

Создание агента ресурса переназначения плавающего IP

Теперь, когда Pacemaker запущен и настроен, нам нужно добавить ресурсы для управления им. Как упоминалось во введении, ресурсы - это сервисы, которые кластер отвечает за обеспечение высокой доступности. В Pacemaker добавление ресурса требует использования * агента ресурса *, который действует как интерфейс для службы, которой нужно управлять. Pacemaker поставляется с несколькими агентами ресурсов для общих служб и позволяет добавлять настраиваемые агенты ресурсов.

В нашей настройке мы хотим убедиться, что сервис, предоставляемый нашими веб-серверами, * primary * и * вторичными *, является высоко доступным в активной / пассивной настройке, что означает, что нам нужен способ гарантировать, что наш плавающий IP-адрес всегда указывает на сервер, который доступен. Чтобы включить это, нам нужно настроить * агент ресурса *, который может запускать каждый узел, чтобы определить, владеет ли он плавающим IP-адресом, и, при необходимости, запустить скрипт, чтобы указать плавающий IP-адрес самому себе. Мы будем называть агента ресурса «FloatIP OCF», а скрипт переназначения плавающего IP - «+ assign-ip ». Как только у нас будет установлен агент ресурса FloatIP OCF, мы можем определить сам ресурс, который мы будем называть ` FloatIP +`.

Скачать скрипт assign-ip

Как мы только что упомянули, нам нужен скрипт, который может переназначить, на какой Droplet указывает наш плавающий IP, в случае, если ресурс + FloatIP + необходимо переместить на другой узел. Для этой цели мы загрузим базовый скрипт Python, который назначает плавающий IP-адрес для данного идентификатора капли, используя API-интерфейс DigitalOcean.

На * обоих серверах * загрузите скрипт Python + assign-ip +:

sudo curl -L -o /usr/local/bin/assign-ip http://do.co/assign-ip

На обоих серверах сделайте его исполняемым:

sudo chmod +x /usr/local/bin/assign-ip

Использование сценария + assign-ip + требует следующих деталей:

* Плавающий IP: * Первый аргумент скрипта, Плавающий IP, который назначается
* Droplet ID: * Второй аргумент скрипта, Droplet ID, которому должен быть назначен плавающий IP
* DigitalOcean PAT (токен API): * Передается как переменная окружения + DO_TOKEN +, ваша запись / чтение DigitalOcean PAT

Не стесняйтесь просматривать содержимое сценария, прежде чем продолжить.

Итак, если вы хотите вручную запустить этот скрипт для переназначения плавающего IP, вы можете запустить его так: + DO_TOKEN = / usr / local / bin / assign-ip +. Однако этот сценарий будет вызываться из агента ресурса FloatIP OCF в случае, если ресурс «+ FloatIP +» необходимо переместить на другой узел.

Давайте установим Float IP Resource Agent дальше.

Загрузить FloatIP OCF Resource Agent

Pacemaker позволяет добавлять агенты ресурсов OCF, размещая их в определенном каталоге.

На * обоих серверах * создайте каталог поставщика ресурсов + digitalocean + с помощью этой команды:

sudo mkdir /usr/lib/ocf/resource.d/digitalocean

На * обоих серверах * загрузите агент ресурсов FloatIP OCF:

sudo curl -o /usr/lib/ocf/resource.d/digitalocean/floatip https://gist.githubusercontent.com/thisismitch/b4c91438e56bfe6b7bfb/raw/2dffe2ae52ba2df575baae46338c155adbaef678/floatip-ocf

На обоих серверах сделайте его исполняемым:

sudo chmod +x /usr/lib/ocf/resource.d/digitalocean/floatip

Не стесняйтесь просматривать содержимое агента ресурса, прежде чем продолжить. Это bash-скрипт, который при вызове с помощью команды + start + ищет идентификатор капли узла, который его вызывает (через метаданные), и назначает плавающий IP идентификатору капли. Кроме того, он отвечает на команды + status и` + monitor of`, возвращая, назначен ли вызывающей капле плавающий IP.

Требуются следующие параметры OCF:

* do_token: *: токен API DigitalOcean, используемый для переназначения плавающего IP, т.е. ваш токен личного доступа DigitalOcean
* Floating_ip: *: ваш Плавающий IP (адрес), в случае, если он должен быть переназначен

Теперь мы можем использовать агент ресурса FloatIP OCF для определения нашего ресурса + FloatIP +.

Добавить ресурс FloatIP

С нашим установленным агентом ресурса FloatIP OCF мы можем теперь настроить наш ресурс + FloatIP +.

На любом сервере создайте ресурс + FloatIP + с помощью этой команды (обязательно укажите два выделенных параметра с вашей собственной информацией):

sudo crm configure primitive FloatIP ocf:digitalocean:floatip \
 params do_token= \
 floating_ip=

Это создает примитивный ресурс, который является универсальным типом кластерного ресурса, называемого «FloatIP», с использованием агента ресурса OCF FloatIP, который мы создали ранее (+ ocf: digitalocean: floatip +). Обратите внимание, что он требует, чтобы + do_token + и + Floating_ip + были переданы в качестве параметров. Они будут использоваться, если необходимо переназначить Плавающий IP.

Если вы проверите состояние вашего кластера (+ sudo crm status + или + sudo crm_mon +), вы должны увидеть, что ресурс + FloatIP + определен и запущен на одном из ваших узлов:

crm_mon:...
2 Nodes configured
1 Resource configured

Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started

Предполагая, что все настроено правильно, теперь у вас должна быть активная / пассивная установка HA! В текущем состоянии плавающий IP будет переназначен на онлайн-сервер, если узел, на котором запущен «+ FloatIP », переходит в автономный режим или в режим « standby ». Прямо сейчас, если активный узел - * primary *, в нашем примере output - становится недоступным, кластер проинструктирует * вторичный * узел запустить ресурс ` FloatIP +` и потребовать для себя плавающий IP-адрес. После переназначения плавающий IP направит пользователей на новый активный * вторичный * сервер.

В настоящее время аварийное переключение (переназначение плавающего IP-адреса) запускается только в том случае, если активный хост отключается или не может связаться с кластером. В лучшей версии этой настройки будут указаны дополнительные ресурсы, которыми должен управлять Pacemaker. Это позволит кластеру обнаруживать сбои определенных служб, таких как балансировщик нагрузки или программное обеспечение веб-сервера. Однако прежде чем настраивать это, мы должны убедиться, что базовое переключение работает.

Тест высокой доступности

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

В настоящее время плавающий IP-адрес назначен одному из ваших узлов (предположим, * primary *). Доступ к плавающему IP-адресу сейчас через IP-адрес или имя домена, на которое он указывает, просто покажет страницу индекса * основного * сервера. Если вы использовали пример сценария пользовательских данных, он будет выглядеть примерно так:

Floating IP is pointing to primary server:Droplet: , IP Address:

Это указывает на то, что плавающий IP фактически назначен основной капле.

Теперь давайте откроем новый локальный терминал и используем + curl + для доступа к плавающему IP по 1-секундному циклу. Используйте эту команду для этого, но не забудьте заменить URL-адрес своим доменом или плавающим IP-адресом:

while true; do curl ; sleep 1; done

В настоящее время будет выведено то же имя капли и IP-адрес основного сервера. Если мы вызовем сбой основного сервера, отключив его или изменив состояние кластера основного узла на «+ standby +», мы увидим, переназначается ли плавающий IP вторичному серверу.

Давайте перезагрузим * основной * сервер сейчас. Сделайте это через панель управления DigitalOcean или запустив эту команду на основном сервере:

sudo reboot

Через несколько секунд основной сервер должен стать недоступным. Обратите внимание на вывод цикла + curl +, который работает в терминале. Вы должны заметить вывод, который выглядит так:

curl loop output:Droplet: , IP Address:
...
curl: (7) Failed to connect to  port 80: Connection refused
Droplet: , IP Address:
...

То есть плавающий IP-адрес должен быть переназначен так, чтобы он указывал на IP-адрес * вторичного * сервера. Это означает, что ваша установка HA работает, так как произошел успешный автоматический переход на другой ресурс.

Вы можете увидеть или не увидеть ошибку «+ Connection отказано +», которая может возникнуть, если вы попытаетесь получить доступ к плавающему IP-адресу между отказом основного сервера и завершением переназначения плавающего IP-адреса.

Если вы проверите состояние Pacemaker, вы должны увидеть, что ресурс + FloatIP + запущен на * вторичном * сервере. Кроме того, * основной * сервер должен быть временно помечен как «+ OFFLINE», но он присоединится к списку «+ Online», как только завершит перезагрузку и снова присоединится к кластеру.

Устранение неполадок при отказе (необязательно)

Пропустите этот раздел, если ваша установка HA работает должным образом. Если отработка отказа произошла не так, как ожидалось, вам следует проверить настройки перед тем, как продолжить. В частности, убедитесь, что любые ссылки на ваши собственные настройки, такие как IP-адреса узла, ваш плавающий IP-адрес и ваш токен API.

Полезные команды для устранения неполадок

Вот некоторые команды, которые могут помочь вам устранить неполадки в вашей настройке.

Как упоминалось ранее, инструмент + crm_mon + может быть очень полезен для просмотра состояния ваших узлов и ресурсов в режиме реального времени:

sudo crm_mon

Также вы можете посмотреть конфигурацию вашего кластера с помощью этой команды:

sudo crm configure show

Если команды + crm + вообще не работают, вы должны посмотреть на логи Corosync:

sudo tail -f /var/log/corosync/corosync.log

Разные команды CRM

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

Вы можете установить узел в режим + standby +, который можно использовать для имитации недоступности узла, с помощью этой команды:

sudo crm node standby

Вы можете изменить статус узла с + standby на` + online` с помощью этой команды:

sudo crm node online

Вы можете отредактировать ресурс, который позволяет вам перенастроить его, с помощью этой команды:

sudo crm configure edit

Вы можете удалить ресурс, который должен быть остановлен перед удалением, с помощью этой команды:

sudo crm resource stop
sudo crm configure delete

Наконец, команда + crm + может быть запущена сама по себе для доступа к интерактивной подсказке + crm +:

crm

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

Добавить ресурс Nginx (необязательно)

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

Pacemaker поставляется с агентом ресурсов Nginx, поэтому мы можем легко добавить Nginx в качестве ресурса кластера.

Используйте эту команду для создания нового примитивного кластерного ресурса под названием «Nginx»:

sudo crm configure primitive Nginx ocf:heartbeat:nginx \
 params httpd="/usr/sbin/nginx" \
 op start timeout="40s" interval="0" \
 op monitor timeout="30s" interval="10s" on-fail="restart" \
 op stop timeout="60s" interval="0"

Указанный ресурс предписывает кластеру контролировать Nginx каждые 10 секунд и перезапускать его, если он становится недоступным.

Проверьте состояние ресурсов вашего кластера, используя + sudo crm_mon или` + sudo crm status`:

crm_mon:...
Online: [ primary secondary ]

FloatIP    (ocf::digitalocean:floatip):    Started
Nginx  (ocf::heartbeat:nginx): Started

К сожалению, Pacemaker решит запустить ресурсы + Nginx + и + FloatIP + на отдельных узлах, потому что мы не определили никаких ограничений ресурсов. Это проблема, потому что это означает, что плавающий IP будет указывать на одну каплю, а служба Nginx будет работать только на другую каплю. Доступ к плавающему IP-адресу покажет вам сервер, на котором не запущена служба, которая должна быть высокой доступности.

Чтобы решить эту проблему, мы создадим ресурс * clone *, который указывает, что существующий примитивный ресурс должен быть запущен на нескольких узлах.

Создайте ресурс-клон ресурса + Nginx + с именем «Nginx-clone» с помощью этой команды:

sudo crm configure clone Nginx-clone Nginx

Состояние кластера теперь должно выглядеть примерно так:

crm_mon:Online: [ primary secondary ]

FloatIP (ocf::digitalocean:floatip):    Started primary
Clone Set: Nginx-clone [Nginx]
    Started: [ primary secondary ]

Как видите, ресурс clone + Nginx-clone + теперь запущен на обоих наших узлах.

Последний шаг - настроить ограничение * colocation *, чтобы указать, что ресурс + FloatIP + должен запускаться на узле с активным ресурсом + Nginx-clone +. Чтобы создать ограничение колокейшна под названием «FloatIP-Nginx», используйте эту команду:

sudo crm configure colocation FloatIP-Nginx inf: FloatIP Nginx-clone

Вы не увидите никакой разницы в выводе + crm status +, но вы можете видеть, что ресурс колокейшн был создан с помощью этой команды:

sudo crm configure show

Теперь на обоих ваших серверах должен быть запущен Nginx, в то время как только на одном из них запущен ресурс + FloatIP +. Сейчас самое время проверить настройки HA, остановив службу Nginx и перезагрузив или отключив свой * активный * сервер.

Заключение

Поздравляем! Теперь у вас есть базовая настройка сервера HA с использованием Corosync, Pacemaker и плавающего IP DigitalOcean.

Следующим шагом является замена примера настройки Nginx балансировщиком нагрузки обратного прокси-сервера. Вы можете использовать Nginx или HAProxy для этой цели. Имейте в виду, что вы захотите привязать свой балансировщик нагрузки к * привязанному IP-адресу *, чтобы ваши пользователи могли получать доступ к вашим серверам только с плавающего IP-адреса (но не через общедоступный IP-адрес каждого сервера). Этот процесс подробно описан в https://www.digitalocean.com/community/tutorials/how-to-create-a-high-availability-haproxy-setup-with-corosync-pacemaker-and-floating-ips-on- Учебное пособие по ubuntu-14-04 [Как создать установку HAProxy высокой доступности с помощью Corosync, Pacemaker и Floating IPs в Ubuntu 14.04].

TOC