Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:linux:lvm_index:lvm-grundlagen [2023/02/10 08:37] – [Logical Volumes (LVs)] marko
+++ it-wiki:linux:lvm_index:lvm-grundlagen [2023/02/11 07:24] (aktuell) – [Anleitungen und Konfigurationen] marko
@@ Zeile 4: / Zeile 4: @@
 Dieser Artikel zeigt wie LVM unter Linux implementiert ist.
-===== Physical Volumes (PVs) =====
 ----
+===== Physical Volumes (PVs) =====
 Ein PV wird immer durch ein Block-Device repräsentiert - z.B. eine Festplatte (Device) oder eine Partition. Wird eine Partition bzw. ein Device als PV initialistiert, so wird das Block-Device mit einem LVM-Label gekennzeichent und mit Metadaten versehen. Das LVM-Label identifiziert das Block-Device als PV, es beinhaltet den Random Unique Identifier (UUID), es speichert die Größe des Devices in Bytes und es zeichnet auf, wo sich die Metadaten befinden.
-{{ :it-wiki:linux:lvm_index:lvm-aufbau.png?direct&200|}}
+{{ :it-wiki:linux:lvm_index:lvm-aufbau.png?direct&200|Aufbau PV-VG-LV}}
 Die Metadaten werden für die genaue Beschreibung der Konfiguration der Volume Groups benötigt. Standardmäßig wird eine identische Kopie der Metadaten auf den PVs einer VG gespeichert. Beim Anlegen einer PV ist es möglich zu definieren, dass 0,1 oder 2 Kopien von Metadaten gespeichert werden - ist diese Zahl einmal definiert, kann sie nicht mehr geändert werden. Die mehrfache Speicherung der Metadaten soll vor einer irrtümlichen Überschreibung schützen. Auch die Größe des Metadatenbereichs kann beim Anlegen eines PVs geändert werden. Unter Umständen kann dieser Bereich nämlich zu klein werden, was zu Problemen führen kann, da die Größe nachträglich nicht mehr geändert werden kann: [[it-wiki:linux:lvm_index:vm_vg_vgname_metadata_too_large_for_circular_buffer_beheben|LVM VG vgname metadata too large for circular buffer beheben]].
 Ein PV wird bei der Erstellung in lauter kleine, gleich große Stückchen unterteilt, den sogenannten Physical Extents (PEs). Diese PEs sind die kleinst mögliche Datenmenge, die allokiert werden kann und beträgt standardmäßig 4 MiB, kann aber beim anlegen der darauf aufsetzenden Volume Group geändert werden. Seit dem lvm2-Format ist die Anzahl der PEs nicht mehr beschränkt, laut Man-Page von vgcreate kann eine hohe Anzahl an PEs die bereit gestellten Tools verlangsamen. Die I/O-Performance wird aber nicht beeinträchtigt.
-===== Volume Groups (VGs) =====
 ----
+===== Volume Groups (VGs) =====
 Eine oder mehrerere PVs können zu einer oder mehreren VGs zusammengefasst werden. Diese VG stellt einen Pool an Datenspeicher dar, aus dem später Logical Volumes allokiert werden können. Der verfügbare Speicher einer VG wird dabei in kleine, gleich groß bleibende Teile unterteilt - den Logical Extents. Diese stellen das Pendant zu den PEs auf PV-Ebene dar. Die Aufgabe der VG ist es, die **Logical Extents** den Physical Extents richtig zuzuordnen. Durch diese Gruppierung in einer Zwischenschicht können auch PEs von unterschiedlichen Devices in einer VG zusammengefasst werden.
-===== Logical Volumes (LVs) =====
 ----
+===== Logical Volumes (LVs) =====
 VGs werden in eine oder mehrere LVs aufgeteilt, auf denen anschließend die Dateisysteme aufsetzen. Von LVs können drei verschiedene Arten angelegt werden:
-{{ :it-wiki:linux:lvm_index:linear-lvm.png?direct&200|}}
+{{ :it-wiki:linux:lvm_index:linear-lvm.png?direct&200|Aufbau eines linearen LVs}}
-  - Linear Volumes: Eine geordnete Zusammenfassung von PEs zu einem LV. Die Größe der darunter liegenden PVs muss nicht gleich sein, sie werden konsolidiert an die LVs weiter gegeben. Des weiteren muss ein LV nicht zwangsweise aus einer VG bestehen. Es können genauso mehrere LV aus einer VG heraus kreiert werden, solange die VG noch Speicherplatz zur Verfügung stellen kann. Die Größen der erzeugten LV können dabei auch unterschiedlich sein, haben minimal aber die Größe eines PE.
+  * Linear Volumes: Eine geordnete Zusammenfassung von PEs zu einem LV. Die Größe der darunter liegenden PVs muss nicht gleich sein, sie werden konsolidiert an die LVs weiter gegeben. Des weiteren muss ein LV nicht zwangsweise aus einer VG bestehen. Es können genauso mehrere LV aus einer VG heraus kreiert werden, solange die VG noch Speicherplatz zur Verfügung stellen kann. Die Größen der erzeugten LV können dabei auch unterschiedlich sein, haben minimal aber die Größe eines PE.
+{{ :it-wiki:linux:lvm_index:striped-lvm.png?direct&200|Aufbau eines striped LVs}}
+  * Striped Volumes: Wie bei RAID 0 werden die Daten des LVs abwechselnd auf die die PVs aufgeteilt. Dies kann unter Umständen die Performance erhöhen, nicht aber die Ausfallssicherheit. Aufbau eines striped LVs Die Abbildung "Aufbau eines striped LV" zeigt, wie die Stripes 1 bis 6 sequentiell auf die darunterliegenden PVs geschrieben werden. Dabei kann es sein, dass einzelne I/O-Operationen parallel getätigt werden können und somit der Schreibvorgang schneller erledigt wird.
+  * Mirrored Volumes: Ähnlich zu RAID 1 werden bei Mirrored Volumes die Daten auf die darunter liegenden Devices gespiegelt. Es können dabei auch mehrere Spiegelungen auf verschiedene, sogenannte "Legs" aufgeteilt werden. Das zu kopierende Device wird dabei in sogenannte "Regions" unterteilt, die bei Änderungen synchronisiert werden. Die Größe dieser Regions ist standardmäßig 512KB, kann aber auch verändert werden.
+----
+===== LVM und Device Mapper =====
+Seit dem Linux Kernel 2.6 ist LVM mithilfe des Device Mappers implementiert. LVM verwendet dabei das linear Device Mapper Target.
+----
+===== Vorteile bei der Verwendung von LVMs =====
+|Flexible Kapazitäten|Mehrere Festplatten können zu einem LV zusammengefasst werden.|
+|Änderungen der Größe| LVs können erweitert bzw. verkleinert werden, ohne dass die darunter liegenden Devices neu formatiert oder partitioniert werden müssen.|
+|Reallokierung von Daten im laufenden Betrieb|Daten können im laufenden Betrieb neu angeordnet werden. Dies kann z.B. hilfreich sein, wenn eine hot-swapable Disk getauscht wird.|
+|Disk Striping|Daten können über mehrere Devices verteilt werden ("Gestriped"), was die Performance erhöhen kann, aber nicht zur Ausfallssicherheit beiträgt.|
+|Data Mirror| Daten können einfach gespiegelt werden.|
+|Volume Snapshots|Es können von einem Device Snapshots erstellt werden, z.B. um von den Snapshots Sicherungen zu erstellen|
+----
+===== Nachteile bei der Verwendung von LVMs =====
+  * Liegen die Daten verteilt auf verschiedenen Devices ("Striping"), so erhöht sich die Gefahr eines Ausfalls der Platten. Dies ist kann nur bedingt als Nachteil von LVM selbst angesehen werden, da es sich eigentlich um eine Designentscheidung beim Aufbau der Speicherarchitektur handelt.
+  * Um Zugriff auf die Daten über Live-CDs zu erhalten müssen diese die Verwaltung von LVMs unterstützen. Grundsätzlich wird zur Zeit der Zugriff auf LVMs nur von Linux unterstützt.
+  * Die alte Grub-Version konnte nicht auf LVM's benutzt werden, es war daher eine eigene, nicht-LVM boot-Partition nötig. GRUB 2 verlangt dies nicht mehr.
+----
+===== Anleitungen und Konfigurationen =====
+  - http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/metadata_contents.html
+  - [[http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/physical_volumes.html|CentOS LVM Dokumentation]]
+  - http://docs.hp.com/en/B2355-90672/ch03s06.html
+  - [[http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mirror_create.html|Red Hat 6 Dokumentation LVM Mirror Create]]
+  - [[http://en.wikipedia.org/wiki/LVM2#Implementation|LVM2 - Implementation (en.wikipedia.org)]]
+  - [[http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/logical_volumes.html|Red Hat 6 Dokumentation LVMs]]
+  - http://wiki.ubuntuusers.de/Logical_Volume_Manager
+  - http://grub.enbug.org/LVMandRAID
+\\
+\\
+\\
+ --- //[[marko.oldenburg@cooltux.net|Marko Oldenburg]] 2023/02/11 08:23//