orm@doc-tcpip.org

Erstellt: August 2007 - Letzte Modifikation: Juni 2008

[ Main | Local ]


Theorie rund um den VGDA und LVM


Das Physical Volume

Was macht eine normale Platte zu einem Physical Volume (PV)?

Die Physical Volume ID (PVID), eine soft serial number. Diese wird vom System generiert und ist eine Kombination aus der Seriennummer der Maschine und dem Datum der Generierung. Die PVID wird von der ODM eingesetzt, um der physikalischen Platte das entsprechende physikalische Volumen (hdiskX) zuzuordnen.

Daher muß eine Platte, die mechanisch ausgebaut wird, vorher aus der ODM entfernt werden (rmdev -dl hdiskX) Wenn die PVID versehentlich von der Platte gelöscht wird, so kann man sie zurückschreiben.

Beim Booten liest der Disk-Configurator die PVID aus, sucht den Namen in der ODM und ordnet dann das entsprechende Harddisk Device zu. Man kann die PVID einer Platten so auslesen:

lquerypv -H /dev/hdiskX

Layout eines Physical Volumes

Ein Physical Volume ist eine Reihe von Sektoren eingeteilt. Gezählt wird dabei von 0 bis zur LPSN (Last Physical Sector Number). Die nutzbare Kapazität der Platte stellt sich also als LPSN+1 Sektoren da. Vor den für den User sichtbaren Sektoren liegen aber noch 128 Sektoren für die Verwaltung der Platte. Die Einzelheiten finden sich im Header-File /usr/include/sys/hd_psn.h.

Die wichtigsten Sektoren sind folgendermassen belegt:

Wieviele PP passen in ein Physical Volume?

Ein PP entspricht einer bestimmten Menge an Blocks auf der Platte, die logisch zusammengefasst werden. Aufgrund architektonischer Beschränkungen (der Größe der Statustabelle im VGSA) kann der LVM nur 1016 PP pro PV verwalten. Das bedeutet, daß auf einer sehr großen Platte auch die PP größer sein müßen, da die Gesamtzahl immer gleich sein muß. Auch die Zahl der PP in einer VG ist beschränkt. Dabei kann man auf einige große Platten alle technisch möglichen PP verteilen. In der Ausgabe von lsvg meine_vg kann man den Faktor ablesen:

   MAX PPs per PV: 2032                   MAX PVs:  16  
Das ist nach der Änderung mit chvg -t #n. Dabei gibt n den Faktor an, mit dem der Standard von 1016 multipliziert wird.

Volume Groups - eine Sammlung von PV

Standard ist die rootvg. Eingige Dinge sind hier anders, denn eine rootvg kann nicht importiert oder exportiert werden. Neue VGs werden mit mkvg angelegt. PVs werden integriert mit extendvg bzw. entfernt mit reducevg.

Volume Group Identifier (VGID)

Die soft serial number für die Volume Group. Mit dieser Nummer werden alle Kommandos gegen die VG abgesetzt und aus dem VGID werden die IDs der einzelnen Logical Volumes erzeugt. Zu einer VG gehört eine Major Number. Diese kann man explizit angeben (mkvg -V majornumber) oder man läßt das System wählen. Wichtig ist, daß die Major Number im Cluster gleich sind. NFS nutzt die Major Number in seinem Filehandle, daran sollte man speziell bei Crossmounts denken.

Volume Group Status Area (VGSA)

Hier wird der Status aller allokierten Physical Partions (PP) auf allen Physical Volumes (PV, vulgo Platte) der Volume Group (VG) verzeichnet. Hier sind die stale Partitions gepflegt (also die nicht synchronisierten) und es wird die Zuordnung Logical Partition (LP) zu PPs im Rahmen des Mirroring angegeben.

Dabei ist für jedes PV der VG ein Eintrag mit 127 Byte vorgesehen. Das sind dann 1016 PP, pro Byte 8 PP. Wenn eine PP nicht geschrieben werden kann, so wird ein Flag gesetzt. Die PP ist dann "stale" (das Bit ist dann auf 1 gesetzt). Stale PPs werden nicht ausgelesen oder geschrieben.

Volume Group Descriptor Area (VGDA)

Hier findet sich die Information rund um die VG, die Logical Volume in der VG und die Physical Volumes die die VG bilden. Der VGDA ist wichtig für das Quorum, und damit für den Import der VG. Das Quorum bestimmt die Anzahl der gültigen VGDAs, die vorhanden sein müssen, damit eine VG importiert werden kann. Ein VGDA reicht, um eine VG zu importieren. Es werden die PVIDs der nötigen Platten ausgelesen und dann importiert. Will man also eine VG importieren (importvg Kommando), so muß man nur eine Platte (PV) angeben. Der Rest wird aus dem VGDA ausgelesen und in die ODM geschrieben.

Wird ein LV der VG modifiziert, so wird der VGDA auf allen Platten entsprechend modifiziert.

Man kann VGs von einem System an ein anderes hängen (Kommando ist importvg). Das System liest damit den VGDA einer Platte aus und erfährt so, welche PVs und LVs zur VG gehören. Diese Information wird in der ODM gespeichert und die entsprechenden Files bzw. Einträge werden in /dev und /etc/filesystems erzeugt. Im ersten Schritt wird die PV Information ausgewertet, dann die LV Information. Dabei wird der LVCB gelesen und das JFS Logging aufgesetzt. Namenskonflikte (gleiche LV Namen) werden gelöst.

Der VGDA besteht aus diesen Teilen:

Der VGSA und VGDA sind folgendermassen gegliedert (In Klammern Angaben für die BigVG):

Block/Sektor
128	VGSA
	Zeitstempel
	PV Missing Flag (Platte kann "active" oder "missing" sein)
	Stalemap 127* 8 Bit pro Record (für je 8 PV - eine Map pro PV)
	VGSA Faktor (t-Faktor)
	VGSA Version
	Reserved
	Zeitstempel am Ende des VGSA

136	VGDA Header
(384)	Zeitstempel für einen Konsistenz-Check
	VGID
	Anzahl der LV
	Maximum Number of LV 128 (512)
	PP Size 2^x (20-30 für x)
	Anzahl der PV
	Anzahl der VGDAs
	VGDA Size 2098 (8242)
	BigVGDA Flag
	Quorum On/Off
	Autovaryon Yes/No
	VGDA Checksum
	Reserviert
Pro Logical Volume ein LV Header
	Logische Nummer des LV
	Zeiger auf die Namensliste
	Maximale Größe des LV
	Status des LV: open/closed sync/stale
	Anzahl der Spiegelkopien
	Mirror Write Policy3
	Anzahl der LP für diese LV
	Flag für read/write
	Bad Block Relokation gewünscht? (Flag)
	Write Verify
	MWC Flag
	Stripe flag
	Stripe Weite
	Spezielle File Permissions
	Logical Volume Control Block
Pro Physical Volume ein PV Header
	PVID
	Anzahl der phys. Partitionen
	Status des PV active/missing
	Anzahl der VGDA auf der Platte
	Mapping der LVs auf die PP der Platte
	Reserviert
Namens Liste    Mappt die LV Nummern auf die Namen
VGDA Trailer    Concurrency Flag
		Zweiter Zeitstempel zur Konsistenzprüfung

2242 	zweiter VGDA (analog erstem VGDA)
(8906)	

Die Physical Partition Map ist begrenzt. Daher kann es vorkommen, das bei großen PV nicht alle Physical Partions gemappt werden können.

Jedes PV hat zwei VGDA. Sie werden aber nicht immer beide ausgewertet:

Logical Volumes

Teile verschiedener phys. Volumes, die das System als eine logische Einheit betrachtet. LVs zeigen ein virtuelles Laufwerk mit zusammenhängenenden logischen Partitionen - was physikalisch nicht so sein muß.

Alle Information über ein LV ist im VGDA - ein LV kann also nur in einer VG existieren. Es kann aber gezielt auf den PVs der VG verteilt sein.

Ausserdem kann man ein LV spiegeln (innerhalb einer VG) und zugleich stipen (in verschiedenen Stripe-Größen).

Spezielle LV sind:

Log LV - JFS
Dump - für System Dumps
Boot - Startinformation des Systemes
Paging - Zum Auslagern einzelner Memory Seiten durch den VMM.

Normale LV sind JFS und Raw Logical Volumes. Journaled Filesystem: Eine Sammlung von 4 KB großen Blocks.

Stanzas in der ODM

In der ODM werden Stanzas angelegt für das PV, die VG und das LV. Die angegeben Informationen werden dabei nicht immer in einer eigenen Stanza abgelegt, sondern sind abgeleitet - zB. ist die Größe der VG die Summe der Plattengrößen.

Für das PV:
	Adapter Attribute
	SCSI/SSA Attribute
	Größe in MB
	PVID
	Major/Minor Number

Für die VG:
	VGID
	alle PVIDs, die diese VG bilden
	Größe in MB
	VG Zeitstempel
	alle LV dieser VG
	Status
	Major/minor Number

Für das LV:
	LVID
	Weite des Stripe
	Größe der PPs
	Label (Name bzw. Mountpoint)
	Status
	Major/Minor Number

Auf der Maschine

Beim Anlegen der VG werden folgende Files in /dev kreiert. Alle bekommen dieselbe Major-Number, es gibt ein Character-Device für die VG und den "Mount" Point der VG (immer eine Kombination von 2 Unterstrichen, "vg" und der Major Number). Für jedes LV gibt es ein Character- und ein Block-Device (ausser bei Raw-Logical Volumes). Das Character-Device wird durch ein vorgestelltes "r" bezeichnet.

Beispiel:
crw-------   1 root     system      100,  0 Apr 13 22:06 __vg100
crw-rw----   1 root     system      100,  0 Apr 11 15:02 db1_vg
brw-rw----   1 4996     db2adm      100,  4 Apr 11 15:04 dms_01_lv
brw-rw----   1 4996     db2adm      100,  5 Apr 11 15:04 dms_02_lv
brw-rw----   1 4996     db2adm      100,  8 Apr 11 15:05 home_lv
crw-rw----   1 4996     db2adm      100,  8 Apr 11 15:05 rhome_lv
brw-rw----   1 4996     db2adm      100,  3 Apr 11 15:04 sms_01_lv
crw-rw----   1 4996     db2adm      100,  3 Apr 11 15:03 rsms_01_lv
brw-rw----   1 4996     db2adm      100,  2 Apr 11 15:03 test1_lv
crw-rw----   1 4996     db2adm      100,  2 Apr 11 15:02 rtest1_lv
brw-rw----   1 root     system      100,  1 Apr 11 15:02 vg1_jfslog1
crw-rw----   1 root     system      100,  1 Apr 11 15:02 rvg1_jfslog1

Logical Volume Control Block LVCB

LVID aus der VGID der VG und der Minor Number des 
Device Files, das das LV beschreibt.
LVCB sind die ersten 512 Byte des LV. 
Enthält: Creation Date, Spiegelkopien des LV (mirrored copies), Mount Points
(/usr/sbin/getlvcb)

Logical Partitions - Ein LV besteht aus einer Reihe logischer Partitionen
(die ihrerseits auf eine oder mehrere - im Fall einer Spiegelung - 
physikalische Partitionen weisen). Die LP sind aufsteigend durchnummeriert - 
die PP kommen beliebig. Das wird durch die "Allocation Policy" bestimmt. 
Hier wird festgelegt, wie das LV auf der Platte liegen soll.

Inter physical volume allocation policy - Wo liegen die PP, die über die
entsprechenden LP einem LV zugeordnet sind ==> Plattengeometrie
(outer edge, middle, center, inner middle, inner edge)

Intra physical volume allocation policy - Über welche PVs werden diese 
der LV verteilt.
Das kann man weiter einengen:
strict allocation policy - Sollen Kopien dieser LP auf verschiedenen
Platten liegen.
strict - nein
notstrict - ja
superstrict - bei mehreren Kopien eines LV müßen diese auch getrennt sein.

Scheduling - Wie sollen die PP geschrieben werden, wenn es mehrer Kopien gibt.
Parallel - zugleich beide schreiben
Sequentiell - nacheinander

Mirror Write Consistency - Sichert die Konsistenz der Daten zwischen
gespiegelten Kopien eines LV bei normalem IO. Sollte das System crashen, 
dann kann man im Cache die LP finden, die gerade geschrieben wurden und 
gezielt prüfen.

Write Verify - Status für die Schreibprüfung des LV:
y== Alle Schreibzugriffe werden beim nächsten Schreiben geprüft.
n== werden nicht geprüft
Map files - man kann explizit die Zuordnung LP - PV (PP) bestimmen.
(mklv -t jfs -y ros_lv -c 2 -m ./mapfile
Bad Block Relocation - sollen beschädigte Blöcke in das BBR Direktory
ausgelagert werden?

Beziehung ODM - VGSA/VGDA

Die Kommandos lsvg, lspv und lslv greifen direkt auf die Platte zu und lesen den VGDA. Sie nutzen die ODM, um den VG-Namen auf die VGID umzusetzen, bzw. um LVs und PVs zuzuordnen.

Die Dateien in /etc/vg/vg* dienen zum Synchronisieren der Daten.

Es gibt einen Locking Mechanismus in der ODM. Man kann dort im VG-Eintrag ein Lock setzen bzw. entfernen. Alle Low-Level Kommandos nutzen diesen Mechanismus. Bleibt das Lock stehen, so kann man es mit dem Kommando putlvodm -K VGID wieder entfernen.

Auch ein varyonvg gegen die VG hilft, den auch dann wird das Lock gebrochen. Man kann das varyonvg-Kommando problemlos gegen eine schon aktive VG einsetzen.

Setzen kann man das Lock mit putlvodm -k VGID

Quorum

Mit den Kommandos varyonvg und varyoffvg wird eine im System angelegte bzw. definierte VG zugänglich (aktiviert) - bzw. deaktiviert. Es müßen mehr als die Hälfte der Quorum-Stimmen vorliegen (also auf den PVs muß man den VGDA lesen können) - sonst stellt der LVM seine Dienste ein und die VG kommt nicht online.

Dabei spielt das Quorum eine Rolle: Ist das Quorum angeschaltet, so muß mehr als die Hälfte der VGDAs zugänglich sein. Dadurch wird sichergestellt, das mindestens eine Kopie des VGDA aktuell ist. Man kann einen varyon erzwingen, wenn man den Schalter -f benutzt oder die Variable MISSING_PV_VARYON auf "TRUE" setzen (/etc/environment) Das ist aber gefährlich... Platten, die nicht hochkommen, werden als removed angegeben.

Alle Stanzas einer VG

In CuAt der Name sowie die "soft serial Number" der VG.
CuAt:
        name = "taddm_vg"
        attribute = "vgserial_id"
        value = "000414f90000d6000000011a49041f82"
        type = "R"
        generic = "D"
        rep = "n"
        nls_index = 637
Gesetzte Eigenschaften der VG.
CuAt:
        name = "taddm_vg"
        attribute = "auto_on"
        value = "n"
        type = "R"
        generic = "DU"
        rep = "l"
        nls_index = 638

CuAt:
        name = "taddm_vg"
        attribute = "quorum"
        value = "n"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0

CuAt:
        name = "taddm_vg"
        attribute = "conc_capable"
        value = "y"
        type = "R"
        generic = "DU"
        rep = "l"
        nls_index = 0
Der Zeitstempel der VG.
CuAt:
        name = "taddm_vg"
        attribute = "timestamp"
        value = "484678481ad1c827"
        type = "R"
        generic = "DU"
        rep = "s"
        nls_index = 0
Für jedes PV, was zur VG gehört, ein Eintrag mit PVID.
CuAt:
        name = "taddm_vg"
        attribute = "pv"
        value = "000414f9bbd646fb0000000000000000"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0
In CuDv ein Eintrag mit der Art des Device.
CuDv:
        name = "taddm_vg"
        status = 0
        chgstatus = 1
        ddins = ""
        location = ""
        parent = ""
        connwhere = ""
        PdDvLn = "logical_volume/vgsubclass/vgtype"
Pro LV dieser VG die "soft serial number" des LV.
CuAt:
        name = "taddm_home_lv"
        attribute = "lvserial_id"
        value = "000414f90000d6000000011a49041f82.5"
        type = "R"
        generic = "D"
        rep = "n"
        nls_index = 648
Gesetzte Attribute für dieses LV: Copy-count, Strictness und Upperbound. 
CuAt:
        name = "taddm_home_lv"
        attribute = "copies"
        value = "2"
        type = "R"
        generic = "DU"
        rep = "r"
        nls_index = 642

CuAt:
        name = "taddm_home_lv"
        attribute = "strictness"
        value = "s"
        type = "R"
        generic = "DU"
        rep = "l"
        nls_index = 645

CuAt:
        name = "taddm_home_lv"
        attribute = "upperbound"
        value = "1"
        type = "R"
        generic = "DU"
        rep = "r"
        nls_index = 646

Das Label (der Mountpoint) des LV. Raw LVs haben sowas nicht.
CuAt:
        name = "taddm_home_lv"
        attribute = "label"
        value = "/home/taddmsrv"
        type = "R"
        generic = "DU"
        rep = "s"
        nls_index = 640
Der Typ des Filesystemes.
CuAt:
        name = "taddm_home_lv"
        attribute = "type"
        value = "jfs2"
        type = "R"
        generic = "DU"
        rep = "s"
        nls_index = 639
In CuDv wird dem Device "LV" der Typ zugeordnet.
CuDv:
        name = "taddm_home_lv"
        status = 0
        chgstatus = 1
        ddins = ""
        location = ""
        parent = "taddm_vg"
        connwhere = ""
        PdDvLn = "logical_volume/lvsubclass/lvtype"
In CuDep wird eine gegenseitige Abhängigkeit der VG zum LV gesetzt.
CuDep:
        name = "taddm_vg"
        dependency = "taddm_home_lv"
Pro PV gibt es weitere Einträge. Hier wird die PVID
einem logischen Device (hdisk1) zugeordnet.
CuAt:
        name = "hdisk1"
        attribute = "pvid"
        value = "000414f9bbd646fb0000000000000000"
        type = "R"
        generic = "D"
        rep = "s"
        nls_index = 2
In CuDv wird das Device definiert (hier eine SAN Platte).
CuDv:
        name = "hdisk1"
        status = 1
        chgstatus = 2
        ddins = "scsidisk"
        location = "05-08-02"
        parent = "fscsi1"
        connwhere = "W_1"
        PdDvLn = "disk/fcp/2107"

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]

Copyright 2001-2021 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )