Настройка высокой доступности с помощью Heartbeat и плавающих IP-адресов в Ubuntu 14.04

1: установка и настройка nginx

Хотя keepalived часто используется для мониторинга и балансировки нагрузки (что упрощает инфраструктуру), в этом мануале вместо него в качестве простого веб-сервера используется Nginx.

Обновите индекс пакетов на каждом из ваших серверов. Затем можно установить Nginx:

sudo apt-get updatesudo apt-get install nginx

В большинстве случаев настройка высокой доступности создается для обслуживания одного и того же контента. Однако в этом мануале Nginx будет обслуживать разный контент: это нужно для того, чтобы видеть, какой из двух серверов обслуживает запросы в тот или иной момент. Для этого нужно изменить страницу index.html по умолчанию на каждом из хостов. Откройте файл:

sudo nano /usr/share/nginx/html/index.html

На первом сервере замените контент файла этой строкой:

На втором сервере файл будет содержать такую строку:

Сохраните и закройте файлы.

Сервер 1 будет теперь первичным, а сервер 2 – вторичным.

3: создание сценария upstart для keepalived

Установка keepalived перенесла все бинарные и сопутствующие файлы в систему. Однако среди них нехватает сценария Upstart для системы Ubuntu 14.04.

Вы можете создать очень простой сценарий Upstart, который будет обрабатывать сервис keepalived. Откройте файл под названием keepalived.conf в /etc/init:

sudo nano /etc/init/keepalived.conf

Для начала добавьте краткое описание сервиса keepalived. Можно использовать описание демона из его справки. Затем укажите уровни запуска, на которых нужно запустить и остановить сервис; в данном случае для запуска используются уровни 2-5, а для остановки – все остальные уровни (например, при перезагрузке, отключении питания или в однопользовательском режиме).

description «load-balancing and high-availability service»start on runlevel [2345]stop on runlevel [!2345]

Поскольку этот сервис является неотъемлемой частью обеспечения высокой доступности вашего приложения, его необходимо перезагружать в случае сбоя. Затем нужно добавить строку exec, которая запустит сервис, и добавить в нее опцию —dont-fork, чтобы система Upstart правильно отслеживала pid:

description «load-balancing and high-availability service»start on runlevel [2345]stop on runlevel [!2345]respawnexec /usr/local/sbin/keepalived —dont-fork

Сохраните и закройте файл.

Такой файл нужно создать на всех серверах инфраструктуры.

4: конфигурация keepalived

Теперь можно перейти к настройке keepalived.

Сервис ищет конфигурации в каталоге /etc/keepalived. Создайте этот каталог на обоих серверах:

sudo mkdir -p /etc/keepalived

4: установка heartbeat

Далее нужно установить Heartbeat на обоих серверах. Самый простой способ установить Heartbeat – использовать apt-get:

sudo apt-get updatesudo apt-get install heartbeat

Приложение Heartbeat установлено, но нуждается в настройке.

5: настройка heartbeat

Чтобы получить нужный кластер, необходимо создать и настроить следующие файлы Heartbeat на обоих серверах в каталогах /etc/ha.d.

  • ha.cf – глобальная конфигурация кластера Heartbeat, которая включает все ноды.
  • authkeys – содержит ключ безопасности, который позволяет нодам пройти аутентификацию в кластере.
  • haresources – определяет сервисы, которыми управляет кластер, и ноду, которая должна быть владельцем этих сервисов. Обратите внимание, этот файл не используется в настройке, в которой есть CRM, (например, Pacemaker).
Предлагаем ознакомиться  Intel Xeon W3680 против X5650

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

6: запуск keepalived и тестирование настройки

Теперь демон keepalived и все его сопутствующие скрипты полностью настроены. Можно запустить сервис на обеих машинах, набрав:

sudo start keepalived

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

Если оба сервера работают корректно, при посещении плавающего адреса в браузере вы увидите страницу Nginx первичного сервера:

Primary

Протестируйте высокую доступность и функцию обработки сбоев инфраструктуры.

Обработка сбоев должна происходить при возникновении любого из следующих условий:

  1. Когда проверка состояния Nginx на первичном сервере указывает на то, что Nginx больше не работает. В этом случае демон keepalived первичного сервера перейдет в состояние «fault». Он уведомит вторичный сервер о том, что он должен взять на себя роль первичного сервера и присвоить себе плавающий IP-адрес.
  2. Когда вторичный сервер теряет свое соединение keepalived с первичным сервером. Если по какой-либо причине вторичный сервер не может связаться с первичным сервером, он перейдет в состояние master и попытается присвоить плавающий IP-адрес.

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

6: создание сервиса для переназначения ip-адреса

Кластер Heartbeat поддерживает сервис floatip, который ноды могут использовать для присвоения плавающего IP-адреса, но сервис все равно нужно создать. Однако прежде чем настроить сервис, нужно создать сценарий, который через API присвоит плавающий IP-адрес ноде, которая его запускает. Затем нужно создать сервис floatip, который будет запускать сценарий переназначения плавающего IP.

7: запуск heartbeat

Теперь приложение Heartbeat настроено, все соответствующие сценарии готовы. Можно запустить кластер Heartbeat.

На обоих серверах введите эту команду для запуска кластера Heartbeat:

sudo service heartbeat start

Вы увидите такой вывод:

Starting High-Availability services: Done.

Настройка инфраструктуры высокой доступности завершена.

Конфигурация вторичного сервера

Теперь нужно создать подобный файл на вторичном сервере. Откройте файл в /etc/keepalived/keepalived.conf:

sudo nano /etc/keepalived/keepalived.conf

Конфигурационный файл вторичного сервера будет в значительной степени эквивалентен конфигурации первичного сервера. Элементы, которые нужно изменить здесь:

  • state: измените значение параметра на BACKUP, чтобы нода инициализировалась в режиме резервного копирования до проведения голосования.
  • priority: здесь нужно указать меньшее значение, чем на первичном сервере, например, 100.
  • unicast_src_ip: здесь нужно указать внутренний IP-адрес вторичного сервера.
  • unicast_peer: здесь нужно указать внутренний IP-адрес первичного сервера.

Изменив эти параметры, вы получите такой конфигурационный файл вторичного сервера:

vrrp_script chk_nginx {script «pidof nginx»interval 2}vrrp_instance VI_1 {interface eth1state BACKUPpriority 100virtual_router_id 33unicast_src_ip secondary_private_IPunicast_peer {primary_private_IP}authentication {auth_type PASSauth_pass password}track_script {chk_nginx}notify_master /etc/keepalived/master.sh}

Предлагаем ознакомиться  Сколько места должно быть на диске C

Сохраните и закройте файл.

Конфигурация первичного сервера

Перейдите на сервер 1 и создайте главный конфигурационный файл keepalived. Демон ищет файл keepalived.conf в каталоге /etc/keepalived.

sudo nano /etc/keepalived/keepalived.conf

Начните с определения проверки работоспособности сервиса Nginx, открыв блок vrrp_script. Это настроит мониторинг состояния веб-сервера, что позволяет своевременно обнаружить сбой и начать восстановление.

Эта проверка очень проста. Каждые две секунды демон будет проверять, что процесс nginx все еще требует pid:

vrrp_script chk_nginx {script «pidof nginx»interval 2}

Затем откройте блок vrrp_instance. Это основной раздел конфигурации, который определяет, как keepalived будет обеспечивать высокую доступность.

Настройте keepalived для использования частного интерфейса eth1. В настройках первичного сервера в параметре state нужно указать MASTER. Это исходное значение, которое будет использовать keepalived.

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

vrrp_script chk_nginx {script «pidof nginx»interval 2}vrrp_instance VI_1 {interface eth1state MASTERpriority 200}

Далее нужно присвоить этой группе кластера ID, который будут совместно использовать обе ноды. В мануале используется ID 33. В параметре unicast_src_ip укажите внутренний IP-адрес первичного сервера, а в unicast_peer – внутренний IP-адрес вторичного сервера.

