Zuverlässigkeit in Azure Batch

Azure Batch führt in Azure groß angelegte parallele HPC-Batchaufträge aus. Batch erstellt und verwaltet Pools von Computeknoten, installiert die Anwendungen, die Sie auf den Knoten ausführen möchten, und plant Aufträge für die Ausführung auf den Knoten.

Wenn Sie Azure verwenden, ist Zuverlässigkeit eine gemeinsame Verantwortung. Microsoft bietet eine Reihe von Funktionen zur Unterstützung von Resilienz und Wiederherstellung. Sie sind dafür verantwortlich, zu verstehen, wie diese Funktionen in allen von Ihnen verwendeten Diensten funktionieren, und die Funktionen auswählen, die Sie benötigen, um Ihre Geschäftsziele und Uptime-Ziele zu erfüllen.

In diesem Artikel wird beschrieben, wie Sie Azure Batch widerstandsfähig für vorübergehende Fehler, Computeknotenfehler, Verfügbarkeitszonenfehler, regionsweite Fehler und Dienstwartung machen. Außerdem werden Empfehlungen für die Produktionsbereitstellung, die Batch-Zuverlässigkeitsarchitektur, die Sicherung und Wiederherstellung sowie wichtige Informationen zum Azure Batch Service Level Agreement (SLA) beschrieben.

Bereitstellungsempfehlungen für die Produktion

Befolgen Sie für Produktionsworkloads die bewährten Methoden für Azure Batch, einschließlich der folgenden Zuverlässigkeitsempfehlungen:

Übersicht über die Zuverlässigkeitsarchitektur

In diesem Abschnitt werden einige der wichtigen Aspekte der Funktionsweise des Diensts beschrieben, die aus Zuverlässigkeitsperspektive am relevantesten sind. Im Abschnitt wird die logische Architektur vorgestellt, die einige der Ressourcen und Features enthält, die Sie bereitstellen und verwenden. Außerdem wird die physische Architektur erläutert, die Details zur Funktionsweise des Diensts unter den Deckeln bereitstellt.

Logische Architektur

Azure Batch verwendet mehrere Ressourcentypen zum Ausführen von Batchworkloads. Die Konfiguration dieser Ressourcen bestimmt, wie Ihre Workload auf Fehler reagiert.

Alle Batchverarbeitungen und Ressourcen sind einem Batch-Konto zugeordnet. Eine Batchlösung verwendet die folgenden logischen Komponenten:

• Batchkonto: Eine regionale Ressource, mit der Pools, Aufträge, Vorgänge und andere Batchressourcen verknüpft sind. Sie erstellen das Konto und wählen seine Region, den Poolzuordnungsmodus und die Authentifizierungseinstellungen aus.

• Pool: Eine Sammlung von Computeknoten, auf denen Aufgaben ausgeführt werden. Die Konfiguration eines Pools definiert sein VM-Image und seine Größe, die Anzahl der Zielknoten, das Skalierungsverhalten, das Netzwerk und die Zonenplatzierung. Sie konfigurieren jeden Pool so, dass er die Kapazität, Platzierung und Betriebsumgebung bereitstellt, die Ihre Workload erfordert. Die Anzahl der Zielknoten ist die angeforderte Kapazität, aber die Anzahl der zugewiesenen Knoten kann aufgrund von Kontingentbeschränkungen, Kapazitätsbeschränkungen oder Zuordnungsfehlern niedriger sein.

• Aufträge und Aufgaben: Ein Auftrag verwaltet eine Sammlung von Aufgaben und ist einem Pool zugeordnet. Eine Aufgabe führt eine Anwendung oder ein Skript auf einem Computeknoten aus. Sie definieren Aufträge, Aufgaben, Einschränkungen, Abhängigkeiten, Wiederholungsverhalten und den Pool, auf dem jeder Auftrag ausgeführt wird.

• Zugeordnetes Speicherkonto: Ein Azure Storage Konto, das Sie optional mit einem Batchkonto verknüpfen. Die meisten Batchlösungen verwenden ein zugeordnetes Speicherkonto für Anwendungsdateien, Ressourcendateien für Tasks, Eingabedaten und Ausgabedaten.

  Nachdem Sie ein Speicherkonto mit einem Batchkonto verknüpft haben, bezeichnet Batch es als autostorage account. Ein AutoStorage-Konto ist für Anwendungspakete erforderlich und kann auch Vorgangsressourcendateien speichern.

  Die Zuverlässigkeit einer Batchlösung hängt von ihren Speicherressourcen ab. Sie sind für die Auswahl einer Speicherredundanzkonfiguration verantwortlich, die Ihre Wiederherstellungsanforderungen erfüllt, wenn Sie das Speicherkonto erstellen. Verschieben Sie die Vorgangsausgabe und andere dauerhafte Daten von Computeknoten in den Speicher. Informationen zu Azure Storage Zuverlässigkeitsoptionen finden Sie unter Zuverlässigkeit in Azure Blob Storage.

Weitere Informationen finden Sie unter Batch-Dienstworkflow und Ressourcen und Batchkonten und Azure Storage-Konten.

Physische Architektur

Azure Batch verfügt über eine regionale Steuerungsebene, die Verwaltungsvorgänge für Batchkonten und andere Batchressourcen verarbeitet, z. B. Pools, Aufträge und Aufgaben. Sie ist von den Computeknoten getrennt, die Aufgaben ausführen.

Azure Batch Pools verwenden Azure Virtual Machines und Virtual Machine Scale Sets. Ein Computeknoten ist eine VM, die einen Teil einer Batch-Workload verarbeitet. Jeder Knoten gehört zu einem Pool und führt Aufgaben aus, die der Batchdienst ihm zuweist. Der Batchknoten-Agent wird auf jedem Knoten ausgeführt und stellt die Befehls- und Steuerungsschnittstelle zwischen dem Knoten und dem Batchdienst bereit. Computeknoten und ihr lokaler Speicher sind kurzlebig. Wenn ein Knoten einen Pool verlässt, gehen Änderungen am Betriebssystem und dateien verloren.

Der Poolzuweisungsmodus des Batchkontos bestimmt, wo Batch die Compute- und VM-bezogenen Ressourcen erstellt:

• Batchdienstpoolzuordnungsmodus: Batch weist die Ressourcen in vom Batch verwalteten Azure-Abonnements zu.
• Zuordnungsmodus des Benutzerabonnementspools: Batch erstellt die Ressourcen direkt im Abonnement, das das Batchkonto enthält.

Die Verantwortlichkeiten für die physische Architektur sind wie folgt unterteilt:

• Microsoft: Microsoft betreibt die regionale Batch-Steuerungsebene und Serviceinfrastruktur. Batch stellt Computeknoten gemäß der Poolkonfiguration und verfügbarer Kapazität bereit, plant Aufgaben, überwacht die Knotenintegrität und versucht, Knoten nach Infrastrukturfehlern wiederherzustellen. Batch kann unterbrochene Aufgaben für die Ausführung auf einem anderen verfügbaren Knoten erneut in die Warteschlange stellen.

• Sie: Sie wählen das VM-Image und die Größe, Knotentypen, Zielknotenanzahl, Skalierungskonfiguration, Netzwerk- und Verfügbarkeitszoneplatzierung aus.

  Sie sind auch dafür verantwortlich, genügend Kapazität zu erhalten, um Knotenfehler zu tolerieren, Knoten- und Aufgabenzustände zu überwachen, das Gastbetriebssystem und den Knoten-Agent aktuell zu halten, Aufgaben so zu entwerfen, dass sie eine erneute Ausführung tolerieren und dauerhafte Daten von den Computeknoten zu verschieben.

Die Batchknotenwiederherstellung garantiert nicht, dass eine Workload ohne Unterbrechung fortgesetzt wird. Weitere Informationen finden Sie unter Resilienz gegenüber Ausfällen von Computeknoten.

Resilienz für vorübergehende Fehler

Vorübergehende Fehler sind kurze, zeitweilige Fehler in Komponenten. Sie treten häufig in einer verteilten Umgebung wie der Cloud auf und sind ein normaler Bestandteil von Vorgängen. Vorübergehende Fehler korrigieren sich nach kurzer Zeit. Es ist wichtig, dass Ihre Anwendungen vorübergehende Fehler behandeln können, in der Regel durch Wiederholen betroffener Anforderungen.

Alle in der Cloud gehosteten Anwendungen sollten die Anleitung zur vorübergehenden Fehlerbehandlung von Azure befolgen, wenn sie mit cloudgehosteten APIs, Datenbanken und anderen Komponenten kommunizieren. Weitere Informationen finden Sie unter Empfehlungen zum Umgang mit vorübergehenden Fehlern.

Innerhalb einer Batchlösung können vorübergehende Fehler sowohl die Anwendungen als auch Skripts betreffen, die als Aufgaben ausgeführt werden, und alle Anwendungen, die Batch-APIs aufrufen, um Batchressourcen zu verwalten. Batch stellt Wiederholungsmechanismen auf Aufgabenebene bereit. Sie sind für die Konfiguration von Vorgangseinschränkungen verantwortlich, machen Aufgaben idempotent (sicher, mehr als einmal ausgeführt zu werden) und konfigurieren das Wiederholungsverhalten für Aufrufe an den Batchdienst und andere Abhängigkeiten.

Aufgabenwiederholungen und Zeitlimits

Konfigurieren Sie maxTaskRetryCount, um zu steuern, wie oft Batch eine Aufgabe erneut versucht, nachdem ihr Prozess mit einem Nicht-Null-Beendigungscode beendet wurde:

• Der Standardwert, 0, bedeutet, dass Batch die Aufgabe nach einem Beendigungscode ungleich null nicht erneut wiederholt.
• Eine positive ganze Zahl legt nach dem anfänglichen Versuch eine maximale Anzahl von Wiederholungsversuchen fest.
• Ein Wert von -1 ermöglicht unbegrenzte Wiederholungen. Dieser Wert wird nicht empfohlen, da ein anhaltender Fehler dazu führen kann, dass die Aufgabe unbegrenzt ausgeführt wird.

Entwerfen Sie jede Aufgabe so, dass sie idempotent ist, sodass Wiederholungen keine Datenbeschädigung oder doppelte Ausgabe verursachen. Verwenden Sie für lange ausgeführte Aufgaben Checkpointing, damit ein erneuter Versuch aus dem gespeicherten Fortschritt fortgesetzt werden kann. Weitere Informationen finden Sie unter "Entwurf für Wiederholungen und erneute Ausführung".

Legen Sie die maxWallClockTime Beschränkung für einen Vorgang oder Auftrag fest, um Arbeiten zu beenden, die innerhalb eines akzeptablen Zeitraums nicht vorankommen. Ein Zeitlimit schränkt auch die Auswirkung wiederholter Fehler ein. Wählen Sie wiederholungsanzahlen und Zeitlimits aus, die den Wiederherstellungszielen der Workload entsprechen.

Vorübergehende Fehler in Vorgangsabhängigkeiten

Anwendungen und Skripts, die als Batchaufgaben ausgeführt werden, rufen häufig andere Komponenten auf, z. B. Azure Storage, Datenbanken oder APIs. Batch verwaltet nicht die einzelnen Anfragen, die Task-Code an diese Abhängigkeiten sendet. Implementieren Sie die vorübergehende Fehlerbehandlung im Aufgabencode, oder verwenden Sie Wiederholungsfeatures, die vom SDK der Abhängigkeit bereitgestellt werden. Befolgen Sie die Anweisungen der einzelnen Abhängigkeiten, um wiederholbare Fehler zu identifizieren, geeignete Backoff- und Timeouteinstellungen auszuwählen und Anweisungen zur Wiederholung wie z. B. die Retry-After-Kopfzeile zu berücksichtigen. Wiederholen Sie nur Vorgänge, die sicher wiederholt werden können.

Wenn ein Abhängigkeitsfehler bewirkt, dass der Aufgabenprozess mit einem nichtzero-Beendigungscode beendet wird, kann Batch die gesamte Aufgabe entsprechend maxTaskRetryCountwiederholen. Batch wiederholt jedoch keine einzelne Abhängigkeitsanforderung innerhalb einer ausgeführten Aufgabe.

Batch-API-Anforderungswiederholungen

Ihre Anwendungen, die außerhalb des Diensts ausgeführt werden, können Batch-APIs aufrufen, um Pools, Aufträge, Aufgaben, Computeknoten und andere Batchressourcen zu erstellen und zu verwalten. Konfigurieren Sie diese Clients mit Wiederholungsrichtlinien, die mindestens fünf Minuten umfassen , um vorübergehende Batchdienst- oder Netzwerkfehler zu behandeln.

Verwenden Sie die integrierte SDK-Wiederholungsunterstützung, wenn sie verfügbar ist. Beispiel: die Azure.Compute.Batch-Clientbibliothek für .NET macht das Wiederholungsverhalten durch Azure.Core Wiederholungsoptionen verfügbar.

Wenn Sie direkt mit den APIs des Batchdiensts aus Ihrem Code interagieren, warten Sie mehrere Sekunden, bevor Sie den Vorgang wiederholen, verwenden Sie exponentielle Backoffs mit Randomisierung (Jitter), um synchronisierte Wiederholungsanforderungen zu vermeiden, und berücksichtigen Sie den mit Drosselungsantworten wie 429 Too Many Requests und 503 Service Unavailable zurückgegebenen Header Retry-After.

Ein Anforderungstimeout bedeutet nicht unbedingt, dass Batch die Anforderung nicht verarbeiten konnte. Wiederholen Sie nach einem Timeout den Vorgang, wenn dies sicher ist, oder rufen Sie den Ressourcenstatus ab, um festzustellen, ob der ursprüngliche Vorgang erfolgreich war. Weitere Informationen finden Sie unter Fehlerbehandlung und -erkennung in Azure Batch.

Resilienz gegenüber Ausfällen von Rechenknoten

Ein Computeknoten kann aufgrund eines Infrastrukturfehlers, eines Betriebssystemproblems oder eines Konfigurationsproblems nicht mehr verfügbar sein. Batch versucht, Knoten wiederherzustellen, die von Infrastrukturfehlern betroffen sind, kann jedoch nicht jeden konfigurationsbezogenen Fehler automatisch beheben. Wenn beispielsweise ein Anwendungspaket oder Container nicht installiert werden kann, müssen Sie das zugrunde liegende Problem beheben und möglicherweise den betroffenen Knoten entfernen und ersetzen.

Wenn ein Knotenfehler einen Vorgang unterbricht, kann Batch die Aufgabe auf demselben Knoten wiederholen, sofern möglich, bis zu einem internen Grenzwert. Wenn die Aufgabe auf diesem Knoten nicht fortgesetzt werden kann, kann Batch sie für die Ausführung auf einem anderen verfügbaren Knoten erneut in die Warteschlange stellen. Diese Wiederholungsversuche zur dienstgesteuerten Wiederherstellung sind unabhängig von maxTaskRetryCount und können auch dann auftreten, wenn ihr Wert 0 ist.

Microsoft-verwalteter Knotenwiederherstellungsprozess

Microsoft verwaltet die dienstgesteuerte Knotenwiederherstellung und die erneute Einreihung von Aufgaben. Wenn der Batchdienst lange genug keine Heartbeat-Signale mehr von einem Knoten empfängt, um die Wiederherstellung auszulösen, kann Batch die folgenden Aktionen ausführen:

1. Isolieren Sie den Knoten: Batch behandelt den Knoten als ungesund, setzt seinen Zustand auf unusable und beendet die Planung neuer Vorgänge auf ihm.
2. Betroffene Aufgaben identifizieren: Batch identifiziert Aufgaben, die auf dem Knoten ausgeführt wurden, als Kandidaten für die Neuplanung.
3. Geeignete Aufgaben erneut einreihen: Wenn eine betroffene Aufgabe weiterhin im Zustand running gespeichert ist, kann Batch sie auf active zurücksetzen, sodass der Planer sie einem anderen Knoten zuweisen kann. Batch setzt einen Vorgang nicht zurück und führt ihn nicht erneut aus, der bereits im completed Zustand gespeichert ist.
4. Wiederherstellen des Knotens: Batch versucht, den Knoten wieder in einen fehlerfreien Zustand zu versetzen oder den zugrunde liegenden virtuellen Computer zu ersetzen.

Die Wiederherstellung erfolgt nicht sofort. Eine Aufgabe kann im running Zustand verbleiben, während Batch den Knotenfehler erkennt und versucht, die Aufgabe neu zu planen. Wenn kein anderer Computeknoten verfügbar ist, kann die Aufgabe in diesem Zustand verbleiben, bis Batch sie neu planen kann. Weitere Informationen finden Sie unter "Bekannte Einschränkungen für Batchaufgaben".

Wenn der ursprüngliche Knoten fehlerfreie Heartbeats wieder aufnimmt, bevor der Ersatz beginnt, kann Batch ihn wieder in einen stabilen Zustand versetzen. Wenn der Ersetzungsvorgang bereits begonnen hat, kann Batch stattdessen den ursprünglichen virtuellen Computer entfernen und einen Ersatz bereitstellen.

Ihre Zuständigkeiten

Die dienstgesteuerte Wiederherstellung garantiert keine unterbrechungsfreie Aufgabenausführung oder ausreichende verbleibende Kapazität. Sie sind für die folgenden Aktionen verantwortlich:

• Ausreichende Kapazität sicherstellen: Wenn Ihre Workload fortgesetzt werden muss, während ein Knoten nicht verfügbar ist, stellen Sie genügend Knoten für die verbleibenden Knoten bereit, um neu geplante Vorgänge auszuführen. Ohne einen anderen verwendbaren Knoten müssen unterbrochene Vorgänge warten.

• Überwachen der verwendbaren Kapazität: Nachverfolgen von Aggregatknotenanzahlen und -zuständen, damit Sie erkennen können, wann ein Pool nicht mehr über genügend verwendbare Knoten für Ihre Workload verfügt. Staaten wie unusable, startTaskFailed, unknownund preempted weisen auf reduzierte Kapazität hin. Weitere Informationen finden Sie unter Überwachen von Batch-Lösungen durch Zählen von Tasks und Knoten nach Status.

• Untersuchen Sie Problemknoten: Wenn Vorgänge wiederholt fehlschlagen, erneut in die Warteschlange eingereiht werden oder im running Zustand verbleiben, nachdem ihr zugewiesener Knoten nicht mehr verwendet werden kann oder den Pool verlässt, verwenden Sie Aufgabenmetadaten, um zu bestimmen, ob die Probleme einem bestimmten Knoten zugeordnet sind.

  Bevor Sie einen Problemknoten entfernen, laden Sie dessen Batchknoten-Agent-Protokolle hoch und bewahren Sie relevante Aufgabenprotokolle auf, da das Entfernen des Knotens die lokalen Dateien löscht. Knoten-Agent-Protokolle können Microsoft-Support bei der Diagnose von Batchdienst- oder Knotenproblemen helfen, während Aufgabenprotokolle wie stdout und stderr Ihnen helfen können, Anwendungs- und Konfigurationsprobleme zu identifizieren. Weitere Informationen finden Sie unter Node-Agent-Protokolldateien.

• Schützen Sie den Aufgabenfortschritt und die Daten: Entwerfen Sie Aufgaben, die für Unterbrechungen und erneute Ausführung ausgelegt sind. Verschieben Sie Checkpoints, Ausgaben und andere dauerhafte Daten von Computeknoten, da ihr lokaler Speicher flüchtig ist.

Weitere Informationen finden Sie unter Azure Batch Pool- und Knotenfehler sowie fehlerbehandlung und -erkennung in Azure Batch.

Ausfallsicherheit bei Ausfällen von Verfügbarkeitszonen

Verfügbarkeitszonen sind physisch getrennte Gruppen von Rechenzentren innerhalb einer Azure-Region. Wenn eine Zone ausfällt, erfolgt ein Failover der Dienste zu einer der verbleibenden Zonen.

Batch unterstützt Verfügbarkeitszonen auf zwei Arten:

• Kontrollebene: Die Batch-Kontrollebene ist in vielen Regionen zonenresilient. In diesen Regionen können Verwaltungsvorgänge für Batchkonten und andere Batchressourcen während eines Zonenfehlers fortgesetzt werden. Microsoft veröffentlicht nicht, welche Regionen diese Resilienz der Kontrollebene bieten.

• Pools: Sie können einen Batchpool so konfigurieren, dass die Platzierung in der Verfügbarkeitszone verwendet wird. Wenn eine Zone nicht verfügbar ist, bleiben Rechenknoten in fehlerfreien Zonen für die Task-Planung verfügbar.

  Bei der Platzierung von Computeknoten ähnelt dieses Unterstützungsmodell zonenredundanz in anderen Azure Diensten, da ein einzelner Pool Computeknoten in mehreren Verfügbarkeitszonen enthalten kann. Batch verteilt Knoten jedoch über Zonen auf Best-Effort-Basis. Es versucht, alle Zonen in der Region zu verwenden, garantiert jedoch nicht die Platzierung in jeder Zone oder eine gleichmäßige Verteilung. Sie können keine bestimmten Zonen auswählen oder die Anzahl der Knoten steuern, die in jeder Zone platziert werden.

Das folgende Diagramm zeigt ein Beispiel für ein Batchkonto. Das Konto verfügt über einen einzelnen Pool mit seinen Knoten, die über drei Verfügbarkeitszonen verteilt sind:

Sie sind dafür verantwortlich, andere abhängige Ressourcen, z. B. Speicherkonten, zonensicher zu machen. Überprüfen Sie die Leitfäden zur Zuverlässigkeit für jeden Service. Weitere Informationen finden Sie in den Zuverlässigkeitsleitfäden für Azure Dienste.

Requirements

• Regionsunterstützung: Erstellen Sie den Pool in einer Azure Region, die Verfügbarkeitszonen unterstützt.

• Verfügbarkeit der VM-SKU: Die ausgewählte VM-SKU muss in mehr als einer Zone in der Region verfügbar sein. Verwenden Sie die Ressourcen-SKUs-Listen-API, um das locationInfoFeld für die VM-SKU zu überprüfen.

• Abonnementzugriff: Für einen Benutzerabonnementpool-Zuweisungsmodus darf das Abonnement keine Zonenangebotseinschränkung für die ausgewählte VM-SKU aufweisen. Überprüfen Sie ResourceSkuRestrictions in der API-Antwort der Ressourcen-SKU-Liste. Wenn eine Einschränkung vorhanden ist, senden Sie eine Supportanfrage, um deren Aufhebung zu beantragen.

• Kommunikation zwischen Knoten: Ein Pool kann keine Verfügbarkeitszonenplatzierungsrichtlinie verwenden, wenn die Kommunikation zwischen Knoten mit einer InfiniBand-aktivierten VM-SKU aktiviert ist.

Instanzverteilung über Zonen hinweg

Wenn Sie die Platzierung der Verfügbarkeitszone aktivieren, versucht Batch, Computeknoten in allen Verfügbarkeitszonen in der ausgewählten Region zuzuweisen. Diese Zuweisung erfolgt auf best-effort-Basis. Batch steuert die Verteilung, und die Anzahl der Knoten in jeder Zone ist möglicherweise nicht gleich.

Cost

Batch fügt keine Gebühr für die Aktivierung der Platzierung der Verfügbarkeitszone hinzu. Sie werden für die Compute-, Speicher-, Netzwerk- und andere Azure Ressourcen in Rechnung gestellt, die von der Workload verwendet werden. Wenn Sie zusätzliche Knoten bereitstellen, um den Verlust einer Zone zu tolerieren, fallen für diese Knoten die üblichen Gebühren an. Weitere Informationen finden Sie unter Azure Batch Preise.

Konfigurieren der Unterstützung von Verfügbarkeitszonen

• Erstellen eines neuen Pools mit Platzierung in der Verfügbarkeitszone: Informationen zum Erstellen eines Pools mit aktivierter Platzierung der Verfügbarkeitszone finden Sie unter Erstellen eines Batchpools über Verfügbarkeitszonen hinweg.

• Ändern Sie die Platzierung der Verfügbarkeitszone in einem vorhandenen Pool: Sie müssen die Platzierung der Verfügbarkeitszone auswählen, wenn Sie den Pool erstellen. Sie können einen vorhandenen Pool nicht ändern, um Verfügbarkeitszonen zu verwenden.

  Sie können einen Ersatzpool erstellen und jeden Ihrer Jobs aktualisieren, um ihn zu verwenden, indem Sie die folgenden Schritte ausführen:

  1. Deaktivieren Sie den Auftrag: Verwenden Sie den Vorgang "Auftrag deaktivieren", und wählen Sie aus, wie Batch Aufgaben verarbeitet, die ausgeführt werden, wenn Sie die Anforderung übermitteln:

     • Warten Sie: Batch beendet das Starten neuer Aufgaben und lässt laufende Aufgaben im vorhandenen Pool abschließen. Der Auftrag verbleibt im disabling Zustand, bis die laufenden Aufgaben abgeschlossen sind.
     • Requeue: Batch unterbricht die Ausführung von Aufgaben und gibt sie an die Warteschlange zurück. Die Aufgaben können erneut ausgeführt werden, nachdem Sie den Job aktiviert haben.
     • Beenden: Batch unterbricht die Ausführung von Aufgaben und kennzeichnet sie als abgeschlossen mit Fehlerinformationen, die angibt, dass sie beendet wurden. Die Aufgaben werden nach dem Aktivieren des Auftrags nicht erneut ausgeführt.

     Aufgaben, die sich bereits im Zustand active befinden, was bedeutet, dass sie in der Warteschlange stehen, aber nicht ausgeführt werden, bleiben mit jeder Option in der Warteschlange.

     Warten Sie, bis der Auftrag den disabled Status erreicht, bevor Sie fortfahren. Zu diesem Zeitpunkt werden keine Aufgaben ausgeführt, und Batch plant keine neuen Aufgaben.

  2. Bearbeiten des Auftragspools: Verwenden Sie den Vorgang „Auftrag aktualisieren“, um den poolInfo.poolId des Auftrags auf den Ersatzpool festzulegen. Batch erlaubt nur die Änderung dieser Eigenschaft, während sich der Job im disabled Zustand befindet. Stellen Sie sicher, dass der Ersatzpool vorhanden ist und über verwendbare Kapazität verfügt, bevor Sie den Job aktivieren. Wenn der Pool nicht vorhanden ist, akzeptiert Batch das Update, aber er kann Aufgaben erst planen, wenn Sie den Pool erstellen.

  3. Aktivieren Sie den Auftrag: Verwenden Sie den Vorgang "Auftrag aktivieren". Der Auftrag wechselt durch den enabling Zustand in den active Zustand. Batch plant dann in die Warteschlange eingereihte Aufgaben, einschließlich der Aufgaben, die von der Option Requeue an die Warteschlange zurückgegeben wurden, im Austauschpool. Aufgaben, die abgeschlossen wurden, während Batch die Option Wait angewendet hat, sowie Aufgaben, die durch die Option Terminate abgeschlossen wurden, werden nicht erneut ausgeführt.

Kapazitätsplanung und -verwaltung

Der normale Knotenwiederherstellungsprozess des Batches versucht, Knoten zu ersetzen, die während eines Zonenfehlers unbrauchbar werden, und den Pool auf die konfigurierte Anzahl der Zielknoten wiederherzustellen. Es erhöht dieses Ziel nicht. Um genügend Kapazität für die Workload vorzuhalten, damit sie weiterläuft, wenn eine Zone nicht verfügbar ist, sollten Sie die Kapazität des Pools überprovisionieren durch automatische Skalierung oder manuelle Anpassung:

• Wenn Sie Autoskalierung verwenden: Verweisen Sie in der Autoskalierungsformel des Pools auf die $UsableNodeCount vom Dienst definierte Variable, um zu ermitteln, wann die verwendbare Kapazität unter den Basiswert fällt, den Ihre Workload benötigt. $UsableNodeCountist eine Batch-Autoskalenvariable für den Pool, dessen Formel ausgewertet wird, nicht eine Azure Monitor Metrik. Azure Monitor veröffentlicht Metriken für die Batchknotenanzahl im Bereich des Batchkontos, und diese Metriken verfügen nicht über eine poolId Dimension.

• Wenn Sie die Kapazität manuell verwalten: Verwenden Sie den Vorgang List Pool Node Counts, um die Anzahl dedizierter Knoten und Spotknoten in jedem Zustand für jeden Pool abzurufen. Der Vorgang gibt keine einzelne Anzahl nutzbarer Knoten zurück. Bewerten Sie aufgabenfähige Status wie idle und running im Vergleich mit nicht verfügbaren oder Problemstatus wie unusable, unknown, offline und startTaskFailed. Die zurückgegebenen Anzahlen sind möglicherweise nicht aktuell, also listen Sie die Computeknoten des Pools auf, wenn Sie eine genaue Anzahl benötigen.

Batch verteilt Knoten über Zonen auf best-effort-Basis, sodass die tatsächliche Verteilung möglicherweise nicht gleich ist. Gehen Sie nicht davon aus, dass Knoten gleichmäßig über Zonen verteilt sind, wenn Sie die Kapazität planen. Überprüfen Sie, ob Ihre Workload ihre Wiederherstellungsziele mit reduzierter Poolkapazität erfüllen kann.

Verhalten, wenn alle Zonen fehlerfrei sind

In diesem Abschnitt wird beschrieben, was Sie erwarten müssen, wenn ein Batchpool die Platzierung der Verfügbarkeitszone verwendet und alle Zonen betriebsbereit sind.

• Zonenübergreifender Betrieb: Batch plant Aufgaben auf verfügbaren Computeknoten im gesamten Pool, unabhängig von der Zone, in der sich der jeweilige Knoten befindet.

• Zonenübergreifende Datenreplikation: Batch-Computeknoten sind kurzlebig und Batch repliziert keine Aufgabendateien zwischen Zonen. Sie sind für das Verschieben von Eingabe-, Ausgabe-, Prüfpunkt- und Diagnosedaten verantwortlich, die den Verlust eines Knotens auf dauerhaftem Speicher überleben müssen. Konfigurieren Sie die Redundanz des Speicherkontos, um Ihre Verfügbarkeitsanforderungen zu erfüllen.

Verhalten bei einem Zoneausfall

In diesem Abschnitt wird beschrieben, was zu erwarten ist, wenn ein Batchpool die Platzierung der Verfügbarkeitszone verwendet und eine Verfügbarkeitszone nicht verfügbar ist.

• Erkennung und Reaktion: Microsoft überwacht den Batchdienst und den Zustand der Computeknoten. Während eines Zonenfehlers erkennt Batch einen anhaltenden Verlust von Heartbeats von betroffenen Knoten und startet seinen normalen Knotenwiederherstellungsprozess. Knoten in fehlerfreien Zonen bleiben verfügbar, und Batch kann Aufgaben darauf weiterhin planen.

  Batch versucht, den Pool über den normalen Wiederherstellungsvorgang auf die konfigurierte Zielanzahl an Knoten wiederherzustellen, erhöht diese Zielanzahl jedoch nicht. Sie sind dafür verantwortlich, zusätzliche Kapazität anzufordern, wenn das Zielsystem nicht genügend Kapazität für die Workload bereitstellt.

• Notification: Microsoft benachrichtigt Sie nicht automatisch, wenn eine Zone abfällt. Sie können jedoch Azure Service Health verwenden, um den Gesamtstatus des Diensts zu verstehen, einschließlich aller Zonenfehler, und Sie können Service Health Alerts einrichten, um Sie über Probleme zu informieren.

• Aktive Aufgaben: Aufgaben, die auf betroffenen Knoten ausgeführt werden, werden unterbrochen. Batch kann Vorgänge auf verfügbaren Knoten im Rahmen des internen Wiederherstellungsverhaltens neu planen. Entwerfen Sie Aufgaben so, dass sie Wiederholungen und erneute Ausführung tolerieren, wie in Resilienz gegenüber vorübergehenden Fehlern und Resilienz gegenüber Ausfällen von Computeknoten beschrieben.

• Erwarteter Datenverlust: Dateien auf den betroffenen Computeknoten sind während des Ausfalls nicht verfügbar und gehen verloren, wenn die Knoten neu aufgesetzt oder aus dem Pool entfernt werden. Batch repliziert diese Dateien nicht zonenübergreifend. Daten, die im dauerhaften Speicher gespeichert werden, bleiben gemäß der Redundanzkonfiguration dieser Speicherressource verfügbar.

• Erwartete Ausfallzeiten: Vorgänge auf fehlerfreien Knoten laufen weiter. Unterbrochene Vorgänge erleben Ausfallzeiten, bis Batch sie auf geeignete Knoten neu planen kann. Wenn kein verwendbarer Knoten verfügbar ist, verbleibt eine Aufgabe möglicherweise im running Zustand, bis Batch sie neu planen kann. Die Wiederherstellungszeit hängt von der verfügbaren Poolkapazität und der in der Warteschlange befindlichen Arbeitslast ab.

  Verwaltungsvorgänge in Bezug auf Batchkonten und andere Batchressourcen werden fortgesetzt, wenn sich das Konto in einer Region befindet, in der die Steuerebene zonensicher ist. In anderen Regionen sind Verwaltungsvorgänge möglicherweise nicht verfügbar, bis sich die betroffene Zone erholt.

• Umverteilung: Nach anhaltendem Heartbeat-Verlust markiert Batch betroffene Knoten als unusable und leitet sie durch den normalen Knotenwiederherstellungsprozess zum Ersetzen weiter. Batch versucht, die konfigurierte Zielknotenanzahl des Pools wiederherzustellen, aber die Ersatzkapazität hängt von der Kontingent- und VM-Verfügbarkeit in den fehlerfreien Zonen ab.

  Aufträge bleiben während dieses Prozesses dem Pool zugeordnet. Batch setzt die Planung von Vorgängen aus aktiven Aufträgen auf verwendbaren Knoten in funktionsfähigen Zonen weiterhin fort. Wenn Ersetzungsknoten bereitgestellt werden und nutzbar werden, kann Batch auch Vorgänge auf diesen Knoten planen.

  Dieser Wiederherstellungsvorgang erhöht nicht die konfigurierte Zielknotenanzahl. Wenn Ihre Workload über dieses Ziel hinaus Kapazität benötigt, erhöhen Sie sie manuell, oder konfigurieren Sie die Autoskalenformel des Pools, um dies zu tun.

Zonenwiederherstellung

Batch verwaltet den Wiederherstellungsvorgang, wenn sich eine Zone nach einem Fehler erholt. Batch folgt demselben Prozess, der in Resilienz bei Ausfällen von Computeknoten definiert ist.

Batch garantiert nicht, dass Knoten nach der Wiederherstellung gleichmäßig auf Verfügbarkeitszonen neu verteilt werden. Die Zonenplatzierung erfolgt weiterhin nur nach bestem Bemühen.

Test auf Zonenfehler

Sie können einen tatsächlichen Azure Ausfall der Verfügbarkeitszone für Tests nicht simulieren. Verwenden Sie stattdessen einen Nichtproduktionspool, um repräsentative Aufgaben zu unterbrechen und genügend Rechenknoten aus dem Dienst zu nehmen, um den erwarteten Kapazitätsverlust annähernd nachzubilden. Erwägen Sie die Verwendung der folgenden unterstützten Knotenoperationen:

• Starten Sie ausgewählte Knoten neu.
• Deaktivieren Sie die Aufgabenplanung auf ausgewählten Knoten.
• Entfernt ausgewählte Knoten aus dem Pool.

Wenn Sie bei einem Vorgang auswählen können, wie laufende Aufgaben behandelt werden sollen, wählen Sie die Option Requeue aus, damit Batch die unterbrochenen Aufgaben auf den verbleibenden Knoten planen kann.

Überprüfen Sie während des Tests, ob Batch unterbrochene Aufgaben neu einplant und dass die erneute Ausführung keine doppelte oder inkonsistente Ausgabe erzeugt. Stellen Sie sicher, dass Prüfpunkte und Ausgabe im dauerhaften Speicher verfügbar bleiben, die Überwachung Knotenverlust und verringerte Kapazität erkennt und die Workload mit der verbleibenden Kapazität fertiggestellt werden kann.

Diese Vorgänge überprüfen Task-Unterbrechung und Neuplanung, Idempotenz, Checkpointing und dauerhafte Ausgabebehandlung. Sie reproduzieren jedoch nicht jeden Effekt eines zonenweiten Fehlers.

Widerstandsfähigkeit bei regionalen Ausfällen

Ein Batchkonto und seine Pools sind auf eine Azure-Region beschränkt. Wenn in der Region ein Fehler auftritt, sind Ihre Batchaufträge und Pools möglicherweise betroffen.

Batch repliziert keine Konten, Poolkonfiguration, Aufträge, Aufgaben, Anwendungspakete oder Aufgabendaten in eine andere Region und bietet kein integriertes regionsübergreifendes Failover. Sie sind für die Bereitstellung und den Betrieb einer Multiregion-Batchlösung verantwortlich, wenn Ihre Workload einen regionalen Ausfall tolerieren muss.

Maßgeschneiderte Multi-Region-Lösungen für mehr Resilienz

Um eine Multiregion-Lösung zu erstellen, stellen Sie mindestens ein Batchkonto in jeder Region bereit, die in Ihrem Wiederherstellungskonzept verwendet wird. Batchkonten arbeiten regionenübergreifend unabhängig voneinander. Sie sind dafür verantwortlich, die Regionen auszuwählen, die Ressourcen in den einzelnen Regionen bereitzustellen und zu betreiben sowie Konfiguration, Replikation, Failover und Failback zu koordinieren.

Sie können einen aktiv-aktiven Ansatz entwerfen, der während des normalen Betriebs Arbeit in mehreren Regionen übermittelt, oder einen aktiv passiven Ansatz, der die sekundäre Bereitstellung für failoverbereit hält. Aktiv-aktive Architekturen können die Wiederherstellungszeit reduzieren, da beide Bereitstellungen während des normalen Betriebs Workloads verarbeiten, während aktiv-passive Architekturen die Rechenkosten im Normalbetrieb reduzieren können.

Die folgende Liste enthält Beispiele für Ihre Verantwortlichkeiten beim Entwerfen der Lösung:

• Bereitstellung: Erstellen Sie die Batchkonten, Pools oder Poolbereitstellungsdefinitionen, Speicherkonten, Netzwerkressourcen und andere Abhängigkeiten in den einzelnen Regionen vorab. Stellen Sie sicher, dass jede ausgewählte Region die Batchfeatures, VM-Größen und abhängigen Dienste unterstützt, die Ihre Workload erfordert. Behalten Sie jedes Batchkonto und die Speicherressourcen, die von den zugehörigen Aufgaben verwendet werden, wenn möglich in derselben Region, um unnötige Wartezeiten zu vermeiden. Definieren Sie Batchkonten, Pools und unterstützende Ressourcen mithilfe der Infrastruktur als Code, damit die Konfiguration konsistent in allen Regionen reproduziert werden kann.

• Kontingente und Kapazität: Überprüfen Sie die entsprechenden Batchkonto-, Abonnement- und VM-Familienkontingente in jeder Wiederherstellungsregion und beantragen Sie falls nötig vor einem Ausfall Erhöhungen. Bei einem Kontingent handelt es sich um einen Grenzwert und nicht um eine Kapazitätsgarantie. Die Vm-Verfügbarkeit variiert je nach Region, VM-Familie und Zeit. Weitere Informationen finden Sie unter Batch-Konto und Kernkontingente.

• Datenreplikation: Halten Sie Anwendungspakete, Containerimages, Eingabedaten und Referenzdaten in jedem Wiederherstellungsbereich zur Verfügung. Batch repliziert diese Elemente nicht für Sie.

• Speicherreplikation: Konfigurieren Sie Speicherredundanz und die regionsübergreifende Datenreplikation basierend auf Ihrem Wiederherstellungspunktziel. Stellen Sie sicher, dass auf replizierte Daten aus jeder Recovery-Region zugegriffen werden kann. Informationen zu Optionen für die Speicherzuverlässigkeit finden Sie unter Zuverlässigkeit in Azure Blob Storage.

• Regionsausrichtung: Wenn Ihre Anwendungen mit Ihrem Batchkonto arbeiten, entwerfen Sie sie so, dass sie ein anderes Batchkonto und die zugehörigen Speicherressourcen auswählen können, ohne dass eine Codebereitstellung erforderlich ist.

• Failover: Batch verschiebt Ihre Workload nicht automatisch in eine andere Region. Sie sind dafür verantwortlich, einen Ausfall zu erkennen, zu bestimmen, wie sich der Ausfall auf Ihre Arbeitsauslastung auswirkt, Übermittlungen an das betroffene Batchkonto zu beenden, neue Arbeit an ein Batchkonto in einer fehlerfreien Region zu leiten und zu entscheiden, ob unterbrochene Aufträge erneut übermittelt werden sollen. Arbeits- oder Vorgangsausgabe, die Sie nicht außerhalb der betroffenen Region repliziert haben, ist möglicherweise nicht verfügbar oder verloren. Ihre Wiederherstellungszeit hängt von Ihrem Bereitstellungsmodell, verfügbarer Kapazität, Datenreplikation und Automatisierung ab.

• Regionswiederherstellung: Nachdem die Dienstverfügbarkeit in der betroffenen Region wiederhergestellt wurde, überprüfen Sie das Batchkonto, Pools, Speicherabhängigkeiten und den Auftragsstatus, bevor Sie Arbeit an diese Region weiterleiten. Gleichen Sie doppelte oder teilweise abgeschlossene Vorgänge vor der erneuten Einsendung ab. Batch koordiniert weder diesen Prozess noch stimmt es den Zustand zwischen regionalen Konten ab.

• Tests: Testen Sie regelmäßig den vollständigen regionalen Wiederherstellungsprozess in einer Nichtproduktionsumgebung. Simulieren Sie, dass eine regionale Bereitstellung nicht verfügbar wird, leiten Sie Übermittlungen an ein anderes regionales Batch-Konto weiter, überprüfen Sie den Zugriff auf Anwendungspakete und Eingabedaten, führen Sie repräsentative Aufträge aus, sammeln Sie die Ausgabe und üben Sie, die wiederhergestellte Bereitstellung wieder in Betrieb zu nehmen. Messen Sie die Ergebnisse anhand Ihres Recovery Time Objective (RTO) und Ihres Recovery Point Objective (RPO).

Sichern und Wiederherstellen

Azure Batch ist kein dauerhafter Speicher für Eingabe- und Ausgabedaten für Workloads. Microsoft verwaltet den Batchdienst, aber Sie sind dafür verantwortlich, die Konfiguration und die Daten beizubehalten, die erforderlich sind, um Ihre Workload neu zu erstellen:

• Batchkonfiguration: Definieren Sie Batchkonten, Pools, Aufträge und unterstützende Ressourcen mithilfe der Infrastruktur als Code, z. B. Bicep, und versionsgesteuerte Auftragsdefinitionen. Diese Artefakte bieten eine wiederholbare Möglichkeit, die Konfiguration in derselben Region oder einer anderen Region neu zu erstellen. Testen Sie regelmäßig, dass die Definitionen einen Pool deployen und einen repräsentativen Job ausführen können.

• Batchmetadaten: Batch behält Auftrags- und Aufgabendatensätze bei, bis Sie den zugeordneten Auftrag oder die zugeordnete Aufgabe löschen, aber diese Datensätze sind keine Sicherung. Wenn Sie diesen Verlauf beibehalten müssen, bewahren Sie die erforderlichen Datensätze außerhalb von Batch auf.

• Daten zu Computeknoten: Computeknoten sind kurzlebig, und ihre Dateisysteme sind kein Sicherungs- oder dauerhafter Speicher. Daten auf einem Knoten gehen verloren, wenn der Knoten neu aufgesetzt wird oder einen Pool verlässt. Batch kann Aufgabendateien auch löschen, nachdem der Aufbewahrungszeitraum abgelaufen ist. Schreiben Sie erforderliche Ausgabe- und Diagnoseprotokolle in persistenten Speicher, bevor eine Aufgabe abgeschlossen wird. Bei lang laufenden Aufgaben speichern Sie während der Ausführung Checkpoints. Weitere Informationen finden Sie unter Auftrags- und Taskausgabe beibehalten und Azure Batch überwachen.

• Daten in autostorage-Konten: Ein zugeordnetes autostorage-Konto kann Anwendungspakete und Vorgangsressourcendateien enthalten. Überlegen Sie zusätzlich zur Konfiguration von Redundanz, die Ihren Wiederherstellungszielen entspricht, ob Sie diese Daten vor versehentlicher Löschung oder Beschädigung schützen müssen. Weitere Informationen finden Sie unter Sicherung und Wiederherstellung in Azure Blob Storage.

Wiederherstellungs- und Recovery-Tests

Stellen Sie zum Wiederherstellen die Batchkonfiguration und die unterstützende Ressourcenkonfiguration bereit, stellen Sie die erforderlichen Eingabedaten und Anwendungsartefakte wieder her oder verbinden Sie sie erneut, und übermitteln Sie die nicht abgeschlossene Arbeit erneut. Testen Sie in regelmäßigen Abständen sowohl die Ressourcenrekonstruktion als auch die Datenwiederherstellung in einer isolierten oder nichtproduktiven Wiederherstellungsumgebung. Verwenden Sie versionsgesteuerte Definitionen und gesicherte Daten, führen Sie einen repräsentativen Job aus, überprüfen Sie die resultierende Ausgabe und den Zugriff auf Abhängigkeiten und messen Sie die erzielte Wiederherstellungszeit und das Wiederherstellungspunktziel anhand Ihrer Ziele. Vergewissern Sie sich, dass Aufgaben idempotent sind, damit das erneute Übermitteln von Arbeit mit unklarem Status keine Daten beschädigt oder doppelte Ausgaben erstellt.

Resilienz gegenüber Wartungsarbeiten an Diensten

Microsoft führt Plattformwartung durch und koordiniert Infrastrukturupdates für Azure Batch und andere Dienste. Sie sind dafür verantwortlich, das Verhalten von Poolupdates zu konfigurieren und Aufgaben so zu entwerfen, dass Unterbrechungen toleriert werden.

• Hostwartung: Azure verwendet Wartungstechniken wie die Livemigration nach Möglichkeit. Wenn für die Wartung ein Computeknoten neu gestartet werden muss oder verschoben wird, kann die Ausführung von Aufgaben unterbrochen werden, und Batch plant sie möglicherweise neu. Machen Sie Aufgaben idempotent, und speichern Sie Prüfpunkte und Ausgabe in einem dauerhaften Speicher.

• Gastbetriebssystem: Sie sind dafür verantwortlich, das Gastbetriebssystem und den Batchknoten-Agent aktuell zu halten. Das Verhalten des Betriebssystemupdates hängt von der Image- und Updatekonfiguration ab. Mit entsprechender Konfiguration können automatische Betriebssystemimageupgrades für Batchpools Poolknoten aktualisieren, ohne die laufenden Aufgaben zu unterbrechen. Automatische Betriebssystemimageupgrades unterstützen nicht jedes Batchbetriebssystemimage.

• Knoten-Agent-Updates: Automatische Betriebssystemimageupgrades aktualisieren nicht automatisch den Batchknoten-Agent. Batchknoten-Agents werden nicht automatisch aktualisiert, solange ein Pool über Computeknoten verfügt. Um einen neueren Knoten-Agent zu erhalten, ändern Sie die Größe des Pools auf Nullknoten, und skalieren Sie ihn erneut, oder ersetzen Sie den Pool. Bewahren Sie vor dem Entfernen von Knoten alle erforderlichen Aufgabenausgabe- und Diagnoseprotokolle auf. Weitere Informationen finden Sie unter Aktualisierungen des Batchknoten-Agents.

Folgen Sie den Empfehlungen für die Produktionsbereitstellung und der Anleitung zu Ausfällen von Computeknoten, damit Ihre Workload fortgesetzt oder wiederhergestellt werden kann, wenn die Wartung Aufgaben unterbricht oder Computeknoten nicht verfügbar macht.

Service-Level-Vereinbarung

Der Service level agreement (SLA) für Azure-Dienste beschreibt die erwartete Verfügbarkeit jedes Diensts und die Bedingungen, die Ihre Lösung erfüllen muss, um diese Verfügbarkeitserwartungen zu erreichen. Weitere Informationen finden Sie unter Dienstleistungsvereinbarungen für Onlinedienste.

Die Azure Batch Verfügbarkeits-SLA gilt für Vorgänge, die Sie über die Batch-API ausführen. Ausführliche Informationen zu den typen von Vorgängen, die enthalten sind, finden Sie in der SLA-Formulierung. Die Größe des Pools, die Zonenverteilung und die abhängigen Dienste wirken sich auf die End-to-End-Verfügbarkeit der Workload aus, ändern jedoch nicht die Bedingungen der Batch-SLA.

Verwandte Inhalte

• Azure Batch-Dokumentation
• Bewährte Methoden für Azure Batch
• Zuverlässigkeit in Azure