Azure Batch: bewährte Methoden

  • Artikel

In diesem Artikel werden bewährte Methoden und nützliche Tipps für die effiziente Verwendung des Azure Batch-Diensts vorgestellt. Diese Tipps können Ihnen helfen, die Leistung zu verbessern und Entwurfsfehler bei Ihren Batch-Lösungen zu vermeiden.

Tipp

Informationen zur Sicherheit in Azure Batch finden Sie unter Bewährte Methoden für die Sicherheit und Konformität von Azure Batch.

Pools

Pools sind die Computeressourcen zum Ausführen von Aufträgen im Batch-Dienst. Die folgenden Abschnitte enthalten Empfehlungen zum Arbeiten mit Batch-Pools.

Poolkonfiguration und Benennung

  • Poolzuordnungsmodus: Beim Erstellen eines Batch-Kontos können Sie zwischen zwei Modi der Poolzuordnung wählen: Batch-Dienst und Benutzerabonnement. In den meisten Fällen sollten Sie den standardmäßigen Batchdienstmodus wählen, in dem Pools im Hintergrund von Batch verwalteten Abonnements zugeordnet werden. Im alternativen Benutzerabonnementmodus werden virtuelle Batchcomputer und andere Ressourcen direkt in Ihrem Abonnement erstellt, wenn ein Pool erstellt wird. Benutzerabonnementkonten werden in erster Linie verwendet, um eine kleine, aber wichtige Teilmenge von Szenarien zu unterstützen. Weitere Informationen finden Sie unter Konfiguration für den Benutzerabonnementmodus.

  • virtualMachineConfiguration oder cloudServiceConfiguration: Obwohl Sie Pools derzeit mithilfe einer der beiden Konfigurationen erstellen können, sollten neue Pools mit virtualMachineConfiguration und nicht mit cloudServiceConfiguration konfiguriert werden. Alle aktuellen und neuen Batch-Funktionen werden von den Pools der Konfiguration des virtuellen Computers unterstützt. Pools mit Cloud Service-Konfiguration unterstützen nicht alle Features, und es sind keine neuen Funktionen geplant. Sie können nach dem 29. Februar 2024 weder neue cloudServiceConfiguration-Pools erstellen noch vorhandenen Pools neue Knoten hinzuzufügen. Weitere Informationen finden Sie unter Migrieren der Batch-Poolkonfiguration von Cloud Services zu Virtual Machines.

  • classic- oder simplified-Knotenkommunikationsmodus: Pools können in den Knotenkommunikationsmodi „klassisch“ oder vereinfacht konfiguriert werden. Im klassischen Knotenkommunikationsmodell initiiert der Batch-Dienst die Kommunikation mit den Serverknoten, und Serverknoten müssen auch mit Azure Storage kommunizieren. Im vereinfachten Knotenkommunikationsmodell initiieren Serverknoten die Kommunikation mit dem Batch-Dienst. Aufgrund des reduzierten Bereichs der erforderlichen eingehenden/ausgehenden Verbindungen und des nicht erforderlichen ausgehenden Azure Storage-Zugriffs für den Basisbetrieb wird empfohlen, das vereinfachte Knotenkommunikationsmodell zu verwenden. Einige zukünftige Verbesserungen am Batch-Dienst erfordern auch das vereinfachte Knotenkommunikationsmodell. Das klassische Knotenkommunikationsmodell wird am 31. März 2026 eingestellt.

  • Überlegungen zu Ausführungszeiten für Aufträge und Aufgaben: Wenn Sie über Aufträge verfügen, die hauptsächlich aus Aufgaben mit kurzer Ausführungszeit bestehen, und die erwartete Gesamtanzahl der Aufgaben niedrig ist, sodass auch die zu erwartende Gesamtausführungszeit des Auftrags nicht lang ist, sollten Sie nicht für jeden Auftrag einen neuen Pool zuordnen. Die Zuordnungszeit der Knoten verringert die Laufzeit des Auftrags.

  • Mehrere Serverknoten: Es ist nicht garantiert, dass einzelne Knoten immer verfügbar sind. Wenn auch ungewöhnlich, so können Hardwareausfälle, Betriebssystemupdates und eine Menge anderer Probleme dazu führen, dass einzelne Knoten offline sind. Wenn Ihr Batch-Workload deterministischen, garantierten Fortschritt erfordert, sollten Sie Pools mit mehreren Knoten zuordnen.

  • Images mit bevorstehendem EOL-Datum: Es wird dringend empfohlen, Images mit bevorstehenden EOL-Datum (End of Life, Ende der Lebensdauer) für die Batch-Unterstützung zu vermeiden. Die Datumsangaben für die Unterstützungseinstellung können Sie über die ListSupportedImages-API, PowerShell oder über die Azure CLI ermitteln. Es liegt in Ihrer Verantwortung, die Ansicht der für Ihre Pools relevanten EOL-Datumsangaben in regelmäßigen Abständen zu aktualisieren und Ihre Workloads vor dem EOL zu migrieren. Wenn Sie ein benutzerdefiniertes Image mit einem angegebenen Knoten-Agent verwenden, müssen Sie sicherstellen, dass Sie die EOL-Datumsangaben der Batch-Unterstützung für das Image berücksichtigen, von dem Ihr benutzerdefiniertes Image abgeleitet oder an dem es ausgerichtet wird. Ein Image ohne batchSupportEndOfLife-Datum gibt an, dass ein solches Datum noch nicht vom Batch-Dienst festgelegt wurde. Das Fehlen eines Datums bedeutet nicht, dass das jeweilige Image unbegrenzt unterstützt wird. Ein EOL-Datum kann jederzeit in der Zukunft hinzugefügt oder aktualisiert werden.

  • VM-SKUs mit bevorstehendem End-of-Life (EOL): Wie bei VM-Images kann auch bei VM-SKUs oder -Familien das Ende der Batch-Unterstützung (EOL) erreicht werden. Die Datumsangaben für die Unterstützungseinstellung können Sie über die ListSupportedVirtualMachineSkus-API, PowerShell oder über die Azure CLI ermitteln. Planen Sie die Migration Ihrer Workload zu einer VM-SKU ohne EOL, indem Sie einen neuen Pool mit einer entsprechenden unterstützten VM-SKU erstellen. Das Fehlen eines zugeordneten batchSupportEndOfLife Datums für eine VM-SKU weist nicht darauf hin, dass bestimmte VM-SKU auf unbegrenzte Zeit unterstützt wird. Ein EOL-Datum kann jederzeit in der Zukunft hinzugefügt oder aktualisiert werden.

  • Eindeutige Ressourcennamen: Batch-Ressourcen (Aufträge, Pools usw.) ändern sich häufig im Laufe der Zeit. Beispielsweise erstellen Sie vielleicht am Montag einen Pool, den Sie am Dienstag löschen, um dann am Donnerstag einen weiteren ähnlichen Pool zu erstellen. Jeder neue Ressource, die Sie erstellen, sollte einen eindeutigen Name erhalten, den Sie zuvor noch nicht verwendet haben. Für die Eindeutigkeit können Sie eine GUID (entweder als vollständiger Ressourcennamen oder als Teil davon) verwenden oder das Datum und die Uhrzeit der Ressourcenerstellung in den Ressourcennamen einbetten. Batch unterstützt DisplayName, sodass Sie einer Ressource einen benutzerfreundlicheren Namen geben können, auch wenn die tatsächliche Ressourcen-ID weniger benutzerfreundlich ist. Durch die Verwendung eindeutiger Namen können Sie leichter unterscheiden, welche spezifische Ressource in Protokollen und Metriken etwas bewirkt hat. Außerdem entfällt hierdurch jede eventuelle Mehrdeutigkeit, wenn Sie jemals eine Supportanfrage für eine Ressource einreichen müssen.

  • Kontinuität bei Wartung und Ausfällen des Pools: Ihre Aufträge sollten Pools dynamisch verwenden. Wenn Ihre Aufträge denselben Pool für sämtliche Aufgaben verwenden, kann es vorkommen, dass Ihre Aufträge bei einem Problem mit dem Pool nicht ausgeführt werden können. Dieses Prinzip ist besonders wichtig für zeitkritische Workloads. Sie können z. B. einen Pool dynamisch auswählen oder erstellen, wenn Sie die einzelnen Aufträge planen, oder Sie implementieren eine Methode, um den Poolnamen außer Kraft zu setzen, sodass fehlerhafte Pools umgangen werden können.

  • Geschäftskontinuität während Poolverwaltung und -ausfall: Es gibt zahlreiche Gründe, aus denen ein Pool nicht die gewünschte Größe erreichen kann, z. B. interne Fehler oder Kapazitätsbeschränkungen. Stellen Sie sicher, dass Sie Aufträge bei Bedarf einem anderen Pool zuweisen können (möglicherweise mit einer anderen VM-Größe über UpdateJob). Verlassen Sie sich nicht auf eine statische Pool-ID in der Erwartung, dass diese nie gelöscht wird und sich nie ändert.

Poolsicherheit

Isolationsgrenze

Wenn es für Ihr Szenario erforderlich ist, Jobs oder Aufgaben voneinander zu isolieren, tun Sie dies, indem Sie sie in separaten Pools ablegen. Ein Pool ist die Sicherheitsisolierungsgrenze in Batch, und standardmäßig sind zwei Pools nicht gegenseitig sichtbar und können auch nicht miteinander kommunizieren. Vermeiden Sie die Verwendung separater Batch-Konten als Mittel zur Sicherheitsisolierung, es sei denn, die größere Umgebung, in der das Batch-Konto betrieben wird, erfordert eine Isolierung.

Batchknoten-Agent-Updates

Batch-Knotenagents werden nicht automatisch für Pools aktualisiert, die mindestens einen Serverknoten haben. Um sicherzustellen, dass Ihre Batch-Pools die neuesten Sicherheitsfixes und Updates für den Batch-Knoten-Agent erhalten, müssen Sie entweder die Größe des Pools auf null Serverknoten ändern oder den Pool neu erstellen. Es wird empfohlen, die Versionshinweise zum Batch-Knoten-Agent zu überwachen, um die Änderungen an neuen Batch-Knoten-Agent-Versionen zu verstehen. Wenn Sie regelmäßig nach neu veröffentlichten Updates suchen, können Sie Upgrades auf die neueste Agent-Version planen.

Bevor Sie Ihren Pool neu erstellen oder seine Größe ändern, sollten Sie alle Knoten-Agent-Protokolle zu Debuggingzwecken herunterladen, wenn Sie Probleme mit Ihrem Batch-Pool oder Serverknoten haben. Dieser Prozess wird im Abschnitt Knoten näher erläutert.

Hinweis

Allgemeine Anleitungen zur Sicherheit in Azure Batch finden Sie unter bewährte Methoden für Batch-Sicherheit und -Compliance.

Betriebssystemupdates

Es wird empfohlen, dass das für einen Batch-Pool ausgewählte VM-Image mit den neuesten vom Herausgeber bereitgestellten Sicherheitsupdates auf dem neuesten Stand gehalten wird. Einige Images können beim Start (oder kurz danach) automatische Updates ausführen, die bestimmte benutzergesteuerte Aktionen beeinträchtigen können, z. B. das Abrufen von Paketrepositoryupdates (z. B. apt update) oder das Installieren von Paketen während Aktionen wie StartTask.

Azure Batch überprüft oder garantiert nicht, dass Images, die für die Verwendung mit dem Dienst zulässig sind, über die neuesten Sicherheitsupdates verfügen. Aktualisierungen zu Images fallen in den Zuständigkeitsbereich des Herausgebers des Images und nicht in den von Azure Batch. Für bestimmte unter microsoft-azure-batch veröffentlichte Images gibt es keine Garantie, dass diese Bilder mit ihrem Upstream-abgeleiteten Image auf dem neuesten Stand gehalten werden.

Lebensdauer und Abrechnung für Pools

Die Poollebensdauer kann abhängig von der Zuordnungsmethode und den auf die Poolkonfiguration angewendeten Optionen variieren. Pools können eine beliebige Lebensdauer und zu jedem Zeitpunkt eine unterschiedliche Anzahl von Rechenknoten aufweisen. Es liegt in Ihrer Verantwortung, die Serverknoten im Pool entweder explizit oder durch vom Dienst bereitgestellte Features (Autoskalierung oder automatischer Pool) zu verwalten.

  • Erneutes Erstellen von Pools: Vermeiden Sie es, Pools täglich zu löschen und neu zu erstellen. Erstellen Sie stattdessen einen neuen Pool, und aktualisieren Sie die vorhandenen Aufträge, sodass sie auf den neuen Pool verweisen. Nachdem alle Aufgaben in den neuen Pool verschoben wurden, löschen Sie den alten Pool.

  • Pooleffizienz und Abrechnung: für Batch selbst fallen keine zusätzlichen Gebühren an. Für genutzte Azure-Ressourcen fallen Gebühren jedoch an, z. B. für Compute-, Speicher-, Netzwerk- und andere Ressourcen, die möglicherweise für Ihre Batch-Workload erforderlich sind. Ihnen wird jeder Computeknoten im Pool in Rechnung gestellt, unabhängig davon, in welchem Zustand er sich befindet. Weitere Informationen zu bewährten Methoden finden Sie im Artikel zu Kostenanalyse und Budgets für Azure Batch.

  • Kurzlebige Betriebssystemdatenträger: VM-Konfigurationspools können kurzlebige Betriebssystemdatenträger verwenden. Sie erstellen den Betriebssystemdatenträger im VM-Cache oder temporären SSD, um zusätzliche Kosten im Zusammenhang mit verwalteten Datenträgern zu vermeiden.

Fehler bei der Poolzuordnung

Fehler bei der Poolzuordnung können jederzeit während der ersten Zuordnung oder bei nachfolgenden Größenänderungen auftreten. Diese Fehler können an einer vorübergehenden Kapazitätserschöpfung in einer Region oder an Fehlern in anderen Azure-Diensten liegen, auf denen Batch basiert. Ihr Kernkontingent ist keine Garantie, sondern ein Limit.

Ungeplante Ausfallzeiten

Es ist möglich, dass es bei Batch-Pools in Azure zu Ausfallzeiten kommt. Sie sollten verstehen, dass Probleme auftreten können, und Ihren Workflow so entwickeln, dass er gegenüber erneuten Ausführungen widerstandsfähig ist. Wenn Knoten ausfallen, versucht Batch automatisch, diese Computeknoten in Ihrem Auftrag wiederherzustellen. Diese Wiederherstellung kann das Umplanen von ausgeführten Aufgaben auf dem wiederhergestellten Knoten oder auf einem anderen verfügbaren Knoten auslösen. Weitere Informationen zu unterbrochenen Aufgaben finden Sie unter Entwerfen für Wiederholungsversuche.

Benutzerdefinierte Imagepools

Wenn Sie einen Azure Batch-Pool mithilfe der Konfiguration des virtuellen Computers erstellen, geben Sie das Image eines virtuellen Computers (VM) an, das das Betriebssystem für jeden Computeknoten im Pool bereitstellt. Sie können den Pool mit einem unterstützten Azure Marketplace-Image erstellen oder ein benutzerdefiniertes Image aus einem Azure Compute Gallery-Image erstellen. Sie können zum Erstellen eines benutzerdefinierten Imagepools ein verwaltetes Image verwenden. Es empfiehlt sich jedoch, nach Möglichkeit mit Azure Compute Gallery benutzerdefinierte Images zu erstellen. Durch die Verwendung von Azure Compute Gallery können Sie Pools schneller bereitstellen, eine größere Anzahl von VM skalieren und die Zuverlässigkeit bei der Bereitstellung von VMs verbessern.

Images von Drittanbietern

Pools können mithilfe von auf Azure Marketplace veröffentlichten Images von Drittanbietern erstellt werden. Bei Batch-Konten im Benutzerabonnementmodus kann beim Erstellen eines Pools mit bestimmten Images von Drittanbietern der Fehler „Fehler bei der Zuweisung aufgrund der Prüfung der Berechtigung zum Kauf über den Marketplace“ auftreten. Akzeptieren Sie die vom Herausgeber des Images festgelegten Bedingungen, um diesen Fehler zu beheben. Sie können dazu Azure Powershell oder die Azure CLI verwenden.

Abhängigkeit von Azure-Regionen

Sie sollten sich nicht auf eine einzige Azure-Region verlassen, wenn Sie eine zeitkritische oder eine Produktionsworkload verarbeiten. In seltenen Fällen kann es Probleme geben, die sich auf eine ganze Region auswirken können. Wenn Ihre Verarbeitung beispielsweise zu einem bestimmten Zeitpunkt gestartet werden muss, sollten Sie erwägen, den Pool in ihrer primären Region zentral hochzuskalieren, und zwar eine ganze Weile im Voraus vor der Startzeit. Wenn diese Poolskalierung fehlschlägt, können Sie als Plan B einen Pool in einer (oder mehreren) Sicherungsregion(en) zentral hochskalieren.

Pools über mehrere Konten hinweg in unterschiedlichen Regionen bieten eine bereite, leicht zugängliche Sicherung, wenn bei einem anderen Pool etwas schiefgeht. Weitere Informationen finden Sie unter Entwerfen Ihrer Anwendung für Hochverfügbarkeit.

Aufträge

Ein Auftrag ist ein Container, der auf die Aufnahme Hunderter, Tausender oder sogar von Millionen von Aufgaben ausgelegt ist. Beachten Sie beim Erstellen von Aufträgen die folgenden Richtlinien.

Weniger Aufträge, mehr Aufgaben

Die Verwendung eines Auftrags zum Ausführen einer einzelnen Aufgabe ist ineffizient. Beispielsweise ist es effizienter, einen einzelnen Auftrag mit 1.000 Aufgaben zu verwenden, statt 100 Aufträge zu erstellen, die jeweils 10 Aufgaben enthalten. Wenn Sie 1.000 Aufträge mit jeweils einer einzelnen Aufgabe verwenden, wäre dies der ineffizienteste, langsamste und teuerste Ansatz.

Vermeiden Sie den Entwurf einer Batch-Lösung, die Tausende gleichzeitig aktiver Aufträge erfordert. Es gibt kein Kontingent für Aufgaben. Wenn Sie also viele Aufgaben unter so wenigen Aufträgen wie möglich ausführen, werden Ihre Kontingente für Aufträge und die Zeitplanung von Aufträgen effizient genutzt.

Lebensdauer von Aufträgen

Ein Batch-Auftrag hat eine unbegrenzte Lebensdauer, bis er aus dem System gelöscht wird. Sein Zustand bestimmt, ob er mehr Aufgaben für die Planung annehmen kann oder nicht.

Ein Auftrag wechselt nicht automatisch in den Zustand „Abgeschlossen“, es sei denn, er wurde explizit beendet. Diese Aktion kann automatisch über die onAllTasksComplete-Eigenschaft oder maxWallClockTime ausgelöst werden.

Es gibt ein standardmäßiges Kontingent für aktive Aufträge und die Zeitplanung von Aufträgen. Aufträge und Auftragszeitpläne im Zustand „Abgeschlossen“ werden nicht auf dieses Kontingent angerechnet.

Löschen Sie Aufträge, wenn sie nicht mehr benötigt werden, auch wenn der Status abgeschlossen ist. Obwohl abgeschlossene Aufträge nicht auf das aktive Auftragskontingent zählen, ist es vorteilhaft, abgeschlossene Aufträge regelmäßig zu bereinigen. Beispielsweise ist das Auflisten von Aufträgen effizienter, wenn die Gesamtzahl der Aufträge kleiner ist (auch wenn auf die Anforderung geeignete Filter angewendet werden).

Aufgaben

Aufgaben sind einzelne Arbeitseinheiten, die einen Auftrag bilden. Tasks werden vom Benutzer übermittelt und von Batch auf Computeknoten geplant. Die folgenden Abschnitte enthalten Vorschläge zum Entwurf Ihrer Aufgaben, um sie effizient auszuführen und Probleme zu behandeln.

Speichern von Aufgabendaten

Computeknoten sind von Natur aus kurzlebig. Batch-Features wie z. B. automatische Pools und Autoskalierung können dazu führen, dass Knoten einfach wegfallen. Wenn Knoten aus einem Pool entfernt werden (aufgrund einer Größenänderung oder der Löschung eines Pools), werden auch alle Dateien auf diesen Knoten gelöscht. Aufgrund dieses Verhaltens sollte die Ausgabe einer Aufgabe aus dem Knoten, auf dem sie ausgeführt wird, in einen permanenten Speicher verschoben werden, bevor sie abgeschlossen wird. Wenn eine Aufgabe fehlschlägt, sollten auch die für die Diagnose des Fehlers erforderlichen Protokolle in einen permanenten Speicher verschoben werden.

Batch verfügt über integrierte Unterstützung für Azure Storage zum Hochladen von Daten über OutputFiles sowie eine Vielzahl von freigegebenen Dateisystemen. Sie können den Upload auch selbst in Ihren Aufgaben durchführen.

Verwalten der Lebensdauer von Aufgaben

Löschen Sie Aufgaben, wenn sie nicht mehr benötigt werden, oder legen Sie eine Einschränkung durch eine retentionTime-Aufgabe fest. Wenn eine retentionTime festgelegt wird, bereinigt Batch automatisch den von der Aufgabe verwendeten Speicherplatz, wenn die retentionTime abläuft.

Durch das Löschen von Aufgaben werden zwei Dinge erreicht:

  • Sicherstellen, dass sich keine Aufgaben im Auftrag ansammeln: Mit dieser Aktion können Sie Schwierigkeiten beim Finden der gewünschten Aufgabe vermeiden, da Sie die abgeschlossenen Aufgaben filtern müssen.
  • Bereinigen der zugehörigen Aufgabendaten auf dem Knoten (sofern retentionTime nicht bereits erreicht wurde): Diese Aktion hilft sicherzustellen, dass Ihre Knoten nicht mit Aufgabendaten aufgefüllt werden und der Speicherplatz knapp wird.

Hinweis

Für Aufgaben, die gerade an Batch übermittelt wurden, dauert der DeleteTask-API-Aufruf bis zu 10 Minuten, bis er wirksam wird. Bevor er wirksam wird, werden möglicherweise andere Aufgaben daran gehindert, geplant zu werden. Dies liegt daran, dass der Batch-Planer weiterhin versucht, die gerade gelöschten Aufgaben zu planen. Wenn Sie eine Aufgabe kurz nach ihrer Einreichung löschen möchten, beenden Sie die Aufgabe stattdessen (da die Anforderung zum Beenden der Aufgabe sofort wirksam wird). Löschen Sie dann die Aufgabe 10 Minuten später.

Übermitteln einer großen Anzahl von Aufgaben in einer Sammlung

Aufgaben können einzeln oder in Sammlungen übermittelt werden. Übermitteln Sie Aufgaben in Sammlungen von bis zu 100 Stück gleichzeitig, wenn Sie eine Massenübermittlung von Aufgaben durchführen, um den Aufwand und die Übermittlungszeiten zu verringern.

Festlegen einer angemessenen maximalen Anzahl von Aufgaben pro Knoten

Batch unterstützt das Überabonnieren von Aufgaben auf Knoten (Ausführen von mehr Aufgaben, als ein Knoten über Kerne verfügt). Sie müssen selbst sicherstellen, dass Ihre Aufgaben die richtige Größe für die Knoten in Ihrem Pool haben. Es kann beispielsweise zu einer verschlechterten Erfahrung kommen, wenn Sie versuchen, acht Aufgaben zu planen, die jeweils 25 % CPU-Auslastung auf einem Knoten verbrauchen (in einem Pool mit taskSlotsPerNode = 8).

Entwerfen für Wiederholungsversuche und erneute Ausführung

Aufgaben können von Batch automatisch wiederholt werden. Es gibt zwei Arten von Wiederholungsversuchen: benutzergesteuert und intern. Benutzergesteuerte Wiederholungsversuche werden über die maxTaskRetryCount der Aufgabe angegeben. Wenn ein in der Aufgabe angegebenes Programm mit einem Exitcode ungleich 0 (null) beendet wird, wird die Aufgabe so oft, wie im Wert maxTaskRetryCount angegeben, wiederholt.

Zwar ist dies selten, doch eine Aufgabe kann aufgrund von Fehlern auf dem Computeknoten intern wiederholt werden, z. B. wenn der interne Zustand nicht aktualisiert werden kann oder ein Fehler auf dem Knoten auftritt, während die Aufgabe ausgeführt wird. Die Aufgabe wird, falls möglich, auf demselben Computeknoten bis zu einem internen Limit wiederholt, bevor die Aufgabe aufgegeben und dann zur Neuplanung durch Batch verzögert wird, potenziell auf einem anderen Computeknoten.

Es gibt keine Entwurfsunterschiede beim Ausführen Ihrer Aufgaben auf dedizierten oder Spot-Knoten. Unabhängig davon, ob eine Aufgabe bei der Ausführung auf einem Spot-Knoten mit niedriger Priorität vorzeitig entfernt oder aufgrund eines Fehlers auf einem dedizierten Knoten unterbrochen wird, werden in beiden Situationen die Fehler in der Aufgabe abgemildert, so dass diese ausfallsicher sind.

Erstellen von permanenten Vorgängen

Aufgaben sollten so entworfen werden, dass Sie Fehlern widerstehen und eine Wiederholung ermöglichen. Dieses Prinzip ist besonders wichtig für zeitintensive Aufgaben. Stellen Sie sicher, dass mit den Aufgaben auch dann immer das gleiche Ergebnis generiert wird, wenn sie mehrfach ausgeführt werden. Eine Möglichkeit, dies zu erreichen, besteht in der „Zielsuche“. Eine andere Möglichkeit besteht darin sicherzustellen, dass Ihre Aufgaben idempotent sind (Aufgaben haben das gleiche Ergebnis, unabhängig davon, wie oft sie ausgeführt werden).

Ein gängiges Beispiel hierfür ist eine Aufgabe zum Kopieren von Dateien auf einen Computeknoten. Ein einfacher Ansatz ist eine Aufgabe, die bei jeder Ausführung alle angegebenen Dateien kopiert, was ineffizient und nicht robust ist. Erstellen Sie stattdessen eine Aufgabe, um sicherzustellen, dass sich die Dateien auf dem Computeknoten befinden, eine Aufgabe, die keine Dateien wiederholt kopiert, die bereits vorhanden sind. Auf diese Weise setzt die Aufgabe an der Stelle fort, an der Sie aufgehört hatte oder unterbrochen wurde.

Vermeiden kurzer Ausführungszeit

Aufgaben, die nur für eine bis zwei Sekunden ausgeführt werden, sind nicht ideal. Versuchen Sie, eine signifikante Menge an Arbeit in einer einzelnen Aufgabe zu verrichten (mindestens 10 Sekunden, bis zu Stunden oder Tage). Wenn jede Aufgabe für eine Minute (oder mehr) ausgeführt wird, ist der Planungsaufwand als Anteil an der gesamten Computezeit gering.

Verwenden des Poolbereichs für Aufgaben mit kurzer Ausführungszeit in Windows-Knoten

Beim Planen einer Aufgabe in Batch-Knoten können Sie auswählen, ob sie mit dem Aufgabenbereich oder dem Poolbereich ausgeführt werden soll. Wenn die Aufgabe nur für kurze Zeit ausgeführt wird, kann der Aufgabenbereich aufgrund der erforderlichen Ressourcen zum Erstellen des automatischen Benutzerkontos für diese Aufgabe ineffizient sein. Zur Effizienzsteigerung können Sie diese Aufgaben auf den Poolbereich festlegen. Weitere Informationen finden Sie unter Ausführen einer Aufgabe als automatischer Benutzer mit Poolbereich.

Nodes

Ein Serverknoten ist ein virtueller Azure-Computer (VM) oder ein virtueller Clouddienstcomputer, der für die Verarbeitung eines Teils der Anwendungsworkload fest zugeordnet ist. Beachten Sie beim Arbeiten mit Knoten die folgenden Richtlinien.

Starten von Aufgaben: Lebensdauer und Idempotenz

Wie bei anderen Vorgängen sollte der Knoten Aufgabe starten idempotent sein. Startaufgaben werden erneut ausgeführt, wenn der Computeknoten neu gestartet wird oder der Batch-Agent neu gestartet wird. Bei einer idempotenten Aufgabe handelt es sich um eine Aufgabe, die bei mehreren Wiederholungen ein konsistentes Ergebnis erzeugt.

Startaufgaben sollten nicht lang ausgeführt werden oder mit der Lebensdauer des Computeknotens gekoppelt sein. Wenn Sie Programme starten müssen, die Dienste oder dienstähnliche Dienste sind, erstellen Sie eine Startaufgabe, mit der diese Programme gestartet und von Betriebssystemeinrichtungen wie systemd unter Linux- oder Windows-Diensten gestartet und verwaltet werden können. Der Startvorgang sollte weiterhin als idempotent erstellt werden, sodass die nachfolgende Ausführung der Startaufgabe ordnungsgemäß behandelt wird, wenn diese Programme zuvor als Dienste installiert wurden.

Tipp

Wenn Batch Ihre Startaufgabe erneut ausführt, wird versucht, das Verzeichnis der Startaufgabe zu löschen und erneut zu erstellen. Wenn Batch das Startaufgabenverzeichnis nicht neu erstellt, kann der Computeknoten die Startaufgabe nicht starten.

Diese Dienste dürfen keine Dateisperren für Dateien in von Batch verwalteten Verzeichnissen auf dem Knoten einrichten, da Batch sonst diese Verzeichnisse wegen der Dateisperren nicht löschen kann. Anstatt beispielsweise den Start des Diensts direkt aus dem Arbeitsverzeichnis der Startaufgabe zu konfigurieren, kopieren Sie die Dateien an anderer Stelle in einer idempotenten Weise. Installieren Sie dann den Dienst von diesem Speicherort aus mit den Betriebssystemeinrichtungen.

Isolierte Knoten

Ziehen Sie die Verwendung von isolierten VM-Größen für Workloads mit Compliance- oder regulatorischen Anforderungen in Betracht. Zu den unterstützten isolierten Größen im Konfigurationsmodus des virtuellen Computers gehören Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5 und Standard_E64i_v3. Weitere Informationen zu isolierten VM-Größen finden Sie unter Isolation von virtuellen Computern in Azure.

Vermeiden der Erstellung von Verzeichnisverbindungen

Verzeichnisverbindungen, manchmal auch als feste Verzeichnisverknüpfungen bezeichnet, sind während der Aufgaben- und Auftragsbereinigung schwierig zu behandeln. Verwenden Sie symlinks (symbolische Verknüpfungen) anstelle von festen Verknüpfungen.

Temporäre Datenträger und AZ_BATCH_NODE_ROOT_DIR

Batch basiert auf temporären VM-Datenträgern und auf mit Batch kompatiblen VM-Größen, um Metadaten im Zusammenhang mit der Aufgabenausführung zusammen mit allen Artefakten sämtlicher Aufgabenausführungen auf diesem temporären Datenträger zu speichern. Beispiele für Bereitstellungspunkte von temporären Datenträgern oder Verzeichnisse sind: /mnt/batch, /mnt/resource/batch und D:\batch\tasks. Das Ersetzen, erneute Einbinden, Verknüpfen, symbolische Verknüpfen (symlink) oder sonstige Umleiten dieser Bereitstellungspunkte und Verzeichnisse oder eines der übergeordneten Verzeichnisse wird nicht unterstützt und kann zu Instabilität führen. Wenn Sie mehr Speicherplatz benötigen, sollten Sie eine VM-Größe oder -Familie verwenden, die über temporären Speicherplatz verfügt, der Ihren Anforderungen entspricht, oder Datenträger anfügen. Weitere Informationen finden Sie im nächsten Abschnitt zum Anfügen und Vorbereiten von Datenträgern für Serverknoten.

Anfügen und Vorbereiten von Datenträgern für Daten

Jedem einzelnen Serverknoten ist genau dieselbe Datenträgerspezifikation angefügt, wenn er als Teil der Batch-Poolinstanz angegeben wird. Nur neue Datenträger können an Batch-Pools angefügt werden. Diese an Serverknoten angefügten Datenträger werden nicht automatisch partitioniert, formatiert oder eingebunden. Es liegt in Ihrer Verantwortung, diese Vorgänge im Rahmen Ihrer Startaufgabe auszuführen. Diese Startaufgaben müssen idempotent sein. Die erneute Ausführung der Startaufgaben auf Computeknoten ist möglich. Wenn die Startaufgabe nicht idempotent ist, können auf den Datenträgern Datenverluste auftreten.

Tipp

Wenn Sie beim Einbinden eines Datenträgers unter Linux den Datenträgerbereitstellungspunkt unter den temporären Azure-Bereitstellungspunkten (etwa /mnt oder /mnt/resource) schachteln, sollte darauf geachtet werden, dass keine Racebedingungen für Abhängigkeiten eingeführt werden. Wenn diese Einbindungen beispielsweise automatisch vom Betriebssystem ausgeführt werden, kann es zu einer Racebedingung zwischen dem temporären Datenträger, der eingebunden wird, und Ihren Datenträgern kommen, die unter dem übergeordneten Datenträger eingebunden werden. Es sollten Schritte unternommen werden, um sicherzustellen, dass geeignete Abhängigkeiten von verfügbaren Einrichtungen erzwungen werden, z. B. systemd. Verschieben Sie alternativ die Einbindung des Datenträgers als Teil Ihres idempotenten Datenträgervorbereitungsskripts in die Startaufgabe.

Vorbereiten von Datenträgern in Linux-Batch-Pools

Azure-Datenträger unter Linux werden als Blockgeräte dargestellt und mit einem typischen sd[X]-Bezeichner versehen. Sie sollten sich nicht auf statische sd[X]-Zuweisungen verlassen, da diese Bezeichnungen zum Startzeitpunkt dynamisch zugewiesen werden und ihre Beibehaltung zwischen dem ersten und jedem nachfolgenden Start nicht garantiert ist. Sie sollten Ihre angefügten Datenträger anhand der in /dev/disk/azure/scsi1/ angegebenen Zuordnungen identifizieren. Wenn Sie beispielsweise für Ihren Datenträger in der AddPool-API „LUN 0“ angegeben haben, wird dieser Datenträger als /dev/disk/azure/scsi1/lun0 festgelegt. Wenn Sie dieses Verzeichnis auflisten, könnte beispielsweise Folgendes angezeigt werden:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Es ist nicht erforderlich, den Verweis zurück in die sd[X]-Zuordnung in Ihrem Vorbereitungsskript zu übersetzen. Sie können stattdessen direkt auf das Gerät verweisen. In diesem Beispiel ist das Gerät /dev/disk/azure/scsi1/lun0. Sie können diese ID direkt in fdisk, mkfs und allen anderen Tools angeben, die für Ihren Workflow erforderlich sind. Alternativ können Sie lsblk mit blkid verwenden, um die UUID für den Datenträger zuzuordnen.

Weitere Informationen zu Azure-Datenträgern unter Linux, einschließlich alternativer Methoden zum Ermitteln von Datenträgern und /etc/fstab-Optionen, finden Sie in diesem Artikel. Stellen Sie sicher, dass keine Abhängigkeiten oder Racebedingungen vorhanden sind, wie im Tipp beschrieben, bevor Sie Ihre Methode zur Verwendung in der Produktion heraufstufen.

Vorbereiten von Datenträgern in Windows-Batch-Pools

Azure-Datenträger, die an Batch-Serverknoten unter Windows angefügt sind, werden unpartitioniert und unformatiert dargestellt. Sie müssen im Rahmen Ihrer Startaufgabe die Datenträger mit RAW-Partitionen enumerieren, um Aktionen auszuführen. Diese Informationen können mithilfe des PowerShell-Cmdlets Get-Disk abgerufen werden. Beispiel:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Dabei ist Datenträger 2 der nicht initialisierte Datenträger, der an diesen Serverknoten angefügt ist. Diese Datenträger können dann gemäß den Anforderungen Ihres Workflows initialisiert, partitioniert und formatiert werden.

Weitere Informationen zu Azure-Datenträgern unter Windows, einschließlich PowerShell-Beispielskripts, finden Sie in diesem Artikel. Stellen Sie sicher, dass alle Beispielskripts auf Idempotenz überprüft werden, bevor sie zur Verwendung in der Produktion heraufgestuft werden.

Erfassen von Batch-Agent-Protokollen

Wenn Sie ein Problem bemerken, das mit dem Verhalten eines Knotens oder einer Aufgabe, die auf einem Knoten ausgeführt wird, zusammenhängt, sollten Sie die Batch-Agent-Protokolle vor dem Aufheben der Zuordnung der fraglichen Knoten erfassen. Die Batch-Agent-Protokolle lassen sich mithilfe der API zum Hochladen von Batch-Dienstprotokollen erfassen. Diese Protokolle können als Teil eines Supporttickets an Microsoft bereitgestellt werden und helfen bei der Behandlung und Behebung von Problemen.

Verwalten von Betriebssystem-Upgrades

Bei Batch-Konten im Modus „Benutzerabonnement“ können automatische Betriebssystem-Upgrades den Taskfortschritt unterbrechen, insbesondere dann, wenn Tasks über einen längeren Zeitraum ausgeführt werden. Das Entwickeln idempotenter Tasks kann zur Reduzierung von Fehlern beitragen, die durch diese Unterbrechungen verursacht werden. Wir empfehlen außerdem, Upgrades von Betriebssystem-Images für Uhrzeiten zu planen, in denen erwartungsgemäß keine Aufgaben ausgeführt werden.

Für Windows-Pools ist enableAutomaticUpdates standardmäßig auf true festgelegt. Das Zulassen automatischer Updates wird zwar empfohlen, aber Sie können diesen Wert auf false festlegen, wenn Sie sicherstellen müssen, dass ein Betriebssystemupdate nicht unerwartet durchgeführt wird.

Batch-API

Timeoutfehler

