Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Кластер JBoss 7 — балансировка нагрузки с поддержкой Apache

Anna | 5.06.2014 | нет комментариев

В прошлой статье мы настроили репликацию сессий пользователей на все узлы кластера JBoss. Само по себе такое действие никак не улучшает отказоустойчивость, и для того, Дабы применять полученную функциональность, требуется балансировщик нагрузки, тот, что будет распределять внешние обращения между узлами кластера. Распределять нагрузку между узлами будет веб-сервер Apache, в соответствии с рекомендациями в документации по JBoss. Каждая информация в статье доступна в разных источниках, но она разрознена, и мне не попалось ни одного источника, где все было бы собрано в одном месте, с изложением решения задач, которые могут появиться на практике (лично у меня появились, следственно делюсь рецептами). Статья не претендует на полноту информации, скорее напротив — описана минимальная конфигурация. Предуготовлена как для экспертов, которых волнуют определенные конфигурации и настройки, так и для людей далеких от данной темы, но которым увлекательно, что такое кластеризация.

Всеобщие тезисы работы

Эксперты, знакомые с тезисами кластеризации, могут пропустить данный раздел. Для наглядности буду рассматривать определенную обстановку, с которой встречаются многие: присутствующая система, состоящая из одного сервера приложений, переходит на кластерное решение. Самый наилучший вариант в таких случаях — не пытаться сразу объять необхватное, а возвести минимальную работающую конфигурацию: два сервера приложений в кластере, а перед ними веб-сервер в качестве интерфейса (frontend) к заказчикам.

Схема работы дальнейшая: все запросы, ранее отправляемые непринужденно на http/https коннектор JBoss-а, сейчас обязаны обращаться к веб-серверу (Apache). Apache настраивается таким образом, Дабы «знать» о существовании «за его спиной» 2-х серверов приложений. При первом обращении заказчика к Системе, веб-сервер выбирает один из серверов приложений (Узел-1) и перенаправляет запрос к нему. Создается сессия, в нее добавляется Cookie, которая в последующем применяется веб-сервером для того, Дабы «приклеить» все дальнейшие запросы того же заказчика к выбранному серверу приложений. Узел-1, обрабатывающий запросы заказчика, при создании/изменении сессии реплицирует её состояние на остальные узлы кластера, где они и висят мёртвым грузом, пока что не принося никакой пользы.

Подробнее о Сессии

Упрощенно. Сессия — объект, создаваемый на стороне JBoss, имеющий разные признаки. Сессия имеет идентификатор, тот, что передается в браузер при создании сессии, и при всяком обращении заказчика к серверу передается браузером обратно серверу (обыкновенно, в виде Cookie). Сервер по идентификатору находит сессию и обрабатывает запрос в контексте данных обнаруженной сессии. Задача репликации в кластере — передача данных о сессии на остальные узлы таким образом, Дабы при обращении заказчика к ним, всякий иной узел сумел бы так же, как и Узел-1 обнаружить сессию (и данные в ней сохраненные) по идентификатору и обработать запрос заказчика в её контексте.

В случае «падения» Узла-1, при очередном обращении заказчика, Apache обнаруживает, что сервер недостижим, и перенаправляет запрос на иной узел (Узел-2). Вот здесь и начинает применяться тот самый «мертвый груз» — сессия, состояние которой теснее есть на всех узлах кластера. Запрос обрабатываетсяУзлом-2, и Apache «приклеивает» сессию к нему, т.е. все дальнейшие запросы пользователя сейчас сразу направляются на Узел-2.

Базовая кофигурация

Если на стороне JBoss теснее настроена репликация сессий, то дополнительных настроек не требуется, всё, что необходимо (AJP коннектор), теснее настроено в конфигурации по умолчанию. Требуется скачать и установить Apache HTTP Server (процесс установки выходит за рамки данной статьи). Каждая настройка осуществляется путем редактирования файла conf/httpd.conf.

  1. Подключение модулей. Раскоментируйте либо добавьте следующие строки:
    LoadModule proxy_module modules/mod_proxy.so
    LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
    LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
    LoadModule headers_module modules/mod_headers.so

    Модули mod_proxy.so, mod_proxy_ajp.so и mod_proxy_balancer.so требуются для балансировщика нагрузки. Если в Системе нет представления «сессия», то их довольно. Я, скажем, работал с системой, которая обрабатывала запросы посредством веб-сервисов, это единичные обращения, не связанные между собой, следственно сессии не создавались. В нашем случае есть пользователи и их сессии, следственно требуется добавить модуль mod_headers.so, тот, что дозволит отслеживать данные о сессии, передаваемые браузером.

  2. Настройка балансировки. Добавьте следующие строки:
    NameVirtualHost 192.168.1.0:80
    <VirtualHost 192.168.1.0:80>
    	Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
    	<Proxy balancer://ajp-cluster>
    		BalancerMember ajp://192.168.1.1:8009 route=node1
    		BalancerMember ajp://192.168.1.2:8009 route=node2
    		ProxySet stickysession=ROUTEID
    	</Proxy>
    	<Location />
    		ProxyPass balancer://ajp-cluster/
    	</Location>
    </VirtualHost>

    Взамен 192.168.1.0 указываете адрес Apache.
    В разделе Proxy указываете список адресов AJP-коннекторов узлов кластера, по одному вступлениюBalancerMember для всякого узла. В конфигурации JBoss 7 по умолчанию AJP-коннектор прослушивает порт 8009. Параметр route присваивает неповторимое имя узла, используемое только самим Apache, т.е. вовсе необязательно совпадение с именами, указанными при старте JBoss (параметр jboss.node.name). Огромнее ничего менять не требуется, кластер готов к запуску и тестированию.

    Подробнее о конфигурации

    Директива “Header add Set-Cookie” действует коллективно с директивой “ProxySet stickysession” дальнейшим образом. При первом обращении заказчика к Apache, позже того, как балансировщик предпочел на какой узел он будет перенаправлен, в сессию пользователя добавляется Cookie с именем “ROUTEID“, значением которой является идентификатор выбранного узла (node1/node2 в конфигурации выше). При последующих обращениях заказчика, Apache теснее не нужно «думать» о том, какой был ранее выбран узел, Cookie очевидно информирует веб-серверу на какой узел следует перенаправить запрос. Директива «Header» ответственна за существование Cookie в сессии, а директива «ProxySet stickysession» за применение ее при маршрутизации для «приклеивания» сессии к определенному узлу. Если ваш сервер не работает с сессиями (скажем, как в моем примере выше, только веб-сервисы), то директивы «Header» и ProxySet не необходимы.

    JSESSIONID

    Во многих примерах конфигурации предлагается применять в качестве маркера узла идентификатор сессии JSESSIONID. Это кажется логичным, т.к. такой идентификатор применяется в большинстве веб-приложений на Java. Пример с apache.org:

    ProxyPass /test balancer://mycluster stickysession=JSESSIONID|jsessionid scolonpathdelim=On
    <Proxy balancer://mycluster>
    BalancerMember http://192.168.1.50:80 route=node1
    BalancerMember http://192.168.1.51:80 route=node2
    </Proxy>

    Сразу скажу: для JBoss это не работает, по крайней мере, в конфигурации по-умолчанию. Данный способ полагает, что значение Cookie с именем JSESSIONID, сформированное на стороне сервера приложений, состоит из 2-х частей: идентификатор сессии дополняется идентификатором сервера, они разделяются точкой. JBoss 7 формирует примитивную Cookie JSESSIONID, которая содержит только идентификатор сессии, значение которого сгенерировано случайным образом и не несет никакой смысловой нагрузки.
    Таким образом, основные различия от описанной мною конфигурации следующие:

    • В описанной в статье конфигурации идентификатор узла и идентификатор сессии находятся в различных Cookie, тут два значения объединены в одну Cookie.
    • В описанной в статье конфигурации идентификатор узла формируется на стороне балансировщика (разумно: кто использует, тот и формирует), а идентификатор сессии на стороне сервера приложений (тот же правило: идентификатор сессии необходим JBoss-у, а не Apache). Тут же оба значения генерируются на стороне сервера приложений (либо веб-сервера на бэкенде).

 

Настройка SSL (HTTPS)

Если до кластеризации вы применяли шифрование при обмене данными с заказчиком, общаясь с ним по протоколу HTTPS, то настройки сертификатов осуществлялись на стороне JBoss, в конфигурации HTTPS-коннектора. При переходе на кластерное решение сертификатами должен управлять Apache.

Всеобщие тезисы

Процесс дальнейший: HTTPS-запросы от заказчика поступают на веб-сервер Apache, расшифровываются и передаются серверу приложений в открытом виде посредством протокола AJP. Результат от сервера приложений передается на веб-сервер также в открытом виде, шифруется там и передается заказчику по протоколу HTTPS. Таким образом, между Apache и JBoss существует так называемая «демилитаризованная зона», т.е. закрытое от внешнего неавторизованного доступа окружение, в котором между серверами настроены доверительные отношения, не требующие дополнительной охраны от несанкционированного доступа на прикладном ярусе. Доступным извне должен быть только Apache, по HTTPS порту (обыкновенно, 443), все остальное должно быть наглухо закрыто.

Настройки веб-сервера в conf/httpd.conf:

  1. Прослушка порта 443. Веб-сервер Apache в конфигурации по умолчанию «слушает» только порт 80. Для того, Дабы он стал прослушивать порт 443, следует добавить строчку:
    Listen 443
  2. Подключение модулей. Раскоментируйте либо добавьте следующую строчку:
    LoadModule ssl_module modules/mod_ssl.so
  3. Настройка балансировки. Добавьте следующие строки:
    NameVirtualHost 192.168.1.0:443
    
    <VirtualHost 192.168.1.0:443>
    	Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
    	<Proxy balancer://ajp-cluster>
    		BalancerMember ajp://192.168.1.1:8009 route=node1
    		BalancerMember ajp://192.168.1.2:8009 route=node2
    		ProxySet stickysession=ROUTEID
    	</Proxy>
    	<Location />
    		ProxyPass balancer://ajp-cluster/
    	</Location>
    
    	ProxyRequests off
    	SSLEngine on
    	SSLCertificateFile c:/Apache2/conf/my.cer
    	SSLCertificateKeyFile c:/Apache2/conf/my.key
    </VirtualHost>
    

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

Задачи с сертификатами и их решение

При настройке шифрования на стороне JBoss, требовался один файл, содержащий ключ и сертификат, скажем, в формате PKCS#12. Apache требует распределения на два файла, в одном файле сертификат, в ином — закрытый ключ. Помимо этого, Apache имеет два ограничения:

  1. Распознается только формат PEM. Узнать, соответствует ли ваш ключ этому формату, дозволено открыв файл ключа текстовым редактором. В оглавлении обязаны присутствовать строки “—–BEGIN PRIVATE KEY—–” и “—–END PRIVATE KEY—–”, длина строк между ними не должна превышать 64 символа. То же касается сертификата, со строками, соответственно “—–BEGIN CERTIFICATE—–” и “—–END CERTIFICATE—–”.
  2. Сборка Apache под ОС Windows не может открывать хранилища ключей, защищенные паролем.

Все вышеперечисленные задачи решаются при помощи утилиты Openssl. Из вашего файла хранилища ключа и сертификата, используемого в JBoss, следует извлечь ключ и сертификат в отдельные файлы, осуществив при этом конвертацию в необходимый формат и сняв охрану паролем. Вот пример конвертации ключа из формата PKCS#12 (поддерживаются и другие форматы, Google вам в поддержка):

openssl pkcs12 -nocerts -nodes -in C:key.p12 -out C:Apache2confmy.key
openssl pkcs12 -clcerts -nokeys -nodes -in C:key.p12 -out C:Apache2confmy.cer

ВНИМАНИЕ! Не позабудьте удалить со своего компьютера полученный файл my.key позже переноса его на индустриальный сервер, т.к. он ничем не защищен и может быть скомпрометирован.

 

Завершение

Позже использования описанного в статье решения, в тезисе, дозволено вообще удалить из настроек JBoss изложение коннекторов HTTP/HTTPS за ненадобностью, т.к. сейчас все внешние обращения будут поступать через AJP коннектор. Это приметно повысит безопасность сервера, исключительно для сканирующих утилит, которые специальное внимание уделяют этим протоколам.

PS

Предлагаемый вариант кластеризации Отчасти решает задачи балансировки нагрузки и отказоустойчивости. Для полновесной конфигурации тут не хватает кластеризации

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB