Wie konvertiere ich Linux-Cron-Jobs auf "Amazon-Art"?

Ob gut oder schlecht, wir haben unsere gesamte LAMP- Webanwendung von dedizierten Computern in die Cloud (Amazon EC2-Computer) migriert . Bisher läuft es großartig, aber die Art und Weise, wie wir Cron machen, ist nicht optimal. Ich habe eine Amazon-spezifische Frage zur optimalen Verwaltung von Cron-Jobs in der Cloud mithilfe von "Amazon".

Das Problem : Wir haben mehrere Webserver und müssen Cron für Batch-Jobs 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 einem Computer ausgeführt werden, da sie häufig in die Datenbank schreiben, sodass die Ergebnisse dupliziert werden, wenn sie auf mehreren Computern ausgeführt werden.

Bisher haben wir einen der Webserver als "Master-Webserver" bezeichnet und er hat einige "spezielle" Aufgaben, die die anderen Webserver nicht haben. Der Kompromiss für Cloud Computing ist die Zuverlässigkeit - wir wollen keinen "Master-Webserver", weil es sich um eine einzelne Fehlerquelle handelt. Wir möchten, dass sie alle identisch sind und in der Lage sind, zu skalieren und zu verkleinern, ohne daran zu denken, den Master-Webserver nicht aus dem Cluster zu entfernen.

Wie können wir unsere Anwendung neu gestalten, um Linux-Cron-Jobs in vorübergehende Arbeitselemente umzuwandeln, die keinen einzigen Fehlerpunkt haben?

Meine bisherigen Ideen:

• Lassen Sie eine Maschine nur Cron laufen. Dies wäre etwas überschaubarer, aber dennoch ein Single-Point-of-Failure und würde etwas Geld mit einer zusätzlichen Instanz verschwenden.
• Einige Jobs könnten möglicherweise von Linux-Cron auf MySQL Events verschoben werden, aber ich bin kein großer Fan dieser Idee, da ich keine Anwendungslogik in die Datenbankebene einfügen möchte.
• Vielleicht können wir alle Cron auf allen Computern ausführen, aber unsere Cron-Skripte so ändern, dass sie alle mit einer Logik beginnen, die einen Sperrmechanismus implementiert, sodass nur ein Server tatsächlich Maßnahmen ergreift und die anderen einfach überspringen. Ich bin kein Fan dieser Idee, da sie möglicherweise fehlerhaft klingt und ich lieber eine bewährte Methode von Amazon verwenden würde, als unsere eigene zu rollen.
• Ich stelle mir eine Situation vor, in der Jobs irgendwo geplant, einer Warteschlange hinzugefügt werden und dann die Webserver jeweils Arbeiter sein können, die sagen können: "Hey, ich nehme diese". Amazon Simple Workflow Service klingt genau so, aber ich weiß derzeit nicht viel darüber, daher wären Einzelheiten hilfreich. Es scheint ein bisschen schwer 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 mir das Amazon Simple Workflow Service- Webinar auf YouTube angesehen und um 34:40 Uhr ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) festgestellt, dass ich einen Blick auf a erhascht habe Folie mit Cron-Jobs als Beispielanwendung. Auf der Dokumentationsseite " AWS Flow Framework-Beispiele für Amazon SWF " gibt Amazon an, Beispielcode für Crones zu haben:

... > Cron-Jobs In diesem Beispiel führt ein lang laufender Workflow regelmäßig eine Aktivität aus. Die Fähigkeit, Ausführungen als neue Ausführungen fortzusetzen, sodass eine Ausführung über einen sehr langen Zeitraum ausgeführt werden kann, wird demonstriert. ...

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

Das Problem ist, wenn ich ehrlich bin, dass dies nicht wirklich hilft, da ich es mit meinen Fähigkeiten 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 bin ich immer noch auf der Suche nach Ratschlägen oder Tipps.

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

Tom

Ich habe einige meiner Kollegen kurz befragt und bin leer auf dem Cron gelandet, aber nachdem ich darauf geschlafen habe, wurde mir klar, dass der wichtige Schritt möglicherweise auf das Sperren beschränkt ist. Also suchte ich nach "Distributed Cron Job Locking" und fand einen Verweis 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-successfully-scaling-with-scalr-on-amazon-by-se.html

