Zuverlässige Aufgabenplanung in Compute Engine mit Cloud Scheduler

In verteilten Systemen, beispielsweise einem Netzwerk von Compute Engine-Instanzen, ist es schwierig, Aufgaben zuverlässig zu planen, da es jederzeit passieren kann, dass Instanzen aufgrund von Autoscaling oder einer Netzwerkpartitionierung nicht mehr verfügbar sind.

Wenn Sie Cloud Scheduler für die Planung und Cloud Pub/Sub für verteilte Nachrichten nutzen, können Sie eine entsprechende Anwendung für die zuverlässige Zeitplanung von Aufgaben auf einer Reihe von Compute Engine-Instanzen erstellen. Wenn Sie komplexe Workflows für andere Produkte oder Clouds planen und orchestrieren müssen, sollten Sie es in Betracht ziehen, stattdessen Cloud Composer zu verwenden.

Dieser dreiteilige Artikel umfasst:

Aufgaben zuverlässig in Compute Engine planen

Bei Cron handelt es sich um ein Standard-Tool für das Planen wiederkehrender Aufgaben auf Unix-Systemen. Wenn die von Ihnen erstellten Systeme an Komplexität zunehmen und verteilt werden, kann ein einzelner Cron ausführender Computer zu einem kritischen Ausfallpunkt werden. Die Instanz wird möglicherweise aufgrund einer automatischen Skalierung gestoppt oder deren Netzwerksegment wird von den Systemen, mit denen es kommunizieren muss, partitioniert.

Cloud Scheduler bietet einen vollständig verwalteten Dienst für Unternehmen, mit dem Sie Ereignisse planen können. Nachdem Sie einen Job geplant haben, ruft Cloud Scheduler die konfigurierten Ereignis-Handler auf, bei denen es sich um App Engine-Dienste, HTTP-Endpunkte oder Cloud Pub/Sub-Abonnements handeln kann.

Wenn auf Ihrer Compute Engine-Instanz Aufgaben als Reaktion auf Cloud Scheduler-Ereignisse ausgeführt werden sollen, müssen Sie die Ereignisse an diese Instanzen weiterleiten. Dies ist beispielsweise durch das Aufrufen eines HTTP-Endpunkts möglich, der auf den Compute Engine-Instanzen ausgeführt wird. Eine weitere Möglichkeit besteht darin, Nachrichten mithilfe von Cloud Pub/Sub von Cloud Scheduler an die Compute Engine-Instanzen weiterzuleiten. Dieses Beispiel zeigt das zweite Designmuster.

Das folgende Diagramm bietet einen architektonischen Überblick über dieses Designmuster.

Architektur-Überblicksdiagramm

Bei dieser Implementierung planen Sie Ereignisse in Cloud Scheduler und übertragen diese dann mithilfe von Cloud Pub/Sub an Compute Engine-Instanzen.

Ein Dienstprogramm auf Ihren Compute Engine-Instanzen abonniert Cloud Pub/Sub-Themen und führt als Reaktion auf Ereignisse, die es aus diesen Themen zieht, Cronjobs aus. Das Dienstprogramm führt Standardskripte aus; Sie müssen Ihre aktuellen Cron-Skripte nicht verändern, um sie in diesem Beispiel zu verwenden.

Wenn Sie mit Cloud Pub/Sub die Aufgabenplanungslogik von der Logik entkoppeln, welche die Befehle in Compute Engine ausführt, können Sie Ihre Cron-Skripte nach Bedarf aktualisieren, ohne die Cloud Scheduler-Konfiguration zu aktualisieren. Außerdem können Sie Ihre Aufgabenplanung ändern, ohne das Dienstprogramm auf den Compute Engine-Instanzen zu aktualisieren.

Kontingente

Da es in der Regel nur wenige Cronjobs gibt und diese nach einem stündlichen, wöchentlichen oder täglichen Zeitplan ausgeführt werden, sollten bei diesem Designmuster die Cloud Scheduler-Kontingente nicht überschritten werden, die zehn Anfragen pro Minute und Tausende pro Tag zulassen. Wenn dies der Fall ist, sollten Sie andere Anwendungsmuster in Betracht ziehen, wie etwa die Verwaltung der Zeitplanung für die Aufgaben direkt im Anwendungscode.

Kosten

Sie können die Beispielimplementierung dieses Designmusters mit der kostenlosen GCP-Stufe ohne Kosten ausprobieren, wenn Sie diese Ressourcen nicht für andere Anwendungen verwenden. Wenn Ihre kostenlosen Kontingente bereits von anderen Anwendungen in Ihrem Projekt aufgebraucht worden sind, leiten sich die Kosten aus der Gesamtnutzung von Compute Engine-, Cloud Scheduler- und Cloud Pub/Sub-Ressourcen ab.

Die Preise für Cloud Scheduler basieren auf der Anzahl der geplanten Jobs. Die Preise für Compute Engine basieren auf dem Typ der verwendeten Instanzen und deren Nutzungsdauer. Die Preise für Cloud Pub/Sub richten sich nach dem gesendeten Datenvolumen.

Wenn Sie beispielsweise die Beispielimplementierung im folgenden Abschnitt eine Stunde lang ausführen und dann die GCP-Ressourcen löschen, betragen die Kosten ungefähr 1 Cent. Eine Aufschlüsselung der Kosten in dieser Schätzung finden Sie im Preisrechner. Dieser ermöglicht auch eine Berechnung der Kosten für Ihren persönlichen Fall.

Beispielimplementierung des Designmusters

Eine Beispielimplementierung dieses Designmusters, Beispiel: Zuverlässige Aufgabenplanung in Compute Engine, ist auf GitHub verfügbar.

Das Beispiel besteht aus zwei Teilen:

  • Anweisungen zum Konfigurieren von Cloud Scheduler und Cloud Pub/Sub.

  • Ein Dienstprogramm, das auf Compute Engine ausgeführt wird. Dieses Dienstprogramm überwacht ein Cloud Pub/Sub-Thema. Wenn es eine neue Nachricht erkennt, wird der entsprechende Befehl lokal auf dem Server ausgeführt.

In der enthaltenen README-Datei wird das Beispiel ausführlicher beschrieben und erläutert, wie der Beispielcode auf der GCP ausgeführt wird.

Wenn Sie dagegen Instanzen im Rahmen eines Zeitplans starten und stoppen möchten, finden Sie entsprechende Informationen unter Compute-Instanzen mit Cloud Scheduler planen.

Erweiterungen des Designmusters und Beispiels

Das Beispiel zeigt eine Möglichkeit, mithilfe von Cloud Scheduler eine zuverlässige Planungslösung für Compute Engine zu implementieren. Dies ist ein nützliches Designmuster, da es die Planungslogik von der Logik trennt, die Befehle auf der Compute Engine-Instanz ausführt und so das Ändern des Speicherortes und die Ausführung Ihrer Aufgaben ohne notwendige Aktualisierung der Planungslogik ermöglicht.

Die folgende Grafik zeigt den Fluss von Nachrichten in diesem Beispiel. Durch Angabe, welche Instanzen ein bestimmtes Thema abonnieren, können Sie kontrollieren, ob ein Cronjob auf einer einzelnen Instanz oder auf mehreren Instanzen ausgeführt wird.

Detailliertes Architekturdiagramm

Ein weiterer Vorteil dieser Architektur besteht in der Kontrolle, die Sie darüber erhalten, wie Cronjobs zu Ihren Instanzen führen.

Sie können verschiedene Cron-Nachrichten an verschiedene Server senden, wie anhand der Cloud Pub/Sub-Themen A und C dargestellt. Die Aufgaben im Thema A werden an einen einzelnen Abonnenten geschickt, wohingegen mehrere Server das Thema C abonnieren. Sie können diese Strategie nutzen, um einen Befehlssatz auf Ihrem Webserver und einen anderen auf Ihren anderen Servern auszuführen.

Eine weitere Option ist, einen Befehl auf einem von mehreren Servern auszuführen. Dies wird im Thema B beschrieben. In diesem Fall teilen sich mehrere Server ein einzelnes Abo. In Thema B veröffentlichte Nachrichten werden vom ersten Server verarbeitet, um sicherzustellen, dass diese Nachricht und der entsprechende Befehl nur auf diesem Server ausgeführt werden. Sie können mit diesem Ansatz eine nächtliche Datenanalyse vornehmen, die nur auf einem einzigen Server ausgeführt werden muss.

Weitere Informationen

Sie haben die Möglichkeit das Beispiel zu verändern und es als Modell für Ihre eigene Anwendung zu verwenden. Hier finden Sie einige Ideen für den Anfang:

  • Aktualisieren Sie die Cloud Scheduler-Konfiguration, um Ihre eigenen Cron-Nachrichten anzugeben. Sie können den Cronjob direkt aktualisieren, wie unter Cronjobs erstellen und konfigurieren beschrieben.

  • Aktualisieren Sie test_executor.py, um ein echtes Skript anstelle von logger_sample_task.py auszuführen, oder schreiben Sie Ihr eigenes Executor-Dienstprogramm.

  • Anstatt das Dienstprogramm auf Compute Engine manuell zu starten und es als Vordergrundprozess auszuführen, können Sie es automatisch als Daemon eines System- oder Drittanbietertools wie systemd oder Supervisor starten.

  • Weder für Cloud Scheduler noch für Cloud Pub/Sub kann garantiert werden, dass es zu "genau einer" Zustellung kommt. In unwahrscheinlichen Fällen können Nachrichten zweimal zugestellt werden. Wenn das Ausführen einer bestimmten Aufgabe mehr als einmal zu einem unerwünschten Ergebnis führt, sollten Sie ein verteiltes, konsistentes Sperrtool wie Zookeeper verwenden, um sicherzustellen, dass die Aufgabe nur einmal und nur von einer Instanz ausgeführt wird.

  • Befolgen Sie bei der Planung von Aufgaben die Best Practices von Cron und prüfen Sie, ob Aufgaben weit genug auseinander geplant werden, damit die Verarbeitung vor der nächsten Ausführung abgeschlossen wird.

  • Überlegen Sie, ob die Ausführung von Compute Engine-Instanzen für alle Aufgaben erforderlich ist. Eine Alternative besteht darin, als Antwort auf Cloud Pub/Sub-Nachrichten Cloud Functions auszulösen. Cloud Functions kann Cloud APIs aufrufen, jedoch keine Shell-Skripte direkt ausführen. Wenn Sie Shell-Skripts ausführen müssen, können Sie die Compute Engine API aufrufen, um temporäre Compute Engine-Instanzen zum Ausführen von Skripts zu erstellen. Diese Instanzen können sich selbst herunterfahren, wenn die Aufgaben abgeschlossen sind. Dies gibt Ihnen die Flexibilität, Aufgaben schon bald nach der Ereigniszeit zu minimalen Kosten abzuschließen.

Weitere Google Cloud Platform-Features: Anleitungen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...