Програмне забезпечення підвищеної готовності проміжного рівня в Linux

Управління робочим навантаженням надзвичайно важливо для бізнесу за вимогою. IBM ® LoadLeveler ® є системою управління завданнями, що дозволяє користувачам запустити на виконання більше число завдань за менший час за допомогою узгодження вимог обробки завдань з доступними ресурсами. Підтримка максимального часу безвідмовної роботи системи управління завданнями стає все більш важливою. Дізнайтеся, як можна досягти підвищеної готовності LoadLeveler-кластера з використанням вбудованих можливостей LoadLeveler і подальшого її поліпшення за допомогою програмного забезпечення з відкритими вихідними кодами.


IBMLoadLeveler – це система управління робочим навантаженням, що дозволяє користувачам призначати, планувати і виконувати завдання в пулі ресурсів. Вона забезпечує динамічне планування та узгодження робочого навантаження для оптимального використання ресурсів кластера. Вона також надає єдиний центр управління завданнями і робочим навантаженням.


LoadLeveler виконується у вигляді набору фонових процесів (демонів) на кожній клієнтській машині. Група клієнтських машин, пов'язуються з центральним машиною управління, називається LoadLeveler-кластером, який визначається за допомогою конфігураційного файлу.


Для найкращого засвоєння матеріалу ви повинні мати базові знання з IBM LoadLeveler і кластерів з підвищеною готовністю. Ви повинні бути також знайомі з першою статтею цієї серії ", частина 1: heartbeat і Web-сервер Apache ".


Реалізація LoadLeveler для підвищеної готовності


Кожна машина в LoadLeveler-кластері виконує одну або декілька ролей в плануванні завдань. Ці ролі і наслідки їх невиконання такі:



Роль, яку відіграє клієнтська машина, залежить від того, які фонові процеси (демони) LoadLeveler сконфігуровані на ній. У цілому кластер забезпечує можливість створення, підтвердження, виконання та управління послідовними і паралельними пакетними завданнями.


У наступному розділі ми обговоримо деякі з вбудованих можливостей LoadLeveler для забезпечення підвищеної готовності, а також способи поліпшення готовності всієї системи при використанні heartbeat.


 


Установка IBM LoadLeveler


У даному розділі показано, як встановити IBM LoadLeveler 3.2 for Linux ™ на трьох машинах: ha1, ha2 і ha3. Ці кроки засновані на інструкціях з установки, наведених у розділі 4 документа "LoadLeveler Installation Memo".


Створіть наступні каталоги для LoadLeveler:





    • Локальний каталог: / var / loadl

    • Домашній каталог: / home / loadl

    • Каталог випуску (release): / opt / ibmll / LoadL / full

    • Ім'я машини центрального менеджера: ha

  1. Увійдіть як root

  2. Створити групу з ім'ям loadl. Наведена нижче команда створює групу loadl з ID групи 1000 на всіх вузлах:



    groupadd g 1000 loadl


  3. Створіть користувача з ім'ям loadl. Наведена нижче команда створює userid loadl на всіх вузлах:



     useradd c loadleveler_user-d / home / loadl-s / bin / bash-u 1000 g 1000-m loadl


  4. Встановіть RPM-пакети LoadLeveler

    1. Встановіть RPM ліцензії (у якому LLIMAGEDIR містить інсталяційний RPMS)



      cd $LLIMAGEDIR

      rpm -Uvh LoadL-full-license-3.2.0.0-0.i386.rpm



    2. Встановіть решта RPM



      cd /opt/ibmll/LoadL/sbin

      ./install_ll -y -d “$LLIMAGEDIR”



  5. Запустіть сценарій ініціалізації llinit

    1. Створіть локальний каталог:



      mkdir /var/loadl


    2. Налаштуйте права доступу



      chown loadl.loadl /var/loadl


    3. Перейдіть в



      loadl

      ID



      su – loadl


    4. Перейдіть з поточного каталогу в підкаталог bin каталогу редакції, виконавши наступну команду:



      cd /opt/ibmll/LoadL/full/bin


    5. Переконайтеся, що ви маєте права на запис у каталогах LoadLeveler home, local та / tmp

    6. Виконайте команду llinit наступним чином:



       . / Llinit-local / var / loadl-release / opt / ibmll / LoadL / full-cm ha


 


Створення конфігурації машини планування завантаження з підвищеною готовністю


В даній установці:



У конфігурації для підвищеної готовності необхідні для ha1 файли і каталоги поміщаються на зовнішньому загальному пристрої зберігання, що робить їх доступними для ha2 у разі виходу з ладу вузла планування завантаження. Ось як це встановити:



  1. Увійдіть під ім'ям root на вузлах ha1 і ha2.

  2. Створіть наступні каталоги на загальних диску (/ ha):

    • /ha/loadl/execute

    • /ha/loadl/spool

  3. Встановіть права доступу, виконавши такі команди на сайті ha1:



    chown loadl.loadl /ha/loadl/
    chown loadl.loadl /ha/loadl/execute
    chown loadl.loadl /ha/loadl/spool


  4. Перейдіть до ID loadl на вузлах ha1 і ha2:



    su – loadl


  5. Встановіть відповідні права доступу для загальних каталогів за допомогою наведених нижче команд на сайті ha1:



    chmod 0777 /ha/loadl/execute

    chmod 775 /ha/loadl/spool



  6. На вузлах ha1 і ha2, Видаліть каталоги execute і spool в / var / loadl.



    rm -rf /var/loadl/execute
    rm rf /var/loadl/spool


  7. Створіть символічне посилання на загальні каталоги, використовуючи наступні команди на вузлах ha1 і ha2:



    ln -s /ha/loadl/execute /var/loadl/execute
    ln -s /ha/loadl/spool /var/loadl/spool


  8. Відредагуйте інформацію про машину. Нижче показана відповідна частина файлу LoadL_admin (у каталозі / home / loadl) на різних вузлах:

    1. ha1 працює як основна машина планування завантаження і як центральний менеджер. У виробничому середовищі я рекомендую розміщувати центральний менеджер і демон планування завантаження на окремих машинах.




      ha1: type = machine
      central_manager = true
      schedd_host = true
      ha3: type = machine



    2. ha2 працює як резервна машина планування завантаження і резервний центральний менеджер




      ha2: type = machine
      central_manager = true
      schedd_host = true
      ha3: type = machine



    3. ha3 працює як виконує машина




      ha: type = machine
      central_manager = true
      schedd_host = true
      ha3: type = machine



  9. Змініть прапорці RUNS_HERE у файлі LoadL_config (в / home / loadl) на різних машинах наступним чином:

    1. ha1 і ha2




      SCHEDD_RUNS_HERE = True
      STARTD_RUNS_HERE = False


      Це заборонить виконання завдань на машинах планування завантаження. Ми хочемо, щоб ha1 і ha2 працювали тільки як машини планування завантаження.

    2. ha3




      SCHEDD_RUNS_HERE = False
      STARTD_RUNS_HERE = True



  10. Відредагуйте файли / etc / hosts на трьох вузлах наступним чином:

    1. ha1




      9.22.7.46 ha.haw2.ibm.com ha
      9.22.7.46 ha2.haw2.ibm.com ha2



    2. ha2




      9.22.7.46 ha.haw2.ibm.com ha
      9.22.7.46 ha1.haw2.ibm.com ha1



    3. ha3




      9.22.7.46 ha.haw2.ibm.com ha
      9.22.7.46 ha1.haw2.ibm.com ha1
      9.22.7.46 ha2.haw2.ibm.com ha2



 


Налаштування heartbeat для управління машиною планування завантаження


Щоб налаштувати heartbeat на управління LoadLeveler:



  1. Створіть сценарій для запуску та вимикання процесів LoadLeveler. Дуже узагальнений сценарій приведений в лістингу 1. Ви можете налаштувати його під свої вимоги. Помістіть цей сценарій в каталог / etc / rc.d / init.d.

    Лістинг 1. Сценарій loadl




    #!/bin/bash
    #
    # /etc/rc.d/init.d/loadl
    #
    # Запускає процеси loadleveler
    #
    # chkconfig: 345 89 56
    # description: Runs loadleveler

    . /etc/init.d/functions
    # Джерело бібліотеки function.

    PATH=/usr/bin:/bin:/opt/ibmll/LoadL/full/bin
    #================================================= ===================
    SU=”sh”
    if [ “`whoami`” = “root” ]; then
    SU=”su – loadl”
    fi
    #================================================= ===================
    start() {
    echo “$0: starting loadleveler”
    $SU -c “llctl start”
    }
    #================================================= ===================
    stop() {
    echo “$0: Stoping loadleveler”
    $SU -c “llctl stop”
    }

    case $1 in
    “start”)
    start
    ;;
    “stop”)
    stop
    ;;
    “restart”)
    stop
    start
    ;;
    *)
    echo “usage: $0 {start/stop/restart}”
    ;;
    esac


  2. Тепер, налаштуйте файл / etc / ha.d / haresources (на обох вузлах планування завантаження) і включіть в нього сценарій loadl. Відповідна частина модифікованого файлу виглядає так:



     ha1.haw2.ibm.com 9.22.7.46 Filesystem:: hanfs.haw2.ibm.com: / ha:: / ha:: nfs:: rw, hard loadl

    Цей рядок наказує, щоб при запуску heartbeat ha1 прийняла IP-адрес кластера, змонтувала загальну файлову систему і запустила фонові процеси LoadLeveler. При зупинці heartbeat спочатку зупинить LoadLeveler, потім демонтує загальну файлову систему і, нарешті, звільнить IP.

 


Тестування аварії на машині планування завантаження


У цьому розділі показано, як протестувати підвищену готовність фонового процесу планувальника.



  1. Запустіть службу heartbeat на основному, а потім на резервному вузлах за допомогою такої команди:



    /etc/rc.d/init.d/heartbeat start

    Після успішного запуску heartbeat ви повинні побачити новий інтерфейс з IP-адресою, який ви сконфігурував у файлі ha.cf. Відразу після запуску heartbeat перегляньте ваш log-файл (за замовчуванням – / var / log / ha-log) на основному вузлі і переконайтеся, що був прийнятий IP і потім запущений LoadLeveler. Використовуйте команду ps для перевірки виконання фонових процесів LoadLeveler на основному вузлі. Heartbeat не запускає ці процеси на резервному вузлі. Це станеться лише у разі аварії на основному вузлі.

  2. Запустіть фонові процеси loadleveler на ha3, Зареєструвавшись як користувач loadl і використовуючи наступну команду:



    llctl start


  3. Зробіть ha3 недоступним в якості виконує машини, зупинивши фоновий процес startd. Це необхідно для забезпечення достатнього часу після підтвердження роботи для тестування аварії. Використовуйте наступну команду як користувач loadl на сайті ha3:



    llctl drain startd


  4. Перевірте, які завдання заплановані на виконання в LoadLeveler-кластері, використовуючи наступну команду на машині ha1 як користувач loadl:



    llq

    На малюнку 1 показана інформація, яка відобразиться на екрані після виконання цієї команди. З'явиться список всіх незавершених завдань на LoadLeveler-кластері.

    Малюнок 1. Видима командою llq інформація на сайті ha1

    Перевірте стан машин LoadLeveler-кластеру за допомогою виконання наступної команди на машині ha1, Зареєструвавшись як користувач loadl:




    llstatus

    Малюнок 2. Видима командою llstatus інформація на сайті ha1

    На малюнку 2 ви можете побачити, що на машині ha1 доступний Scehdd, а Startd зупинено (drained) на машині ha3 відповідно до кроку 3.


  5. Встановіть права доступу на каталог samples. Використовуйте наведену нижче команду на вузлі ha3 (На якому буде виконуватися завдання):



    chown loadl.loadl /opt/ibmll/LoadL/full/samples


  6. Підтвердіть завдання. Підтвердіть одне з примірних завдань, наданих з LoadLeveler, виконавши наведені нижче команди на машині ha1 і зареєструвавшись як користувач loadl:



    cd /home/loadl/samples

    llsubmit job1.cmd


    Якщо все нормально, ви побачите приблизно таке повідомлення:



     llsubmit: The job "ha1.haw2.ibm.com.23" with 2 job steps has been submitted.

    Приклад job1 є завдання, що складається з двох етапів, яке повинно викликати створення двох нових етапів завдання. Ці два нових етапу завдання перейдуть в стан очікування (I) при недоступності виконує машини. Див. малюнок 3.

    Малюнок 3. Видима командою llq інформація на сайті ha1 після підтвердження job1

    Тепер, зупиніть машину планування завантаження.


  7. Емулювання аварії. Ви можете зробити це, просто зупинивши heartbeat на основній системі за допомогою такої команди:



    /etc/rc.d/init.d/heartbeat stop

    Ви побачите, що менш ніж за хвилину всі служби запустяться на резервній машині. Ви можете переконатися в тому, що LoadLeveler працює на резервному вузлі, перевіривши файл / var / log / ha-log і використовуючи команду ps на резервній машині. Відразу після того, як резервна машина візьме керування на себе, запустіть команди llstatus і llq на резервному вузлі, зареєструвавшись як користувач loadl. На рисунках 4 і 5 показана інформація, яка відображається при виконанні цих команд.

    Малюнок 4. Видима командою llq інформація на сайті ha2 після аварії

    Малюнок 5. Видима командою llq інформація на сайті ha1 після підтвердження job1

    Зверніть увагу на малюнки 4 і 5:


    1. Відображаються всі старі незавершені завдання, включаючи два завдання, що відповідають завданням, підтвердженому вище на кроці 6. Це доводить, що інформація про завдання пережила відмову в роботі машини.

    2. Schedd тепер доступний на машині ha2.

    3. Startd все ще не працює на машині ha3.

  8. Продовжите роботу фонового процесу startd на машині ha3 за допомогою виконання наступної команди на ha3, Зареєструвавшись як користувач loadl:



    llctl resume startd

    Тепер машина ha3 доступна для виконання завдань. Два завдання повинні перейти в стан виконання і завершитися на машині ha3. Ви можете переконатися у завершенні роботи, глянувши на файли. Out, створені цими двома кроками завдання в каталозі / home / loadl / samples на машині ha3. Ви повинні побачити наступні файли: job1.ha1.23.0.out і job1.ha1.23.1.out.

  9. Знову запустіть службу heartbeat на основному вузлі. Це має зупинити LoadLeveler-процеси на вторинній машині. Основна машина повинна також взяти контроль над IP-адресою кластеру. Запустіть службу heartbeat за допомогою такої команди:



    /etc/rc.d/init.d/heartbeat start

    Ви бачите, як, використовуючи загальний диск, підтверджені на виконання завдання перед аварією основного вузла планування завантаження були відновлені після того, як управління прийняв на себе резервний вузол.

 


Налаштування підвищеної готовності центрального менеджера


Якщо ви вирішили запустити центральний менеджер на окремому від планувальника завантаження вузлі (ha4), Ви можете скористатися перевагами вбудованих функцій забезпечення підвищеної готовності центрального менеджера. Для того щоб спробувати цю конфігурацію, визначте машину ha4 в якості центрального менеджера в конфігураційних файлах всіх машин.


Проблеми з взаємодією по мережі, програмні або апаратні збої можуть з'явитися причиною недоступності центрального менеджера. У таких ситуаціях інші машини в LoadLeveler-кластері будуть вважати, що центральний менеджер більше не працює. Ви можете виправити цю ситуацію, призначивши одного або більше альтернативних центральних менеджера в налаштуваннях машини.


Наступний приклад налаштування машини визначає машину ha5 альтернативним центральним менеджером:






ha5: type = machine
central_manager = alt

Якщо основний центральний менеджер потерпить аварію, центральним менеджером стане альтернативний. Коли альтернативний стає центральним менеджером, завдання не будуть втрачені, але реєстрація всіх машин в кластері в новому центральному менеджері може зайняти кілька хвилин. У результаті запити про стан завдань можуть на короткий проміжок часу бути некоректними.


Коли ви визначаєте центральні менеджери, ви повинні встановити такі ключові слова в конфігураційному файлі:






 CENTRAL_MANAGER_HEARTBEAT_INTERVAL = <час у секундах>
CENTRAL_MANAGER_TIMEOUT = <кількість heartbeat-інтервалів>

У наведеному нижче прикладі альтернативний менеджер буде чекати протягом двох інтервалів часу, кожен інтервал триває 30 секунд:






CENTRAL_MANAGER_HEARTBEAT_INTERVAL = 30
CENTRAL_MANAGER_TIMEOUT = 2

 


Тестування виходу з ладу машини центрального менеджера


Ви можете протестувати аварію, знявши процес центрального менеджера під назвою Loadl_negotiator на машині ha4. Для запобігання повторного запуску фонового процесу центрального менеджера на цьому ж сайті ви повинні встановити ключове слово RESTARTS_PER_HOUR в 0. Протягом хвилини це викличе запуск центрального менеджера на альтернативному вузлі ha5.


 


Налаштування підвищеної готовності для виконують машин LoadLeveler


Налаштування аналогічна настройці підвищеної готовності для машин планування загрузнемо.


 


Висновок


У цій статті ви побачили, як реалізувати підвищену готовність для LoadLeveler-кластеру, використовуючи вбудовані можливості LoadLeveler, а також як додатково поліпшити готовність за допомогою програмного забезпечення з відкритими вихідними кодами. У четвертій частині цієї серії статей буде розглянута реалізація функцій підвищеної готовності на IBM WebSphere ® Application Server.

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


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

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

Ваш отзыв

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

*

*