DAS (intern) als RAID 1 für MultiBoot System

[Cilla]

Hallo zusammen,

ich habe hier eine Frage zur Umsetzung meiner Speicherlösung für ein MultiBoot System mit Windows und min. einer Linux-Distribution.

Windows residiert auf einer eigenen NVMe SSD, Linux auf einer weiteren. Ich würde nun gerne von beiden Systemen auf einen dritten Datenspeicher - vorzugsweise SSD - zugreifen können (deswegen DAS, Direct Access Storage). Das geht z.B. mit einem NTFS formatierten Medium. In der Vergangenheit habe ich so ein DualBoot-System auch schon eine ganze Zeit lang genutzt. Ich habe ein NAS mit WD RED HDDs, welches ich für Synchronisations- & Backup Aufgaben benutze. Auf die Daten-Platte würde ich gerne mit SSD Lese- & Schreibgeschwindigkeiten zugreifen.

Ich würde nun allerdings gerne den internen Datenspeicher im RAID 1 (oder evt. 5) einrichten und trotzdem von beiden Systemen darauf zugreifen können. Use Case ist u.A. neben normalen geteilten Office-Daten usw. der Zugriff auf VMs von Linux und Windows aus. Mein Mainboard unterstützt (fake) RAID 0, 1 & 10 (msi x570 Tomahawk), ich weiss aber nicht, ob sich das so vertragen würde und nicht anfällig für Probleme wäre.

Ein Backup/Synchro soll trotzdem stattfinden, in naher Zukunft mit FreeNAS und ZFS, aber das scheint mir nicht die sinnvolle Lösung für niedrige Zugriffszeiten und schnelles Lesen & Schreiben zu sein.

Ich bin für allen Input dankbar!

 

[GrumpyCat]

Z.B. der Highpoint SSD7101A-Controller macht Hardware-RAID mit 2-4 NVMes und funktioniert mit Windows und Linux. Ist aber nicht billig.

 

[Rach78]

Raid ist in meinen Augen eher was für Server, und vielleicht noch Workstations. Den Nachteil den ich sehe, hab es selber lange Zeit im Desktop genutzt ist eben der dass nach einem Absturz, egal ob wegen Stromausfall oder Betriebssystemfehler jedesmal du dein komplettes Raid auf Konsistenz prüfen musst (wenn du nicht grad ZFS oder btrfs einsetzt). Raid5 ist mitunter auch beim Schreiben recht langsam wenn du keinen Batteriegestützten Cache nutzen kannst. Schaltet man ihn ohne Batterie ein (wenn das bei FakeRaid überhaupt geht) gewinnst du zwar Geschwindigkeit, zahlst dies aber mit einem potentiell höheren Risiko für Datenverlust.
Problem mit einem NAS ist aber aktuell eben dass 1Gbit selbst für ne einzelne HDD schon der Flaschenhals ist, und selbst 10Gbit Ethernet ist langsamer als eine NVMe. Und USB3 ist mit mindestens 5Gbit auch deutlich schneller als 1Gbit Ethernet. Fürs Backup daheim ist 1Gbit aber in aller Regel immer noch schnell genug, man muss ja nicht jeden Tag ein Vollbackup machen.
Die Frage ist irgendwo auch wieso überhaupt Raid mit SSDs. NVMe sind für nahezu alle Anwendungen schnell genug und zuverlässiger als HDDs sind sie auch. Ergo einfach eine NVMe in der passenden Größe mit der passenden Leistung kaufen. Kurzum Raid würde ich vergessen, und Raid5 schon 10mal. Damit steigerst du das Risiko von Datenverlust eher noch.
Und "Office Daten" syncronisiert man heute halt eher mit einem Server, da brauch man dann kein lokales Backup weil man eine Kopie schon auf dem Server hat. Da muss man sich wenn dann eher darum Gedanken machen wie macht man vom Server nochmal nen Backup.
Und wenn man dann einen Server/NAS hat wäre auch die Frage macht es nicht vielleicht mehr Sinn wenn auch die VMs da laufen.

DualBoot System vielleicht auch nochmal überlegen ob man das wirklich brauch. Alternative ist auch hier einfach das System was man weniger häufig nutzt als Gast VM laufen lassen. Und wenn man es ganz selten nutzt vielleicht auch mal gucken ob es dann Sinn macht das ganze OS auf einen Stick zu packen um dann davon zu booten.
Vorteil bei einer VM ist eben du kannst deine beiden Systeme gleichzeitig nutzen auch und hast kein "entweder/oder" und musst bei einem Wechsel nicht herunter und hochfahren.

 

[Cilla]

Hi Rach, danke für deinen Input. Ich kann die Argumente auch gut nachvollziehen, hatte diese Diskussion schon öfter mal.

DualBoot System vielleicht auch nochmal überlegen ob man das wirklich brauch. Alternative ist auch hier einfach das System was man weniger häufig nutzt als Gast VM laufen lassen. Und wenn man es ganz selten nutzt vielleicht auch mal gucken ob es dann Sinn macht das ganze OS auf einen Stick zu packen um dann davon zu booten.
Vorteil bei einer VM ist eben du kannst deine beiden Systeme gleichzeitig nutzen auch und hast kein "entweder/oder" und musst bei einem Wechsel nicht herunter und hochfahren.

Dual Boot möchte ich auf jeden Fall nutzen, neben VMS, da ich Softwareingenieur bin und es für mich nach wie vor etwas Anderes ist ein Betriebsystem nativ zu nutzen. Insbesondere werde ich wohl mehrere Linux-Distributionen mit einer geteilten home-partition (nicht geteiltes home-Verzeichnes) aufsetzen und testen wollen.

Und "Office Daten" syncronisiert man heute halt eher mit einem Server, da brauch man dann kein lokales Backup weil man eine Kopie schon auf dem Server hat. Da muss man sich wenn dann eher darum Gedanken machen wie macht man vom Server nochmal nen Backup.
Und wenn man dann einen Server/NAS hat wäre auch die Frage macht es nicht vielleicht mehr Sinn wenn auch die VMs da laufen.

Also du meinst, dass man die Office Daten gar nicht mehr lokal hat und direkt auf dem Server arbeitet? Oder meinst du man synchronisiert die Daten mit einem Server um ein lokales Backup zu erübrigen?

Bei Letzterem stimme ich voll zu. Ersteres ist ja auch möglich (also im Sinne von Network Attached Storage), aber in meinem Falle hätte ich dann alles doppelt und dreifach, wenn ich für die verschiedenen Betriebssysteme die Daten jeweils für den lokalen Zugriff vorhalte und dann zusätzlich synchronisiere. Das kann nicht gut gehen, dann möchte ich lieber auf einer geteilten (shared) partition/drive arbeiten und einmal synchronisieren.

Nur zur Klarstellung, falls ich das nicht richtig rübergebracht habe. Das NAS will ich auch weiter nutzen für Synchronisation & Backup. Ich kann mir aber aktuell nicht vorstellen da direkt drauf zu arbeiten.

Für die VMs ist das NAS wohl auch viel zu unperformant - denke ich zumindest. Wie würde ich denn da dann auch mit einer GUI drauf zugreifen?

Trotzdem danke für die Gedankenanstöße. Ein NAS mit SSDs und Gbit-Verbindung scheint mir noch sinnvoll, aber auch gerade deutlich zu teuer.

Mein Gedanke zum internen RAID war, dass ich wahrscheinlich nicht aus allen Betriebssystemen eine Synchronisation mit meinem NAS für diese Daten einrichten werde/kann. Das würde heißen, dass die Daten dann nur unter Windows auch synchronisiert werden und ich somit ein Backup habe.

Vielleicht gibt es hier aber noch eine elegantere Lösung.

 

[GrumpyCat]

@Rach78 Ist das überhaupt noch aktuell? Wenigstens Linux hat seit Ewigkeiten Write Intent Bitmaps und seit Linux 4.4 auch RAID-Journals (https://lwn.net/Articles/665299/). Da wird dann nur für die Stripes, die u.U. beim Absturz gerade geschrieben wurden, die Parity neu berechnet und fertig.

 

[cgs]

Auf die Daten-Platte würde ich gerne mit SSD Lese- & Schreibgeschwindigkeiten zugreifen.

a) Also Du benunst Dein NAS um Daten zwischen Windows und Linux auszutauschen, aber es ist zu langam.

internen Datenspeicher im RAID 1

b) Also willst zusätzlich eine RAID 1 in den PC bauen. Warum RAID?

Also am einfachsten ist es auf der SSD von Linux eine Partition einzurichten auf die Beide Betriebssystem zugriff haben.

und ich somit ein Backup habe.

RAID ist kein Backup!

 

[Rach78]

@Rach78 Ist das überhaupt noch aktuell? Wenigstens Linux hat seit Ewigkeiten Write Intent Bitmaps und seit Linux 4.4 auch RAID-Journals (https://lwn.net/Articles/665299/). Da wird dann nur für die Stripes, die u.U. beim Absturz gerade geschrieben wurden, die Parity neu berechnet und fertig.

Ich hatte damals ein FakeRaid im Desktop mit Windows und da war eh halt so, damals noch zu HDD Zeiten, dass nach jedem Absturz erstmal das Raid1 alles lesen musste, was die Performance des Systems dann arg herabgesetzt hat jedesmal. Raid5 kenn ich mit dem WBC Problem. Entweder lahm (beim Schreiben) oder schnell dafür Risiko mit potentiellem Datenverlust. Ob man da bei Linux was verbesser hat keine Ahnung, bin auf ZFS umgestiegen, da hat man die Probleme gänzlich eben nicht. Das Konzept von ZFS ist für mich auch irgendwo die Zukunft. Keine Hardware Raidcontroller, und kein LVM unter dem Dateisystem. Windows versucht sich mit seinen Storage Spaces und ReFS ja auch an sowas, wie auch Linux mit btrfs. Von daher würde ich von "klassischem" Raid einfach abraten an der Stelle es sei denn es geht nicht anders. Und wenn dann würd ich auch nur Raid1 machen. Mehrere 100eus in einen Hardware Raidcontroller stecken würde ich definitv hier nicht.

Seh für Raid auf einem Desktop System aber wie gesagt hier auch gar nicht den Anwendungsfall. NVMe schaffen mehrere GB pro Sekunde einzelnt, das dürfte für 99% der Leute erstmal ausreichend sein. Einfach die richtige NVMe kaufen, nicht nur stumpf die mit dem billigste Preis/GB Verhältnis die dann bei kleinen Dateien so ihre Probleme hat.

Mein Gedanke zum internen RAID war, dass ich wahrscheinlich nicht aus allen Betriebssystemen eine Synchronisation mit meinem NAS für diese Daten einrichten werde/kann.

Potentielle Probleme die ich sehe. FakeRaid ist auf Software angewiesen. Kann also sein dass das ganze in Windows klappt, aber in Linux dann nicht falls Intel oder AMD hier nicht die entsprechenden "Treiber" Whatever anbietet.
Auf ein NAS wirst du recht Problemlos mit den unterschiedlichsten Systemen drauf zugreifen können: SMB, NFS. Oder man nutzt sowas wie NextCloud, son ne Art Bittorrent zum sycronisieren der eigenen Dateien auf all seinen Geräten, inklusive iOS und Co gabs auch mal, keine Ahnung ob immer noch. Da gibt es also reichlich Möglichkeiten auf ein NAS zuzugreifen...

 

[Cilla]

a) Also Du benunst Dein NAS um Daten zwischen Windows und Linux auszutauschen, aber es ist zu langam.

b) Also willst zusätzlich eine RAID 1 in den PC bauen. Warum RAID?

Also am einfachsten ist es auf der SSD von Linux eine Partition einzurichten auf die Beide Betriebssystem zugriff haben.

und ich somit ein Backup habe.

RAID ist kein Backup!

Hier ist aber ein Bißchen was durcheinander gekommen.

a) Nein. An welcher Stelle hast du das so verstanden? Ich benutze mein NAS aktuell für Synchronisations & Backupaufgaben. Ich will eben nicht über das NAS Daten zwischen Windows und Linux austauschen (und dann doppelt haben bei Synchronisation oder da direkt drauf zugreifen), insb. nicht große Dateien wie z.B. VM-Dateien oder andere, größeren Dateien, auf denen gearbeitet wird.

b) Hab ich am Ende meines 2. Posts nochmal genauer beschrieben, den Gedankengang. Den hast du dann auch halb zitiert. Das neue Dual-/Multi-Boot ist noch gar nicht eingerichtet. Bezüglich Zugriff schrieb ich ja Eingangs bereits, dass das über eine weitere Partition/SSD einfach zu bewerkstelligen sei, aber dass mir ein RAID eigentlich lieber wäre - in Ermangelung von Alternativen.

Ergänzung (19. Januar 2021)

