Outgrowing cron: jaki jest następny harmonogram? [Zamknięte]

Używamy crona od tak długo, jak pamiętam, aby obsłużyć wszystkie nasze potrzeby w zakresie planowania zadań. Wszystko, od klonów pamięci / migawek po raporty baz danych, codzienne raporty systemowe i kontrole monitorowania są zaplanowane na kilkuset serwerach za pośrednictwem crona.

Wady są dość oczywiste: trudne w zarządzaniu zadaniami, nie ma łatwego sposobu na tworzenie zależności (szczególnie na różnych serwerach), i oczywiście jest nieuniknione, że ktoś „tymczasowo” pominie zadanie, ale później zapomni o usunięciu komentarza.

Wypróbowaliśmy ofertę komercyjną, ale ostatecznie uznano ją za zbyt kosztowną w porównaniu z cronem.

Widzę inne opcje, takie jak SLURM, Oracle Grid Engine, Torque / Maui, Quartz, DIET, Condor, które wydają się być ukierunkowane na większe, bardziej jednorodne środowiska klastrowe z zadaniami, które działałyby na dowolnej liczbie podobnych węzłów: grid computing i tym podobne. Nasze środowisko jest dość zróżnicowane (różne Linuxes, AIX i FreeBSD) i musimy stworzyć zależności między różnymi typami systemów (np. Zadanie na komputerze z systemem Linux może wymagać ustalenia, czy zadanie na komputerze z systemem AIX powinno zostać uruchomione).

Czy ktoś ma jakieś doświadczenie w przechodzeniu z crona do bardziej centralnie zarządzanej oferty? Wszelkie wskazówki dotyczące wyboru oprogramowania lub tego, czy lepiej przejść na oprogramowanie open source czy komercyjne?

Condor, OGE i Torque mogą cię tam dostać, ale tylko Condor ma wbudowane zarządzanie zależnościami za pomocą narzędzia DAGMan . DAGMan pozwala skonfigurować ukierunkowany, acykliczny wykres opisujący przebieg pracy, a kierownik dba o przechodzenie między zadaniami w przepływie pracy i ocenę wyników pozytywnych / negatywnych na każdym etapie przepływu. Condor jest względnie niezależny od platformy, co oznacza, że ​​DAGMan też. Z pewnością można uruchomić jeden krok podrzędny w systemie AIX, gdy rodzic działa w systemie Linux lub Windows. DAGMan nie przejmuje się tym, gdzie uruchamiane są zadania, tylko to, że kody wyjścia są przekazywane lub nie.

Wszelkie wskazówki dotyczące wyboru oprogramowania lub tego, czy lepiej przejść na oprogramowanie open source czy komercyjne?

Z pewnymi zastrzeżeniami uważam, że warto przyjrzeć się wolnym społecznościom w tej przestrzeni.

OGE jest teraz w dziwnej przestrzeni. Uruchomienie wariantu GE produkowanego przez Oracle nie jest już darmowe, a Oracle nie dodaje już kodu, który zapisuje z powrotem w GE SCC, ale istnieje kilka rozwidleń kodu, które próbują wykorzystać jako bezpłatne projekty typu open source. W szczególności Univa przewodził tej sprawie , zatrudniając byłych twórców Sun GE, aby kontynuowali pracę nad otwartym, ogólnodostępnym wariantem GE. Silnik Grid Engine ma dwie rzeczy: jest łatwy w konfiguracji, może obsłużyć krótkotrwałe (<2 minuty) zadania bez nadmiernego nakładania harmonogramu na zadania, które spowalniają wydajność. Wielką wadą jest to, że nie ma bardzo dobrego wsparcia dla systemu Windows. Niektórzy z nas starali się przenieść go na Cygwina wiele lat temu, ale na pewno nie jest tak dobry jak native.

Teraz Condor jest moją ulubioną z trzech wspomnianych technologii. Wokół Condor istnieje silna społeczność, a oprogramowanie jest bardzo dojrzałe (teraz> 20 lat). Natywna obsługa systemów operacyjnych Windows i POSIX oznacza, że ​​działa bardzo dobrze wszędzie. Wspomniany DAGMan jest tylko jednym z wielu wspaniałych elementów, które są dostarczane z Condorem. Konfiguracja może być skomplikowana, ale kiedy jest już uruchomiona i działa, jest niesamowicie solidny. Ma niewiarygodnie elastyczny język do wykonywania zadań <-> dopasowywania maszyn i budowania reguł użytkowania zasobów. Obsługuje także dynamiczne przydzielanie na komputerach, umożliwiając zadaniom wybranie potrzebnych zasobów maszyn, a następnie ponownie reklamując różnicę jako wciąż dostępną. Obsługuje globalne liczniki zasobów, dzięki czemu można ograniczyć się do takich rzeczy, jak licencje na oprogramowanie. I oczywiście, ma DAGMan, który jest niezwykle potężnym narzędziem do zarządzania przepływem pracy. Wadą Condora jest to, że narzut związany z planowaniem krótkich zadań może być uciążliwy. Idealnie potrzebujesz zadań, które trwają dłużej niż 2 minuty, w przeciwnym razie planowanie zacznie stanowić dużą część czasu pracy w systemie.

Torque jest trochę bardziej niszowy. Obawiam się, że mniej wiem. Porównuje bardziej do silnika sieciowego niż Condora. Istnieją płatne dodatki wspomniane przez @warren, które mogą rozszerzyć to, co może zrobić podstawowa, darmowa Torque.

Jeśli chcesz wypróbować trzy technologie i sprawdzić, jak działają one z Twoimi konkretnymi obciążeniami, CycleCloud może rozdzielić bezpieczne, zwirtualizowane pule, które są wstępnie skonfigurowane z Condor, GridEngine lub Torque - więc nie marnuj czasu na wymyślanie tego. z Twojej strony. Rozbudowanie małych pul każdej technologii i wypróbowanie ich przy reprezentatywnych obciążeniach zajęłoby kilka dolarów. (Uwaga: Pracuję dla Cycle Computing, tworzymy CycleCloud)

Chronos wygląda bardzo obiecująco.

Chronos zastępuje crona przez Airbnb. Jest to rozproszony i odporny na awarie harmonogram działający na platformie Apache Mesos. Możesz go użyć do koordynowania zadań. Obsługuje niestandardowe executory Mesos, a także domyślny executor poleceń. Dlatego domyślnie Chronos wykonuje skrypty sh (w większości systemów bash). Chronos może być używany do interakcji z systemami, takimi jak Hadoop (w tym EMR), nawet jeśli niewolnicy Mesos, na których odbywa się wykonanie, nie mają zainstalowanego Hadoop. Dołączone skrypty otoki umożliwiają przesyłanie plików i wykonywanie ich na zdalnym komputerze w tle oraz używanie asynchronicznych wywołań zwrotnych do powiadamiania Chronos o zakończeniu zadania lub niepowodzeniach.

Odniosłem również wielki osobisty sukces, używając Jenkinsa jako zamiennika crona. Ładnie radzi sobie z wykonywaniem zadań na zdalnych serwerach. Oto opis na ten temat: http://www.22ideastreet.com/blog/2014/05/02/replace-local-cron-with-jenkins/

Przez ostatnie 4,5 roku współpracowałem z platformą HP Automation Server Automation (reszta Opsware) oraz resztą pakietu Business Technology Optimization (Automatyzacja sieci, Operations Orchestration itp.).

W przypadku wystarczająco dużego środowiska zarządzanie zadaniami za pośrednictwem SA jest wysoce opłacalnym (i pożądanym) narzędziem. W połączeniu z OO, zadania mogą być kontrolowane poprzez zarządzanie zmianami, sprzedaż biletów itp.

Oto niezbyt zabawna część: jest drogo (bardzo drogo). Możesz sprawdzić niektóre sugestie w podobnym pytaniu, które zadałem kiedyś: narzędzia do zarządzania i kontroli serwera FLOSS .

Powiedziałbym również, że Torque / Maui / Moab (z Adaptive Computing ) są bardzo fajne: nie jestem pewien co do ceny, ale są również bardzo elastycznymi narzędziami.

UWAGA Zupełnie inne podejście do problemu!

cron jest stary i niezgrabny pod pewnymi warunkami.

Jeśli naprawdę szukasz nowych sposobów planowania, spróbuję czegoś opartego na oprogramowaniu pośredniczącym do przesyłania wiadomości. Pomyśl RabbitMQ z klientami na każdym serwerze.

Zależności między hostami można rozwiązać za pomocą „kolejek powiadomień”.

Zdarzenia oparte na czasie rzeczywistym są nieco trudniejsze, właśnie do tego służy cron (i jest całkiem dobry, przynajmniej w małych środowiskach). Trudno jest zdobyć się na pomysł, aby zapobiec czkawkom. Jak w: każdej nocy o 01:00 r. Rób migawkę. W tym momencie możesz zobaczyć pewne gwałtowne wzrosty obciążenia lub wiele nieudanych prób logowania. Jeśli masz podejście oparte na kolejce, otrzymasz co najmniej pewne odchylenie za darmo (chociaż nie jest to gwarantowane - chyba że jakaś logika to zaimplementuje).

Rzeczą do obejścia jest to, że bez zadań opartych na czasie rzeczywistym nie można polegać na takich rzeczach: tak, moje kopie zapasowe rozpoczną się o 0200 godzin, a jeśli nadal będą działać o 04:00, coś jest nie tak. Co łatwiej zrobić, to upewnić się, że nie zostaną uruchomione żadne 2 zakłócające zadania w tym samym czasie. Po prostu stwórz agenta blokującego, który będzie zużywał tylko jedno zadanie na raz.

Częścią zarządzającą byłby fajny interfejs WWW, w którym zadania można było przesyłać na żądanie, lub - teraz wraca do „cron” lub Twojej ulubionej implementacji, harmonogram kwarcowy Java ma szczegółowość w sekundach AFAIK - dla część oparta na czasie wystarczy użyć starego dobrego crona :)

Proszę nie głosować za to, że jestem OT - jest to dość szorstka koncepcja, ale ponieważ pytanie nie wyklucza pieniędzy, równie dobrze można wydać pieniądze, aby znaleźć rozwiązanie dla konkretnych wymagań wewnętrznych, tworząc coś zamiast wydawać pieniądze, kupując coś, co zdaniem sprzedawcy spełnia niektóre wymagania :)

Użyłem espresso (Cybermation) z CA. Nie jestem pewien, jak to teraz nazywają. Użyłem również UC4. Oba pracują, kosztują dużo pieniędzy (według mojego zrozumienia) i mogą być niedźwiedziem do utrzymania, ale robią to, co jest napisane na puszce. / Edycja - przegapiłem informację, że aplikacje komercyjne są zbyt drogie. Zdecydowanie mogę się zgodzić, ale w przypadku niektórych firm jest tego warta, szczególnie w przypadku aplikacji biznesowych, które zarabiają pieniądze.

Pracowałem z programem Open Source Job Scheduler jako opcją zastąpienia centralnej tabeli crontab 2000+ w środowisku produkcyjnym. Sprawy stały się tak skomplikowane w przypadku crona, że ​​nie mogliśmy ustalić, jakie były okna przestojów ani jak radzić sobie z zależnościami między serwerami. Ten produkt pomógł, ale jego konfiguracja była nieco skomplikowana.