[DE] LVM und mdadm, Planung eines Systems

[ayla]

Hallo,

ich möchte mein System komplett neu aufbauen, mich dazu mit LVM2 beschäftigen, einen -oder möglicherweise auch zwei- md-Raids da rein packen, einen für Daten auf den normalen HD's, vielleicht auch einen für das Hauptsystem auf zwei SSD's.

Da ich den LVM noch nicht kenne werde ich agaidas Tipp folgen und das Ganze erst mal auf einer vbox ausprobieren und den Umgang üben. Allerdings soll diese dann auch gleich die Struktur erhalten wie ich es später auf das Hauptsystem übernehmen will. D.h ich stelle mir vor die vbox virtuell in 3 SSD und zwei HD aufzuteilen und diese dann so zu partitionieren und zu installieren (etwas verkleinert aber von der Struktur her) wie es später im richtigen System aussehen soll. Mal sehen wie sowas geht, bisher hab ich die immer nur mit einer virtuellen Platte betrieben -ah, Lesen bildet, scheint machbar.

Konkret zur Verfügung habe ich zwei 1TB-HDs, die sollen einen 512GB-Mirror zur Datensicherung aufnehmen. Die restlichen 1000GB sind zur Aufnahme eines festen Rettungssystems und zum "Spielen" gedacht -also nicht WoW oder so  was, sondern Testinstallationen zum Ausprobieren von neuen BS/DE, Datenrettung mit Testdisk, usw., sollen also immer wieder möglichst einfach neu angepasst/vergrößert/verkleinert/umpartitoniert werden können.

Die SSD's sind für's Hauptsystem gedacht, wobei eine Vertex4 mit 128GB und eine Vertex3 mit 60GB möglichst schonend behandelt werden sollen. Deshalb soll eine Agility2 mit 60GB den swap, var und auf einer dritten Partition die Platte einer vbox-Installation von XP aufnehmen. /tmp kommt in das RAM, die SSDs sollen GPT erhalten.

Eventuell sollen die Vertex 3 und die Hälfte der V4 in einem 60GB Mirror laufen mit / und /home, aber das ist erst mal nur eine Idee, eine weitere wäre die V3 ebenfalls als Test- oder Rettungsplatte separat vorzuhalten, reizen würde mich hier natürlich auch ein Stripe statt des Mirrors.

Mit mdadm kam ich bisher ganz gut klar, aber den LVM kenne ich bisher überhaupt nicht. Als Starthilfe benutze ich gerade diese Seite und unser wiki, würde mich also über Vorschläge zur Partitionierung, Tipps, Kommentare, nogos... von euch freuen.

Gruß
ayla

[agaida]

Dann mal Butter bei die Fische

Die beiden 1T würde ich anders verbraten. Für ein linux-System brauchst Du ca 20-30 G wenn es komfortabel sein soll. lass also 100 G auf den Platten frei und Du hast Platz für ein Rettungssystem und 5 Spielsysteme. Andererseits wirst Du auf das Gefrickel mit nativen Partitionen dankbar verzichten, wenn Du mit LVM vertraut bist. Ist aber Deine Sache.

Durch Deine Anzahl an Platten hast Du auch eine genügende Anzahl von MBRs zum Spielen. Das kann ebenfalls von Vorteil sein. Aber auch da wird sich nach einer Übungsphase eine gewisse Bequemlichkeit einstellen.

Momentan habe ich es bei mir so, dass der MBR der SSD (sda) nach /dev/sdf1 zeigt. Das ist mein "offizielles" Startsystem. Einen
zweiten MBR für absolute Notfälle habe ich auch noch auf /dev/sdd untergebracht. Der zeigt dann auf /dev/sdd1, mein sakrosanktes Rettungssystem.

Alles weitere ist dann recht langweilig: arch auf sda1, siduction auf sda2, ein Raid 0 auf sdb und sdc, ein Raid1 auf sdd und sdf. Das Raid 0 nutze ich nur, um bestimmte Sachen, die ich nicht im Speicher haben kann, möglichst schnell lesen und schreiben zu können. Das sind dann pbuilder-archive, irgenwelche Paketcaches und ein debian-mirror. Meine Spiel-Installationen liegen dann auf logischen Volumes im Raid 1. Und für Härtefälle hab ich noch ein oder 2 kleine Partitionen auf sdd.

Und damit man sich bei der Plattenfrickelei nicht vollkommen in die Füsse schießt, "zeigen" die Einträge in den fstabs immer auf Labels. Das macht das schöne Leben mit vielen Partionen angenehmer, wenn mal das eine oder andere System aus welchen Gründen auch immer verschoben werden muss. Das ist dann aber schon wieder ein ganz anderes Thema.

[ayla]

Eine Platte, Flavour der Wahl, installieren und fertig.

Danach würde ich dieses frische System nehmen und da ein degraded Raid 1 in der VM daneben setzen. Dann würd ich wahrscheinlich auf dieses degraded Raid ein LVM setzen und die bestehende Installation dahin migrieren.

Wenn das passiert ist, dann würde ich das migrierte System startbar machen und die Ursprungsplatte dem Raid zuschlagen

Siduction installiert auf /dev/sda1 (/) und /dev/sda2 (/home)
Dies soll später eine Platte des 1. mirror werden.

Degraded Raid1 mit /dev/sdb1 erstellt. Metadata 0.90 wegen Warnung von mdadm beim Erstellen von bootfähigen Raids und keine Ahnung ob Grub metadata1.x kann.

Code: [Select]

mdadm -C /dev/md0 --level=1 --metadata=0.90 -n2 /dev/sdb1 missing

Code: [Select]

mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sun Jan 13 12:33:33 2013
     Raid Level : raid1
     Array Size : 57421760 (54.76 GiB 58.80 GB)
  Used Dev Size : 57421760 (54.76 GiB 58.80 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan 13 12:33:33 2013
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : b48a2ad3:19b90b84:f19b2a02:f1f88303 (local to host siductionvbox)
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       0        0        1      removed
 
So siehts in der vbox aus, wobei sda-c die SSD sein sollen:

Code: [Select]

fdisk -l
                                                                                               
Disk /dev/sda: 58.8 GB, 58801192960 bytes                                                      
255 heads, 63 sectors/track, 7148 cylinders, total 114846080 sectors                          
Units = sectors of 1 * 512 = 512 bytes                                                        
Sector size (logical/physical): 512 bytes / 512 bytes                                          
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0001d5de

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    53061631    26529792   83  Linux
/dev/sda2        53061632   114845695    30892032   83  Linux

Disk /dev/sdb: 58.8 GB, 58801192960 bytes
255 heads, 63 sectors/track, 7148 cylinders, total 114846080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005a711

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   114845695    57421824   83  Linux

Disk /dev/sdc: 58.8 GB, 58801192960 bytes
255 heads, 63 sectors/track, 7148 cylinders, total 114846080 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005be9f

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048    35145727    17571840   82  Linux swap / Solaris
/dev/sdc2        35145728    72605695    18729984   83  Linux
/dev/sdc3        72605696   114845695    21120000   83  Linux

Disk /dev/sdd: 305.3 GB, 305340874752 bytes
255 heads, 63 sectors/track, 37122 cylinders, total 596368896 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00043b3b

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1            2048   596367359   298182656   83  Linux

Disk /dev/sde: 305.3 GB, 305340874752 bytes
255 heads, 63 sectors/track, 37122 cylinders, total 596368896 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00068185

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1            2048   596367359   298182656   83  Linux

Disk /dev/md0: 58.8 GB, 58799882240 bytes
2 heads, 4 sectors/track, 14355440 cylinders, total 114843520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

     
Hmm...  müsste ich jetzt als nächsten Schritt so:      

Code: [Select]

pvcreate /dev/sde1 /dev/sdd1 /dev/sdc1 /dev/sdc2 /dev/sdc3 /dev/sdb1 /devsda1 /dev/sda2
erst mal die "physical Volumes" erstellen?

[agaida]

grub2 kann metadaten > 0.90, wir sind ja nicht bei Ubuntu :twisted: (Bei Ubuntu ist es aber der mdadm, der so uralt ist, dass da seit Jahren nur noch gefrickelt wird. Das nennt sich Frickelfortpflanzungsgesetz).
Wenn Du willst, kannst Du das noch mal neu anlegen, das wäre dann wohl ein Fall für mdadm --zero-superblock /dev/sdXY

das physical volume und die volume group möchtest Du wahrscheinlich auf dem Raid-Device erstellen,ebenso wie die ersten logischen devices. Ungefähr so:

Code: [Select]


pvcreate --verbose /dev/md0
vgcreate --verbose vg0 /dev/md0
lvcreate --size 25G --name $mein_neues_root --readahead auto --verbose vg0
lvcreate --size XYZG --name workload --readahead auto --verbose vg0


Wie eventuell auffällt, halte ich immer noch absolut nichts von einem separaten /home. Von einer separaten Partition mit meinen Arbeitsdateien halte ich dagegen sehr viel.

Mehr dazu später.

[ayla]

Hi,

sorry, das wird etwas dauern, hab gerade festgestellt daß ich mit meiner vbox irgendwo Mist gebaut hab. Obwohl die Platten auf entsprechenden Partitionen angelegt sind müllt die mir das /home ungefragt mit Sicherungspunkten voll. Werd ich wohl erst am WE dazu kommen das Problem zu suchen.

[agaida]

ich bin bei so was ja feige. ich hab das Vbox-Verzeichnis in meinem Home auf eine eigene Partition geknallt

[bluelupo]

Hi ayla,
beim Anlegen einer VG unbedingt die PE-Size mit der Option -s angeben, weil die Standardgröße nämlich bei 4MB liegt und viel zu klein ist bei den heutigen TB-Disks.

Code: [Select]


# vgcreate -s 128M VGsystem /dev/sdaX


Die PE-Size kann auch nachträglich nicht mehr verändert werden und sollte mit Bedacht gewählt werden, weil sonst der Verwaltungsaufwand für den LVM immens ansteigt. Würdest du die PE-Size auf 4MB lassen wäre deine max. LV Größe 256GB.

Als unterste Grenze würde ich 32MB ansetzen. In deinem Fall mit TB-Platten auf 128MB oder sogar auf 256MB gehen. Die PE-Size ist die Verwaltungseinheit des LVM und bestimmt u.a. die Vergrößerungs- bzw. Verkleinerungsschrittweite deiner LV's.

Zu deiner HW-Konstellation:
Ich persönlich würde mir das Testsystem innerhalb des RAID nicht antun. Zum Testen würde ich immer virtuelle Maschinen (vbox oder kvm) nutzen, weil dies keine "Operation" am offenen Herzen bedeutet. Somit gehst du kein Risiko bei der Installation eines Testsystems ein, zB. durch falsche GRUB-Konfiguration. Virtuelle Maschinen sind mittlerweile ideale Testsysteme an denen sich (fast) alles was auf realen Systemen vorkommt nachstellen lässt.

Konkret würde ich ein RAID1 (gespiegelt) mit deinen SSD's anlegen. Problem bei dir sind unterschiedlichen SSD-Kapazitäten. Hier würde ich überlegen eine neue 128GB SSD zu kaufen. Das zweite RAID1 (gespiegelt) würde für die Daten nutzen.

md0 --> 2 x 128GB --> sda und sdb (SSD gespiegelt)
md1 --> 2 x 1TB --> sdc und sdd (HD gespiegelt)

md0 würde ich komplett in eine VolumeGroup packen (VGsystem), die dann die folgende LogicalVolumes enthält:

LVroot --> 6 GB --> Mountpunkt /
LVvar  --> 3 GB --> Mountpunkt /var
LVhome --> variabel --> Mountpunkt /home
LVswap --> 4 GB

Diese Aufteilung der LV's hat sich bei mir bestens bewährt. LVroot ist mit 6 GB völlig ausreichend dimensioniert. /var deshalb als eigenes LV (LVvar), weil es das FS ist das erfahrungsgemäß am schnellsten wächst und somit nicht dein "/" (LVroot) zumüllt. Swap ebenfalls in LVM, weil du das bei Bedarf in der Größe schnell anpassen kannst. Ein großer Swap-Bereich ist bei den heute üblichen RAM-Speicher eher ungewöhnlich und mehr als 4GB würde ich eher nicht anlegen.
Userdaten unterhalb von /home/<username>/ kannst mit Hilfe von Links ins zweite RAID (md1) zeigen lassen. Das heißt das nur noch die Configs der User auf den SSD's liegen und die Userdaten auf den HDD's.

md1 (Kapazität 1TB) auch in eine zweite VG packen (VGdata) und nur für die Daten verwenden, bei denen es nicht nötig ist sie auf der SSD vorzuhalten.

LVdata01 -->  ?? GB
LVdata02 -->  ?? GB
...

Deine zukünftigen Testsysteme (als virtuelle Maschinen) kannst du jeweils in eigenes LV auf den SSD's oder den HDD's packen, zB. so:

VGsystem/LVfastVM
VGdata/LVslowVM

LVfastVM, da im RAID1 auf den SSD's, würde wohl performanter sein.

Fazit:
Somit erhälst du ein schnell startendes System, da dies im md0 auf den SSD's ist. Das zweite RAIDs (md1) enthält deine Daten und liegt auf den konventionellen Disks.

Die Installationen der virtuellen Testsysteme kannst du wahlweise in das LV auf den SSD's (LVfastVM) oder den HDD's (LVslowVM) legen. Damit hast du einen hohen Grad Flexibilität via LVM erreicht, gepaart mit der Sicherheit eines gespiegelten RAID-Systems.

[ayla]

ich bin bei so was ja feige. ich hab das Vbox-Verzeichnis in meinem Home auf eine eigene Partition geknallt

Gute Idee, hats bei mir jetzt auch. Komischerweise iss die vbox (nachdem ich sie neu installiert hab) jetzt auch brav, d.h. sie will keine Sicherungspunkte mehr selbstständig anlegen, die Partition bleibt nahezu leer.  :twisted:

Hi ayla,
beim Anlegen einer VG unbedingt die PE-Size mit der Option -s angeben,

Danke, so gemacht.

Zu deiner HW-Konstellation:
Ich persönlich würde mir das Testsystem innerhalb des RAID nicht antun. Zum Testen würde ich immer virtuelle Maschinen (vbox oder kvm) nutzen,

Die Testsysteme sollen auch nicht mit in den Raid, momentan nur sicher die Datenplatte und eventuell / und /home.
Die vbox möchte ich für Testsysteme eigentlich nur im Ausnahmefall nutzen da sonst nur auf der virtuellen Hardware getestet wird.

Konkret würde ich ein RAID1 (gespiegelt) mit deinen SSD's anlegen. Problem bei dir sind unterschiedlichen SSD-Kapazitäten.

Ich will erst mal nur 60GB der SSD's in den Raid nehmen -schon zu groß für ein einziges Linuxsystem, aber meine Plattenkapazität ist eh überdimensioniert- Der Rest ist erst mal noch unverplant. Die TB-Platten sollen nur je zur Hälfte (oder auch 2/3) in einen Raid1, die SSD's sind mir für ständige Neuinstallationen einfach zu schade. Ausnahme die Agility2 -die ich im Moment in Gedanken außerhalb des LVM's geplant hab'-, die mit /var rödeln muß -deshalb, weil ichs einerseits schnell möchte und deshalb /var nicht auf einer HD unterbringen will, andererseits aber meine beiden Vertex nicht frühzeitig verbraten will. Swap ist bei meinem System seit Monaten ungenutzt, will aber nicht ausschließen daß ich's irgendwann mal brauche und der Platz auf der Agility ist ja auch da.

md1 (Kapazität 1TB) auch in eine zweite VG packen (VGdata) und nur für die Daten verwenden, bei denen es nicht nötig ist sie auf der SSD vorzuhalten.

Jupp, so war's auch von mir gedacht.

Also im Moment etwa so:
je 30GB / und /home auf einem Raid1 im LV mit den Vertex
20GB SWAP / 20GB /var / 20GB /Vbox außerhalb des LV auf der "schwächeren" SSD
500-700GB Raid1 mit Daten innerhalb eines LV
300-500GB innerhalb eines LV für's spielen.

Nachdem ich jetzt das degraded raid1 (alles jetzt erstmal in der vbox) wieder erstellt hab muß ich jetzt mal schauen wie ich mein System unfallfrei auf den Raid im LV umgezogen bekomme.
Irgendwie hakts bei mir momentan welche Schicht da jetzt wie wohin gehört.
Normalerweise hätte ich versucht, nach Erstellen des "halben" Raids, die komplette Disk mit dem System von einer Live-CD aus mittels dd auf den Raid zu klonen und dann die fstab und den Grub entsprechend anzupassen, aber damit dürften -vermute ich mal- meine gerade erstellten LV my_root und my_home geliefert sein, oder werden die Verwaltungsdaten so außerhalb der Partitionen aufbewahrt daß ich damit auch so nix kaputt machen könnte?

Bei nem defekten mirror brauch ich nur die defekte Platte zu ersetzen und mdadm synced mir die vorhandene auf die neue, aber wenn ich so vorgehe würde ich ja jetzt das leere md0 auf mein System kopieren...

Ich seh' schon, ich brauch Lesestoff zu den Grundlagen...

[agaida]

@ayla: Eine SSD wird vom Rahmen hinter Glas nicht besser, die altert moralisch bei Nichtbenutzung genau so schnell wie unter Volldampf.

SSDs sind momentan eher so aufgestellt, dass man zusehen sollte, die innerhalb der Garantie platt zu bekommen Und nach 2-3 Jahren will man die Teile eh nicht mehr haben, da sich diese Technik rapide weiterentwickelt.

[ayla]

...auch wieder wahr...  

[agaida]

Die modernen Pladden haben so ein Management eingebaut, dass die benutzten Speicherzellen "gleichmäßig" abnutzt - ich glaube, der Teufel weiss da mehr dazu. Die Rechenexempel sahen recht astronomisch aus - also, was man tun muss, um eine moderne SSD zu schrotten. Und die benötigte Zeit war auch nicht ohne.

Ansonsten bin ich da ganz konservativ und empfehle eine ganz dezente Speicherausstattung von 16, besser 32G. Und dann alles, was nicht unbedingt auf die Pladde gehört, ab ins tmpfs. Is eh schneller.

[ayla]

http://www.howtoforge.com/linux_lvm_p6


7 LVM On RAID1

In this chapter we will set up LVM again and move it to a RAID1 array to guarantee for high-availability. In the end this should look like this:

http://static.howtoforge.com/images/lvm/lvm_scheme_full_raid1.png

This means we will make the RAID array /dev/md0 from the partitions /dev/sdb1 + /dev/sdc1, and the RAID array /dev/md1 from the partitions /dev/sdd1 + /dev/sde1. /dev/md0 and /dev/md1 will then be the physical volumes for LVM.

Wenn ich das Howto richtig verstehe -was ich bezweifle :? - arbeite ich bei der Erstellung des Raids nach wie vor auf der Ebene Festplatte/Partition, muß auch mein System hier klonen und nicht wie ich eigentlich dachte bereits auf der LV-Ebene.
Da ich / und /home auf getrennten Partitionen auf sdc habe müsste ich demnach auch zwei md-Devices auf sdb einrichten, deren Partitionen in der Größe meinem root und home entsprechen, also auch 2 PV und nicht eine md0 und ein PV die ich dann später in die LV my_root und my_home aufteilen kann.
Irgendwo hakts bei mir mit dem Verständnis was der LVM da eigentlich dann drin verloren hat.

Vermutung: Ich hab noch garnix kapiert  :shock:

Gruß
ayla

[agaida]

@ayla: hihihi, ich bezweifel das auch
Die Antwort ist aber ganz einfach LVM = Logical Volume Manager. Dat Dingens ist nur ein Abstraktionslayer für logische Blockdevices.

Beispiel:

Code: [Select]


pvcreate /dev/sda
vgcreate /dev/sda vg0
lvcreate --size 50G --name blockdevice1 vg0
lvcreate --size 50G --name blockdevice2 vg0

pvcreate /dev/md0
vgcreate /dev/md0 vg1
lvcreate --size 50G --name blockdevice3 vg1
lvcreate --size 50  --name blockdevice4 vg1

mount /dev/vg0/blockdevice1 mountpoint1
mount /dev/vg0/blockdevice2 mountpoint2
mount /dev/vg1/blockdevice3 mountpoint3
mount /dev/vg2/blockdevice4 mountpoint4


Ich finde, das illustriert das ganz gut. Bei der Arbeit mit den logischen Blockdevices siehst du dann nicht mehr, was da physikalisch drunter liegt, Du siehst nur noch das Blockdevice. Das ist die durch LVM eingefügte Abstraktionsebene.

Wenn Du den Partitionen jetzt noch Label verpasst oder die Teile per UUID mountest, wird es noch ein stückweit abstrakter. Man braucht ein oder zwei Sekunden, um die schlichte Schönheit hinter diesem Konzept zu begreifen. Und noch ein oder zweit Tage, um den Sinn in diesem Tun zu verstehen. :twisted:

[bluelupo]

Hi ayla,
zum Zusammenspiel von RAID und LVM noch ein paar Worte.

Wie agaida schon sagte zieht der LVM eine zusätzliche Abstraktionschicht ein der mit Blockdevices arbeitet (siehe /dev/mapper/*).

Wenn du mit einer Kombination RAID/LVM arbeitest legst du zuerst mit phys. Diskdevices wie gewöhnlich dein RAID an, danach werden diese md-Devices dem LVM zur Erstellung eines PV vorgelegt.

Das heißt, dein LVM wird anstatt der phys. Diskdevices (sd*) mit den RAID-Devices (md*) "gefüttert". Letztendlich ist das dem LVM egal welche Devices du ihm gibst.

Links:
http://wiki.marek-walther.de/wiki/seminare/workshops/lvm2/index
http://de.wikipedia.org/wiki/Logical_Volume_Manager
http://de.wikipedia.org/wiki/Device_Mapper

EDIT: Ich nutze den LVM schon lange und bin von seiner Flexibilität sehr beigeistert, aber es braucht auch ein paar HowTo's um die Funktionalität intus hast ;-)