it-swarm.com.de

Wie konvertiert man Linux-Cron-Jobs auf "Amazon-Art"?

Zum Guten oder Schlechten haben wir unsere gesamte LAMP -Webanwendung von dedizierten Computern in die Cloud (Amazon EC2-Computer) migriert. Es geht soweit gut, aber die Art, wie wir crons tun, ist suboptimal. Ich habe eine Amazon-spezifische Frage, wie man Cron-Jobs in der Cloud auf "Amazon-Weise" am besten verwaltet.

Das Problem: Wir haben mehrere Webserver und müssen Crons für Stapeljobs ausführen, z. B. das Erstellen von RSS-Feeds, das Auslösen von E-Mails und viele andere Dinge. ABER die cron-Jobs müssen nur auf einer Maschine ausgeführt werden, da sie häufig in die Datenbank schreiben, sodass die Ergebnisse bei mehreren Maschinen dupliziert werden.

Bisher haben wir einen der Webserver als "Master-Webserver" bezeichnet und er hat einige "spezielle" Aufgaben, die die anderen Webserver nicht haben. Beim Cloud Computing geht es um Zuverlässigkeit. Wir wollen keinen "Master-Webserver", da dies ein zentraler Fehler ist. Wir möchten, dass sie alle identisch sind und in der Lage sind, Upscale und Downscale durchzuführen, ohne sich daran zu erinnern, den Master-Webserver nicht aus dem Cluster zu entfernen.

Wie können wir unsere Anwendung neu gestalten, um Linux-Cron-Jobs in temporäre Arbeitselemente umzuwandeln, die keinen einzigen Ausfallpunkt haben?

Meine bisherigen Ideen:

  • Besitze eine Maschine, die nur für das Laufen von crons bestimmt ist. Dies wäre ein wenig überschaubarer, wäre aber immer noch ein Single-Point-of-Failure und würde mit einer zusätzlichen Instanz etwas Geld verschwenden.
  • Es ist denkbar, dass einige Jobs von Linux crons nach MySQL Events verschoben werden können. Ich bin jedoch kein großer Fan dieser Idee, da ich die Anwendungslogik nicht in die Datenbankebene integrieren möchte.
  • Vielleicht können wir alle crons auf allen Rechnern ausführen, aber unsere cron-Skripte ändern, sodass alle mit etwas Logik beginnen, die einen Sperrmechanismus implementiert, sodass nur ein Server tatsächlich aktiv wird und die anderen einfach überspringen. Ich bin kein Fan dieser Idee, da sie sich möglicherweise als fehlerhaft anhört und ich würde es vorziehen, eine Amazon-Best-Practice zu verwenden, anstatt unsere eigene zu rollen.
  • Ich stelle mir eine Situation vor, in der Jobs irgendwo geplant werden, zu einer Warteschlange hinzugefügt werden und dann die Webserver jeweils ein Arbeiter sein könnten, der sagen kann "Hey, ich nehme das hier". Amazon Simple Workflow Service klingt genau so, aber ich weiß im Moment nicht viel darüber, daher wären Besonderheiten hilfreich. Es scheint ein schweres Gewicht für etwas so Einfaches wie ein Cron? Ist es der richtige Dienst oder gibt es einen geeigneteren Amazon-Dienst?

Update: Seit ich die Frage gestellt habe, habe ich das Amazon Simple Workflow Service - Webinar auf YouTube angesehen und um 34:40 ( http://www.youtube.com/watch?v) festgestellt = lBUQiek8Jqk # t = 34m40s ) Ich konnte einen Blick auf eine Folie werfen, in der Cron-Jobs als Beispielanwendung erwähnt wurden. Amazon sagt auf seiner Dokumentationsseite " AWS Flow Framework-Beispiele für Amazon SWF ", dass sie Beispielcode für crons haben:

... > Cron-Jobs In diesem Beispiel wird regelmäßig ein langwieriger Workflow ausgeführt führt eine Aktivität aus. Die Möglichkeit, die Ausführung als neu fortzusetzen Ausführungen, so dass eine Ausführung sehr lange von .__ ausgeführt werden kann. Zeit ist demonstriert . ...

Ich habe das AWS SDK für Java heruntergeladen ( http://aws.Amazon.com/sdkforjava/ ) und zwar in einer lächerlichen Schicht von Ordnern versteckt, gibt es Java-Code (aws-Java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow).

Das Problem ist, wenn ich ehrlich bin, hilft das nicht wirklich, da ich es mit meinem Skillset nicht leicht verdauen kann. Das gleiche Beispiel fehlt im PHP SDK und es scheint kein Tutorial zu geben, das den Prozess durchläuft. Im Grunde suche ich immer noch nach Ratschlägen oder Tipps.

109
Tom

Amazon hat am 12/Feb/16 über Einplanung von SSH-Jobs mit AWS Lambda geschrieben. Ich denke, das beantwortet die Frage.

6
Tom

Ich habe mich beim Amazon Gold-Support angemeldet, um ihnen diese Frage zu stellen. Dies war ihre Antwort:

Tom

Ich habe eine kurze Umfrage bei einigen meiner Kollegen gemacht und bin am .__ leer. cron, aber nachdem ich darauf geschlafen hatte, wurde mir klar, dass der wichtige Schritt .__ sein kann. begrenzt auf Verriegelung. Also suchte ich nach "Distributed Cron Job Locking" und fand einen Hinweis auf Zookeeper, ein Apache-Projekt.

http://zookeeper.Apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-erfolgreich-skalieren-mit-scalr-on-Amazon-by-se.html

Ich habe auch einen Hinweis auf die Verwendung von memcached oder einer ähnlichen Zwischenspeicherung gesehen Mechanismus als Möglichkeit zum Erstellen von Sperren mit einer TTL. Auf diese Weise setzen Sie eine flag, mit einer TTL von 300 Sekunden und kein anderer Cron-Worker wird ausgeführt die Arbeit. Die Sperre wird automatisch aufgehoben, nachdem TTL abgelaufen. Dies ist konzeptionell der SQS-Option we .__ sehr ähnlich. gestern diskutiert.

Siehe auch; Googles Chubby http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

Lassen Sie mich wissen, wenn dies hilft, und zögern Sie nicht, Fragen zu stellen, wir sind sehr Wir sind uns bewusst, dass unsere Dienstleistungen für beide Anfänger komplex und entmutigend sein können und erfahrene Entwickler gleichermaßen. Wir bieten immer gerne an Beratung zu Architektur und Best Practice.

Freundliche Grüße,

Ronan G. Amazon Web Services

36
Tom

Ich denke, dass dieses Video Ihre genaue Frage beantwortet - Cronjobs wie Aws (skalierbar und fehlertolerant):

Cron in der Cloud mit Amazon Simple Workflow verwenden

Das Video beschreibt den Dienst SWF anhand des speziellen Anwendungsfalls der Implementierung von Cronjobs.

Die relative Komplexität der Lösung kann schwer zu schlucken sein, wenn Sie direkt von einer Crontab kommen. Am Ende gibt es eine Fallstudie, die mir half zu verstehen, was diese zusätzliche Komplexität für Sie bedeutet. Ich würde empfehlen, die Fallstudie zu betrachten und Ihre Anforderungen an Skalierbarkeit und Fehlertoleranz zu prüfen, um zu entscheiden, ob Sie von Ihrer vorhandenen Crontab-Lösung migrieren sollten.

13
Nathan Buesgens

Seien Sie vorsichtig bei der Verwendung von SQS für Cronjobs, da diese nicht garantieren, dass nur "ein Job von nur einer Maschine gesehen wird". Sie garantieren, dass "mindestens einer" die Nachricht erhält.

Von: http://aws.Amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

F: Wie oft bekomme ich jede Nachricht?

Amazon SQS ist so konzipiert, dass alle Nachrichten in den Warteschlangen mindestens einmal geliefert werden. Obwohl die meisten Nachrichten genau einmal an Ihre Anwendung übermittelt werden, sollten Sie Ihr System so gestalten, dass durch die mehrfache Verarbeitung einer Nachricht keine Fehler oder Inkonsistenzen entstehen.

Bisher kann ich über die Lösung nachdenken, bei der Sie eine Instanz mit Gearman Job Server-Instanz installiert haben: http://gearman.org/ . Auf demselben Computer konfigurieren Sie Cron-Jobs, die den Befehl zum Ausführen Ihrer Cronjob-Aufgabe im Hintergrund ausführen. Dann startet einer Ihrer Webserver (Worker) diese Aufgabe und garantiert, dass nur einer diese Aufgabe übernimmt. Es spielt keine Rolle, wie viele Mitarbeiter Sie haben (insbesondere wenn Sie die automatische Skalierung verwenden).

Die Probleme mit dieser Lösung sind:

  • Der Gearman-Server ist ein Single-Point-of-Failure-Problem, sofern Sie ihn nicht mit verteiltem Speicher konfigurieren, z. B. mit memcached oder einer Datenbank
  • Wenn Sie mehrere Gearman-Server verwenden, müssen Sie einen Server auswählen, der die Aufgabe über cronjob erstellt, sodass wir uns wieder mit dem gleichen Problem beschäftigen. Aber wenn Sie mit dieser Art von Single Point of Failure mit Gearman leben können, sieht das nach einer ziemlich guten Lösung aus. Insbesondere, dass Sie keine große Instanz dafür benötigen (in unserem Fall genügt die Mikroinstanz). 
11
Maciej Majewski

Amazon hat gerade veröffentlicht neue Funktionen für Elastic Beanstalk. Aus den docs :

AWS Elastic Beanstalk unterstützt periodische Aufgaben für die Mitarbeiterumgebung
Ebenen in Umgebungen, in denen eine vordefinierte Konfiguration mit einem Lösungsstapel ausgeführt wird, der im Containernamen "v1.2.0" enthält. "

Sie können jetzt eine Umgebung erstellen, die eine cron.yaml-Datei enthält, in der Zeitplanungsaufgaben konfiguriert werden:

version: 1
cron:
- name: "backup-job"          # required - unique across all entries in this file
  url: "/backup"              # required - does not need to be unique
  schedule: "0 */12 * * *"    # required - does not need to be unique
- name: "audit"
  url: "/audit"
   schedule: "0 23 * * *"

Ich würde mir vorstellen, dass die Versicherung, es nur einmal in einer automatisch skalierten Umgebung auszuführen, über die Nachrichtenwarteschlange (SQS) genutzt wird. Wenn der Cron-Daemon ein Ereignis auslöst, wird dieser Anruf in die SQS-Warteschlange gestellt, und die Nachricht in der Warteschlange wird nur einmal ausgewertet. In den Dokumenten heißt es, dass die Ausführung verzögert werden könnte, wenn SQS viele Meldungen verarbeiten muss.

10
user541905

Ich bin jetzt zum dritten Mal auf diese Frage gestoßen und dachte, ich würde mich einmischen. Wir haben dieses Dilemma jetzt schon eine Weile. Ich bin immer noch der Meinung , dass in AWS eine Funktion fehlt.

In unserem Fall entschieden wir uns nach Prüfung der möglichen Lösungen für zwei Optionen:

  • Richten Sie einen Cronjob-Server ein, auf dem die Jobs ausgeführt werden, die jeweils nur einmal ausgeführt werden sollen, skalieren Sie ihn automatisch und stellen Sie sicher, dass er ersetzt wird, wenn bestimmte CloudWatch-Statistiken nicht den Anforderungen entsprechen. Wir verwenden cloud-init Skripte, um die Cronjobs zum Laufen zu bringen. Dies hat natürlich Ausfallzeiten zur Folge, die zu verpassten Cronjobs führen (wenn Sie bestimmte Aufgaben wie wir jede Minute ausführen).
  • Verwenden Sie die von rcron verwendete Logik. Natürlich liegt die Magie nicht wirklich in rcron selbst, sondern in der Logik, die Sie verwenden, um einen fehlerhaften Knoten zu erkennen (wir verwenden keepalived hier) und einen anderen Knoten zu "upgraden", um ihn zu meistern.

Wir haben uns für die zweite Option entschieden, weil sie einfach hervorragend schnell ist und wir bereits Erfahrung mit Webservern hatten, die diese Cronjobs ausführen (in unserer Zeit vor AWS).

Natürlich ist diese Lösung speziell dafür gedacht, den traditionellen Einknoten-Cronjob-Ansatz zu ersetzen, bei dem das Timing entscheidend ist (z. B. "Ich möchte, dass Job A einmal täglich um 5 Uhr morgens ausgeführt wird" . oder wie in unserem Fall "Ich möchte, dass Job B einmal pro Minute ausgeführt wird" ). Wenn Sie Cronjobs verwenden, um die Stapelverarbeitungslogik auszulösen, sollten Sie sich wirklich SQS ansehen. Es gibt kein aktiv-passives Dilemma, dh Sie können einen einzelnen Server oder eine gesamte Belegschaft für die Verarbeitung Ihrer Warteschlange verwenden. Ich würde auch vorschlagen, sich SWF anzusehen, um Ihre Belegschaft zu skalieren (obwohl auto scaling in den meisten Fällen ebenfalls dazu in der Lage sein könnte).

Abhängig von einem anderen Dritten wollten wir dies vermeiden.

6
Jaap Haagmans

Der "Amazon" Weg soll verteilt werden, was bedeutet, dass sperrige Crons in viele kleinere Jobs aufgeteilt und den richtigen Maschinen übergeben werden müssen. Durch das Zusammenkleben mit SQS wird sichergestellt, dass jeder Job nur von einer Maschine gesehen wird. Es toleriert auch einen Fehler, da die Warteschlangen puffern, bis eine Maschine wieder hochfährt.

Überlegen Sie auch, ob Sie diese Vorgänge wirklich "stapeln" müssen. Was passiert, wenn die Aktualisierungen einer Nacht erheblich größer sind als erwartet? Selbst bei dynamischer Ressourcennutzung kann es zu Verzögerungen bei der Verarbeitung kommen, bis genügend Maschinen hochgefahren werden. Speichern Sie Ihre Daten stattdessen in SDB, benachrichtigen Sie Maschinen über SQS-Updates und erstellen Sie Ihren RSS-Feed "on the fly" (mit Zwischenspeicherung).

Stapeljobs stammen aus einer Zeit, in der die Verarbeitungsressourcen begrenzt waren und "Live" -Dienste Vorrang hatten. In der Cloud ist dies nicht der Fall.

4
vsekhar

Wenn Sie bereits einen Redis-Dienst eingerichtet haben, sieht dies nach einer guten Lösung aus:

https://github.com/kvz/cronlock

Lesen Sie mehr: http://kvz.io/blog/2012/12/31/lock-your-cronjobs/

4
barbolo

Warum baust du dein eigenes? Warum nicht so etwas wie Quarz verwenden (mit Clustered Scheduling)? Siehe Dokumentation.

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering

1
Rama Nallamilli

Was wir tun, ist, dass wir einen bestimmten Server haben, der Teil unseres Webanwendungsclusters hinter einer ELB ist, der auch einen bestimmten DNS-Namen zugewiesen hat, damit wir die Jobs auf diesem einen Server ausführen können. Dies hat auch den Vorteil, dass der ELB den Server aus dem Cluster entfernt und ihn zurückbringt, wenn der Job langsamer wird, sobald der Job abgeschlossen ist und wieder gesund wird.

Funktioniert wie ein Champion.

1
Patrick Steil

Wenn Sie einen Nicht-AWS-Dienst verwenden möchten, checken Sie Microsoft Azure aus. Azure bietet einen guten Job-Scheduler .

0
johnnyodonnell

Da niemand CloudWatch Event erwähnt hat, würde ich sagen, dass dies der AWS-Weg ist, Cron-Jobs auszuführen. Es können viele Aktionen ausgeführt werden, z. B. Lambda-Funktion, ECS-Task.

0
wanghq