Macht ein RAID-1 aus SSDs bei einem Windows Server Sinn?

kawakawa

Experte
Thread Starter
Mitglied seit
21.07.2013
Beiträge
197
Hallo,

macht dieses Vorhaben bei einem Windows Server Sinn?:

Nämlich das Betriebssystem zwecks Verfügbarkeit auf ein RAID-1 aus zwei baugleichen SSDs zu legen? Das RAID-1 würde an einem Intel SATA Controller eines aktuellen Intel Cxxx Server Chipsatzes hängen.

Die Intel RST Treiber ermöglichen das TRIM auch bei RAID-0 und RAID-1 Umgebungen.

Was spricht also dafür, ein SSD RAID-1 für das Betriebssystem eines Windows Servers 2008 R2 oder höher zu verwenden?

Was spricht dagegen?

Oder fallen SSDs auf eine andere Weise aus, als HDDs, so dass ein RAID-1 aus SSDs keinen vernünftigen Sinn ergibt?

Würde gerne Eure Meinungen dazu hören, um eine Entscheidungsgrundlage zu haben. Der Grund für dieses Vorhaben ist, dass falls eine SSD ausfallen würde, der Serverbetrieb nicht unterbrochen würde und man einfach ein Rebuild auf eine neue SSD machen könnte.

Der Server läuft 24/7 ohne Pause.

Backups sind natürlich selbstverständlich. Sollen aber nicht zum Thema dieses Beitrags werden.

Der Server läuft auf einem Workstation/Server Mainboard mit IPMI, Xeon-CPU und 32 GB ECC-RAM. Der Server hängt an einer USV, welche bei Stromausfall ein geordnetes Herunterfahren ermöglicht.

Zu dieser Konfiguration soll nun eben ein passendes Setup für die Betriebssystempartition/Betriebssystem-Platte(SSD) gefunden werden.

Für die Daten-Partition(en) nutze ich z.B. ein RAID-6 an einem LSI Controller mit mehreren Enterprise NAS Festplatten. Aber hier soll es nur um das RAID für die Systempartition gehen.

Falls ich, so wie beschrieben, alles richtig geplant habe, wäre mir ebenfalls eine Bestätigung von Euch wichtig, damit ich weiß, dass das so OK ist.

Grüße
kawakawa
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich habe keine Ahnung, aber was erwartest du von dem Raid mit Windows?
Sie installieren auf jeder der beiden SSD je ein Windows. Klar
Aber wenn eine SSD ausfällt, warum sollte die andere dann übernehmen? Woher weiß sie das denn ??

MfG
 
Prinzipiell können SSDs genauso ausfallen wie Platten, nach meinem Empfinden sogar ähnlich oft. Enterprise SSD und - Platten meist seltener als billigere Desktop Exemplare. Ein Raid-1 verbessert da die Verfügbarkeit wenn eine Platte komplett ausfällt, da man dann unterbrechungsfrei mit der zweiten weitergearbeiten kann.

ABER

Ich kenne das auch so, dass es plötzlich Abstürze oder Bootprobleme mit einfacheren Raid gibt. Mit nur einer Platte bootet es dann. Bei einfacheren Raidcontrollern oder dem Onboard Raid gibt es z.B. das Write Hole Problem. Wenn beim Schreiben der Rechner abstürzt, kann es sein dass eine Platte aktualisiert wurde, die andere nicht oder nur teilweise oder beide teilweise. Das Raid ist dann inkonsistent oder das Dateisystem korrupt. Mit NTFS hat man mangels Prüfsummen dann nichtmal die Möglichkeit festzustellen, welche Platte gute und welche schlechte Daten hat. Gleiches passiert durch stille Datenfehler die mit einer statistischen Wahrscheinlichkeit auftreten. Bei normalen Systemplatten ist das aber noch nicht so relevant, wird erst im Multi-Terabyte Bereich zum echten Problem. Bei SSDs kommt dazu, dass die Firmware im Hintergrund ständig Daten optimiert. Ein Stromausfall kann da auch Daten verändern.

