Поиск по сайту:

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

Введение

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

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

Цель

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

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

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

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

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

Предпосылки

Чтобы автоматизировать переназначение зарезервированного IP-адреса, мы должны использовать API DigitalOcean. Это означает, что вам необходимо сгенерировать токен личного доступа (PAT), который представляет собой токен API, который можно использовать для аутентификации в вашей учетной записи DigitalOcean с доступом чтение и запись. следуя разделу «Как создать токен личного доступа» руководства по API. Ваш PAT будет использоваться в сценарии, который будет добавлен на оба сервера в вашем кластере, поэтому обязательно сохраните его в безопасном месте, поскольку он обеспечивает полный доступ к вашей учетной записи DigitalOcean, для справки.

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

  • Зарезервированные IP-адреса
  • Метаданные
  • Данные пользователя (сценарии Cloud-Config)

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

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

Первым шагом является создание двух капель 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-адресом дроплета (со ссылкой на службу метаданных). Доступ к любой капле через ее общедоступный IP-адрес покажет базовую веб-страницу с именем хоста и IP-адресом капли, что будет полезно для проверки того, на какую каплю указывает зарезервированный IP-адрес в любой момент.

Создать зарезервированный IP-адрес

В панели управления DigitalOcean нажмите «Сеть» в верхнем меню, затем «Зарезервированные IP-адреса» в боковом меню.

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

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

http://your_reserved_ip

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

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

Если вы хотите иметь доступ к настройке HA через доменное имя, создайте запись A в своем DNS, которая указывает ваш домен на ваш зарезервированный IP-адрес. Если ваш домен использует серверы имен DigitalOcean, выполните третий шаг руководства «Как настроить имя хоста с помощью DigitalOcean». Как только это распространится, вы сможете получить доступ к своему активному серверу через доменное имя.

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

Настройка синхронизации времени

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

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

  1. sudo dpkg-reconfigure tzdata

Выберите желаемый часовой пояс. Например, мы выберем Америка/Нью-Йорк.

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

  1. sudo apt-get update

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

  1. sudo apt-get -y install ntp

Теперь часы вашего сервера должны быть синхронизированы с помощью NTP. Чтобы узнать больше о NTP, ознакомьтесь с этим руководством: Настройка часовых поясов и синхронизации протокола сетевого времени.

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

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

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

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

  2. sudo iptables -A OUTPUT  -o eth1 -p udp -m multiport --sports 5404,5405,5406 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

Установите Corosync и кардиостимулятор

На обоих серверах установите Corosync и Pacemaker с помощью apt-get:

  1. sudo apt-get install pacemaker

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

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

Настроить Коросинк

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

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

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

На основном сервере установите пакет haveged:

  1. sudo apt-get install haveged

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

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

  1. sudo corosync-keygen

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

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

  1. sudo apt-get remove --purge haveged

  2. sudo apt-get clean

С основного сервера скопируйте authkey на дополнительный сервер:

  1. sudo scp /etc/corosync/authkey username@secondary_ip:/tmp

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

  1. sudo mv /tmp/authkey /etc/corosync

  2. sudo chown root: /etc/corosync/authkey

  3. sudo chmod 400 /etc/corosync/authkey

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

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

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

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

  1. sudo vi /etc/corosync/corosync.conf

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

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

  1. totem {

  2.   version: 2

  3.   cluster_name: lbcluster

  4.   transport: udpu

  5.   interface {

  6.     ringnumber: 0

  7.     bindnetaddr: server_private_IP_address

  8.     broadcast: yes

  9.     mcastport: 5405

  10.   }

  11. }

  12. 

  13. quorum {

  14.   provider: corosync_votequorum

  15.   two_node: 1

  16. }

  17. 

  18. nodelist {

  19.   node {

  20.     ring0_addr: primary_private_IP_address

  21.     name: primary

  22.     nodeid: 1

  23.   }

  24.   node {

  25.     ring0_addr: secondary_private_IP_address

  26.     name: secondary

  27.     nodeid: 2

  28.   }

  29. }

  30. 

  31. logging {

  32.   to_logfile: yes

  33.   logfile: /var/log/corosync/corosync.log

  34.   to_syslog: yes

  35.   timestamp: on

  36. }

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

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

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

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

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

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

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

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

Затем добавьте службу Pacemaker:

service {
  name: pacemaker
  ver: 1
}

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

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

  1. sudo vi /etc/default/corosync

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

START=yes

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

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

  1. sudo service corosync start

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

  1. 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(primary_private_IP_address)
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(secondary_private_IP_address)
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 при загрузке системы с помощью этой команды:

  1. sudo update-rc.d pacemaker defaults 20 01

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

Теперь давайте запустим Pacemaker:

  1. sudo service pacemaker start

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

Проверьте Pacemaker с помощью crm:

  1. 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 ]

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

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

  1. sudo crm_mon

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

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

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

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

  1. sudo crm configure property stonith-enabled=false

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

  1. sudo crm configure property no-quorum-policy=ignore

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

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

  1. sudo crm configure show

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

