하드웨어 중급 #6 RAID 운영의 실제 — 리빌드, 스크럽, 그리고 백업

인프라 하드웨어
5 분 소요

5편이 디스크 한 장의 성능이었다면, 이번 글은 여러 장의 운영입니다. 기초 5편에서 RAID 레벨의 개념(0/1/5/6/10)을 잡았으니, 여기서는 운영자가 실제로 마주치는 장면으로 갑니다. RAID의 진짜 시험은 디스크가 멀쩡할 때가 아니라 한 장이 죽은 다음에 시작되기 때문입니다.

디그레이드 — 한 장이 죽은 상태로 달리기 #

디스크 한 장이 죽으면 어레이는 디그레이드(degraded, 중복성을 잃은 채 동작하는 상태)로 들어갑니다. 서비스는 계속 돌지만 두 가지가 달라집니다.

  • 성능이 떨어집니다. 패리티 방식(RAID5/6)에서는 죽은 디스크의 데이터를 매 읽기마다 나머지 디스크의 패리티로 계산해 복원해야 합니다.
  • 여유가 사라집니다. RAID5라면 이제 한 장만 더 죽어도 어레이 전체가 끝납니다.

그래서 디그레이드는 “아직 괜찮은 상태"가 아니라 카운트다운이 시작된 상태입니다. 모니터링이 어레이 상태를 사람에게 알리는 데까지 이어져 있는지가, RAID 운영에서 가장 먼저 점검할 항목입니다.

리빌드 — 가장 위험한 시간 #

죽은 디스크를 갈아 끼우면 리빌드(rebuild, 남은 디스크들에서 데이터를 재계산해 새 디스크를 채우는 일)가 시작됩니다. 역설적이게도 이 복구 시간이 어레이의 일생에서 가장 위험한 시간입니다.

  • 오래 걸립니다. 리빌드는 새 디스크를 처음부터 끝까지 채우는 일이라, 수십 TB 디스크에서는 하루를 넘기기도 합니다. 서비스 I/O 와 경합하면 더 깁니다.
  • 나머지 디스크가 혹사당합니다. 리빌드는 남은 모든 디스크를 끝까지 읽습니다. 같은 시기에 사서 같은 수명을 달려온 디스크들에게 최대 부하가 걸리니, 두 번째 고장이 하필 이때 나올 확률이 평소보다 높습니다.
  • URE를 만날 수 있습니다. URE(Unrecoverable Read Error, 디스크가 끝내 읽어 내지 못하는 섹터 오류)는 카탈로그에 “10^14비트당 1회” 같은 확률로 적혀 있습니다. 평소에는 중복성이 가려 주지만, RAID5의 리빌드 중에는 가려 줄 중복이 없습니다. 수십 TB를 전부 읽는 동안 한 번이라도 만나면 그 지점의 데이터는 잃습니다.

마지막 항목이 “대용량 디스크 시대에 RAID5는 위험하다"는 격언의 근거입니다. 디스크가 클수록 리빌드에서 읽는 양이 늘어 URE를 만날 확률이 커지므로, 큰 디스크로는 패리티가 두 장인 RAID6, 혹은 리빌드가 빠른 RAID10이 보수적인 선택이 됩니다.

핫스페어와 스크럽 — 사건을 줄이는 두 습관 #

운영에서 리스크를 줄이는 표준 장치가 두 가지 있습니다.

  • 핫스페어(hot spare) — 어레이에 미리 꽂아 두는 대기 디스크입니다. 고장이 나면 사람을 기다리지 않고 즉시 리빌드가 시작되어, 디그레이드로 머무는 시간을 줄입니다. 새벽의 고장과 출근 사이, 디그레이드로 노출되는 몇 시간을 줄여 주는 보험입니다.
  • 스크럽(scrub) — 어레이 전체를 주기적으로 읽어 잠복한 불량 섹터를 미리 찾아 고치는 점검입니다. 평소에 안 읽는 영역의 URE는 스크럽이 아니면 리빌드 날까지 숨어 있다가 최악의 순간에 나타납니다. mdadm이든 ZFS든 하드웨어 컨트롤러든 같은 개념이 있고, 보통 주 단위나 월 단위 스케줄로 돌립니다.

요약하면 핫스페어는 사건 후의 시간을, 스크럽은 사건 자체의 확률을 줄입니다. 어느 쪽도 설정 한 줄 수준의 비용입니다.

쓰기 캐시와 배터리 — 성능과 안전의 거래 #

하드웨어 RAID 컨트롤러의 쓰기 성능은 상당 부분 컨트롤러 위의 쓰기 캐시에서 나옵니다. 쓰기를 캐시에 받고 즉시 완료로 응답하는 라이트백(write-back) 모드입니다. 3편의 더티 페이지와 같은 구조의 거래라서 같은 약점이 있습니다. 디스크에 내려가기 전에 전원이 나가면 그 쓰기는 사라지고, 파일 시스템이나 DB가 “완료됐다"고 믿은 데이터라서 피해가 큽니다.

그래서 컨트롤러에는 배터리나 플래시 백업(BBU/CacheVault)이 붙습니다. 정전 시 캐시 내용을 지켜 부팅 후 마저 쓰는 장치입니다. 운영 포인트는 하나입니다. 배터리가 죽으면 컨트롤러가 보통 라이트스루(write-through)로 강등되어 쓰기 성능이 뚝 떨어집니다. “어느 날 갑자기 DB 쓰기가 느려졌다"의 답이 배터리 수명 만료인 사례는 흔합니다. 배터리 상태도 모니터링 항목입니다.

RAID는 백업이 아닙니다 — 운영 버전 #

기초 5편에서도 짚었지만, 운영의 언어로 다시 정리할 가치가 있습니다. RAID가 막아 주는 것은 디스크 하드웨어의 고장, 그 한 가지입니다.

  • 실수로 지운 파일은 모든 디스크에서 성실하게 동시에 지워집니다.
  • 랜섬웨어의 암호화도, 버그가 쓴 잘못된 데이터도 마찬가지로 충실히 복제됩니다.
  • 컨트롤러 고장이나 화재는 어레이 전체를 한 번에 가져갑니다.

그래서 RAID는 가용성(디스크가 죽어도 서비스가 계속) 장치이고, 백업은 복구(잘못된 과거로 돌아가기) 장치입니다. 둘은 대체 관계가 아니라 둘 다 필요한 관계입니다. ZFS 같은 체크섬 기반 파일 시스템은 여기에 무결성(조용한 데이터 손상의 탐지·자가 복구)을 더해 주지만, 그것도 백업의 대체는 아닙니다.

자주 만나는 함정 #

  • 디그레이드 알림이 사람에게 닿지 않는다 — 디그레이드인 채 몇 주를 달리다 두 번째 고장으로 끝나는 사고의 원인은 기술이 아니라 알림 경로입니다. 어레이 상태 모니터링부터 점검합니다.
  • 리빌드 완료까지를 복구로 본다 — 리빌드 중이 최고 위험 구간입니다. 그 시간 동안만이라도 백업 주기를 당기거나 변경 작업을 미루는 운영 판단이 필요합니다.
  • 스크럽 없이 대용량 RAID5를 돌린다 — 잠복 URE 와 리빌드의 조합이 최악의 시나리오입니다. 스크럽을 켜고, 새 어레이라면 RAID6/10을 검토합니다.

정리 #

이번 글에서 잡은 그림입니다.

  • 디그레이드는 카운트다운 상태이고, 리빌드는 시간·혹사·URE 세 이유로 가장 위험한 구간입니다.
  • 디스크가 클수록 RAID5의 리빌드 리스크가 커집니다. 핫스페어와 스크럽이 기본 장치입니다.
  • 라이트백 캐시의 성능은 배터리가 담보합니다. 배터리 상태까지 모니터링에 넣습니다.
  • RAID는 가용성, 백업은 복구입니다. 서로를 대체하지 않습니다.

다음 — 스토리지 네트워크 #

여기까지는 서버 안의 디스크였습니다. 다음 글인 “하드웨어 중급 #7 스토리지 네트워크"에서는 디스크가 서버 밖으로 나갑니다. 기초 5편에서 개념만 본 SAN을 실제로 잇는 iSCSI 와 FC, 그 위에서 끊기지 않는 길을 만드는 멀티패스, 그리고 NVMe 시대의 NVMe-oF까지 다룹니다.

X