@Rach78 Ist das überhaupt noch aktuell? Wenigstens Linux hat seit Ewigkeiten Write Intent Bitmaps und seit Linux 4.4 auch RAID-Journals (https://lwn.net/Articles/665299/). Da wird dann nur für die Stripes, die u.U. beim Absturz gerade geschrieben wurden, die Parity neu berechnet und fertig.

Danke für die Info! Was denkst du denn zu meinem Problem im Allgemeinen?

Ergänzung (19. Januar 2021)

Potentielle Probleme die ich sehe. FakeRaid ist auf Software angewiesen. Kann also sein dass das ganze in Windows klappt, aber in Linux dann nicht falls Intel oder AMD hier nicht die entsprechenden "Treiber" Whatever anbietet.
Auf ein NAS wirst du recht Problemlos mit den unterschiedlichsten Systemen drauf zugreifen können: SMB, NFS. Oder man nutzt sowas wie NextCloud, son ne Art Bittorrent zum sycronisieren der eigenen Dateien auf all seinen Geräten, inklusive iOS und Co gabs auch mal, keine Ahnung ob immer noch. Da gibt es also reichlich Möglichkeiten auf ein NAS zuzugreifen...

Ja, ich benutze Nextcloud bereits auf meinem NAS (davor owncloud) und bin damit auch ganz zufrieden.

Das potentielle Problem, was du bei FakeRaid siehts, macht mir eben auch Sorgen und ich will eigentlich keinen extra Hardware-RAID-Controller kaufen. Dann werd ich das wohl so machen, wie du das beschrieben hast. NVMe SSD - hab noch eine weitere 1TB, für die ich dann einen PCIe-Adapter brauche, und aus allen Betriebssystemen die Daten von dieser SSD mit dem NAS synchronisieren.

Benutze ich NTFS als Dateisystem für die Daten SSD oder hast du hier noch eine andere Idee?

 

[Rach78]

Verstehe nach wie vor nicht warum Raid. NVMe sind wirklich sehr zuverlässig (wenn du was gescheites kaufst). Bevor du da was spiegelst kümmer dich erstmal um ein Backup. Und wenn es um Hochverfügbarkeit geht sodass man schon ne NVMe spiegelt, dann sollte der PC am besten auch nen redundantes Netzteil haben denn ich würde mal behaupten dass die Komponente allein schon aufgrund von sich bewegenden Teilen nen höheres Ausfallrisiko haben wird als ne NVMe. Ein Raid schützt dich eben auch nicht vor Bedienfehlern, Viren, Verschlüsselungstrojanern etc. Wenn du sagen würdest du brauchst jetzt 10GB/s lesen schreiben, dann wäre Raid vllt interesant hier. Aber auch wiederum nur dann wenn es nix bezahlbares gibt wie man das einfacher haben kann.

 

[Cilla]

Verstehe nach wie vor nicht warum Raid. ...

Hast du meine letzte Antwort gelesen?

 

[GrumpyCat]

Was denkst du denn zu meinem Problem im Allgemeinen?

Tatsächlich halte ich auch von RAID im Desktop nichts. Geschwindigkeitsmäßig bringt's nichts, weil a) alles, was Du auf einem normalen Desktop laufen lässt, nicht wirklich durch eine gute NVMe limitiert ist (die Programme, die mehr als 4GB/Sek Durchsatz schaffen, kann man wohl an einer Hand abzählen). Und b) Ausfallsicherheit/Verfügbarkeit ist normalerweise am Desktop nicht so sehr Thema. Und nicht zuletzt c) hört sich Dein Setup so an, als ob Du Dir mit einem RAID eigentlich nur eine potenzielle Fehlerquelle mehr anlachen würdest. Wenn dann das RAID kaputtgeht, weil Windows mal wieder Schluckauf hatte, ist schließlich guter Rat teuer und genau gar nichts gewonnen durch den ganzen Aufwand.

Ergänzung (19. Januar 2021)

Ob man da bei Linux was verbesser hat keine Ahnung, bin auf ZFS umgestiegen, da hat man die Probleme gänzlich eben nicht

ZFS kann ja nun auch nicht zaubern und wird das genauso machen wie Linux mit den Bitmaps und Journal.

 

[Cilla]

Tatsächlich halte ich auch von RAID im Desktop nichts. Geschwindigkeitsmäßig bringt's nichts, weil a) alles, was Du auf einem normalen Desktop laufen lässt, nicht wirklich durch eine gute NVMe limitiert ist (die Programme, die mehr als 4GB/Sek Durchsatz schaffen, kann man wohl an einer Hand abzählen). Und b) Ausfallsicherheit/Verfügbarkeit ist normalerweise am Desktop nicht so sehr Thema. Und nicht zuletzt c) hört sich Dein Setup so an, als ob Du Dir mit einem RAID eigentlich nur eine potenzielle Fehlerquelle mehr anlachen würdest. Wenn dann das RAID kaputtgeht, weil Windows mal wieder Schluckauf hatte, ist schließlich guter Rat teuer und genau gar nichts gewonnen durch den ganzen Aufwand.

Ja denke ich auch. Mittlerweile bin ich auch schon ab von diesem Gedanken bzgl. RAID.

Wie würdest du denn den Zugriff auf den Datenspeicher, interne NVMe SSD, realisieren von Linux/Windows und die Synchronisation (BackUp) zum NAS?

Danke auf jeden Fall für die ausführlichen Antworten!

 

[Rach78]

Tatsächlich halte ich auch von RAID im Desktop nichts. Geschwindigkeitsmäßig bringt's nichts, weil a) alles, was Du auf einem normalen Desktop laufen lässt, nicht wirklich durch eine gute NVMe limitiert ist (die Programme, die mehr als 4GB/Sek Durchsatz schaffen, kann man wohl an einer Hand abzählen). Und b) Ausfallsicherheit/Verfügbarkeit ist normalerweise am Desktop nicht so sehr Thema. Und nicht zuletzt c) hört sich Dein Setup so an, als ob Du Dir mit einem RAID eigentlich nur eine potenzielle Fehlerquelle mehr anlachen würdest. Wenn dann das RAID kaputtgeht, weil Windows mal wieder Schluckauf hatte, ist schließlich guter Rat teuer und genau gar nichts gewonnen durch den ganzen Aufwand.

Ergänzung (19. Januar 2021)

ZFS kann ja nun auch nicht zaubern und wird das genauso machen wie Linux mit den Bitmaps und Journal.

Nein ZFS ist nen ganz anderes Ansatz. Der LVM ist in das Dateisystem komplett integriert. Zaubern kann es zwar nicht, der Ansatz ist aber wie gesagt nen völlig anderer, da wird dem Dateisystem eben nicht vorgegaukelt es würde ne Partition/Platte haben und darunter ist nicht die Platte sondern der LVM, der aber wiederum nix vom Dateisystem versteht. Ist aber bei Wikipedia hinreichend erklärt, zumindest das gröbste wie das mit ZFS genau ist und was es tut.

Also ein Journal hat ZFS nicht, weil man den da nicht brauch, weil bei einem Systemabsturz auch nichts rekonstruiert werden muss dadurch, weil das Dateisystem zu jeder Zeit in sich konsistent ist.

 

[GrumpyCat]

Wie würdest du denn den Zugriff auf den Datenspeicher, interne NVMe SSD, realisieren von Linux/Windows und die Synchronisation (BackUp) zum NAS?

Also EIGENTLICH bin ich da auch nahe bei Rach78s Meinung aus #3. Ein Problem ist die Wahl des Dateisystems für die gemeinsame Partition. FAT32 ist stabil aber insgesamt ein Witz. NTFS tut, aber Linux-seitig würde meine Hand dafür im Dauerbetrieb nicht ins Feuer legen (ebenso wie man wohl für ZFS on Windows kaum die Hand ins Feuer legen will). Dann kommen noch andere Probleme dazu, z.B. darf Windows nicht ins Hibernate geschickt werden, weil sonst solange die NTFS-Partition blockiert ist. Da kann man sagen "ist kein Problem", aber wenn man dann mal nicht aufpasst, sind schnell Daten weg.

Ich würde auch zur Nutzung von VMs raten. Sowas wie mehrere VM-Linuxe mit geteilter Home-Partition in den VMs (wie Du haben willst) ist kein Problem, einfach in jeder VM /home entsprechend mounten, das geht sogar ggf. ohne Block-Device und Image-Datei, sondern direkt auf Dateiebene. Alles viel flexibler als das Gefrickel auf Bare Metal.

Wegen Backup: Ich würde ein automatisches verschlüsseltes inkrementelles Backup aufs NAS einrichten (KEINE reine Synchronisation! Man will schließlich Sachen von Vorgestern wieder herstellen können). Da gibt's eine Menge Lösungen für, z.B. https://github.com/duplicati/duplicati .

Nein ZFS ist nen ganz anderes Ansatz. Der LVM ist in das Dateisystem komplett integriert.
[...]
Also ein Journal hat ZFS nicht, weil man den da nicht brauch, weil bei einem Systemabsturz auch nichts rekonstruiert werden muss dadurch, weil das Dateisystem zu jeder Zeit in sich konsistent ist.

Hab mich falsch ausgedrückt, ich meinte nicht "Journal" im "harten" Sinne bei z.B. ext3, sondern einfach nur konzeptionell - und CoW bei btrfs und ZFS ist natürlich eine Variante davon, da man bei CoW de facto ein Log einer Datei bzw. ihrer Versionen hat, auch wenn das anders umgesetzt ist.