Создать зарезервированный агент ресурсов для переназначения IP-адресов

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

В нашей настройке мы хотим убедиться, что служба, предоставляемая нашими веб-серверами, первичным и вторичным, высокодоступна в активно-пассивной настройке, а это означает, что нам нужен способ гарантировать, что наш зарезервированный IP-адрес всегда указывает на доступный сервер. Чтобы включить это, нам нужно настроить агент ресурсов, который может запускать каждый узел, чтобы определить, владеет ли он зарезервированным IP-адресом, и, при необходимости, запустить сценарий, чтобы указать зарезервированный IP-адрес на себя. Зарезервированные IP-адреса иногда называют плавающими IP-адресами. В следующих примерах мы будем называть агент ресурсов \FloatIP OCF, а сценарий переназначения зарезервированного IP-адреса - assign-ip. После установки агента ресурсов FloatIP OCF мы можем определите сам ресурс, который мы будем называть FloatIP.

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

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

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

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

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

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

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

  • Зарезервированный IP-адрес: первый аргумент скрипта, зарезервированный IP-адрес, который назначается
  • Идентификатор дроплета: второй аргумент скрипта, идентификатор дроплета, которому должен быть назначен зарезервированный IP-адрес.
  • DigitalOcean PAT (токен API): передается как переменная среды DO_TOKEN, ваш PAT для чтения/записи DigitalOcean

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

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

Далее давайте установим агент ресурсов Float IP.

Скачать агент ресурсов FloatIP OCF

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

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

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

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

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

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

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

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

Для этого требуются следующие параметры OCF:

  • do_token: токен DigitalOcean API для переназначения зарезервированных IP-адресов, т. е. ваш токен личного доступа DigitalOcean.
  • reserved_ip: ваш зарезервированный IP-адрес (адрес) на случай, если его нужно будет переназначить

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

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

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

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

  1. sudo crm configure primitive FloatIP ocf:digitalocean:floatip \

  2.   params do_token=your_digitalocean_personal_access_token \

  3.   reserved_ip=your_reserved_ip

При этом создается примитивный ресурс, представляющий собой общий тип ресурса кластера, называемый \FloatIP, с использованием агента ресурсов FloatIP OCF, который мы создали ранее (ocf:digitalocean:floatip). Обратите внимание, что для этого требуется do_token и reserved_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 primary

Предполагая, что все было настроено правильно, теперь у вас должна быть активная/пассивная настройка HA! В настоящее время зарезервированный IP-адрес будет переназначен онлайн-серверу, если узел, на котором запущен FloatIP, отключится или перейдет в режим ожидания. Прямо сейчас, если активный узел — первичный в нашем примере выходных данных — становится недоступным, кластер дает указание вторичному узлу запустить ресурс FloatIP и потребовать зарезервированный IP-адрес для себя. Как только произойдет переназначение, зарезервированный IP-адрес направит пользователей на новый активный вторичный сервер.

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

Проверка высокой доступности

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

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

Reserved IP is pointing to primary server:
Droplet: primary, IP Address: primary_ip_address

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

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

  1. while true; do curl reserved_IP_address; sleep 1; done

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

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

  1. sudo reboot

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

curl loop output:
Droplet: primary, IP Address: primary_IP_address
...
curl: (7) Failed to connect to reserved_IP_address port 80: Connection refused
Droplet: secondary, IP Address: secondary_IP_address
...

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

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

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

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

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

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

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

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

  1. sudo crm_mon

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

  1. sudo crm configure show

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

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

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

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

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

  1. sudo crm node standby NodeName

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

  1. sudo crm node online NodeName

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

sudo crm configure edit ResourceName

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

  1. sudo crm resource stop ResourceName

  2. sudo crm configure delete ResourceName

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

  1. crm

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

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

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

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

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

  1. sudo crm configure primitive Nginx ocf:heartbeat:nginx \

  2.   params httpd="/usr/sbin/nginx" \

  3.   op start timeout="40s" interval="0" \

  4.   op monitor timeout="30s" interval="10s" on-fail="restart" \

  5.   op stop timeout="60s" interval="0"

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

Проверьте состояние ресурсов кластера с помощью sudo crm_mon или sudo crm status:

crm_mon:
...
Online: [ primary secondary ]

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

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

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

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

  1. 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 ]

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

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

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

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

  1. sudo crm configure show

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

Заключение

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

Следующим шагом является замена примера установки Nginx балансировщиком нагрузки с обратным прокси. Для этой цели вы можете использовать Nginx или HAProxy. Имейте в виду, что вы захотите привязать свой балансировщик нагрузки к якорному IP-адресу, чтобы ваши пользователи могли получать доступ к вашим серверам только через зарезервированный IP-адрес (а не через общедоступный IP-адрес каждого сервера). Этот процесс подробно описан в руководстве «Как создать настройку HAProxy высокой доступности с Corosync, Pacemaker и зарезервированными IP-адресами в Ubuntu 14.04».