Azure Batch-Pool- und -Knotenfehler

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Einige Erstellungs- und Verwaltungsvorgänge für Azure Batch-Pools werden sofort ausgeführt. Das Erkennen von Fehlern für diese Vorgänge ist einfach, da Fehler in der Regel sofort von der API, der Befehlszeile oder der Benutzeroberfläche zurückgegeben werden. Einige Vorgänge werden aber asynchron und im Hintergrund ausgeführt. Es kann einige Minuten dauern, bis diese Vorgänge abgeschlossen ist. In diesem Artikel wird beschrieben, wie Sie Fehler in den Hintergrundvorgängen für Pools und Knoten erkennen und vermeiden können.

Stellen Sie sicher, dass Sie Ihre Anwendungen so konfiguriert haben, dass eine umfassende Fehlerprüfung implementiert ist, insbesondere für asynchrone Vorgänge. Eine umfangreiche Fehlerüberprüfung kann Ihnen helfen, Probleme schnell zu identifizieren und zu diagnostizieren.

Poolfehler

Poolfehler können sich auf Timeouts oder Fehler bei der Größenänderung, auf Fehler bei der automatischen Skalierung oder auf Fehler beim Löschen des Pools beziehen.

Timeout oder Fehler bei Größenänderung

Wenn Sie einen neuen Pool erstellen oder die Größe eines vorhandenen Pools ändern, geben Sie die geplante Anzahl der Knoten an. Der Vorgang für die Erstellung oder Änderung der Größe wird unmittelbar abgeschlossen, aber die tatsächliche Zuordnung der neuen bzw. die Entfernung vorhandener Knoten kann einige Minuten dauern. Sie können das Timeout für die Größenänderung in den APIs Pool – Hinzufügen oder Pool – Ändern der Größe angeben. Falls Azure Batch die Zielanzahl von Knoten während des Timeouts für die Größenänderung nicht zuordnen kann, wird der Pool in einen stabilen Zustand versetzt und meldet Größenänderungsfehler.

Die Eigenschaft resizeError listet die bei der aktuellen Auswertung aufgetretenen Fehler auf.

Häufige Gründe für Größenänderungsfehler sind:

  • Timeout für die Größenänderung zu kurz. In der Regel ist das Standardtimeout von 15 Minuten lang genug, um Poolknoten zuzuweisen oder zu entfernen. Wenn Sie eine große Anzahl von Knoten zuweisen, z. B. mehr als 1.000 Knoten aus einem Azure Marketplace-Image oder mehr als 300 Knoten aus einem benutzerdefinierten VM-Image, können Sie das Timeout für die Größenänderung auf 30 Minuten festlegen.

  • Kernkontingent nicht ausreichend. Die Anzahl der Kerne, die über alle Pools hinweg zugeordnet werden können, ist in einem Azure Batch-Konto begrenzt, und die Zuweisung von Knoten wird beendet, sobald dieses Kontingent erreicht ist. Sie können das Kernkontingent erhöhen, sodass Azure Batch mehr Knoten zuordnen kann. Weitere Informationen finden Sie im Artikel Batch-Dienst – Kontingente und Limits.

  • Nicht genügend Subnetz-IP-Adressen, wenn sich ein Pool in einem virtuellen Netzwerk befindet. Das Subnetz eines virtuellen Netzwerks muss über ausreichend IP-Adressen verfügen, die allen angeforderten Poolknoten zugeordnet werden können. Andernfalls können die Knoten nicht erstellt werden. Weitere Informationen finden Sie unter Erstellen eines Azure Batch-Pools in einem virtuellen Netzwerk.

  • Nicht genügend Ressourcen, wenn sich ein Pool in einem virtuellen Netzwerk befindet. Beim Erstellen eines Pool in einem virtuellen Netzwerk können Sie Ressourcen, wie z. B. Lastenausgleichsmodule, öffentliche IP-Adressen und Netzwerksicherheitsgruppen (NSGs), im selben Abonnement wie das Azure Batch-Konto erstellen. Vergewissern Sie sich, dass die Abonnementkontingente für diese Ressourcen ausreichend sind.

  • Große Pools mit benutzerdefinierten VM-Images. Die Zuordnung großer Pools, die benutzerdefinierte Images verwenden, kann länger dauern und zu Timeouts bei Größenänderungen führen. Empfehlungen zu Grenzwerten und zur Konfiguration finden Sie unter Erstellen eines Pools mit Azure Compute Gallery.

Fehler bei der automatischen Skalierung

Sie können Azure Batch so konfigurieren, dass die Anzahl der Knoten in einem Pool automatisch skaliert wird, und Sie definieren die Parameter für die Formel zur automatischen Skalierung für den Pool. Der Azure Batch-Dienst verwendet die Formel dann, um die Anzahl der Knoten im Pool regelmäßig auszuwerten und eine neue Zielanzahl festzulegen. Weitere Informationen finden Sie unter Erstellen einer Formel für die automatische Skalierung von Computeknoten in einem Azure Batch-Pool.

Bei Verwendung der automatischen Skalierung können die folgenden Probleme auftreten:

  • Die Auswertung für die automatische Skalierung schlägt fehl.
  • Die resultierende Größenänderung schlägt fehl und führt zu einem Timeout.
  • Ein Problem mit der automatischen Skalierungsformel führt zu falschen Zielwerten für die Knoten. Entweder funktioniert die Größenänderung, oder es tritt ein Timeout auf.

Verwenden Sie die Eigenschaft autoScaleRun, um Informationen zur letzten Auswertung für eine automatische Skalierung abzurufen. Diese Eigenschaft meldet die Auswertungszeit, die Werte und das Ergebnis sowie eventuelle Leistungsfehler.

Das Ereignis zum Abschluss der Größenänderung von Pools erfasst Informationen zu sämtlichen Auswertungen.

Fehler beim Löschen von Pools

Um einen Pool, der Knoten enthält, zu löschen, löscht Azure Batch zunächst die Knoten. Dies kann einige Minuten dauern. Anschließend löscht Azure Batch das eigentliche Poolobjekt.

Der poolState wird von Azure Batch während des Löschvorgangs auf „deleting“ festgelegt. Die aufrufende Anwendung kann mithilfe der Eigenschaften state und stateTransitionTime erkennen, ob der Löschvorgang im Pool zu lange dauert.

Wenn die Poollöschung länger als erwartet dauert, wiederholt Azure Batch den Vorgang in regelmäßigen Abständen, bis der Pool erfolgreich gelöscht wurde. In einigen Fällen ist die Verzögerung auf einen Azure-Dienstausfall oder andere temporäre Probleme zurückzuführen. Bei anderen Faktoren, die eine erfolgreiche Löschung des Pools verhindern, müssen Sie möglicherweise Maßnahmen ergreifen, um das Problem zu beheben. Hierzu können die folgenden Probleme gehören:

  • Ressourcensperren können auf von Azure Batch erstellte Ressourcen oder auf von Azure Batch verwendete Netzwerkressourcen angewandt werden.

  • Die erstellten Ressourcen können eine Abhängigkeit von einer Ressource aufweisen, die von Azure Batch erstellt wurde. Wenn Sie beispielsweise einen Pool in einem virtuellen Netzwerk erstellen, erstellt Azure Batch eine Netzwerksicherheitsgruppe (NSG), eine öffentliche IP-Adresse und einen Lastenausgleich. Wenn Sie diese Ressourcen außerhalb des Pools verwenden, können Sie den Pool nicht löschen.

  • Die Registrierung des Ressourcenanbieters Microsoft.Batch wurde möglicherweise für das Abonnement mit Ihrem Pool aufgehoben.

  • Für Azure Batch-Konten im Benutzerabonnementmodus hat Microsoft Azure Batch möglicherweise nicht mehr die Rollen Mitwirkender oder Besitzer für das Abonnement, das Ihren Pool enthält. Weitere Informationen finden Sie unter Gewähren des Zugriffs auf Ihr Abonnement für Azure Batch.

Knotenfehler

Selbst wenn Azure Batch Knoten in einem Pool erfolgreich zuweist, können verschiedene Probleme dazu führen, dass einige Knoten fehlerhaft sind und keine Tasks ausführen können. Da für diese Knoten weiterhin Gebühren anfallen, ist es wichtig, Probleme zu erkennen, um zu verhindern, dass Sie für Knoten bezahlen, die nicht genutzt werden können. Das Wissen um häufige Knotenfehler und die Kenntnis des aktuellen JobStatus sind bei der Fehlersuche hilfreich.

Fehler bei Starttask

Sie können einen optionalen startTask für einen Pool angeben. Wie bei jedem Task verwendet der Starttask eine Befehlszeile und kann Ressourcendateien aus dem Speicher herunterladen. Der Starttask wird für jeden Knoten beim Start ausgeführt. Die waitForSuccess-Eigenschaft gibt an, ob Azure Batch wartet, bis der Starttask erfolgreich abgeschlossen ist, ehe weitere Tasks für einen Knoten geplant werden. Wenn Sie den Knoten so konfigurieren, dass er auf den erfolgreichen Abschluss des Starttasks wartet, der Starttask aber fehlschlägt, ist der Knoten nicht verwendbar, es fallen jedoch weiterhin Gebühren an.

Starttaskfehler können Sie mithilfe der Eigenschaften taskExecutionResult und taskFailureInformation der Knoteneigenschaft startTaskInformation der obersten Ebene erkennen.

Ein fehlgeschlagener Starttask führt auch dazu, dass Azure Batch computeNodeState auf „starttaskfailed“ festlegt, wenn waitForSuccess auf „true“ festgelegt wurde.

Wie bei jedem anderen Task kann es viele Ursachen für einen Fehler bei Starttasks geben. Zur Fehlerbehebung sollten Sie stdout, stderr und weitere taskspezifische Protokolldateien überprüfen.

Starttasks müssen eintrittsinvariant sein, da der Starttask mehrere Male auf demselben Knoten ausgeführt werden kann, z. B., wenn für den Knoten ein Reimaging oder ein Neustart durchgeführt wird. In seltenen Fällen, wenn ein Starttask ausgeführt wird, nachdem ein Ereignis einen Knotenneustart verursacht, erfolgt für ein Betriebssystem oder einen kurzlebigen Datenträger ein Reimaging, für andere aber nicht. Da Azure Batch-Starttasks und alle Azure Batch-Tasks vom kurzlebigen Datenträger ausgeführt werden, ist diese Situation in der Regel kein Problem. In Fällen, in denen der Starttask jedoch eine Anwendung auf dem Betriebssystemdatenträger installiert und andere Daten auf dem kurzlebigen Datenträger speichert, kann es zu Synchronisierungsproblemen kommen. Schützen Sie Ihre Anwendung entsprechend, falls Sie beide Datenträger verwenden.

Fehler beim Herunterladen des Anwendungspakets

Sie können ein oder mehrere Anwendungspakete für einen Pool angeben. Die angegebenen Paketdateien werden von Azure Batch auf die einzelnen Knoten heruntergeladen und nach dem Starten der Knoten, aber vor der Planung der Tasks, dekomprimiert. Normalerweise wird ein Starttaskbefehl mit Anwendungspaketen verwendet, um z.B. Dateien an einen anderen Speicherort zu kopieren oder ein Setup auszuführen.

Wenn ein Anwendungspaket nicht heruntergeladen und dekomprimiert werden kann, meldet die Eigenschaft computeNodeError den Fehler und legt den Knotenstatus auf „unusable“ fest.

Fehler beim Herunterladen von Containern

Sie können in einem Pool eine oder mehrere Containerreferenzen angeben. Batch lädt die angegebenen Container auf die einzelnen Knoten herunter. Wenn der Container nicht heruntergeladen werden kann, meldet die Eigenschaft computeNodeError den Fehler und legt den Knotenstatus auf „unusable“ fest.

Betriebssystemupdates für Knoten

