RAID Config stripe size für den ESXi mit dem DATEV File-Server - Erfahrungswerte?

[#1]

Hallo liebe Kollegen und Community-Members,

die Hardware-Erneuerung steht bei uns mal wieder an und ich habe eine grundsätzliche Fragen in der Hoffnung dass sich schonmal jemand damit intensiver beschäftigt hat.

THEMA: RAID Konfiguration für den VMWare ESXi Server auf dem der DATEV File-Server läuft (in meinem Fall laufen auf dem ESXi ausser dem DATEV DB/File-Server nur einige unperformante guests wie KOMM-Server, LIMA, usw.)

Es handelt sich um ein RAID 10 mit 8 SSDs (zwei davon sind als HotSpares deklariert, BBU und write-back vorhanden und konfiguriert). Das Hauptaugenmerk gillt ja hier wie schon erwähnt der Datenbank.

1. Welche stripe-size ist hier zu empfehlen - RAID-Stripe-Size -> ESXi Stripe Size -> NTFS Cluster-Größe -> Hat da jemand praktische Erfahrungen und Empfehlungen?
2. Besteht die Möglichkeit die DATEV DB zu zerlegen in DB und Logfiles, und falls ja wie sind dann die Empfehlungen für die beiden unterschiedlichen RAID Volumes?

In den letzten 3 Monaten habe ich mehrfach die Kollegen von der DATEV angeschrieben unter der dafür empfohlenen Mail: it-beratung@datev.de - bis heute leider noch keine Antwort bekommen. Bin über jeden Erfahrungsbericht aus eurer Praxis vor allem bezüglich der stripe-sizes dankbar.

[#2]

Zu erstens würde ich nehmen, was ESX vorschlägt, dass ist n.m.E. dynamisch je nach Volumegröße? Jedenfalls nicht <8192, eher Richtung 16k Stripe Size/ Cluster. Je kleiner, desto Fragment und je länger dauern on-demand-RW-Zugriffe und Rebuilds. 

Zu zweitens=nein, bitte nicht DB und LogFiles trennen, auch wenn Dein SQL-Admin sagt, das sei ganz toll performant. Es sei denn, Du möchtest in die Tiefen des individuellen SQL-Management hinabsteigen und findest auch selbst wieder heraus, wenn es nicht funzt. (Zweifel)

Ein RAID10 mit eff. 6 SSDs sollte auch für mehrere Server jederzeit ausreichend hurtig, jedenfalls nicht der Flaschenhals des Systems sein. 

[#3]

Interessant wird es nach einem DATEV-Umzug auf ein solch performantes System. Ich hatte einen Server als HyperV, 2 RAIDs, 1x für den HV selbst und 1x für das Storage / die VMs. Unter Windows konnte ich mit min. 2GB/s von RAID A nach B kopieren. 

DATEV auf dem System fühlte sich an, wie Kaugummi. Klar, es war OK. Keine Frage aber so ein riesen Unterschied bestand zu anderen, älteren Systemen doch nicht. Und nein, es war nicht die CPUs. Da waren ebenfalls Server-unübliche hohe-GHz-CPUs drin, so wie DATEV das gerne möchte. 

Und allein die DATEV SQL ist eigentlich von den Zugriffen zu vernachlässigen, in meinen Augen. Es kommt stark drauf an, wie die Systeme miteinander reden. Client-Server oder doch RDS? Auf einem echt lahmen Server läuft DATEV auch echt lahm bei einem Mandaten; angeschlossen ist aber ein Windows Client mit DATEV installiert. Da geht DATEV ratzfatz auf, auch wenn der DATEV SQL Server an sich eher nicht der Hit ist dank HDD RAID5 und lahmer CPU. 

Bzgl. der NTFS Clustergröße steht in der Info-DB Windows Server 2019 oder Windows Server 2016 einrichten unter Punkt 3.1, 16KB Clustergröße auf der Festplatte, auf der die WINDVSW1 Freigabe liegt. Soll wohl laut meinem Kollegen tatsächlich spürbar sein, weil Windows standardmäßig einen anderen Wert drin hat. 

[#4]

Windows Server 2019 oder Windows Server 2016 einrichten

http://www.datev.de/lexinform-infodb/1070547

3.4.3 Energiesparmodi deaktivieren ...

sollte nicht ignoriert werden. (im Windowsstandard auch bei Servern direkt aus der Dose immer aktiv!). Es vermeidet wenig, kostet aber definitiv (DATEV-)Performance, man staunt!

[#5]

"Bzgl. der NTFS Clustergröße steht in der Info-DB Windows Server 2019 oder Windows Server 2016 einrichten unter Punkt 3.1, 16KB Clustergröße auf der Festplatte, auf der die WINDVSW1 Freigabe liegt. Soll wohl laut meinem Kollegen tatsächlich spürbar sein, weil Windows standardmäßig einen anderen Wert drin hat. "

Danke schon mal für die Antworten, das ist eine sehr gute Info.
NTFS hat standardmäßig 4KB Clustergröße eingestellt, SQL betreibt aber per default ein 8x8 Mapping, weshalb generell 64KB als optimale Clustergröße für die Partition mit der DB empfohlen wird um die Schreibzyklen zu minimieren. Dieser Wert scheint nach meinen Recherchen in den letzten Tagen auch immer noch der aktuell empfohlene zu sein. Es kann sein dass die DATEV eine abgespeckte bzw. proprietär konfigurierte SQL Variante betreibt (hatte glaube ich gelesen das es MS SQL Express ist...bin mir aber nicht sicher), evtl. deshalb die 16KB Empfehlung von der DATEV. Das zu testen wird schwer da man hierbei für das Benchmark immer komplette DATEV Installationen bräuchte.

Aber sicher ist dass der Kollege mit der Feststellung richtig liegen muss, die 4KB Standard bremsen sicherlich. Damit steht schon mal fest das die Partition für WINDVSW1 eine Clustergröße zwischen 16 und 64 KB bekommt. Die Frage ReFS vs. NTFS stellt sich bei mir nicht, da ich kein HyperV sondern ESXi betreibe und die Storage-Technologien wie dedup usw. auf anderer Ebene und nicht im File-System gelöst werden. Damit verliert bei mir ReFS die Vorteile gegenüber NTFS - und im zweifel tendiere ich persönlich eh zur bewährten Technologie. Auch über die Stabilität (Gesundheit) des ReFS im Langzeitbetrieb habe ich in den letzten Tagen eher negatives als positives gelesen. Somit steht der Rahmen für die Konfiguration vom SQL Guest-System bei uns fest. Jetzt bleibt zu klären wie die Cluster- bzw. Stripe-Sizes im Unterbau zu wählen sind. Die letzten Wochen Recherche bringen kaum Fortschritt, da es diesbezüglich sehr widersprüchliche Aussagen gibt. Das wiederum kann man aber sehr gut und unaufwendig testen, und genau das mache ich in den kommenden Tagen nebenbei da ich sonst an dieser Stelle nicht weiterkomme. Gerne teile ich die Ergebnisse dann im Anschluss. Hat jemand Erfahrung mit einem guten Benchmark-Tool für Storage, ich habe in der Vergangenheit nur mal Intel's Iometer und Crystalmark benutzt, kennt jemand dafür etwas besseres? 

[#6]

---

@epictax  schrieb:

Es kann sein dass die DATEV eine abgespeckte bzw. proprietär konfigurierte SQL Variante betreibt (hatte glaube ich gelesen das es MS SQL Express ist...bin mir aber nicht sicher), evtl. deshalb die 16KB Empfehlung von der DATEV.

---

Das kommt drauf an. Mandanten mit eigener DATEV Installation erhalten immer den SQL Express, der auch nur 1 Sockel und 4 Kerne (afaik) unterstützt und auch nur SQL Datenbanken < 10GB unterstützt. Wird die Datenbank größer, kann man bei DATEV den SQL Standard beantragen und gegen den Express tauschen. 

Kanzleien erhalten immer den SQL Standard, weil insbesondere die REWE Datenbank bei derart vielen Mandaten schnell anwächst. Unsere ist aktuell 185GB groß (afaik). Der SQL Standard kann dann aber mehr als 1 Sockel und auch ordentlich RAM nutzen.  

[#7]

Viel Interessanter ist nach den "best practises" von VMWare die Aufteilung der Maschinen auf mehrere Storages, hier lassen sich wesentliche Optimierungen erreichen als "ein Storage für Alles".

Die Schreib-/Leseleistung ist ohnehin nur wichtig bei größeren Dateien, bei den kleinen Häppchen , die DATEV in Massen produziert, ist diese Leistung zu vernachlässigen. Wichtig sind dabei wieder die Latenzen welche in Abhängigkeit zu dem verwendeten Controller stehen (Cachegröße, NCQ).

Für VMWare ist die virtuelle Platte ohnehin nur ein Container, das darauf laufende Betriebssystem "sieht" das emulierte Filesystem. Wie jetzt VMWare mit den Containerdaten umgeht oder was direkt aus dem Cache bedient wird lässt sich schwer beeinflussen, Ausnahme ist der Effekt bei großen Dateien.

[#8]

Hi,

---

Danke schon mal für die Antworten, das ist eine sehr gute Info.

NTFS hat standardmäßig 4KB Clustergröße eingestellt, SQL betreibt aber per default ein 8x8 Mapping, weshalb generell 64KB als optimale Clustergröße für die Partition mit der DB empfohlen wird um die Schreibzyklen zu minimieren. Dieser Wert scheint nach meinen Recherchen in den letzten Tagen auch immer noch der aktuell empfohlene zu sein. Es kann sein dass die DATEV eine abgespeckte bzw. proprietär konfigurierte SQL Variante betreibt (hatte glaube ich gelesen das es MS SQL Express ist...bin mir aber nicht sicher), evtl. deshalb die 16KB Empfehlung von der DATEV. Das zu testen wird schwer da man hierbei für das Benchmark immer komplette DATEV Installationen bräuchte.

DATEV verwendet den Microsoft SQL. Bei Mandanten i.d.R. den Express. Sofern die Beschränkungen (meist DB-Größe über 10GB) nicht ausreichen, kann bei DATEV auch der "normale" SQL eingesetzt werden. 

Microsoft SQL Server Express Edition nach Standard-Edition wechseln

Zudem könnte auch ein eigener SQL eingesetzt werden.

Selbst lizenzierten Microsoft SQL Server für DATEV-Programme verwenden

Grüße

Chr.Ockenfels

[#9]

Bzgl. Write-Back und Write-Through würde ich das fertige System auch noch einmal benchmarken. Bei SSD-RAIDs wird an vielen Stellen im Gegensatz zu Magnetplatten-RAIDs empfohlen, Write-Through zu verwenden (mehr IOPS). Dann kann man sich auch die BBU sparen, wenn man Platten mit Power Loss Protection einsetzt, was bei den Server SSDs in der Regel der Fall ist.

Wegen der Stripe-Size habe ich auch schon oft und lange recherchiert - bis jetzt aber ohne die ultimative Antwort. Ist auch schwierig, da auf dem ESXI ja unterschiedliche "Anwendungstypen" laufen (SQL, Exchange, RDP Server usw.). Von daher verwende ich im Zweifel die Defaults des Controllers.