Автономне розподіл навантаження, частина 1: Cisco Content Switching Module, Комерція, Різне, статті

Інтегровані системи управління системою і робочим навантаженням довели свою цінність і використовуються для моніторингу та управління корпоративними програмами та системами. У той час як системи можуть багато знати про додатки, зазвичай, вони не володіють великою здатністю управляти швидкістю, з якою ці програми беруть роботу. На відміну від них розподільники навантаження можуть управляти цією швидкістю, але зазвичай вони мають мало інформації про здатність програми успішно обробити запит.


В даній статті описана спільна робота одного з продуктів 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.


Рисунок 1. Взаємодія між CSM і EWLM


  • Всі підтримуване програмне забезпечення проміжного рівня оснащено 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 може забезпечити особливі вигоди:



    Усунення несправностей


    Ось що ми дізналися про усунення несправностей:



    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, який, у свою чергу, здатний розподіляти клієнтські запити в найбільш підходящий сервер. Результатом цього є добре збалансоване, високоефективне розподіл трафіку, що гарантує найкраще використання наявних ресурсів, як визначено адміністратором.


    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *