Der Azure Batch-Knoten bleibt aufgrund von Konfigurationsproblemen im nicht verwendbaren Zustand hängen

Azure Batch kann den Status eines Batchknotens aus verschiedenen Gründen auf "Nicht verwendbar" festlegen. Vorgänge können nicht in einem Knoten im nicht verwendbaren Zustand geplant werden, es entstehen jedoch weiterhin Gebühren. In den meisten Fällen versucht der Batchdienst, den Knoten wiederherzustellen. Wenn der nicht verwendbare Zustand jedoch durch ein Konfigurationsproblem verursacht wird, kann der Knoten nicht wiederhergestellt werden. In diesem Artikel werden einige häufige Konfigurationsprobleme erläutert, die dazu führen, dass Knoten nicht mehr verwendet werden können, und lösungen bereitgestellt werden.

Problem 1: Probleme bei der Konfiguration virtueller Netzwerke

In diesem Abschnitt werden die Konfigurationsprobleme des virtuellen Netzwerks (VNet) sowohl im klassischen als auch im vereinfachten Knotenkommunikationsmodus erläutert.

Klassische Knotenkommunikation

Der klassische Knotenkommunikationsmodus ist die ursprüngliche Kommunikationsweise für einen Pool, der einem Subnetz eines VNet zugeordnet ist. Dieses Feature wird im Jahr 2026 durch den vereinfachten Kommunikationsknotenmodus ersetzt.

In einem Pool, der einem Subnetz eines VNet zugeordnet ist, befinden sich alle Knoten im Zustand "Nicht verwendbar" . Auf den Knoten gibt es jedoch keinen Fehlercode .

Das vorangehende Symptom bedeutet, dass der Batchdienst nicht mit den Knoten kommunizieren kann. In den meisten Fällen wird dies durch VNet-Konfigurationsprobleme verursacht. In den folgenden Abschnitten werden die beiden häufigsten Ursachen beschrieben.

Ursache 1: Fehlende erforderliche Regeln für die Netzwerksicherheitsgruppe (NSG)

Wenn eine NSG im Subnetz konfiguriert ist, müssen Sie diese NSG so konfigurieren, dass mindestens die eingehenden und ausgehenden Sicherheitsregeln (wie im folgenden Screenshot gezeigt) vorhanden sind, damit der Batchdienst mit den Knoten kommunizieren kann. Wenn die Kommunikation mit den Knoten im angegebenen Subnetz von der NSG verweigert wird, legt der Batchdienst den Status der Knoten auf " Unbrauchbar" fest.

• Eingangssicherheitsregeln

  

• Ausgangssicherheitsregeln

  

Lösung 1: Konfigurieren von NSG für die erforderlichen eingehenden und ausgehenden Sicherheitsregeln

Um dieses Problem zu beheben, konfigurieren Sie die NSG so, dass die erforderlichen eingehenden und ausgehenden Sicherheitsregeln vorhanden sind, wie in Netzwerksicherheitsgruppen für Konfigurationspools für virtuelle Computer empfohlen: Angeben von Regeln auf Subnetzebene.

Führen Sie die folgenden Schritte aus, um die Konfiguration auszuführen:

1. Navigieren Sie vom Azure-Portal zum Pool.

2. Überprüfen Sie die Pooleigenschaften, um die VNet- und Subnetznamen abzurufen.

   

3. Navigieren Sie zum VNet. Wählen Sie auf der VNet-Seite "Einstellungen Subnetze">aus. Wählen Sie in der Liste der Subnetze das erwartete Subnetz aus. Suchen Sie im Subnetzbereich nach NSG.

   

4. Navigieren Sie zum NSG. Überprüfen Sie die Konfiguration auf der NSG-Seite.

   

5. Konfigurieren Sie diese NSG so, dass die erforderlichen Eingehenden und ausgehenden Sicherheitsregeln vorhanden sind.

6. Starten Sie den Knoten neu, um ihn in den Standardzustand zurückzugeben.

Ursache 2: Fehlende erforderliche benutzerdefinierte Routen (UDR)

Wenn das VNet, dem der Pool zugeordnet ist, erzwungenes Tunneln ermöglicht, müssen Sie einen UDR hinzufügen, der dem BatchNodeManagement.<region> Diensttag in der Region entspricht, in der Ihr Batchkonto vorhanden ist. Andernfalls wird der Datenverkehr zwischen dem Batchdienst und den Knoten blockiert, und die Computeknoten können nicht mehr verwendet werden.

Lösung 2: Hinzufügen von UDR, das BatchNodeManagement entspricht.<Regionsdiensttag>

Um dieses Problem zu beheben, fügen Sie einen UDR hinzu, der dem BatchNodeManagement.<region> Diensttag in der Region entspricht, in der Ihr Batchkonto vorhanden ist. Legen Sie dann den Typ "Nächster Hop " auf "Internet" fest. Weitere Informationen finden Sie unter Benutzerdefinierte Routen für erzwungene Tunneling.

Gehen Sie dazu wie folgt vor:

1. Navigieren Sie vom Azure-Portal zum Pool.

2. Überprüfen Sie die Pooleigenschaften, um die VNet- und Subnetznamen abzurufen.

   

3. Navigieren Sie zum VNet. Wählen Sie auf der VNet-Seite "Einstellungen Subnetze">aus. Wählen Sie in der Liste der Subnetze die Routingtabelle aus, die dem erwarteten Subnetz zugeordnet ist.

   

4. Wählen Sie auf der Stammtabellenseite>"Routen hinzufügen" aus. Fügen Sie im Bereich "Route hinzufügen" den erforderlichen UDR hinzu, und legen Sie dann den Typ " Nächster Hop " auf "Internet" fest.

   

5. Starten Sie den Knoten neu, um ihn in den Standardzustand zurückzugeben.

Vereinfachte Knotenkommunikation

Die Verwendung des vereinfachten Knotenkommunikationsmodus kann die VNet-Konfiguration in einem Pool vereinfachen. Wenn die Knoten in einem Pool, der den vereinfachten Knotenkommunikationsmodus verwendet, den nicht verwendbaren Zustand anzeigen, überprüfen Sie die folgenden möglichen Ursachen und Lösungen für die Selbstbehandlung.

Ursache 1: Fehlende ausgehende NSG-Regeln

Beim Anwenden eines VNet müssen Sie die ausgehende Anforderung vom internen Knoten auf den externen ordnungsgemäß konfigurieren. Andernfalls kann der Knoten nicht mehr verwendet werden.

Lösung 1: Hinzufügen eines ausgehenden Diensttags "BatchNodeManagement".<Region>

Um dieses Problem zu beheben, fügen Sie das BatchNodeManagement.<region> Diensttag in der ausgehenden NSG-Regel hinzu.

Weitere Informationen finden Sie unter "Ausgehende Sicherheitsregeln".

Ursache 2: Fehlender ausgehender Zugriff für die Batchknotenverwaltung

Dies gilt nur für das Szenario, in dem der Batchpool keine öffentlichen IP-Adressen hat. Standardmäßig werden allen Knoten in einem Azure Batch-Konfigurationspool für virtuelle Computer öffentliche IP-Adressen zugewiesen. Benutzer können den Pool jedoch ohne öffentliche IP-Adressen bereitstellen, um den Zugriff auf diese Knoten einzuschränken und die Auffindbarkeit dieser Knoten im Internet zu verringern. Ein Pool ohne öffentliche IP-Adressen hat standardmäßig keinen ausgehenden Internetzugriff, was zu Netzwerkkommunikationsproblemen zwischen Batchknoten und dem Batchknotenverwaltungsdienst führt.

Lösung 2: Konfigurieren eines privaten Knotenverwaltungsendpunkts

Überprüfen Sie Ihre Netzwerkeinstellungen, indem Sie zu Ihrem Batchkonto navigieren und "Netzwerkeinstellungen">auswählen. Wenn die Option "Ausgewähltes Netzwerk " oder "Deaktivieren " aktiviert ist, Sie jedoch nur einen batchAcount privaten Endpunkt konfigurieren oder keinen privaten Endpunkt konfigurieren, konfigurieren Sie einen nodeManagement privaten Endpunkt, um die interne Kommunikation zwischen Knoten sicherzustellen.

Ursache 3: Eine schlechte DNS-Konfiguration verhindert, dass der Knoten mit dem Knotenverwaltungsendpunkt kommuniziert.

Wenn der DNS nicht ordnungsgemäß konfiguriert ist, können die Knoten möglicherweise nicht mit dem Batchdienstendpunkt kommunizieren. Diese Situation bewirkt, dass die Batchknoten in einem nicht verwendbaren Zustand hängen bleiben.

Notiz

Dieses Szenario richtet sich an Batchpools, die einen privaten Endpunkt für die Knotenverwaltung aktivieren. In der Regel haben diese Pools eine vereinfachte Knotenkommunikation und verwenden keine öffentlichen IP-Adressen.

Lösung 3: Beheben der DNS-Konfiguration

Überprüfen Sie, ob die DNS-Namensauflösung ordnungsgemäß funktioniert, und korrigieren Sie die DNS-Konfiguration bei Bedarf. Der richtige Prozess zur Überprüfung der DNS-Konfiguration hängt davon ab, ob Sie den privaten Knotenverwaltungsendpunkt mithilfe einer automatischen privaten DNS-Integration oder einer benutzerdefinierten DNS-Konfiguration erstellt haben.

Verfahren für die automatische private DNS-Integration

Überprüfen Sie, ob die automatische private DNS-Integration ordnungsgemäß konfiguriert ist, indem Sie die folgenden Schritte ausführen:

1. Stellen Sie sicher, dass der private Endpunkt in die private DNS-Zone privatelink.batch.azure.comintegriert ist.

   

2. Stellen Sie sicher, dass diese private DNS-Zone mit demselben oder peerierten VNet verknüpft ist, das der Batchpool verwendet.

   

Verfahren für die benutzerdefinierte DNS-Konfiguration

Überprüfen Sie, ob das benutzerdefinierte DNS ordnungsgemäß konfiguriert ist, und verweist auf die IP-Adresse des privaten Endpunkts, indem Sie die folgenden Schritte ausführen:

1. Suchen Sie im Azure-Portal nach Batchkonten, und wählen Sie sie aus.

2. Wählen Sie in der Liste der Batchkonten den Namen Ihres Batchkontos aus.

3. Suchen Sie auf der Seite "Übersicht" Ihres Batchkontos den Abschnitt "Essentials ", und kopieren Sie dann den Wert im Feld "Knotenverwaltungsendpunkt ". (Dieser Wert ist in der Regel eine URL mit dem folgenden Format: <guid>.<region>.service.batch.azure.com.)

   

4. Suchen Sie im Navigationsbereich des Batchkontos die Überschrift "Einstellungen", und wählen Sie dann "Netzwerk" aus. Wählen Sie auf der Seite "Netzwerk " die Registerkarte "Privater Zugriff " aus, und wählen Sie dann in der Liste der privaten Endpunkte für die Knotenverwaltung den privaten Endpunkt aus.

   

5. Suchen Sie im Navigationsbereich des privaten Endpunkts die Überschrift "Einstellungen", und wählen Sie dann die DNS-Konfiguration aus. Suchen Sie auf der Seite "DNS-Konfiguration" den Abschnitt "Customer Visible FQDNs", und kopieren Sie dann den Wert in der Spalte "IP-Adressen" für die Netzwerkschnittstelle Ihres privaten Knotenverwaltungsendpunkts.

   

6. Erstellen Sie einen Batchknoten oder einen virtuellen Computer (VM) innerhalb desselben Subnetzes, in dem der Pool erstellt wird. Stellen Sie dann eine Verbindung mit dem virtuellen Computer her, und öffnen Sie eine PowerShell-Konsole (in Windows) oder eine Shell-Konsole (unter Linux).

7. Testen Sie die DNS-Namensauflösung, indem Sie den folgenden nslookup-Befehl ausführen. (In Windows ist nslookup standardmäßig installiert. Installieren Sie unter Linux nslookup, oder verwenden Sie andere Tools.)

   nslookup <node-management-endpoint-url>
   

   Das erwartete Ergebnis entspricht der privaten IP-Adresse des privaten Knotenverwaltungsendpunkts:

   PS C:\Users\xxx> nslookup <node-management-endpoint-url>
   Server:  UnKnown
   Address:  x.x.x.x
   
   Name:     <node-management-endpoint-url>
   Address:  <private-ipnode-management-endpoint-private-ip>
   Aliases:  <node-management-endpoint-url>
   

8. Testen Sie die Verbindung mit der Knotenverwaltungsendpunkt-URL am Port 443. Führen Sie dazu das Cmdlet Test-NetConnection in Windows aus, oder führen Sie den Befehl Netcat (nc) unter Linux aus.

   Test-NetConnection -ComputerName <node-management-endpoint-url> -Port 443
   

   nc -v <node-management-endpoint-url> 443
   

   Das erwartete Ergebnis ist eine erfolgreiche Verbindung, wie in der folgenden Beispielausgabe gezeigt:

   PS C:\Users\xxx> Test-NetConnection -ComputerName <node-management-endpoint-url> -Port 443
   
   ComputerName     : <node-management-endpoint-url>
   RemoteAddress    : <private-ipnode-management-endpoint-private-ip>
   RemotePort       : 443
   InterfaceAlias   : Ethernet
   SourceAddress    : <vm-private-ip>
   TcpTestSucceeded : True
   