Für Windows-Pools ist enableAutomaticUpdates standardmäßig auf true festgelegt. Es wird zwar empfohlen, automatische Updates zuzulassen, aber diese können den Fortschritt von Tasks unterbrechen, insbesondere wenn diese zeitintensiv sind. Sie können diesen Wert auf false festlegen, wenn Sie sicherstellen müssen, dass ein Betriebssystemupdate nicht unerwartet durchgeführt werden soll.

Knoten mit dem Status „Nicht verwendbar“

Es kann verschiedene Ursachen dafür geben, dass Azure Batch den computeNodeState auf „unusable“ festlegt. Sie können keine Tasks für einen unusable-Knoten planen, aber für den Knoten fallen weiterhin Gebühren an.

Wenn Azure Batch die Ursache bestimmen kann, wird sie von der Eigenschaft computeNodeError gemeldet. Wenn sich ein Knoten im Status „unusable“ befindet, aber keinen computeNodeError aufweist, bedeutet dies, dass Azure Batch nicht mit dem virtuellen Computer kommunizieren kann. In diesem Fall versucht Batch immer, den virtuellen Computer wiederherzustellen. Azure Batch versucht nicht automatisch, virtuelle Computer, die keine Anwendungspakete oder Container installiert konnten, wiederherzustellen, auch wenn ihr Status „unusable“ lautet.

Andere Gründe für unusable-Knoten können die folgenden Ursachen sein:

  • Ein benutzerdefiniertes VM-Image ist ungültig. Das Bild wurde beispielsweise nicht ordnungsgemäß vorbereitet.
  • Eine VM wird aufgrund eines Infrastrukturausfalls oder eines niedrigstufigen Upgrades verschoben. Azure Batch stellt den Knoten wieder her.
  • Ein VM-Image wurde auf Hardware bereitgestellt, von der es nicht unterstützt wird. Beispiel: Ein CentOS-HPC-Image wird auf einer Standard_D1_v2-VM bereitgestellt.
  • Die VMs befinden sich in einem virtuellen Azure-Netzwerk, und der Datenverkehr zu den Schlüsselports wurde blockiert.
  • Die VMs befinden sich in einem virtuellen Netzwerk, aber der ausgehende Datenverkehr an Azure Storage ist blockiert.
  • Die VMs befinden sich in einem virtuellen Netzwerk mit einer benutzerdefinierten DNS-Konfiguration, und der DNS-Server kann Azure Storage nicht auflösen.

Protokolldateien des Knoten-Agents

Der Azure Batch-Agent-Prozess, der auf jedem Poolknoten ausgeführt wird, stellt Protokolldateien bereit, die hilfreich sein können, wenn Sie den Support bei einem Problem mit einem Poolknoten kontaktieren müssen. Sie können Protokolldateien für einen Knoten über das Azure-Portal, den Azure Batch Explorer oder die API Computeknoten – Hochladen der Protokolle des Azure Batch-Diensts hochladen. Nachdem Sie die Protokolldateien hochgeladen und gespeichert haben, können Sie den Knoten oder Pool löschen, um die Kosten für die Ausführung der Knoten zu sparen.

Knotendatenträger voll

Azure Batch verwendet das temporäre Laufwerk auf einer Knotenpool-VM, um Dateien wie die folgenden Auftragsdateien, Taskdateien und freigegebenen Dateien zu speichern:

  • Anwendungspaketdateien
  • Taskressourcendateien
  • Anwendungsspezifische Dateien, die in einen Batch-Ordner heruntergeladen wurden
  • stdout- und stderr-Dateien für jede Ausführung von Taskanwendungen
  • Anwendungsspezifische Ausgabedateien

Dateien wie Anwendungspakete oder Starttask-Ressourcendateien werden nur einmal geschrieben, wenn Azure Batch den Poolknoten erstellt. Auch wenn diese Dateien nur einmal geschrieben werden, können sie den gesamten Speicherplatz des temporären Laufwerks belegen, falls sie zu groß sind.

Andere Dateien, z. B stdout und stderr, werden für jeden von einem Knoten ausgeführten Task geschrieben. Wenn eine große Zahl von Tasks auf demselben Knoten ausgeführt wird oder die Taskdateien zu groß sind, ist das temporäre Laufwerk damit unter Umständen bereits gefüllt.

Der Knoten benötigt zudem ein wenig Speicherplatz auf dem Betriebssystemdatenträger, um nach dem Start Benutzer zu erstellen.

Die Größe des temporären Laufwerks hängt von der Größe des virtuellen Computers ab. Eine Überlegung bei der Auswahl der VM-Größe ist es, sicherzustellen, dass das temporäre Laufwerk genügend Platz für die geplante Arbeitslast bietet.

Wenn Sie im Azure-Portal einen Pool hinzufügen, können Sie die vollständige Liste der VM-Größen anzeigen, einschließlich einer Spalte Größe des Ressourcendatenträgers. Die Artikel, in denen VM-Größen beschrieben werden, enthalten Tabellen mit einer Spalte Temporärer Speicher. Weitere Informationen finden Sie unter Für Compute optimierte VM-Größen. Eine Beispielgrößentabelle finden Sie unter Fsv2-Serie.

Sie können für eine Aufbewahrungszeit Dateien, die von den einzelnen Tasks geschrieben werden, festlegen. Die Aufbewahrungszeit bestimmt, wie lange die Taskdateien aufbewahrt werden sollen, bevor sie automatisch bereinigt werden. Sie können die Aufbewahrungszeit verringern, um die Speicheranforderungen zu verringern.

Wenn auf dem temporären Datenträger oder dem Betriebssystemdatenträger nicht genügend Speicherplatz vorhanden ist oder der Speicherplatz knapp wird, wechselt der Knoten in den computeNodeState „unusable“, und der Knotenfehler besagt, dass der Datenträger voll ist.

Sollten Sie nicht sicher sein, wodurch der Speicherplatz auf dem Knoten beansprucht wird, versuchen Sie, eine Remoteverbindung mit dem Knoten herzustellen und die Ursache manuell zu untersuchen. Sie können auch die API Datei – Liste aus Computeknoten verwenden, um Dateien, z. B. Taskausgaben, in von Azure Batch verwalteten Ordnern zu untersuchen. Beachten Sie, dass diese API nur Dateien in den von Azure Batch verwalteten Verzeichnissen auflistet. Wenn Ihre Tasks Dateien an anderer Stelle erstellt haben, werden diese von dieser API nicht angezeigt.

Nachdem Sie sichergestellt haben, dass Sie alle benötigten Daten vom Knoten abgerufen oder in einen dauerhaften Speicher hochgeladen haben, können Sie die Daten nach Bedarf löschen, um Speicherplatz freizugeben.

Sie können alte abgeschlossene Aufträge oder Tasks löschen, deren Taskdaten sich noch auf den Knoten befinden. Suchen Sie in der recentTasks-Sammlung in taskInformation auf dem Knoten, oder verwenden Sie die API Datei – Liste aus Computeknoten. Beim Löschen eines Auftrags werden alle Tasks im Auftrag gelöscht. Das Löschen der Tasks im Auftrag löst das Löschen von Daten in den Taskverzeichnissen auf den Knoten aus und gibt Speicherplatz frei. Nachdem Sie genügend Speicherplatz freigegeben haben, starten Sie den Knoten neu. Der Knoten sollte aus dem Status unusable wieder in „idle“ wechseln.

Sie können mithilfe der API Pool – Entfernen von Knoten einen Knoten aus dem Pool entfernen, um einen nicht verwendbaren Knoten in VirtualMachineConfiguration-Pools wiederherzustellen. Anschließend können Sie den Pool wieder vergrößern, um den fehlerhaften Knoten durch einen neuen Knoten zu ersetzen. Für CloudServiceConfiguration-Pools können Sie das -Reimaging des Knotens durchführen, indem Sie die API Computeknoten – Reimaging verwenden, um den gesamten Datenträger zu bereinigen. Für Pools vom Typ VirtualMachineConfiguration wird das Reimaging derzeit nicht unterstützt.

Nächste Schritte