Спасительный суперкластер: Часть 1. Способы достижения экстремальной масштабируемости приложения

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Кевин Кепрос, инженер-консультант по программному обеспечению, IBM
Д-р Дебасиш Банерджи, консультант по WebSphere, IBM

10.08.2009

Представьте себе, что у вас есть приложение, к которому обращается очень много клиентов. Уже в силу большого числа клиентов или клиентских запросов, обслуживаемых этим приложением, чтобы справляться с такой нагрузкой, потребуется множество серверов приложений. Стандартное решение такой задачи заключается в использовании кластеров IBM WebSphere Application Server Network Deployment, но что, если построить достаточно большой кластер для требуемой нагрузки не удается?

Из журнала IBM WebSphere Developer Technical Journal.

Введение

Масштабируемость приложений – важный фактор качества обслуживания для большинства корпоративных конфигураций программного обеспечения. Для достижения масштабируемости приложения Java EE корпоративного уровня обычно развертываются и исполняются на кластерах IBM WebSphere Application Server Network Deployment. Однако на практике размер кластера может быть ограничен. Что если кластер нельзя сделать достаточно большим, чтобы справляться с требуемой нагрузкой?

Эта статья из двух частей знакомит с полезным методом достижения экстремальной масштабируемости приложения на WebSphere Application Server, который мы назовем суперкластером. Первая часть статьи знакомит читателей с методом построения «суперкластера» с применением HTTP-плагина и прокси-сервера WebSphere Proxy Server. Вторая часть добавляет к этому технологии DMZ Secure Proxy Server для WebSphere Application Server, маршрутизатора по требованию (on demand router - ODR) IBM WebSphere Virtual Enterprise и IBM WebSphere eXtreme Scale.

В начало

Кластеры

Для достижения масштабируемости приложения Java EE корпоративного уровня обычно развертываются на кластерах IBM WebSphere Application Server Network Deployment (далее мы будем называть это сетевой установкой [Network Deployment]). Клиентские запросы маршрутизируются в пределах кластера, так что нагрузка распределяется между всеми участвующими процессами сервера приложений.

• Привязка (affinity)

  Если приложение не зависит от предыстории, запросы могут направляться любым элементам кластера сетевой установки, содержащим установленное приложение (привязка не требуется). Однако в зависимости от протокола и конструкции приложения клиентские запросы могут быть связаны с определенными элементами кластера сетевой установки. Например, сеанс HTTP мог быть создан на сервере в составе кластера, который обслужил самый первый запрос, так что все последующие запросы от этого клиента должны пересылаться на тот же самый сервер. Примерами такой привязки могут служить привязка HTTP-сеанса для протокола HTTP, привязка SIP-сеанса для протокола SIP, транзакционная привязка для протокола IIOP и т.д. Большинство маршрутизаторов способно сохранять соответствующие привязки при передаче запросов элементам кластера (серверам приложений).

• Аварийное переключение

  Кроме масштабируемости, развертывание приложений на кластере сетевой установки может обеспечить высокую готовность. В случае отказа одного из членов кластера маршрутизатор может направлять запросы к оставшимся. Использование механизма восстановления сеансов обеспечивает прозрачное аварийное переключение даже при наличии сеансов HTTP или SIP.

• Администрирование

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

Ограничение размера кластера

В IBM WebSphere Application Server V6.0 появился компонент, называемый менеджером высокой готовности (high availability manager - HAM). Наряду с этим компонентом появился новый атрибут конфигурации - основная группа (core group). Описание менеджера высокой готовности и всей связанной с ним функциональности выходит за рамки настоящей статьи, но правила образования основной группы влияют на предельные размеры кластера, и здесь требуется элементарное понимание основных групп:

• Основная группа

  Основная группа – это статический домен высокой готовности, состоящий из набора тесно связанных процессов WebSphere Application Server. Каждый процесс в ячейке WebSphere Application Server является членом основной группы. Процессы основной группы открывают сетевые соединения для всех остальных и используют эти соединения для контроля и определения того, работает ли процесс, остановлен или дал сбой. Все члены основной группы соединены друг с другом в топологии full meshed (каждый с каждым), как показано на рисунке 2.

  
  
  Рисунок 2. Процессы в основной группе WebSphere Application Server
  
  
  

  Такая тесная связь между JVM гарантирует короткую задержку приложений (всего один переход по сети между любыми двумя членами) и быстрое выявление отказов. Однако топология «каждый с каждым» налагает определенные ограничения на масштабируемость основной группы. Так, основные группы не масштабируются в той же степени, что и ячейки, и крупные ячейки приходится подразделять на несколько сетевых групп. В зависимости от требований конкретной среды WebSphere Application Server в отношении коммуникаций между основным группами отдельные основные группы могут быть соединены при помощи (мостовой службы основных групп (core group bridge service, CGBS).

  
  
  Рисунок 3. Несколько основных групп в большой ячейке WebSphere
  
  
  
• Правила создания основных групп

  Правильно оформленные основные группы должны создаваться с учетом следующих правил образования основных групп, изложенных в документации на странице WebSphere Application Server Information Center (см. Ресурсы). Одно из этих правил гласит, что кластер WebSphere Application Server не должен перекрывать основную группу. Иными словами, все члены кластера должны быть членами одной и той же основной группы. Это правило означает, что максимальный размер кластера WebSphere Application Server явно ограничен максимальным размером основной группы.

  
  
  Рисунок 4. Кластер должен быть подмножеством основной группы
  
  
  
• Предельный размер основной группы

  Слишком большое количество членов основной группы может помешать ее правильному функционированию. Точное предельное число членов основной группы зависит от нескольких факторов, включая доступность ресурсов ЦП, ресурс памяти, полосу пропускания сети, число и тип приложений и др. Поэтому определить абсолютный предел невозможно. Однако для целей планирования IBM предлагает следующие рекомендации:

  • WebSphere Application Server V6.0.2: при приближении числа членов к 50 рассмотрите возможность организации несколько основных групп
  • WebSphere Application Server V6.1 или V7.0: при приближении числа членов к 100 рассмотрите возможность организации несколько основных групп

  Помните, что это просто рекомендации, и только тестирование в вашей собственной топологии может показать, каков ее точный предел. И все же эти рекомендации предполагают, что кластер Сетевой Установки должен быть ограничен максимальным размером в 50 или 100 членов.

Дилемма

Вы убедились, что максимальный размер кластера сетевой установки явно ограничен максимальным размером основной группы и что поэтому кластер не должен превышать максимального размера в 50 или 100 членов в зависимости от оборудования, топологии, приложений и т.п. Это значительный размер, который обеспечивает достаточную масштабируемость для большинства приложений. Но что если вашему приложению требуется экстремальная масштабируемость? Что если требование масштабируемости приложения диктует размеры кластера, превышающие прямое ограничение? Как развернуть приложение на таком количестве экземпляров сетевой установки, сохранив большую часть преимуществ для администрирования, которые дает развертывание в кластере?

Ответом может служить суперкластер.

В начало

Суперкластер

Требования масштабируемости приложений нечасто превышают предел для одного кластера WebSphere Application Server, но это может случиться. При таком сценарии одним из методов преодоления предельного размера кластера может быть суперкластер, или топология "кластера кластеров". Суперкластер – это иерархический кластер, который можно считать обобщением классического кластера WebSphere Application Server.

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

• принадлежит к своей собственной основной группе
• содержит разумное число членов.

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

• Развернуть приложение на нескольких кластерах (кластере кластеров).
• Использовать подходящий маршрутизатор для распределения клиентских запросов таким образом, чтобы с точки зрения клиента двухуровневая иерархия кластеров казалась традиционным одноуровневым кластером WebSphere Application Server.

Очевидно, что суперкластеры тоже накладывают некоторые ограничения:

• В настоящее время метод суперкластеров может применяться только к протоколу HTTP, но не к другим протоколам, таким как IIOP или SIP.
• Для протокола HTTP некоторые маршрутизаторы могут автоматически пересылать запросы к приложениям, развернутым на нескольких кластерах, тогда как другие маршрутизаторы требуют ручного изменения данных маршрутизации, чтобы поддерживать распределение клиентских запросов между приложениями, развернутыми на нескольких кластерах.
• В отличие от развертывания приложения на традиционном кластере, на суперкластере это не обязательно одношаговый процесс.

Например, предположим, что приложение, чтобы справляться с требуемой клиентской нагрузкой, должно быть развернуто на кластере со 120 членами. Для данного примера можно создать три новые основные группы, из этих основных групп создать кластеры по 40 членов в каждом и развернуть приложение на этих трех кластерах. В предположении использования привычного плагина маршрутизатора HTTP результирующая топология суперкластера будет выглядеть примерно как на рисунке 6.

Как уже говорилось, для суперкластерной топологии можно использовать разные виды маршрутизаторов. В следующем разделе подробно рассказывается о том, как сконфигурировать и использовать маршрутизаторы разных типов, а также о связанных с ними ограничениях. Все примеры основаны на версии WebSphere Application Server 7.

В начало

HTTР-плагин

В этом разделе объясняется, как установить и настроить суперкластер, если маршрутизатор представляет собой HTTP-плагин WebSphere Application Server. Рассмотрим простой пример из двух кластеров, как на рис. 7.

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

Для конфигурирования топологии суперкластера с маршрутизатором на основе HTTP-плагина необходимо выполнить следующие основные шаги:

1. Создать кластер WebSphere Application Server.
2. Установить на кластер приложение.
3. Протестировать и проверить приложение.
4. Создать дополнительные кластеры WebSphere Application Server.
5. Отобразить модули приложения на каждый кластер.
6. Сгенерировать файл HTTP-плагина (plugin-cfg.xml).
7. Отредактировать файл plugin-cfg.xml, чтобы запросы маршрутизировались в пределах нескольких кластеров.
8. Скопировать модифицированный файл plugin-cfg.xml в подходящее место на Web-сервере.

Большая часть этих шагов – стандартные задачи администрирования WebSphere Application Server (создать кластер, установить приложение, сгенерировать плагин и т.п.), и инструкции для решения этих задач хорошо документированы на странице WebSphere Application Server Information Center. Однако пара из этих шагов – а именно, шаги 5 и 7, - могут потребовать некоторых пояснений. Рассмотрим эти «менее знакомые» шаги на следующем простом примере.

Отображение модулей приложения на несколько кластеров

Рассмотрим два кластера WebSphere Application Server, называемых Cluster1 и Cluster2:

• Каждый кластер содержит по два члена (рисунок 8).
  
  Рисунок 8. Топология из двух кластеров
  
  
  
• "Ping" (рисунок 9) – пример приложения Java EE, развернутого на кластере Cluster1.
  
  Рисунок 9. Приложение Ping
  
  
  
• Задача в том, чтобы отобразить модули приложения Ping на оба кластера Cluster1 и Cluster2. Это достигается путем изменения страницы конфигурации приложения Ping с консоли администратора. Для администрирования модулей приложения выберите ссылку Manage Modules на странице конфигурации приложения Ping (рисунок 10).
  
  Рисунок 10. Конфигурация приложения Ping
  
  
  
• На панели конфигурации Manage Modules (рисунок 11) можно отобразить модули приложения на некоторые или все конфигурируемые кластеры и серверы. Для этого:
  1. Выберите нужные модули.
  2. Выберите один или более кластеров или серверов (совет: чтобы выбрать несколько целей, удерживайте клавишу CTRL).
  3. Нажмите кнопку Apply.
  4. Проверьте соответствия, и если все правильно, нажмите OK.
  5. Сохраните и синхронизируйте изменения.
  
  
  Рисунок 11. Приложение Ping – управление модулями
  
  
  

Проследите за тем, чтобы модуль Web-приложения, кроме двух кластеров, отображался на Web-сервер. В данном примере Web-сервер сконфигурирован как неуправляемый узел, и для администрирования Web-сервера используется WebSphere Application Server.

На рисунке 11 видно, что модули приложения Ping связаны с обоими конфигурируемыми кластерами, Cluster1 и Cluster2. Когда модули приложения отображены на несколько кластеров, можно продолжить процесс, сгенерировав и отредактировав файл plugin-cfg.xml, как описано ниже.

Редактирование файла plugin-cfg.xml

После того как модули приложения отображены на несколько кластеров, на следующем шаге нужно сгенерировать файл конфигурации плагина (plugin-cfg.xml), который используется кодом плагина HTTP для маршрутизации запросов HTTP. Если вы пользовались плагином HTTP, то должны быть знакомы с процессом генерации файла его конфигурации. В любом случае это хорошо документированный процесс, и здесь мы не будем его подробно рассматривать. Вкратце, на консоли администратора WebSphere Application Server есть опция для генерации этого файла, исходя из сконфигурированной топологии. На рисунке 12 изображен нужный фрагмент файла plugin-cfg.xml, сгенерированный по топологии развертывания приложения, который отображает приложение Ping на оба конфигурируемых кластера. Заметьте, что файл plugin-cfg.xml содержит определение двух кластеров, по два члена в каждом.

Плагин маршрутизатора HTTP принимает решения, основываясь на клиентских запросах (URL) и информации, содержащейся в файле plugin-cfg.xml. Клиентский запрос передает плагину маршрутизатора HTTP следующую информацию:

• Имя хоста
• Порт
• URI

Плагин HTTP анализирует содержание файла plugin-cfg.xml в поисках соответствующей цели, которая может должным образом обработать клиентский запрос. Маршрутизатор HTTP передает запрос первой подходящей цели, которую находит. В кластере HTTP-маршрутизатор передает клиентские запросы всем элементам Server, расположенным внутри элемента ServerCluster. Маршрутизатор не проверяет, действительно ли сервер(ы) принадлежат к сконфигурированному кластеру WebSphere Application Server. При маршрутизации запросов HTTP-маршрутизатор использует заданную стратегию LoadBalance для распределения нагрузки при сохранении привязки сеансов.

Главная цель редактирования файла plugin-cfg.xml заключается в том, чтобы заставить HTTP-плагин «верить», что все члены иерархического (супер) кластера принадлежат к традиционному (одноуровневому) кластеру. Такое редактирование предусматривает следующие шаги:

1. Определение кластера, который будет использоваться для обработки запросов приложения по умолчанию.
2. Копирование записей, относящихся к серверам из другого кластера (кластеров), в кластер из файла plugin-cfg.xml, который обрабатывает клиентские запросы по умолчанию.

Простейший способ определить, какой кластер следует выбрать, это простое тестирование приложения. Несмотря на то, что модули приложения отображены на несколько кластеров, по умолчанию только один из кластеров будет использоваться для обслуживания запросов приложения. Обычно это последний кластер, указанный в plugin-cfg.xml. Когда известно, какой из кластеров является целью по умолчанию, нужно скопировать записи серверов из других кластеров в кластер по умолчанию.

3. Скопируйте элементы Server из всех других элементов ServerCluster в соответствующий элемент ServerCluster целевого кластера по умолчанию.
4. Скопируйте элементы Name из всех других элементов ServerCluster в соответствующий элемент ServerCluster целевого кластера по умолчанию.

Соответствующий фрагмент отредактированного файла plugin-cfg.xml показан на рисунке 13, который иллюстрирует объединение членов Cluster1 и Cluster2 с образованием суперкластера.

В приведенном выше примере целевым кластером по умолчанию был Cluster2. Поэтому элементы Server и ServerName скопированы из Cluster1 в Cluster2. При таком модифицированном файле plugin-cfg.xml плагин HTTP-маршрутизатора распределяет запросы по всем четырем членам суперкластера.

Для равномерного выравнивания нагрузки по всем четырем членам суперкластера можно изменить атрибуты LoadBalanceWeight членов суперкластера. В данном конкретном примере – в предположении, что все члены суперкластера имеют одинаковую производительность – в качестве значений атрибута LoadBalanceWeight для циклического распределения нагрузки можно использовать 1000, 999, 998 и 997.

Ограничения

В любой топологии суперкластера существуют ограничения. При использовании HTTP-плагина в качестве маршрутизатора нужно иметь в виду следующие ограничения:

• Существующая реализация WebSphere Application Server поддерживает только суперкластеры с протоколом HTTP.
• Схема обеспечивает только масштабируемость, без восстановления нарушенных сеансов:
  • Репликация сеансов не поддерживается.
  • Для восстановления нарушенных сеансов можно использовать механизмы WebSphere eXtreme Scale или персистентности сеансов.
• Данный метод требует ручного администрирования файла plugin-cfg.xml:
  • Файл plugin-cfg.xml нужно редактировать вручную.
  • Автоматическую генерацию и распространение файла плагина следует запретить.
  • Нужно вручную поддерживать синхронизацию файла plugin-cfg.xml с изменениями в топологии.

В следующем разделе рассматривается тот же пример сценария, но с использованием для распределения запросов по суперкластеру прокси-сервера WebSphere Proxy Server вместо маршрутизатора на основе HTTP-плагина.

В начало

Прокси-сервер

Рассмотрим на том же простом примере из двух кластеров, как установить и сконфигурировать суперкластер с использованием в качестве маршрутизатора WebSphere Proxy Server (рисунок 14).

Наряду с другими важными функциями прокси-серверы передают запросы HTTP или SIP в серверы приложений WebSphere. Прокси-сервер – это просто один из нескольких типов серверов, которые можно создать с помощью консоли администратора WebSphere Application Server.

При конфигурировании топологии суперкластера с WebSphere Proxy Server необходимо выполнить следующие шаги:

1. Создать кластер WebSphere Application Server.
2. Установить на кластер приложение.
3. Протестировать и проверить приложение.
4. Создать дополнительные кластеры WebSphere Application Server.
5. Отобразить модули приложения на каждый кластер.
6. Соединить мостами все основные группы, содержащие кластеры, с основной группой, содержащей прокси-сервер.

Обратите внимание, что в описании этих шагов нигде не упоминается о создании или ручном редактировании файла конфигурации маршрутизатора. Дело в том, что информация по маршрутизации для прокси-сервера создается и редактируется динамически. Преимущества использования суперкластера с прокси-сервером в данной конфигурации, вместо маршрутизатора на основе HTTP-плагина заключается в том, что при этом не требуется никакого ручного редактирования статической информации по маршрутизации. Недостаток этого метода: все основные группы, содержащие прокси-сервер и любые кластеры, в которые будут передаваться запросы, должны быть соединены между собой мостами.

Маршрутизация запросов

Шаги по отображению модулей приложения на несколько кластеров подробно рассматриваются в части, посвященной HTTP-плагину, и здесь мы не будем их повторять. Для нужд данного примера, если вы выполнили эту процедуру, вы уже готовы к распределению клиентских запросов по суперкластеру. Никакой дополнительной настройки не требуется, так как наш простой пример содержит всего одну основную группу. Поздравляем, теперь у вас есть прокси-сервер, распределяющий запросы по суперкластеру!

Прокси-сервер будет автоматически маршрутизировать запросы HTTP всем членам суперкластера, сохраняя привязку сеансов. При этом не нужно редактировать вручную никакие файлы маршрутизации. Прокси-сервер получает информацию по маршрутизации динамически через службу объявлений менеджера высокой готовности. Маршрутизацию через прокси-сервер можно рассматривать как «ориентированную на приложение», а не на кластер, как в случае с HTTP-плагином. Прокси-сервер будет адресовать запросы любым серверам приложений WebSphere в ячейке, где развернуто приложение. Это подразумевает как членов кластера, так и внекластерные серверы приложений.

Мостовая служба основной группы

В этом простом примере нам не пришлось иметь с мостовой конфигурацией основных групп. В более реалистичном сценарии, вероятно, участвовало бы несколько мостовых групп и потребовалось бы конфигурировать мосты для связи основных групп между собой. Это позволяет динамически передавать информацию по маршрутизации от разных кластеров на прокси-сервер, где принимаются решения по маршрутизации. Если прокси-сервер и целевые кластеры расположены в разных основных группах, потребуется мостовая конфигурация основных групп (см. Ресурсы).

Ограничения

В любой топологии суперкластера также существуют ограничения. При использовании прокси-сервера в качестве маршрутизатора нужно принимать во внимание следующее:

• Для суперкластера прокси-сервер может поддерживать только протокол маршрутизации HTTP.
• Эта схема не обеспечивает восстановления нарушенных сеансов:
  • Репликация сеансов не поддерживается.
  • Для восстановления нарушенных сеансов можно использовать механизмы WebSphere eXtreme Scale или персистентности сеансов.
• Для этого метода может потребоваться конфигурирование мостовой службы основных групп (core group bridge service - CGBS); CGBS нужна, если прокси-сервер и кластеры (цели развертывания приложений) расположены в разных основных группах.

В начало

HTTP-плагин и прокси-сервер

Мы показали, как сконфигурировать топологию суперкластера, когда маршрутизатором служит либо HTTP-плагин, либо прокси-сервер. Теперь рассмотрим причины, по которым может оказаться целесообразным использование в топологии суперкластера маршрутизаторов обоих типов одновременно.

Безопасность

Использование прокси-сервера в топологии суперкластера удобно тем, что не нужно вручную редактировать и администрировать файл статической конфигурации маршрутов. Однако по причинам безопасности некоторые пользователи могут не захотеть выносить прокси-серверы за пределы DMZ (демилитаризованной зоны). Чтобы уладить это, можно сконфигурировать в DMZ Web-серверы (с традиционным HTTP-плагином маршрутизации), которые будут передавать запросы на прокси-сервер (серверы), расположенные с внутренней стороны от протокольного межсетевого экрана (рисунок 16).

При такой конфигурации Web-серверы в DMZ будут передавать запросы членам прокси-кластера с использованием традиционного маршрутизатора на базе HTTP-плагина. По умолчанию распределение запросов между прокси-серверами осуществляется строго циклически, и Web-серверам не нужно заботиться о привязке сеансов HTTP. Члены прокси-кластера передают запросы членам суперкластера. При необходимости прокси-сервер сохраняет привязку сеансов HTTP. Добавляется один сетевой сегмент (между Web-сервером и прокси-сервером), но в большинстве случаев это не имеет большого значения. Одной из особенностей такой топологии является генерация файла конфигурации HTTP-плагина.

Генерация файла plugin-cfg.xml

Для поддержки маршрутизации на прокси-серверы требуется специальный файл конфигурации HTTP-плагина. Традиционный файл конфигурации плагина содержит топологию ячейки и приложения. В данном сценарии файл конфигурации плагина должен понимать только, как маршрутизировать запросы на прокси-серверы. Сам прокси-сервер содержит механизмы для генерации файла плагина и его автоматического распространения. Чтобы сконфигурировать генерацию файла плагина, нужно обратиться по ссылке на параметры настройки Proxy со страницы конфигурации прокси-сервера, показанной на рисунке 17.

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

В данном случае нам нужны параметры настройки, относящиеся к генерации и распространению файла конфигурации плагина. Прокрутите страницу параметров настройки прокси-сервера вниз до раздела Proxy Plugin Configuration Policy (рисунок 18). Здесь вы найдете два параметра, относящихся к файлу конфигурации плагина HTTP:

• Генерация конфигурации плагина

  Этот параметр управляет тем, должен ли прокси-сервер генерировать файл plugin-cfg.xml, и задает область охвата при генерации.

  
  
  Рисунок 18. Правила конфигурации плагина прокси-сервера
  
  
  

  В качестве области охвата для генерации конфигурации плагина можно указать значения none, All, Cell, Node и Server. Сгенерированный файл конфигурации плагина будет находиться в каталоге <profile home>/etc.

• Сценарий изменения конфигурации плагина

  В поле Plugin config change script можно указать имя файла сценария, который будет выполняться по завершении генерации. Эту возможность можно использовать для автоматизации задачи распространения файла плагина между нужными Web-серверами. На рисунке 19 показан тот же раздел панели настройки прокси-сервера с всплывающим пояснением к этому полю.

  
  
  Рисунок 18. Правила конфигурации плагина прокси-сервера
  
  
  

Квинтэссенция этой части статьи заключается в том, что для конфигурирования Web-серверов для маршрутизации на прокси-серверы через HTTP-плагин нужно настроить прокси-сервер для генерации файла конфигурации плагина.

Дополнительные соображения

Пока что сгенерированный файл plugin-cfg.xml содержит только те прокси-серверы, которые работают на момент генерации. Если у вас есть прокси-серверы, которые сконфигурированы, но не работают, их не будет в сгенерированном файле конфигурации. Поэтому файл нужно создавать после запуска всех серверов.

При использовании для генерации файла конфигурации плагина прокси-сервера файл plugin-cfg.xml автоматически регенерируется при любых изменениях в среде, способных повлиять на его содержание. В число примеров таких изменений входят:

• Запуск нового прокси-сервера
• Инсталляция или деинсталляция приложения
• Модификация определений виртуального хоста
• Модификация контекстного корня.

В случае восстановления или других аналогичных действий во время генерации файла маршрутизации плагина в каталоге <profile home>/etc могут оказаться две версии файла маршрутизации: plugin-cfg.xml и plugin-cfg-<member name>.xml. Последний файл – это временный файл, который обычно не используется для маршрутизации. При наличии более чем одной версии файла маршрутизации плагина файл можно регенерировать после удаления версии plugin-cfg-<member name>.xml.

Прокси-кластер

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

В начало

Заключение

В первой части этой статьи из двух частей рассматриваются проблемы, с которыми можно столкнуться при масштабировании приложений Java EE путем их развертывания в крупных кластерах WebSphere Application Server. Обсуждается общий принцип построения суперкластера - двухуровневого иерархического кластера WebSphere Application Server, - а также то, как для достижения экстремальной масштабируемости приложений определенных классов, обслуживающих HTTP-клиентов, можно развертывать их в суперкластере.

Принцип построения суперкластера существенно зависит от возможностей по пересылке запросов разных маршрутизаторов, включенных в топологию. Представлены примеры топологий, содержащих традиционный плагин Web-сервера, классический прокси-сервер WebSphere Application Server, а также комбинированной топологии с применением маршрутизаторов обоих типов. В некоторых случаях автоматически сгенерированную статическую информацию по маршрутизации приходится изменять вручную. Рассматривается также метод развертывания приложения на нескольких кластерах.

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

Вариант с применением суперкластера можно рассмотреть в следующих случаях:

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

Хотя теоретического предела для числа экземпляров WebSphere Application Server, которое может содержаться в суперкластере, не существует, суперкластер не следует рассматривать как панацею масштабируемости. Ресурсы, используемые для конкретных приложений Java ЕЕ, могут накладывать ограничения на масштабируемость этих приложений. Например, для приложения на основе реляционной базы данных число экземпляров WebSphere Application Server, в которых это приложение может быть развернуто одновременно, а, следовательно, и масштабируемость приложения, может ограничиться максимальным числом соединений с базой данных, обслуживаемых сервером базы данных.

Во второй части мы продолжим рассмотрение суперкластера, добавив DMZ Secure Proxy Server для WebSphere Application Server, маршрутизатор по требованию IBM WebSphere Virtual Enterprise и продукт IBM WebSphere eXtreme Scale.

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи (EN).
  
  
• Менеджер высокой готовности
  
  
• Основные группы (домены высокой готовности)
  
  
• Кластеры и управление нагрузкой
  
  
• Связь с веб-серверами
  
  
• Установка прокси-сервера
  
  
• Руководство IBM Redbook: Techniques for Managing Large WebSphere Installations [методы организации крупных установок WebSphere], (SG24-7536-00), март 2008 г. (EN).

Об авторах

		Кевин Кепрос (Kevin Kepros) работает инженером-консультантом по программному обеспечению в лаборатории IBM Software Development Lab в Рочестере, штат Миннесота. Он является ведущим разработчиком компонента WebSphere High Availability Manager и членом группы разработчиков WebSphere Clustering.

		Д-р Дебасиш Банерджи (Debasish Banerjee) в настоящее время работает консультантом в IBM Software Services. Свою карьеру в области WebSphere он начинал в качестве архитектора по интернационализации WebSphere. Сегодня в круг его интересов входят экстремальная обработка транзакций, распределенное кэширование, эластичные вычисления и «облачные» вычисления. Дебасиш имеет диплом доктора философии по комбинаторным языкам функционального программирования.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало