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

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

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

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

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

Ресурсы«). Cisco сделал значительный вклад в разработку IBM спецификации SASP.

Ресурсы«.

  • Создать политику домена для установки бизнес-задачи для каждого управляемого приложения.
  • Обратитесь к 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.

    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 <имя переменной> <значение>

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

    рисунок 3) вы можете увидеть, какие управляемые сервера подключены и используются в данный момент.

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

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

  • Все поддерживаемое программное обеспечение промежуточного уровня оснащено ARM-инструментами.
  • 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. Занимается разработкой программного
    обеспечения для технологий распределения нагрузки.

    Комментарии закрыты.

    Карта сайта: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34