LVM

Aus SchnallIchNet
Version vom 29. Oktober 2017, 10:19 Uhr von Cbs (Diskussion | Beiträge) (Platte austauschen)

Wechseln zu: Navigation, Suche

future comments

since luks is outdated:
in future use eCryptfs https://launchpad.net/ecryptfs


pakete

apt-get install lvm2 cryptsetup mdadm


raid erzeugen

mdadm -C /dev/md0 -l1 -n2 /dev/sdb1 /dev/sdc1

packt die platten sdb1 und sdc1 in ein raid1 (-l1)
-n2 = 2 raid-member

fuer ein raid5 waere das entsprechend:

mdadm -C /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1

um ein raid1 mit einer fehlenden platte
(um z.b. ein laufendes system in ein raid1 umzubauen):

Achtung.jpeg Backup anfertigen!! Es _kann_ zu einem totalverlust aller daten kommen!!
mdadm --create /dev/md0 --level 1 --raid-devices=2 missing /dev/sdc1

nun md0 als laufwerk vorbereiten, also (optional LVM) und auf die erstellte
partition (md0 oder lvm-device) ein filesystem erzeugen.
die daten (im single-user mode oder im rettungssystem(!!!)) auf das neue md0 oder lvm-device
kopieren. die boot-einstellungen bearbeiten, so dass die neuen devices benutzt werden...
ACHTUNG: die initrd muss ebenfalls neu erzeugt werden...!
neu booten, checken dass alles so gebootet wurde wie erwartet!
falls ja kann man die 'alte partition' zum raid1 hinzugefuegt werden...

/sbin/mdadm --add /dev/md0 /dev/sdb1

lvm anlegen

pysical volume erzeugen

pvcreate /dev/md0

oder ohne raid:

pvcreate /dev/hda5 /dev/hdc1 /dev/sda2

fuegt die physical volumes hinzu.

Achtung.jpeg bei der verwendung eines raid's muss das device /dev/mdX (z.B. pvcreate /dev/mdX) verwendet werden.


volume-group erzeugen

vgcreate vg1 /dev/md0

legt die volume-group 'vg1' an. name frei waehlbar


logisches volume erzeugen

lvcreate -L 10G -n <name (z.b. daten)> <vol-group (z.b. vg1)>

wenn verschluesselt werden soll:

cryptsetup -c aes-cbc-essiv:sha256 -y -s256 luksFormat /dev/<vol-grp>/<name> 
cryptsetup luksOpen /dev/<vol-grp>/<name> daten.decrypted

Physical (encrypted) /dev/<vol-grp>/<name>
Logical (unencrypted) /dev/mapper/daten.decrypted


logische volumes aktivieren

meist geschieht dies automatisch...
beim clvmd und shared storage hinten dran muss man ggf. die volume-groups finden (falls 'vgs' sie nicht anzeigt: vgscan)

# vgs
# (no output)
# vgscan
Reading all physical volumes.  This may take a while...
Found volume group "vg_foo" using metadata type lvm2
Found volume group "vg_bar" using metadata type lvm2
...

# vgs
VG                  #PV #LV #SN Attr   VSize  VFree
aello                 1   4   0 wz--n- 67,62G     0
vg_foo                1   1   0 wz--nc  1,95T  3,21G
vg_bar                1   1   0 wz--nc  1,95T     0
...

# lvscan
inactive          '/dev/vg_bar/lvol1-2' [1,95 TB] inherit
inactive          '/dev/vg_foo/lvol1' [1,95 TB] inherit
...

# vgchange -ay vg_foo
1 logical volume(s) in volume group "vg_foo" now active

bei clustered vg's benutze '-aey'
das wiederholt man fuer alle inaktive-VG's

# lvscan
ACTIVE            '/dev/vg_bar/lvol1-2' [1,95 TB] inherit
ACTIVE            '/dev/vg_foo/lvol1' [1,95 TB] inherit

done. alle aktiv!

dateisystem erzeugen

 mkfs.ext3 /dev/<vol-grp>/<name>

z.b.:

mkfs.ext3 /dev/vg1/daten

oder falls verschluesselt:

mkfs.ext3 /dev/mapper/daten.decrypted


lvm loeschen

umount [PARTITION]
cryptsetup luksClose daten.decrypted
dmsetup remove /dev/mapper/vg1-daten
lvremove /dev/vg1/daten


lvm vergroessern

groesse der volume-group anzeigen

vgdisplay zeigt volume-group an, also verbleibender/benutzter speicher etc.
ohne den optionalen parameter werden alle volume groups aufgelistet.

vgdisplay [vol-group (z.b. daten)]


logisches volume vergroessern

lvextend -L +100G /dev/vg1/daten


dm-crypt-container vergroessern

wenn verschluesselt, dann den dmcrypt-container vergroessern

cryptsetup resize  daten.decrypted


dateisystem vergroessern

danach das filesystem vergroessern...

resize2fs /dev/vg1/daten

wenn verschluesselt:

resize2fs /dev/mapper/daten.decrypted


LVM verkleinern

Achtung.jpeg Reihenfolge beachten um datenverlust zu vermeiden!!!
ANYWAY: BE SURE YOU HAVE A BACKUP!!

nachdem wir die 100G abgezogen haben bleiben noch 50GB in der partition.
diese information ist wichtig fuer die berechnung des wertes am ende des resize2fs commandos
dies ist die angabe der groesse in bloecken.

  1. dateisystem verkleinern
  2. ggf. crypted container verkleinern
  3. lv verkleinern
umount /dev/mapper/daten.decrypted
e2fsck -f /dev/mapper/daten.decrypted
resize2fs /dev/mapper/daten.decrypted 51200000

wenn verschluesselt nun:

cryptsetup resize  daten.decrypted
lvreduce -L-100G /dev/mapper/daten.decrypted
mount /dev/mapper/daten.decrypted /dest/path


Platte austauschen

alte platte raus

defekte platte aus raid entfernen

mdadm --manage /dev/md0 --fail /dev/sdd
mdadm --remove /dev/md0 /dev/sdd


wenn man (wie ich) 3 gleiche platten eingebaut hat, wie finde ich jetzt die defekte?
ich weiss, es ist sdd, aber welche physikalische platte ist das?

sdparm -i /dev/sdd
...
ST31000340AS                                        9QJ0W04D
...

oder man verwendet lshal

lshal | less

nun nach der defekten platte, also 'sdd' suchen
dann findet man ein paar zeilen weiter unten etwa sowas:

...
storage.serial = 'SATA_ST31000340AS_9QJ0W04D'  (string)
...

und hat damit die seriennummer der platte 9QJ0W04D

nun also platte raus...

neue platte rein

Falls noetig Partitionstabelle von platte sda auf neue platte sdb uebertragen:

sfdisk -d /dev/sda | sfdisk /dev/sdb

ich denke allerdings ein raid aus platten-partitionen ist eher sub-optimal!


Achtung.jpeg ACHTUNG: bei platten die bereits als raid in benutzung waren!

das magig-flag am anfang der raid-partition muss ueberschrieben werden:

dd if=/dev/zero of=/dev/sdb5 bs=1024 count=1000

bzw:

dd if=/dev/zero of=/dev/sdd bs=1024 count=1000


raid-partition zu mdX hinzufuegen bzw. ganzes device:

mdadm /dev/md0 -a /dev/sdb1

bzw:

mdadm /dev/md0 -a /dev/sdd


replication abwarten:

watch 'cat /proc/mdstat'
...
[>....................] recovery = 4.1% (40587520/976761408) finish=227.8min
...


neue platte ist groesser als die alte

nachdem man die platte wie oben beschrieben ausgetauscht hat, nutzt das raid den neuen vorhandenen platz jedoch nicht.
daher muss man es bekannt geben:

mdadm --grow /dev/md0 --bitmap none
mdadm --grow /dev/md0 --size=max


dann das PV:

pvresize /dev/md0

Raid-Status

cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sdb5[1] sda5[0]
      155999040 blocks [2/2] [UU]
 
unused devices: <none> 

ausgabe bei inconsitenz oder fehlender platte:

cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sda5[0]
      155999040 blocks [2/1] [U_]

unused devices: <none>

mit folgendem kommando kann wird die ausgabe staendig refreshed:

watch cat /proc/mdstat


LVM Snapshot/Backup

erstelle ein backup eines logischen volumes.
dies wird hauptsaechlich zum backup von mysql benutzt. ich fuehre also die
schritte, die innerhalb von mysql benoetigt werden, hier mit auf...

mysql-datenbanken locken damit die files consistent sind:

mysql> FLUSH TABLES WITH READ LOCK

dies kann einen moment dauern.
wenn das kommando durch ist, die mysql-connection offen lassen!
nun:

lvcreate -L16G -s -n dbbackup /dev/vg1/mysqlPartition

dies erzeugt eine kopie der lvm-partition die die datenbanken enthalten.
bei der groesse (-L16G) muss man natuerlich darauf achten dass partition f. die kopie
gross genug ist um die daten in /dev/vg1/mysqlPartition aufzunehmen.
danach haben wir eine kopie unserer partition /dev/vg1/mysqlPartition unter /dev/vg1/dbbackup

zurueck zur datenbank und tabellen frei geben.
falls die DB repliziert ist muss man zusaetzlich noch die log-position sichern:

mysql> SHOW MASTER STATUS;
...
mysql> UNLOCK TABLES;

nun kann man ganz gemuetlich die backup-partition mounten und die daten kopieren.
die datenbank laeuft derweil ganz normal weiter...

mount /dev/vg1/dbbackup /mnt/backup
cp /mnt/backup/mysql/* /path/to/backups

or whatever you want...
if ready, unmount the partition and destroy it...

umount /mnt/backup
lvremove /dev/vg1/dbbackup

thats it! ;-)


LVM volume group collissions

if you put a disk to another system, and the system has a volume group
of the same name as on the newly attached disk, you will run into trouble... ;-)
you will see log messages like:

[lvm] WARNING: Duplicate VG name vg00: Existing ribPzO-611T-0Cdc-SBi0-iV78-27xy-VCjaAt (created here) 
takes precedence over ribPzO-611T-0Cdc-SBi0-iV78-27xy-VCjaAt

vgrename command with UUID does not wort!!
so, renaming the first (production) VG into whatever,
then renaming the second (NON-production) VG into final name
and renaming back the first (production) VG into it's old name will solve the problem...

vgrename vg02 my_new_volume_group_name

now you can activate both and access the files on both!

perhaps you will have to change the UUID's of the pv and/or vg

pvchange --uuid /physical/volume/path
vgchange --uuid /volume/group/name