SSD im (DATEV)-Server - mögliche Hardware und Erfahrungen

[#1]

Wir werden in den nächsten Tagen einen neuen Host-Server benötigen, welcher auch neben zwei potenten CPU´s und reichlich RAM mit einer SSD bestückt werden soll, auf der die virtuellem Maschinen des Fileservers und des WTS abgelegt werden. Die Kaufempfehlungen der DATEV verweisen hier hier nur auf eine SSD-Option ohne konkretere Ausführungen. Daher stellen sich einige Fragen, wenn man sich etwas tiefer mit der Materie beschäftigt. Da es bei diesem Thema sicherlich nicht nur mir so geht würde ich hier gerne einen Erfahrungsaustausch zu diesen Fragen eröffnen...

- welche SSD sind so im Einsatz? Mit welchen Erfahrungen?

- Consumer-SSD vs. Server-SSD: Freigaben - Hersteller - Performance - Preis - Server-Neukauf oder nachträgliches Upgrade

- Schnittstellen: SATA vs. PCIe als AddInCard oder U.2? Oder M.2 mittels Adapterkarte?

- SSD und RAID: Bei SATA kein Problem. Bei PCIe auch? TRIM-Befehl im RAID? SSD ohne RAID bei täglicher Datensicherung?

- Datenmenge: wie viele GB werden so erfahrungsgemäß auf einem FS bzw. WTS am Tag geschrieben?

- Lebensdauer und reale Ausfälle

[#2]

Client- Server, 10 Arbeitsplätze:
Hier fiel die Entscheidung für die Samsung- Pro- Linie aus folgenden Gründen:

- Preislich akzeptabel und qualitativ sehr gute Noten (ausgereiftes Produkt)
- Da die Boards kein SATA3 unterstützen, kommt es nicht auch die maximale Geschwindigkeit von Server- Platten an.

- RAID 1 am Server ist ein MUß, da jedes Bauteil ausfallen kann, und bei der Platte dann die Daten weg sind.

- Die PRO- Linie hat mehr als ausreichend Schreibzyclen

- Bei der jetzigen Entwicklung kommt es preiswerter, alle 2 Jahre die Comsumer- Platte zu tauschen, als auf einer teuren zu kleinen Server- Platte zu sitzen. -> Bei RAID 1 ist der Tausch der Platten ein Kinderspiel.

Status heute:

- keinerlei Ausfälle

- Pro Jahr vielleicht 1 Prozent Verbrauch der möglichen Schreibzyclen. (Am Client in einem Jahr max. 2 TB geschrieben)

- Server: konstante Performance, obwohl das TRIM ignoriert wird (Raid 1)

Hier wurden Drehscheiben durch SSD getauscht, und die schnellen Zugriffszeiten lassen sowohl am Client, als auch am Server alles einfach schneller reagieren, so daß allein die kürzeren Update- Zeiten für den Admin die Investition rechnen.

Interessant, daß z.B. beim Einspielen von Rewe- Beständern die Prozessorlast am Server gegen 50% steigt, so daß jetzt die CPU zum Nadelöhr wird. (Früher zeigte der Prozessor kaum Last)

Auch den schnellen PC- bzw. Programmstart möchte niemand mehr missen.
Auch bremsen sich die Mitarbeiter nicht gegenseitig aus, so daß beim Einspielen eines Rewe- Bestandes die Kollegen normal weiter arbeiten können.

[#3]

Ich kann von 2 Fällen berichten, wo der "EDV Dienstleister" meinte Consumer SSDs (Samsung Pro waren das) im virtualisierungs Host sind vollkommen i.O. In den beiden Fällen sind dann aber auch die Consumer SSDs im RAID 1 gleichzeitig ausgefallen. Das sowas natürlich auch mit Server SSDs passieren kann ist klar, aber in meinem Fall noch nicht vorgekommen.

Zum Einsatz kommen entsprechende SSDs, die der Serverhersteller passend zum Server anbietet.

Und generell lässt sich zur Hardware mit "potenten CPUs" und "reichlich RAM" nicht viel sagen ohne die Rahmenbedingungen bzw. Fakten zu kennen.

[#4]

Konnte die Ursache oder der Auslöser des Ausfalls gefunden werden?
- SSDs anschließend physikalisch defekt, oder 'nur' Daten beschädigt?

- Ausfall im laufenden Betrieb, bei Anwesenheit des Admins, oder bei einem Crash?

- Ausgeschlossen, daß andere Komponenten den Ausfall auslösten?

Mir geht es einfach darum, zu erkennen, wo Risiken trotz Raid 1 bestehen, um diese realistisch einschätzen zu können.

Vergleich PKW. Wenn ich die Staustrecke München Tegernsee fahre (Analog: SATA2- Anschluß an einem älteren Server), dann ist es eigentlich egal, ob ich Ferrari, oder Golf fahre. Beides ist aber um Welten flexibler als die Bahn (Zugriffszeiten bei Drehplatten). Ein teurer Hardware- Upgrade auf SATA3 und Server- Platten würde in diesem Fall nur wenige Prozent Gesamtperformance bringen.

[#5]

Das ein kompletter RAID-Verbund gleichzeitig aussteigt ist aber schon heftig. Aber dafür werden ja noch regelmäßig (mehrfach) Sicherungen gefahren. Neben einem normalen taglichen Backup aus der VM heraus auf ein NAS kommt bei uns noch die tägliche Sicherung über die DaSo. Zusätzlich würde ich die kompletten VM´S noch jede Nacht auf HDD´s sichern lassen.

Das mit dem Einsatz von nur einer SSD hielt ich beim lesen des entsprechenden Beitrages auch für mächtig gewagt, wollte aber einfach auch mal wissen, wie die Meinungen dazu so stehen. Habe selber aber auch noch keinen Server gesehen, in dem kein RAID lief.

Bei einem Server-Board von Intel kommen dann wohl zu 95% nur Intel-SSD´s der DC-Serie in Frage, überwiegend aber mit SATA-Schnittstelle. Leider gibt es nur ein paar wenige mit PCIe-Schnittstelle, welche über NVMe angesprochen werden. Bezogen auf einen neu aufzubauenden Server, welcher beide Schnittstellen voll unterstützt: Lohnt sich dieser Mehraufwand überhaupt und ist der Geschwindigkeitsvorteile einer DC P3700 gegenüber einer DC S3610 spürbar? Bei einem älterem Server stellt sich diese Frage sicherlich nicht...

Die sonstige Hardware hab ich jetzt nicht weiter beschrieben da es sich hier eigentlich mehr um das Thema SSD dreht. Aber momentan stehen 2 x E5-2643V4 oder 2x E5-2667V4 auf der Wunschliste, dazu noch 96GB DDR4-2600 auf nem Intel S2600CW2SR...

[#6]

Die Kanzleien wurden von uns nur bzgl. DATEV betreut. Der Rest wurde von anderen "Dienstleistern" "erledigt".

Ursache: 2 defekte SSDs; Ob physikalisch defekt oder "nur" Daten kann ich nicht sagen; Ausfall im Betrieb (Datenverlust von x Stunden); kein Admin vor Ort; Ich würde eine andere Quelle ausschließen.

Mittlerweile steht in beiden Kanzleien ein "Markenserver" mit entsprechender Hardware.

Und die Hardware-Wunschliste basiert auf welchen Anforderungen bzgl. Verfügbarkeit / tolerierbarem Datenverlust / ...

Aber das würde wohl den Rahmen der Community sprengen.

[#7]

Moin,

zunächst sollte einmal mit dem Unterschied SATA/PCIe aufgeräumt werden. PCIe ist das Bussystem über welches die Daten von den Schnittstellen zum Prozessor laufen, SATA ist eine Protokollschnittstelle. Mit anderen Worten: Was über SATA von der Platte kommt, wird vom Controller übersetzt und auf den PCIe Bus zum Prozessor/Hauptspeicher geschickt.

- Also 1.: Schnellste und neuste Busversion für den Server auswählen.

Wie gesagt, es ist egal, ob die Platten über SATA, SAS oder, oder, oder an den Bus angebunden werden, entscheidend ist, mit welcher Bandbreite der Controller an den Bus angebunden ist. Ein Controller an einem x16 Port kann schneller sein als ein Boardeigener SATA Port.

- Also 2.: Ein extra Controller kann eine höhere Bandbreite als ein boardeigener Controller bieten.

Sollte ein RAID Verbund geplant werden muss dieser auch verwaltet sein. Ein gesonderter Controller (LSI oder Adaptect z. B.) hat dafür einen eigenen Prozessor, das Motherboard des Servers verwendet den "normalen" Prozessor für die Verwaltung.

- Also 3.: Ein extra Controller bietet Entlastung bei einem RAID Verbund (ab 5 aufwärts).

Ein RAID Verbund ist ein empfindliches Wesen, geht der Controller kaputt, benötigt man bei einem boardeigenen Controller meist ein Motherboard mit genau dem Controller, der den Geist aufgeben hat. Bei externen Controllern passt das Protokoll meist auch bei anderen Produkten eines Herstellers.

- Also 4.: Ein externer Controller bietet Sicherheit.

Bei Anschaffung des Gesamtsystems sollte überlegt werden, wie der Zuschnitt aussehen soll. Welche Komponenten benötigen wirklich Plattenpower und welche nicht. Baue ich den DC mit SQL und Fileserver usw. auf einem System auf, dann werde ich Performanceprobleme (und Sicherheitsprobleme) bekommen. Packe ich dann noch den kommServer drauf und am Besten noch den LiMaServer, dann gute Nacht.

- Also 5.: Planung der Maschinen spart Geld und bringt viel Leistung

Der SQL Server 2014 kann in der Standardversion 4 Sockel mit x Kernen nutzen. Bei der DATEV Nutzung wichtig, denn DATEV braucht viele Prozesse und jeder Prozess bindet einen Kern.

- Also 6.: Prozessorkerne können die Leistung erhöhen.

MSSQL greift sich den Arbeitsspeicher, wo er ihn bekommen kann. Läuft auf dem Server noch weiteres, dann kann der Cache knapp werden.

- Also 7.: Möglichst wenig andere Anwendungen auf dem SQL Server.

Die Daten im Cache des SQL Servers werden von diesem sehr effektiv verwaltet um eben Zugriffe auf die Platten möglichst zu vermeiden, bei Datenänderungen werden diese oft schon automatisch in den Cache geladen.

- Also 8.: Arbeitsspeicher bringt es.

Ist das Gesamtsystem gut organisiert, dann braucht es keine SSDs, diese bringen Performance, wenn viel geswappt oder viele Zugriffe erfolgen müssen. Ob der Fileserver meine Excel Datei nun in 10 oder 30Millisekunden ausliefert, kann mir egal sein. Eine SSD bringt also viel, wenn das Gesamtsystem nicht optimal designt ist. Wobei DATEV den SQL Server auch nicht optimal nutzt. An der Schriftguterstellung kann man gut ersehen, dass viele Prozesse suboptimal laufen und durch SSDs auch nicht beschleunigt werden können. Das Geld für SSDs würde ich eher in Kerne und Hauptspeicher stecken sowie Lizenzen für ServerBS um virtualisiert mehr Maschinen zu haben.

Gruß

KP

[#8]

Bei einer vernünftigen Planung sollte sich unter anderem ergeben, ob man die benötigte "Disk Performance" durch eine Anzahl X an herkömmlichen HDDs bekommt oder ob es nötig ist eine Anzahl Y an SSDs zu verbauen.

Es könnte ja auch durchaus interessant sein, das "Back-End" auf HDDs zu betreiben und für die Terminalserver die ein oder andere SSD ins Array / den Server zu stecken.

Und mit einem Ausblick auf Server 2016 würde ich drauf achten, dass meine (zwei) CPUs nicht mehr als 8 Kerne pro CPU haben

[#9]

Und mit einem Ausblick auf Server 2016 würde ich drauf achten, dass meine (zwei) CPUs nicht mehr als 8 Kerne pro CPU haben

Ist zwar Off Topic, aber mittels Softwareinsurance lässt sich die Corebeschränkung bei 2016 umgehen. Muss bis 31.12.2016 abgeschlossen werden. Mein Hardwarehändler hatte das in seiner letzten Werbemail mitgeteilt.

[#10]

Generell ist es selten verkehrt die Win SRV mit SA zu erwerben und aktiv zu halten, da die DATEV sich ja vermutlich so schnell nicht vom Windows Server trennen wird

[#11]

Wie KP es schreibt: Bei einem gut ausgelegtem System merkt man tatsächlich (ausser beim Reboot) keinen Unterschied (aber das ist nicht von Interesse) zwischen SSDs und anderen schnellen SAS Platten im Betrieb.

Ich mache es immer noch "klassisch": Gesonderter wertiger RAID Controller Adaptec / LSI. Schnell drehende SAS Platten oder 2,5" SAS Platten.

RAID-Verbund ein wenig sinnvoll aufteilen z.B. HOST-OS auf RAID 1, Daten auf RAID 10, VMs auf jeweils gesonderte RAID 1 - so als Beispiel. Global-Hot-Spare dazu fertig.

OnBoard Controller für mich ein No-Go. Gründe sind oben genannt (Mainboard-Defekt).

[#12]

Man merkt keinen Unterschied zwischen drehenden HDDs und Flash

[#13]

Man merkt keinen Unterschied zwischen drehenden HDDs und Flash

Auf einem DATEV Server nicht!

Beim Start des AP werden zunächst die Daten vom SQL angefordert, in der Regel befinden sich die Daten im Cache des SQL Servers, also kein Zugriff auf die Platte, warum - siehe oben. Dann werden die Daten über das Netzwerk zum Client geschickt, also kein Plattenzugriff, wenn alle Daten am Client (ich hoffe der muss nicht swappen) wird gefiltert (der gute alte Desingnfehler), wieder kein Zugriff auf die Platte. Der erste Zugriff auf die Platte erfolgt beim Programmaufruf, und durch die Waitstates für LiMa Abfrage etc. ist eine Beschleunigung durch SSDs auf dem Server nicht feststellbar. Es geht hier ja immer noch um den Server.

SSDs haben immer Vorteile wenn kontinuierlich eine hohe Datenrate übertragen werden muss, nicht bei dem Gestückel welches DATEV Anwendungen benötigen (ein Videostream zum Bearbeiten ist nun einmal etwas Anderes als ein Buchungssatz oder eine Auswertung im Reportgenerator).

Auf einem Client kann es ganz anders aussehen.

[#14]

Ganz oben geht es um eine virtuelle Umgebung aus (DATEV) File und WTS. Da wäre ja der Client.

Evtl. sollte man nicht nur den (hier recht geschönten) Lesevorgang betrachten, sonder auch die Schreibvorgänge. In einer virtuellen Umgebung gibt es eine ganze Menge an verschiedenen Lese- / Schreibvorgängen (Und im DATEV Alltag gibt es ja neben den SQL Schreibvorgängen auch noch diverse andere Schreibvorgänge im Datei System).

Mit herkömmlichen HDDs lässt sich mit sicherheit eine performante DATEV Software betreiben, aber SSDs machen das ganze definitiv spürbar schneller.

[#15]

Zum Thema VM WTS SSD und Fileserver auf einer Hardware.

Nun JA auch wir setzen in der Kanzlei auf WTS mit SSD und VM und haben dort seit mehr als 18 Monaten gute Erfahrungen gemacht.

Als Grundlage für die WTS setzen wir auf Fujitsu Primergy RX2540M1 mit SAS G12 SSD und 2x 10 GB/s LAN Karten. Die SSD sind als RAID Verbund verbaut. Dieses System setzen wir redundant ein um einen möglichen Ausfall zu vermeiden.

Um die Ausfallsicherheit weiter zu erhöhen haben wir uns dagegen entschieden den Fileserver mit den WTS auf die selbe Hardware zu legen. Die Leistung ist nicht das Problem gewesen.

Beim Fileserver setzen wir auch auf  Fujitsu Primergy RX2540M1 hier allerdings auf klassische HDD mit 15 K Drehzahl ( 7x 580 GB ) auch als RAID mit SAS G12 und cache controller mit eigener CPU. Auch hier setzen wir auf 2x 10 GB/s LAN Karten.

Um ausreichend CPU Leistung für alle Systeme zur Verfügung zu stellen haben wir  pro Hardware für x2 Intel Xeon E5-2637v3 mit DDR4 RAM entschieden.

Da hier die weiter eingesetzten Server keine Rolle spielen gehe ich darauf auch nicht weiter ein.

Wir haben festgestellt, dass nur eine Kombination aus schnellem LAN ( Server sind alle mit 2x10 GB/s angebunden) und großem Datendurchsatz bei den eingesetzten SSD oder HDD Laufwerken zu einem deutlichen Leistungsschub geführt haben.

Bei der Kombination von Fileserver und WTS auf einer Serverhardware kann man die Konfiguration auch so wählen, dass die eine VM mit den WTS auf SSD zugreift und der Fileserver in der anderen VM auf normale HDD zugreift. Ich würde bei der Datenübertragung auf SAS G12 und nicht auf G6 setzen hier zählt Leistung.

Wenn die Preise für SAS Systeme abschrecken, kein Problem, wir haben bei unserer letzten Hardwarebestellung mal über den DATEV Tellerrand hinaus geblickt, es war sehr lehrreich ;-). Man kann z.B.: auch beim TK Anbieter fragen ( diese können weit größere Stückzahlen abnehmen und der Rabatt ist entsprechend) oder direkt beim Hersteller anfragen.

Zusammenfassung:

18 Monate SSD im WTS Einsatz keine Probleme, System auch mit DATEV schnell.

Fileserver keine SSD aber mit SAS G12 HDD auch schnell genug nur beim SQL Zugriff haben wir jetzt festgestellt, wir haben zu wenig RAM verbaut.