Workload Management |
Настройка и запуск примера BeenThere |
В этом разделе приведены инструкции по настройке среды (см. рис. Рисунок 1), установке и выполнению примера BeenThere. Убедитесь, что установлены следующие программные продукты:
Имя системы | Установленные программы |
web |
IBM HTTP Server Модуль IBM HTTP Server |
app1 | IBM WebSphere Application Server |
app2 | IBM WebSphere Application Server |
dm | Администратор развертываний IBM WebSphere Application Server |
Примечание: Перед тем, как выполнять приведенные здесь инструкции, убедитесь, что запущен Web-сервер и его служба администрирования. Кроме этого, в Администраторе развертываний должно быть создано определение Web-сервера, чтобы файл plugin-cfg.xml распространялся автоматически.
Для добавления узлов сервера приложений в кластер выполните следующие действия:
addNode <deploymgr-хост>
addNode.sh <deploymgr-хост>
корневой-установочный-каталог/bin/addNode <deploymgr-хост> <deploymgr-порт> -имя-профайла <имя-профайла> -startingport <блок-портов>
Теперь серверы приложений объединены в ячейку.
Кластер MyWebCluster предназначен для распределения задач и автоматического переноса ресурсов сервлетов.
Для создания кластера MyWebCluster выполните следующие действия:
Будет создан кластер MyWebCluster.
Кластер MyEJBCluster предназначен для распределения задач и автоматического переноса ресурсов объектов EJB.
Для создания кластера MyEJBCluster выполните следующие действия:
Примечание:В распределенных платформах выбор опции Предпочитать локальные означает, что сначала будут рассматриваться объекты EJB на локальном узле. В данном примере эта опция отключена, чтобы проиллюстрировать управление запросами EJB.
Будет создан кластер MyEJBCluster.
При создании кластера MyWebCluster каждый новый кластер создается с включенной опцией Создавать уникальные порты HTTP. Это позволяет предотвратить конфликты портов HTTP за счет создания уникального номера порта для каждого нового сервера приложений.
Для того чтобы проверить, соответствует ли каждому динамически создаваемому номеру порта HTTP запись о псевдониме виртуального хоста хост-по-умолчанию, выполните следующие действия:
Обновление виртуального хоста завершено.
По умолчанию служба настройки WebSphere для серверов приложений отключена. В данном примере требуется, чтобы эта служба программно считывала файлы конфигурации WebSphere Application Server и получала из них информацию о среде.
Для включения службы настройки WebSphere выполните следующие действия:
Служба настройки WebSphere включена.
Для установки файла BeenThere.ear выполните следующие действия:
Если защита BeenThere вам не требуется, пропустите этот раздел. Для того чтобы настроить защиту BeenThere, воспользуйтесь инструкциями из раздела here.
Для запуска серверов выполните следующие действия:
Серверы будут запущены.
Для выполнения примера откройте в Web-браузере страницу http://<хост>/wlm/BeenThere, где <хост> - имя или IP-адрес хоста, на котором работает IBM HTTP Server.
Примечание: начиная с версии 6, WebSphere обладает новой функцией, разработанной для достижения максимальной производительности всей системы. Это значит, что в этих версиях при тестировании примера BeenThere, компонент Workload Management не сможет маршрутизировать запросы в строгом соответствии с их весом. Веса могут изменяться во время выполнения, поэтому методы проверки, описанные ниже, могут давать неверные результаты. В этих сценариях лучший метод проверки функции WLM — гарантировать доставку запросов всем элементам кластера, несмотря на то, что маршруты некоторых запросов не соответствуют их весам. Также существуют методы выключения этих механизмов обратной связи. Если это необходимо, обращайтесь в службу технической поддержки IBM за дополнительной информацией.
Для проверки управления задачами Web-контейнера выполните следующие действия:
Откройте в Web-браузере страницу http://<хост>/wlm/BeenThere, где <хост> - имя или IP-адрес хоста, на котором работает IBM HTTP Server.
Значения в резюме выполнения сервлета изменятся, как показано в следующем примере:
Узел сервлета теперь станет не app1, а app2. Это говорит о том, что IBM HTTP Server передал запрос HTTP другим членам кластера MyWebCluster, а именно WebServer2 на app2. Повторные выполнения сервлета показывают, что запросы HTTP распределяются в зависимости от настроенных значений весов для членов кластера MyWebCluster.
Проверка конфигурации управления задачами Web-контейнера завершена.
Для проверки управления задачами контейнера EJB выполните следующие действия:
В распределенных платформах значения в резюме выполнения объекта EJB должны быть следующими:
В этом примере можно увидеть управление рабочей схемой компонента EJB в зависимости от весовых значений, настроенных для членов кластера MyEJBCluster. Каждому вызову объекта EJB на сервере app1 соответствует три вызова объекта на сервере app2.
В платформах z/OS весовые значения служат для распределения запросов HTTP, а для распределения запросов протокола IIOP они не применяются.
Проверка конфигурации управления задачами контейнера EJB завершена.
Для проверки правильности указания весовых значений членов кластера bean-объекта выполните следующие действия.
В результате должно получиться следующее:
В примере показаны весовые значения всех членов кластера MyEJBCluster. Вес EJBServer1 равен 1, а вес EJBServer2 равен 3.
Проверка весовых значений членов кластера bean-объекта завершена.
Итак, мы рассмотрели управление рабочей схемой в действии и проверили правильность настройки и работы примера BeenThere.