Neu SQL Konfig - Raid ja oder nein?

[Martin Mallorca]

Moin allerseits von der Insel!

Ich bin gerade an der Erstinstallation und mir stellt sich schon die erste Frage:

Ich installiere den SQL Server auf einem neu aufgebauten Windows 10 PC und das MB hat 4 SATA Anschlüße (noch kein M2 MB)

Ich habe 4 SSDs verbaut.

laut JTL Installationjsanleitung soll ich idealerweise wie folgt installieren

Richten Sie Ihr System wie folgt ein:

• Installieren Sie auf dem verwendeten Computer neben dem Betriebssystem nur den SQL-Server.
• Festplatte 1: Installieren Sie den SQL-Server auf derselben Festplatte, auf der auch das Betriebssystem installiert ist.
• Festplatte 2/3: Speichern Sie sowohl die .mdf-Datei als auch die .log-Datei auf getrennten Datenträgern.
• Festplatte 4: Wählen Sie als Speicherort der Temp-DB ebenfalls eine eigene, idealerweise die schnellste Festplatte.

Halte ich mich daran kann ich kein internes RAID mehr einrichten.

Geht Datensicherheit nicht vor Geschwindigkeit? oder installiert dann nochmal zusätzliches Platten als externes RAID?

Ich dachte ursprünglich an eine 2 x RAID 1 Konfiguration...

oder macht ihr einfach alle paar Stunden ein Backup auf ein NAS ohne RAID?

kurz- mittelfristig werden wir mit 2-3000 Produkten arbeiten langfristig maximal ca. 8000

Vielleicht kann mir da ja einer weiter helfen welches die ideale Lösung für mich ist oder mit welcher Konfiguration Ihr die besten Erfahrungen gemacht habt.

Danke für euren Input.

Grüße!

 

[SebiW]

Naja, ob Du auf einem System, dass nur 4 Platten unterstützt, einen massiven Geschwindigkeitsvorteil durch das Aufteilen der SQL Dateien haben wirst ist eher unwahrscheinlich.
Das Vorgehen stammt auch eher noch aus der vor SSD Zeit. Natürlich macht das bei großen Clustern auch weiterhin Sinn, dann laufen die Platten aber auch nicht auf nemm Consumer Board sondern über dedizierte Hardware.
Insofern gilt auch: Inwieweit ein typischer Windows Software Raid Sinn macht sei dahingestellt.

Wenn es um Datensicherheit geht heisst das Zauberwort Backup, nicht Raid. Raids dienen der Verfügbarkeit, Backups der Datensicherheit. Und alle paar Stunden bedeutet: Hast Du einen defekt ist im schlechtesten Fall alles der letzten paar Stunden weg. Speicherplatz ist billig, Datenverlust teuer.

 

[Thomas_T]

4 gleichgroße SSD-Platten? Mach einen Raid 10 und gut ist (wenn die Platten was taugen)

 

[Martin Mallorca]

Naja, ob Du auf einem System, dass nur 4 Platten unterstützt, einen massiven Geschwindigkeitsvorteil durch das Aufteilen der SQL Dateien haben wirst ist eher unwahrscheinlich.
Das Vorgehen stammt auch eher noch aus der vor SSD Zeit. Natürlich macht das bei großen Clustern auch weiterhin Sinn, dann laufen die Platten aber auch nicht auf nemm Consumer Board sondern über dedizierte Hardware.
Insofern gilt auch: Inwieweit ein typischer Windows Software Raid Sinn macht sei dahingestellt.

Wenn es um Datensicherheit geht heisst das Zauberwort Backup, nicht Raid. Raids dienen der Verfügbarkeit, Backups der Datensicherheit. Und alle paar Stunden bedeutet: Hast Du einen defekt ist im schlechtesten Fall alles der letzten paar Stunden weg. Speicherplatz ist billig, Datenverlust teuer.

danke für die Meinung. Aber ein bissichen Widerspruch war das ja jetzt schon Ich habe doch bei einem RAID eine höhere Datensicherheit für die effektive Funktionalität da es eben keinen temporären Ausfall geben kann. Das Backup ist doch quasi ein Zusatz - das Hilft mir ja an dem Betriebstag im Moment des Ausfalls nicht weiter.
Aber wahrscheinlich auch eine Wortauslegung je nach Zusammenhang. Ich tendiere aber auch so eher zum Raid. Aber hat mir trotzdem erstmal weiter geholfen. Danke

 

