나는 많은 수의 가상 머신을 갖춘 프로덕션 ESXI 서버를 보유하고 있습니다. 몇 시간 전에 정전이 발생하여 UPS 배터리가 방전되었습니다. 어떤 이유로 자동 종료 메커니즘이 작동하지 않아 전체 시스템의 전원이 차단되었습니다.
중단 후 mysql 서버 가상 머신을 제외한 모든 것이 정상으로 돌아왔습니다. 이제 I/O 오류로 콘솔에 스팸을 보내고 있습니다.
end_request: 중요한 미디어 오류, dev sda, 섹터 X end_request: I/O 오류, dev sda, 섹터 X .... EXT4-fs 오류(장치 dm-1): ext4_wait_block_bitmap: 476 통신 바운스: 블록 비트맵을 읽을 수 없습니다. - block_group=X, block_bitmap=X 장치 dm-1-8에서 로깅을 중단하는 중 EXT4-fs(dm-1): 파일 시스템을 읽기 전용으로 다시 마운트합니다.
VM은 암호화된 LVM 설정을 사용합니다.
이러한 오류는 무엇을 의미합니까? 하드웨어인가요? 어떡해? 나는 몇 시간 동안 인터넷 검색을 해왔지만 무엇을 해야할지 모르겠습니다. 라이브 CD로 부팅하고 마운트 해제된 루트 파티션에서 fsck를 실행한 후 문제를 해결하고 재부팅했지만 문제는 동일합니다.
편집 #1 이것을 시도했지만 아무 일도 일어나지 않았습니다.
root@ubuntu:~# sudo cryptsetup --key-file=/media/ubuntu/7b225e2d-9c0f-4bd4-a4de-1d2f7a0b4c58/keyfile luksOpen /dev/sda5 myvolume root@ubuntu:~# vgscan 모든 물리학 책을 읽으십시오. 시간이 좀 걸릴 수도 있어요... 메타데이터 유형 lvm2를 사용하여 볼륨 그룹 "mysql-server-vg"를 찾습니다. root@ubuntu:~#tune2fs -O ^has_journal /dev/mysql-server-vg/root une2fs 1.42.13(2015년 5월 17일) need_recovery 플래그가 설정되었습니다. 삭제하기 전에 e2fsck를 실행하세요. has_journal 플래그입니다. root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root \e2fsck 1.42.13(2015년 5월 17일) /dev/mysql-server-vg/root: 복구 로그 패스 1: inode, 블록, 크기 확인 삭제된 inode 391687의 dtime은 0입니다. 고치시겠습니까? 예 손상된 고아 연결 목록의 일부인 인덱스 노드가 발견되었습니다. 고치시겠습니까? 예 Inode 391697은 분리된 inode 목록의 일부입니다. 안정적인. Inode 391699는 분리된 inode 목록의 일부입니다. 안정적인. Inode 391700은 분리된 inode 목록의 일부입니다. 안정적인. 2단계: 디렉터리 구조 확인 3단계: 디렉터리 연결 확인 4단계: 참조 횟수 확인 패스 5: 그룹 요약 정보 확인 사용 가능한 블록 수 오류(5462594, 개수=5462792). 고치시겠습니까? 예 인덱스 노드 비트맵 차이: -391687 -391697 -(391699--391700) 고치시겠습니까? 예 그룹 #48에 대한 사용 가능한 inode 수가 잘못되었습니다(7946, 개수 = 7950). 고치시겠습니까? 예 사용 가능한 inode 수 오류(1854371, 개수=1854370). 고치시겠습니까? 예 /dev/mysql-server-vg/root: ***** 파일 시스템이 수정되었습니다***** /dev/mysql-server-vg/root: 95870/1950240개 파일(0.8% 비연속), 2337016/7799808개 블록 root@ubuntu:~#tune2fs -O ^has_journal /dev/mysql-server-vg/root une2fs 1.42.13(2015년 5월 17일) root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root e2fsck 1.42.13(2015년 5월 17일) 패스 1: inode, 블록, 크기 확인 2단계: 디렉터리 구조 확인 3단계: 디렉터리 연결 확인 4단계: 참조 횟수 확인 패스 5: 그룹 요약 정보 확인 /dev/mysql-server-vg/root: 95870/1950240개 파일(0.8% 비연속), 2304248/7799808개 블록 root@ubuntu:~#tune2fs -j /dev/mysql-server-vg/root une2fs 1.42.13(2015년 5월 17일) 로그 inode 생성: 완료
답변1
좋아, 알아냈고 성공적으로 고쳤습니다. 이틀이 걸렸습니다.
먼저 스토리지 컨트롤러, 데이터 스토리지 하드웨어(기계 드라이브), 케이블에 이상이 없는지 확인했습니다. 파일 시스템에서 vmdk 파일에 제대로 액세스할 수 없는 점 참고하시기 바랍니다. scp와 vSphere Client를 사용하여 로컬로 복사를 시도했지만 잠시 후 둘 다 입력/출력 오류가 발생했습니다.
가상 디스크를 별도의 데이터 저장소에 복제해 보기도 했습니다.
CD /vmfs/볼륨/ vmkfstools -i datastore1/vm/vm.vmdk datastore2/vm/vm.vmdk -d Thin -a lsilogic
16% 후에는 입력/출력 오류가 발생했습니다.
정전으로 인해 vmfs 파일 시스템(데이터 저장소), 오래된 잠금 등이 일부 손상되었다고 생각합니다. VOMA(vSphere Disk Metadata Analyser)를 사용하여 VMFS 메타데이터 일관성을 확인했습니다. 이 명령을 실행하기 전에 데이터 저장소를 마운트 해제해야 합니다.
voma -m vmfs -f 확인 /vmfs/devices/disks/disk_name:1
34개의 오류가 발견되었습니다. vSphere Hypervisor 버전 5.5에 번들로 제공되는 voma는확인하다파일 시스템. 복구 모드에서 clonezilla를 사용하여 데이터 저장소를 새 하드 드라이브에 복제하고 있습니다(불량 섹터가 있는 디스크 복제). 그런 다음 최신 버전의 voma 명령이 있으므로 VMware ESXi 버전 6.5로 업그레이드했습니다. 오류가 수정되었으므로 다음 명령을 실행했습니다.
voma -m vmfs -f 수리 /vmfs/devices/disks/disk_name:1
그것은 뭔가를 합니다. 가상 머신을 시작했지만 다음 이유로 인해 콘솔에 연결할 수 없습니다.새로운 vCenter vSphere WebClient 넌센스 및 vSphere Client가 더 이상 사용되지 않음, 그래서 원래 VMware ESXi 5.5 설치로 돌아갔습니다. 위의 vmdk 파일을 성공적으로 복제했습니다. 복제된 디스크를 사용하여 VM을 시작하고 fsck를 한 번 실행한 다음 재부팅했습니다. 예상대로 작동합니다. 서버가 내 모든 데이터와 함께 온라인 상태가 되었습니다.
많은 조작이 필요했지만 다른 것을 알아낼 수 없었습니다. 혹시 더 쉬운 방법 아시는 분 계시면 댓글 부탁드립니다.
사고 발생 12시간 전에 데이터베이스 백업을 수행했지만 가능하다면 라이브 데이터를 복원하고 싶습니다.