개요
최근 사내에서 물리서버 한 대가 디스크 관련 이슈로 갑작스럽게 다운되는 일이 발생했다. 예상 못한 상황에서 긴박하게 진행했었지만, RAID 구성과 물리 디스크 상태를 점검하고 문제가 발새한 장치를 찾아 교체하여 정상적으로 복구를 완료할 수 있었다.
이번 글에서는 당시 상황에 발생한 디스크 오류와 트러블 슈팅 과정을 공유해보려 한다.
작업 히스토리
1. 서버 down 확인
2. RAID 컨트롤러 Error 발생
3. RAID 컨트롤러 캐시 메모리 초기화 시도 -> 실패
4. RAID 컨트롤러 교체(여분 장비)
5. 서버 Up 확인, 데이터 정상 여부 확인 완료
1. 서버 Down 이슈 확인(디스크 문제)
평소 일과를 진행하던 중 사내 개발서버에 연결이 안되는 장애가 발생했다. 정확하게는 물리 서버에서 실행중인 하이퍼바이저는 작동 중이였으나, 그 위에서 동작하는 VM들이 모두 중단되는 상황이였다.
문제 발생 직후 하이퍼바이저 서버에 접근 자체는 가능했지만, 기본적인 시스템 명령어를 입력하면 에러가 출력되었다.
root@vm01:~# lsblk
-bash: /usr/bin/lsblk: Input/output error
- bash: /usr/bin/lsblk: Input/output error
디스크 상태를 확인하기 위해 lsblk 명령을 실행했을때 발생하였는데, 찾아보니 파일 시스템 관련 문제로 확인된다.
시간이 지나면서 결국 하이퍼바이저 서버 자체도 접근이 불가능한 상태가 되어 서버 재부팅을 진행하였으나, 다음과 같은 에러가 발생하며 부팅되지 않았다.
- https://unix.stackexchange.com/questions/542554/got-input-output-error-when-execute-any-commands
- https://askubuntu.com/questions/1216954/bash-usr-bin-top-input-output-error
(다음 자료를 참고해보면 디스크나 파일시스템 손상으로 인해 발생한 것으로 보인다.)
- UEFI0116 One or more boot drivers have reported issues
해당 화면처럼 UEFI0116 오류는 DELL 서버의 부트 드라이버 자체나 설정에 문제가 있다는 것이다.
여러 이유가 있을 수 있는데, 아무 키(Press any key)를 눌러서 상세한 내용을 확인할 수 있다.
해당 에러는 DELL 서버에서 발생하는 오류로, 부트 드라이버 또는 설정에 문제가 있음을 나타낸다.
보통 물리 디스크 문제, RAID 구성 오류, 펌웨어 오류 등으로 발생할 수 있는데, 상세 로그를 확인하기 위해 아무 키(Press any key)를 눌러 드라이버 헬스 매니저(Driver Health Manager)로 접근하였다.
2. RAID 컨트롤러 Multibit ECC Error
서버를 재부팅하며 나타난 UEFI0116 오류 화면에서 Driver Health Manager로 진입하여 드라이버 상태를 확인하였다.
해당 메세지는 사용중인 DELL 440 서버의 RERC H750(RAID 컨트롤러 모델명)에서 치명적인 오류가 발생하여 부팅이 불가능하는 내용이다.
- Multibit ECC Error
Multibit ECC Error는 RAID 컨트롤러의 캐시 메모리에서 다중 비트 오류가 발생하여 자동 복구가 불가능한 상태를 의미한다.
조사해보니 보통 ECC 메모리는 단일 비트 오류를 자동으로 수정할 수 있으나, 다중 비트 오류는 수동으로 처리하거나 하드웨어를 교체해야 하는 경우가 많다고 한다.
보통 다음과 같은 원인으로 발생한다.
- RAID 컨트롤러의 캐시 메모리 손상
- RAID 배터리 문제
- RAID 펌웨어 버그
관련 자료를 조사하던 중, 비슷한 사례를 발견했다. RAID 컨트롤러의 캐시 메모리를 초기화하여 복구하였다는 내용이다.
https://dasandata.tistory.com/entry/Dell-R740-서버-정전-후-UEFI0116-Avago-MegaRAID-FW-Fault-MFI-Register-0xF0FF8302-부팅-불가
다음 사례의 요약은 다음과 같다.
- RAID 컨트롤러에서 Multibit ECC Error로 인해 부팅 불가
- 서버 종료 후 전원 공급 장치 제거
- RAID 컨트롤러 배터리 방전 유도
-> RAID 컨트롤러의 BBU가 방전되도록 대기 - 배터리가 방전되며 RAID 컨트롤러의 캐시 메모리 초기화
- 전원 및 디스크 복구 후 재부팅
- 정상 부팅 확인
이에 본인도 캐시 메모리를 초기화하는 방법으로 진행해보겠다.
3. RAID 컨트롤러 캐시 메모리 초기화
RAID 컨트롤러와 캐시 메모리 역할
RAID 컨트롤러는 서버의 디스크를 관리하는 장치이다.
본인의 경우 서버는 DELL 440, RAID 컨트롤러는 H750 모델을 사용중이라 해당 모델들을 기준으로 설명하자면, RAID 구성 정보나 데이터들은 물리적 디스크와 컨트롤러에 저장된다.
(RAID 컨트롤러 별로 기능이 상이하기 때문에 잘 확인하고 진행해야한다.)
즉, 물리 디스크에도 RAID 구성 정보가 저장되기 때문에, RAID 컨트롤러를 교체하거나 캐시 메모리를 초기화하더라도 RAID 구성이 유지된다는 것을 확인하였다.
그리고 이번 서버는 개발 용도로 사용중이였고, 데이터는 이미 백업된 상태였기 때문에 데이터 안정성보다 빠른 복구가 필요한 상황이였다.
위와 같은 근거로 RAID 컨트롤러 캐시 초기화를 시도하였다.
캐시 메모리 초기화 작업
다음 절차로 캐시 메모리 초기화 작업을 진행하였다.
- 대기 전력 제거
(서버 종료 후 전원 케이블, 네트워크 케이블 제거하여 대기 전력 차단) - RAID 컨트롤러 재결합 진행
(서버 내부 RAID 컨트롤러를 분리했다가 다시 결합) - 전원 및 네트워크 케이블 연결 후 대기
(케이블 연결 후 전원은 키지 않은 상태로 잠시 대기) - 서버 부팅 시도
작업 대상 서버이다.
그리고 해당 부분이 RAID 컨트롤러이다.
이후 약 30분간 전원을 차단한 뒤 작업을 진행했으나, 결국 동일한 문제가 재발하였다.
추측할 수 있는 원인:
- 캐시 메모리 초기화가 제대로 이뤄지지 않음
- 캐시 메모리 초기화에 필요한 정확한 대기 시간이 불명확하다. 초기화 과정이 실패했을 가능성이 있다.
- RAID 컨트롤러의 물리적인 장애
- RAID 컨트롤라 자체에 손상이 발새했을 가능성도 있음
그래서 다음 작업으로는, 여분 서버에서 RAID 컨트롤러를 교체하여 복구를 시도해보았다.
4. RAID 컨트롤러 교체
캐시 메모리 초기화가 실패한 이후, RAID 컨트롤러를 교차하기로 결정하였다. 장치 교체가 가장 확실한 해결책이라고 생각했다.
https://www.dell.com/support/contents/ko-kr/videos/videoplayer/poweredge-r720용-raid-카드를-교체하는-방법/6079773598001
다음 자료를 참고해서 작업을 진행하였다.
- 특히 DELL 홈페이지에 동영상으로 상세히 교체 방법이 있다.
교체 작업 진행 : RAID 컨트롤러
아래 사진은 작업 대상이였던 RAID 컨트롤러이다. (위 검색 사진과 똑같다.)
TMI: 우측 이미지에 중앙 네모난 부분이 배터리인데, 배터리 교체를 진행한다면 해당 부분을 교체해주면 된다.
여분 서버에서 부품 수령
올해 IDC에서 NCP로의 마이그레이션 과정 중 남겨진 여분의 서버들 덕분에 동일 모델 RAID 컨트롤러를 확보할 수 있었다.
대부분 폐기 예정이던 서버들인데, 내가 사내 개발환경으로 만들려고 쌓아둔 덕분이였다.(고맙다.. 과거의 나)
여기서 동일 모델의 서버에서 RAID 컨트롤러를 교체해보겠다.
교체 후 부팅 성공
RAID 컨트롤러를 교체하고 기도하며 서버를 다시 부팅하였다.
그리고 기도에 보답한걸까.... 성공적으로 부팅되었다.(본인은 무교다)
해당 메세지는 H750 RAID 컨트롤러를 교체 후 기존 RAID 구성 차이를 감지하여 적용하는 내용이다.
- Message PR1: 서버에 RAID 컨트롤러가 교체된 것을 감지했다.
- Message PR2: 교체된 RAID 컨트롤러와 디스크의 저장된 RAID 설정 간의 차이를 감지하였다.
- Message PR3: RAID 컨트롤러가 디스크에 저장된 RAID 구성을 성공적으로 불러와 적용하였다.
결과적으로 RAID 구성이 유지되었고, 데이터 접근이 정상적으로 복구되었다.
즉, RAID 컨트롤러 교체가 정상적으로 적용되었고, 모든 물리 디스크 상태가 정상 상태임을 확인하였다.
데이터 백업이 잘 되어 있어서 다행이였지, RAID 컨트롤러 장애는 정말 치명적인 문제로 이어질 수 있다는 것을 실감한 경험이였다.
단순 OS나 서비스 모니터링 뿐 아니라, 하드웨어 점검과 백업 프로세스를 더 체계화 할 필요가 있음을 느끼게 되었다.
이렇게 여분 서버를 활용하여 비용과 시간을 절약할 수 있었다.
+여담. Tomcat 소스 연결 문제(파일시스템 손상)
서버 복구 후 개발 서비스를 다시 배포하던 중, 개발자분으로부터 연락을 받았다.
해당 경로를 확인해보니 다음과 같이 데이터가 나타난다.
순간 데이터가 손상된 줄 알고 식은땀이 줄줄 흘렀다.
서버 복구 후 확인했을때는 기존 모든 데이터가 문제없이 존재했기 때문에 이 현상에 의문이 들었다.(해당 경로만 문제가 있었다.)
이후 확인해보니 RAID 복구와는 별개의 문제였다.
해당 경로에 소스 배포를 진행하던 중 서버가 다운되면서 파일 시스템이 손상된 것이 원인이였다.
파일 삭제 시도
일단 문제가 발생한 파일을 삭제하려 했으나, 아래와 같은 오류가 발생하였다.
rm: cannot remove 'WEB-INF/lib/log4j-api-2.17.2.jar': Structure needs cleaning
rm: cannot remove 'WEB-INF/lib/log4j-api-2.17.2.jar': Structure needs cleaning
rm 명령을 진행 시 나타났던 에러인데, 파일 시스템이 손상되었기에 해당 명령어를 동작시킬 수 없다는 것이였다.
이에 나는 다음과 같은 방법들로 삭제를 시도해보았다.
rm -rf
명령inode
번호 확인하여 삭제
(find / -inum 1234 -exec rm -rf {} ;)unlink
명령으로 삭제dev/null
로 파일 덤프
결론으로는 파일 시스템이 손상된 상태에서는 해당 디렉터리나 파일 자체에 접근이 불가능하기 때문에 위 방법들은 모두 실패하였다.
파일 시스템 복구 진행(fsck 명령어)
파일 시스템 복구를 위해 fsck 명령을 사용했다.
1. 스토리지 마운트 해제
파일 시스템을 복구 하기 이전, 일단 해당 스토리지 umount를 진행한다.
umount /application_data
2. fsck 명령으로 파일 시스템 복구
손상된 파티션에 대해 fsck 명령을 진행한다.
이번 경우는 여러 디스크를 LVM으로 묶어서 사용 중이었기 때문에 LVM 경로로 진행했다.
3. 복구 후 마운트
파일 시스템 복구가 완료된 후 다시 마운트를 진행하여 정상적으로 파일 삭제 및 재 배포가 완료되었다.
mount /application_data
5. 마무리
이번 작업을 통해 RAID 및 파일 시스템 복구라는 온프레미스 환경에서 전형적인 문제를 해결하면서 클라우드 중심의 업무 환경에서 잊고 있었던 중요한 교훈을 되새길 수 있었다.
클라우드 환경에 대한 기술과 관리에 집중하다 보니 온프레미스 환경과 로우 레벨 기술에 소홀했던 부분이 있었다는 점을 몸소 느낀 것 같다.. 특히! 물리 서버와 관련된 문제는 하드웨어와 소프트웨어간 섬세하고 긴밀한? 상호작용으로 많은 이해가 필요하다는 것을 다시 느끼게 되었다.
지금의 인프라 운영은 클라우드로 빠르게 전환되고 있다. 하지만 물리적인 환경이나 하드웨어에 기본적인 작동 원리에 대한 이해도는 언제나 중요한 기반이 되며 이번 같은 로우 레벨의 지식 또한 클라우드 문제 해결에 직접적이나 간접적으로도 기여할 수 있다고 생각한다.
역시 배움은 끝이 없는 것 같다. 클라우드와 온프레미스를 능숙히 다룰 수 있도록 열심히 노력해야겠다!!!
참고 자료
- https://www.dell.com/support/kbdoc/ko-kr/000110444/poweredge-하드-드라이브-및-raid-스토리지의-이해-유지-관리-및-문제-해결
- https://louky0714.tistory.com/137
- https://ubuntuforums.org/showthread.php?t=2348768
- https://www.2cpu.co.kr/bbs/board.php?bo_table=4raid&wr_id=1730
- https://www.2cpu.co.kr/QnA/816089
- https://www.dell.com/support/kbdoc/ko-kr/000148741/인텔-perc-및-lsi-컨트롤러를-사용하여-raid를-생성하는-방법
- https://pubs.lenovo.com/x3550-m5-8869/ko/t_installing_raid_adapter
'DevOps > 기타_장비' 카테고리의 다른 글
[NAS] 시놀로지 NAS 외장하드 백업(USB-Copy) (0) | 2023.08.10 |
---|---|
[NAS] 시놀로지 NAS 외장하드 백업(Hyper-Backup) (0) | 2023.08.09 |