9. Wenn nach dem Ausprobieren der beiden vorherigen Schritte Probleme auftreten, wenden Sie die Anleitungen zur Problembehandlung in der folgenden Tabelle an.

   Problemszenario	Anleitungen zur Problembehandlung
   Das Ergebnis des Befehls "nslookup" ist nicht wie erwartet.	Überprüfen Sie die benutzerdefinierte DNS-Einstellung des VNet des Batchpools. Zu überprüfende Werte umfassen die folgenden Elemente: Der Name der privaten DNS-Zone Der benutzerdefinierte DNS-Server Alle anderen Dienste oder Komponenten, die sich auf die DNS-Namensauflösung auswirken können
   Das Ergebnis des Befehls "nslookup" wird erwartet, aber das Ergebnis des Test-NetConnection Cmdlets oder nc Befehls ist unerwartet.	Überprüfen Sie, ob ein Dienst vorhanden ist (z. B. Netzwerksicherheitsgruppe und Firewall), der die ausgehende Verbindung vom VNet blockieren kann.

Weitere Informationen finden Sie unter Problembehandlung für private Knotenverwaltungsendpunkte.

Problem 2: Vollständiges Problem des Datenträgers

Ein Knoten befindet sich im Zustand "Nicht verwendbar ", und die folgende Fehlermeldung wird auf dem Knoten angezeigt:

Code: DiskFull
Meldung:
Auf dem Knoten ist nicht genügend Speicherplatz vorhanden.
Werte:
Nachricht : Der VM-Datenträger ist voll. Löschen Sie Auftrag, Aufgaben oder Dateien auf dem Knoten, um Leerzeichen freizugeben, und starten Sie dann den Knoten neu.

Ursache: Nicht genügend Speicherplatz auf dem Knoten

Wenn ein Auftrag auf dem Knoten ausgeführt wird, kann jede Aufgabe im Auftrag Ausgabedaten erzeugen. Diese Ausgabedaten werden in das Dateisystem des Batchknotens geschrieben. Wenn diese Daten mehr als 90 Prozent Kapazität der Datenträgergröße der Knoten-SKU erreichen, kennzeichnet der Batchdienst den Knoten als unbrauchbar und blockiert die Ausführung anderer Aufgaben, bis der Batchdienst eine Bereinigung durchführt.

Der Batchknoten-Agent reserviert 10 Prozent Kapazität des Festplattenspeichers für seine Funktionalität. Bevor aufgaben je nach Kapazität des Batchknotens ausgeführt werden sollen, ist es wichtig, genügend Speicherplatz auf dem Datenträger zu behalten. Bewährte Methoden zum Ausführen der Aufgaben finden Sie unter "Aufgaben".

Lösung: Löschen von Dateien in Aufgabenordnern

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

1. Stellen Sie mithilfe von RDP eine Verbindung mit dem Knoten her.

2. Überprüfen Sie den auf dem Datenträger verfügbaren Speicherplatz.

   • Wenn nicht genügend Speicherplatz auf dem Datenträger vorhanden ist, fahren Sie mit Schritt 3 fort.

     Das folgende Beispiel zeigt, dass nicht genügend Speicherplatz auf dem Datenträger vorhanden ist. In diesem Beispiel ist die VM-SKU für Windows und Linux Standard_D2s_V3, und die Datenträgergröße beträgt 16 Gigabyte (GB).

     Für Windows zeigt der folgende Screenshot, dass auf dem Datenträger weniger als 1 GB Speicherplatz verfügbar ist.

     

     Notiz

     Für Windows können Sie auch Explorer verwenden, um den Speicherplatz zu überprüfen.

     Für Linux zeigt der folgende Screenshot, dass 100 Prozent des bereitgestellten Datenträgers verwendet werden.

     

     Aufgabenbezogene Dateien unter Linux befinden sich unter ./mnt/batch/tasks/workitems/.

   • Wenn genügend Speicherplatz für die auszuführenden Aufgaben verfügbar ist, der Knoten jedoch nicht verwendbar ist, hat der Batchdienst möglicherweise die Dateien basierend auf der Aufbewahrungsrichtlinie der Aufgabe bereinigt. Wechseln Sie in diesem Fall zu Schritt 4.

3. Navigieren Sie zu jedem Aufgabenordner, und löschen Sie die Dateien.

4. Nachdem die Dateien gelöscht wurden, starten Sie den Knoten neu.

   Nachdem der Knoten neu gestartet wurde, sollte sich der Knoten in einem fehlerfreien Zustand befinden und neue Aufgaben annehmen.

   

Problem 3: Problem mit der Konfiguration von benutzerdefinierten Bildern

Manchmal können benutzerdefinierte Bildkonfigurationsprobleme (z. B. falsche Vorbereitung) Knoten beschädigen. Benutzerdefinierte Bilder verwenden eine vielzahl von Variablen, die dazu führen können, dass Knoten nicht verwendet werden können.

Beispielsweise befindet sich ein Batchknoten im Zustand "Nicht verwendbar " oder "Start ", und der folgende Fehlercode wird auf dem Knoten angezeigt:

Code:
BatchAgentInstallationFailure
Meldung:
Fehler bei der Bereitstellung der Batch-Agent-Erweiterung auf dem Computeknoten

Ursache: Benutzerdefinierte Betriebssystem-SKU unterscheidet sich von der Betriebssystem-SKU, die während der Poolerstellung ausgewählt wurde.

Wenn Sie einen Azure Batch-Pool über die Azure-Portal erstellen und den Imagetyp auf "Benutzerdefiniertes Image – Freigegebene Bildgalerie" festlegen, führt die Azure-Portal die SKU-Überprüfung des Betriebssystems nicht aus. Wenn Sie eine Betriebssystem-SKU auswählen, die sich von der tatsächlichen Betriebssystem-SKU unterscheidet, die im benutzerdefinierten Image verwendet wird, installiert Azure Batch den Batchknoten-Agent, der der ausgewählten Betriebssystem-SKU entspricht, anstelle der tatsächlichen Betriebssystem-SKU, die im benutzerdefinierten Image verwendet wird.

Im folgenden Screenshot basiert das benutzerdefinierte Bild auf dem Ubuntu 20 Azure Marketplace-Image von Canonical. Wenn Sie die Betriebssystemsku festlegen, führt der Azure Batch die Überprüfung nicht aus.

Lösung: Erstellen Sie den Pool mit der SKU des benutzerdefinierten Imagebetriebssystems neu.

Um dieses Problem zu beheben, erstellen Sie den Pool erneut, um die Betriebssystem-SKU zu verwenden, die im benutzerdefinierten Image verwendet wird.

Weitere Informationen zum Erstellen eines benutzerdefinierten Bilds finden Sie in den folgenden Artikeln:

• Verwenden der Azure Compute Gallery zum Erstellen eines benutzerdefinierten Imagepools
• Entfernen sie computerspezifische Informationen, indem Sie einen virtuellen Computer generalisieren, bevor Sie ein Image erstellen.

Problem 4: Problem mit verwalteter Identitätskonfiguration

Wenn der Authentifizierungsmodus des verknüpften Azure Storage-Kontos (auch als automatisches Speicherkonto bezeichnet) auf "Verwaltete Batchkontoidentität " festgelegt ist (wie im folgenden Screenshot dargestellt), führt die falsche Konfiguration der Poolidentität dazu, dass Knoten nicht mehr verwendet werden können. Weitere Informationen finden Sie unter Verhaltensszenarien.

Ein Batchknoten befindet sich im Zustand "Nicht verwendbar ", und der folgende Fehlercode wird auf dem Knoten angezeigt:

Code: ApplicationPackageError
Meldung:
Mindestens ein für den Pool angegebenes Anwendungspaket ist ungültig.
Werte:
ApplicationPackageReference - asdf:0.0.1
Meldung – Fehler beim Herunterladen der Ressource

Ursache: Verwaltete Identität, die im Knotenidentitätsverweis definiert ist, wird nicht zur Poolidentität hinzugefügt.

Wenn Sie den Pool erstellen, können Sie mehrere verwaltete Identitäten angeben. Wenn die im Knotenidentitätsverweis definierte verwaltete Identität (konfiguriert im Autospeicherkonto) der Poolidentität nicht hinzugefügt wird, können Knoten nicht die richtige verwaltete Identität für die Authentifizierung verwenden. Dies führt dazu, dass der Downloadvorgang des Anwendungspakets fehlschlägt und der Knoten nicht mehr verwendet werden kann.

Lösung: Erstellen Sie den Pool erneut, um die verwaltete Identität zu korrigieren.

Um dieses Problem zu beheben, erstellen Sie den Pool erneut, um die richtige verwaltete Identität (konfiguriert im Autospeicherkonto) einzuschließen, die im Knotenidentitätsverweis definiert ist. Weitere Informationen zur Verwendung der vom Batchpool verwalteten Identität finden Sie unter Einrichten der verwalteten Identität in Ihrem Batchpool.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.