Ich habe auch Hinweise auf die Verwendung von memcached oder eines ähnlichen Caching-Mechanismus als Möglichkeit zum Erstellen von Sperren mit einer TTL gesehen. Auf diese Weise setzen Sie ein Flag mit einer TTL von 300 Sekunden, und kein anderer Cron-Worker führt den Job aus. Die Sperre wird automatisch aufgehoben, nachdem die TTL abgelaufen ist. Dies ist konzeptionell der gestern besprochenen SQS-Option sehr ähnlich.

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

Lassen Sie mich wissen, ob dies hilfreich ist, und stellen Sie Fragen. Wir sind uns sehr bewusst, dass unsere Services sowohl für Anfänger als auch für erfahrene Entwickler komplex und entmutigend sein können. Wir beraten Sie gerne gerne zu Architektur und Best Practices.

Freundliche Grüße,

Ronan G. Amazon Webdienste

Ich denke, dieses Video beantwortet Ihre genaue Frage - cronjobs the aws way (skalierbar und fehlertolerant):

Verwenden von Cron in der Cloud mit Amazon Simple Workflow

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

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

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 werde ich jede Nachricht erhalten?

Amazon SQS ist so konzipiert, dass alle Nachrichten in seinen Warteschlangen mindestens einmal zugestellt werden. Obwohl die meiste Zeit jede Nachricht genau einmal an Ihre Anwendung übermittelt wird, sollten Sie Ihr System so gestalten, dass die mehrmalige Verarbeitung einer Nachricht keine Fehler oder Inkonsistenzen verursacht.

Bisher kann ich über die Lösung nachdenken, bei der eine Instanz mit Gearman Job Server-Instanz installiert ist: http://gearman.org/ . Auf demselben Computer konfigurieren Sie Cron-Jobs, die Befehle erzeugen, um Ihre Cronjob-Aufgabe im Hintergrund auszuführen. Dann beginnt einer Ihrer Webserver (Mitarbeiter) mit der Ausführung dieser Aufgabe. Dies garantiert, dass nur einer sie ü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, es sei denn, Sie konfigurieren ihn mit verteiltem Speicher, z. B. mithilfe von Memcached oder einer Datenbank
• Wenn Sie dann mehrere Gearman-Server verwenden, müssen Sie einen auswählen, der eine Aufgabe über Cronjob erstellt. Wir sind also wieder bei demselben Problem. Aber wenn Sie mit dieser Art von Single Point of Failure mit Gearman leben können, scheint dies eine gute Lösung zu sein. Vor allem, dass Sie dafür keine große Instanz benötigen (in unserem Fall reicht eine Mikroinstanz aus).

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

AWS Elastic Beanstalk unterstützt regelmäßige Aufgaben für
Ebenen der Arbeitsumgebung in Umgebungen, in denen eine vordefinierte Konfiguration mit einem Lösungsstapel ausgeführt wird, der den Containernamen "v1.2.0" enthält. ""

Sie können jetzt eine Umgebung erstellen, die eine cron.yamlDatei enthält, in der Planungsaufgaben 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 Aufruf in die SQS-Warteschlange gestellt und die Nachricht in der Warteschlange wird nur einmal ausgewertet. In den Dokumenten wird angegeben, dass die Ausführung möglicherweise verzögert wird, wenn in SQS viele Nachrichten verarbeitet werden müssen.

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 habe immer noch das Gefühl, dass AWS hier eine Funktion fehlt.

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

• 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-initSkripte, um die Cronjobs zum Laufen zu bringen. Dies ist natürlich mit Ausfallzeiten verbunden, die zu verpassten Cronjobs führen (wenn bestimmte Aufgaben wie wir jede Minute ausgeführt werden).
• Verwenden Sie die verwendete Logik rcron. Natürlich ist die Magie nicht wirklich an rcronsich, sondern in der Logik, die Sie verwenden, um einen fehlerhaften Knoten zu erkennen (wir verwenden ihn keepalivedhier) und einen anderen Knoten zum Master zu "upgraden".

