| orm@doc-tcpip.org | Erstellt: August 2007 - Letzte Modifikation: Juni 2008 |
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
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:
Bootrecord. Hier steht die PVID und die Information, die es dem ROS (Read Only Storage, RS6000 bzw. PSeries BIOS) ermöglicht, die Platte zu initialisieren. Das Headerfile ist: /usr/include/sys/bootrecord.h
Configuration
MWC Cache (Mirror Write Consistency). Hier wird ein Flag für jede nicht konsistente Physical Partition abgelegt. Beim varyon werden diese geflagten PP dann synchronisiert.
LVM. Dieser Sektor wird geschrieben, wenn die Platte in eine VG aufgenommen wird. Hier steht die LVM ID, die Größe des VGDA und der Offset, nach dem am Ende der Platte Sektoren zur Bad-Block Relokation vorgehalten werden. Das Headerfile ist: /usr/include/lrmrec.h
Bad Block. Zeigt auf das Bad Block Directory. Hier stehen alle Blocks, die defekt sind und relokiert wurden. Es wird ein Grund angegeben, der logische Sektor und der relokierte Sektor. Das Header-File ist: /usr/include/sys/bbdir.h
Länge des BB Directory.
Backup des Configuration Records.
LVM Backup Backup des LVM Records.
Backup des Bad Block Directories.
Concurrent Configuration Work Directory. Zwischenspeicher für Konfigurations-Operationen, eine Art "scratch pad" für Arbeiten an der Platte.
128 Erster, nicht reservierter Block. Hier beginnen das Volume Group Status Area (VGSA) und das Volume Group Descriptor Area (VGDA). Ab hier bis zum Bereich für die Bad Block Relokation ist der für den User nutzbare Bereich der Platte.
Dieser Bereich ist in "Physical Partitions" (PP) eingeteilt. Die Größe eines PP ist variable, je nach Plattengröße und AIX Version sind verschiedene Größen möglich. AIX 4.3 unterstützt z.B. PP von je 1, 2, 4, 8 .... 1024 MB. Beim Anlegen einer VG kann man die Größe setzen (mkvg -s). Ein PV, das einer bestehenden VG zugeordnet wird, erbt die PP Size dieser VG.
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: 16Das ist nach der Änderung mit chvg -t #n. Dabei gibt n den Faktor an, mit dem der Standard von 1016 multipliziert wird.
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.
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.
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.
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:
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.
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
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
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?
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
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.
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"
[ 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