☰

LVM: 재부팅 후 PV가 손실됨

tag-icon • tag-icon linux lvm
LVM: 재부팅 후 PV가 손실됨

여러 LVM 논리 볼륨이 있는 서버(Ubuntu 18.04)가 있습니다. 일상적인 재부팅 후에 그 중 하나가 다시 돌아오지 않습니다. 몇 가지 조사를 마친 후, 저는 다음과 같은 위치에 있습니다.

  • 물리적 디스크는 iSCSI 장치이고 커널은 이를 /dev/sdc로 인식합니다(오류가 없고 크기가 정확함).

  • lvmdiskscan -v는 /dev/sdc에서 PV를 확인합니다.

 
> lvmdiskscan -v
...
/dev/sdc [72.76TiB] LVM 물리 볼륨
  • blkid는 LVM 구성에서도 찾을 수 있는 UUID를 반환합니다.
...
/dev/sdc: UUID="fvUXXf-pVOF-EPnn-c8eg-tZ5S-iMVW-wsSFDy" TYPE="LVM2_member"

  • 이 항목에는 시스템의 다른 LV에 있는 PARTUUID 항목이 없습니다. 이게 단서인가요? 나는 이 정보를 나에게 더 도움이 될 어떤 것과도 연관시킬 수 없습니다.

  • pvscan이 /dev/sdc를 보고하지 않습니다.

  • pvdisplay가 이 PV를 모르는 것 같습니다.

> PV디스플레이 /dev/sdc
물리적 볼륨 "/dev/sdc"를 찾을 수 없습니다.

누구든지 올바른 방향으로 나를 가리킬 수 있습니까?

Pvck -t의 출력을 추가하도록 편집되었습니다.

pvck -t /dev/sdc
  테스트 모드: 메타데이터가 업데이트되지 않으며 볼륨이 (비)활성화되지 않습니다.
  /dev/sdc, 섹터 1, 유형=LVM2 001에서 레이블을 찾았습니다.
  텍스트 메타데이터 영역 찾기: 오프셋=4096, 크기=1044480

또한 이 LV는 원래 Ubuntu 14.04에서 제작되었으며 Ubuntu 18.04에서 매우 잘 실행된다는 점도 도움이 됩니다.

다음은 lvmdiskscan의 추가 출력입니다. 이 출력은 시스템의 다른 VG 출력과 다르지 않습니다. LV는 먼저 격리된 것으로 나타난 다음 VG와 연결되어 사용 가능해집니다. 그러나 r3vg에서는 이런 일이 발생하지 않습니다.

lvm[7852]: /dev/sdc 장치에서 태그를 읽는 중
 lvm[7852]: /dev/sdc RO O_DIRECT 열기
 lvm[7852]: /dev/sdc: 블록 크기는 4096바이트입니다.
 lvm[7852]: /dev/sdc: 물리적 블록 크기는 512바이트입니다.
 lvm[7852]: /dev/sdc: 섹터 1에서 lvm2 레이블이 감지되었습니다.
 lvm[7852]: lvmcache /dev/sdc: 이제 VG #orphans_lvm2(#orphans_lvm2)에서 mda는 0입니다.
 lvm[7852]: /dev/sdc: PV 헤더 확장 버전 2 발견
 lvm[7852]: /dev/sdc: 5632 크기 1015(지역 4096 크기 1044480)에서 r3vg(Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00)에 대한 메타데이터를 찾았습니다.
 lvm[7852]: lvmcache에는 VGID가 Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00인 vgname "r3vg"에 대한 정보가 없습니다.
 lvm[7852]: lvmcache에 vgname "r3vg"에 대한 정보가 없습니다.
 lvm[7852]: lvmcache /dev/sdc: 이제 1mda가 있는 VG r3vg에 있습니다.
 lvm[7852]: lvmcache /dev/sdc: VG r3vg: VGID를 Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00으로 설정합니다.
 lvm[7852]: lvmcache /dev/sdc: VG r3vg: 호스트 생성을 leitrim으로 설정합니다.
 lvm[7852]: lvmcache /dev/sdc: VG r3vg: 저장된 메타데이터 체크섬 0x54affad5, 크기 1015.
 lvm[7852]: /dev/sdc 닫기
 lvm[7852]: /dev/sdc: 캐시 크기 156250918912 섹터 사용
 lvm[7852]:/dev/sdc [72.76TiB] LVM 물리 볼륨
 lvm[7852]: 디스크 7개
 lvm[7852]: 파티션 3개
 lvm[7852]: 1 LVM 물리 볼륨 전체 디스크
 lvm[7852]: LVM 물리 볼륨 2개
 lvm[7852]: global/notify_dbus를 1로 설정
 lvm[7852]: 완료됨: lvmdiskscan -dddddd

답변1

sudo vgscan및 작업을 수행 하면 LV를 설치할 수 있습니까 sudo vgchange -ay? 이러한 명령으로 인해 오류가 발생하면 다른 문제가 있을 수 있으므로 이러한 오류 메시지를 원본 게시물에 추가해야 합니다.

그러나 이 명령 후에 LV를 설치할 준비가 되면 다음 내용을 읽어 보십시오...

LVM 논리 볼륨 경로 이름(예 /dev/mapper/vgNAME-lvNAME: ) 만으로는 /etc/fstab네트워킹 및 iSCSI가 활성화될 때까지 이 특정 파일 시스템을 마운트할 수 없다는 단서를 시스템에 제공하지 않습니다.

이러한 단서가 없으면 시스템은 파일 시스템이 로컬 디스크에 있다고 가정하고 가능한 한 빨리 마운트를 시도합니다. 일반적으로 네트워크를 활성화하기 전에 마운트를 시도합니다. 이는 분명히 iSCSI LUN에 실패합니다. 따라서 어떻게든 그 단서를 제공해야 합니다.

_netdev한 가지 방법은 파일 시스템에 마운트 옵션을 추가하는 것입니다 /etc/fstab. ~에서이 우분투 도움말 페이지우분투는 그것을 지원하는 것 같습니다. 실제로 vgscan라벨이 붙은 것을 마운트하려고 할 때 _netdev.

또 다른 접근 방식은 시스템별 마운트 옵션을 사용하는 것입니다 x-systemd.requires=<iSCSI initiator unit name>. iSCSI 초기자가 성공적으로 활성화될 때까지 파일 시스템 마운트 시도를 연기하면 동일한 효과를 얻을 수 있습니다.

iSCSI 초기자가 활성화되면 구성된 모든 LUN이 자동으로 사용 가능해지며, LVM은 사용 가능한 모든 VG를 자동으로 활성화해야 합니다. 따라서 마운트 시도를 연기하면 충분합니다.

누락된 PARTUUID는 디스크/LUN에 GPT 파티션 테이블이 없음을 나타냅니다. 실제로 파티션 테이블이 전혀 없기 때문입니다 /dev/sdc. TYPE="LVM2_member"이론적으로는 Linux에서 문제가 발생하지 않아야 하지만, iSCSI 스토리지가 포함된 Ubuntu 18.04 시스템을 개인적으로 테스트하지 않았기 때문에 완전히 확신할 수는 없습니다.

파티션 테이블이 없는 디스크/LUN의 문제는 다른 운영 체제가 Linux LVM 헤더를 디스크가 사용 중이라는 신호로 인식하지 못하고 메시지를 거의 표시하지 않고 덮어쓴다는 것입니다. 이는 iSCSI 저장소 관리자가 실수로 해당 저장소 LUN을 다른 시스템에 제공한 경우 /dev/sdc발생할 수 있습니다 .

누락된 VG에 해당하는 디렉터리에서 LVM 구성 백업 파일을 찾아 /etc/lvm/backup읽어서 누락된 PV의 예상 UUID를 찾아야 합니다. 보고서와 일치 하는 경우 blkid스토리지 관리자에게 위 오류에 대한 최근 작업을 다시 확인하도록 요청하세요. 다른 시스템에서 PV를 덮어쓴 것으로 밝혀지면 LUN에 남아 있는 데이터는 다소 손상되었을 수 있으므로 백업에서 복원하는 것이 가장 좋습니다. 새 데이터를 얻은 후에는충돌 없음 보장iSCSI 관리자의 LUN.

실제 UUID가 예상과 다른 것으로 밝혀지면 /dev/sdc누군가 실수로 pvcreate -f /dev/sdcUUID를 실행했을 수도 있습니다. 그것이 완료된 유일한 일이라면 비교적 쉽게 고칠 수 있습니다. (노트:man vgcfgrestore장을 확인하세요물리 볼륨 교체업데이트에 대한 참고 사항 - 귀하의 LVM 도구가 내 도구보다 최신일 수 있습니다. ) 먼저 UUID를 복원합니다.

pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc

그런 다음 VG 구성을 복원합니다.

vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>

그런 다음 VG를 활성화하고 다른 손상이 발생하지 않으면 파일 시스템을 마운트할 수 있어야 합니다.

답변2

telcoM의 의견을 읽고 로그와 매뉴얼 페이지를 자세히 살펴본 후 이제 내 질문에 답할 수 있습니다.

어떤 이유로 PV /dev/sdc가 속한 VG에 대한 정보가 재부팅 중에 손실되어 다시는 돌아오지 않습니다.

나는 해결책을 완전히 이해하지 못하지만(누군가가 세부 사항을 추가할 수도 있음) 다음은 작동합니다. 첫 번째

> vgscan --캐시
  메타데이터 유형 lvm2를 사용하여 볼륨 그룹 "r3vg"를 찾았습니다.

내 VG 구성을 찾으세요. 이제 PV가 다시 알려졌습니다.

> 태양광 발전
  /dev/sdc r3vg lvm2 a-- 72.76t 26.39t

LV도 다시 알려져 있지만 비활성 상태입니다.

> lvscan
   비활성 '/dev/r3vg/p0' [46.37 TiB] 상속

마침내

> lvchange -ay r3vg/p0

다시 가져와.

재부팅 후 VG 구성이 선택되지 않는 이유를 잘 모르겠습니다. 누구든지 제안 사항이 있으면 댓글에 추가해 주세요.

관련 정보