RD Farm meldet sich nach und nach ab

[illumina7 3]

Guten Morgen,

ich bin mit meiner Server 2019 RDSH-Farm langsam echt am Ende mit den Nerven, ständig ist irgendetwas anderes.

Jetzt hab ich ein ganz spannendes Phänomen:

- die RDSH melden sich nach ein paar Tagen Laufzeit irgendwann plötzlich nicht mehr beim Verbindungsbroker, aber nicht gleichzeitig sondern einer nach dem anderen

- wenn das passiert werden alle bestehenden Verbindungen getrennt und die User, die gerade auf einem "getrennten" RDSH eingeloggt waren kommen nicht mehr in ihre Sitzungen

- auch mit mstsc /admin kann ich mich nicht mehr an einem getrennten Server anmelden (kommt ein Timeout, nicht erreichbar), Ping ist aber möglich

- selbst über den Hyper-V Manager kann ich mich häufig weder mit dem lokalen noch Domainadmin anmelden, manchmal klappt es mit dem Lokalen

- falls der Login klappt, kann ich zwar von betroffenem Server noch auf SMB Shares zugreifen und Pingen im Netzwerk ist noch möglich, aber z.B. kann keine Website mehr aufgerufen werden

- rebooten ist nicht möglich, ein aufgehängter RDSH bleibt bei "Wird neugestartet" stehen und da passiert nichts mehr, also die VM hängt sich auch komplett auf

- nach dem Reboot meldet sich ein aufgehängter Server nicht mehr beim Sessionbroker, erst wenn ich den Broker durchgestartet hab, werden die Server wieder erreichbar (die Sitzungssammlungen verschwinden nach und nach, bis im Servermanager nur noch dort steht "Verbindung zum RD-Verbindungsbroker wird hergestellt..."

- in der Regel fängt der 4. Terminalserver mit den Problemen an, dann gehts weiter mit dem 3. in der Reihenfolgen, dann der 2., der 1. Terminalserver war noch nie davon betroffen, der geht aber dann in die Knie wenn der als letzter verbleibender Server in der Farm alle Sitzungen annimmt (derzeit auf 30 pro RDSH limitiert, sollte aber eigentlich nie erreicht werden)

- ich muss also alle paar Tage RDSH 2-4 und Broker rebooten, weil sonst kein Arbeiten mehr möglich ist

- alle RDSH sind einzeln installiert (nicht geklont) und auf dem gleichen, aktuellen Patchstand, Software ist auch auf allen identisch (auch die gleichen Installer verwendet, automatische Updates bei allen Software Paketen deaktiviert)

wir nutzen Windows Defender, einzelne Netzwerkressourcen sind per GPO als Ausnahme eingestellt (u.a. der UPD UNC Pfad)

- auf Malware hatte ich die RDSH erst komplett geprüft - nichts gefunden

- sfc /scannow sagt alles in Ordnung

- Dauerping über Nacht unauffällig (0% Paketverlust auf den RDSH)

 

Die Logs sind nicht aufschlussreich, absolut nichts hilfreiches, viele DCOM Errors und wenn ein RDSH sich aufgehängt hat, sind die UPD nicht mehr erreichbar (NTFS-Errors im Sekundentakt), sonst nichts Spannendes.

 

Könnte vlt. Veeam den Fehler beim Sichern verursachen? Mir ist heute aufgefallen, dass noch etliche Veeam Checkpoints auf den VMs nicht entfernt worden sind. Theoretisch könnte ich die RDSH-Farm aus der laufenden Sicherung rausnehmen, da dort auch keine Daten gespeichert sind, kann ich im Worstcase auch eine ältere Sicherung zurückspielen.

 

Jemand vielleicht eine Idee was da los sein könnte?

 

[Weingeist 157]

NTFS-Errors klingen gerne mal nach sterbendem Storage oder Storage mit zu hoher Latenz z.B. aufgrund eines Rebuilds oder schlichtweg überfordertem Storage aufgrund Sicherung etc. was dann die VM in Bedrängnis bringt.

Abhilfe: Storage Checken, eventuell Disk-Timeout innerhalb der VM erhöhen.

 

Allgemeines aufhängen nach Zeit ist auch gerne mal ein Fehler mit dem Arbeitsspeicher. Also entweder eine Software welche sich nicht sauber entlädt und so irgendwann in die Kiste in die Knie zwingt oder aber ein defekter Riegel. Abhilfe: Z.Bsp. mal auf nen anderen Host schieben sofern möglich und beobachten ob die Probleme identisch bleiben.

 

Ansonsten wenn Du keine NTFS Error auf den Servern selbst hast sondern nur auf den Broker und die nicht direkt nach dem durchstarten sondern mit starker Verzögerung kommen, kannst auch testweise einfach mal jede Nacht durchstarten lassen, sofern das Arbeitsfenster diese zulässt.

bearbeitet 25. Januar 2022 von Weingeist

[illumina7 3]

Storage ist top, Raid 10 aus Intel Server SSDs, arbeitet mit 8GB/s r/w und extrem geringer Latenz (<0,1ms per AS SSD Benchmark). Die NTFS Errors der UPD treten auf, weil diese nicht mehr erreichbar sind, vorher nicht, auch eine lokale Anmeldung ist dann nicht mehr möglich.

 

Das nächtliche Rebooten werde ich jetzt aktivieren, aber das ist kein dauerhafter Workaround, ich möchte lieber die Ursache finden als nur die Symptome zu erwürgen.

[Weingeist 157]

Für die Ursachenfindung bleibt Dir nichts anderes übrig als Systematisch zu analyisieren bevor sie sich weghängt. Und/Oder erweitertes logging usw.

Arbeitsspeicherauslastung prüfen ob der Kram jeweils freigegeben wird oder nicht usw. Da gibts so viel Möglichkeiten was schief laufen kann... Netz durchforsten mit den ersten Events die geworfen werden usw.

[illumina7 3]

Also ich lese jetzt seit heute Morgen um 7 Uhr Logs an zwei RDSH und suche Gemeinsamkeiten und Unterschiede sowie aussagekräftige Meldungen, leider wirklich komplett erfolglos bis jetzt. Windows typisch gibt es halt jede Menge Fehlermeldungen, gerade auch, weil da ja User drauf arbeiten.

 

Einen Verdacht habe ich nicht, evtl. könnte das NIC Teaming unter Windows Probleme mit Verbindungen verursachen, bin mir auch relativ sicher, dass die jetzige Problematik erst aufgetreten ist, nachdem ich das NIC Teaming am Hyper-V Host kurz vor Weihnachten wieder eingeschalten hatte. Das ist zwar switchunabhängig konfiguriert, allerdings habe ich in der Vergangenheit schon das ein oder andere Problem damit gehabt. Irgendwie wirkt es halt so, als wäre es ein Netzwerkproblem. Storage ist wirklich unauffällig und auch der Adaptec Manager meldet alles iO.

[StefanA 0]

Moin Illumina7,

 

hast Du eine Lösung gefunden?

Ich habe die gleichen Probleme.

 

Gruß Stefan

[Weingeist 157]

Hui, da war mal eine Antwort...

 

Wie gesagt, da geht nur systematisches Vorgehen. Wenn Du Dinge an der Umgebung geändert hast mach sie als erstes rückängig. Wenn Du das Gefühl hast, es ist seit dem aktiven Teaming, hebe es doch einfach wieder auf und teste es

 

Teaming kenne ich mich nicht wirklich sinnvoll aus, meine wenigen Gehversuche unter Windows waren immer von Ärger gekrönt. Ist aber doch einige Jahre her. In Zeiten von 10Gbit vermisse ich das halt nicht wirklich. Bin kein Fan der Netzwerkonfig unter HyperV, in ESXi ist das so absolut simpel gestrickt in der Konfig, dass ich mich mit HyperV nur sehr ungerne rumschlage (Einer DER Haupgründe warum ich ESXi statt HyperV verwende, einfach kein Bock auf allfällige Netzwerkproblemsuche und mich in die Eigenheiten einarbeiten)

[illumina7 3]

Hallo Stefan, 

Leider habe ich weder Ursache noch eine Lösung für das Problem gefunden. 

Als Workaround lasse ich die rdsh und den Broker jetzt jede Nacht neustarten.

Ist nicht schön, aber besser als wenn ich 3mal die Woche die Farm in der Arbeitszeit neustarten muss, weil sich niemand mehr einloggen kann. 

 

Falls du die Ursache finden solltest wäre ich über einen Tipp sehr dankbar. 

 

Gruß Illumina7

bearbeitet 25. Februar 2022 von illumina7

[Weingeist 157]

Damit ist das Probleme behoben? Also dann tippe ich auf eine Software welche sich nicht sauber entlädt. Was läuft denn da drauf ausser Office und Windows?

[Nobbyaushb 1.361]

Wir hatten mal solche Probleme mit einer Software für Ordner-Rücken.

Da die nur zwei der Anwender tatsächlich gebraucht haben, deinstalliert und Fehler weg.

In der Regel wird man in der Ereigniss-Anzeige was finden

[djmaker 95]

Ich habe noch etwas für die Analyse gefunden:

 

https://docs.microsoft.com/de-de/troubleshoot/windows-server/remote/log-files-to-troubleshoot-rds-issues

 

Was sagen die Protokolle des phys. Hosts?

[illumina7 3]

Am 26.2.2022 um 00:07 schrieb djmaker:

Ich habe noch etwas für die Analyse gefunden:

 

https://docs.microsoft.com/de-de/troubleshoot/windows-server/remote/log-files-to-troubleshoot-rds-issues

 

Was sagen die Protokolle des phys. Hosts?

Die Analyse hatte ich schon einige Zeit aktiviert - ohne hilfreiches Ergebnis.

 

Protokolle der Hyper-V Hosts sind praktisch komplett sauber, überhaupt nichts Auffälliges.

Am 25.2.2022 um 19:14 schrieb Nobbyaushb:

Wir hatten mal solche Probleme mit einer Software für Ordner-Rücken.

Da die nur zwei der Anwender tatsächlich gebraucht haben, deinstalliert und Fehler weg.

In der Regel wird man in der Ereigniss-Anzeige was finden

Alle 5 RDSH Server sind mit der identischen Software ausgestattet (gleiche Installer) und komplett durchgepatcht. 

4 RDSH sind produktiv, 3 hängen sich ab einer nicht, der 5. RDSH ist ein Testserver, der hängt sich auch nicht ab. Die Server sind nicht geklont sondern wirklich einzeln installiert.

Denke nicht, dass der Fehler von irgendeiner ominösen Software ausgelöst wird, dann müsste es ja eigentlich alle 4 RDSH betreffen.

 

Am 25.2.2022 um 15:09 schrieb Weingeist:

Hui, da war mal eine Antwort...

 

Wie gesagt, da geht nur systematisches Vorgehen. Wenn Du Dinge an der Umgebung geändert hast mach sie als erstes rückängig. Wenn Du das Gefühl hast, es ist seit dem aktiven Teaming, hebe es doch einfach wieder auf und teste es

 

Teaming kenne ich mich nicht wirklich sinnvoll aus, meine wenigen Gehversuche unter Windows waren immer von Ärger gekrönt. Ist aber doch einige Jahre her. In Zeiten von 10Gbit vermisse ich das halt nicht wirklich. Bin kein Fan der Netzwerkonfig unter HyperV, in ESXi ist das so absolut simpel gestrickt in der Konfig, dass ich mich mit HyperV nur sehr ungerne rumschlage (Einer DER Haupgründe warum ich ESXi statt HyperV verwende, einfach kein Bock auf allfällige Netzwerkproblemsuche und mich in die Eigenheiten einarbeiten)

Nachträglich hatte ich noch den Switch, an dem die beiden Hosts hängen, getauscht, leider auch erfolglos. Beim Switchtausch ist mir aufgefallen, dass ein kurzer Netzwerkdisconnect eben nicht zum "Verlieren" der User Profile Disks führt. Erste bei einer Trennung von ~10min waren die UPD dann komplett abgehängt, also selbst ein paar verlorene Datenpakete sind kein Indikator für eine Trennung.

Problem tritt mit und ohne NIC Teaming auf dem Hyper-V Host auf, aktuell ist das Teaming aber wieder aktiv.

 

 

Irgendwie müsste ich den ursprünglichen Fehler finden, auf dem hin dann alle Windows Protokolle der RDSH mit Fehlermeldungen zugespamt werden. Trotz etlicher Tage Logs lesen und analysieren ist es mir bis jetzt noch nicht gelungen diesen einen Fehler zu identifizieren. Zusätzlich erschwert wird die Fehlersuche auch durch die Symptome, ich kann einen "abgehängten" RDSH am Broker nicht mehr zum Login deaktivieren und mich in Ruhe durch die Logs wühlen, der Broker versucht also weiterhin neue User auf den Server zu verbinden und die User in ihre getrennten Sitzungen zurück zu verbinden, was nicht funktioniert. Einen fixen Zeitpunkt gibt es auch nicht, der Fehler tritt idR zwischen 1 und 7 Tage Laufzeit auf, aber auch nicht immer, teilweise erst nach 4 Wochen auf einem Server, während ich die anderen beide 3mal die Woche neustarten musste. Also bin komplett ratlos inzwischen.

[Nobbyaushb 1.361]

Ich habe jetzt nicht rausgelesen ob die Host in Physik oder als VM laufen.

 

Bei NIC Teamining gehe ich von Physik aus.

Was für NIC sind verbaut, ist das Markenhardware (Dell, HP, Lenovo..)

[StefanA 0]

Moin Zusammen,

also bei uns sieht das Fehlerbild exakt wie bei Illumina7 aus.

Wir haben hier allerdings nur 2 rdsh und auf dem Ersten läuft auch Broker und Lizenzserver.

Ich starte die Server bereits seit einigen Monaten Nachts durch und trotzdem tritt der Fehler unregelmäßig auf.

Generell scheint es immer um die Mittagszeit zu passieren. Hier scheinen viele User Browsergames oder Ähnliches zu machen, da der Edge viel CPU nutzt.

Den Hosts habe ich 8 Kerne und 24GB RAM (fest) gegeben, unter HyperV und für ca. 6 User.

Der rdsh1 und der Fileserver, auf dem die UPDs liegen, befinden sich auf dem gleichen HyperV Host. Dieser steigt auch relativ selten aus.

Der rdsh2 läuft auf einem anderen Host und macht die meisten Probleme. Auch ein Umziehen auf einen dritten Host macht keinen Unterschied.

Host 1 und 2 sind identische Hardware von Krenn. Host 3 ist ein älterer Server von Maxdata und mit HyperV Core.

 

Nic-Teaming habe ich auf allen Hosts aktiviert (Switchunabhängig). Hier sind Intel Karten verbaut.

Alles Server2019 Maschinen und durchgepatcht.

 

Software auf den rdsh's ist überschaubar, Office2019, Acrobat, Firefox, 7ip, Telefonsoftware und unser ERP. Mehr ist da nicht drauf.

Im "normalen" Betrieb dümpelt die CPU Auslastung bei 5 bis 20% rum und RAM Ausnutzung liegt unter 10GB.

 

In den Logs finde ich auch nichts, was hier passen könnte. Bin hier auch am verzweifeln.

 

mfg

Stefan

 

 

[illumina7 3]

vor 21 Stunden schrieb Nobbyaushb:

Ich habe jetzt nicht rausgelesen ob die Host in Physik oder als VM laufen.

 

Bei NIC Teamining gehe ich von Physik aus.

Was für NIC sind verbaut, ist das Markenhardware (Dell, HP, Lenovo..)

 

Zwei identisch ausgestattete Supermicro Server (Dual AMD Epyc, 384GB DDR4 ECC, 2xRaid10 Intel Server SSDs) als Hyper-V Hosts, Maschinen sind für Hyper-V zertifiziert. Server 2019 Datacenter in der kompletten Umgebung (Hosts und VMs, RDSH, Fileserver, etc.).

Eine RDSH VM hat derzeit 16 vCPUs und 32-48GB Ram zugewiesen, Broker und Lizenzserver laufen auf eigener VM getrennt, insgesamt ca. 120 User, VMs laufen ziemlich entspannt, seitdem ich die vCPUs von 8 auf 16 verdoppelt habe.

Alle VMs werden repliziert, dafür sind die beiden Server direkt per 2x10Gbit/s LWL Kabel verbunden (Intel X710, nur für Replikation).

Beide Hyper-V Hosts haben je zwei Intel X550 10Gbit Kupfer NICs Onboard verbaut, über die diese im Teaming am Netzwerk hängen. Gepatcht sind die beiden Hosts derzeit auf einen Netgear XS708T als "Core Switch", dort sind die 4 weiteren internen 1G HPE Switches für die Clients gepatcht.

 

vor einer Stunde schrieb StefanA:

Moin Zusammen,

also bei uns sieht das Fehlerbild exakt wie bei Illumina7 aus.

Wir haben hier allerdings nur 2 rdsh und auf dem Ersten läuft auch Broker und Lizenzserver.

Ich starte die Server bereits seit einigen Monaten Nachts durch und trotzdem tritt der Fehler unregelmäßig auf.

Generell scheint es immer um die Mittagszeit zu passieren. Hier scheinen viele User Browsergames oder Ähnliches zu machen, da der Edge viel CPU nutzt.

Den Hosts habe ich 8 Kerne und 24GB RAM (fest) gegeben, unter HyperV und für ca. 6 User.

Der rdsh1 und der Fileserver, auf dem die UPDs liegen, befinden sich auf dem gleichen HyperV Host. Dieser steigt auch relativ selten aus.

Der rdsh2 läuft auf einem anderen Host und macht die meisten Probleme. Auch ein Umziehen auf einen dritten Host macht keinen Unterschied.

Host 1 und 2 sind identische Hardware von Krenn. Host 3 ist ein älterer Server von Maxdata und mit HyperV Core.

 

Nic-Teaming habe ich auf allen Hosts aktiviert (Switchunabhängig). Hier sind Intel Karten verbaut.

Alles Server2019 Maschinen und durchgepatcht.

 

Software auf den rdsh's ist überschaubar, Office2019, Acrobat, Firefox, 7ip, Telefonsoftware und unser ERP. Mehr ist da nicht drauf.

Im "normalen" Betrieb dümpelt die CPU Auslastung bei 5 bis 20% rum und RAM Ausnutzung liegt unter 10GB.

 

In den Logs finde ich auch nichts, was hier passen könnte. Bin hier auch am verzweifeln.

 

mfg

Stefan

 

Klingt wirklich unserem Problem sehr ähnlich.

Unsere Software auf den RDSHs: Office 2019 Std, Firefox ESR, Acrobat Reader, 7-zip, CTI (MyPortal), Citrix Client für Buchhaltungssoftware, sfirm, pdf24, Zoom und Teams, Nextcloud Client. Alles andere an "Spezial-Software" läuft als Remoteapp über einen eigenen Server (z.B. Acrobat Pro, CAD Software, etc.).