Crass Spektakel
Lieutenant
- Registriert
- Juli 2015
- Beiträge
- 978
mifritscher schrieb:Vernünftige OSe haben kein Problem, von einem SW-RAID zu booten. Genauso wenig wie mit beliebigen Kombis aus [BIOS, UEFI] und [MBR, GPT] zu booten...
Dann gibt es keine vernünftigen Betriebssysteme. Denn wie ein OS von einem RAID5 aus 5x10TByte booten soll, am Besten noch wenn darauf logische Volumen liegen die ihrerseits mittels LUKS verschlüsselt sind, das musst du mir mal gaaanz genau erklären.
Tipp: Es geht nicht.
Du kannst problemlos das Root-Verzeichnis in ein LUKS/LVM/RAID-Matroschka-System stecken aber davon booten kannst Du nicht. Dafür muss das Boot-Verzeichnis so liegen dass das BIOS darauf zugreifen kann.
Bei meinem aktuellem RAID5-System aus 5x10TByte alias sd[abcde] mache ich das wie folgt: Jede Platte hat zwei Partitionen, die ersten Partitionen Schema /dev/sd.1 wird zu einem RAID1 (RAID ONE!!!) namens /dev/md0 aus 5x1GByte zusammengefasst auf dem native die /boot-Partition liegt. Die zweiten alias /dev/sd.2 werden über alle Platten zu einem RAID5 aus 5x10TByte zusammengefasst, alias /dev/md1, das wird als physical Volume in die Volume Group vgsys zusammengefasst wo dann /dev/mapper/vgsys_root, /dev/mapper/vgsys_swap, /dev/mapper/vgsys_home liegen und die werden dann über LUKS auf /dev/mapper/vgsys_root_crypt, /dev/mapper/vgsys_swap_crypt, /dev/mapper/vgsys_home_crypt abgebildet. Gottseidank packt mkinit-ramdisk automatisch alle Abhängigkeiten rein so dass nach dem Booten von /dev/sd.1 (NICHT /dev/md0, das kennt das BIOS nämlich nicht) alles korrekt gestartet wird.
Der Trick: nachdem man von /dev/sda1 (oder welchem sd.1 auch immer) gebootet wurde wird /dev/md0 überhaupt erst als RAID erzeugt. Weil aber während des Bootens nicht schreibend auf /dev/sd.1 oder /dev/md0 zugegriffen wird ist das tatsächlich egal. Und das klappt auch wirklich nur mit RAID1.
Wenn Du versuchst direkt vom RAID5 zu booten wirst Du feststellen das das BIOS/UEFI/Firmware halt einfach NIX sieht. Wie denn auch, das sind ja einzelne Fetzen die kreuz und quer über Laufwerke verteilt sind.
Witzigerweise läuft das oben geschildete sogar an einem 486er noch problemlos.
Ergänzung ()
Nun, bei Hardware-RAIDs ist das in der Tat der Fall aber nicht bei Software-RAIDs.Tsu schrieb:Lausig die Realität bei Soft-RAID, wenn ohne direkte Anbindung an die CPU Daten mehrfach durch Busse übertragen werden: Laufwerk, ggf. Controller, ggf. Southbridge/Chipsatz, Arbeitsspeicher, CPU und zurück. Noch dazu RAID5/6, und die Kiste wird langsam, aber jeder misst 0% CPU-Auslastung und wundert sich.
Alle Daten fliessen einmal über den Bus in die CPU, werden verarbeitet und dann in den Cache geschrieben. In der CPU erfolgt mehr Arbeit aber der Bus wird praktisch garnicht belastet weil das alles hochgradig Cache-Affine implementiert wird. Selbst ein RAID5 auf dem ein LVM und auf dem ein LUKS-Container sitzt schiebt die Daten exakt zweimal über den Bus: Einmal beim Lesen vom Gerät und einmal beim Schreiben in den Cache. Fertig. Die Implementierung von Linux ist in dem Punkt wirklich genial. Auch die CPU-Last ist dank modernster SSE/AVX-Nutzung lächerlich, ein RAID5 kann eine moderne CPU mit 50-100GByte/s verarbeiten, selbst LUKS mit heftigster AES512-Verschlüsseslung wuppt ein i9-13900 mit sagenhaften 25GByte/s durch - wohlgemerkt, immer nur einen Kern nutzend.
Davon abgesehen, moderne Bus-Systeme liegen in der Grössenordnung 30Gbyte/s in jede Richtung und sind Punkt-zu-Punkt, d.h. was über SATA oder PCIE rein- und rausgeht blockiert nur diese Leitungen und sonst nix. Das 1GByte was das HD-RAID5 da produziert ist wumpe.
Zuletzt bearbeitet: