close Warning: Can't synchronize with repository "keplertools" (/srv/svn/keplertools does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 14 years ago

Closed 14 years ago

#898 closed Aufgabe (erledigt)

LVM-Snapshots verstehen

Reported by: Rüdiger Kupper Owned by: Rüdiger Kupper
Priority: bald erledigen Milestone: Schuljahr 2012/13
Component: Server: Linux Terminal Server (LTSP) Severity: beeinträchtigt keinen Unterricht
Keywords: Cc: bau

Description

Ich möchte verstehen, wie folgende LVM-Features funktionieren:

  • LVM-Snapshots (Priorität)
  • LVM-Striping (weniger wichtig)

-> Dazu werde ich ein VirtualBox-Setup mit LVM verwenden.

Change History (7)

comment:1 by bau, 14 years ago

Holger schreibt da was nützliches unter ​http://www.linuxmuster.net/anwenderwiki:virtualisierung:kvm:kvm_ubuntu1204?s[]=libvirt#backup_mittels_lvm_snapshot_und_einem_qnap_nas

Ganz gut beschreibt das auch ​http://www.howtoforge.com/linux_lvm_snapshots und ich hatte noch eine deutsche Seite, die ich aber leider nicht mehr finde, wo der Autor sehr schön beschreibt, wie ein LVM im Echtzeitbetrieb angelegt wird und dann LVM Änderungen im LVolume dort vornimmt aber die "Datei" vorher ins Snapshot kopiert und dann ändert. Greift man dann auf das Original zu, so hat man die geänderte Version, mountet man das Snapshot, so erhält man die ursprüngliche Version.

comment:2 by Rüdiger Kupper, 14 years ago

Prinzip ist hier beschrieben: ​http://en.wikipedia.org/wiki/Logical_volume_management#Snapshots:
Alle Daten in LVM sind in Blöcken ("Logical Extents") organisiert. Wird von einem LV ein Snapshot angefordert, werden alle beteiligten Logical Extents auf "copy-on-write" gesetzt. Wird anschließend auf das LV geschrieben, wird eine Kopie des LE gesichert, wie sie vor dem Schreibzugang war. Mit hilfe dieser Kopien können zu jedem Zeitpunkt zwei Versionen des LV regeneriert werden:

  • die aktuelle Version
  • die Version zum Zeitpunkt, als der Snapshot angefordert wurde.

Zentral ist dabei das Konzept, copy-on-write auf LE-Basis zumachen. D.h., dass der Snapshot nur in dem Maße zusätzlichen physikalischen Plattenplatz benötigt, wie nach Anforderung des Snapshots auf das LV geschrieben wird.
Das Verfahren ist analog den "differential images" bei VirtualBox.

comment:3 by Rüdiger Kupper, 14 years ago

Status: new → accepted

comment:6 by Rüdiger Kupper, 14 years ago

Okay, Snapshots habe ich jetzt verstanden. Das Ltsp-Setup-Skript sollte beim Klonen des Filesystems von einem laufenden Server am besten einen LVM-Snapshot verwenden. -> #918.

comment:7 by Rüdiger Kupper, 14 years ago

Resolution: → erledigt
Status: accepted → closed
Zu LVM-Striping
Entspricht einem RAID0. Siehe ​http://docs.huihoo.com/redhat/rhel-5-manual/Cluster_Logical_Volume_Manager/striped_volumes.html Ein Vergleich hier: ​https://lists.uni-koeln.de/pipermail/linux-users/2007-August/011798.html)
Zu LVM-Mirroring
Entsprecht einem RAID1. Siehe ​http://docs.huihoo.com/redhat/rhel-5-manual/Cluster_Logical_Volume_Manager/mirrored_volumes.html

Offenbar zielen die LVM-Entwickler darauf ab, die Funktion von md in lvm aufzunehmen.
Wenn das mal gut funktioniert, wäre das natürlich schön, weil man sich dann nicht mit einem Doppelsystem aus RAID und LVM rumschlagen müsste, sondern nur noch LVM bräuchte. Momentan traue ich dem aber noch nicht über den Weg. md gilt im Vergleich dazu als inzwischen sehr stabil.

Note: See TracTickets for help on using tickets.