SLES 11.2 PPC(3.0.58-0.6.6-ppc64)システムで、ボリュームグループ(重要ではないが、取得するのがかなり良いデータを含むLVを含む)の追跡ができなくなったディスクは、SANからの2つのファイバーパスを介して接続されます。
先週の金曜日に計画された停電の前に再起動したときに問題が始まりました。再度停止する前にトラブルシューティングを行う時間がありませんでした。ボリュームグループは、以前は約2年間正常に使用されていました。
vgscanとpvscanは何も返しません。
_# pvscan -vP
Partial mode. Incomplete logical volumes will be processed.
Wiping cache of LVM-capable devices
Wiping internal VG cache
Walking through all physical volumes
No matching physical volumes found
# vgscan -vP
Partial mode. Incomplete logical volumes will be processed.
Wiping cache of LVM-capable devices
Wiping internal VG cache
Reading all physical volumes. This may take a while...
Finding all volume groups
No volume groups found
_
vgcfgrestoreはPVが見つからないと報告します。
_# vgcfgrestore vgclients
Couldn't find device with uuid PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU.
Couldn't find device with uuid FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2.
Cannot restore Volume Group vgclients with 2 PVs marked as missing.
Restore failed.
_
しかし、blkidはそれらのUUIDを見つけることができます。
_# blkid -t UUID=PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU
/dev/mapper/3600a0b800029df24000011084db97741: UUID="PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU" TYPE="LVM2_member"
/dev/sdl: UUID="PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU" TYPE="LVM2_member"
/dev/sdw: UUID="PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU" TYPE="LVM2_member"
# blkid -t UUID=FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2
/dev/mapper/3600a0b800029df24000017ae4f45f30b: UUID="FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2" TYPE="LVM2_member"
/dev/sdg: UUID="FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2" TYPE="LVM2_member"
/dev/sdr: UUID="FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2" TYPE="LVM2_member"
_
_/etc/lvm/backup/vgclients
_にはすべての正しい情報があり、PVが欠落しているとは言いません。
_# egrep "(N1YELU|kSqUA2|dm-|ALLOC)" /etc/lvm/backup/vgclients
id = "PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU"
device = "/dev/dm-7" # Hint only
status = ["ALLOCATABLE"]
id = "FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2"
device = "/dev/dm-12" # Hint only
status = ["ALLOCATABLE"]
_
SANで確認しました。このサーバー上のLVM専用の(および名前付きの)ボリュームが提示され、識別子(f30bまたは7741で終わる)がSANおよびサーバー上:
_# multipath -ll | egrep -A5 "(f30b|7741)"
3600a0b800029df24000017ae4f45f30b dm-7 IBM,1814 FAStT
size=575G features='1 queue_if_no_path' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=6 status=active
| `- 6:0:0:1 sdr 65:16 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
`- 5:0:0:1 sdg 8:96 active ghost running
--
3600a0b800029df24000011084db97741 dm-12 IBM,1814 FAStT
size=834G features='1 queue_if_no_path' hwhandler='1 rdac' wp=rw
|-+- policy='round-robin 0' prio=6 status=active
| `- 5:0:0:7 sdl 8:176 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
`- 6:0:0:7 sdw 65:96 active ghost running
_
どちらのデバイスにもパーティションテーブルはありません(仕様)。
_# fdisk -l /dev/dm-7 /dev/dm-12 | grep table
Disk /dev/dm-7 doesn't contain a valid partition table
Disk /dev/dm-12 doesn't contain a valid partition table
_
デバイスから直接読み取ることができます。
_# dd if=/dev/dm-7 of=/tmp/a bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.00121051 s, 846 kB/s
# strings /tmp/a
LABELONE
LVM2 001FXfSAOP9hODgtl0Ihfx2jXTnHUkSqUA2
_
再起動してsd(r|g|l|w)
とdm-(7|12)
を削除し、再スキャンしてみましたが、効果はありません。
バックアップ値を使用してPVを再作成しようとしましたが、それらを見つけることができないとまだ表示されます。
_# pvcreate --uuid "PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU" --restorefile /etc/lvm/backup/vgclients /dev/mapper/3600a0b800029df24000011084db97741 -t
Test mode: Metadata will NOT be updated and volumes will not be (de)activated.
Couldn't find device with uuid PyKfIa-cCs9-gBoh-Qb50-yOw4-dHQw-N1YELU.
Couldn't find device with uuid FXfSAO-P9hO-Dgtl-0Ihf-x2jX-TnHU-kSqUA2.
Device /dev/mapper/3600a0b800029df24000011084db97741 not found (or ignored by filtering).
_
これが私のlvm.confですが、私が知っている限り、行った唯一の変更はログレベルを上げることです。
_# egrep -v "^( *#|$)" /etc/lvm/lvm.conf
devices {
dir = "/dev"
scan = [ "/dev" ]
preferred_names = [ ]
filter = [ "a|^/dev/sda$|", "r/.*/" ]
cache = "/etc/lvm/.cache"
write_cache_state = 1
sysfs_scan = 1
md_component_detection = 1
ignore_suspended_devices = 0
}
log {
verbose = 0
syslog = 1
overwrite = 0
level = 2
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"
activation = 1
proc = "/proc"
locking_type = 3
fallback_to_clustered_locking = 1
fallback_to_local_locking = 1
locking_dir = "/var/run/lvm/lock"
}
activation {
missing_stripe_filler = "/dev/ioerror"
reserved_stack = 256
reserved_memory = 8192
process_priority = -18
mirror_region_size = 512
readahead = "auto"
mirror_log_fault_policy = "allocate"
mirror_device_fault_policy = "remove"
udev_rules = 1
udev_sync = 1
}
dmeventd {
mirror_library = "libdevmapper-event-lvm2mirror.so"
snapshot_library = "libdevmapper-event-lvm2snapshot.so"
}
_
だから何を与えるのですか? VGはどこにありますか?
Novellナレッジベースのドキュメント がここに当てはまるようです:SLESでは、デフォルトでLVMがマルチパスデバイスをスキャンしないため、この状況ではデバイスが表示されないことが説明されています。
この問題を解決するには、Novellが提供する回避策を実装できます。
/etc/lvm.conf
devices
セクションで、filter
を次のように変更します。
filter = [ "a|/dev/sda.*|", "a|/dev/disk/by-id/dm-uuid-.*mpath-.*|", "r|.*|"]
(これはSLES 11用です。他のバージョンについては、リンクされているKB記事を参照してください。)
vgreduce --removemissingは、同じ問題が発生したときに私の場合に役立ちました。
これが私がこの問題を作成した方法です。
既存の論理ボリュームを拡張する予定でしたが、その途中で、別の端末から、拡張に使用するデバイスでfdiskを実行しました。以前に削除したいと思っていたパーティションテーブルがいくつかありました。このディスクをすでにボリュームグループに追加しているため(まだ論理ボリューム自体を拡張していないだけです)、その物理ボリュームはもう存在しないため、UUIDが見つからないという問題が発生しました。
それを解決するために、vgreduce --removemissingをRandし、それで大丈夫でした。
変更/etc/lvm/backup/<vg_name>
ファイル。めちゃくちゃになったものを修正し、特に不足しているUUIDを削除します。
次に実行します:
vgcfgrestore <vg_name>