Wenn es sich um ein kritisches System handelt, dann kann man
- einen Hardware Raidcontroller mit Cache und BBU nehmen (verringert das Write Hole Problem bei Raid)
- ein Dateisystem mit CopyOnWrite nehmen sofern möglich (vermeidet das Write Hole Problem
und bringt Prüfsummen für eine damit mögliche Reparatur)
- SSD mit Powerloss Protection nehmen, z.B. Intel S3500
 
Zuletzt bearbeitet:
Prinzipiell können SSDs genauso ausfallen wie Platten, nach meinem Empfinden sogar ähnlich oft. Enterprise SSD und - Platten meist seltener als billigere Desktop Exemplare. Ein Raid-1 verbessert da die Verfügbarkeit wenn eine Platte komplett ausfällt, da man dann unterbrechungsfrei mit der zweiten weitergearbeiten kann.
Ich stehe gerade vor der gleichen Frage. Das ist auch meine Denke. Bei totalausfall einer SSD ist das Raid 1 nützlich. Aber wenn nur die Daten einer SSD korrupt werden, hilft das Raid 1 nicht. Im schlimmsten Fall werden dann die korrupten Daten verwendet und auf die gute SSD kopiert.

Meine eigene Erfahrung bisher war:

HDDs fielen komplett aus, was bei einem Raid 1 gut war, da der Fehler gleich bemerkt wurde. Oder machten sich mit Timeouts bemerkbar.

SSDs fielen bei mir noch nie komplett aus. Es gab immer "nur" korrupte Daten, die man dann irgendwann gemerkt hat, wenn das Betriebssystem wegen Fehlern in Systemdateien nicht mehr booten wollte.

Wenn es sich um ein kritisches System handelt, dann kann man
- einen Hardware Raidcontroller mit Cache und BBU nehmen (verringert das Write Hole Problem bei Raid)
- ein Dateisystem mit CopyOnWrite nehmen sofern möglich (vermeidet das Write Hole Problem
und bringt Prüfsummen für eine damit mögliche Reparatur)
- SSD mit Powerloss Protection nehmen, z.B. Intel S3500
Er schreibt, dass der Server an einer USV hängt. Das dürfte Cache, BBU, Speicherkondensatoren in der SSD überflüssig machen.

Durch einen Absturz verursachte Fehler kann eine USV nicht mindern. Aber das kann auch kein Cache, BBU oder Speicher-Elkos in der SSD.

Bin gespannt, ob noch weitere Aspekte sich in der Diskussion herausarbeiten...
 
Ich habe im Server 2 SSDs im RAID1 zur Ausfallsicherheit und 4 SSDs im RAID5 für Ausfallsicherheit, Kapazität und Performance. Bin damit zufrieden und läuft nun knapp über zwei Jahre ohne Probleme. Bei einem Windows Server würde ich jedoch auf ein Hardware Raid setzen....bin kein Fan von Software RAID und die CPU soll die VMs befeuern und keine Storage Paritäten berechnen/verarbeiten.


Zum Thema Cache und BBU. In einem anderen Thread habe ich es belegt, dass man nur mit abgeschalteten Write-Cache die volle Performance erhält. Auch LSI selber schreibt in deren Artikeln, die Funktion ausgeschaltet zu belassen. Diverse Tests im Internet belegen dieses Verhalten auch mit aktuellen SAS-12GB/s Controllern. Schau mal hier nach meinem Thread, wo ich 8x Samsung SSDs mit verschiedenen Settings getestet habe.

Von RAID6 wird bei SSDs abgeraten....wenn dann brauchst du schon SSDs, die viel unnötiges Schreiben vertragen...das wird dann aber gleich auch teuer. Zu dem habe ich bei IBM SANs die Erfahrung gemacht, dass RAID5 die richtige Wahl für SSDs ist....hier ist die Performance extrem hoch! Was mit HDDs früher ein Kompromiss war, wird mit neuer Technik neu definiert :)
 
Zuletzt bearbeitet:
Was spricht also dafür, ein SSD RAID-1 für das Betriebssystem eines Windows Servers 2008 R2 oder höher zu verwenden?
Auch bei SSDs spricht alles dafür, ein RAID 1 zu erstellen, um die Verfügbarkeit zu erhöhen.

Was spricht dagegen?
Nur die Tatsache, dass zwei SSDs natürlich mehr kosten als eine.

Oder fallen SSDs auf eine andere Weise aus, als HDDs, so dass ein RAID-1 aus SSDs keinen vernünftigen Sinn ergibt?
Nö.

Ich habe keine Ahnung, aber was erwartest du von dem Raid mit Windows?
Sie installieren auf jeder der beiden SSD je ein Windows. Klar
Aber wenn eine SSD ausfällt, warum sollte die andere dann übernehmen? Woher weiß sie das denn ??
So wie es aussieht hast Du wirklich keine Ahnung, wie ein RAID funktioniert...

Bei einem RAID 1 sieht Windows nicht beide SSDs einzeln, sondern nur den RAID-Verbund. Der RAID-Controller (bzw. in diesem Falle der Chipsatz) schreibt auf beide SSDs identische Daten, und wenn eine ausfällt, läuft das RAID weiter, ohne dass der Server ausfällt. Die defekte SSD kann dann ausgetauscht werden, die Daten werden im Hintergrund von der funktionierenden auf die neue kopiert und das RAID ist wieder funktionsfähig.
 
Ich habe im Server 2 SSDs im RAID1 zur Ausfallsicherheit und 4 SSDs im RAID5 für Ausfallsicherheit, Kapazität und Performance. Bin damit zufrieden und läuft nun knapp über zwei Jahre ohne Probleme. Bei einem Windows Server würde ich jedoch auf ein Hardware Raid setzen....bin kein Fan von Software RAID und die CPU soll die VMs befeuern und keine Storage Paritäten berechnen/verarbeiten.

Bei einem Windows Server mit ntfs würde ich auch auf ein Hardware Raid setzen. Das liegt aber daran dass die Softwareraids unter Windows nichts taugen. Ansonsten sehe ich keinen Nutzen mehr für Hardwareraid. Ein aktuelles Storagesystem mit 20 Platten, und einem Pool aus mehreren Raid-Z2 Arrays und 100TB liefert 600-800MB/s über SMB bei recht geringer CPU Last. CPUs sind heute für Echtzeit 3D tauglich, was macht da das bisschen Parity rechnen. Wirklich sicheres, großes, erweiterbares und schnelles Storage geht heute über gutes Softwareraid auf CopyOnWrite Dateisystemen.

Von RAID6 wird bei SSDs abgeraten....wenn dann brauchst du schon SSDs, die viel unnötiges Schreiben vertragen...das wird dann aber gleich auch teuer. Zu dem habe ich bei IBM SANs die Erfahrung gemacht, dass RAID5 die richtige Wahl für SSDs ist....hier ist die Performance extrem hoch! Was mit HDDs früher ein Kompromiss war, wird mit neuer Technik neu definiert :)

Bei halbwegs professioneller Nutzung mit SSDs sollte man vernünftige SSD mit Powerloss Protection wie z.B. Intel S3500 .. S3710 wählen. Die haben weder Probleme mit der Schreiblast (selbst bei intensiver Schreiblast, wenigsten nicht in den 5 Jahren die es halten soll) noch Probleme mit Garbage Collection als Background Task oder besondere Performance Probleme im Raid, egal welches Level.

Aus Sicht einer Platte gibt es auch keinen Unterschied zwischen Raid5 und Raid6. In letzterem Fall dürfen halt 2 Platten gleichzeitig ausfallen.
 
Zuletzt bearbeitet:
Er schreibt, dass der Server an einer USV hängt. Das dürfte Cache, BBU, Speicherkondensatoren in der SSD überflüssig machen.
NEIN, ein immer wieder gern geäußertes Märchen! Die USV schützt vor Netzseitigem Stromausfall, aber nicht vor einem defektem Netzteil oder einem BSOD.
Die USV kann keinen Cacheinhalt puffern, da der Controller ohne BBU einfach initialisiert wird z:B. nach einem BSOD. Mit BBU erkennt der Controller während der Initialisierung die nicht geschriebenen Daten im Cache und schreibt diese weg - bei kleinen Dateien durchaus erfolgreich, grosse Dateien (grösser als die Cachegrösse) sind im Regelfall verloren / zerstört, unvollständig


