Arch Linux

Einrichtung von RAID, LUKS und LVM?

Bachsau

Hi! Ich bin gerade dabei ein System mit Arch komplett neu aufzusetzen. Dabei würde ich gerne mit zwei 6 TB Platten ein RAID 1 (Mirror-Array) aufbauen und das System mit LUKS verschlüsseln. Ich bin aber noch unschlüssig, wie ich das am besten verschachtel und würde deshalb mal gerne eure Meinung dazu hören. Folgende Szenarien habe ich mir überlegt:

Möglichkeit 1: 4 Partitionen auf jeder Platte
* BIOS-Boot
* mdraid für /boot, darauf ext4
* mdraid für /root, darauf LUKS, darin ext4
* mdraid mit LUKS, darin swap

Vorteile: Wenige Ebenen.
Nachteile: Unflexibel, drei RAIDS, mehrere LUKS-Container.

Möglichkeit 2: 3 Partitionen auf jeder Platte
* BIOS-Boot
* mdraid für /boot, darauf ext4
* mdraid mit LUKS, darin /root, darauf ein Swap-File

Vorteile: Wenige Ebenen, nur ein LUKS-Container, flexibler als Möglichkeit 1.
Nachteile: Unflexibel, zwei RAIDs, extrem schwierig mit Hibernate in Einklang zu bringen.

Möglichkeit 3: 3 Partitionen auf jeder Platte
* BIOS-Boot
* mdraid für /boot, darauf ext4
* mdraid mit LUKS, darauf LVM, darin /root und swap

Vorteile: Nur ein LUKS-Container, LVM komplett verschlüsselt, ziemlich flexibel
Nachteile: Viele Ebenen, mehrere RAIDs

=> Dies scheint die am häufigsten empfohlene und am besten unterstützte Konfiguration zu sein.

Möglichkeit 4: 2 Partitionen auf jeder Platte
* BIOS-Boot
* LVM mit /boot und 2x LUKS für /root und swap, alle drei als mirrored Volumes

Vorteile: Nur 2 physikalische Partitionen, extrem flexibel, wenig Ebenen da mdraid komplett entfällt
Nachteile: Mehrere LUKS-Container, wenig populär

=> Scheint mir eine sehr saubere Lösung zu sein, ich hadere aber damit, im Gegensatz zu Möglichkeit 3 wieder LUKS zu chainen. Gibt es einen Grund der dagegen spricht, das RAID dem LVM zu überlassen?

Als Bootloader möchte ich GRUB2 einsetzen. Hoffe auf Kommentare.

Gruß,
Bachsau

frostschutz

Wenn dann mdadm. Das dmraid (fakeraid) ist lange nicht so verbreitet/gut unterstützt.

Gibt es einen Grund der dagegen spricht, das RAID dem LVM zu überlassen?

Du hast genausoviele Ebenen, nur daß das eben vor dir versteckt wird. Es ist undurchsichtig und wenn du mal Probleme damit hast wirst du weniger Leute finden die helfen können, als beim traditionellen MD->LUKS->LVM-> ...

Bachsau

frostschutz schriebWenn dann mdadm. Das dmraid (fakeraid) ist lange nicht so verbreitet/gut unterstützt.

Sorry, das meinte ich. Habe den Beitrag gerade editiert. dm-raid lässt sich ja gar nicht auf einzelne Partitionen anwenden. Ich halte fake-raids auch für totalen Unfug. Diese art Ärger werde ich mir definitiv nicht antun. 🙂

frostschutz schriebDu hast genausoviele Ebenen, nur daß das eben vor dir versteckt wird.

Ich dachte erst, LVM könnte das vielleicht irgendwie noch effektiver handhaben. Habe jetzt aber auch gelesen, dass es eigentlich auch nur mdadm nutzt und lange nicht so ausgereift sein soll.

Bachsau

Was würdet ihr als Chunk-Größe empfehlen um an einem Desktop-System möglichst viel Read-Performance rauszuziehen? Ich dachte so an 32 KiB. Wiie wirkt sich das beim Swap aus?

Um das ganze noch schwerer zu machen, sind das Festplatten mit "Advanced Format", das heißt 4 KiB-Sektoren mit 512 Byte-Emulation. Ich muss also darauf achten, dass durch alle Ebenen hindurch die Zugriffe auf die Grenzen der 4 KiB-Sektoren fallen, ansonsten stürzt die Performance ab.

frostschutz

RAID-1 hat keine Chunks in dem Sinne.

Ich muss also darauf achten, dass durch alle Ebenen hindurch die Zugriffe auf die Grenzen der 4 KiB-Sektoren fallen, ansonsten stürzt die Performance ab.

MiB Align ist überall der Standard. Du musst also nur drauf achten daß dein Partitionierungsprogramm keinen Mist baut.

Normalerweise hat man da keine Probleme mehr, das ist eher wenn man Altlasten mit sich herumschleppt.

Bachsau

frostschutz schriebRAID-1 hat keine Chunks in dem Sinne.

Da stimmt. Optimal gewählt müsste in vielen Fällen aber eine fast doppelt so schnelle Lesegeschwindigkeit erreicht werden.

Edit: Es scheint tatsächlich keine Rolle mehr zu spielen. mdadm --detail gibt keine Chunk Size an.

frostschutz schriebMiB Align ist überall der Standard. Du musst also nur drauf achten daß dein Partitionierungsprogramm keinen Mist baut.

Wenn das stimmt, würde mir das einige Kopfschmerzen ersparen. 🙂
Denn das ist etwas, das sich später nicht mehr so leicht ändern lässt. Partitioniert habe ich mit gdisk in Standard-Einstellung, alle Partitions auf Mebibyte-Boundaries.

[gelöscht]

Hy,

schon mal an btrfs gedacht, solange Du kein raid5/6 haben willst! Bei mir läuft btrfs raid0 super und im laufendem Betrieb kann ich partitionen (Festplatten) inzufügen. Läuft sauber mit/ab Linux Kernel 4.4.X

Gruß

Bachsau

Eigentlich möchte ich derartige Experimente nicht wagen. Ich habe bisher immer mit ext4 gearbeitet und war damit sehr zufrieden. Vor allem aber scheint Btrfs keine integrierte Verschlüsselung zu bieten. Das bedeutet, dass ich LUKS wohl darunter bauen müsste. Das Problem hierbei ist, dass dies zur Folge hätte, dass alle Daten 2x verschlüsselt werden müssten und das kostet ziemlich viel, da mein Prozessor noch keine AES-Beschleunigung bietet.

[gelöscht]

doch Verschlüsselung funktioniert siehe https://www.youtube.com/watch?v=P5dX_e8_BEI
BtrFS ist stabil ausser raid5/6 das wird wohl neu geschrieben. BtrFs hat seine Vorteile besonders auf Server.

Gruß

frostschutz

Wenn btrfs die gewünschte RAID-1 Funktion übernimmt aber darunter beide Platten verschlüsselt sein müssen, dann wärs doppelt. Das hat er glaube ich gemeint.

Man kann natürlich das RAID traditionell und dann trotzdem btrfs obendrauf, dann ist es nicht anders als wie mit jedem anderen Dateisystem.

Bachsau

Genau, das meinte ich. Das LUKS muss auf jeden Fall AUF das Raid, nicht drunter, weil ich meinem System nicht die Last aufbürden will, alles doppelt zu verschlüsseln. Also danke für den Vorschlag, aber eine Lösung mit Btrfs kommt derzeit nicht in Frage.

Schade ist, dass mdadm keine Container mit nativem 1.2-Metadaten-Superblock unterstützt. Das wäre eine richtig schöne Lösung gewesen: Nur eine GPT-Partition mit nur einem Metadaten-Bereich für alle Arrays. Aber ich denke es wird dann wohl doch die Möglichkeit 3. Das ist am weitesten verbreitet und scheint eine recht ordentliche Lösung zu sein.

Es geht übrigens um ein Desktop-System, das gleichzeitig zur Arbeit, Entwicklung und zum Spielen genutzt wird, und außerdem sporadisch als Host für virtuelle Maschinen dient, wenn es etwas zu testen oder nur für Windows gibt. Bisher lief das mit Ubuntu und Windows im Dual-Boot, wobei Windows schon lange ein Schattendasein fristet (ein Boot alle zwei Monate). Mit den neuen Festplatten geht das eh nicht mehr und ich werde es wohl auch nicht vermissen. Auf Servern setze ich aber weiter auf Debian. Arch ist dafür weniger geeignet, weil ein wartungsarmes und stabiles System dort wichtiger ist, als aktuelle Software.

Datenschutz
Impressum