Worauf willst du denn konkret hinaus?
URL: https://www.overclockers.at/linux/encrypted_lvm_over_raid5_213573/page_1 - zur Vollversion wechseln!
Spiel mich gerade mit lvm2 unter Ubuntu Server 9.10 (Kernel 2.6.31-17) und überlege ein verschlüsseltes LVM über mein Raid5 zu ziehen.
Die Vorteile von LVM liegen wohl auf der Hand, jedoch hab ich bedenken, was die Wiederherstellbarkeit bei defekt einer Platte angeht.
Gründsätzlich müssten Raid und LVM ja 2 Abstraktionsschichten sein, die sich nicht beeinflussen.
Jedoch find ich beim "Googeln" nach möglichen Varianten und Konfigurationen viele Berichte über defekte LVMs nach der Recovery des Raids...
Tipps/Vorschläge wie das Risiko gering gehalten werden kann?
ad write hole Problem mit Software Raid5:
Gibts da andere Lösungen als sich eine USV anzuschaffen?
Zitat von EvilGohanad write hole Problem mit Software Raid5:
Gibts da andere Lösungen als sich eine USV anzuschaffen?
Das Problem versteh ich nicht ganz, wenn eine Disk defekt ist tauscht du sie einfach aus und mdadm macht selbstständig den Rebuild. Wenn du das System migrieren willst, weil z.B. die restliche Hardware hin ist, kannst du das RAID auf dem neuen Sys assemblen und dann die LVs in einem Schritt suchen und aktiv setzen. Wenn mehr als eine Disk kaputt ist, hast du ein Backup
Worauf willst du denn konkret hinaus?
Zitat von COLOSSUSRaidcontroller mit Pufferspeicher- und Batterie. Dann doch lieber sowas, oder? Software, die damit kann, gibt's genug. Ich nutze nut, habe aber auch mit apcupsd gute Erfahrungen gemacht.
Der Vollständigkeit halber: Ich verwende ebenfalls apcupsd ohne Probleme. Ein Rechner hängt per USB dran und fährt die anderen im Notfall herunter.
Die APC USVs sind auch bei mir die erste Wahl, sofern sich keine Softwarelösung - Bsp ZFS - finden lässt.
ad Datensicherheit: Hab auf der Suche nach Informationen über verschlüsselte LVMs auf Raid 5 _sehr_ viele User gefunden, die ihre Daten mit dieser Kombination auf unterschiedlichst Art und Weise zerschossen haben.
Hatte selbst bis zu dem Zeitpunkt eigendlich keine Bedenken. Wollte hier nur mal nachfragen, da die Problematik jeweils unterschiedlich war.
Spiel mich gerade mit der Optimierung des Raids:
+ NCQ deaktivieren
+ cfq verwenden
+ readahead erhöhen
Jetzt werd ich mich ans LVM wagen. 
Beim anlegen der LVM-Komponenten solltest du dringend darauf achten, dass dies mit aktivierter md component detection passiert.
Code:md_component_detection = 1 md_chunk_alignment = 1 data_alignment_offset_detection = 1
Grad beim Überfliegen des Threads nochmal auf was aufmerksam geworden...
Zitat von nexus_VIWenn mehr als eine Disk kaputt ist, hast du ein Backup
Worauf willst du denn konkret hinaus?
Ned von den unwichtigen Daten nach folgenden Anpassungen:Code: PHProot@filer:/home/tom# hdparm -tT /dev/md0 /dev/md0: Timing cached reads: 3918 MB in 2.00 seconds = 1958.91 MB/sec Timing buffered disk reads: 756 MB in 3.00 seconds = 251.85 MB/sec
Code: PHProot@filer:/home/tom# blockdev --setra 65536 /dev/md0 root@filer:/home/tom# echo 1 > /sys/block/sdb/device/queue_depth root@filer:/home/tom# echo 1 > /sys/block/sdc/device/queue_depth root@filer:/home/tom# echo 1 > /sys/block/sdd/device/queue_depth root@filer:/home/tom# echo 1 > /sys/block/sde/device/queue_depth
Code: PHP/dev/md0: Timing cached reads: 3850 MB in 2.00 seconds = 1924.95 MB/sec Timing buffered disk reads: 956 MB in 3.01 seconds = 318.02 MB/sec
md RAID5 garantiert Datenkonsistent und -verfuegbarkeit auf dem Block-Level. Was auf und mit dem entstehenden Blockdevice passiert, ist md egal - ob du das jetzt als Basis fuer LVM, LUKS oder noch eine weitere Iteration von/mit md verwendest, md kuemmert das nicht. So lange n - 1 Komponenten des RAID5-Arrays funktionieren, wird dein Array verfuegbar sein - im "degraded mode" geht nur die Schreibgeschwindigkeit gehoerig in den Keller, sonst merkst du davon gar nichts.
Die grundsätzliche Technik dahinter ist mir schon soweit klar.
Um die Software mach ich mir Sorgen.
Also die Funktionsweise bzw. die möglichen Probleme wenn _ich_ was falsch mach.
Wo sind da die Punkte die man beachten sollte und was sollte man sich ev. extern sichern um eine Recovery nicht zu gefährden?
Gibts da irgendwelche Crypto-Header die man sich raussichern sollte? Kenn das noch vom Truecrypt für Windows.
Wenn die Mühle nämlich mal läuft würd ich nur _sehr_ ungern Dinge ändern müssen, die es notwendig machen alle Daten zu sichern. Das wird nämlich bis zum nächsten Festplattenupdate nicht drin sein.
Zu LUKS kann ich dir nicht viel sagen (man kann den verschluesselten Key exportieren, ja), aber wenn dir das Array entsprechend kracht (zwei Disks gleichzeitig weg), dann sind die Daten selbstredend Geschichte.
Was das Management des Array mittels mdadm angeht - so viel kann man da nicht falsch machen, wenn man halbwegs bei Sinnen ist. Die /etc/mdadm.conf zu sichern schadet sicher nicht, sowie das Partitionslayout der beteiligten Festplatten (`sfdisk -d /dev/blockdevice`). Auch die LVM-Konfiguration kann man sich extern aufbewahren - die paar Byte wird man auch noch wo unterbringen.
Wichtig ist aus meiner Sicht, das ganze nicht ohne USV zu betreiben. Stromausfall bei Volldampf tut weder md noch LUKS gut.
Hab mich nach einigem Herumprobieren dazu entschlossen auf die Verschlüsselung zu verzichten.
Viele Features und Vorteile von LVM werden durch die Verschlüsselung sehrviel komplizierter. Vielleicht wirds in Zukunft ein Thema wenn ichs mehr im "Gefühl" hab.
Festgestellt hab ich jedoch ein "Problem", dass auch du in deinem blog angeführt hast (zumindest Teilweise):
Der Wert für readahead auf dem md0 device sollte vergrößert werden um besseren Durchsatz zu erreichen.
Du erhöhst jedoch nie den Wert auf dem blockdevice des lvm? Der ist nämlich standardmäßig 256!
Die Einstellungen sind auch leider nicht persistent. Wo wäre hier der (logisch) richtige Platz, um diese Einstellungen beim start des Systems zu setzen?
edit: Und bevor ichs vergess:
Wie misst du deine read/write Werte?
einfach mittels dd?
Erstellst dir testfiles und schreibst sie nach /dev/null?
Wie genau man da korrekte Messungen für va. Ausdrucksstarke Benachmarks erreicht ist mir noch nicht wirklich klar.
Zitat von EvilGohanHab mich nach einigem Herumprobieren dazu entschlossen auf die Verschlüsselung zu verzichten.
Viele Features und Vorteile von LVM werden durch die Verschlüsselung sehrviel komplizierter. Vielleicht wirds in Zukunft ein Thema wenn ichs mehr im "Gefühl" hab.
Zitat von EvilGohanFestgestellt hab ich jedoch ein "Problem", dass auch du in deinem blog angeführt hast (zumindest Teilweise):
Der Wert für readahead auf dem md0 device sollte vergrößert werden um besseren Durchsatz zu erreichen.
Du erhöhst jedoch nie den Wert auf dem blockdevice des lvm? Der ist nämlich standardmäßig 256!
Zitat von EvilGohanDie Einstellungen sind auch leider nicht persistent. Wo wäre hier der (logisch) richtige Platz, um diese Einstellungen beim start des Systems zu setzen?
Zitat von EvilGohanedit: Und bevor ichs vergess:
Wie misst du deine read/write Werte?
einfach mittels dd?
Erstellst dir testfiles und schreibst sie nach /dev/null?
Wie genau man da korrekte Messungen für va. Ausdrucksstarke Benachmarks erreicht ist mir noch nicht wirklich klar.
Würdest dich wundern wie wenig ich auf bunte Balkendiagramme gebe.
Fang mehr was mit realistischen Zahlen an, die auch Aussagekraft haben.
Freut mich jedenfalls, dass ich dir Profi als Anfänger der ich bin noch was zeigen konnte.
Hab Ubuntu Server 9.10 und die rc.local mal entsprechend angepasst.
Auf deinen Artikel freu ich mich schon. Man findet einfach nur Mist im Netz was das angeht. 
Fokus steht - wie bei dir - auch bei mir auf großen Meidendateien die vorwiegend "gestreamt" werden. Einbindung werd ich wohl vorerst (der Einfachheit halber) über SMB-Shares machen und ev. später auch NFS antesten.
Hab jetzt mal bissl gespielt mit dd, glaube aber irgendwo was falsch zu machen. Mir kommen die Werte jedenfalls viel zu hoch vor.
Code:Erstellen eines 1,1GB großen Testfiles root@filer:/mnt/lvmraid5# dd if=/dev/zero of=test1gb bs=1024k count=1024 1024+0 Datensätze ein 1024+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 3,04036 s, 353 MB/s 3x lesen dieses Files nach /dev/null /mnt/lvmraid5# dd if=test1gb of=/dev/null 2097152+0 Datensätze ein 2097152+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 1,1482 s, 935 MB/s root@filer:/mnt/lvmraid5# dd if=test1gb of=/dev/null 2097152+0 Datensätze ein 2097152+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 1,49458 s, 718 MB/s root@filer:/mnt/lvmraid5# dd if=test1gb of=/dev/null 2097152+0 Datensätze ein 2097152+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 1,13597 s, 945 MB/s
Ja, wenn du mehrere Runs hintereinander auf das selbe File faehrst, kommen die Quelldaten zum Groszteil aus dem VFS-Cache (im RAM). Um den zu leeren solltest du (als root) zwischen den Tests `sync; echo 3 > /proc/sys/vm/drop_caches` ausfuehren, um auch wieder vom tatsaechlichen Blockdevice zu lesen.
Edith meint noch: Bei mir SUCKT die SMB/CIFS-Performance uebrigens schwer. Samba 3.4.5 am Server, Clients sind GNU/Linux (in-kernel CIFS Client) und WinXP, keiner kommt uber 30MiB/s sequentiell. Das liegt aber (zumindest zum ueberwiegenden Teil) an den Clients, mit `smbclient` (Userspace-only-CIFS-Client) krieg ich mit Ach und Krach 60MiB/s ueber das GBit-Netzwerk. Andere Protokolle kratzen an 110MiB/s.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025