Die Stelle richtet sich an Linux-Systemadministratoren, die bestehende LVM-konfigurierte Systeme anfänglich konfigurieren oder weiter optimieren möchten. Er diskutiert:
- die Notwendigkeit einer spezifischen LVM-Filterstring-Konfiguration für den jeweiligen verwendeten Speichertyp.
- Stellen Sie Beispiel-LVM-Filterzeichenfolgen für eine Vielzahl gängiger Speichergeräte bereit
LVM-Konfiguration – Filterparameter
Die primäre LVM-Konfigurationsdatei ist /etc/lvm/lvm.conf . Die Datei besteht aus mehreren Abschnitten, die jeweils verschiedene Parameter/Werte enthalten. Dieser Artikel konzentriert sich speziell auf den Filterparameter im Geräteabschnitt.
Es folgt eine beispielhafte lvm.conf-Datei:
devices {
dir = "/dev"
scan = [ "/dev" ]
obtain_device_list_from_udev = 1
preferred_names = [ ]
filter = [ "a/.*/" ]
cache_dir = "/etc/lvm/cache"
cache_file_prefix = ""
write_cache_state = 1
sysfs_scan = 1
multipath_component_detection = 1
md_component_detection = 1
md_chunk_alignment = 1
default_data_alignment = 0
data_alignment_detection = 1
data_alignment = 0
data_alignment_offset_detection = 1
ignore_suspended_devices = 0
disable_after_error_count = 0
require_restorefile_with_uuid = 1
pv_min_size = 2048
issue_discards = 0
}
log {
verbose = 0
syslog = 1
overwrite = 0
level = 0
indent = 1
command_names = 0
prefix = " "
}
backup {
backup = 1
backup_dir = "/etc/lvm/backup"
archive = 1
archive_dir = "/etc/lvm/archive"
retain_min = 10
retain_days = 30
}
shell {
history_size = 100
}
global {
umask = 077
test = 0
units = "h"
si_unit_consistency = 0
activation = 1
proc = "/proc"
locking_type = 1
wait_for_locks = 1
fallback_to_clustered_locking = 1
fallback_to_local_locking = 1
locking_dir = "/var/lock/lvm"
prioritise_write_locks = 1
abort_on_internal_errors = 0
detect_internal_vg_cache_corruption = 0
metadata_read_only = 0
}
activation {
checks = 0
udev_sync = 1
udev_rules = 1
verify_udev_operations = 0
missing_stripe_filler = "error"
reserved_stack = 256
reserved_memory = 8192
process_priority = -18
mirror_region_size = 512
readahead = "auto"
mirror_log_fault_policy = "allocate"
mirror_image_fault_policy = "remove"
snapshot_autoextend_threshold = 100
snapshot_autoextend_percent = 20
use_mlockall = 0
monitoring = 1
polling_interval = 15
}
dmeventd {
mirror_library = "libdevmapper-event-lvm2mirror.so"
snapshot_library = "libdevmapper-event-lvm2snapshot.so"
} Standardmäßig scannt LVM beim Systemstart Geräte, die durch den Filterparameter definiert sind, um LVM-Geräte zu erkennen. Verwenden Sie die obige Standardfilterzeichenfolge (filter =[ „a/.*/“ ] ), scannt LVM alle verfügbaren Geräte auf dem System. Wenn PVs entdeckt werden, werden VGs zusammengesetzt, LVs aktiviert und anschließend Dateisysteme (falls vorhanden) gemountet.
Bei Systemen mit einer beträchtlichen Anzahl angeschlossener Speichergeräte (LUNs) ist es möglicherweise nicht wünschenswert oder erforderlich, dass LVM jedes verfügbare Gerät scannt. In diesem Fall kann die LVM-Filterzeichenfolge modifiziert (optimiert) werden, um eine benutzerdefinierte Gruppe von Geräten zu scannen.
LVM und Multipathing
Abgesehen von lokalem Speicher erstellen Benutzer häufig LVM-Geräte auf SAN-Speicher. Darüber hinaus erfolgt der Zugriff auf SAN-Speicher häufig über mehrere Pfade, d. h. es existieren mehrere Pfade zu derselben SAN-LUN auf dem System. Im Fall von device-mapper-multipath, der nativen Multipath-Lösung von Oracle Linux, könnten die folgenden Geräte vorhanden sein, die alle auf dieselbe SAN-LUN verweisen:
/dev/mapper/mpath1 /dev/dm-1 /dev/sda /dev/sdb
Multipath-Implementierungen unterscheiden sich – im Fall von EMC PowerPath könnten die folgenden Geräte vorhanden sein, die alle auf dieselbe SAN-LUN verweisen:
/dev/emcpowera /dev/sda /dev/sdb
Wie bereits erwähnt, weist der standardmäßige lvm.conf-Filterstringwert LVM an, alle angeschlossenen/verfügbaren Geräte zu scannen. Leider kann dies problematisch sein, wenn LVM in Verbindung mit Multipathing verwendet wird. Abhängig von der Erkennungsreihenfolge der Geräte (Pfade) kann LVM letztendlich Singlepath-Geräte verwenden, z. /dev/sd[a,b] um VGs zu erstellen, anstatt das beabsichtigte Multipath-Gerät zu verwenden, z. /dev/mapper/mpath1. Wenn dies auftritt, erhält das LVM-Gerät nicht die Vorteile des Multipathing, d. h. Pfadverlustredundanz, Hochverfügbarkeit usw. Dasselbe Problem gilt in ähnlicher Weise für Systeme, die mit Booten von SAN konfiguriert sind.
Meldungen wie die folgenden werden normalerweise beobachtet, wenn LVM-Systeme, die Multipath verwenden, nicht optimal konfiguriert sind, um Singlepath-Geräte auszuschließen:
# pvs Found duplicate PV Yvq85ssLqAXeBvZpVtAqBIbm44KU8cd5: using /dev/dm-1 not /dev/sda Found duplicate PV Yvq85ssLqAXeBvZpVtAqBIbm44KU8cd5: using /dev/mapper/mpath1 not /dev/dm-1 Found duplicate PV Yvq85ssLqAXeBvZpVtAqBIbm44KU8cd5: using /dev/sdb not /dev/mapper/mpath1 PV VG Fmt Attr PSize PFree /dev/sdb VolGroup01 lvm2 a-- 1.00G 1.00G /dev/cciss/c0d0p2 VolGroup00 lvm2 a-- 48.81G 0
Oben verwendet LVM fälschlicherweise das Singlepath-Gerät /dev/sdb anstelle des Multipath-Geräts /dev/mapper/mpath1. Um sicherzustellen, dass LVM beabsichtigte Speichergeräte/Pfade verwendet, passen Sie die LVM-Filterzeichenfolge an, um gewünschte und/oder unerwünschte Geräte ausdrücklich einzuschließen und/oder auszuschließen. Aufgrund des Umfangs und der Vielfalt der verfügbaren lokalen und SAN-Speicher ist keine einzige LVM-Dateikonfiguration notwendigerweise für jede mögliche Bereitstellung geeignet. Daher muss die LVM-Filterzeichenfolge für individuelle System-/Speicherkombinationen angepasst werden.
Beispiel-LVM-Filterzeichenfolgen
Dieser Abschnitt bietet einen unvollständigen Bereich von Beispielwerten für LVM-Filterzeichenfolgen. Beachten Sie, dass LVM verschiedene Kombinationen der Syntax regulärer Ausdrücke für Filterzeichenfolgenwerte akzeptiert. Die folgenden Muster stellen eine solche Variation dar, andere Variationen/Kombinationen werden jedoch akzeptiert. LVM wird sich jedoch bereitwillig beschweren, wenn größere Syntaxfehler vorhanden sind.
Akzeptiere(a) Filter
| Filtern | Bedeutung |
|---|---|
| filter =[ „a/.*/“ ] | Alle Geräte |
| filter =[ „a|^/dev/sd*|“ ] | Nur alle SCSI-Geräte |
| filter =[ „a|^/dev/sda|“ ] | SCSI-Gerät /dev/sda |
| filter =[ „a|^/dev/sda[1-9]$|“ ] | Nur alle Partitionen auf dem SCSI-Gerät /dev/sda |
| filter =[ „a|^/dev/cciss/*|“ ] | Nur von HP SmartArray gesteuerte Geräte (cciss) |
| filter =[ „a|^/dev/loop*|“ ] | Alle Loop-Geräte – /dev/loop* |
| filter =[ „a|^/dev/loop1[0-2]$|“ ] | Nur Loop-Geräte 10, 11, 12 – /dev/loop1[0-2] |
| filter =[ „a|^/dev/hda1$|“ ] | Partition 1 auf IDE-Gerät /dev/hda |
| filter =[ „a|^/dev/mapper/*|“ ] | Device-Mapper-Multipath-Geräte |
| filter =[ „a|^/dev/emcpower*|“ ] | Alle EMC PowerPath-Geräte |
| filter =[ „a|^/dev/vpath[a-z]*|“ ] | Alle IBM Subsystem Device Driver (SDD)-Geräte |
| filter =[ „a|^/dev/sddlm*|“ ] | Alle Hitachi Dynamic Link Manager (HDLM)-Geräte |
Filter ablehnen
| Filtern | Bedeutung |
|---|---|
| filter =[ „r|^/dev/*|“ ] | Alle Geräte |
| filter =[ „r|^/dev/cdrom|“ ] | CD/DVD-Gerät /dev/cdrom |
| filter =[ „r|^/dev/hdc|“ ] | Nur IDE-Gerät /dev/hdc |
LVM-Filterzeichenfolgen können einzeln angegeben oder mehrere Werte in Verbindung nach Bedarf verwendet werden. Um Mehrdeutigkeiten oder unbeabsichtigte Scans/Verwendungen von Geräten zu vermeiden, sollten alle beabsichtigten Geräte (a) definiert werden, denen dann unmittelbar eine explizite Ausschlusszeichenfolge (r) folgt, um zu verhindern, dass andere Geräte gescannt/verwendet werden.
Arbeitsbeispiele für LVM-Filterzeichenfolgen
Ein System mit LVM-Geräten auf lokalem SCSI-Speicher und Device-Mapper-Multipath-SAN-Speicher könnte Folgendes definieren:
filter = [ "a|^/dev/sda[1-9]$|", "a|^/dev/mapper/*|", "r|^/dev/*|" ]
Ein HP-System mit LVM-Geräten auf lokalem Smart Array-Speicher und Remote-EMC PowerPath-SAN-Speicher könnte Folgendes definieren:
filter = [ "a|^/dev/cciss/*|", "a|^/dev/emcpower*|", "r|^/dev/*|" ]
Ein System mit LVM-Geräten auf lokalem SCSI-Speicher und IBM Subsystem Device Driver-SAN-Speicher könnte Folgendes definieren:
filter = [ "a|^/dev/sda[1-9]$|", "a|^/dev/vpath[a-z]*|", "r|^/dev/*|" ]
Validierung von Kandidaten-LVM-Filterzeichenfolgen
Stellen Sie beim Entwickeln und Testen von LVM-Filterzeichenfolgen sicher, dass LVM alle (und nur) vorgesehenen Geräte erkennt/verwendet und dass andere, unbeabsichtigte Geräte nicht gescannt/verwendet werden. Der Validierungsprozess sollte Folgendes beinhalten:
- Sichern Sie die Originaldatei /etc/lvm/lvm.conf
- Erstellen Sie optional einen lvmpdump, um die gesamte LVM-Konfiguration zu sichern
- Passen Sie die LVM-Filterzeichenfolge nach Bedarf an, d. h. /etc/lvm/lvm.conf:filter =[…]
- Entfernen Sie die LVM-Cache-Datei, z. # /bin/rm /etc/lvm/cache/.cache
- Suche erneut nach LVM-Geräten, z. # /sbin/pvscan -vv
Geräte, die im Abschnitt „Alle physischen Volumes durchlaufen“ der pvscan-Ausgabe aufgeführt sind, geben an, welche Geräte von LVM gescannt wurden. Der abschließende Abschnitt der pvscan-Ausgabe listet alle/alle erkannten PV-Geräte auf. Beachten Sie, dass eine falsche oder suboptimal konfigurierte LVM-Filterzeichenfolge zu Folgendem führen kann:
- Verwendung nicht vorgesehener Geräte, z. singlepath statt multipath
- unnötiges Scannen von LVM-Geräten, was zu einem verlängerten Systemstart führt
- Fehler beim Erkennen beabsichtigter LVM-Geräte, was zur Nichtverfügbarkeit von Gerät/Dateisystem führt
- Fehler beim Booten des Systems, d. h. Kernel Panic usw.
Die folgende Systemkonsolenausgabe zeigt typische Startzeitmeldungen, wenn ein System das LVM-Gerät mit dem Root-Dateisystem nicht finden kann:
root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.18-348.el5 ro root=/dev/VolGroup00/root 3 crashkernel=128@16M elevator=deadline [Linux-bzImage, setup=0x1e00, size=0x1fd6fc] initrd /initrd-2.6.18-348.el5.img [Linux-initrd @ 0x37a7c000, 0x57396d bytes] Warning: pci_mmcfg_init marking 256MB space uncacheable. Red Hat nash version 5.1.19.6 starting. lpfc 0000:06:00.0 0:1303 Link Up Event x1 received Data : x1 xf7 x10 x9 x0 x0 0 lpfc 0000:06:00.1 1:1303 Link Up Event x1 received Data : x1 xf7 x10 x9 x0 x0 0 Unable to access resume device (/dev/VolGroup00/swap) mount: could not find filesystem '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init!
Implementieren von LVM-Konfigurationsänderungen
Eine Kopie der lvm.conf-Datei wird in der System-Initial-RAM-Disk-Datei (initrd) gespeichert, die während des Systemstarts verwendet wird. Daher erfordert eine LVM-Konfigurationsänderung die Neuerstellung der initrd, damit die Änderungen beim Booten wirksam werden. Nachdem ein geeigneter LVM-Filter definiert/validiert wurde, führen Sie die folgenden Aktionen aus:
1. Entfernen Sie die LVM-Cache-Datei, z.
# rm /etc/lvm/cache/.cache
2. Erstellen Sie die anfängliche Ramdisk (initrd) wie folgt neu
Beachten Sie, dass die Neuerstellung der initrd-Datei mit einem falsch konfigurierten LVM-Filter zu einem vollständigen Systemstartfehler führen kann. Dementsprechend werden die folgenden alternativen Ansätze bereitgestellt, um einen solchen Fehler zu verhindern.
Option 1 (empfohlen)
Bei dieser Option wird ein neuer GRUB-Kernel-Boot-Eintrag definiert, um LVM-Änderungen zu testen, ohne die aktuelle initrd zu überschreiben.
# cd /boot # mkinitrd -v -f /boot/initrd-`uname -r`.LVM.img `uname -r` Creating initramfs ...
# ls -lart ... -rw------- 1 root root 3805700 Nov 1 16:40 initrd-2.6.18-348.el5.LVM.img
Überprüfen Sie als Nächstes die GRUB-Konfigurationsdatei /boot/grub/grub.conf. GRUB-Kernel-Boot-Einträge, beginnend mit dem Titel, werden nacheinander aufgelistet. Der Wert des Parameters default definiert den aktuellen Standard-Boot-Kernel. Die Nummerierung der GRUB-Starteinträge beginnt bei Null (0), daher:
– default=0 bezieht sich auf den ersten aufgelisteten GRUB-Kernel-Boot-Eintrag.
– default=3 bezieht sich auf den vierten aufgelisteten GRUB-Kernel-Boot-Eintrag.
Kopieren Sie alle Zeilen des standardmäßigen Kernel-Starteintrags unter sich. Ändern Sie die initrd-Zeile des neuen Kernel-Starteintrags so, dass sie den Namen der neu erstellten initrd-Datei widerspiegelt. Ändern Sie den Wert des Standardparameters so, dass er den neu erstellten GRUB-Kernel-Starteintrag widerspiegelt. Wenn der ursprüngliche Standardwert des Parameters 0 war und der neue GRUB-Eintrag direkt darunter erstellt wurde, ändern Sie den Standardwert des Parameters auf 1, zum Beispiel:
# cat /etc/grub/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
#default=0
default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Oracle Linux Server (2.6.18-348.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-348.el5 ro root=/dev/VolGroup00/LogVol00 crashkernel=128M@32 numa=off
initrd /initrd-2.6.18-348.el5.img
title Oracle Linux Server (2.6.18-348.el5) LVM
root (hd0,0)
kernel /vmlinuz-2.6.18-348.el5 ro root=/dev/VolGroup00/LogVol00 crashkernel=128M@32 numa=off
initrd /initrd-2.6.18-348.el5.LVM.img
... Beim Neustart bootet das System mit dem neu erstellten GRUB-Starteintrag, einschließlich der neu erstellten initrd. Falls Probleme auftreten, starten Sie das System neu, unterbrechen Sie den Startvorgang, um auf das GRUB-Menü zuzugreifen, und wählen Sie aus, das System mit dem ursprünglichen Starteintrag zu starten.
Option 2 (Experte)
Diese Option umfasst das Überschreiben des vorhandenen standardmäßigen GRUB-Kernel-Starteintrags und das Überschreiben der aktuellen initrd.
# cd /boot # mv initrd-`uname -r`.img initrd-`uname -r`.img.orig # mkinitrd -v -f /boot/initrd-`uname -r`.img `uname -r` Creating initramfs ...
Beim Neustart bootet das System mit dem vorhandenen GRUB-Boot, verwendet aber die neu erstellte initrd.
3. Überprüfen Sie nach dem Neustart, ob alle LVM-Geräte (PVs, VGs, LVs) vorhanden sind und die beabsichtigten physischen und/oder Multipath-Geräte verwenden. Wiederholen Sie die obigen Aktionen für jede weitere Optimierung der LVM-Filterkonfiguration oder wann immer weitere LVM-/Speicheränderungen/Reorganisationen eine Neukonfiguration rechtfertigen.