Обеспечение высокой степени готовности приложений на платформе IBM Cloud

Как защитить Cloud-приложение производственного уровня от отказа на любом узле

Новые функции платформы IBM® Cloud позволяют разработчикам и архитекторам приложений исключить единичные точки отказа в этих приложениях. Данная статья предоставляет собой детальное руководство по этим функциям. В статье рассматриваются следующие вопросы: подход к обеспечению высокой готовности (HA), применяемый в среде IBM Cloud (добавление поддержки виртуальных IP-адресов); порядок подготовки экземпляров Cloud-среды к использованию этих функций; порядок настройки Web-сайта высокой готовности и порядок тестирования этого Web-сайта.

Дима Рекеш, старший технический специалист, IBM

Дима Рекеш — участник стратегической группы IBM Cloud Computing Enterprise Initiatives. Ранее он работал над целым рядом крупномасштабных платформ Web-приложений, участвовал в разработке новых технологий, а также занимался выработкой стратегий в отношении передовых и экологически чистых центров обработки данных.



Алан Робертсон, консультант по решениям высокой готовности, IBM

Алан Робертсон (Alan Robertson) является основателем проекта с открытым исходным кодом LINUX-HA и всемирно известным экспертом по системам высокой готовности. Его часто приглашают выступать по вопросам высокой готовности и Linux.



17.12.2012

The IBM® Smart Business Development and Test - это динамически инициализируемая и масштабируемая эластичная среда, предоставляющая корпоративным заказчикам все необходимое для разработки, тестирования и хостинга приложений. Эта среда содержит Web-портал для конфигурирования Cloud-ресурсов и управления ими; образы программных продуктов IBM, позволяющие заказчику быстро приступить к разработке и тестированию; а также API-интерфейсы, позволяющие заказчику программным образом управлять предоставляемыми ему ресурсами и приложениями Cloud-среды. Кроме того, за период, прошедший с момента появления платформы IBM Cloud, специалисты IBM добавили новые функции, призванные обеспечить ей дополнительную гибкость и устойчивость.

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

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

С учетом этого обстоятельства заказчикам приходится дополнять свои Cloud-развертывания специальными HA-конструкциями, существующими за пределами Cloud-среды. В данной статье демонстрируется, каким образом эта проблема решается в среде IBM Cloud и как заказчик может воспользоваться соответствующими функциями в своих интересах.

  • Сначала мы рассмотрим подход, применяемый в IBM Cloud (добавление поддержки виртуальных IP-адресов).
  • Мы покажем, как заказчик сможет подготовить свои Cloud-экземпляры для использования этих функций.
  • Затем на конкретном примере мы продемонстрируем, как настроить Web-сайт высокой готовности.
  • И, наконец, мы покажем, как осуществить тестирование этого Web-сайта.

Надежная и адекватная поддержка виртуальных IP-адресов

Для надежного и адекватного решения проблем высокой готовности (HA) разработчики платформы IBM Cloud добавили поддержку виртуальных IP-адресов (vIP) на виртуальных экземплярах среды IBM Cloud. Хотя существует много различных методов поддержки сервисов высокой готовности (см. раздел Ресурсы), наиболее популярный и надежный из этих методов состоит в использовании виртуальных IP-адресов.

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

Рассмотрим следующий простой пример. Имеется две виртуальные машины, VM A и VM B, со статическими IP-адресами 192.168.1.101 и 192.168.1.102 соответственно. Кроме того, обе виртуальные машины сконфигурированы для поддержки динамического присваивания vIP-адреса 192.168.1.10 (рисунок 1).

Рисунок 1. Виртуальные машины VM A и VM B имеют индивидуальные статические IP-адреса и способны принять vIP-адрес
VM A and B have individual static IPs and can assume a vIP

В этой конфигурации статические IP-адреса используются для администрирования и технического сопровождения экземпляров. Виртуальный IP-адрес используется для других целей – он предоставляется клиентам как IP-адрес соответствующего сервера.

