Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Der Fehler „no healthy upstream“ in vCenter tritt meist zu ungünstigen Zeitpunkten auf – häufig direkt nach einem Neustart oder während Wartungsarbeiten und fast immer zusammen mit einer 503‑Meldung „Service Unavailable“.
Im Kern bedeutet der Fehler, dass der Envoy‑Proxy keine Backend‑Dienste wie vpxd, vsphere‑ui oder vapi‑endpoint erreichen kann. Die Ursache liegt zumeist in zwei Bereichen: vollem Speicherplatz oder abgelaufenen Zertifikaten.
Dieser Leitfaden stellt fünf Fehlerbehebungsmethoden vor, um die Ursache zu ermitteln und Ihre vSphere‑Umgebung schnell wieder in Betrieb zu nehmen.
Im Folgenden die häufigsten technischen Ursachen für diesen vCenter‑Fehler.
Abgelaufene Zertifikate sind die häufigste Ursache für diesen Fehler. Innerhalb der VCSA sind zwei Zertifikate für die interne Kommunikation von zentraler Bedeutung:
Die VCSA‑Partitionen reagieren empfindlich auf Speichergrenzen. Erreicht eine Partition 100 % Auslastung, können Dienste keine Protokolle oder temporären Dateien mehr schreiben und stürzen umgehend ab. Die häufigsten Problemstellen sind:
/storage/log: Überlastet durch stark anwachsende Protokolldateien./storage/seat: Füllt sich mit Statistik‑ und Ereignisdaten und verursacht oft einen Ausfall des Dienstes vpxd.vsphere‑ui und vpxd)Der Begriff „Upstream“ bezeichnet die internen Dienste, die Ihre Anfragen verarbeiten. Wenn diese gestoppt oder hängig sind, hat der Proxy kein Ziel für den Datenverkehr:
vsphere‑ui: Der Web‑Konsolendienst zur Darstellung der Client‑Oberfläche.vpxd: Die zentrale vCenter‑Engine. Stürzt dieser aufgrund von Datenbankproblemen ab, ist die gesamte Verwaltungsebene nicht erreichbar. Wenn zentrale Dienste nicht starten, kann zudem das Problem auftreten, dass VMware keine Synchronisation mit dem Host durchführen kann. Dies deutet häufig auf tiefgreifende Probleme im Verwaltungsnetz oder auf eine beschädigte zugrundeliegende Datenbank hin.Die VCSA erfordert strikte RAM‑Reservierungen, insbesondere nach Aktualisierungen.
vCenter ist auf ein funktionierendes Domain‑Name‑System (DNS) angewiesen, um seine eigenen Endpunkte über den vollqualifizierten Domänennamen (FQDN) zu erkennen.
Sobald Sie die zugrundeliegenden Gründe für den vCenter‑Fehler „No Healthy Upstream“ verstanden haben, können Sie die Dienste systematisch wiederherstellen. Dieser Fehler bedeutet im Allgemeinen, dass der Envoy‑Proxy keinen funktionsfähigen Backend‑Dienst für die Weiterleitung Ihrer Anfragen findet.
Unabhängig davon, ob der Fehler nach einem Neustart oder im regulären Betrieb auftritt, helfen Ihnen diese technischen Schritte, den Ausfall zu identifizieren und zu beheben.
Bevor Sie Konfigurationen ändern, stellen Sie sicher, dass die VCSA ausreichend Speicherplatz für ihre Prozesse hat. Ein voller Datenträger ist eine Hauptursache für fehlgeschlagene Dienstinitialisierungen.
df -h
Wonach Sie suchen sollten: Prüfen Sie die Ausgabe auf Partitionen mit 100 % Auslastung. In VCSA‑Umgebungen sind /storage/log und /storage/core die häufigsten Problemstellen.
Die Lösung: Ist /storage/log voll, müssen Sie ggf. alte komprimierte Protokolldateien manuell löschen. Reicht die zugewiesene Speicherkapazität nicht mehr aus, erweitern Sie die virtuelle Festplatte in den ESXi‑Einstellungen. Führen Sie anschließend folgenden Befehl aus, um eine interne Größenanpassung und eine Aktualisierung der Dienste auszulösen:
service-control --stop --all && service-control --start --all
Abgelaufene Zertifikate sind eine der wichtigsten technischen Fehlerursachen für die vCenter‑Meldung „No Healthy Upstream“. Sind die zugrundeliegenden STS‑ oder Machine‑SSL‑Zertifikate ungültig, können die Dienste sich nicht gegenseitig authentifizieren.
Erstellen Sie vor einem Zertifikats‑Reset immer eine dateibasierte Sicherung oder einen VM‑Snapshot. Für eine sicherere und effizientere Sicherungslösung empfehlen sich Lösungen wie i2Backup.
Führen Sie diesen Befehl aus, um die Ablaufdaten aller VCSA‑Speicher zu prüfen:
for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo "STORE: $i"; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | grep -ie "Not After"; done
Die Lösung: Werden abgelaufene Zertifikate angezeigt, starten Sie das VMware‑Zertifikats‑Manager‑Werkzeug:
/usr/lib/vmware-vmca/bin/certificate-manager
In den meisten Fällen von „No Healthy Upstream“ aufgrund eines vollständigen Zertifikatsausfalls ist Option 8 (Alle Zertifikate zurücksetzen) die effektivste Maßnahme für eine vollständige Wiederherstellung.
Sind die Datenträger ausreichend und die Zertifikate gültig, kann es sein, dass die sogenannten Upstream‑Dienste gestoppt oder abgestürzt sind.
Um festzustellen, welcher Dienst fehlerhaft ist:
service-control --status --all
Wonach Sie suchen sollten: Prüfen Sie, ob sich vsphere‑ui (der HTML5‑Client) oder vpxd (der zentrale vCenter‑Dienst) im Status „Stopped“ befindet.
Die Lösung: Sind kritische Dienste gestoppt, versuchen Sie einen sauberen manuellen Neustart des gesamten Dienststapels:
service-control --stop --all
service-control --start --all
vSphere‑Dienste hängen stark von korrekter Zeit‑ und Namensauflösung ab. Kann die VCSA sich selbst nicht auflösen oder weicht die Systemuhr ab, werden Token abgelehnt.
nslookup <vcenter‑fqdn>
date
Die Lösung: Weicht die Uhrzeit um mehr als wenige Minuten ab, lehnt der Security‑Token‑Dienst Authentifizierungsanfragen ab und löst damit den Upstream‑Fehler aus. Korrigieren Sie die Uhrzeit über die vCenter‑Management‑Schnittstelle (VAMI) oder den Befehl date und stellen Sie sicher, dass die NTP‑Synchronisation funktioniert.
Zeigt service‑control an, dass die Dienste laufen, der Fehler „no healthy upstream“ aber weiterhin besteht, liegt das Problem wahrscheinlich in der Java‑Laufzeitumgebung des vSphere‑Clients. Wenn ein Dienst startet, aber nicht vollständig initialisiert wird, finden Sie Hinweise in den Wrapper‑Protokollen.
Öffnen Sie die Shell und geben Sie die letzten 100 Zeilen des vSphere‑Client‑Protokolls aus:
tail -n 100 /var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log
Wonach Sie suchen sollten:
lang.OutOfMemoryError: Bestätigt, dass der VCSA nicht genügend physischen RAM für den Java‑Heap der Oberflächendienste zugewiesen hat. Dies tritt häufig nach einem vCenter‑Upgrade und anschließendem Neustart auf.lang.NullPointerException: Deutet oft auf beschädigte Plugins oder Kommunikationsfehler zum Lookup‑Dienst hin.Die Lösung: Bei einem OutOfMemoryError schalten Sie die VCSA aus und erhöhen die zugewiesene Arbeitsspeichermenge in den vSphere‑Einstellungen.
Bei pluginbezogenen Ausnahmen müssen Sie ggf. die Serenity‑Datenbank leeren oder veraltete Erweiterungen über den Managed‑Object‑Browser (MOB) abmelden.
F1: Warum wird „no healthy upstream“ auch nach einem Neustart der Dienste weiterhin angezeigt?
A: Höchstwahrscheinlich wurde die eigentliche Ursache (abgelaufene Zertifikate, zu wenig RAM oder DNS‑Probleme) nicht behoben. Prüfen Sie die Protokolle oder führen Sie die kurzen Diagnosebefehle aus, um den Fehler zu finden.
F2: Kann ich den Fehler „no healthy upstream“ ohne SSH‑Zugriff beheben?
A: Ja. Nutzen Sie die ESXi‑DCUI‑Schnittstelle, um auf die VCSA‑Shell zuzugreifen, oder verwenden Sie die VAMI‑Schnittstelle zur Korrektur von Zeit‑ und DNS‑Einstellungen. Für Zertifikats‑Resets ist SSH zwar einfacher, aber nicht zwingend erforderlich.
F3: Ist die Verwendung eines VM‑Snapshots zur Fehlerbehebung sicher?
A: Ein Snapshot‑Rollback kann eine vorübergehende Lösung darstellen, ist aber langfristig nicht empfehlenswert. Erstellen Sie vor einem Rollback immer eine dateibasierte Sicherung und beheben Sie anschließend die eigentliche Ursache, beispielsweise abgelaufene Zertifikate.
F4: Warum zeigt df -h ausreichenden Speicher an, der Fehler tritt aber trotzdem auf?
A: Die Ursache liegt wahrscheinlich bei DNS‑, Zeitsynchronisations‑ oder Dienst‑Deadlock‑Problemen. Prüfen Sie zuerst die DNS‑Auflösung und die Systemzeit, anschließend starten Sie alle Dienste neu.
F5: Wie überprüfe ich, ob der Envoy‑Proxy in vCenter 8.0 läuft?
A: Führen Sie den Befehl aus: service-control --status envoyproxy. Ist er gestoppt, starten Sie ihn mit service-control --start envoyproxy.
F6: Muss ich vCenter nach einer Zertifikatskorrektur neu starten?
A: Ja. Nach dem Zurücksetzen der Zertifikate starten Sie alle Dienste mit service-control --stop --all && service-control --start --all, damit die Änderungen wirksam werden.
F7: Warum tritt der Fehler nur nach einem vCenter‑Upgrade auf?
A: Upgrades erhöhen oft die RAM‑Anforderungen oder erneuern Zertifikate nicht automatisch. Prüfen Sie zuerst die RAM‑Zuweisung und die Ablaufdaten der Zertifikate.
F8: Können Plugin‑Probleme den Fehler „no healthy upstream“ verursachen?
A: Ja. Beschädigte oder veraltete Plugins können den Dienst vsphere‑ui zum Absturz bringen. Prüfen Sie die Oberflächenprotokolle auf NullPointerException und melden Sie veraltete Plugins ab.
F9: Welcher Mindest‑RAM‑Wert für vCenter 8.0 vermeidet diesen Fehler?
A: Empfohlen werden 16 GB RAM. 12 GB stellen das absolute Minimum dar, führen aber häufiger zum OOM‑Killer‑Ereignis und zum Fehler „no healthy upstream“.
F10: Wie lange soll ich nach einem vCenter‑Neustart warten, bevor ich mit der Fehleranalyse beginne?
A: Warten Sie 10‑20 Minuten. Die Dienste benötigen insbesondere nach Neustart oder Upgrade Zeit für den vollständigen Start. Tritt der Fehler auch nach 20 Minuten auf, beginnen Sie mit der Fehlersuche.
Der vCenter‑Fehler „no healthy upstream“ ist im Grunde ein Hinweis darauf, dass die zentralen VCSA‑Dienste nicht miteinander kommunizieren können. Die 503‑Meldung ist eine generische Antwort des Reverse‑Proxys. Die systematische Arbeit über die Kommandozeile macht es einfach, die eigentliche Ursache – abgelaufene Zertifikate, voller Speicherplatz oder abgestürzte Dienste – zu finden.
Bei der Behebung des Fehlers prüfen Sie zuerst die STS‑Zertifikate und den Zustand der Partitionen. Durch ausreichende Ressourcenreserven und die Überwachung von Dienstprotokollen lassen sich Vorfälle wie „no healthy upstream“ nach Neustarts vermeiden und die Stabilität Ihrer vSphere‑Umgebung sicherstellen. Erstellen Sie vor umfangreichen Zertifikats‑ oder Dienstkorrekturen stets eine dateibasierte Sicherung oder einen VM‑Snapshot.
