Windows Datenbankzugriff blockiert bzw. verlangsamt

[maxprox]

Hallo,

komplizierte Geschichte:
Es geht um einen Proxmox Produktivserver einer größeren Arztpraxis (1x Proxmox Server, 16x aktuelle Windows 7 Clients mit SSDs), der seit über 4 Jahren ohne eine Ausnahme stabil und schnell läuft.
Auf der Proxmox 3.4-14 Maschine mit 16 GB RAM, Raid 10 usw. läuft nur eine VM: Windows 2008 R2.
Darauf läuft neben dem ActivDirectory die Praxensoftware namens Medistar und Moviestar.

Seit 4 Wochen, seit Anfang Juli ist der Zugriff auf die Moviestar Datenbank ca. um den Faktor 5x bis 10x langsamer oder friert für 2 bis 5 Minuten ganz ein. Über Moviestar werden eingescannte Dokumente als PDF in eine interne Access Datenbank über eine ODBC Schnittstelle übertragen. Und jeder dieser Prozesse dauert anstatt wie die 4 Jahre zuvor nicht 0,5 bis 2 Sekunden sondern bis zu Minuten oder friert eben kurz ein.

Zeitgleich mit dem beschriebenen Problem gab es Ende Juni einen Befall durch einen Nachfolger von Locky (zepto), dessen Schaden durch Backup-Rücksicherung gering gehalten werden konnte. Befallen war vor allem ein Client, der "Verursacher" und die Freigaben auf dem Server.

Jetzt haben wir bereits:
1: Die ganze Moviestar Software auf dem Server (der VM) und den Clients komplett deinstalliert und neu installiert.
2: Die eigentliche Datenbank zu den Entwicklern geschickt => keine Fehler.
3: Gestern einen separaten neuen Windows Server -ohne Virtualisierung-BareMetall- hingestellt, noch mal installiert, und lief so schnell wie noch nie.
4: heute einen separaten zweiten Proxmox 4.2(!) Server mit neu aufgesetzter Windows 2012R2 VM wiederum Moviestar darauf neu Installiert - und: ich kann es nicht verstehen, wieder das gleiche Problem!

Mir gehen die Ideen aus. Zur Zeit ist die einzige Lösung nicht mehr zu virtualisieren. Das wäre für mich ein Super GAU!

Für Ideen und Hinweise wäre ich mehr als Dankbar.
maxprox

 

[fireon]

Also zum ersten: Ich kann dir aus Erfahrung sagen das in der EDV nix unmöglich ist was die Problemstellung angeht, sei es noch so unlogisch.

Nun zu deinem Problem, wohl einer der kniffligsten. Alles völlig unlogisch. Du sagst aus heiterem Himmel hat sich die Geschwindigkeit geändert? Gab es denn überhaupt keine aktiven Änderungen, z.B. von der Konfiguration deiner VM, oder der Anforderungen vom Hersteller? Sind event. irgendwelche HW/BIOSstrings seit neuesten erforderlich (hatten wir jetzt vor kurzem, da eine Software vom Hersteller nicht auf der Virtualisierung unterstützt wird, nach Eingabe des HW/BIOSstrings lief diese einwandfrei), hat sich das Datenbanklayoutforma geändert, der Datenbankinhalt, Abhängigkeiten. War die BareMetallinstallation ein 2008r2 oder Win2012? Sind die Testsysteme mit den gleichen Produktdateien auch gefüttert worden? Wie ist deine VM configuriert (qmconfig ID)? Mit dem Cryptotrojaner hat es nichts zu tun.

Wie ist denn die Last des Servers, gibt es das Probleme wenns virtualisiert ist? i/o, cpu, netzwerk. Wie schaut die Netzwerkconfig aus, gibt es da Unterschiede?

 

[maxprox]

Hallo Fireon,

ja, absolut unlogisch!
Der (Supermicro-) Server lief die letzten Jahre wie ein Uhrwerk, (und) die VM zeigte zu keiner Zeit während der Tests oder innerhalb der eigentlichen Zeitverzögerungen eine größere Auslastung. Die Proxmox GUI Verlaufsgrafik zB über die letzte Woche der CPU usage geht nicht mal in den zweistelligen Bereich.
Außer Updates einspielen wurde am Proxmox-Server nichts geändert, spielt auch kaum eine Rolle, ich habe heute, wie beschrieben, ein komplett anderes Serversystem (einen anderen physischen Server) mit einer neueren Proxmox Version (statt 3.4 wie der Produktivserver mit 4.2) getestet.

Die Produktiv VM ist ein W2k8R2 Windows Server die von mir alternativ getesteten sowohl auf dem Produktivserver als auch auf dem neuen mit dem Proxmox 4.2 waren W2k12R2 Server.

Die Maschine der Medistar-Supporter war ein Win7-Prof. - BarMetal - das einzige das lief.

Auf allen wurde letztendlich auch immer die Produktivdaten, also die Prokuktiv-Datenbank migriert und damit getestet.

So und jetzt wird es noch verrückter: nachdem der Fehler bereits eine Woche vor herrschte, gab es ein großes Release-Upgrade der Problem-Software "Moviestar", von der ich dachte "jetzt wird alles gut!" n e i n, keinerlei Veränderung.

Übrigens: die einzige evtl. rettende Idee, die mir zZ einfällt, so dass ich bei dieser Arztpraxis evtl. doch noch bei Proxmox bleiben kann, war die Bitte an die Medistar-Supporter, mir ein (Acronis) Image der super laufenden Win7-Prof. Version zur Verfügung zu stellen, mit der ich von physisch zu virtuell (P2V) migrieren kann. Dem konnten sie aber bisher noch nicht zustimmen, obwohl das mit einem neu eingegebenen legalen Key eigentlich kein Problem sein sollte.

Vielen Dank für's mitdenken,
maxprox

 

[fireon]

PHY zu VIRT ist kein Problem, haben wir schon zigmal gemacht. Clonezilla auf beiden Seiten, System zusammenräumen, alle Treiber entfernen, alles auf DHCP schalten und das script ausführen: https://ftp.iteas.at/public/Mergeide.reg Dann runterfahren und mit Clonezilla nach Best Practice migrieren.

Also in der VM zuerst IDE und 100mbit Netzwerkkarten. Dann virtuelle virtio Platte hinzufügen usw.... glaub du weist schon wie das geht.
Natürlich vorher Image ziehen. Und bevor du die VM bearbeitest, Snapshot.

lg

 

[robhost]

Wie sehen denn die SMART Werte der SSDs aus? Sind diese vielleicht am Ende?

Evtl. zudem mal TRIM laufen lassen, evtl. wurden durch Locky auch VM-Images (nutzt Ihr QCOW?) komplett ausgerollt und sind nun deutlich größer auf den SSDs (Verifikation via qemu-image info image.qcow). Hier hilft ebenfalls TRIM in den VMs, allerdings k.A. wie/ob das mit Windows geht.

 

[maxprox]

Hi robhost,
nein, das sind die guten Samsung 850 Pro, die werden von mir mit dessen Programm alle 1/4 Jahr gepflegt.
Und damit wir uns richtig verstehen: SSD's gibt es nur auf den Clients! Auf dem Server habe ich ein Raid 10 (4xSAS HGST 2TB) auf einem Adaptec Raid Controller.
Ist beides gecheckt und beides gut.
Außerdem haben wir ja alle serverseitigen Probleme versucht auszuschließen, in dem wir Testweise auf einen anderen Server migriert hatten und dieser Server hatte natürlich andere Hardware und hatte eine neuere Proxmox Version.

-----------------------------------------------------------------------------

Am Sonntag habe ich den einzigen Switch in diesem Netz getauscht, wegen Lüfterausfall (D-Link 1210-48 G) gegen den gleichen neueren.
Dabei habe ich das gesamte Netzwerksetup geändert:
am Switch und am Proxmox Host habe ich ein Bond Mode 4 bzw. LACP eingerichtet. Vorher war nur ein LAN Interface des Servers angeschlossen. An der betroffenen Windows 2008R2 Server VM habe ich die virtuelle Netzwerkkarte von virtio auf Intel E1000 umgestellt.
Ich will halt nichts unversucht lassen.
Dann habe ich den problembehafteten Moviestar PDF Import erneut getestet ==>> es ging. Die jeweiligen Zeiten (Start, Import, Oberfächenwechsel) dauerten nur zwischen 1 und 5 Sekunden, was normal für diese Umgebung ist.
Heute im produktiven Test mit freudiger Erwartung in der Praxis angerufen.... :-(( Die Arzthelferinnen konnten heute abermals keine Verbesserung feststellen.
Vielleicht gibt es ja ein Zusammenhang mit einem oder mehreren Clients. Der Locky Nachfolger hatte sich ja verschlüsslungstechnisch immerhin auf den Freigaben dreier Clients -nachweislich- ausgetobt. (Wir haben übrigens nie die eigentliche Malware analysieren können, was aber bei dieser Art der Ransomware wohl nicht unüblich ist)
Also, um Clientprobleme aufdecken zu können, sollen die Arzthelferinnen vor oder nach Dientsbeginn, zunächst nur den einen Import-Client hochfahren und -so wie ich am Wochenende- mit nur diesem einen Windows Client testen.
Wenn das dann auch wieder so schnell wie gewünscht läuft, dann sollen sie sukzessive weiter Windows Clients hochfahren und dazwischen immer wieder Testen...
Vielleicht kommt ja dabei was zum Vorschein - ich sag auf jeden Fall Bescheid.

Für jede weiter Idee dankbar
maxprox

 

[maxprox]

Also:
Weil bisher alle Versuche, die Software auf einer VM wieder korrekt zum Laufen zu bringen, gescheitert sind,
habe ich zZ keine angemessene Alternative dazu gefunden, in den sauren Apfel zu beißen und die Software auf einen Leistungfähigen als Server umgebauten Arbeitsplatz PC aus zu lagern.
Das haben wir heute umgesetzt.

 

[fireon]

Also:
Weil bisher alle Versuche, die Software auf einer VM wieder korrekt zum Laufen zu bringen, gescheitert sind,
habe ich zZ keine angemessene Alternative dazu gefunden, in den sauren Apfel zu beißen und die Software auf einen Leistungfähigen als Server umgebauten Arbeitsplatz PC aus zu lagern.
Das haben wir heute umgesetzt.

Huch, ja schade. Aber da kann man nichts machen. Gibt eben leider oft Dinge in der IT die man sich nicht erklären kann. Mach dir nix drauf, vielleicht kommst noch drauf. Bei mir hats mit meinem virtualisierten VDR fast ein Jahr gedauert bis ich den Fehler gefunden habe, war auch schon kurz davor alles wieder auf eine PHY Maschine zu werfen. Aber in meinem Fall war durch ein Update verursachte Softwarefehler in blöder Kombination mit Virtualisierung Schuld. Bin muss ich zugeben, dann durch Zufall drauf gekommen... wobei... trau ich mir fast wetten das es bei dir sicher nur eine Kleinigkeit ist. ...ist ja fast immer so

lg

 

[maxprox]

Ja, da gebe ich dir recht, wenn man die eigentliche Fehlerursache raus bekommen hat, was ja leider nicht immer der Fall ist, sind meist nur wenige Handgriffe oder Einstellungen nötig um es zu beheben --- zu viele wenn ;-)

Ganz wichtig hier zu erwähnen:
Ich bin recht sicher, dass das eigentliche Problem nicht wirklich was mit Proxmox und der Virtualisierung zu tun hat.

Im produktiven Einsatz -heute zum ersten mal- stellte sich nun heraus, dass der NICHT VIRTUALISIERTE Windows 7 Prof. (alles auf einer Samsung SM863 SSD, i5 und 16GB RAM) liefen die Datenbankzugriffe wieder nicht, also wieder die Probleme mit den teilweise ein zwei Minuten und länger hängenden Zugriffen usw.
Dann habe ich diesen als Server laufenden Windows 7 Porf. PC aus der Domäne genommen und ohne Domänenmitgliedschaft im Netz laufen lassen, danach lief es wieder schnell, ich warte mal den morgigen Tag ab.
Um das zu durchschauen reichen meine Kenntnisse leider nicht aus.
Grüße,
maxprox

 

[proxtest]

Kannst du dem ODBC-Treiber Benutzernamen und Passwort aus der Datenbank direkt mitgeben? Das ganze sieht ja eher nach einem Netzwerktimeout von Windoof aus.
Bei MS SQL kannst du einstellen ob Windoof Useraccount oder DB Account, mit DB Account gabs bisher nie Probleme.

 

[maxprox]

Kannst du dem ODBC-Treiber Benutzernamen und Passwort aus der Datenbank direkt mitgeben? .....

ich gebe das an die Supporter von Moviestar / Medistar weiter und und kläre das mit denen ab.

Ergebnis ist zZ: erst nachdem wir den als Movistar Server laufenden Windows 7 Prof. PC aus der Domänenmitgliedschaft raus genommen haben lief der Zugriff wieder zuverlässig.
Und das jetzt seit 1 1/2 Tagen....

 

[fireon]

ich gebe das an die Supporter von Moviestar / Medistar weiter und und kläre das mit denen ab.

Ergebnis ist zZ: erst nachdem wir den als Movistar Server laufenden Windows 7 Prof. PC aus der Domänenmitgliedschaft raus genommen haben lief der Zugriff wieder zuverlässig.
Und das jetzt seit 1 1/2 Tagen....

Hmm, irgendwelche netten GPO's?

 

[Kevin Weise]

3: Gestern einen separaten neuen Windows Server -ohne Virtualisierung-BareMetall- hingestellt, noch mal installiert, und lief so schnell wie noch nie.

Wir hatten hier bei einem Windowsserver auch große Performanceeinbußen. Problem kam von dem Ballooning-Device. Erst nachdem wir ihn über die vmid.cfg mit "balloon: 0" rausgeschmissen haben war es deutlich besser. Deaktivieren oder Treiber rausschmeißen unter Windows brachte nichts.

Ansonsten hat das hier gut geholfen:
https://pve.proxmox.com/wiki/Windows_2008_guest_best_practices

 

[maxprox]

Hmm, irgendwelche netten GPO's?

No, Gruppenrichtlinien domänenweit nutze ich nur für die Druckerverteilung, Laufwerksmapping, und Deaktivierung von Offlinedateien

Wir hatten hier bei einem Windowsserver auch große Performanceeinbußen. Problem kam von dem Ballooning-Device. Erst nachdem wir ihn über die vmid.cfg mit "balloon: 0" rausgeschmissen haben war es deutlich besser. Deaktivieren oder Treiber rausschmeißen unter Windows brachte nichts. Ansonsten hat das hier gut geholfen:
https://pve.proxmox.com/wiki/Windows_2008_guest_best_practices

No, durch die unterschiedlichen Tests mit unterschiedlicher Hardware können wir das ausschließen. Und wie schon beschrieben, der Server UND die Moviestar Software liefen 4Jahre anstandslos, wohl auch weil ich mich an so was wie "best practices" gehalten habe ;-)
Trotzdem finde ich dein Hinweis über "balloon: 0" gut, das kannte ich so noch nicht und bei mir machen die VirtIO- u. Balloon-Treiber oft "blöd" und führen insbesondere wenn ich neuere Versionen einspiele, oft zum BlueScreen (daher fasse ich die inzwischen, wenn sie ein mal laufen, nicht mehr an).

Nein, das Problem muss ein sehr spezielles sein. Kommunikation zur Moviestar-DB Schnittstellte in Verbindung mit Domänenrechten, evtl. Firewall evtl. auch GPOs, aber hier haben die Supporter und ich bereits die "Liste" der nötigen Einstellungen mehrfach geprüft.

Das physische Netz kann auch als Fehlerquelle ausgeschlossen werden: neue Kabel, neuer Switch, sogar neue NIC Schnittstelle am Server (Bond Mode 4)

Was bleibt sind so Einstellungen wie von testprox in Post 10 beschrieben,
das muss ich aber noch mit den Supportern klären (ich weiß nicht ob, wie und wo das in Moviestar eingestellt werden kann).
Grüße, maxprox