storage management (c) Till Hänisch 2003, BA Heidenheim

Transkript

1 storage management (c) Till Hänisch 2003, BA Heidenheim

2 warum? > df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda % / /dev/sda % /boot /dev/sdb % /oradata /dev/sdb % /oralog /dev/sdb % /home Platz auf devices wird üblicherweise in Partitionen aufgeteilt, deren Größe bei der Erstellung festgelegt wird. Aber: Vorhersagen sind schwierig (insbesondere, wenn sie die Zukunft betreffen), also: Bedarf ändert sich, was nun? Partition(en) sichern, löschen, neu anlegen (mit anderer Größe) oder?

3 device layout "klassiche" Partitionen auf devices /dev/hda /dev/hdb Part1 Part2 Part1 Part2 /dev/hda1 /dev/hda2 /dev/hdb1 /dev/hdb2 Jedes device besteht aus Blöcken gleicher Größe Zusammenhängende (!) Bereiche werden zu Partitionen zusammengefaßt. Deren Größe kann deshalb nicht (ohne weiteres) nachträglich geändert werden

4 Virtualisierung Volumegroup /dev/vg1 erscheint als ein (logisches) device, enthält mehrere physikalische /dev/hda /dev/hdb enthält logical Volumes (entspricht Partitionen) LV1 LV2 LV3 LV1 Mehrere devices werden zu Volumegroups zusammengefaßt. Diese bestehen aus Extents gleicher Größe (übl. z.b. 1MB), die logical Volumes zugeordnet werden. Die Extents eines logical Volumes können über die gesamte Volumegroup verteilt sein, insbesondere kann die Größe der logical Volumes nachträglich geändert werden. Lösung unseres Problems von vorher: lvextend -L +100 /dev/vg_usr/home logical volume manager bilden eine Abstraktionsschicht zwischen physikalischen und logischen devices

5 und weiter Platten auf Server2 sind voll, auf Server1 und Server3 wäre noch Platz, was nun? aus: [Troppens2003]

6 Virtualisierung contd. devices werden nicht (lokal) einem Server zugeordnet, sondern über ein spezielles Netzwerk allen zur Verfügung gestellt (später mehr) Storage Area Networks bilden eine Abstraktionsschicht zwischen devices und Servern aus: [Troppens2003]

7 LVM verwenden Beispiel unter Linux, bei anderen aber gleiches Prinzip 1. LVM initialisieren, devices werden auf existierende Volumegroups untersucht und Informationen in /etc/lvmtab (usw.) gespeichert susi:~ # vgscan vgscan -- reading all physical volumes (this may take a while...) vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created vgscan -- WARNING: This program does not do a VGDA backup of your volume group 2. Physical Volume auf einer Partition anlegen susi:~ # pvcreate /dev/hdb3 pvcreate -- physical volume "/dev/hdb3" successfully created

8 3. Volumegroup vg_usr anlegen (hier nur ein physical volume, aber auch mehrere möglich) susi:~ # vgcreate vg_usr /dev/hdb3 vgcreate -- INFO: using default physical extent size 4 MB vgcreate -- INFO: maximum logical volume size is Gigabyte vgcreate -- doing automatic backup of volume group "vg_usr" vgcreate -- volume group "vg_usr" successfully created and activated 4. logical volumes anlegen, hier homes in vg_usr mit initialer Groesse 1GB susi:~ # lvcreate -L1000M -nhomes vg_usr lvcreate -- doing automatic backup of "vg_usr" lvcreate -- logical volume "/dev/vg_usr/homes" successfully created 5. Filesystem erzeugen, mounten, verwenden... susi:~ # mkfs -t ext2 /dev/vg_usr/homes susi:~ # mount /dev/vg_usr/homes /home...

9 Konsistenz von Backups Problem: Backup wird normalerweise (wann nicht?) auf Dateiebene durchgeführt, d.h. Verzeichnisbaum wird durchlaufen und gefundene Dateien werden nacheinander gesichert. Großes Dateisystem --> dauert lange Was passiert bei Änderungen während das backup läuft? (Konsistenz zwischen und innerhalb von Dateien - open-file-problem) Lösung: Ein snapshot ist eine (virtuelle) Kopie des ganzen Dateisystems zu einem Zeitpunkt auf Blockebene virtuell: kopiert wird erst bei Änderung (Copy On Write)

10 Snapshot Original snapshot, zunächst leer Schreibzugriff z.b. auf Block 3 wird verzögert Original wird im snapshot gesichert (+ Verwaltungsinformation), erst dann wird die Änderung im Original durchgeführt

11 snapshots bei Linux # echo "HALLO" > /mnt/hallo.txt # lvcreate -L10M -s -nhome_bck /dev/vg_usr/homes lvcreate -- rounding up size to physical extent boundary "12 MB" lvcreate -- WARNING: the snapshot will be automatically disabled once it gets full lvcreate -- INFO: using default snapshot chunk size of 64 KB for "/dev/vg_usr/home_bck" lvcreate -- doing automatic backup of "vg_usr" lvcreate -- logical volume "/dev/vg_usr/home_bck" successfully created snapshot wird angelegt, wie normales logical volume, aber mit Parameter -s kopiert werden nicht ganze extents, sondern chunks (Standard 64kB - Performance!!)

12 # echo "WIE GEHTS" >> /mnt/hallo.txt # mkdir /mnt_backup # mount /dev/vg_usr/home_bck /mnt_backup mount: block device /dev/vg_usr/home_bck is write-protected, mounting read-only # cat /mnt/hallo.txt HALLO WIE GEHTS # cat /mnt_backup/hallo.txt HALLO Der snapshot (hier unter /mnt_backup gemounted) zeigt die alte Version der Datei --> Konsistenzproblem gelöst, aber: was passiert mit Daten, die nicht auf der Platte, sondern im Speicher von Applikationen sind? Entweder applikationsspezifische Lösungen (Beispiel Oracle) oder Clusterbackup