Зростаючий крон: який наступний планувальник? [зачинено]


30

Ми використовуємо cron приблизно стільки часу, скільки я пам'ятаю, щоб впоратися з усіма нашими потребами у плануванні роботи. Все, починаючи від клонів / знімків зберігання даних до звітів проти баз даних, до щоденних системних звітів до моніторингових перевірок, заплановано на декілька сотень серверів через cron.

Недоліки досить очевидні: важке управління робочими місцями, непростий спосіб створення залежностей (особливо на різних серверах), і, звичайно, неминуче хтось "тимчасово" пропускає роботу, але пізніше забуває видалити коментар.

Ми спробували комерційну пропозицію, але врешті-решт це було визнано занадто дорогим, як крок від крона.

Я бачу інші варіанти, такі як SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor, які, як видається, орієнтовані на більш великі, однорідні середовища кластерів із завданнями, які працюватимуть на будь-якій кількості подібних вузлів: обчисленні в сітці тощо. Наше середовище досить змішане (різні Linuxes, AIX та FreeBSD), і нам потрібно створити залежності в різних типах систем (наприклад, завдання на вікні Linux може знадобитися, щоб визначити, чи має виконуватися завдання в коробці AIX.)

Хтось має досвід переходу від крона до більш централізованого управління? Будь-які поради щодо вибору програмного забезпечення чи краще перейти з відкритим кодом чи комерційним?

Відповіді:


11

Condor, OGE та Torque можуть усі вас туди доставити, але тільки Condor має вбудоване управління залежностями за допомогою інструменту DAGMan . DAGMan дозволяє встановити спрямований, ациклічний графік, який описує ваш робочий потік, і менеджер піклується про переміщення робочих місць у вашому робочому процесі та оцінку результатів пропуску / відмови на кожному кроці потоку. Condor є відносно платформою агностиком, що означає, що DAGMan теж є, і ви, безумовно, можете виконати один дочірній крок на AIX, коли батьків працює в Linux або Windows. DAGMan не переймається тим, де виконуються завдання, лише те, що коди виходу проходять або проходять.

Будь-які поради щодо вибору програмного забезпечення чи краще перейти з відкритим кодом чи комерційним?

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

OGE зараз знаходиться в дивному просторі. Більше не можна запускати створений Oracle варіант GE, і Oracle вже не надсилає код, який він записує назад до GE SCC, але існує декілька вилок коду, які намагаються надати солдату як вільні проекти з відкритим кодом. Univa, зокрема, привело заряд , наймаючи колишніх GE-розробників, щоб продовжувати працювати над відкритим джерелом, вільно доступним варіантом GE. Grid Engine має на увазі дві речі: це легко налаштувати, він може працювати з короткими (<2 хвилинами) завданнями, не надаючи багато планових накладних витрат на завдання, що уповільнює пропускну здатність. Це великий мінус - не дуже хороша підтримка Windows. Деякі з нас доклали певних зусиль, щоб перенести його на запуск Cygwin багато років тому, але це не так добре, як рідне, це точно.

Зараз Condor - мій улюблений із трьох згаданих вами технологій. Навколо Condor є сильна спільнота, і програмне забезпечення дуже зріле (зараз 20 років). Підтримка Native Windows та POSIX OS означає, що вона працює дуже добре. Вищезгаданий DAGMan - лише одна з безлічі чудових творів, які поставляються з Condor. Це може бути дотиком, складним у налаштуванні, але як тільки він працює і працює, це тверда порода. Він володіє неймовірно гнучкою мовою для виконання роботи <-> машинного узгодження та побудови правил користування вашими ресурсами. Він також підтримує динамічне забезпечення на машинах, дозволяючи робочим місцям вибирати кількість необхідних ресурсів для машин, а потім повторно рекламувати різницю як наявну. Він підтримує глобальні лічильники ресурсів, щоб ви могли обмежитися такими речами, як ліцензії на програмне забезпечення. І звичайно, він має DAGMan, який є надзвичайно потужним інструментом для управління робочим процесом. Мінус Кондора - це накладні витрати на планування короткочасних завдань, які можуть бути обтяжливими. Ви хочете, щоб завдання, які тривають довше, ніж 2 хвилини, в ідеалі, інакше планування стане великою частиною часу роботи в системі.

Крутний момент - це трохи більше ніші. Я про це знаю менше, боюся. Він більше порівнює з Grid Engine ніж Condor. Є платні додатки, які @warren згадав, які можуть розширити те, що може зробити базовий, безкоштовний Torque.

Якщо ви хочете спробувати три технології та побачити, як вони працюють з вашими конкретними робочими навантаженнями, CycleCloud може створити безпечні, віртуалізовані пули, які попередньо налаштовані за допомогою Condor, GridEngine або Torque - тому не витрачайте часу на пошук цього матеріалу. з вашого боку. Буде потрібно кілька доларів, щоб розкрутити невеликі пули кожної технології та спробувати їх з репрезентативними робочими навантаженнями. (Відмова: я працюю в Cycle Computing, ми робимо CycleCloud)


Спасибі за інформацію. Здається, Condor справді орієнтований на більші колекції машин, які здатні виконувати певну роботу. Проблема, яка в мене є, полягає в тому, що я маю купу завдань, які виконуються в дуже конкретних місцях, але мені потрібно ланцюжок завдань разом, щоб запускатися в певному порядку. Це теж може зробити Кондор, або це буде болісно, ​​щоб він працював таким чином?
Cakemox

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

6

Хронос виглядає дуже перспективно.

Chronos - це заміна Airbnb на cron. Це розповсюджений і невідмовний планувальник, який працює на вершині Apache Mesos. Ви можете використовувати його для упорядкування завдань. Він підтримує власні виконавці Mesos, а також виконавця команд за замовчуванням. Таким чином, Chronos виконує сценарії sh (для більшості системних файлів). Chronos можна використовувати для взаємодії з такими системами, як Hadoop (включаючи EMR), навіть якщо для рабів Mesos, на яких відбувається виконання, не встановлено Hadoop. Включені сценарії обгортки дозволяють переносити файли та виконувати їх на віддаленій машині у фоновому режимі та за допомогою асинхронних зворотних викликів повідомляти Chronos про завершення роботи або збої.

Я також одержав великий особистий успіх, використовуючи Дженкінса як заміну крона. Він досить добре обробляє виконання завдань на віддалених серверах. Ось запис про це: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/


4

Протягом останніх 4,5 років я працював з платформою автоматизації сервера HP (уроджене Opsware), а також з рештою набору оптимізації бізнес-технологій (Автоматизація мережі, Оркестрація операцій тощо).

Для достатньо великого середовища управління роботою через SA - це дуже життєздатний (і бажаний) інструмент. У поєднанні з ОО, роботу можна контролювати за допомогою управління контролем змін, оформлення квитків тощо.

Ось не надто весела частина: це дорого (дуже дорого). Ви можете перевірити деякі пропозиції в аналогічному запитанні, яке я задовго запитав: Інструменти управління та аудиту сервера FLOSS .

Я б також сказав, що Torque / Maui / Moab (від Adaptive Computing ) дуже круті: не впевнені в ціноутворенні, але вони також дуже гнучкі інструменти.


Відмова від відповідальності - я працюю для партнера HP BTO та Adaptive


2

ПРИМІТКА Зовсім інше сприймайте проблему!

cron є старим і незграбним у певних термінах.

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

Залежності Inter Host можна вирішити "чергами на сповіщення".

"Реальні" події, що базуються на часі, трохи складніше, саме це і є cron (і це дуже добре, принаймні щодо невеликих середовищ). Там, де складно впоратися з ідеєю, є запобігання гикавці. Як у: щовечора о 0100 год робіть знімок. Можливо, ви побачите якісь спайкові навантаження або багато невдалих реєстрацій в той самий момент, що придушили всю вашу інфраструктуру. Якщо у вас є підхід, що базується на черзі, ви отримаєте принаймні якісь відхилення безкоштовно (хоча це не гарантується - якщо тільки це не реалізує якась логіка).

Що потрібно обійти, це те, що без роботи в режимі реального часу ви не можете розраховувати на такі речі: так, мої резервні копії почнуться о 0200 год, і якщо вони все ще працюватимуть на 0400 год, щось не так. Що простіше зробити, це переконатися, що жодне 2 завдання, яке перешкоджає виконанню одночасно. Просто зробіть блокуючий агент, який буде споживати лише одну роботу за один раз.

Керувальною частиною буде якийсь приємний веб-інтерфейс, де завдання можна подавати або на вимогу, або - тепер він повертається до "cron" або вашої улюбленої його реалізації, кварцовий планувальник java має деталізацію на секунди AFAIK - для Часто основна частина просто використовувати добрий старий cron :)

Будь ласка, не оскаржуйте мене за те, що я є OT - це досить груба концепція, але оскільки питання не виключає грошей, можна також витратити гроші, щоб отримати рішення на точні внутрішні потреби, створивши щось, а не витрачаючи гроші гроші, купуючи щось там, де продавець думає, що це виконує деякі вимоги :)


Це цікаво для розподілу великих робочих місць, але мої роботи набагато тимчасовіші. У мене є деякі робочі місця, які можна було б встановити на черзі, як це, тому я буду пам'ятати про це.
Cakemox

1

Я використовував Еспресо (Кіберформація) від Каліфорнії. Не впевнений, як вони зараз це називають. Я також використовував UC4. Вони обидва працюють, коштують чималих грошей (наскільки я розумію), і можуть бути ведмедиком для підтримання, але вони роблять те, що йдеться на тині. / Редагувати - пропустив, що ви сказали, що комерційні програми занадто дорогі. З певним погодженням можу погодитись, але для деяких компаній воно того варте, особливо коли це стосується бізнес-додатків, які заробляють гроші.


1

Я працював з відкритим вихідним кодом Планувальник робочих місць як варіант заміни центрального кронт-версії 2000+ у виробничих умовах. З Cron все настільки ускладнилося, що ми не змогли визначити, що таке вікна простоїв або як боротися з міжсерверними залежностями. Цей продукт допомагав, але був трохи складним у налаштуванні.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.