Hallo, das Thema wurde ja schon des öfteren diskutiert, aber alle paar Monate scheint es dazu wieder neue Erkentnisse zu geben. Deshalb wollte ich einmal für unser aktuelles Vorhaben nachfragen, ob dies so machbar ist.
Ist-Zustand: Client-Server, File-Server Win2008R2 + LizServer, SWM Modul per USB/LAN Server angebunden, kein DMS, Domäne ist bereits neu umgestellt (Funktionslevel 2016), der bisherige DATEV Server läuft auf einem Blech o. Virtualisierung.
Soll-Zustand: Client-Server wird beibehalten, DATEV FileServer 2019 auf einem Virtuallisierungshost (Hyper-V) installieren, Der Servername ändert sich dabei
Für die Installation des virtuellen DATEV FileServers hätte ich folgende Ressourcen vergeben: 8 CPU Kerne je 3 GHz, 32 GB RAM, 800 GB HDD (200 GB C-System, 600 GB D-Daten (Windvsw1)
Bei der Installation des Server gehe ich nach Dok. Nr. 1070547 vor, dazu diese Fragen
-Am server war bisher das lokale DATEV Verzeichnis unter D:\DATEV - darunter befindet sich auch das Windvsw1 Verzeichnis und eben auch das lok. Prog. Verzeichnis. Dies möchte ich trennen, dass unter D:\DATEV nur noch windvsw1 liegt und das lokale Prog/Daten Verzeichnis vom Server unter c:\ProgramData. Ist dies so möglich, bei der DATEV Server Installation sollte er diese Struktur ja selbst anlegen
Der Umzug von Server alt zu Server neu, soll per SAA (2.0) erfolgen. Ich habe schon einige Beträge hier dazu gelesen und es scheint immer wieder eine neue Erfahrung bei dem Thema aufzutauchen. Diesen Ablauf hätte ich geplant, nach Dok. 1011814
-der neue Server ist auf Win Ebene fertig installiert und in der Domäne eingebunden, noch keine DATEV Installation, kein DNS und DHCP - es gibt zwei seperate DCs
-akt. Datensicherung DATEV Server alt ist vorhanden, BRV Notprogramm ist angelegt
-am alten FileServer alle SQL Datenbanken trennen und SQL Server herunterfahren
-Lizenzmanager Server stoppen, Standard Verzeichnis kopieren und an neuen Server das Verzeichnis C:\ProgramData\DATEV\Daten\LimaServ\LizPool\Standard anlegen und die Lizenz Daten hineinkopieren
-Lizenzmanagerserver alt deinstallieren - wirklich nötig?
-SWM von Server alt trennen
-dem Dokument nach nun (wg. SAA 2.0) das ConfigDB Verzeichnis nicht mit SAA exportieren sondern wegkopieren und umbenennen
-Freigabe an alten Server entfernen
-Freigabe an neuen Server erstellen, windvsw1 als L: einbinden, Verzeichnis von Server alt auf neu kopieren. Umbenannte ConfigDB kann mitkopiert werden
-(wg. SAA 2.0) alter Server D:\DATEV\DATEN\B0001502\DATA\STANDARD\CentralConfigurationData nach C:ProgramData\DATEV\DATEN\B0001502\DATA\STANDARD\CentralConfigurationData kopieren (Pfad anlegen)
-leere ConfigDB unter windvsw1 anlegen
-Server Plattform mit LimaServer installieren
- SAA 2.0 an einem PC starten, Serverumzug mit zuvor wegkopierten ConfigDB Verzeichnis ausführen
- SWM Modul verbinden prüfen ob Lima läuft
- an restlichen Clients SAA durchführen
Habe ich hierbei einen groben Patzer enthalten, oder sollte dies so funktionieren bzw. ist der Ablauf sinnvoll.
Sorry für die ausführliche Fragestellung und Danke vorab für eventuelle Tipps.
Gruß
Matthias Sammel
Hallo matthiass,
leider funzt in der Community das "zitieren" wieder mal nicht.
Außerdem gibt es zum Thema Server-Umzug eine ganze reihe weiterer Dokumente - die sicher vorher mal durchgesehen werden sollten.
Und Letztlich meine Empfehlung - wenn die Hardware das hergibt, dann unbedingt auch auf Terminalserver umsteigen und den auf das gleiche Blech wie den fileserver legen - das gibt einen deutlichen Performanceschub.
Ich würde von Client-Server Umgebungen - schon wegen des viel höheren Pflegeaufwands - abraten.
@matthiass schrieb:Für die Installation des virtuellen DATEV FileServers hätte ich folgende Ressourcen vergeben: 8 CPU Kerne je 3 GHz, 32 GB RAM, 800 GB HDD (200 GB C-System, 600 GB D-Daten (Windvsw1)
Von den 8 werden dann laut meiner Info maximal 4 von DATEV genutzt. Das ist OK. Ich denke auch 4 würden ausreichen, wenn es nur SQL Datenbanken ohne DMS sind.
32GB RAM - je mehr desto besser. Wenn möglich und das ist abhängig von der Größe der REWE Datenbank, würde ich schon auf 48GB oder mehr gehen, wenn man > 100GB REWE Datenbank hat.
Festplatte:
Und wenn virtualisiert wird und man dabei ist 1 schicken großen Host zu kaufen: zumindest sollte man wie @Michael-Renz schreibt prüfen, ob ein WTS/RDS nicht die bessere Lösung ist. Dann kann man mit Veeam alles inkl. aller VMs easy sichern und wiederherstellen und die Clients sind nur noch "Anzeige-PCs". Aktuelles Windows drauf, aktuell halten via WSUS oder jeder Client geht selbst an die MS Updateserver und man ist fertig. Neue Software? 1x am WTS installieren, fertig.
Und dass Argument, wenn 1 PC ausfällt, kann der Rest arbeiten zieht nicht, weil man dank Veeam einen WTS in maximal 1h wieder am Laufen hat und wenn der DATEV SQL ausfällt, können die Clients auch nicht arbeiten. Gehopst wie gesprungen.
@metalposaunist schrieb:
Genau das ist der Vorteil der Virtualisierung, dass man Festplatten immer größer machen kann, aber nie kleiner....
verkleinern geht bei HyperV schon recht einfach, aber nicht im laufenden Betrieb, und zugegeben nicht ganz so simpel wie vergrössern.
erst in der Datenträgerverwaltung das Volume verkleinern, und dann in der Powershell mit "Resize-VHD -Path <vDisk.vhdx> -ToMinimumSize" die vhdx verkleinern.
Und natürlich niemals ohne vorhergehende Datensichung.
Hallo vielen Dank für hilfreichen Antworten.
Die vhdx Größe werde ich mal so lassen. Der Platz ist gut vorhanden und ich gehe mal davon aus dass der DATEV Server auf C:\ in absehbarer Zeit nicht mehr wie 200 GB brauchen sollte. Da der DATEV Server künftig keine Funktion im ADS mehr hat, wäre er auch "schnell" neu aufgesetzt, falls wirklich irgendetwas knapp werden sollte. Den RAM wollte ich erst mal nicht über 32 GB gehen, da er sich sonst auf die zweite CPU erstreckt, was nicht so ideal ist. Speicher ist ein RAID10 6xSSD.
Das neue DATEV Installationsverzeichnis am Server würde dann so passen, mit lok. Prog/Daten Verzeichnis C:\ProgramData und windvsw1 Verzeichnis auf D:\DATEV.
Für den beschriebenen Umzug der DATEV Daten und Lizenmanager und die Anwendung des SAA 2.0, ist dies so richtig. Vor allem bezogen auf das kopieren der der beschriebenen Config Verzeichnisse.
Gruß
@matthiass schrieb:Den RAM wollte ich erst mal nicht über 32 GB gehen, da er sich sonst auf die zweite CPU erstreckt, was nicht so ideal ist. Speicher ist ein RAID10 6xSSD.
Das glaube ich kaum und wenn, sind's nicht nennenswerte Prozente. Und bei > 100GB REWE Datenbank machen 48GB+ deutlich mehr Sinn.
@matthiass schrieb:Das neue DATEV Installationsverzeichnis am Server würde dann so passen, mit lok. Prog/Daten Verzeichnis C:\ProgramData und windvsw1 Verzeichnis auf D:\DATEV.
Das lokale Programmverzeichnis ist C:\Program Files (x86). Unter ProgramData wird nur die lokale Datenbank abgelegt, welche es in einer WINDVSW1 Umgebung nicht gibt. Aber das macht DATEV alles von alleine schon richtig.
Ich meinte damit vor allem diesen Punkt aus dem Dokument 1011814
Hier muss ich doch das Verezichnis aus dem bisherigen %DatevDP% (in meinem Fall D:\DATEV\Daten am Server und nicht in windvsw1) nach C:\ProgramData kopieren.
Hallo,
der Server Umzug ist soweit erfolgreich gewesen. Datenumzug und Serveranpassung haben auch funktioniert, es gab dabei auch keine Fehlermeldungen. Es kann auch in allen Programmen gearbeitet werden.
Eines dabei gefällt mir aber noch nicht. Es fällt auf, dass die Reaktionszeiten im z.B. Rechnungswesen geschätzt teilweise doppelt solange wie vor dem Tausch sind.
Beispiele:
Hatt vielleicht jemand eine Idee, wie ich weiter die Performance/Funktion testen kann, oder gibt es bei dieser Art von Umzug eine bekannte Stellschraube, an der man Verbesserungen vornehmen kann?
Es gibt in der Tat einen Test für die Performance von DATEV. Einfach folgende Datei ausführen: C:\Program Files (x86)\DATEV\PROGRAMM\RWAPPLIC\Leistungsindex.cmd
Es wird dann genau aufgelistet wo es zu langsam ist. Das kann vom SQL, über CPU bis zu den Platten alles sein.
@dombrowski schrieb:
Hatt vielleicht jemand eine Idee, wie ich weiter die Performance/Funktion testen kann, oder gibt es bei dieser Art von Umzug eine bekannte Stellschraube, an der man Verbesserungen vornehmen kann?Es gibt in der Tat einen Test für die Performance von DATEV. Einfach folgende Datei ausführen: C:\Program Files (x86)\DATEV\PROGRAMM\RWAPPLIC\Leistungsindex.cmd
Es wird dann genau aufgelistet wo es zu langsam ist. Das kann vom SQL, über CPU bis zu den Platten alles sein.
... vermutlich hängen doch aber die Ergebnisse dieses Tests auch stark von der momentanen Auslastung des Arbeitsplatzes, des LANs, des Fileservers etc ab, oder ?
... aus meiner Sicht eine recht gute Orientierungshilfe (bei definierten 'Labor'-Bedingungen)
... vermutlich hängen doch aber die Ergebnisse dieses Tests auch stark von der momentanen Auslastung des Arbeitsplatzes, des LANs, des Fileservers etc ab, oder ?
Ja klar. Ich würde den Test einfach mal Abends auf dem neuen und auf dem alten System laufen lassen, um einen Vergleich zu haben. Sollte das alte DATEV System nicht mehr existieren, dann helfen bestimmt einige Kollegen hier mit Vergleichswerten. Sollte sich auf jeden Fall lösen lassen. Das ein neues System langsamer ist als das alte, darf einfach nicht vorkommen.
Hallo, gilt dieser Index nur in Terminal Server Umgebungen? Ich kann diese Bat leider nicht finden, weder im Datev Prog Verzeichnis auf dem Client, noch Server?
.... lokal auf jedem Client, auf dem Rewe installiert ist
.... außerdem keine .bat sondern .cmd
... vielleicht besser nicht nach dem ganzen Pfad, sondern nur nach "Leistungsindex.cmd" suchen
... befindet sich bei mir in "C:\DATEV\PROGRAMM\RWAPPLIC"
Zu dem Thema Performance nach Installation oder Update gibt es eine Info-DB Dokument mit der Nummer: 1080330
Das erstellen der Nativen-Images lässt sich für die Zukunft im Installationsmanager aktiviert, falls nicht aktiv wäre es einen Versuch wert den Befehl per Hand auszuführen.
Aber Vorsicht, der Befehlt nimmt alles was er an Leistung kriegen kann, wenn noch Leute arbeiten, dann wird es für die noch langsamer.
Ich werde es mir noch einmal ansehen und Rückmeldung geben. Danke.
Hallo, diesen Index erhalte ich an einem Client Arbeitsplatz. Am File Server habe ich kein RW installiert und kann den Leistungsindex nicht ausführen. Wie würden andere dieses Ergebnis einschätzen?
.... bei mir, ebenfalls im Client-Server-Netzwerk, ist die Gesamtzeit (gestern kurz getestet) weniger als die Hälfte.
Andere Community-Mitglieder haben, glaube ich, noch bessere Werte
Bei uns auf dem RDS folgendes Ergebnis:
Bild einfügen hat mal wieder super funktioniert (beim 5. Anlauf). 🤔🙄
... vielleicht besser nicht nach dem ganzen Pfad, sondern nur nach "Leistungsindex.cmd" suchen
... befindet sich bei mir in "C:\DATEV\PROGRAMM\RWAPPLIC"
Mein Fehler. Bei Systemen die frisch ab DVD 11 installiert wurden, liegt alles unter Programme. Bei älteren Systemen im DATEV Ordner direkt unter C.
Hallo Matthias,
also die 16 Sekunden sind wirklich schlecht. Was mir bei dir spontan direkt auffällt ist, dass zum einen der reine Anwendungsstart mit 9 Sekunden unglaublich langsam ist (ein Wert zw. 2-3 Sekunden wäre normal), zum anderen aber auch die Festplatten mit 2 Sekunden einen recht hohen Wert (0.5 bei mir mit SSD) haben. Das sind keine SSDs oder?
Vielen Dank für die Antworten. Ich habe es eben noch einmal ausgeführt mit diesen Werten. Die bisher von anderen geposteten Ergebnisse wurden scheinbar immer auf einer TS Umgebung ausgeführt. Bringt es etwas, das Hyperthreading am File Server zu deaktivieren, kann dies jemand bestätigen?
Ich habe keinen Terminalserver, sondern ein 'stinknormales' Client-Server-Netzwerk.
1 Fileserver (der kein Datev-Arbeitsplatz ist) und 17 Clients.
Aufruf direkt auf dem Client.
Es handelt sich schon um SSDs. Geht es bei diesem Leistungsindex nur um den lokalen Programm Start? Für mich wäre ein Test für den Datenzugriff interessanter.
Wie gesagt, einige haben den Index direkt auf dem File/ oder Terminal Server ausgeführt. Dort ist es natürlich schneller.
Direkt auf dem File/SQL Server den Index starten ist natürlich unsinnig. Allerdings sollten die Werte zwischen Terminalserver Installation und Client-Server trotzdem annähernd die gleichen sein. In beiden Fällen werden die Programme lokal gestartet (CPU, RAM, HDD ausschlaggebend) und bei beiden erfolgt der Datenzugriff auf den SQL Server der nicht lokal liegt.
Wenn die schlechten Werte von einer lokalen Installation stammen, Energieoptionen von Windows auf Ausballanciert und nicht auf Performance? Wäre insbesondere bei dem langsamen Programmstart von 9 Sekunden eine Möglichkeit.
Ich habe gerade mal den Test ausgeführt - Client Server - PC ist 8 Jahre - Win10.
Punkt 1 bei mir wird ein "Service Test" mit aufgeführt.
Punkt 2 - Während Werte 1-3 für die Hardware (Alter PC als Kaltreserve ok sind, gibts bei der Festplatte (SSD) sehr schlechte Werte - andere PC in der Kanzlei sind bei der Festplatte ähnlich schlecht. Kann es sein dass hier über das Netz getestet wird. Habe während des Tests keine Ausschläge im Taskmonitor für die lokalen Datenträger - nur Netz. Weiß jemand etwas dazu? Oberfläche liegt wahrscheinlich am 38" Monitor.
sollche miesen Werte hatte ich mal auf einem Serversystem bei dem im Bios der Energiesparmodus nicht auf Höchstleistung stand.
Speziell bei virtuallisierten Systemen kann die falsche Einstellung enorm an der Leistung knabbern.
Ein i5-2500 ist nicht mal offiziell für Windows 10 freigegeben bzw. wird die integrierte Grafikkarte erst ab Generation 3 vollständig unterstützt. Und schaut man sich die Single Thread Werte 7 Jahre später an ... ob es noch sinnvoll ist, da den Flaschenhals zu suchen, muss jeder selber wissen. 38% mehr Leistung ist schon ein Wort und der 9500 ist keine besondere CPU. Ganz normaler Standard.
Zum Problem der Festplatte: SATA II oder gar III? Wenn die SSD vom SATA I oder II Interface mit ca. 150MBs oder 300MBs ausgrembremst wird, ist niemanden geholfen. Und selbst SATA III ist mit seinen 550MBs nicht schnell genug. Deshalb gibt es NVMe PCIe SSDs mit weit über 1GBs.
Wenn es NVMe SSDs sind (wobei das bei 8 Jahre alten Kisten zu 99,9% ausgeschlossen ist, wenn man nicht einen eigenen Controller dazu verbaut, der bootfähig ist): Korrekte Treiber installiert?
Was sagt CrystalDiskInfo oder CrystalDiskMark? Gibt die SSD das her, was sie soll?
Was sagt der Stresstest der DATEV zum Netzwerk, der mehrfach Dateien von Client auf Laufwerk L: und zurück schiebt? PingFile nennt sich das Tool.
Bzgl. HyperThreading: Ist es ein reiner Hardware Fileserver? Dann am besten ausschalten. DATEV nutzt immer die Hälfte der Kerne und maximal 8. Heißt also mehr als 16 Kerne nutzt DATEV sowieso nicht. Und wenn auch der FileServer schicke ca. 2000 Punkte im SingleThread hat, geht DATEV ab.
Danke für die Infos ! Es ist immer wieder mal etwas Neues dabei, was sich zu merken lohnt.
Zum Glück schreiben Sie im öffentlichen Bereich der Community und lassen uns 'Normalos' teilhaben an Ihrem IT-Wissen. In einer der geschlossenen Gruppen (z.B. "Administratoren" etc.) würde Vieles davon verpuffen.
Übrigens, "pingfile.cmd" ist ein sehr schönes Beispiel für den Einsatz von Systembefehlen auf Kommandozeilenebene. Es ist ja keine EXE-Datei, sondern eine Batch-Datei (*.CMD), die man lesen, theoretisch anpassen oder erweitern könnte (falls man sich gut mit Batch-Programmierung auskennt). Jedenfalls kann man damit die Geschwindigkeit und Zuverlässigkeit der Datenübertragungen im LAN gut mit 'Bordmitteln' testen.
Der I5-2500 ist Kaltreserve und Testrechner - habe extra einen alten Rechner zum Vergleich für den Fragesteller genommen.
Unklar ist die Ermittlung der Festplattenwerte im Leistungsindex:
Vergleich I5-2500 Oldie: SSD per SATA III (älteres Modell) Diskmark 283MB / 134MB ; Leistungsindex Festplatte 2,562 Sekunden ; pingfile Senden 847 MBit; Empfang 470 MBit; Summe 605 MBit
Aktuelles System: SSD per SATA III: Diskmark 528MB / 435 MB; Leistungsindex Festplatte 2,244 Sekunden; pingfile Senden 832 MBit; Empfang 850 MBit; Summe 841 MBit
Aus dem Vergleich passt der Leistungsindex Festplatte nicht mit den unterschiedlichen Leistungsdaten der SSD zusammen. Also entweder etwas falsch konfiguriert oder der Index wird anders ermittelt. Muss bei Gelegenheit mal bei einer NVMe schauen.
Was mir aufgefallen ist, der Start des Servicetools dauert sehr lange, kein Vergleich zu vor der Umstellung.
Kann dies auf etwas hindeuten. Sobald es gestartet ist, lässt es sich normal bedienen.
Die Prüfläufe bringen mir aber keine Fehler, Namensauflösung usw. ist alles in Ordnung.
Ich werde nächstens versuchen einen DATEV PC neu zu installieren um zu sehen wie dort die Performance ist.
Mit dem Leistungsindex werde ich nicht schlau, auf einer schlechten HDD, einer mittleren SSD und einer guten SSD
habe ich schlussendlich immer den gleichen Wert.
Den i5 2500 mit dem i5 9500 kann man natürlich vergleichen. Dann muss ich aber auch die 19% Turbo Mehrtakt herausrechnen.Und zu sagen, DATEV läuft nur auf einer NVMe SSD ist natürlich ein Geschenk für einen Verkäufer, aber ein Unterschiedvon SATAIII zu NVMe ist vielleicht messbar, aber im DATEV Arbeitsplatz nicht spürbar.
Wie zu Beginn gesagt, vor dem Update hatten wir noch keine Schwierigkeiten. Deshalb würde ich jetzt nicht bei
der Client Hardware nachforschen. Gibt es eine vernünftige Möglichkeit im DATEV die SQL Performance zu testen?