[Martin Mallorca]

4 gleichgroße SSD-Platten? Mach einen Raid 10 und gut ist (wenn die Platten was taugen)

nein 2 x 512 und 2 x 128

 

[sebjo82]

Naja, ob Du auf einem System, dass nur 4 Platten unterstützt, einen massiven Geschwindigkeitsvorteil durch das Aufteilen der SQL Dateien haben wirst ist eher unwahrscheinlich.
Das Vorgehen stammt auch eher noch aus der vor SSD Zeit. Natürlich macht das bei großen Clustern auch weiterhin Sinn, dann laufen die Platten aber auch nicht auf nemm Consumer Board sondern über dedizierte Hardware.
Insofern gilt auch: Inwieweit ein typischer Windows Software Raid Sinn macht sei dahingestellt.

Wenn es um Datensicherheit geht heisst das Zauberwort Backup, nicht Raid. Raids dienen der Verfügbarkeit, Backups der Datensicherheit. Und alle paar Stunden bedeutet: Hast Du einen defekt ist im schlechtesten Fall alles der letzten paar Stunden weg. Speicherplatz ist billig, Datenverlust teuer.

RAID bietet Datensicherheit und ist essentieller Bestandteil einer soliden Speicherstrategie

 

[Martin Mallorca]

RAID bietet Datensicherheit und ist essentieller Bestandteil einer soliden Speicherstrategie

Ich bin ja eigentlich nur von der JTL Anleitung irritiert das auf die 4 Platten hingeweisen wird um die unterschiedlichen SQL Files zu speichern aber von RAID nirgends die Rede ist obwohl es ja eigentlich wesentlich wichtiger ist.

 

[MichaelH]

Wieviele PCs hängst du an den Server und wie viele werden gleichzeitig arbeiten - dies bestimmt die Auslegung deines Servers ...

Ansonsten bezüglich Sicherheit SQLBACKUPANDFTP mit seinen Möglichkeiten nutzen, lokal speichern und / oder über FTP sichern, das kannst du sogar alle 15 Minuten machen + RAID, dann bist du ziemlich sicher mit deiner DB und darum geht es ja.

 

[SebiW]

RAID bietet Datensicherheit und ist essentieller Bestandteil einer soliden Speicherstrategie

Nein. Raid bietet wie der Name schon sagt Redundanz. Fällt eine Platte aus kann der Betrieb im Optimalfall ohne Unterbrechung fortgesetzt werden. Gleichzeitig bringen Raidsysteme aber auch ganze eigene Probleme mit sich.

Funktion eines Backups ist die komplette Wiederherstellbarkeit eines Systems, notfalls auf völlig anderer Hardware an einem beliebigen anderen Standort. Das kann Raid nicht.

Oder schön einfach erklärt: https://www.raidisnotabackup.com/

Auf Raid kann man verzichten. Auf Backups nicht.

 

[sebjo82]

Nein. Raid bietet wie der Name schon sagt Redundanz. Fällt eine Platte aus kann der Betrieb im Optimalfall ohne Unterbrechung fortgesetzt werden. Gleichzeitig bringen Raidsysteme aber auch ganze eigene Probleme mit sich.

Funktion eines Backups ist die komplette Wiederherstellbarkeit eines Systems, notfalls auf völlig anderer Hardware an einem beliebigen anderen Standort. Das kann Raid nicht.

Oder schön einfach erklärt: https://www.raidisnotabackup.com/

Auf Raid kann man verzichten. Auf Backups nicht.

Wenn du deine Datenbank auf einer einzelnen Festplatte laufen hast, dann gute Nacht. Keiner sagt, dass man keine Backups machen soll, aber wenn du kein RAID nutzt, wirst du häufiger auf Backups zurückgreifen müssen

 

[Verkäuferlein]

Ich installiere den SQL Server auf einem neu aufgebauten Windows 10 PC und das MB hat 4 SATA Anschlüße (noch kein M2 MB)

Ich habe 4 SSDs verbaut.

Man weiß ja viel zu wenig über Hardware, Clientanzahl, SQL-Lizenz, etc.

Grundsätzlich würde ich aber mal behaupten, brauchst Du dieses "Feintuning" nicht, weil vermutlich schon die sonstige Hardware die mögliche Leistung der SSDs gar nicht wirklich ausschöpfen kann, insbesondere wenn auf mehrere verteilte gleichzeitig zugegriffen wird. Mach da ein schickes Raid (bei 4 SSD bieten sich ja mehrere Varianten zur Auswahl) draus unterteil das nach Betriebssystem- und Daten-Partionen und in der Regel hast Du dann schon eine ganz gute Konfiguration.

