일본 IDC 물리 서버 운영 중 mdadm 기반 소프트웨어 RAID 디스크 장애가 발생했을 때 진단부터 디스크 교체, 파티션 복제, Rebuild 및 부트로더 재설치까지의 실무 조치 가이드를 제공합니다.
서버 호스팅 및 코로케이션 환경에서 하드웨어 디스크 장애는 언제든 발생할 수 있는 주요 장애 요소 중 하나입니다. 하드웨어 RAID Controller를 사용하는 구성 외에도, Linux 환경에서는 커널 레벨의 mdadm을 활용한 소프트웨어 RAID(RAID 1, RAID 10 등)가 널리 사용됩니다. 전용서버는 물리 자원을 다른 인스턴스와 공유하지 않는 독립된 구성인 만큼 높은 I/O 안정성을 기대할 수 있지만, 디스크 상태 감지와 교체 작업은 운영자의 정교한 실무 절차를 요구합니다.
디스크 손상이 발생했을 때 적절한 초동 조치를 취하지 않으면 시스템 부팅 불가나 데이터 유실 위험이 생길 수 있습니다. 따라서 장애 디스크를 정확히 식별하고, 안전하게 제거한 뒤, 신규 디스크를 추가하여 Rebuild를 완료하는 표준 절차를 숙지하는 것이 중요합니다.
1. mdadm RAID 상태 진단 및 장애 디스크 식별
디스크 이상 징후가 감지되면 먼저 현재 RAID 배열의 상태를 파악해야 합니다. Linux 시스템에서는 커널의 RAID 상태 정보 파일과 mdadm 유틸리티를 활용해 장애 유무를 진단합니다.
RAID 상태 확인 기본 명령어
현재 구성된 RAID 디스크의 상태는 다음 명령어로 확인할 수 있습니다.
cat /proc/mdstat
정상 상태에서는 [UU] 표시가 나타나지만, 특정 디스크에 문제가 발생한 경우 [_U] 또는 [U_] 형태로 디스크 이탈 상태가 표시됩니다. 추가로 구체적인 장치 정보와 실패 원인을 확인하기 위해 아래 명령어를 수행합니다.
mdadm --detail /dev/md0
상세 정보 출력 화면에서 ‘State’ 항목이 degraded 상태인지 확인하고, ‘Failed Devices’ 목록에 포함된 블록 장치명(예: /dev/sdb1)을 확인합니다. 또한 dmesg 로그나 /var/log/messages를 분석하여 I/O 오류가 발생한 물리 디스크의 타겟을 정확히 지정해야 합니다.
2. 장애 디스크 오프라인 처리 및 교체 준비
물리적 디스크 교체 전, 소프트웨어 레벨에서 해당 디스크를 RAID 배열에서 명시적으로 실패(Fail) 처리하고 제거(Remove)하는 과정이 필요합니다.
소프트웨어 차원의 디스크 제거 절차
- 장애 디스크 Mark Fail 처리:
mdadm /dev/md0 --fail /dev/sdb1 - RAID 배열에서 장치 제거:
mdadm /dev/md0 --remove /dev/sdb1 - 스왑 및 기타 파티션 마운트 해제:
해당 디스크에 활성화된 Swap 파티션이 있다면 swapoff 명령을 통해 마운트를 해제합니다.
이후 IDC 현장 엔지니어에게 물리 디스크 교체를 요청해야 합니다. HARU IDC와 같이 원격 핸즈 서비스를 제공하는 환경에서는 정확한 디스크 슬롯 번호와 시리얼 번호를 전달하여 오작동으로 인한 정상 디스크 탈거 사고를 방지해야 합니다.
3. 신규 디스크 파티션 복제 및 Rebuild 진행
새 물리 디스크가 입고되어 교체 장착된 후에는 기존 정상 디스크의 파티션 구조를 신규 디스크로 동일하게 복제한 후 RAID 배열에 재편입해야 합니다.
파티션 구조 복제 (GPT 기준)
GPT 파티션 테이블을 사용하는 시스템에서는 sgdisk 유틸리티를 활용하여 기존 정상 디스크(/dev/sda)의 파티션 정보를 신규 디스크(/dev/sdb)로 복제합니다.
sgdisk -R /dev/sdb /dev/sdasgdisk -G /dev/sdb
RAID 배열에 파티션 재연결 및 Rebuild
파티션 설정이 완료되면 신규 파티션을 RAID 디스크에 추가합니다.
mdadm /dev/md0 --add /dev/sdb1
이 명령을 실행하면 즉시 동기화(Rebuild) 작업이 시작됩니다. cat /proc/mdstat을 조회하면 복구 진행률과 예상 완료 시간이 표시됩니다. Rebuild 진행 중에는 디스크 I/O 부하가 증가할 수 있으므로 서비스 트래픽 상황을 함께 모니터링해야 합니다.
4. 부트로더(GRUB) 재설치 및 장애 대비 점검
RAID 1 Mirroring 환경에서 primary 디스크가 교체되었거나 부팅 영역이 유실될 위험에 대비하여 신규 디스크에도 GRUB 부트로더를 올바르게 설치해주어야 합니다.
grub2-install /dev/sdb
부트로더 재설치가 완료되지 않으면, 추후 다른 정상 디스크에 추가 장애가 발생했을 때 교체된 디스크로 부팅을 시도하지 못하는 상황이 발생할 수 있습니다.
5. RAID 복구 작업 실무 체크리스트
디스크 장애 진단부터 복구까지 단계별로 점검해야 할 핵심 항목은 다음과 같습니다.
| 단계 | 작업 항목 | 주요 확인 명령어 및 내용 | 주의 사항 |
|---|---|---|---|
| 1. 장애 감지 | 디스크 상태 식별 | cat /proc/mdstat, dmesg 분석 | 정상 디스크와 장애 디스크 식별 오류 주의 |
| 2. 오프라인 | RAID 제거 및 파티션 해제 | mdadm –fail 및 –remove 실행 | 비활성화 전 프로세스 마운트 해제 확인 |
| 3. 물리 교체 | IDC 원격 핸즈 작업 요청 | 디스크 시리얼, 슬롯 위치 명시 | HARU IDC 원격 지원 요청 시 디스크 정보 정확히 전달 |
| 4. Rebuild | 파티션 복제 및 Array Add | sgdisk 복제 후 mdadm –add 실행 | 동기화 중 과도한 I/O 작업 최소화 |
| 5. 부트설정 | GRUB 재설치 및 모니터링 | grub2-install 및 smartd 연동 | 재부팅 테스트 전 부팅 영역 유효성 점검 |
6. 지속적인 모니터링과 체계적인 인프라 관리
소프트웨어 RAID 디스크 장애는 적절한 진단과 복구 절차를 거치면 서비스 중단 없이 안전하게 복구될 수 있습니다. 그러나 장애 발생 시점을 빠르게 인지하지 못하면 보조 디스크마저 다중 장애를 일으켜 심각한 데이터 손실로 이어질 수 있습니다.
따라서 smartd 모니터링 데몬을 구성하여 S.M.A.R.T. 오류를 사전에 감지하고, mdadm 메일 알림 기능을 활성화하여 이상 상태를 실시간으로 통보받는 모니터링 체계를 구축하는 것이 바람직합니다. 또한 운영 환경과 네트워크 조건에 맞는 서버 인프라 설계와 체계적인 원격 작업 대응 프로세스를 유지함으로써 인프라 신뢰도를 높일 수 있습니다.
일본 서버 및 IDC 인프라가 필요하신가요?
서비스 용도와 예상 트래픽을 알려주시면 적합한 서버와 네트워크 구성을 안내해드립니다.