Создание высокодоступной фермы рабочих серверов OneScript в ОС Centos 7

Введение

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

firewall-cmd –zone=work –add-source=172.16.210.47/32
firewall-cmd –zone=work –add-source=172.16.210.48/32

Сохраним изменения:

firewall-cmd –runtime-to-permanent
firewall-cmd --reload

Создание виртуального интерфейса

Для исключения отправки неправильного MAC-адреса на клиентский компьютер, создадим интерфейс кластера, как loopback интерфейс. Для этого, в папке /etc/sysconfig/network-scripts, создадим файл ifcfg-lo:0, примерно следующего содержания (см. рис. 4):

Рисунок4. Настройки виртуального интерфейса.

Дополнительные сетевые настройки

Для исключения проблемы неправильного MAC-адреса в режиме direct routing и добавления возможности коммуникации с виртуальным интерфейсом, добавим в файл /etc/sysctl.conf нижеследующие ключи:

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.ip_forward = 1

Настройка маршрутизаторов

Установка компонентов

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

Устанавливаем необходимые компоненты:

yum install ipvsadm
yum install keepalived

Разрешаем автоматический старт сервисов:

systemctl enable ipvsadm
systemctl enable keepalived

Настройка firewall

Как и в предыдущей статье, будем использовать зону work – для коммуникаций с серверами приложений 1С:Предприятие, internal – для коммуникаций с компьютерами администраторов.

Для коммуникаций между роутерами используем зону home.

Далее предполагается, что базовые настройки firewall произведены в соответствии с вышекуазанной публикацией.

Настраиваем зону home:

firewall-cmd –zone=home –add-source=172.16.210.47/32
firewall-cmd –zone=home –add-source=172.16.210.48/32
firewall-cmd –zone=home –add-rich-rule=’rule protocol value=”vrrp” accept’

Сохраняем изменения:

firewall-cmd –runtime-to-permanent
firewall-cmd –reload

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

Для конфигурирования кластера, отредактируем файл /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), представлены ниже:

! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.16.210.46/24
    }
}

virtual_server 172.16.210.46/24 443 {
    delay_loop 1
    lb_algo rr
    lb_kind DR
    protocol TCP

    real_server 172.16.210.45  443 {
              
        TCP_CHECK {
           
        }
    }
    real_server 172.16.210.42 443 {
        
        TCP_CHECK {
            
        }
    }
}

! Configuration File for keepalived

global_defs {
   router_id LVS_DEVEL
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        172.16.210.46/24
    }
}

virtual_server 172.16.210.46/24 443 {
    delay_loop 1
    lb_algo rr
    lb_kind DR
    protocol TCP

    real_server 172.16.210.42 443 {
               
        TCP_CHECK {
        }
    }
    real_server 172.16.210.45 443 {
        
        TCP_CHECK {
        }
    }
}

Дополнительные настройки сети

Для исключения проблемы неправильного MAC-адреса в режиме direct routing и добавления возможности коммуникации с виртуальным интерфейсом кластера, добавим в файл /etc/sysctl.conf нижеследующие ключи:

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.ip_forward = 1

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

Рестартуем рабочие сервера и маршрутизаторы.

Обратимся к кластеру из браузера. Если все настроено правильно, мы увидим примерно следующую картину (см. рис. 5).

Рисунок 5. Результат тестирования из браузера.

Запустим конфигурацию АИТП.

Изменим url сервиса для выполнения скриптов на url кластера. В нашем случае – это https://cluster.itpa.cf.

Введем нижеследующий код:

ТекДок = Новый ТекстовыйДокумент;
ТекДок.Прочитать("//var/www/html/index.aspx");
Результат = ТекДок.ПолучитьТекст();

Выполним его несколько раз, через определенный промежуток времени (см. рис. 6.) и просмотрим результаты. Как можно увидеть, наш код выполняется на разных нодах кластера.

Рисунок 6. Результат тестирования из 1С:Предприятие.

Заключение

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

Настоящая методика также может быть использована для развертывания любых приложений на основе http-сервисов OneScript или сервисов web-доступа к 1С:Предприятие, при соответствующей настройке нод кластера.

Надеюсь, что настоящая публикация поможет Вам в использовании конфигурации АИТП, http-сервисов OneScript или других web-приложений, в корпоративной среде.