LVM
Inhaltsverzeichnis
future comments
since luks is outdated:
in future use eCryptfs https://launchpad.net/ecryptfs
pakete
apt-get install lvm2 cryptsetup mdadm
platte partitionieren
# parted -a optimal /dev/sdb (parted) mklabel gpt (parted) mkpart primary 2048s 100% (parted) align-check optimal 1 1 aligned (parted) set 1 raid on (parted) print Model: ATA WDC WD30EFRX-68E (scsi) Disk /dev/sdb: 3001GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 3001GB 3001GB primary raid (parted) quit Information: You may need to update /etc/fstab.
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):
 |
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.
| |
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
for XFS:
xfs_growfs /mount/point -D size
leave out '-D size' to grow to max available
Be aware of xfs_growfs expects the mount-point not the device file
lvm vergroessern VMWARE
resize disk
resize disk in VMWare
Rescan Disk
# ls -la /dev/disk/by-path |grep sdb lrwxrwxrwx 1 root root 9 13. Mai 08:54 pci-0000:03:00.0-scsi-0:1:0:0 -> ../../sdb
echo 1 > /sys/class/scsi_disk/0\:1\:0\:0/device/rescan
resize PV
| |
use this if you donot have a partition but using the entire disk sdb and not sdb1 |
# pvresize /dev/sdb
Your PV is resized, your done.
Extend your LV now.
create new PV (if resizing does not work)
| |
if you have a partition such as sdb1 |
create new partition e.g. sdb2
# fdisk /dev/sdb
Make the kernel aware of the changes to the partition table:
# partprobe
Create new PV
# pvcreate /deb/sdb2
Add PV to existing VG
# vgextend VolGroup /dev/sdb2
Your PV is resized.
# pvscan
Extend volume now.
LVM verkleinern
| |
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.
- dateisystem verkleinern
- ggf. crypted container verkleinern
- 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: 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
