Encrypted LVM over Raid5

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

19.01.2010 - 21:08

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?

Bearbeitet von EG am 19.01.2010, 21:10

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

19.01.2010 - 21:47

Zitat von EvilGohan
ad write hole Problem mit Software Raid5:
Gibts da andere Lösungen als sich eine USV anzuschaffen?

Raidcontroller 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.

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3772

19.01.2010 - 22:11

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?

davebastard

Vinyl-Sammler

Registered: Jun 2002
Location: wean
Posts: 12442

19.01.2010 - 22:20

Zitat von COLOSSUS
Raidcontroller 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.

verwende auch apcupsd. hatte zwar noch keinen stromausfall, bei meinen tests (stecker ziehen) gabs aber keine probleme.

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3772

19.01.2010 - 22:22

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.

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

19.01.2010 - 22:36

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.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

19.01.2010 - 23:48

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

sollten daher in deiner lvm.conf in devices{} gesetzt sein. Benoetigt eine halbwegs aktuelle LVM-version; ich glaube, Ubuntu 9.10 bringt eine qualifzierte mit.

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

22.01.2010 - 16:49

Grad beim Überfliegen des Threads nochmal auf was aufmerksam geworden...

Zitat von nexus_VI
Wenn mehr als eine Disk kaputt ist, hast du ein Backup
Worauf willst du denn konkret hinaus?

Das Raid ist 4TB groß...da gibts kein Backup!

Ned von den unwichtigen Daten

Wird ein Fileserver für große "Multimedia"dateien (300MB-8GB) auf dem AUCH meine wichtigen Daten liegen.
Die wichtigen Daten werden regelmäßig "gebackupt" (...), die anderen Daten nicht.

Hab mich schonmal bissl mit lvm gespielt, ein unverschlüsseltes angelegt, resized usw...war an sich kein Problem.
Auch bissl optimiert hab ich nach Colos Tipps (und mich auf deinem Blog schlau gemacht).

Es fällt auf:

Benchmark mit io scheduler cfg und Standardeinstellungen:

Code: PHP

root@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

nach folgenden Anpassungen:

Code: PHP

root@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

Das ist jetzt jedoch noch ohne LVM...würd gern ein - wie im Titel angemerkt - verschlüsseltes LVM über das Raid ziehen.
Bin jedoch noch/nach wie vor unsicher im Umgang damit und kann noch nicht ganz einschätzen wie die Verschlüsselung sich auf die Flexibilität und Datenrecovery (jeglicher Art) auswirkt.
Find leider fast nur Threads in anderen Foren wo User sich mit dieser Thematik beschäftigen. Die Meinungen gehen stark auseinander - einen gemeinsamen Nenner kann ich hier nicht finden.

Auch ein HOW-TO das eventuell mehr Infos als die einzugebenden Befehle step-by-step liefert gibts kaum (oder ich such falsch).

Hoffe ihr könnt mir bissl unter die Arme greifen.
tia

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

22.01.2010 - 18:33

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.

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

22.01.2010 - 22:04

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.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

22.01.2010 - 22:12

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.

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

28.01.2010 - 22:36

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.

Bearbeitet von EG am 28.01.2010, 22:41

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

28.01.2010 - 22:54

Zitat von EvilGohan
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.

Full Disk Encryption zahlt sich bei einem Standgeraet eigentlich nur dann aus, wenn du dich davor fuerchten musst, dass dir irgendjemand die Maschine stehlen koennte. Sonst ist es wirklich unkomfortabel (weil man zum Rebooten vor Ort sein muss), reduziert evtl. den Durchsatz und erhoeht ganz sicher den Stromverbrauch.

Zitat von EvilGohan
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!

Stimmt. Ich hab das nicht getestet, da ich davon ausgegangen bin, dass der Block-Cache des MD-Volumes sich auch schon hinreichend positiv auf die LVM-Performance auswirken duerfte, aber wenn man das readhead des Logical Volumes ebenfalls entsprechend erhoeht, bringt das (bei mir zumindest) noch einmal 50MiB/s seq. read. Cool! Danke fuer den Input; werde ich auch in meinem Blog-Eintrag nachtragen

Zitat von EvilGohan
Die Einstellungen sind auch leider nicht persistent. Wo wäre hier der (logisch) richtige Platz, um diese Einstellungen beim start des Systems zu setzen?

Das ist (leider) Distrospezifisch. In Ubuntu/Debian bietet sich /etc/rc.local an - Kommandos in dieser Datei werden am Ende des Bootvorgangs in den Default-Runlevel direkt von init ausgefuehrt. Unter Gentoo findet man ein vergleichbares File unter /etc/conf.d/local, unter RHEL/CentOS und SuSe gibt es das auch (mir ist nur leider inzwischen entfallen, wo genau).

Zitat von EvilGohan
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.

Kommt drauf an, welche Load du erwartest. Fuer meine Zwecke (mein Server "streamt" hauptsaechlich relativ grosze Dateien ueber NFS und SMB) ist die dd-Variante (Lesetests mit of=/dev/null - Schreibtests mit if=/dev/zero) bzw. sogar hdparm schon ein guter Anhaltspunkt dafuer, welche Performance man erwarten wird duerfen. Wenn du einen NNTP-Server betreibst, musst da natuerlich nach anderen Gesichtspunkten optimieren und messen. Ein flexibles und empfehlenswertes Dateisystem-Benchmark ist z. B. bonnie++ - es gibt aber auch hier jede Menge Alternativen, und keines das mir bekannt ist zeigt dir dann eine bunte Balkengrafik und sagt "Dein System ist 1336 Punkte toll!" - die Interpretation der Resultate ist nicht immer einfach, dafuer vermeidet man unserioese - weil uebersimplifizierende - Aussagen.

Vielleicht bringe ich dazu (richtiges Benchmarken unter GNU/Linux) mal einen Artikel - werd ich intern mal ansprechen. Eine (ebenfalls intern) schon laenger angekuendigte Ueberraschung habe ich ja auch noch in der Hinterhand, das traefe sich eigentlich gar nicht schlecht… stay tuned!

EG

thinking with portals

Registered: May 2004
Location: 11**
Posts: 3918

28.01.2010 - 23:36

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

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12141

28.01.2010 - 23:42

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.

EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	19.01.2010 - 21:08 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? Bearbeitet von EG am 19.01.2010, 21:10
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	19.01.2010 - 21:47 Zitat von EvilGohan ad write hole Problem mit Software Raid5: Gibts da andere Lösungen als sich eine USV anzuschaffen? Raidcontroller 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.
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3772	19.01.2010 - 22:11 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?
davebastard Vinyl-Sammler Registered: Jun 2002 Location: wean Posts: 12442	19.01.2010 - 22:20 Zitat von COLOSSUS Raidcontroller 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. verwende auch apcupsd. hatte zwar noch keinen stromausfall, bei meinen tests (stecker ziehen) gabs aber keine probleme.
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3772	19.01.2010 - 22:22 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.
EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	19.01.2010 - 22:36 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.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	19.01.2010 - 23:48 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` sollten daher in deiner lvm.conf in devices{} gesetzt sein. Benoetigt eine halbwegs aktuelle LVM-version; ich glaube, Ubuntu 9.10 bringt eine qualifzierte mit.
EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	22.01.2010 - 16:49 Grad beim Überfliegen des Threads nochmal auf was aufmerksam geworden... Zitat von nexus_VI Wenn mehr als eine Disk kaputt ist, hast du ein Backup Worauf willst du denn konkret hinaus? Das Raid ist 4TB groß...da gibts kein Backup! Ned von den unwichtigen Daten Wird ein Fileserver für große "Multimedia"dateien (300MB-8GB) auf dem AUCH meine wichtigen Daten liegen. Die wichtigen Daten werden regelmäßig "gebackupt" (...), die anderen Daten nicht. Hab mich schonmal bissl mit lvm gespielt, ein unverschlüsseltes angelegt, resized usw...war an sich kein Problem. Auch bissl optimiert hab ich nach Colos Tipps (und mich auf deinem Blog schlau gemacht). Es fällt auf: Benchmark mit io scheduler cfg und Standardeinstellungen: Code: PHP `root@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` nach folgenden Anpassungen: Code: PHP `root@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` Das ist jetzt jedoch noch ohne LVM...würd gern ein - wie im Titel angemerkt - verschlüsseltes LVM über das Raid ziehen. Bin jedoch noch/nach wie vor unsicher im Umgang damit und kann noch nicht ganz einschätzen wie die Verschlüsselung sich auf die Flexibilität und Datenrecovery (jeglicher Art) auswirkt. Find leider fast nur Threads in anderen Foren wo User sich mit dieser Thematik beschäftigen. Die Meinungen gehen stark auseinander - einen gemeinsamen Nenner kann ich hier nicht finden. Auch ein HOW-TO das eventuell mehr Infos als die einzugebenden Befehle step-by-step liefert gibts kaum (oder ich such falsch). Hoffe ihr könnt mir bissl unter die Arme greifen. tia
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	22.01.2010 - 18:33 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.
EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	22.01.2010 - 22:04 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.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	22.01.2010 - 22:12 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.
EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	28.01.2010 - 22:36 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. Bearbeitet von EG am 28.01.2010, 22:41
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	28.01.2010 - 22:54 Zitat von EvilGohan 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. Full Disk Encryption zahlt sich bei einem Standgeraet eigentlich nur dann aus, wenn du dich davor fuerchten musst, dass dir irgendjemand die Maschine stehlen koennte. Sonst ist es wirklich unkomfortabel (weil man zum Rebooten vor Ort sein muss), reduziert evtl. den Durchsatz und erhoeht ganz sicher den Stromverbrauch. Zitat von EvilGohan 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! Stimmt. Ich hab das nicht getestet, da ich davon ausgegangen bin, dass der Block-Cache des MD-Volumes sich auch schon hinreichend positiv auf die LVM-Performance auswirken duerfte, aber wenn man das readhead des Logical Volumes ebenfalls entsprechend erhoeht, bringt das (bei mir zumindest) noch einmal 50MiB/s seq. read. Cool! Danke fuer den Input; werde ich auch in meinem Blog-Eintrag nachtragen Zitat von EvilGohan Die Einstellungen sind auch leider nicht persistent. Wo wäre hier der (logisch) richtige Platz, um diese Einstellungen beim start des Systems zu setzen? Das ist (leider) Distrospezifisch. In Ubuntu/Debian bietet sich /etc/rc.local an - Kommandos in dieser Datei werden am Ende des Bootvorgangs in den Default-Runlevel direkt von init ausgefuehrt. Unter Gentoo findet man ein vergleichbares File unter /etc/conf.d/local, unter RHEL/CentOS und SuSe gibt es das auch (mir ist nur leider inzwischen entfallen, wo genau). Zitat von EvilGohan 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. Kommt drauf an, welche Load du erwartest. Fuer meine Zwecke (mein Server "streamt" hauptsaechlich relativ grosze Dateien ueber NFS und SMB) ist die dd-Variante (Lesetests mit of=/dev/null - Schreibtests mit if=/dev/zero) bzw. sogar hdparm schon ein guter Anhaltspunkt dafuer, welche Performance man erwarten wird duerfen. Wenn du einen NNTP-Server betreibst, musst da natuerlich nach anderen Gesichtspunkten optimieren und messen. Ein flexibles und empfehlenswertes Dateisystem-Benchmark ist z. B. bonnie++ - es gibt aber auch hier jede Menge Alternativen, und keines das mir bekannt ist zeigt dir dann eine bunte Balkengrafik und sagt "Dein System ist 1336 Punkte toll!" - die Interpretation der Resultate ist nicht immer einfach, dafuer vermeidet man unserioese - weil uebersimplifizierende - Aussagen. Vielleicht bringe ich dazu (richtiges Benchmarken unter GNU/Linux) mal einen Artikel - werd ich intern mal ansprechen. Eine (ebenfalls intern) schon laenger angekuendigte Ueberraschung habe ich ja auch noch in der Hinterhand, das traefe sich eigentlich gar nicht schlecht… stay tuned!
EG thinking with portals Registered: May 2004 Location: 11** Posts: 3918	28.01.2010 - 23:36 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
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12141	28.01.2010 - 23:42 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.

Encrypted LVM over Raid5

Forum Index > Software > Linux and other OS

EG

COLOSSUS

nexus_VI

davebastard

nexus_VI

EG

COLOSSUS

EG

COLOSSUS

EG

COLOSSUS

EG

COLOSSUS

EG

COLOSSUS