Wie konvertiert man Linux-Cron-Jobs in "den Amazon-Weg"?

Für besser oder schlechter, wir haben migriert, unsere ganze LAMPE web-Anwendung vom eigenen Computer in die cloud (Amazon EC2 Maschinen). Es läuft gut so weit, aber die Art, wie wir crons ist sub-optimal. Ich habe einen Amazon-spezifische Frage, wie am besten zu verwalten, cron-jobs in der cloud mit "Amazon Art".

Das problem: Wir haben mehrere Webserver, und müssen laufen crons für batch-jobs, wie das anlegen RSS-feeds -, Trigger-E-Mails, viele verschiedene Dinge eigentlich. ABER die cron-jobs müssen nur auf einer Maschine, weil Sie oft in die Datenbank schreiben, so würde die doppelte Ergebnisse, wenn die Ausführung auf mehreren Maschinen.

So weit, wir als eines der den Webserver als "master-webserver" und es hat ein paar "Besondere" Aufgaben, die der andere Webserver nicht haben. Die trade-off für cloud computing ist die Zuverlässigkeit - wir wollen keinen "master-webserver", weil es einen single point of failure. Wir wollen, dass Sie alle identisch sein und in der Lage sein zu gehobenen und downscale ohne Erinnerung nicht zu nehmen, die der master-webserver aus dem cluster.

Wie können wir die Neugestaltung unserer Anwendung zum konvertieren von Linux-cron-jobs in vergänglichen Arbeitsaufgaben, die nicht über ein single point of failure?

Meine Ideen bisher:

  • Haben eine Maschine gewidmet, um nur die Laufenden crons. Dies wäre ein wenig mehr überschaubar, aber es würde immer noch ein single-point-of-failure, und würde verschwenden Geld haben eine extra-Instanz.
  • Einige Arbeitsplätze könnten möglicherweise verschoben werden von Linux crons zu MySQL-Veranstaltungen allerdings bin ich kein großer fan von dieser Idee, da ich nicht möchten, um die Anwendung von Logik in die Datenbank-Schicht.
  • Vielleicht können wir alle crons auf alle Maschinen, sondern ändern unser cron-Skripts, so dass Sie beginnen alle mit ein wenig Logik implementiert, dass ein locking-Mechanismus, so dass nur ein server tatsächlich tritt in Aktion, und die anderen einfach überspringen. Ich bin kein fan von dieser Idee, wie es klingt potenziell buggy, und ich würde lieber eine Amazon-best-practice-eher als rollende unsere eigenen.
  • Ich mir vorstelle, eine situation, wo die jobs werden irgendwo, einer Warteschlange Hinzugefügt und dann die Webserver-könnte jeder sein, ein Arbeiter, sagen kann "hey, I' ll take this one". Amazon Simple Workflow Service hört sich genau diese Art der Sache, aber ich derzeit nicht wissen viel über Sie, so dass keine Einzelheiten wären hilfreich. Es scheint Art von schweren Gewicht für etwas so einfaches wie ein cron? Ist es der richtige service ist oder ist es ein passender Amazon-service?

Update: Da die Frage, ich habe gesehen, das Amazon Simple Workflow Service webinar auf YouTube an und bemerkte mit 34:40 (http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s) ich fing einen Blick von einer Folie zu erwähnen, cron-jobs, wie eine Beispiel-Anwendung. In Ihrer Dokumentation Seite "AWS Flow Framework-Beispiele für Amazon SWF", Amazon, sagen, dass Sie Beispielcode für die crons:

...
> Cron-jobs In diesem Beispiel, eine lang laufende Workflows in regelmäßigen Abständen
führt eine Aktivität. Die Fähigkeit, auch weiterhin als neue Hinrichtungen
Ausführungen, so dass eine Hinrichtung ausführen können, für sehr lange Zeiträume
Zeit ist nachgewiesen.
...