vrrp_script chk_nginx {script «pidof nginx»interval 2}vrrp_instance VI_1 {interface eth1state MASTERpriority 200virtual_router_id 33unicast_src_ip primary_private_IPunicast_peer {secondary_private_IP}}

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

vrrp_script chk_nginx {script «pidof nginx»interval 2}vrrp_instance VI_1 {interface eth1state MASTERpriority 200virtual_router_id 33unicast_src_ip primary_private_IPunicast_peer {secondary_private_IP}authentication {auth_type PASSauth_pass password}}

Затем нужно использовать подпрограмму chk_nginx, созданную в начале файла, чтобы определить состояние работоспособности локальной системы. После этого нужно создать скрипт notify_master, который будет выполняться всякий раз, когда эта нода будет ведущей. Этот скрипт будет отвечать за запуск переназначения плавающего IP-адреса.

vrrp_script chk_nginx {script «pidof nginx»interval 2}vrrp_instance VI_1 {interface eth1state MASTERpriority 200virtual_router_id 33unicast_src_ip primary_private_IPunicast_peer {secondary_private_IP}authentication {auth_type PASSauth_pass password}track_script {chk_nginx}notify_master /etc/keepalived/master.sh

Сохраните и закройте файл.

Политика безопасности

Виртуальные сервера с информацией, требующей высокой степени защищенности и доступности, можно объединять в локальные сети. Для связи с интернетом можно использовать подключение через NAT на виртуальных серверах вне безопасных частных локальных сетей внутри облака.

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

Решаемые задачи

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

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

Предлагаем ознакомиться  Оперативная память Kingston ValueRAM [KVR13N9S8/4] 4 ГБ

Примеры систем, в которых можно использовать облачную платформу Selectel:

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

Сбор информации о ноде

Прежде чем настроить файл ha.cf, нужно узнать имя каждой ноды. Heartbeat требует, чтобы имя ноды совпадало с ее выводом uname –n.

Следующую команду нужно запустить на обоих серверах.

uname -n

Обратите внимание на вывод команды. Ноды должны иметь имена primary и secondary.

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

Чтобы узнать IP-адрес интерфейса eth0, запустите следующую команду на обоих серверах:

ip addr show eth0ip addr show eth0 output:2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000link/ether 04:01:76:a5:45:01 brd ff:ff:ff:ff:ff:ffinet 104.236.6.11/18 brd 104.236.63.255 scope global eth0valid_lft forever preferred_lft foreverinet 10.17.0.

Примечание: Также узнать IP-адрес можно с помощью панели управления.

Обратите внимание на IP-адрес сетевого интерфейса (в примере он выделен красным). Не забудьте получить IP-адреса обоих серверов.

Создание файла haresources

Файл haresources указывает предпочтительные хосты в паре  сервисами, которыми управляет кластер. Предпочтительным хостом является нода, которая должна запускать тот или иной сервис, если она доступна. Если предпочтительный хост недоступен в кластере, сервис передается другому хосту. Другими словами, вторичный сервер возьмет работу на себя, если первичный сервер перестанет работать.

На обоих серверах откройте файл haresources в текстовом редакторе:

sudo vi /etc/ha.d/haresources

Добавьте в файл эту строку, указав имя ноды 1:

primary floatip

Сохраните и закройте файл.

Этот параметр настроит сервер 1 как предпочтительный хост для сервиса floatip, который в настоящее время не определен. Теперь нужно настроить сервис floatip.

Тестирование обработки ошибок сервера

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

sudo reboot

Опять же, сначала вы увидите сообщение об ошибке:

This webpage is not availableERR_CONNECTION_REFUSED

Через несколько секунд вторичный сервер обработает запросы, и на странице появится сообщение:

Secondary

Спустя пару секунд первичный сервер завершит перезагрузку и вернет себе плавающий IP-адрес.

Оцените статью
Техничка
Adblock detector