Введение
В корпоративной среде, обеспечение высокой доступности приложений, а также их масштабирование для распределения нагрузки, играют важную роль. Поэтому, в настоящей статье, на примере развертывания рабочих серверов OneScript для конфигурации АИТП (проект на GitHub), рассмотрено создание кластера высокой доступности для web-приложения на основе http-сервисов OneScript.
Поскольку приложения на основе http-сервисов OneScript являются web-приложениями, для обеспечения их высокой доступности используется технология распределения (балансировки) сетевой нагрузки (NLB). В качестве основы, для построения кластера NLB выбрана технология Linux Virtual Server (LVS). С документацией по установке и настройке LVS для RHEL, которая также подойдет и для CentOS, можно ознакомиться, перейдя по этой ссылке.
Особенности архитектуры
Базовая конфигурация LVS состоит из двух уровней (см. рис. 1).
Рисунок 1. Базовая конфигурация LVS.
На первом уровне, находятся два LVS маршрутизатора. Они имеют по два сетевых интерфейса и перенаправляют (балансируют) входящий траффик на сервера приложений (real servers), которые находятся “за” маршрутизаторами. Сервера приложений обрабатывают поступивший траффик и отправляют ответ обратно, на маршрутизатор.
В нашем случае, создание нескольких подсетей и соответственно интерфейсов будет избыточным, поэтому была реализована конфигурация, где маршрутизаторы имеют один сетевой интерфейс.
Для уменьшения траффика через маршрутизаторы можно использовать технологию Direct Routing (см. рис 2.), где сервера приложений отправляют траффик напрямую получателю, минуя маршрутизаторы.
Рисунок 2. Схема работы Direct Routing.
Подготовка лабораторной среды
Для тестового развертывания нам понадобится лабораторная среда, аналогичная среде, описанной ранее. В нашем случае она была дополнена еще одним рабочим сервером, а также двумя виртуальными машинами – маршрутизаторами см. рис. 3.
Рисунок 3. Лабораторная среда.
В качестве сертификата, для размещения на рабочих серверах использовался wildcard сертификат - *.itpa.cf.
В дальнейшем предполагается, что все компоненты лабораторной среды установлены и настроены.
Также предполагается, что ноды кластера рабочих серверов, а также маршрутизаторы настроены в соответствии с этой публикацией, (маршрутизаторы до пункта “Подготовка среды для web-приложения”).
Настройки firewall, установка компонентов etc. должны выполняться на обеих нодах или маршрутизаторах, если не указано другое.
Настройка рабочих серверов
Настройка firewall
Разрешим проверку доступности web-сервера с маршрутизаторов. Для этого, добавим ip адреса маршрутизаторов в зону work:
Сохраним изменения:
Создание виртуального интерфейса
Для исключения отправки неправильного MAC-адреса на клиентский компьютер, создадим интерфейс кластера, как loopback интерфейс. Для этого, в папке /etc/sysconfig/network-scripts, создадим файл ifcfg-lo:0, примерно следующего содержания (см. рис. 4):
Рисунок4. Настройки виртуального интерфейса.
Дополнительные сетевые настройки
Для исключения проблемы неправильного MAC-адреса в режиме direct routing и добавления возможности коммуникации с виртуальным интерфейсом, добавим в файл /etc/sysctl.conf нижеследующие ключи:
Настройка маршрутизаторов
Установка компонентов
Для создания кластера нам понадобится компонент для балансировки нагрузки – keepalived, а также компонент, обеспечивающий работу с виртуальным адресом кластера, а также балансировку на транспортном уровне – ipvsadm.
Устанавливаем необходимые компоненты:
Разрешаем автоматический старт сервисов:
Настройка firewall
Как и в предыдущей статье, будем использовать зону work – для коммуникаций с серверами приложений 1С:Предприятие, internal – для коммуникаций с компьютерами администраторов.
Для коммуникаций между роутерами используем зону home.
Далее предполагается, что базовые настройки firewall произведены в соответствии с вышекуазанной публикацией.
Настраиваем зону home:
Сохраняем изменения:
Настройка кластера
Для конфигурирования кластера, отредактируем файл /etc/keepalived/keepalived.conf
В нашем случае, ip кластера – 172.16.210.46, ip адреса нод кластера: 172.16.210.42 и 172.16.210.45. В качестве алгоритма балансировки для тестов выберем rr (round robin). В этом слкучае, каждый последующий запрос будет отправляться на ноду, отличную от ноды, на которой выполнялся последний запрос. В производственной среде имеет смысл использовать алгоритм lc (least connections), при котором запрос отправляется на ноду с наименьшим количеством соединений.
Содержимое конфигурационного файла для активного роутера (router1) и пассивного (router2), представлены ниже:
Дополнительные настройки сети
Для исключения проблемы неправильного MAC-адреса в режиме direct routing и добавления возможности коммуникации с виртуальным интерфейсом кластера, добавим в файл /etc/sysctl.conf нижеследующие ключи:
Тестирование функционала
Рестартуем рабочие сервера и маршрутизаторы.
Обратимся к кластеру из браузера. Если все настроено правильно, мы увидим примерно следующую картину (см. рис. 5).
Рисунок 5. Результат тестирования из браузера.
Запустим конфигурацию АИТП.
Изменим url сервиса для выполнения скриптов на url кластера. В нашем случае – это https://cluster.itpa.cf.
Введем нижеследующий код:
Выполним его несколько раз, через определенный промежуток времени (см. рис. 6.) и просмотрим результаты. Как можно увидеть, наш код выполняется на разных нодах кластера.
Рисунок 6. Результат тестирования из 1С:Предприятие.
Заключение
При помощи вышеприведенной методики была создана ферма рабочих серверов OneScript, которая позволяет горизонтально масштабировать нагрузку, а также обеспечивает высокую доступность сервиса.
Настоящая методика также может быть использована для развертывания любых приложений на основе http-сервисов OneScript или сервисов web-доступа к 1С:Предприятие, при соответствующей настройке нод кластера.
Надеюсь, что настоящая публикация поможет Вам в использовании конфигурации АИТП, http-сервисов OneScript или других web-приложений, в корпоративной среде.
