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

В данной статье описана совместная работа одного из продуктов IBM по управлению рабочей нагрузкой, Enterprise Workload Manager (EWLM), и одного из продуктов CISCO по распределению нагрузки, Content Switching Module (CSM), направленные на предоставление решения по эффективному распределению нагрузки на основе производительности приложения и способности приложения достигать поставленных целей на бизнес-уровне.

Для облегчения взаимодействия между распределителями нагрузки сервера, такими как CSM, и объектами управления рабочей нагрузкой, такими как EWLM, был разработан Server/Application State Protocol (SASP). EWLM следит за состоянием и нагрузкой серверов и их приложений в настроенном кластере и принимает решения, какие серверы или приложения лучше всего подходят для успешной обработки клиентских запросов. Как часть такого процесса мониторинга, EWLM назначает относительный весовой коэффициент каждому серверу в кластере и передает эти весовые коэффициенты распределителю нагрузки. Распределитель нагрузки может затем использовать эти значения для распределения клиентского трафика на наиболее подходящий сервер.

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

О компонентах

Content Switching Module является первым распределителем нагрузки Cisco, поддерживающим SASP; первыми продуктами IBM, взаимодействующими с CSM с использованием SASP, являются Enterprise Workload Manager и z/OS® Load Balancing Advisor. В данной статье обсуждается только взаимодействие между EWLM и CSM. Аналогичную информацию о взаимодействии между z/OS Load Balancing Advisor и CSM можно найти в соответствующей документации по z/OS.

CSM получает информацию о состоянии сервера, используя единственное выделенное для SASP соединение с EWLM. SASP не только позволяет EWLM предоставлять относительные весовые коэффициенты серверов, но также позволяет CSM или EWLM удалить сервер из службы. Это может произойти, когда сервер либо сконфигурирован как необслуживаемый, либо если на этом сервере обнаружена авария.

На рисунке 1 изображена диаграмма, показывающая взаимодействие CSM и EWLM.

Обзор CISCO CSM

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

Например, если три сервера (A, B и C) имеют весовой коэффициент (2, 3 и 1) соответственно, порядок, согласно которому распределялся бы трафик, мог бы быть таким: A, B, C, A, B, B.

Обратите внимание на то, что в течение начального создания группы серверов CSM назначает серверам статический весовой коэффициент. По умолчанию этот весовой коэффициент равен 8, но может быть установлен в другое значение администратором.

Для группы серверов, с которой был ассоциирован EWLM, весовые коэффициенты, получаемые CSM из EWLM, подменяют все статические весовые коэффициенты. Однако в случае, когда EWLM становится недоступным (из-за аварии в сети или в системе), CSM использует весовые коэффициенты, которые были сконфигурированы при создании сервера для выполнения схемы распределения нагрузки.

Обзор рекомендаций по распределению нагрузки в EWLM

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

EWLM вычисляет новые весовые коэффициенты для группы серверов каждые 30 секунд. Вот некоторые прикладные и системные факторы, используемые в вычислениях:

• Оставшаяся пропускная способность
• Текущая степень аварий приложения
• История соответствий приложения своим показателям
• Уровень значимости текущей выполняемой работы

Обратите внимание на то, что вся статистика в EWLM поступает из его компонента Managed Server, который должен быть установлен на машинах группы серверов. Если этот компонент не работает, EWLM считает, что машина остановлена, и возвращает соответствующий весовой коэффициент, равный 0. CSM рассматривает этот нулевой весовой коэффициент как признак того, что сервер больше не обслуживается, и удаляет его из анализа для распределения нагрузки (см. раздел "Конфигурирование EWLM для распределения нагрузки").

SASP, Server/Application State Protocol

EWLM посылает весовые коэффициенты в распределитель нагрузки, используя Server/Application State Protocol (SASP). SASP - это двоичный протокол, состоящий из нескольких взаимодействий запрос-ответ. Управление этими взаимодействиями по протоколу сохраняется за распределителем нагрузки, пока он явно не откажется от управления. Мы вкратце опишем типы сообщений SASP:

• Register Request/Reply: Используется распределителем нагрузки или приложением-участником для регистрации приложения с EWLM.
• DeRegistration Request/Reply: Используется распределителем нагрузки или приложением-участником для удаления регистрации приложения с EWLM.
• Set Member State Request/Reply: Используется распределителем нагрузки или приложением-участником для приостановки или реактивации участников группы серверов.
• Set Load Balancer State Request/Reply: Используется распределителем нагрузки для настройки SASP-взаимодействия и позволяет приложениям-участникам использовать сообщения о регистрации, удалении регистрации и установке состояния участника.
• Get Weights Request/Reply: Используется распределителем нагрузки для получения текущих весовых коэффициентов для участников группы серверов.
• Send Weights Message: Это единственное сообщение, передаваемое из EWLM без предварительного получения соответствующего запроса. Если распределитель нагрузки конфигурирует EWLM на такое поведение, EWLM передает это сообщение, содержащее самые последние весовые коэффициенты, когда посчитает нужным.

Детальную информацию по SASP можно найти в документе "SASP Internet Draft" (см. раздел "Ресурсы"). Cisco сделал значительный вклад в разработку IBM спецификации SASP.

Настройка распределения нагрузки с EWLM и CSM

Настройка EWLM для работы с CSM и наоборот обычно осуществляется после установки EWLM-доменов управления и CSM-доменов распределения нагрузки. Важно отметить, что конфигурации и копии экранов, включенные в этот документ, взяты из EWLM Release 1, и мы предполагаем, что у вас установлен Virtualization Engine fix pack 1.1.020 или выше. Конфигурации и настройки из более свежих версий EWLM будут приведены в последующих статьях.

Типичная процедура установки EWLM-домена управления выглядит так:

1. Установить и настроить EWLM Domain Manager.
2. Настроить EWLM Control Center.
3. Установить и настроить EWLM Managed Server на каждом управляемом узле.
4. Разрешить ARM-инструменты измерения в поддерживаемом программном обеспечении промежуточного уровня (middleware). Более подробная информация об этом приведена в eServer Information Center и "Мониторинг производительности с Enterprise Workload Manager", ссылки на которые находятся в разделе "Ресурсы".
5. Создать политику домена для установки бизнес-задачи для каждого управляемого приложения.

Обратитесь к EWLM InfoCenter за полными инструкциями по установке EWLM.

Типичная процедура установки CSM-домена распределения нагрузки выглядит так:

1. Основная установка коммутатора Catalyst серий 6500 или маршрутизатора серий 7500 (наш CSM был в коммутаторе Catalyst 6509).
2. Подключить серверы к соответствующим портам.
3. Создать VLAN в зависимости от требований приложения.
4. Настроить маршрутизацию в коммутаторе для разрешения передачи данных на серверы и из серверов.
5. Логически сгруппировать серверы по группам на основе приложений, которые они обслуживают.
6. Определить виртуальные IP-адреса для того, чтобы входящий трафик достиг этих групп серверов.
7. Выбрать алгоритм распределения нагрузки для каждой группы серверов и по выбору назначить статический весовой коэффициент реальным серверам.
8. По выбору определить пробники (probe) и политики устойчивых групп (sticky group).

Полные инструкции по установке CSM и распределения нагрузки приведены в руководстве пользователя по Cisco CSM.

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

В литературе по Cisco CSM может использоваться термин Group Workload Manager (GWM) для обращения к любому программному обеспечению, которое может назначать динамические весовые коэффициенты участникам группы серверов, используя SASP-протокол. В данном случае EWLM является типом Group Workload Manager.

Настройка Catalyst 6509 и CSM для EWLM

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

1. Во-первых, убедитесь в том, что у вас имеется нужная версия встроенного программного обеспечения CSM, 4.1.2 или выше, а также поддерживаемая версия IOS.
2. Настройте агент для SASP EWLM соединения.
3. Назначьте этого агента соответствующим группам серверов.

Настройка агента для SASP/EWLM соединения

Должен быть настроен специальный DFP-агент, обозначенный специальным id привязки (bind id). Если этот id привязки попадает в диапазон идентификаторов привязки, назначенных для обмена данными по протоколу SASP, CSM знает, что соединение должно использовать протокол SASP для обмена данными. Например:

Router(config-slb-dfp)# agent 64.100.235.159 3860 65520

где синтаксис выглядит так:

Router(config-slb-dfp)# agent <ip-адрес> <порт> <id привязки>

CSM идентифицирует id привязки как GWM через использование переменных окружения. Переменные окружения SASP_FIRST_BIND_ID и SASP_GWM_BIND_ID_MAX идентифицируют первый GWM id привязки и максимальное количество идентификаторов привязки соответственно. То есть, если DFP-агент создан с id привязки между SASP_FIRST_BIND_ID и SASP_FIRST_BIND_ID + SASP_GWM_BIND_ID_MAX, агент использует SASP в качестве коммуникационного протокола к GWM.

Порт 3860 зарегистрирован в IANA для SASP (IANA Port Number Assignments). Использование этого порта уменьшает вероятность конфликтов при настройке обмена данными по протоколу SASP.

CSM настраивает параметры SASP так, чтобы EWLM автоматически передавал весовые коэффициенты серверов в CSM всякий раз, когда происходит изменение весовых коэффициентов. Однако для проверки того, что соединение с EWLM не было потеряно, если весовые коэффициенты не принимались после интервала повтора, CSM передает сообщение о состоянии распределителя нагрузки в EWLM. Если вся система полностью функционирует корректно, CSM принимает сообщение о состоянии распределителя нагрузки из EWLM. Интервал повтора по умолчанию равен 180 секундам, но может быть настроен при создании соединения. Кроме того, существует счетчик повтора, который указывает количество передач CSM сообщения о состоянии распределителя нагрузки в EWLM, которые нужно сделать, прежде чем отказаться от попыток. Значение по умолчанию 0 означает, что CSM делает попытки постоянно. Например:

Router(config-slb-dfp)# agent 64.100.235.159 3860 65520 0 120

где синтаксис выглядит так:

 
Router(config-slb-dfp)# agent <ip-адрес> <порт> <id привязки> <счетчик повторений> <интервал повторений>

Ассоциирование SASP-агента с группой серверов

После инициализации EWLM-соединения группа серверов может быть ассоциирована с SASP/EWLM агентом. Используя id привязки, назначенный SASP/EWLM агенту, группа серверов становится связанной с EWLM.

На данном этапе CSM регистрирует серверы в группе серверов с EWLM и запрашивает у EWLM весовые коэффициенты, представляющие состояние сервера. ID привязки представляет соединение с EWLM Domain Manager, поэтому более одной группы серверов может использовать один и тот же ID привязки, если каждая группа серверов управляется одним и тем же Domain Manager.

Например:

Router(config-slb-sfarm)# bindid 65520

На данном этапе состояние реальных серверов в группе серверов подстраивается в соответствии с полученной из EWLM ответной реакцией.

Важное замечание: Убедитесь в том, что ассоциированный виртуальный сервер имеет IP-протокол и порт, установленные так, чтобы EWLM отображал входящие запросы в конкретный PID на каждом реальном сервере. Это позволяет сделать доступной статистику уровня приложения для вычисления лучших весовых коэффициентов. Если протокол или порт не установлены, или целевое приложение не оснащено ARM-инструментами, то вычисление весовых коэффициентов все равно работает, но оно будет основано на системной статистике, а не на статистике из приложения.

Поддерживающие переменные окружения

Некоторые из необходимых переменных окружения мы упоминали ранее. В таблице 1 приведен список переменных.

Переменные в таблице 1 изменяются при помощи следующей команды:

Router(config-module-csm)# variable <имя переменной> <значение>

Настройка EWLM для распределения нагрузки

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

changeDM [.bat | .sh] workingDir -lbp xxxx

где xxxx - это корректный номер порта TCP/IP или значение "Off" для запрета генерирования весовых коэффициентов.

При начальной загрузке EWLM Domain Manager, если указан корректный порт распределения нагрузки, активизируется менеджер весовых коэффициентов, который ожидает соединений с распределителями нагрузки. После получения соединения и регистрации корректных групп, Domain Manager передает обновления в CSM при любом изменении. Если Domain Manager обнаруживает, что Managed Server больше не находится в оперативном режиме, или целевое приложение завершилось, он также передает CSM весовой коэффициент 0, указывающий на то, что реальный сервер находится в автономном режиме и на него не нужно перенаправлять какой-либо трафик.

Предположения о восстановлении после сбоя

Существует два предположения о восстановлении после сбоя, которые должны заинтересовать вас:

• Отказ CSM
• Отказ EWLM

При отказе CSM два CSM, настроенные в конфигурации active/standby, могут гарантировать синхронизированную информацию о состоянии сервера путем подключения к одной и той же EWLM для получения идентичных обновлений динамических весовых коэффициентов. Однако для работы этой конфигурации два CSM должны быть различимы для EWLM; таким образом, они должны хранить различные значения в своих полях SASP_CSM_UNIQUE_ID. Например, один CSM может иметь значение SASP_CSM_UNIQUE_ID равное "CSM-1", тогда как другой CSM будет требовать другое значение, например "CSM-2."

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

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

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

В данном разделе представлен пример топологии и конфигурации, используемых для выполнения сценария тестирования распределения нагрузки. Этот сценарий состоит из CSM, распределяющего трафик по четырем транзакционным путям, каждый из которых содержит Web-сервер (IBM HTTP Server), сервер приложений (WebSphere® Application Server) и базу данных (IBM DB2®). Два пути состоят из машин AIX®, третий использует машины Windows, а четвертый использует систему Solaris. Domain Manager выполняется на выделенной машине Linux®. Распределитель нагрузки является CSM-модулем в третьем слоте CISCO Catalyst 6509 Switch.

На рисунке 2 изображена топология сети и приложения.

Теперь мы рассмотрим некоторые конфигурации распределения нагрузки.

Конфигурации EWLM

Корректная работа EWLM-домена управления означает:

1. Управляемые сервера (Managed Servers) подключены к Domain Manager. На копии экрана EWLM (рисунок 3) вы можете увидеть, какие управляемые сервера подключены и используются в данный момент.
   Рисунок 3. Подключенные и используемые управляемые сервера
   
   

   На рисунке 4 вы можете увидеть настройку среды для данного учебного примера. В этом примере конфигурации вы можете заметить, что каждый пункт в потоке транзакции (IHS > WebSphere > DB2) находится на той же самой машине (тот же IP-адрес). Это делает пример проще, но, определенно, такой ситуации быть не должно.

   
   Рисунок 4. Среда примера
   
   

2. Все поддерживаемое программное обеспечение промежуточного уровня оснащено ARM-инструментами.
3. Control Center показывает статистику транзакций.

   Шаги 2 и 3 не являются абсолютным требованием, но могли бы значительно улучшить алгоритм вычисления весовых коэффициентов.

Ниже перечислены шаги по настройке EWLM Domain Manager на прослушивание и реакцию на SASP-сообщения:

1. Остановите Domain Manager.
2. Проверьте конфигурацию Domain Manager: ./displayDM.sh /usr/EWLMDM.
3. Добавьте порт распределения нагрузки в конфигурационную таблицу: ./changeDM.sh /usr/EWLMDM -lbp 3860.
4. Если ваш Domain Manager имеет два IP-адреса, и вы хотите использовать оба для Managed Servers и распределения нагрузки, убедитесь, что параметр -ma IP равен 0.0.0.0, а не конкретному IP-адресу, поскольку порты -mp xxxx и -lbp xxxx используют параметр -ma IP в качестве IP-адреса для привязки. Для изменения этой ситуации используйте следующую команду: ./changeDM.sh /usr/EWLMDM -ma 0.0.0.0. Вы можете объединить предыдущую команду и эту в одну.
5. Опять запустите Domain Manager.
6. Проверьте, что Domain Manager прослушивает порт распределения нагрузки. В Windows для этого используется команда: => netstat -na. Найдите следующую строку:

 TCP 0.0.0.0:3860 0.0.0.0:0 LISTENING 

Конфигурации CSM

Все эти шаги должны быть выполнены с уровнем привилегий равным 15 и использованием команды login или enable в консоли.

1. Проверьте SASP-переменные по умолчанию.

   esvt6509#sh mod csm 3 variable variable value ---------------------------------------------------------------- ... SASP_CSM_UNIQUE_ID Cisco-CSM SASP_FIRST_BIND_ID 65520 SASP_GWM_BIND_ID_MAX 1 ...

   
   
2. Измените значение переменной.

   esvt6509#configure terminal esvt6509(config)#mod csm 3

   
   
3. Создайте группу серверов.

   esvt6509(config-module-csm)#serverfarm testfarm esvt6509(config-slb-sfarm)#nat server esvt6509(config-slb-sfarm)#no nat client esvt6509(config-slb-sfarm)#predictor leastconns esvt6509(config-slb-sfarm)#bindid 65520 esvt6509(config-slb-sfarm)#real 192.168.200.84 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.170 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.104 esvt6509(config-slb-real)#inservice esvt6509(config-slb-real)#real 192.168.200.13 esvt6509(config-slb-real)#inservice

   
   
4. Создайте виртуальный сервер.

   esvt6509(config-module-csm)#vserver testvserver esvt6509(config-slb-vserver)#virtual 192.168.100.251 tcp www esvt6509(config-slb-vserver)#serverfarm testfarm esvt6509(config-slb-vserver)#persistent rebalance esvt6509(config-slb-vserver)#inservice

   
   
5. Создайте DFP-агент.

   esvt6509(config-module-csm)#dfp esvt6509(config-slb-dfp)#agent 192.168.200.173 3860 65520 esvt6509(config-slb-dfp)#end

   
   
6. Проверьте группу серверов.

   esvt6509#sh mod csm 3 serverfarms detail TESTFARM, type = SLB, predictor = LeastConns nat = SERVER virtuals inservice = 1, reals = 4, bind id = 66520, fail action=none inband health config: <none> retcode map = <none> Real servers: 192.168.200.84, weight = 56, OPERATIONAL, conns = 0 192.168.200.170, weight = 56, OPERATIONAL, conns = 0 192.168.200.104, weight = 56, OPERATIONAL, conns = 0 192.168.200.13, weight = 56, OPERATIONAL, conns = 0 Total connections = 0

   
   
7. Проверьте реальные серверы.

   esvt6509#sh mod csm 3 reals real server farm weight state conns/hits ---------------------------------------------------------------------- 192.168.200.84 TESTFARM 56 OPERATIONAL 0 192.168.200.170 TESTFARM 56 OPERATIONAL 0 192.168.200.104 TESTFARM 56 OPERATIONAL 0 192.168.200.13 TESTFARM 56 OPERATIONAL 0

   
   
8. Проверьте виртуальные серверы.

   esvt6509#sh mod csm 3 vservers detail TESTVSERVER, type = SLB, state = OPERATIONAL, v_index = 14 virtual = 192.168.100.251/32:80 bidir, TCP, service = NONE, advertise = FALSE idle = 3600, replicate csrp = none, vlan = ALL, pending = 30, layer 4 max parse len = 2000, persist rebalance = TRUE ssl sticky offset = 0, length = 32 conns = 0, total conns = 0 Default policy: server farm = TESTFARM, backup = <not assigned> sticky: timer = 0, subnet = 0.0.0.0, group id = 0 Policy Tot matches Client pkts Server pkts ----------------------------------------------------- (default) 0 0 0

   
   
9. Проверьте DFP-агент.

   esvt6509#sh mod csm 3 dfp detail DFP Agent 192.168.200.173:3860 Connection state: Connected Keepalive = 65520 Retry Count = 0 Interval = 180 (Default) Security errors = 0 Last message received: 16:12:14 EST 06/22/04 Last reported Real weights for Protocol TCP, Port www Host 192.168.200.84 Bind ID 65520 Weight 56 Host 192.168.200.170 Bind ID 65520 Weight 56 Host 192.168.200.104 Bind ID 65520 Weight 56 Host 192.168.200.13 Bind ID 65520 Weight 56 DFP manager listen port not configured. No weights to report to managers.

   
   

Выученные уроки

В данном разделе описано то, что мы узнали во время тестирования и выполнения учебных примеров использования CSM весовых коэффициентов EWLM. Этот раздел включен в данную статью потому, что мы считаем, что эта статья должна использоваться в качестве справочника по обеспечению более эффективного распределения нагрузки с EWLM и CISCO CSM.

Передовой опыт

Из нашего опыта мы сформулировали четыре основные рекомендации:

1. Рекомендуется, прежде всего, начать с функционального EWLM-домена управления и функционального CSM-домена распределения нагрузки, а затем разрешить передачу данных между EWLM Domain Manager и CSM.
2. В большинстве наших тестов взвешенный алгоритм наименьшего числа соединений (weighted least-connection) показывал лучшую производительность, чем взвешенный алгоритм кругового обслуживания (weighted round-robin).
3. Помните об ограничениях и уязвимых местах использования EWLM Firewall Broker. Firewall Broker выступает в качестве прокси сервера, принимая соединения от всех Managed Servers в одной и той же IP-подсети и направляя их в Domain Manager. Если машина с Firewall Broker или сам процесс не доступен, все эти Managed Servers становятся отсоединенными от Domain Manager. Обычно тот факт, что Managed Servers отсоединены от Domain Manager, не влияет на функционирование программного обеспечения промежуточного уровня. Однако если использование EWLM для распределения нагрузки разрешено в CSM, Domain Manager распознает, что Managed Server находится в автономном режиме, и передает весовой коэффициент 0 в CSM, останавливая передачу трафика на этот сервер. Если Firewall Broker неожиданно стал недоступным, Domain Manager и CSM могут подумать, что недоступна вся группа серверов.
4. Наиболее надежной топологией является как можно меньшее количество узлов между Domain Manager и Managed Servers.

Особые выгоды использования EWLM для распределения нагрузки

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

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

Устранение неисправностей

Вот что мы узнали об устранении неисправностей:

1. Настройка домена распределения нагрузки в CSM и установка и конфигурирование EWLM в сложных корпоративных средах может быть довольно не простой. Если в таких средах возникают проблемы с распределением нагрузки, их устранение должно начинаться с удаления DFP-агента, указывающего на EWLM Domain Manager.

   Обычно, Domain Manager будет менять только весовой коэффициент реальных серверов в CSM, но не будет препятствовать движению трафика. Единственный раз, когда он сможет это сделать - если Domain Manager посчитает Managed Server находящимся в автономном режиме или когда функции ARM-оснастки в приложении не работают. В этом случае Domain Manager посылает весовой коэффициент 0 для указания того, чтобы CSM больше не посылал трафик к этому приложению. Используйте команду sh mod csm 3 reals, для того чтобы увидеть, имеются ли у вас какие-либо серверы, находящиеся в состоянии DFP_THROTTLED (полагая, что ваш CSM установлен в слот 3).

   Если у вас действительно есть эта проблема, проверьте EWLM Control Center, для того чтобы найти неисправность. Затем проверьте Managed Server, для того чтобы увидеть, что все работает правильно, особенно Java-процесс Managed Server, программное обеспечение промежуточного уровня и сетевое подключение к Domain Manager. После восстановления всего в обратном порядке проверьте EWLM Control Center, для того чтобы убедиться, что этот управляемый сервер снова работает правильно.

2. Для решения проблем с SASP может быть очень полезным ведение журналов. Log-сообщения сохраняются в буфере Catalyst, и вы можете использовать внешнюю фоновую программу syslog, имеющую большую гибкость и больше вариантов записи.

   Для отображения всех сообщений в буфере Catalyst используйте команду show logging. Для настройки ведения журналов в удаленный syslog-файл обратитесь к руководству пользователя Catalyst и руководствам по вашей операционной системе.

   Все сообщения об ошибках SASP и код возврата записываются в буфер или удаленный syslog-файл в зависимости от настройки. Успешные коды возврата не записываются.

3. Еще одна обычная проблема, выявленная при тестировании, возникает тогда, когда DFP-агент не использует SASP-протокол для обмена данными с EWLM Domain Manager. При этом вы нигде не увидите каких-либо сообщений. В отображаемой информации команды sh mod csm 3 dfp detail вы увидите, что состояние DFP-агента равно Not connected или Trying to connect (предполагая, что ваш CSM установлен в слот 3). Для исправления этой ситуации вы должны опять проверить вашу конфигурацию. Особое внимание уделите SASP-агенту и убедитесь в том, что его ID связывания находится в пределах между SASP_FIRST_BIND_ID и SASP_FIRST_BIND_ID + SASP_GWM_BIND_ID_MAX.

В заключение

Используя усовершенствованную методику сбора ресурсов и статистики, EWLM может разумно назначать весовые коэффициенты на основе относительной загрузки и доступности серверов в кластере. Используя SASP, EWLM затем может передать эту информацию о состоянии в CSM, который, в свою очередь, способен распределять клиентские запросы в наиболее подходящий сервер. Результатом этого является хорошо сбалансированное, высокоэффективное распределение трафика, гарантирующее наилучшее использование имеющихся ресурсов, как определено администратором.

		Алан Бивенс (Alan Bivens) - доктор философии, сотрудник группы исследований в IBM T.J. Watson Research Center, где он занимается созданием возможностей автономного управления рабочей нагрузкой для самодиагностики и самоорганизации центров данных (datacenter). В настоящее время в круг его обязанностей входят вопросы распределения нагрузки, управления питанием и координации между автономными менеджерами.

		Чеким Чуор (CheKim Chhuor) в настоящее время работает в IBM Poughkeepsie в группе System Verification Test. Он имеет многолетний опыт консультирования по Web-инфраструктуре, а также множество сертификатов IBM WebSphere, DB2 и e-business. Сейчас занимается сетевыми и автономными вычислениями. Связаться с ним можно по адресу chhuor@us.ibm.com.

		Донна Диленбергер (Donna Dillenberger) пришла в IBM в 1988 и работала над моделированием перспективного аппаратного обеспечения, операционных систем больших ЭВМ, управления рабочей нагрузкой, а также над масштабируемыми JVM, масштабируемыми Web-серверами, потоковыми серверами и EJB-контейнерами. Она является ведущим инженером (Distinguished Engineer) отдела IBM Chief Architect of IT Optimization, специалистом-изобретателем (Master Inventor), членом IBM Academy и адьюнкт-профессором в Columbia University. Сейчас работает над Enterprise Workload Management и супервизорами универсальных ЭВМ.

		Грэг Фэррис (Greg Ferris) работает в IBM Poughkeepsie, New York над System Verification Test проекта Virtualization Engine. Перед этим он несколько лет работал в области тестирования производительности zSeries. В проекте VE он занимается EWLM, распределением нагрузки и автоматизацией.

		Джон Фентон (John Fenton) - технический директор в Cisco Systems. Он несколько лет разрабатывал и проектировал различные коммуникационные протоколы. В настоящее время занимается разработкой программного обеспечения для сетевых процессоров, предоставляющего усовершенствованные коммуникационные службы.

		Весли Чоу (Wesley Chou) работает руководителем разработки в Cisco Systems' Application Delivery Business Unit. Занимается разработкой программного обеспечения для технологий распределения нагрузки.