Heruntergeladen ich das AWS SDK für Java (http://aws.amazon.com/sdkforjava/) und sicher genug, vergraben in einem lächerlich Schichten von Ordnern es gibt einige 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, bedeutet dies nicht wirklich helfen, da es nicht etwas ich kann leicht zu verdauen mit meinem skillset. Die gleiche Probe fehlt die PHP-SDK, und es scheint nicht zu sein ein tutorial, das geht, obwohl der Prozess. Also im Grunde bin ich immer noch auf der Jagd für Ratschläge oder Tipps.

Kommentar zu dem Problem

InformationsquelleAutor der Frage Tom | 2012-04-08

  1. 35

    Ich habe mich für Amazon Gold support, um Sie zu bitten, diese Frage, dies war Ihre Antwort:

    Tom

    Habe ich eine schnelle Umfrage von einigen meiner Kollegen und kam leer auf der
    cron, aber nach dem schlafen auf es der ich realisierte, dass der wichtige Schritt sein kann
    begrenzt zu sperren. Also suchte ich nach "verteiltes cron-job locking"
    und fand einen Verweis auf Tierpfleger, 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

    Außerdem habe ich gesehen, Verweis auf die Verwendung von memcached oder eine ähnliche Cache
    Mechanismus als ein Weg, um Schlösser mit einem TTL. Auf diese Weise setzen Sie ein
    Flagge, mit einer TTL von 300 Sekunden und keine andere cron-worker ausgeführt wird
    die job. Die Sperre wird automatisch freigegeben, nachdem die TTL hat
    abgelaufen. Dies ist konzeptionell sehr ähnlich wie die SQS-option, die wir
    gestern erörtert.

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

    Lassen Sie mich wissen, ob das hilft, und fühlen sich frei, Fragen zu stellen, wir sind sehr
    beachten Sie, dass unsere Dienstleistungen können Komplex sein und abschreckend für Anfänger
    und erfahrene Entwickler gleichermaßen. Wir sind immer glücklich zu bieten
    Architektur und best-practice-Empfehlungen.

    Beste Grüße,

    Ronan G. Amazon Web Services

    InformationsquelleAutor der Antwort Tom

  2. 12

    Ich denke, das video beantwortet genau Ihre Frage - cronjobs die aws-Art (scalable and fault-tolerant):

    Die Verwendung von Cron in der Cloud mit Amazon Simple Workflow

    Das video beschreibt die SWF - Dienst unter Verwendung der spezifischen Anwendungsfall der Implementierung von cronjobs.

    Die relative Komplexität der Lösung kann schwierig sein, zu schlucken, wenn Sie kommen gerade von einem crontab. Es ist eine Fallstudie, die am Ende das hat mir geholfen, zu verstehen, was das zusätzliche Komplexität kauft Sie. Ich würde vorschlagen, gerade die Fallstudie und unter Berücksichtigung Ihrer Anforderungen für die Skalierbarkeit und Fehlertoleranz zu entscheiden, ob Sie migrieren Ihre vorhandene crontab-Lösung.

    InformationsquelleAutor der Antwort Nathan Buesgens

  3. 11

    Vorsichtig sein mit der Verwendung von SQS für cronjobs, da Sie nicht garantieren, dass nur "ein job ist gesehen nur eine Maschine". Sie garantieren, dass "mindestens ein" wird die Nachricht bekommen.

    Aus: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

    Q: Wie oft erhalte ich jede Nachricht?

    Amazon SQS wurde entwickelt, um "wenigstens einmal" die Zustellung aller Nachrichten in seiner Warteschlange. Obwohl die meisten der Zeit, jede Nachricht wird übermittelt, um Ihre Anwendung genau einmal, sollten Sie Ihre design-system, so dass die Verarbeitung einer Nachricht mehr als einmal nicht schaffen, alle Fehler oder Unstimmigkeiten.

    So weit ich denken kann die Lösung, wenn Sie eine Instanz mit Gearman-Job-Server-Instanz installiert: http://gearman.org/. Auf der gleichen Maschine, die Sie konfigurieren cron-jobs, die den Befehl zur Ausführung des cronjob-task im hintergrund. Dann einem Ihrer web-Server (Arbeitnehmer) startet die Ausführung dieser Aufgabe, die es garantiert, dass nur ein nehmen. Es spielt keine Rolle, wie viele Arbeiter Sie haben (vor allem, wenn Sie mithilfe von auto scaling).

    Die Probleme mit dieser Lösung sind:

    • Gearman-server ist " single point of failure, es sei denn, Sie konfigurieren es mit verteilter Speicherung, zum Beispiel mithilfe von memcached oder einer Datenbank
    • Dann mit mehreren Gearman-Server müssen Sie wählen Sie eine, die schafft die Aufgabe über cron-Job, damit wir wieder zurück zu dem gleichen problem. Aber wenn Sie Leben können mit dieser Art von single point of failure mit Gearman-sieht aus wie ganz gute Lösung. Vor allem, dass Sie nicht brauchen, big-Instanz für das (micro-Instanz, in unserem Fall ist genug).

    InformationsquelleAutor der Antwort Maciej Majewski

  4. 10

    Amazon hat gerade freigegeben neue features für AWS Elastic Beanstalk. Aus der docs:

    AWS Elastic Beanstalk unterstützt periodische Aufgaben für Arbeiter, Umwelt

    Ebenen in Umgebungen, für die eine vordefinierte Konfiguration mit einer Lösung Stapel mit "v1.2.0" im container-Namen. "

    Können Sie jetzt ein Umfeld schaffen, mit einer cron.yaml - Datei konfiguriert, die scheduling-Aufgaben:

    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 mir vorstellen, dass die Versicherung, es läuft nur einmal in ein autoscaled Umwelt verwertet wird, über die message queue (in SQS). Wenn der cron-daemon löst ein Ereignis aus, es stellt diesen Anruf in die SQS-queue und die Nachricht in der Warteschlange wird nur einmal ausgewertet. Die docs sagen, dass die Ausführung möglicherweise verzögert werden, wenn die SQS hat viele Nachrichten zu verarbeiten.

    InformationsquelleAutor der Antwort user541905

  5. 6

    Kam ich über diese Frage zum Dritten mal und dachte, ich würde chip. Wir hatten dieses dilemma für eine Weile jetzt. Ich noch wirklich fühlen AWS ist eine Funktion vermisst hier.

    In unserem Fall, nach einem Blick auf die möglichen Lösungen, die wir beschlossen hatten wir zwei Möglichkeiten:

    • Einrichten eines cronjob-server läuft, die Arbeitsplätze, dass sollte nur einmal ausgeführt werden, zu einer Zeit, automatische Skalierung und stellen Sie sicher, es ist ersetzt wenn bestimmte CloudWatch stats sind nicht, was Sie sein sollten. Wir verwenden cloud-init - Skripte, um die cronjobs ausgeführt. Natürlich, dieser kommt mit einer Ausfallzeit, die zu verpassten cronjobs (bei der Ausführung bestimmter Aufgaben, in jeder minute, wie wir es tun).
    • Verwenden Sie die Logik, die rcron verwendet. Natürlich ist die Magie nicht wirklich in rcron selbst, es ist in der Logik, die Sie verwenden zum erkennen einer fehlerhaften Knoten (wir verwenden keepalived hier) und "upgrade" zu einem anderen Knoten zu beherrschen.

    Entschieden wir uns für die zweite option, einfach weil es genial schnell und wir hatten bereits Erfahrung mit Webserver laufen diese cronjobs (in unserem pre-AWS-ära).

    Natürlich, diese Lösung ist gedacht speziell für das ersetzen der traditionellen ein-Knoten-cronjob-Ansatz, wo timing ist der entscheidende Faktor (z.B. "ich will den job einmal täglich um 5 UHR", oder wie in unserem Fall "ich will den Auftrag B zu laufen, einmal pro minute"). Wenn Sie cronjobs auszulösen batch-Verarbeitung von Logik, sollten Sie wirklich werfen Sie einen Blick auf SQS. Es gibt keine aktiv-passiv-dilemma, das heißt, Sie können auf einem einzelnen server oder eine ganze Belegschaft für die Bearbeitung Ihrer Warteschlange. Ich würde auch vorschlagen, Blick auf SWF für die Skalierung Ihrer Belegschaft (obwohl auto scaling vielleicht in der Lage, den trick zu tun, wie auch in den meisten Fällen).

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

    InformationsquelleAutor der Antwort Jaap Haagmans

  6. 6

    Am 12/Feb/16 Amazon gebloggt Planung SSH-jobs mit AWS Lambda. Ich denke, das beantwortet die Frage.

    InformationsquelleAutor der Antwort Tom

  7. 4

    "Amazon" Art und Weise verteilt werden, was bedeutet, sperrige crons sollte aufgeteilt werden in viele kleinere jobs und weitergegeben, um die richtigen Maschinen. Mit SQS kleben es zusammen ist sichergestellt, dass jeder Auftrag wird von nur einer Maschine. Es wird auch toleriert Ausfall, da die Warteschlangen gepuffert werden, bis eine Maschine spins sichern.

    Sich auch überlegen, ob Sie wirklich brauchen, um zu 'batch' dieser Vorgänge. Was passiert, wenn man nachts die updates sind erheblich größer als erwartet? Auch mit der dynamischen Finanzierung, Ihre Verarbeitung könnte verzögert werden, warten auf genügend Maschinen zu drehen. Stattdessen speichern Sie Ihre Daten in SDB, Benachrichtigen Maschinen von updates durch SQS, und erstellen Sie Ihren RSS-feed-on the fly (mit caching).

    Batch-jobs sind aus einer Zeit, als die Verarbeitung Ressourcen seien begrenzt und "live" - Dienste den Vorrang hatten. In der cloud, dieses ist nicht der Fall.

    InformationsquelleAutor der Antwort vsekhar

  8. 4

    Wenn Sie bereits eine Redis-service-up, das aussieht, wie eine gute Lösung:

    https://github.com/kvz/cronlock

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

    InformationsquelleAutor der Antwort barbolo

  9. 1

    Warum würden Sie Ihre eigenen bauen? Warum nicht so etwas wie Quarz (mit Gruppierten Scheduling). Siehe Dokumentation.

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

    InformationsquelleAutor der Antwort Rama Nallamilli

  10. 1

    Was wir tun ist, wir haben ein server, der Teil unseres web-application-cluster hinter einem ELB auch die Zuordnung einer bestimmten DNS-Namen, damit können wir die jobs auf, die einem bestimmten server. Dies hat auch den Vorteil, dass, wenn dieser job bewirkt das der server sich zu verlangsamen, der ELB wird, entfernen Sie Sie aus dem cluster und geben es dann zurück, wenn der job ist vorbei und es wird wieder gesund.

    Funktioniert wie ein champ.

    InformationsquelleAutor der Antwort Patrick Steil

  11. 0

    Wenn Sie bereit sind, verwenden Sie eine nicht-AWS-service, dann sind Sie vielleicht check out Microsoft Azure. Azure bietet eine große job-scheduler.

    InformationsquelleAutor der Antwort johnnyodonnell

  12. 0

    Da hat niemand erwähnt CloudWatch-Event, würde ich sagen, dass es der AWS Art und Weise zu tun, cron-jobs. Es kann laufen viele Aktionen, wie die Lambda-Funktion, ECS Aufgabe.

    InformationsquelleAutor der Antwort wanghq

Schreibe einen Kommentar