14
Server 2019 - VM (DC) hängt sporadisch
Hallo liebe Kolleginnen und Kollegen,
ich habe mal wieder eine Frage zu einem Problem:
Eine VM (DC) bleibt im Betrieb sporadisch "hängen". Das äußert sich folgendermaßen: Der HyperV Manager zeigt eine konstante Auslastung von 37%/38% an. Klickt man auf StgAltEntf kommt entweder gar kein Anmeldebildschirm (schwarzes Fenster) oder nur der Sperrbildschirm (ohne Login) - das dauert aber. Es kommt auch ab und zu die Meldung: Takt unterbrochen. Remoteverbindung ist auch nicht mehr möglich. Die Clients können sich nicht mehr anmelden - eine Netzwerkordner, welcher über den Server läuft ist auch nicht erreichbar. Die VM läuft seit einem halben Jahr eigentlich ohne Probleme. Seit dem 2.1.2021 häufen sich diese aber. Gestern und heut 2 mal hintereinander. Nur ein harter Reset der Machine hilft ihr wieder auf die Beine - Geschwindigkeit ist superschnell - so auch keine negativen Auffälligkeiten.
Meine Umgebung:
Hyper V - Server 2019
3 VM - DC, WSUS und ERP Server
Dual Xeon Silver Prozessoren, Genügend RAM, NVMe SSD RAID 10
Die betreffende VM ist der DC, DNS, DHCP Server. Ebenso läuft noch Acronis CyberCloud und der ESET File Security drauf. Darüberhinaus noch als ESET Verwaltungsserver für die Agents.
Meine Diagnose:
Eventlog der VM und des HyperV Host soweit unspektakulär - nichts, was auf ein größeres Problem hindeutet
Hardware soweit ohne Auffälligkeiten
SFC ohne Befund
DISM ohne Befund
Vermutung:
Ich hatte letztens immer mal wieder Probleme mit dem Backup, was jedoch auf die Größe und Anzahl der Daten zu tun hatte (durch Ausschlüsse hatte ich das aber wieder im Griff) Es waren auch immer Probleme mit den Backups wenn der Server einfror - Frage halt: läßt das Backup den Server abschmieren oder umgekehrt... Habe heute mal die Backups soweit deaktiviert. Evtl hat das ja aber auch nichts damit zu tun.
Ebenso war kurz vor dem Auftauchen der Probleme ein ESET Upgrade (ESET Protect + File Security) - FS wurde auf allen VM's installiert - ohne Probleme.
Meine Frage:
Kann ich irgendwie nachträglich rausfinden, welches Programm die Last auf der VM verursacht?
Hatte jemand schon ein ähnliches Problem?
Vielen dank schonmal für euere Antworten bzw Fragen
ich habe mal wieder eine Frage zu einem Problem:
Eine VM (DC) bleibt im Betrieb sporadisch "hängen". Das äußert sich folgendermaßen: Der HyperV Manager zeigt eine konstante Auslastung von 37%/38% an. Klickt man auf StgAltEntf kommt entweder gar kein Anmeldebildschirm (schwarzes Fenster) oder nur der Sperrbildschirm (ohne Login) - das dauert aber. Es kommt auch ab und zu die Meldung: Takt unterbrochen. Remoteverbindung ist auch nicht mehr möglich. Die Clients können sich nicht mehr anmelden - eine Netzwerkordner, welcher über den Server läuft ist auch nicht erreichbar. Die VM läuft seit einem halben Jahr eigentlich ohne Probleme. Seit dem 2.1.2021 häufen sich diese aber. Gestern und heut 2 mal hintereinander. Nur ein harter Reset der Machine hilft ihr wieder auf die Beine - Geschwindigkeit ist superschnell - so auch keine negativen Auffälligkeiten.
Meine Umgebung:
Hyper V - Server 2019
3 VM - DC, WSUS und ERP Server
Dual Xeon Silver Prozessoren, Genügend RAM, NVMe SSD RAID 10
Die betreffende VM ist der DC, DNS, DHCP Server. Ebenso läuft noch Acronis CyberCloud und der ESET File Security drauf. Darüberhinaus noch als ESET Verwaltungsserver für die Agents.
Meine Diagnose:
Eventlog der VM und des HyperV Host soweit unspektakulär - nichts, was auf ein größeres Problem hindeutet
Hardware soweit ohne Auffälligkeiten
SFC ohne Befund
DISM ohne Befund
Vermutung:
Ich hatte letztens immer mal wieder Probleme mit dem Backup, was jedoch auf die Größe und Anzahl der Daten zu tun hatte (durch Ausschlüsse hatte ich das aber wieder im Griff) Es waren auch immer Probleme mit den Backups wenn der Server einfror - Frage halt: läßt das Backup den Server abschmieren oder umgekehrt... Habe heute mal die Backups soweit deaktiviert. Evtl hat das ja aber auch nichts damit zu tun.
Ebenso war kurz vor dem Auftauchen der Probleme ein ESET Upgrade (ESET Protect + File Security) - FS wurde auf allen VM's installiert - ohne Probleme.
Meine Frage:
Kann ich irgendwie nachträglich rausfinden, welches Programm die Last auf der VM verursacht?
Hatte jemand schon ein ähnliches Problem?
Vielen dank schonmal für euere Antworten bzw Fragen
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 640998
Url: https://administrator.de/contentid/640998
Ausgedruckt am: 18.11.2024 um 17:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
konkret kann ich dir nicht helfen, hatte jüngst aber selbiges Phänomen mit einem jungfräulichen Server 2019, direkt auf Blech installiert.
Sobald ich die ISO des WSUSOffline gemountet habe, hat es keine 2 Minuten gedauert und die Kiste ist im Blackscreen festgefahren.
Nur ein harter Shutdown hat geholfen.
Schlussendlich habe ich dann die Updates in die Installations-ISO des Servers integriert und noch einmal von vorn begonnen - bei einer frischen Installation wahrlich kein Problem. Seit dem ist Ruhe.
Zu deinem Problem oben:
ICH würde die ESET-Tools vom DC runter nehmen.
Und da du ja drei VMs hast: Pack das Gelump auf den WSUS-Server mit drauf. Da passt es thematisch auch eher hin, meiner Meinung nach.
konkret kann ich dir nicht helfen, hatte jüngst aber selbiges Phänomen mit einem jungfräulichen Server 2019, direkt auf Blech installiert.
Sobald ich die ISO des WSUSOffline gemountet habe, hat es keine 2 Minuten gedauert und die Kiste ist im Blackscreen festgefahren.
Nur ein harter Shutdown hat geholfen.
Schlussendlich habe ich dann die Updates in die Installations-ISO des Servers integriert und noch einmal von vorn begonnen - bei einer frischen Installation wahrlich kein Problem. Seit dem ist Ruhe.
Zu deinem Problem oben:
ICH würde die ESET-Tools vom DC runter nehmen.
Und da du ja drei VMs hast: Pack das Gelump auf den WSUS-Server mit drauf. Da passt es thematisch auch eher hin, meiner Meinung nach.
Kann ich irgendwie nachträglich rausfinden, welches Programm die Last auf der VM verursacht?
Nachträglich dürfte schwierig werden.... Mir ist zumindest kein Weg bekannt. ggf. mal die Logs der einzelnen DIenste sichten, ob da irgendwelche Probleme entstanden sind. Und ich meine nicht nur das Eventlog, sondern ggf. gibt es Log-Files im Installationsverzeichnis...
Moin,
Ein DC ist ein DC ist ein ...
LG, Thomas
eine Netzwerkordner, welcher über den Server läuft ist auch nicht erreichbar
Probleme mit dem Backup, was jedoch auf die Größe und Anzahl der Daten zu tun hatte
Ein DC ist ein DC ist ein ...
LG, Thomas
Ein DC ist ein DC - ja da hast du Recht.
Das ist ein kleiner Folder, nur für Verwaltungszwecke, insgesamt 300MB
Zur Info: Über die Acronis Cyber Cloud sichere ich über den Agent des DC einen großen Netzwerkordner, welcher auf einer NAS liegt, weg
Das ist ein kleiner Folder, nur für Verwaltungszwecke, insgesamt 300MB
Zitat von @keine-ahnung:
Probleme mit dem Backup, was jedoch auf die Größe und Anzahl der Daten zu tun hatte
Zur Info: Über die Acronis Cyber Cloud sichere ich über den Agent des DC einen großen Netzwerkordner, welcher auf einer NAS liegt, weg
Zitat von @em-pie:
Zu deinem Problem oben:
ICH würde die ESET-Tools vom DC runter nehmen.
Und da du ja drei VMs hast: Pack das Gelump auf den WSUS-Server mit drauf. Da passt es thematisch auch eher hin, meiner Meinung nach.
Hab' ich schon auf meine To-Do geschrieben... Zu deinem Problem oben:
ICH würde die ESET-Tools vom DC runter nehmen.
Und da du ja drei VMs hast: Pack das Gelump auf den WSUS-Server mit drauf. Da passt es thematisch auch eher hin, meiner Meinung nach.
Moin.
ESET File Security würde ich, sofern es nicht per Richtlinie Gott weiß wie verbogen wurde, als Fehlerquelle ausschließen. Läuft zumindest in all unseren Umgebungen völlig stressfrei.
Anders sieht es mit ESET Protect aus. Zumindest der Vorgänger ESMC ist seitens des Herstellers nicht für die Installation auf einem DC vorgesehen. Da ESET Protect ja keine Neuentwicklung ist, sondern eigentlich nur ein umbenannten ESMC und halt jetzt in Version 8, würde ich hier -unabhänig vom Mantra: Ein DC ist ein DC ist ein DC- auf identische Voraussetzungen tippen. Kurz gesagt: Migrier' mal dein ESET Protect weg vom DC.
Und wenn du bereits in der Vergangenheit ein Problem mit dem Backup hattest würd' ich da auch nochmal ein wenig Zeit investieren.
Was mit bei deiner Beschreibung fehlt, sind die Eckdaten der VM - nutzt wenig, wenn die der Host ne Rakete ist, man beim Erstellen der VM aber vergessen hat, selbiger auch mehr als eine vCPU zu spendieren (um mal ein blödes Beispiel zu nennen, das aber leider in der Praxis immer wieder vorkommt).
Cheers,
jsysde
ESET File Security würde ich, sofern es nicht per Richtlinie Gott weiß wie verbogen wurde, als Fehlerquelle ausschließen. Läuft zumindest in all unseren Umgebungen völlig stressfrei.
Anders sieht es mit ESET Protect aus. Zumindest der Vorgänger ESMC ist seitens des Herstellers nicht für die Installation auf einem DC vorgesehen. Da ESET Protect ja keine Neuentwicklung ist, sondern eigentlich nur ein umbenannten ESMC und halt jetzt in Version 8, würde ich hier -unabhänig vom Mantra: Ein DC ist ein DC ist ein DC- auf identische Voraussetzungen tippen. Kurz gesagt: Migrier' mal dein ESET Protect weg vom DC.
Und wenn du bereits in der Vergangenheit ein Problem mit dem Backup hattest würd' ich da auch nochmal ein wenig Zeit investieren.
Was mit bei deiner Beschreibung fehlt, sind die Eckdaten der VM - nutzt wenig, wenn die der Host ne Rakete ist, man beim Erstellen der VM aber vergessen hat, selbiger auch mehr als eine vCPU zu spendieren (um mal ein blödes Beispiel zu nennen, das aber leider in der Praxis immer wieder vorkommt).
Cheers,
jsysde
Es gibt neue Info's zu meinem Problem. Backup ist es schon mal nicht.
Heute ist wieder das Problem aufgetaucht - VM eingefroren - hab mir nochmal die Log angeschaut:
Hab da einige ESENT Warnings gefunden: ID 508, 510 und 533 (die sind auch schon vorher da gewesen, habs aber mit was anderem verwechselt und deswegen ignoriert - sorry)
Diese deuten alle auf ein Hardwareproblem hin - die anderen VM's laufen aber normal.
Wie schon gesagt, SFC, DISM und chkdsk finden keine Fehler - Dies Systemperformace ist normal - die SSD's unauffällig und der Hardware Raid Controller meldet sich als optimal.
Jemand noch eine Idee?
P.S. die VM hat 48GB RAM, und 16vCPU's - nur zur Info
Heute ist wieder das Problem aufgetaucht - VM eingefroren - hab mir nochmal die Log angeschaut:
Hab da einige ESENT Warnings gefunden: ID 508, 510 und 533 (die sind auch schon vorher da gewesen, habs aber mit was anderem verwechselt und deswegen ignoriert - sorry)
Diese deuten alle auf ein Hardwareproblem hin - die anderen VM's laufen aber normal.
Wie schon gesagt, SFC, DISM und chkdsk finden keine Fehler - Dies Systemperformace ist normal - die SSD's unauffällig und der Hardware Raid Controller meldet sich als optimal.
Jemand noch eine Idee?
P.S. die VM hat 48GB RAM, und 16vCPU's - nur zur Info
Moin.
Naja... Ich würde jetzt mal alles, was nix auf nem DC zu suchen hat, weg migrieren.
Dann einen zweiten DC aufsetzen, FSMO und sonstige Funktionen verschieben, dann den Problem-DC demoten und abschalten.
Das wäre der pragmatische Ansatz, um es schnell wieder ans Laufen zu bekommen.
Der nicht so pragmatische Ansatz wäre, weitere Stunden und Tage mit der Fehlersuche zu verbringen, um dann doch den pragmatischen Ansatz zu wählen.
Cheers,
jsysde
Naja... Ich würde jetzt mal alles, was nix auf nem DC zu suchen hat, weg migrieren.
Dann einen zweiten DC aufsetzen, FSMO und sonstige Funktionen verschieben, dann den Problem-DC demoten und abschalten.
Das wäre der pragmatische Ansatz, um es schnell wieder ans Laufen zu bekommen.
Der nicht so pragmatische Ansatz wäre, weitere Stunden und Tage mit der Fehlersuche zu verbringen, um dann doch den pragmatischen Ansatz zu wählen.
Cheers,
jsysde
Also die 16vCPUs für einen DC in deiner Größe halte ich für übertrieben.
Was ist das für ein Server? Wie viele Kerne und Sockel hat der?
Nicht, dass du die CPU überbucht hast.
Wenn im Server CPU mit 16 Kernen steckt, hast du dein Dilemma schon - theoretisch.
16 physische Kerne verfügbar
DC hat 16 vCPUs, dein WSUS auch noch mal etwas und das ERP will sicherlich auch etwas vom Kuchen abhaben.
Du willst eine Kiste Bier (24 Flaschen) auf 48 Gäste aufteilen: Irgendwer hat dann das nachsehen.
Mein Vorschlag als erstes wäre:
Wenn das nicht hilft, dann wie @jsysde schon schrieb:
du musst im Vorfeld nur den File-Server noch wegmigrieren. aber da du ja bereits 3 VMs auf dem HyperV laufen hast, dürfte noch eine Lizenz für eine vierte VM frei sein. Dort würde ich die Daten ablegen lassen...
Was ist das für ein Server? Wie viele Kerne und Sockel hat der?
Nicht, dass du die CPU überbucht hast.
Wenn im Server CPU mit 16 Kernen steckt, hast du dein Dilemma schon - theoretisch.
16 physische Kerne verfügbar
DC hat 16 vCPUs, dein WSUS auch noch mal etwas und das ERP will sicherlich auch etwas vom Kuchen abhaben.
Du willst eine Kiste Bier (24 Flaschen) auf 48 Gäste aufteilen: Irgendwer hat dann das nachsehen.
Mein Vorschlag als erstes wäre:
- ESET auf den WSUS-Server migrieren
- dem DC weniger vCPUs geben (4 reichen sicherlich)
Wenn das nicht hilft, dann wie @jsysde schon schrieb:
- Zweiten DC aufsetzen
- Alles syncen lassen
- FSMO-Rollen verschieben
- abwarten
- defekten DC herunter fahren
- alles beobachten
- DC demoten
du musst im Vorfeld nur den File-Server noch wegmigrieren. aber da du ja bereits 3 VMs auf dem HyperV laufen hast, dürfte noch eine Lizenz für eine vierte VM frei sein. Dort würde ich die Daten ablegen lassen...
1
Den ESET Protect migriere ich gerade auf den WSUS.
Ansonsten hilt wohl nur
Danke schonmal
Ansonsten hilt wohl nur
Dann einen zweiten DC aufsetzen, FSMO und sonstige Funktionen verschieben, dann den Problem-DC demoten und abschalten.
Ich würd' halt gern den Fehler finden, aber Kosten/Nutzen geht vorDanke schonmal
Mahlzeit.
Valider Punkt.
Leider auch ein Fehler, den man häufiger sieht - kam mir nicht in den Sinn bei meiner Antwort, hatte wohl zu wenig Kaffee...
Cheers,
jsysde
Valider Punkt.
Leider auch ein Fehler, den man häufiger sieht - kam mir nicht in den Sinn bei meiner Antwort, hatte wohl zu wenig Kaffee...
Cheers,
jsysde
Zitat von @em-pie:
Also die 16vCPUs für einen DC in deiner Größe halte ich für übertrieben.
Was ist das für ein Server? Wie viele Kerne und Sockel hat der?
Nicht, dass du die CPU überbucht hast.
Ich habe hier 2x Intel Xeon Silver: mit 2x10 "echten" Cores, ergibt 40 mit HTAlso die 16vCPUs für einen DC in deiner Größe halte ich für übertrieben.
Was ist das für ein Server? Wie viele Kerne und Sockel hat der?
Nicht, dass du die CPU überbucht hast.
DC hat 16
ERP hat 8
WSUS hat 4
Sollte doch reichen oder findet ihr, dass er überbucht ist?
BTW, die Maschine lief ein halbes Jahr ohne Probleme in dieser Konfig.
Mahlzeit.
Passt.
Cheers,
jsysde
Passt.
DC hat 16
ERP hat 8
WSUS hat 4
Finde die Zuordnung eigenartig, aber überbucht ist hier nix.ERP hat 8
WSUS hat 4
Cheers,
jsysde
Finde die Zuordnung eigenartig, aber überbucht ist hier nix.
Da hast du Recht - eigentlich soll der ERP die 16 haben und der DC 8 - hatte ich vergessen umzustellen
Also, bin noch eine Lösung schuldig.
Problem war im Grunde der SQL 2014 auf dem DC - genauer gesagt die Backup Funktion des SQL. Sobald der SQL deaktiviert wurde, läuft die VM wieder stabil, aktiviert man ihn wieder, schmiert die VM beim auslösen des SQL Backups reproduzierbar ab.
Als Konsequenz den Eset Protect auf eine andere VM umgezogen und Ruhe war wieder eingekehrt.
Vielen Dank an alle Beitragenden!
Problem war im Grunde der SQL 2014 auf dem DC - genauer gesagt die Backup Funktion des SQL. Sobald der SQL deaktiviert wurde, läuft die VM wieder stabil, aktiviert man ihn wieder, schmiert die VM beim auslösen des SQL Backups reproduzierbar ab.
Als Konsequenz den Eset Protect auf eine andere VM umgezogen und Ruhe war wieder eingekehrt.
Vielen Dank an alle Beitragenden!