Timeoutfehler deuten nicht unbedingt darauf hin, dass der Dienst die Anforderung nicht verarbeiten konnte. Wenn ein Timeoutfehler auftritt, sollten Sie entweder den Vorgang wiederholen oder den Status der Ressource entsprechend der Situation abrufen, um zu überprüfen, ob der Vorgang erfolgreich war oder fehlgeschlagen ist.

Konnektivität

Lesen Sie den folgenden Leitfaden zur Konnektivität in Ihren Batch-Lösungen.

Netzwerksicherheitsgruppen (NSGs) und benutzerdefinierte Routen (UDRs)

Wenn Sie Batch-Pools in einem virtuellen Netzwerk bereitstellen, sollten Sie sicherstellen, dass Sie die Richtlinien bezüglich der Verwendung des Diensttags „BatchNodeManagement.region“, der Ports, der Protokolle und der Richtung der Regel streng befolgen. Die Verwendung des Diensttags wird dringend empfohlen. Verwenden Sie keine IP-Adressen des zugrunde liegenden Batch-Diensts, da sich diese im Lauf der Zeit ändern können. Die direkte Verwendung von IP-Adressen des Batch-Diensts kann zu Instabilität, Unterbrechungen oder Ausfällen für die Batch-Pools führen.

Für benutzerdefinierte Routen (UDRs) wird empfohlen, BatchNodeManagement.region-Diensttags anstelle von IP-Adressen des Batch-Diensts zu verwenden, da diese sich im Lauf der Zeit ändern können.

Berücksichtigen von DNS

Stellen Sie sicher, dass Ihre Systeme die DNS-Gültigkeitsdauer (Time-to-Live, TTL) für Ihre Batch-Kontodienst-URL berücksichtigen. Stellen Sie darüber hinaus sicher, dass die Batch-Dienstclients und andere Konnektivitätsmechanismen für den Batch-Dienst nicht auf IP-Adressen basieren.

Für HTTP-Anforderungen mit Statuscodes der Ebene 5xx und dem Header „Connection: close“ in der Antwort muss das Verhalten des Batch-Dienstclients angepasst werden. Der Batch-Dienstclient muss die Empfehlung einhalten, indem er die vorhandene Verbindung schließt, DNS für die Batch-Kontodienst-URL erneut auflöst und dann die folgenden Anforderungen mit einer neuen Verbindung versucht.

Automatisches Wiederholen von Anforderungen

Stellen Sie sicher, dass für Ihre Batch-Dienstclients geeignete Wiederholungsrichtlinien vorhanden sind, um Ihre Anforderungen auch während des normalen Betriebs und nicht ausschließlich während der Dienstwartungszeiten zu wiederholen. Diese Wiederholungsrichtlinien sollten ein Intervall von mindestens 5 Minuten umfassen. Automatische Wiederholungsfunktionen werden mit verschiedenen Batch-SDKs bereitgestellt, etwa in der RetryPolicyProvider-Klasse von .NET.

Statische öffentliche IP-Adressen

Normalerweise erfolgt der Zugriff auf virtuelle Computer in einem Batch-Pool über öffentliche IP-Adressen, die sich während der Nutzungsdauer des Pools ändern können. Diese Dynamik kann die Interaktion mit einer Datenbank oder einem anderen externen Dienst erschweren, bei denen der Zugriff auf bestimmte IP-Adressen beschränkt ist. Aus diesem Grund können Sie einen Pool mithilfe einer Gruppe von statischen öffentlichen IP-Adressen erstellen, die Sie steuern. Weitere Informationen finden Sie unter Erstellen eines Azure Batch-Pools mit angegebenen öffentlichen IP-Adressen.

Testen der Konnektivität mit Cloud Services-Konfiguration

Sie können das normale „ping“/ICMP-Protokoll nicht mit Clouddiensten verwenden, da das ICMP-Protokoll nicht über Azure Load Balancer zugelassen wird. Weitere Informationen finden Sie unter Konnektivität und Netzwerke in Azure Cloud Services.

Zugrunde liegende Abhängigkeiten von Batch-Knoten

Beachten Sie beim Entwerfen Ihrer Batch-Lösungen die folgenden Abhängigkeiten und Einschränkungen.

Vom System erstellte Ressourcen

Azure Batch erstellt und verwaltet mehrere Benutzer*innen und Gruppen auf der VM, die nicht geändert werden sollten:

Windows:

  • Ein Benutzer mit dem Namen PoolNonAdmin
  • Eine Benutzergruppe mit dem Namen WATaskCommon

Linux:

  • Ein Benutzer mit dem Namen _azbatch

Tipp

Die Benennungen dieser Benutzer oder Gruppen sind Implementierungsartefakte und können jederzeit geändert werden.

Dateibereinigung

Batch versucht, das Arbeitsverzeichnis zu bereinigen, in dem Aufgaben ausgeführt werden, sobald die Aufbewahrungsdauer abläuft. Alle außerhalb dieses Verzeichnisses geschriebenen Dateien müssen von Ihnen bereinigt werden, um die Überfüllung des Speicherplatzes zu verhindern.

Wenn Sie einen Dienst unter Windows aus dem Arbeitsverzeichnis der Startaufgabe ausführen, wird die automatisierte Bereinigung für das Arbeitsverzeichnis blockiert, da der Ordner noch verwendet wird. Diese Aktion führt zu Leistungseinbußen. Um dieses Problem zu beheben, ändern Sie das Verzeichnis für diesen Dienst in ein anderes Verzeichnis, das nicht von Batch verwaltet wird.

Nächste Schritte