На начальном этапе этот vIP-адрес присваивается виртуальной машине VM A, которая, соответственно, обрабатывает весь трафик данного сервиса. Виртуальная машина VM B также функционирует, однако она не имеет vIP-адреса и выступает в качестве «теплого» резерва (рисунок 2).

Рисунок 2. Конфигурация активный/пассивный: машина VM A удерживает vIP-адрес и обслуживает весь трафик; машина VM B действует как пассивный резерв
Active/passive configuration: VM A holds the vIP and services all traffic; VM B acts as a passive stand-by

Теперь предположим, что приложение обнаруживает проблему в виртуальной машине VM A. К примеру, эта машина стала работать медленно или вообще отказала. Приложение решает передать вышеуказанный vIP-адрес другой виртуальной машине. Теперь обслуживание всего трафика осуществляет виртуальная машина VM B, а виртуальная машина VM A, высвободившая vIP-адрес, после восстановления становится теплым резервом (рисунок 3).

Рисунок 3. Конфигурация активный/пассивный: виртуальные машины поменялись ролями
Active/passive configuration: VMs swap roles

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

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


Подготовка экземпляров к обеспечению высокой готовности

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

Получение свободного (незакрепленного) резервного IP-адреса

Удостоверьтесь в наличии свободного (незакрепленного) резервного IP-адреса. Войдите в портал IBM Cloud и нажмите на вкладку Account Tab. Прокрутите окно вниз до раздела Your Ips, в котором содержится список резервных IP-адресов. Убедитесь в том, что в вашем центре обработки данных имеется не менее одного свободного (Free) адреса; в противном случае нажмите на кнопку Add IP и дождитесь доступности нового IP-адреса (рисунок 4).

Рисунок 4. Панель резервных IP-адресов на портале IBM Cloud
The reserved IP address panel of the IBM Cloud portal

Инициализация экземпляров

Теперь инициализируйте свои экземпляры. Выберите нужный образ и на следующем экране нажмите на кнопку Add IP рядом с полем Virtual IP, а затем выберите один из свободных IP-адресов (рисунок 5).

Рисунок 5. В диалоговом окне инициализации экземпляра портала IBM Cloud пользователь может присвоить vIP-адрес своему экземпляру
This IBM Cloud instance provision dialog lets you assign a vIP to your instance

Обратите внимание, что виртуальный IP-адрес должен находиться в том же центре обработки данных, что и экземпляр, которому вы присваиваете этот адрес. Нажмите на кнопку Close и завершите запрос на инициализацию.

После инициализации каждый экземпляр сначала получает только свой статический IP-адрес. Обратите внимание, что статический IP-адрес экземпляра связан с сетевым интерфейсом eth0, а виртуальные IP-адреса (если они были выбраны на этапе инициализации) присваиваются интерфейсам eth0, eth1 и т.д., в порядке их выбора.

Связывание vIP-адреса с экземпляром

В любой момент жизненного цикла экземпляра можно с помощью команды sudo /sbin/ifup <interface name> связать с этим экземпляром какой-либо виртуальный IP-адрес. Команда sudo /sbin/ifdown <interface name> выполняет высвобождение виртуального IP-адреса.

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

В качестве примера предположим, что экземпляр получил присвоенный системой статический IP-адрес 170.224.163.231 и виртуальный IP-адрес 170.224.163.161. Дополнительные сведения о конфигурации первичного интерфейса содержатся в файле /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
TYPE=Ethernet
BOOTPROTO=static
HWADDR=DE:AD:BE:A7:13:52
IPADDR=170.224.163.231
NETMASK=255.255.240.0
ONBOOT=yes
GATEWAY=170.224.160.1

Сравните его с файлом /etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE=eth1
TYPE=Ethernet
BOOTPROTO=static
HWADDR=DE:AD:BE:C8:25:20
IPADDR=170.224.163.161
NETMASK=255.255.240.0
ONBOOT=no

Выполните команду sudo /sbin/ifup eth1 для связывания адреса 170.224.163.161 с экземпляром и команду sudo /ifdown eth1 для его высвобождения. Если вы хотите получить этот IP-адрес в процессе загрузки, измените значение параметра ONBOOT в файле /etc/sysconfig/network-scripts/ifcfg-eth1 на «yes».


Настройка Web-сайта высокой готовности

В этом примере мы создадим простую топологию, которая будет состоять из двух прокси-серверов, сконфигурированных в HA-конфигурации активный/пассивный, и трех Web-серверов/серверов приложений (как показано на рисунке 6):

Рисунок 6. Простая топология, в которой два реверсивных прокси-сервера в конфигурации активный/пассивный распределяют трафик между тремя Web-серверами
A simple topology where a pair of reverse proxies, set up in the active/passive configuration, sprays traffic across three web servers

В этом примере используется следующая конфигурация программного обеспечения:

  • На прокси-серверах исполняется nginx.
  • Высокая готовность прокси-серверов поддерживается программным обеспечением Linux HA и Pacemaker.
  • На Web-серверах исполняется Apache (устанавливается заранее в составе образа Base OS).
  • Все экземпляры IBM Cloud используют базовый 64-разрядный образ RHEL 5.4.
  1. Все пять экземпляров необходимо инициализировать с помощью портала IBM Cloud. Убедитесь в том, что вы зарезервировали и присвоили vIP-адрес двум узлам прокси-серверов, как было описано выше.
  2. Сконфигурируйте экземпляры прокси-серверов. Ссылки на все необходимые загрузки указаны в разделе Ресурсы.
  3. Необходимо соблюсти несколько обязательных условий:
    sudo yum -y install glib2-devel libxml2 libxml2-devel bzip2 bzip2-devel pcre-devel
  4. Установите nginx (например, следующим образом):
    wget http://nginx.org/download/nginx-0.8.53.tar.gz
    tar -xvfz nginx-0.8.53.tar.gz
    cd nginx-0.8.53
    ./configure -with-http_ssl_module
    make
    sudo make install
  5. Чтобы добавить в nginx базовые правила прокси-сервера, откройте в редакторе файл /usr/local/nginx/conf/nginx.conf и под директивой server добавьте следующие строки (используйте реальные IP-адреса серверов приложений (appserver):
    upstream appservers {
       ip_hash;
       server appserver1_ip;
       server appserver2_ip;
       server appserver3_ip;
        	}
  6. Время на всех серверах должно быть согласованным, поэтому проследите, чтобы ntpd запускался автоматически
    sudo /sbin/chkconfig --level 2345 ntpd on
    sudo /sbin/service ntpd start
  7. Установите пакеты Pacemaker и LINUX-HA. Удостоверьтесь в доступности репозитариев Clusterlabs (Pacemaker) и EPEL. Для RHEL 5.4 выполните следующие две команды:
    sudo rpm -Uvh \
    http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
    sudo wget -O \
    /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

    Затем установите Pacemaker и требуемые пакеты:
    sudo yum install -y pacemaker heartbeat
  8. Вам потребуется совместимый скрипт для управления сервером nginx, поэтому установите агент ресурсов nginx. Этот скрипт был представлен в проект LINUX-HA, поэтому со временем он будет поставляться автоматически, а пока воспользуйтесь следующей командой:
    sudo wget -O /usr/lib/ocf/heartbeat/resource.d/nginx \
    http://lists.linux-ha.org/pipermail/linux-ha-dev/attachments/20101206/3c141ea6/
          attachment.txt
  9. Вы должны предоставить надлежащую конфигурацию для программного обеспечения Heartbeat проекта LINUX-HA. Для IBM Cloud необходимо сконфигурировать все коммуникации, которые будут осуществляться с использованием однонаправленной передачи (отсылка сообщений на единственный пункт назначения в сети, идентифицируемый по своему уникальному адресу). Именно для этого был установлен коммуникационный уровень Heartbeat.

    Для конфигурирования коммуникационного уровня Heartbeat используются три разных файла: /etc/ha.d/ha.cf, /etc/ha.d/authkeys и /etc/logd.cf.

    • Все машины должны иметь точную копию файла /etc/ha.d/ha.cf. Для конфигурирования добавьте следующие строки:
      use_logd yes
      ucast eth0 cluster1-fixed-ip
      ucast eth0 cluster2-fixed-ip # repeat for all cluster nodes
      autojoin any
      crm on

      Следует отметить, что в среде IBM Cloud необходимо использовать коммуникацию типа ucast, поскольку эта среда не поддерживает широковещательную и многоадресную передачу. Это обстоятельство препятствует использованию Corosync в качестве коммуникационного уровня, поскольку этот продукт требует широковещательной или многоадресной передачи. «Фиксированные» IP-адреса, которые необходимо указать – это реальные (не виртуальные) адреса серверов. Введите по одной строке для каждого сервера.
    • Кроме того, каждая машина должна иметь копию файла /etc/ha.d/authkeys; должен использоваться режим 0600. Создайте первый экземпляр файла, как указано ниже, а затем скопируйте этот файл на все остальные узлы в кластере:
      cat <<-!AUTH >/etc/ha.d/authkeys
      auth 1
      	1 sha1 'dd if=/dev/urandom count=4 2>/dev/null | openssl dgst -sha1`
      	!AUTH
    • Наконец, добавьте в файл /etc/ha.d/logd.cf следующую строку: logfacility daemon. logfacility daemon.
  10. Поскольку конфигурировать Pacemaker проще в процессе исполнения, отложим это конфигурирование до более позднего момента.
  11. С помощью следующего кода обеспечьте автоматический запуск Heartbeat:
    sudo /sbin/chkconfig --levels 345 heartbeat on
  12. Начальная конфигурация межсетевого экрана является слишком «запретительной», поэтому добавьте в файл /etc/sysconfig/iptables несколько правил:
    # разрешить пингование
    -A INPUT -p icmp --icmp-type any -j ACCEPT
    # on the virtual IP address, allow only ports 80 and 443.  
    -A INPUT -d virtual_ip -m tcp -p tcp --dport 80 -j ACCEPT
    -A INPUT -d virtual_ip -m tcp -p tcp --dport 443 -j ACCEPT
    -A INPUT -d virtual_ip  -j REJECT --reject-with icmp-host-prohibited
    
    # разрешить ssh для IP-адресов данного сервиса
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    
    # разрешить порт heartbeat
    -A INPUT -p udp -m udp --dport 694 -j ACCEPT
  13. После завершения редактирования перезапустите межсетевой экран:
    sudo /sbin/service iptables restart

    .
  14. Для Web-серверов требуется лишь минимальное конфигурирование. Во-первых, обеспечьте автоматический запуск Apache:
    sudo /sbin/chkconfig -level 345 httpd on
    sudo /sbin/service httpd start

    Затем откройте порты 80 и 443 в файле /etc/sysconfig/iptables:

    -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

    После этого перезапустите межсетевой экран: sudo /sbin/service iptables restart. Проследите за тем, чтобы ntpd запускался автоматически и на этих узлах:

    sudo /sbin/chkconfig --level 2345 ntpd on
    sudo /sbin/service ntpd start

На этом настройка завершается. Теперь протестируем систему.


Тестирование системы

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

  1. На каждом узле кластера запустите Heartbeat (что приведет к запуску Pacemaker).
  2. Сконфигурируйте Pacemaker с помощью команды crm.
  3. Убедитесь в корректном запуске всех компонентов.
  4. Протестируйте конфигурацию. Выполните несколько базовых операций по передаче данных с переключением ресурсов.

Запуск Heartbeat

Для запуска Heartbeat выполните команду service heartbeat start. После этого вы должны увидеть множество процессов, выглядящих примерно следующим образом:

ha_logd: read process
ha_logd: write process
heartbeat: master control process
heartbeat: FIFO reader
heartbeat: write: ucast some-ip-address
heartbeat: read: ucast some-ip-address
/usr/lib/heartbeat/ccm
/usr/lib/heartbeat/cib
/usr/lib/heartbeat/lrmd -r
/usr/lib/heartbeat/stonithd
/usr/lib/heartbeat/attrd
/usr/lib/heartbeat/crmd
/usr/lib/heartbeat/pengine

Наличие этих процессов означает, что Heartbeat и Pacemaker исполняются.

Конфигурирование Pacemaker

Для конфигурирования Pacemaker отредактируйте «живую» конфигурацию с помощью команды crm configure edit, которая открывает текстовый редактор. Вставьте в конфигурационный файл следующие строки непосредственно перед утверждением property в нижней части файла:

primitive nginx-primitive ocf:heartbeat:nginx \
 op monitor interval="5s" timeout="120s" \
 OCF_CHECK_LEVEL="0" \
 op monitor interval="10s" timeout="120s" \ 
 OCF_CHECK_LEVEL="10" \
 params configfile="/etc/nginx/stci.d/nginx.conf"
primitive nginx-ipaddr ocf:heartbeat:IPaddr2 \
 op monitor interval="5s" timeout="120s"\
 params ip="NGINX-IP-ADDRESS"
primitive NFS-server lsb:nfs-kernel-server
primitive NFS-ipaddr ocf:heartbeat:IPaddr2 \
 op monitor interval="5s" timeout="120s"\
 params ip="NFS-IP-ADDRESS"
group nginx-group nginx-primitive nginx-ipaddr
group NFS-group NFS-server NFS-ipaddr
clone nginx-clone nginx-group \
        meta clone-max="1"

Проверка запуска

После сохранения конфигурации Pacemaker система запустит ваши ресурсы и распространит эту новую конфигурацию на все узлы в системе. Это важный момент. При просмотре системных журналов вы должны увидеть сообщения о запускаемых сервисах и т.д. Чтобы увидеть состояние HA-системы, выполните команду sudo crm_mon. Она покажет исполняющиеся ресурсы, включенные/выключенные узлы кластеры и т. д.

Тестирование конфигурации

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

  • Выполните на активном узле команду sudo service heartbeat stop; посмотрите, куда происходит перемещение, и затем перезапустите этот узел
  • Выполните на активном узле команду sudo reboot -f, а затем наблюдайте (с другого узла), куда перемещаются ресурсы.
  • Выполните на активном узле команду sudo crm node standby, посмотрите, куда переместился сервис, затем выполните команду sudo crm node online.

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


Заключение

Набор методов, описанных в этой статье, можно использовать для обеспечения высокой степени готовности почти любого сервиса в Cloud-среде; например, для высокой готовности NFS-сервера в среде IBM Cloud, что предусматривает репликацию данных между виртуальными Cloud-серверами.

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

Ресурсы

Научиться

  • Помимо виртуальных IP-адресов, существуют и другие методы для поддержания высокой готовности сервисов. На Web-сайте Managing Computers with Automation собраны материалы по таким темам, как готовность, автоматизация, управляющие системы, открытый исходный код, а также по многим другим.
  • nginx ("engine x") - это HTTP-сервер и реверсивный прокси-сервер.
  • В разделе Ресурсы для cloud-разработчиков на Web-сайте developerWorks вы сможете обменяться знаниями и опытом с разработчиками приложений и сервисов, создающих проекты для развертывания в Cloud-среде.
  • Следите за обновлениями Web-сайта developerWorks on Twitter.
  • Познакомьтесь со средой разработки и тестирования IBM Smart Business Development and Test on the IBM Cloud.

Получить продукты и технологии

  • Высокая степень готовности прокси-серверов в данной статье обеспечивалась следующими средствами:
    • Проект Linux-HA поддерживает набор конструктивных блоков для построения кластерных систем высокой готовности [Загрузить Heartbeat | Загрузить Cluster Glue | Загрузить Resource Agents].
    • Для получения практической пользы демон Heartbeat следует применять в сочетании с каким-либо инструментом для управления ресурсами кластера, например, с инструментом Pacemaker.
    • o Пакеты EPEL (Extra Packages for Enterprise Linux) создаются силами добровольцев из сообщества проекта Fedora с целью формирования репозитария высококачественных дополнительных пакетов для Red Hat Enterprise Linux (RHEL) и совместимых побочных проектов [Сведения о EPEL | Загрузить].

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Linux, Open source
ArticleID=852153
ArticleTitle=Обеспечение высокой степени готовности приложений на платформе IBM Cloud
publish-date=12172012