방금 약 9개월 전에 설치된 두 대의 새롭고 동일한 서버에서 동일한 문제를 발견했습니다. 시스템이 읽기 전용으로 표시했기 때문에 두 디스크 모두에 디스크에 쓸 수 없었습니다. 로그에는 둘 다에 일종의 디스크 오류가 있음이 표시되었습니다.
각 서버에서 여러 게스트로 KVM을 실행하고 있습니다. 게스트는 모두 잘 작동했지만 문제는 KVM 호스트에 있었습니다. 이것은 아마도 중요하지 않을 수도 있지만 관련이 있을 수도 있습니다. 두 시스템 모두드라이브 2개소프트웨어 raid1 및 LVM이 맨 위에 있습니다. 각 KVM 게스트에는 자체 LVM 파티션도 있습니다.
를 살펴보면 두 시스템 모두 성능이 저하된 RAID1 어레이를 보여주었습니다 /proc/mdstat.
그래서 시스템 중 하나를 재부팅했는데 fsck. 그래서 나는 그렇게 했다. 문제를 해결한 것으로 보였고 재부팅하면 시스템이 정상적으로 백업되었습니다. 두 번째 서버에서도 동일한 프로세스가 작동했습니다.
mdadm --manage /dev/md0 --add /dev/sdb1다음으로 실패한 드라이브를 어레이에 다시 추가하기 위해 실행했습니다 . 이것은 두 서버 모두에서 잘 작동했습니다. 다음 한 시간 정도 동안 /proc/mdstat드라이브 동기화 진행 상황을 살펴보았습니다. 약 한 시간 후에 한 시스템이 완료되고 /proc/mdstat모든 것이 [UU].
그러나 다른 시스템에서는 약 1시간 30분쯤 지나자 시스템 부하가 급증하고 아무 응답도 없었습니다. 몇 분 후, 모든 것이 다시 돌아왔습니다. 하지만 /proc/mdstat지금 보면 다음과 같습니다.
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
보시다시피 더 이상 동기화되지 않는 것 같습니다. 완료율, 남은 시간 등이 더 이상 표시되지 않습니다. 그러나 실행하면 mdadm --detail /dev/md0다음이 표시됩니다.
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
결과적으로 스페어가 재구축되고 있음을 나타내는 것 같습니다. 왜 예비품인가요? 시스템에서는 두 장치가 모두 깨끗한 것으로 보고됩니다. 몇 시간 동안 이 상태로 있었습니다. 드라이브는 작고 빠른 300GB 10K RPM VelociRaptor이므로 지금쯤 동기화되었을 것이라고 생각합니다. 다시 추가하려고 하면 기기가 사용 중이라고 표시됩니다.
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
"좋은" 서버에서 dmesg를 실행하면 끝에 다음이 표시됩니다.
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
"불량" 서버에서는 마지막 4줄이 수백 번 반복됩니다. "좋은" 서버에서는 한 번만 표시됩니다.
드라이브가 아직 동기화되고 있나요? 이 "재구축"이 끝날까요? 좀 더 인내심을 가져야만 하는 걸까요? 그렇지 않다면 이제 어떻게 해야 합니까?
업데이트:
방금 재부팅했는데 드라이브가 다시 동기화를 시작했습니다. 거의 2시간 후에 위에서 설명한 것과 동일한 현상이 발생했습니다(여전히 [_U]가 표시됨). 그러나 RAID1 conf 인쇄 청크가 모두 소비되기 전에 dmesg 로그를 볼 수 있었습니다.
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
그래서 제가 물어봐야 할 질문은 "레이드 세트의 예비 디스크에서 fsck를 어떻게 실행합니까?"일 것입니다.
답변1
고장난 드라이브를 실제로 교체했는지 확실하지 않습니다. 결함이 있는 드라이브를 다시 추가하면 증상이 이해가 되기 때문에 드라이브가 잠겼을 가능성이 높습니다. 결함이 있는 드라이브를 다시 추가한 경우 /var/log/messages 또는 dmesg에 후속 오류가 있습니까?
(부수적으로, 결함이 있는 드라이브를 RAID 어레이에 다시 추가하지 말 것을 강력히 권장합니다. 결함으로 인해 플래터의 데이터가 손상된 경우 이를 어레이에 다시 추가할 때 재동기화로 인해 손상된 파일이 플래터에 남아 있음을 알 수 있습니다. 디스크를 사용하고 다음에 파일을 읽을 때 어떤 디스크가 먼저 응답하는지에 따라 좋은 데이터를 얻을지 나쁜 데이터를 얻을지 여부는 문제가 될 것입니다. 저는 이런 일이 실제로 일어나는 것을 보았습니다.
답변2
mdadm --details를 사용하면 드라이브를 재구축하는 동안 예비 드라이브로 나열됩니다. 재구축이 완료되면 더 이상 예비로 표시되지 않습니다.
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
첫 번째 줄은 재할당 실패가 발생하여 데이터를 읽지 못했다는 내용입니다. 다음 세 줄은 데이터를 읽을 수 없음을 나타내며 읽을 수 없는 섹터를 나열합니다.
Rodger가 지적했듯이 드라이브가 불량이므로 다시 추가하지 마십시오. 실패한 드라이브를 다시 추가하는 것은 결코 좋은 생각이 아닙니다. 드라이브를 당겨서 교체하십시오. 원할 경우 고장난 드라이브에 대한 진단을 실행하되 드라이브를 꺼내서 교체한 후에만 실행하십시오.
답변3
첫째, 그렇습니다. 로그 파일에 기록되는 읽기 오류를 발생시키는 디스크를 제거하십시오. 이는 불량 블록 재배치가 실패했거나 드라이브가 거의 죽어가고 있음을 의미합니다.
다음과 같은 Linux 복구 CD를 사용하여 데이터를 복구하는 것이 좋습니다.http://ubuntu-rescue-remix.org/ddrescue를 사용합니다. 이렇게 하면 새 디스크의 파티션에 이미지 복사를 수행할 수 있으며 파티션 복구를 시도하기 위해 많은 재시도 등을 수행하게 됩니다. USB 드라이브 또는 다른 파티션 마운트
mkdir /tmp/x && 마운트 /dev/sdd1 /tmp/x
ddrescue 로그 파일을 보관하려면 ddrescue를 중지(ctrl-C)하고 나중에 동일한 지점에서 다시 시작할 수 있습니다.
새 디스크의 파티션을 기존 디스크보다 조금 더 크게 만듭니다. 전체 디스크를 사용할 필요는 없습니다!
커널 부팅 매개변수로 "nodmraid"를 사용하여 복구 CD를 부팅합니다. 우분투 라이브 CD를 사용하는 경우 RAID 및 LVM을 사용하는 경우 설치하십시오.
apt-get 설치 mdadm lvm2 gddrescue
이 작업을 수행하려면 인터넷에 연결되어 있어야 합니다.) 그렇지 않으면 ddrescue 단계에 우분투 복구 CD를 사용하십시오. ddrescue 실행을 위한 복구 CD와 grub 및 fsck 작업을 위한 라이브 CD를 교환했습니다.
/dev/sdb가 실패한 소스 디스크이고 /dev/sdx가 새 디스크이고 /mnt/x가 USB 키이거나 마운트된 다른 디스크의 파티션이라고 가정합니다. 너필요ddrescue 로그 파일이군요! ddrescue가 어떻게 진행되고 있는지 추적하고 중단할 수 있습니다.
에 따라http://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX 이미지 파일 /mnt/x/logfile
그 다음에
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
그 다음에
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
단일 섹터를 복구하는 데 몇 시간이 걸리는 경우 프로세스를 Ctrl-C하는 것을 두려워하지 마십시오. 다음 단계로 넘어가세요(1단계는 무슨 일이 있어도 성공해야 합니다). 마지막 단계에서는 사용 가능한 데이터의 마지막 조각을 복구하려고 합니다.
당신도해야 할 것입니다
mdadm --create /dev/md99 --level-1 --raid-devices=2 누락 /dev/sdX
새 디스크를 사용하여 새 RAID 어레이를 만들려면 파티션에 새 RAID 슈퍼 블록을 씁니다(파티션 끝의 마지막 64K~128K).
이전에 실패한 디스크 /dev/sdb를 시스템에서 제거하여 Linux에 표시되지 않도록 하십시오.
소스 RAID 디스크에 액세스할 수 있도록 만듭니다. ubuntu 복구 CD에 문제가 있었고 결국 nodmraid가 F6 옵션에 있는 Ubuntu 라이브 CD(10.4)를 사용하게 되었기 때문에 커널 부팅 커널에 "nodmraid" 매개변수를 사용해야 할 수도 있습니다. 그냥 사용해야합니다
mdadm --assemble /dev/md99 /dev/sdX
그런 다음 fsck를 수행하거나 md99 RAID 배열의 데이터에 대해 수행해야 하는 모든 검사를 수행합니다(vgscan을 사용한 다음 검사를 실행할 LVM LV를 볼 수 있었습니다). 신화TV에 XFS를 사용하는데 xfs_check 명령으로 시스템이 충돌했지만 xfs_repair는 정상이었습니다.
새 /dev/sdX에서 /boot 디렉터리를 마운트합니다.
마운트 /dev/mapper/my_vg/root_lv /tmp/x
그런 다음 새 GRUB 부트 레코드를 새 /dev/sdX RAID 디스크에 넣습니다(RAID에서 부팅하는 경우에만!)
grub-setup -d /tmp/x/boot/grub /dev/sdX
이제 (거의) 부팅 가능한 RAID 어레이가 생겼습니다. GRUB 자체를 사용하여 설정을 수행하거나 dd를 사용하여 /dev/sdb의 처음 446바이트를 /dev/sdX에 복사할 수도 있습니다. 처음 446바이트만, 첫 번째 섹터의 나머지 부분은 파티션 테이블입니다. 더 많이 복사하면 공간이 꽉 차게 됩니다! 파티션 /dev/sdX1(가령)의 첫 번째 섹터에 대해서도 동일한 작업을 수행해야 할 수도 있습니다. 덮어쓰려는 모든 섹터를 dd를 사용하여 백업합니다.
grub2를 사용하고 RAID에서 부팅하는 경우 RAID 배열 UUID가 변경되어 부팅이 실패하는 것을 확인할 수 있습니다. 부팅 명령줄(예: Grub 시작 패널)을 편집하여 스플래시 및 조용함을 제거하면 무슨 일이 일어나고 있는지 확인할 수 있습니다. 그런 다음 부팅 실패 후 initramfs에 남아 있습니다.
mdadm --assemble /dev/md99 /dev/sdX
그런 다음 /proc/mdstat를 확인하여 어레이가 있는지 확인하십시오. 그런 다음 그냥 "종료"하고 GRUB 부팅 스탠자가 제대로 작동하기를 바랍니다(광산은 LVM을 사용하도록 설정되었으므로 RAID 장치가 있으면 RAID 장치에서 LV를 찾았고 방금 LV를 검색했습니다). 부팅이 완료되면 거의 완료됩니다.
initrd 이미지 파일(gzip으로 압축된 cpio 파일)에는 부팅 프로세스 중에 사용되는 mdadm.conf의 복사본이 포함되어 있으며 부팅 프로세스 중에 /etc/mdadm/mdamdm.conf로 표시 및 편집 가능합니다. 시스템을 정상적으로 부팅할 수 있다면 다음을 사용하여 initramfs를 업데이트하세요.
업데이트-initramfs -u
mdadm.conf 파일의 UUID가 일치하지 않아 시스템을 부팅할 수 없는 경우
다른 방식(Grub, 복구, 실제 부팅)으로 부팅하면 대상 장치 /dev/sdX가 /dev/sdY로 나타날 수 있다는 점에 유의하세요.
그건 그렇고, RAID5를 사용하고 있고 블록 정렬에 정말로 관심이 있는 것이 아니라면 RAID 어레이에 파티션을 사용하겠습니다. 전체 디스크를 사용할 필요는 없습니다(특히 1TB 디스크를 2TB 디스크로 교체하는 경우). 하나). 나중에 언제든지 다른 파티션과 두 번째 RAID 어레이를 추가하여 전체 2TB를 사용할 수 있습니다.
휴! 완료!