Wenn die SSD insgesamt möglicherweise teurer sind, als die restliche Hardware, wird ein Flaschenhals vermutlich eher woanders entstehen.

Zum Thema Raid:
Im Idealfall kannst Du halt trotz Ausfall einer SSD weiterarbeiten und brauchst nur eine defekte SSD austauschen und es läuft alles weiter. Da geht's also mehr um Datensicherheit im Sinne von Verfügbarkeit.

Die Datensicherung (Backup) sorgt dann je nach Ausbaustufe dafür, dass Du bestimmte Risiko-Szenarien umschiffen kannst und dafür auch eine Lösung parat hast (ggf. mit einer längeren Ausfallzeit).

Bei mir steht es 1:1, einmal hat das Raid das Einspielen von Backups erforderlich gemacht und ausgelöst und einmal hat das Raid dafür gesorgt, dass dies nicht erforderlich war. Zieht man das als statistisches Beispiel heran, ist es egal, ob Du eins hast oder nicht. Aber wie heißt es so schön: Haben ist besser als brauchen.

 

[Martin Mallorca]

Wieviele PCs hängst du an den Server und wie viele werden gleichzeitig arbeiten - dies bestimmt die Auslegung deines Servers ...

Ansonsten bezüglich Sicherheit SQLBACKUPANDFTP mit seinen Möglichkeiten nutzen, lokal speichern und / oder über FTP sichern, das kannst du sogar alle 15 Minuten machen + RAID, dann bist du ziemlich sicher mit deiner DB und darum geht es ja.

Ich denke wir werden mittelfristig nicht mehr als 4 Clienten dran hängen. Backup auf FTP wird auf jeden Fall gemacht. glaube habe da noch einiges an Speicher bei unserem Hoster. SQL Express ich denke Standard ist raus geworfenes Geld am Anfang. Das kann man imme rnoch machen wenn wirklich Bedarf ist.

 

[recent.digital]

Ich denke wir werden mittelfristig nicht mehr als 4 Clienten dran hängen. Backup auf FTP wird auf jeden Fall gemacht. glaube habe da noch einiges an Speicher bei unserem Hoster. SQL Express ich denke Standard ist raus geworfenes Geld am Anfang. Das kann man imme rnoch machen wenn wirklich Bedarf ist.

Die Backups auch gerne mal prüfen, testweise einspielen etc.

Beim SQL Standard die Lizenzierung gut geplant angehen, weil da schnell ein Lizenzmangel entstehen kann.

 

[SebiW]

Wenn du deine Datenbank auf einer einzelnen Festplatte laufen hast, dann gute Nacht. Keiner sagt, dass man keine Backups machen soll, aber wenn du kein RAID nutzt, wirst du häufiger auf Backups zurückgreifen müssen

Es gibt zahlreiche Szenarien, in denen aufgrund eines Raidfehlers (Plattendefekte jenseits des Raidlevels, schleichende Plattendefekte, Defekt am Raidcontroller, Defekt am System das den Raid enthält, Fehler im Filesystem, unbeabsichtiges Löschen, bösartiges Löschen oder Verschlüsseln) Backups eingespielt werden müssen.
Es gibt keine realistischen Szenarien, in denen aufgrund eines Backupfehlers Raids einspringen müssen.

Nochmal: Raid ist für Verfügbarkeit, Backup für Sicherheit.
Raids hat man um im Falle eines Festplattenausfalls potentiell unterbrechungsfrei weiterarbeiten zu können.
Raids sind keine Backups. Backups hat man um IMMER, wenn auch mit Unterbrechung, weiterarbeiten zu können.

Und nochmal: Auf Raid kann man verzichten. Auf Backups nicht. Geht bei Daten ohne Raid was schief verliert man Zeit. Geht bei Daten ohne Backup was schief verliert man alles.

 

[JohnFrea]

Wieso eigentlich 4 identische Festplatten im RAID?
Macht es nicht mehr Sinn, auf gleich große Platten unterschiedlicher Hersteller zu setzen? Streut man nicht so die Wahrscheinlichkeit eines Ausfalls? Da gabs doch mal eine HDD Serie, die nach einer bestimmten Anzahl Betriebsstunden ausfiel. Wenn man davon mehrere im Raid hatte und die gleichzeitig in Betrieb genommen wurde...Gute Nacht.

 

[mh1]

Die Aufteilung der Dateien bei einem Datenbankserver auf verschiedene Laufweke ist darin begründet, dass das der Zugriff auf das Transktionsprotokoll (ldf) sequentiell erfolgt. Aber auf die Datendatei (mdf) wird zufällig zugegriffen.

Vor allem bei (sich drehenden) Festplatten, wo bei jedem Zugriff der Schreib-/Lesekopf entsprechend platziert werden muss, kann es sich drastisch auf die Performance der Datenbank auswirken, wenn man die Dateien auf verschiedene Laufwerke aufteilt. So hat man ein Laufwerk mit der ldf, wo der Kopf immer am Ende steht und einfach immer nur neue Daten hinten anhängt.
Und man hat ein separates Laufwerk, wo der Kopf lesend und schreibend hin und her springt.

Bei einer SSD ist das aber nicht mehr so interessant, da hier sowieso nur Speicheradressen angesprochen werden und keine Bauteile mechanisch platziert werden.

In großen Installationen werden Datenbankserver aber trotzdem dahingehend opimiert. Darum wird bei Enterprise SSD's meist im Datenblatt angegeben, ob sie für schreibende Zugriffe optimiert wurden, oder für "mixed mode".

Mit deinem SQL-Server mit ca. vier Clients wirst du aber meiner Meinung nach keinen Unterschied bemerken, wenn du auf verschiedene Laufwerke aufteilst.

 

[SebastianB]

Hi,

also: Die Angaben im Guide beziehen sich noch auf eine vergangene Zeit, in der Festplatten noch state-of-the-art waren. Das ist heute anders. Heute geht es um SSDs - wenn es geht, angebunden via NVMe - und damit ist ja die Idee von vielen Laufwerken eh vom Tisch...

Heute ist die Aufteilung der Daten insofern sinnvoll, als dass man schaut, dass man sich nicht gegenseitig die Platten vollschreibt: Wenn z.B: der SQL Server die Platte vom OS komplett vollschreibt - oder andersrum - ist das ungünstig.

Aus Performance-Sicht ist die Anzahl der SSDs eher egal - ich glaub nicht, dass wir uns hier in der Liga bewegen, in der das wirklich im Betrieb feststellbare Unterschiede macht. Da gibt es andere Stellschrauben (RAM, Anbindung des Datenspeichers, Software-Konfiguration des Systems) die vermutlich deutlich mehr bewirken als die Anzahl der Festplatten: Wenn ich statt 4 SATA SSDs eine große NVMe SSD nehme, wird das System vermutlich am Ende schneller sein.

Zum RAID:
Da bin ich auf der Seite: Ein RAID hat nix mit Datensicherheit zu tun: Datenverlust entsteht ja nicht nur durch defekte Festplatten / SSDs, sondern auch durch Probleme und Bugs in Treibern, in der Firmware und auf sonstigen Ebenen: Und ein Setup mit RAID ist nunmal komplexer als ein Setup ohne RAID - ich kenne keinen empirischen Daten, aber mich würde es nicht wundern, wenn unterm Strich die Anzahl der Fälle, in denen man auf ein Backup angewiesen ist, zwischen RAID und non RAID sehr, sehr ähnlich ist.

 

[recent.digital]

Danke für die Aufklärung @SebastianB -die Energie sollte man in ein JTL-Backupkonzept stecken.

Wir entwickeln gerade dazu auch einen entsprechenden Blog-Beitrag, damit diese wichtige Thematik auch für alle zugänglich ist.

 

[mh1]

Man sollte auch Bedenken, dass die Ausfallsicherheit beim RAID kein Automatismus ist, sondern erst dann so richtig in die Praxis umgesetzt wird, wenn das RAID auch im Blick behalten wird. Also es muss die Manpower bzw. das technische Know How im Haus vorhanden sein.
Ich hab im Lauf meines Berufslebens schon mehrere kleinere bzw mittelgroße Firmen sehen wo sich eine Festplatte im RAID schon seit langer Zeit unbemerkt verabschiedet hat. Hilferufe des RAID-Controllers gingen z.b. per Email an eine Supportadresse des Dienstleuister, den es gar nicht mehr gab, oder gehen an den GF und werden dort als "wahrscheinklich nicht so wichtig" angesehen, oder oder...

 

[sebjo82]

gute Dashboards sind Gold wert