Wir haben uns für die zweite Option entschieden, einfach weil sie 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 herkömmlichen Cronjob-Ansatz mit einem Knoten zu ersetzen, bei dem das Timing der entscheidende Faktor 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 Job B" einmal pro Minute laufen " ). Wenn Sie Cronjobs Trigger - Batch-Verarbeitungslogik verwenden, sollten Sie wirklich einen Blick auf SQS. Es gibt kein Aktiv-Passiv-Dilemma, dh Sie können einen einzelnen Server oder eine gesamte Belegschaft verwenden, um Ihre Warteschlange zu verarbeiten. Ich würde auch vorschlagen, nach SWFeiner Skalierung Ihrer Belegschaft zu suchen (obwohl auto scalingdies in den meisten Fällen auch möglich ist).

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

Am 12. Februar 16 bloggte Amazon über das Planen von SSH-Jobs mit AWS Lambda . Ich denke, das beantwortet die Frage.

Wenn Sie bereits einen Redis-Dienst eingerichtet haben, scheint dies eine gute Lösung zu sein:

https://github.com/kvz/cronlock

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

Die "Amazon" -Methode soll verteilt werden, was bedeutet, dass sperrige Crones in viele kleinere Jobs aufgeteilt und an die richtigen Maschinen übergeben werden sollten.

Kleben Sie die SQS-Warteschlange mit dem auf FIFO eingestellten Typ zusammen, um sicherzustellen, dass jeder Job nur von einem Computer ausgeführt wird. Es toleriert auch Fehler, da die Warteschlangen gepuffert werden, bis sich ein Computer wieder dreht.

Genau einmalige FIFO-Verarbeitung : Eine Nachricht wird einmal zugestellt und bleibt verfügbar, bis ein Verbraucher sie verarbeitet und löscht. Duplikate werden nicht in die Warteschlange aufgenommen.

Überlegen Sie auch, ob Sie diese Vorgänge wirklich stapeln müssen. Was passiert, wenn die Updates einer Nacht erheblich größer sind als erwartet? Selbst bei dynamischer Beschaffung kann sich Ihre Verarbeitung verzögern und darauf warten, dass genügend Maschinen hochgefahren werden. Speichern Sie stattdessen Ihre Daten in SDB, benachrichtigen Sie Computer über Aktualisierungen über SQS und erstellen Sie Ihren RSS-Feed im laufenden Betrieb (mit Caching).

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

Warum sollten Sie Ihre eigenen bauen? Warum nicht so etwas wie Quarz verwenden (mit Clustered Scheduling)? Siehe Dokumentation.

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

Wir haben einen bestimmten Server, der Teil unseres Webanwendungsclusters ist, hinter einem ELB, dem auch ein bestimmter DNS-Name zugewiesen wurde, damit wir die Jobs auf diesem einen bestimmten Server ausführen können. Dies hat auch den Vorteil, dass wenn dieser Job dazu führt, dass der Server langsamer wird, die ELB ihn aus dem Cluster entfernt und ihn dann zurückgibt, sobald der Job beendet ist und er wieder fehlerfrei wird.

Funktioniert wie ein Champion.

Eine Methode, um zu überprüfen, ob Ihr Cron-Ausdruck auf Amazon-Weise funktioniert, besteht darin, ihn über den Befehl events auszuführen. Beispielsweise:

aws events put-rule --name "DailyLambdaFunction" --schedule-expression "<your_schedule_expression>

Wenn Ihr Zeitplanausdruck ungültig ist, schlägt dies fehl.

Weitere Ressourcen: https://docs.aws.amazon.com/cli/latest/reference/events/put-rule.html

Wenn Sie bereit sind, einen Nicht-AWS-Dienst zu verwenden, können Sie Microsoft Azure ausprobieren . Azure bietet einen hervorragenden Jobplaner .

Da niemand CloudWatch Event erwähnt hat , würde ich sagen, dass dies die AWS-Methode für Cron-Jobs ist. Es kann viele Aktionen ausführen, z. B. Lambda-Funktion, ECS-Task.