WebSphere Liberty: Построение высокодоступной среды

В этой статье я расскажу о своем опыте работы с WebSphere Liberty, о нюансах настройки, и о том как построить масштабируемую и высокодоступную среду на платформе Liberty.

О WebSphere Liberty

С момента своего появления, WAS Liberty проделал путь от быстрого и легковесного сервера для разработки до динамичного и удобного Java EE сервера приложений, подходящего для использования в продакшене и облаке.

WAS Liberty создан на основе ПО с открытым исходным кодом (~40%) и технологий IBM. Liberty имеет легкий дистрибутив (max 200mb), быстрое время запуска (несколько секунд), и активируемые по необходимости функции (features). То есть, нет необходимости использовать полный стек функциональностей JEE, можно выбирать только необходимые приложениям функции (например, servlet-3.0, jdbc-4.1). Изменение конфигурации сервера, например, активация подобных функций, происходит динамически, т.е. без перезапуска сервера. Можно сказать, что Liberty – это своеобразный контейнер от IBM. Так же стоит отметить, что IBM использует Liberty или позволяет заменить им традиционный WAS в других продуктах, например, BPM и ODM. Все новые фичи будут сначала выпускаться для Liberty, а потом уже для традиционного WAS.

Процесс настройки сервера с Liberty становится удобным и легким, благодаря простому, но гибкому XML-формату конфигурационного файла server.xml. Обычно после создания сервера, server.xml имеет вид:

Немного позже мы рассмотрим как с ним работать.

Внутренняя архитектура WebSphere Liberty.

Внутри WebSphere Liberty представляет собой OSGi фреймворк, ядро Liberty (Kernel) и дополнительные функции (Features), работающие в единой JVM. Код функций и большая часть кода ядра функционируют как модули (bundles) в OSGi фреймворке. Общая схема архитектуры Liberty представлена ниже.

libertyProfileArchitectureРассмотрим как устроено ядро Liberty.

Лаунчер (launcher) ядра производит начальную загрузку системы и запускает OSGi фреймворк. Далее выполняется парсинг конфигурации и подключенные функции загружаются менеджером функций (Feature Manager). Ядро широко использузует OSGi сервисы для предоставления высокодинамичной среды. Так, OSGi сервис Configuration Admin управляет конфигурацией системы, а служба Declarative Services управляет жизненным циклом системных сервисов. Сервис File Monitor обнаруживает изменения приложений и файла конфигурации. Сервис Logging Service производит запись сообщений и информации для отладки в файл. Схема ядра Liberty представлена ниже.

libertyKernelРассмотрим как работает Feature Manager.

Функции (features) могут быть определены в файле server.xml и других подключаемых файлах конфигурации. Сервис управления конфигурацией (Configuration Admin) читает эти файлы и вводит конфигурацию в менеджер функций (Feature Manager). Менеджер функций производит маппинг функции со соответствующим списком бандлов, которые обеспечивают данную функцию. Модули (бандлы) устанавливаются в OSGi фреймворк и запускаются. Благодаря этому механизму возможно динамическое изменение функций, их добавление и удаление во время работы сервера. Схема работы менеджера функций представлена ниже.

featureManagementГлавный файл конфигурации – это server.xml, однако, вы можете создать структуру отдельных конфигурационных файлов, которые будут подключены в server.xml с помощью директивы “include”.

Изначально Liberty предоставляет конфигурацию по умолчанию, поэтому, когда вы изменяете конфигурацию, например, указываете необходимые фичи и параметры, служба управления конфигурацией (Configuration Admin) производит проверку вашей конфигурации и применяет ее над системными настройками по умолчанию. Схема управления конфигурацией представлена ниже.

configurationManagementСлужба Declarative Services используется для разложения функции на дискретные сервисы, которые активируются только по необходимости. Это позволяет среде выполнения сохранять небольшой объем и быстро запускаться. Объявленные сервисы добавляются в реестр сервисов OSGi (OSGi service registry) и зависимости между сервисами решаются без загрузки классов реализации.

Мы рассмотрели внутреннее устройство WebSphere Liberty, теперь рассмотрим какие бывают поставки Liberty и чем они отличаются.

Варианты поставок и лицензирование

Liberty представлено в 3 версиях, это WAS Liberty Core, WAS Base и WAS Network Deployment (ND). То есть в лицензии Base и ND включен как традиционный WAS, так и Liberty. Редакции WAS отличаются между собой набором функций. Лучше всего это отражено в таблице:

was_compare_editions_v2_7-28-16-1

На скрине ниже детально отражено, какие фичи Liberty доступны в различных редакциях WAS:

liberty_features_8-5-5-6

К сожалению, купить лицензии Liberty Base или Liberty ND отдельно от соответствующих традиционных версий WAS невозможно.

Версия Liberty для разработчиков, которую можно скачать с WASdev, стоит особняком.
На самом деле она не только для разработки, ее можно использовать в QA и Prod средах бесплатно, при условии, что суммарный размер хипа всех JVM на тестовом и боевом окружениях не будет превышать 2 GB.
Бесплатная лицензия этой версии Liberty включает в себя набор фич, соответствующий WAS Base, поддерживающий полную функциональность Java EE.
Так же можно скачать “облегченную” версию Liberty – это Liberty Java EE 7 Web Profile.

Подробнее о лицензировании версии Liberty для разработчиков можно узнать здесь.

В этой статье мы рассмотрим как развернуть отказоустойчивую, масштабируемую и высокодоступную среду WebSphere Liberty, с контроллером, кластерами, динамическим роутингом запросов и автомасштабированием:

Это возможно только если вы работаете с поставкой WAS ND, отметим отличительные особенности этой редакции:

  • Collective Controller – управляющая компонента, необходимая для объединения серверов в коллектив (аналог cell), настройки серверов и мониторинга. Единая точка управления серверами приложений;
  • Кластеры (Clusters) – возможно объединение серверов в кластеры, с возможностью репликации сессий;
  • Динамический роутинг (Dynamic Routing) – динамическая маршрутизация запросов IBM HTTP Server + Plug-in между серверами приложений. То есть IHS сам понимает на каких серверах какое приложение работает и направляет туда запросы; Активный балансировщик;
  • Переключение серверов в режим обслуживания (Maintenance mode) , когда IHS + Plug-in перестает отправлять запросы на сервер, при этом сам сервер запущен и с ним можно проводить технологические работы;
  • Автомасштабирование (Auto Scaling) – когда при изменении параметров CPU Usage/Memory Usage/Heap Usage поднимаются/опускаются дополнительные сервера приложений в кластере.
Установка WebSphere Liberty

1. Т.к. в поставке Liberty нет своей Java , то ее необходимо поставить (если нет в системе) и проверить:

[root@wlp-host01 bin]# java -version
openjdk version “1.8.0_51″
OpenJDK Runtime Environment (build 1.8.0_51-b16)
OpenJDK 64-Bit Server VM (build 25.51-b03, mixed mode)

Для работы Liberty не обязательно нужна Java от IBM, можно использовать Java от Oracle. Однако, с Java от IBM Liberty работает производительнее, к тому же есть полезные параметры, применимые только в Java от IBM. Скачать актуальную версию IBM Java SE можно здесь.

2. Устанавливаем IBM Installation Manager (IM) на все четыре хоста: wlp-host01, wlp-host02, wlp-host03, wlp-host04. Скачать IM можно здесь. Копируем дистрибутивы Liberty на эти сервера.
3. Устанавливаем Liberty через IM:

  • В репозитории добавляем скаченные дистрибутивы Liberty и актуального фикса;
  • В процессе установки выбираем дополнительные Addons и Features.
  • Поробнее об установке через IM здесь.
Создание коллектива (collective) и кластера AppCluster1

Создаем первый сервер на хосте wlp-host01:

Создаем второй сервер на хосте wlp-host02:

Создаем сервер wlp03server1 на хосте wlp-host03:

На хосте wlp-host04 создаем сервер Collective Controller’a:

В server.xml контроллера добавляем:

Изменяем description, добавляем host="*".

В collective-create-include.xml добавляем:

Это простой способ создания учетной записи для работы с AdminCenter.

Запускаем сервер Controller1:

В server.xml добавляем:

Проверяем, что AdminCenter работает:

https://wlp-host04:9443/adminCenter/

Для редактирования server.xml через AdminCenter добавляем:

Добавляем сервер приложений wlp01server1 в collective:

В server.xml wlp01server1 добавляем:

Добавляем сервера wlp02server1 и wlp03server1 в collective, выполняем команды:

В server.xml wlp02server1 и wlp03server1 добавляем строчку:

Создание кластера AppCluster1

В server.xml серверов wlp01server1, wlp02server1 и wlp03server1 добавляем:

Запускаем сервера:

Статический кластер AppCluster1 создан.

Создание динамического (auto scaled) кластера ElasticCluster

Создаем сервера приложений wlp01server2, wlp02server2 и wlp03server2:

Добавляем эти сервера в collective:

В server.xml серверов добавляем строчку:

Создаем кластер, добавляем в server.xml:

Запускаем сервера wlp01server2, wlp02server2 и wlp02server3.

В контроллере активируем фичу scalingController:

В каждом участнике динамического кластера активируем фичу scalingMember:

И там же прописываем

Создаем конфигурационный файл политики масштабирования scalingPolicy.xml, например:

В контроллере подключаем файл с описанием политики масштабирования:

Перезапускаем контроллер. После запуска он остановит сервера wlp02server2 и wlp02server3 согласно политике.

В политике мы описали, что в кластере ElasticCluster всегда должен быть запущен один сервер. Два других сервера будут запускаться когда в кластере использование хипа, CPU или RAM превысит 95%, и останавливаться когда эти параметры будут ниже 85%.

Настройка динамической маршрутизации (dynamic routing) http-нагрузки

В контроллере подключаем фичу

На хосте контроллера выполняем команду для генерации плагина plugin-cfg.xml и хранилища ключей plugin-key.jks:

Файлы будут помещены в директорию из которой производилось выполнение команды.

Копируем файлы plugin-cfg.xml и plugin-key.jks на хост HTTP сервера, например в директорию /tmp
На хосте HTTP сервера выполняем команды для преобразования хранилища ключей plugin-key.jks в CMS формат, который поддерживает WebSphere Plug-in, и устанавливаем сертификат по умолчанию:

Копируем полученные файлы plugin-key.kdb, plugin-key.rdb, и plugin-key.sth в директорию <value of the --pluginInstallRootargument>/config/<web server name>.

Копируем plugin-cfg.xml в директорию, указанную в директиве WebSpherePluginConfig в httpd.conf HTTP сервера, запускаем HTTP сервер.
Теперь технология Intelligent Management может динамически направлять HTTP запросы в среду Liberty.

Важно:
1. Перед перезапуском HTTP сервера убедиться, что контроллер запущен.
2. Перезапуск контроллера при работающем HTTP сервере не оказывает влияния на маршрутизацию запросов.
3. Если в схеме развертывания несколько коллективов, то:
Generating a plugin-cfg.xml to route to multiple collectives

Настройка удаленного доступа к конфигурации серверов

Это необходимо,  если мы хотим редактировать конфиг файлы серверов через AdminCenter и чтобы Liberty работал не из-под root, а, например, под пользователем wlp.
Останавливаем сервера приложений.
Создаем пользователя wlp, из-под которого будет запукаться Liberty.

В server.xml серверов приложений добавляем:

На каждом хосте wlp-host01, wlp-host02, wlp-host03, wlp-host04 выполняем следующее:

Запускаем сервера приложений под пользователем wlp.

Настройка среды Liberty

– В директории сервера создаем файл server.env – в нем можно устанавливать переменные среды, например:

log_root=/var/log/liberty/apps/
JAVA_HOME=/opt/IBM/java/jre

– В директории сервера создаем файл jvm.options -в нем можно устанавливать параметры JVM, например:

-Xmx128m
-verbose:gc

Что бы эти настройки применились ко всем серверам на этом хосте, необходимо разместить файлы server.env и jvm.options
в директории <wlp.install.directory>/etc/

– До версии Java 8, процесс сервера запускался с ключом -XX:MaxPermSize=256m по умолчанию.
Начиная с версии Java 8 VM больше не поддерживается опция MaxPermSize.
С версии WLP 8.5.5.6 при создании сервера автоматически создается файл server.env, с параметром
WLP_SKIP_MAXPERMSIZE=true для того, что бы игнорировать MaxPermSize=256m.

Для того, что бы все сервера приложений на данном хосте использовали этот параметр,
можно вручную создать файл server.env в директории <wlp.install.directory>/etc/, с параметром:

WLP_SKIP_MAXPERMSIZE=true

– Удалить сервер из коллектива:

Настройки логирования

Например, мы хотим вести message.log в 5 файлов по 10 MB, для этого в server.xml необходимо добавить:

Трассировка

Пример трассировки веб контейнера:

Подробнее о трассировке можно узнать здесь.

VN:F [1.9.22_1171]
Rating: 4.8/5 (5 votes cast)
Метки: , , , ,
Опубликовано в WebSphere Application Server, Основы, Тюнинг
1 комментарий на “WebSphere Liberty: Построение высокодоступной среды
  1. Sergey Kirsanov Sergey Kirsanov:

    Дополнение к настройкам среды Liberty:
    Пример HealthPolicy для перевода в режим обслуживания (MaintenanceMode) серверов в кластере mycluster1 при превышении времени ответа 10 секунд:

    <healthPolicy id=”myHealthPolicy” >
    <cluster clusterName=”mycluster1″/>
    <excessiveResponseTime responseTime=”10s”/>
    <action action=”enterMaintenanceMode”/>
    </healthPolicy>

    VN:F [1.9.22_1171]
    Rating: +3 (from 5 votes)

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: