Содержание


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

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

Comments

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
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
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
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
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-сервер и реверсивный прокси-сервер.
  • Высокая степень готовности прокси-серверов в данной статье обеспечивалась следующими средствами:
    • Проект Linux-HA поддерживает набор конструктивных блоков для построения кластерных систем высокой готовности [Загрузить Heartbeat | Загрузить Cluster Glue | Загрузить Resource Agents].
    • Для получения практической пользы демон Heartbeat следует применять в сочетании с каким-либо инструментом для управления ресурсами кластера, например, с инструментом Pacemaker.
    • o Пакеты EPEL (Extra Packages for Enterprise Linux) создаются силами добровольцев из сообщества проекта Fedora с целью формирования репозитария высококачественных дополнительных пакетов для Red Hat Enterprise Linux (RHEL) и совместимых побочных проектов [Сведения о EPEL | Загрузить].
  • В разделе Ресурсы для cloud-разработчиков на Web-сайте developerWorks вы сможете обменяться знаниями и опытом с разработчиками приложений и сервисов, создающих проекты для развертывания в Cloud-среде.
  • Познакомьтесь со средой разработки и тестирования IBM Smart Business Development and Test on the IBM Cloud.

Комментарии

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

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