Problematischer ist, daß die Cachegrössen der Controller seit zig Jahren stagnieren und nicht an aktuellle Dateigrössen und Festplattengrössen angepasst wurden.
Die Plattencaches selbst sind zum Teil in der Summe grösser als die Controllercaches.
 
Zuletzt bearbeitet:
Ich würde zu Samsung SSD SM863 greifen. Die haben vernünftige TBW Werte und Power-Loss Protection. Eine 850 Pro als Enterprise SATA halt.

Zum RAID5 / 6 Vergleich. Bei RAID 6 wird unnötig mehr geschrieben. Zu dem ist die Aufgabe für den Controller schweißtreibender. Ich würde ein RAID 5 mit Hotspare vorziehen...geht auch aus IBM V5000 Dokumenten als Empfehlung hervor.

Der Cache beim Controller ist nicht schnell genug und zieht die Performance herunter...daher aus damit.


Zum Thema RAID 1. Neben der Ausfallsicherheit können auch die Daten gleichzeitig von beiden Festplatten gelesen werden. Das ergibt auch einen Mehrwert.
 
Kleine Ergänzung zu der Cache Problematik.

Wenn beim Schreiben einer großen Datei das System abstürzt, so ist die Datei kaputt.
Da hilft es nur, wenn das schreibende Programm z.B. Word eine Temp-Datei hat.

Es hilft aber bei Transaktionen.
Das Schreiben eines Datenblocks beinhaltet immer mehrere Transaktionen, z.B.
Datenblock schreiben + Metafiles aktualisieren. Hier hilft der Cache. Bei einem Absturz nach dem Schreiben des Datenblocks wird das Aktualisieren der Metadaten beim nächsten Boot nachgeholt. Die Datei ist zwar dennoch kaputt, das Dateisystem aber konsistent.

oder
Eine Datenbank für Finanztransaktionen. Da besteht eine Buchung aus dem Belasten eines Kontos und dem Gutschreiben auf ein anderes. Ein Absturz nach der ersten Buchung und die Buchhaltung stimmt nicht mehr da die Gutschrift verloren geht. Ein Cache kann solche Transaktionen auf der Ebene der tatsächlichen Daten absichern. Selbst eine transaktionssichere Datenbank braucht letztlich ein derart verlässliches Storage.

Also niemals Cache oder BBU ausschalten ausser der Controller taugt nicht. Der Cache ist auch nicht fürs Lesen, das kann das OS besser sondern als Schreibschutz - wobei auch das Softwareraid mit ZFS besser kann.

Ansonsten würde ich nie Raid-5 + Hotspare sondern immer Raid-6 oder ZFS-Z2 oder Z3 mit drei Redundanzplatten machen. Raid-5 eh nur mit ganz wenigen Platten - eigentlich garnicht mehr. Das bisschen mehr Last bei Raid6 für aktuelle CPUs ist vernachlässigbar. Die Gefahr eines zweiten Ausfalls beim Rebuild eines Raid-5 aber sehr real.

Mehr Daten zu schreiben ist auch nicht per se schlecht. Wenn das Redundanzdaten sind oder bei bei ReFS oder ZFS Prüfummen, dann ist das höchst willkommen und bringt einen Mehrwert, nämlich Sicherheit.
 
Zuletzt bearbeitet:
Zuweilen können Kosten die durch einen Ausfall entstehen größer sein, als die Kosten für eine 2'te SSD und einem Controller.
Also da spricht gar nix gegen, und wenn der Controller noch beide Platten zum lesen nutzt, dann ist es beim Lesen wie ein Raid-0 beim Schreiben ein Raid-1.
Schreibzugriffe sind auch weniger als bei Raid-5/6.
Auf den Tip "SSD mit Powerloss Protection" würde ich hören, da eine Dateninkonsistenz nicht unbedingt sofort auffällt.
Stripegröße würde ich eher auf 64K setzen bei Systemlaufwerk, da eher mit schreiben von kleinen Dateien zu rechnen ist.
 
Also niemals Cache oder BBU ausschalten ausser der Controller taugt nicht. Der Cache ist auch nicht fürs Lesen, das kann das OS besser sondern als Schreibschutz.

If using HDD (Hard Disk Drives) enable write back cache (consider using a BBU in the event of unexpected power loss or unclean shutdown)


Under Windows and Linux using SSDs:

When the volume is created, use write through caching (i.e. write cache will be disabled)

Use Direct IO (and not Cached IO)

Quelle: Avagotech ehemals LSI




Der Wirte-Cache gehört definitiv aus. Man greift nur zum großen Controller, weil sein Prozessor für aufwendige Raid-Systeme mit vielen Platten performanter ist. Der Cache und die BBU werden ergo nicht benutzt.
 
Zuletzt bearbeitet:
Es geht in dieser Überlegung um einen Controller mit Cache und Batteriepufferung nicht um Schreibcache. Der Controllercache wird benötigt um die Daten bis zum nächsten Reboot zu halten.

Das sonstige Cacheverhalten (write back etc) ist davon unabhängig und kann unabhängig davon gesetzt werden - teils auch als Plattencacheoption. Primär ist also die BBU und der damit gepufferte Cache relevant um Daten im Falle eines Ausfalls zu puffern. Insofern haben wir wohl unterschiedliche Aspekte im Blick.

siehe z.B. https://www.thomas-krenn.com/de/wiki/Virtual_Drive_Definition_am_MegaRAID_Controller
Punkte sind write, io und drive policy

Einen Controller ohne Batterie Pufferung zu nutzen halte ich aus Sicherheitsgründen bei Hardwareraid im professionellen Einsatz nicht für sinnvoll, dazu ist das Fehlerverhalten im Crashfall während einer Schreibaktion im Raid zu unvorhersehbar da der Controller die Daten ja quasi selbstständig nacheinander auf die Platte schreibt. Der Cache mit BBU ist dann ist dann quasi der einzige Schutz für eine Konsistenz im Raid - unabhängig von Performanceüberlegungen oder der Frage wann der Controller ein Commit ans OS liefert. Es nützt ja nichts wenn eine Platte im Raid-1 aktualisiert ist, die andere nicht und das System abstürzt. Da bringt es dann auch nichts mehr wenn das OS noch kein Commit für erfolgreiches Schreiben erhalten hat (ohne cache) oder ein Commit (Daten im Cache).

Letztlich dreht es sich aber um die Frage wie man trotz dreier Cashes (OS, Controller, Disk) bei einem Ausfall möglichst wenig Schaden erhält. Ein Datenverlust ist immer dabei, es dreht sich aber um mögliche Dateisystem oder Raid Konsistenz. Daneben gibt es klar Überlegungen über Häufigkeit derartiger Probleme und Performance wenn man das beachten möchte.

Das Hauptproblem "Write Hole" im Raid und transaktionssicheres Schreiben auf Platten sehe ich durch neuere Dateisystementwicklungen aber als gelöst an. BBU und Hardwareraid ist nur eine Behelfskrücke bis das überall verfügbar ist.

siehe
http://www.raid-recovery-guide.com/raid5-write-hole.aspx

Ansonsten wenn es um Verfügbarkeit mit Windows geht:
Einzelplatte < Mainboard Raid < Hardwareraid Raid mit BBU < Virtualisierte Lösungen
 
Zuletzt bearbeitet:
Ist das so richtig, dass bei RAID-1 der Performance-Unterschied zwischen echtem RAID-Controller und Mainboard-RAID so ziemlich bei Null liegt?

Und welchen Sinn macht eine Intel SSD DC S3500 ??? Hat die Pufferkondensatoren? Konnte nichts davon lesen...
 
Zuletzt bearbeitet:
1.
Wenn dann ist das Mainboard Raid schneller da es über die Mainboard CPU und OS Treiber angesprochen wird.
Raidcontroller CPU, RAM und Firmware ist im Vergleich dazu langsam

Ist aber eher belanglos, da die Platten/SSD Performance im Vergleich dazu der limitierende Faktor ist.

2.
PRODUCT BRIEF Intel® Solid
StateDrive DC S350 Series

Fast and Consistent Performance
Full End to End Data Protection
Enhanced Power Loss Data Protection
Latest 20nm MLC NAND Flash Memory Technology
Intel based controller technology
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh