RAID와 스토리지 이중화: 패리티, 핫스페어, 복구

RAID는 백업이 아니라 장애 시간을 줄이는 장치다

RAID는 여러 개의 디스크를 하나의 논리 장치처럼 묶어 성능, 용량, 내결함성을 조합하는 기술이다. Red Hat 문서는 RAID가 여러 HDD, SSD, NVMe를 하나의 배열로 묶어 단일 장치로는 얻기 어려운 성능 또는 중복성을 얻는 방식이라고 설명한다. Linux에서는 보통 커널의 md 드라이버와 mdadm으로 software RAID를 운영한다.

운영자가 가장 먼저 정리해야 할 문장은 이것이다. RAID는 백업이 아니다. RAID 1, RAID 5, RAID 6, RAID 10은 디스크 일부가 고장났을 때 서비스를 계속 유지하거나 복구 시간을 줄이는 데 도움을 준다. 하지만 다음 문제는 막지 못한다.

• 사용자가 데이터를 잘못 삭제했다.
• 애플리케이션 버그가 잘못된 값을 대량으로 썼다.
• 랜섬웨어나 악성 작업이 파일을 암호화했다.
• 컨트롤러, 파일시스템, 운영자 실수로 논리적 손상이 생겼다.
• 데이터센터, 리전, 랙 단위 장애가 발생했다.

따라서 RAID를 설계할 때의 질문은 “백업을 대신할 수 있는가?”가 아니라 “디스크 장애 한두 개를 서비스 장애로 번지지 않게 만들 수 있는가?”, “rebuild 동안 남은 위험을 감당할 수 있는가?”, “성능 저하와 용량 손실을 어느 정도 받아들일 것인가?”가 되어야 한다.

RAID 레벨을 용량 공식으로만 고르면 안 된다

RAID 레벨은 보통 용량 계산으로 소개된다. 하지만 운영 환경에서는 failure domain, write penalty, rebuild 시간, 관측 가능성까지 같이 봐야 한다.

RAID 0: 성능은 있지만 내결함성은 없다

RAID 0은 striping이다. 데이터를 여러 디스크에 나누어 쓰므로 대역폭은 늘 수 있지만, 어느 한 디스크라도 잃으면 논리 볼륨 전체가 깨진다. 재생성 가능한 임시 처리 공간, 캐시, scratch 영역이 아니라면 운영 데이터에는 맞지 않는다.

RAID 1: 단순하고 복구가 쉽다

RAID 1은 mirroring이다. 같은 데이터를 두 개 이상의 디스크에 쓴다. 하나의 멤버가 죽어도 다른 멤버로 읽을 수 있고, 구조가 단순해 장애 대응이 직관적이다. 부트 볼륨, 작은 metadata 볼륨, 장애 대응을 단순하게 만들고 싶은 환경에 잘 맞는다. 단점은 용량 효율이다. 두 장 mirror라면 물리 용량의 절반만 쓴다.

RAID 5: 단일 패리티의 비용과 위험

RAID 5는 distributed parity를 사용한다. N개 디스크 중 대략 1개 디스크 분량을 패리티에 쓰므로 용량 효율이 좋고, 디스크 1개 실패를 견딘다. 하지만 작은 random write에서는 기존 데이터와 기존 패리티를 읽고, 새 데이터와 새 패리티를 쓰는 과정이 필요하다. 이것이 흔히 말하는 write penalty다.

RAID 5의 더 큰 운영 이슈는 rebuild 창이다. 디스크 하나가 빠진 degraded 상태에서는 남은 디스크를 강하게 읽어 replacement 디스크를 채워야 한다. 이 기간 동안 추가 디스크 장애나 unrecoverable read error가 발생하면 데이터 손실로 이어질 수 있다. 큰 HDD 배열에서 RAID 5를 조심해야 하는 이유가 여기에 있다.

RAID 6: 이중 패리티로 rebuild 위험을 낮춘다

RAID 6은 두 개 디스크 장애를 견딜 수 있도록 dual distributed parity를 둔다. 용량은 대략 N-2개 디스크만큼 사용할 수 있고, 쓰기 비용은 RAID 5보다 더 크다. 대용량 HDD, 긴 rebuild 시간, 읽기 많은 저장소라면 RAID 5보다 RAID 6이 안전한 선택이 되는 경우가 많다.

RAID 10: 비싸지만 운영자가 좋아하는 구조

RAID 10은 mirror와 stripe를 결합한다. 패리티 계산이 없고, random write 지연이 낮으며, rebuild도 보통 mirror 한 쌍 안에서 단순하게 진행된다. 물리 용량의 절반을 중복성에 쓰므로 비용은 높지만, DB의 write-heavy workload나 지연 민감 workload에서는 RAID 5/6보다 예측 가능하다.

패리티는 마법이 아니라 재구성 공식이다

패리티 RAID를 이해할 때 중요한 점은 “패리티 디스크가 데이터를 백업한다”가 아니라 “같은 stripe 안의 나머지 블록으로 빠진 블록을 계산한다”는 것이다. RAID 5는 stripe마다 패리티 위치를 분산한다. RAID 6은 두 종류의 패리티를 두어 두 개 블록 손실까지 계산할 수 있게 한다.

간단히 보면 RAID 5의 한 stripe는 다음과 같은 구조다.

Stripe 1: Disk A = data1, Disk B = data2, Disk C = parity(data1,data2)
Stripe 2: Disk A = data3, Disk B = parity(data3,data4), Disk C = data4
Stripe 3: Disk A = parity(data5,data6), Disk B = data5, Disk C = data6

Disk B가 죽으면 RAID는 Disk A와 Disk C의 값으로 Disk B 위치의 값을 계산해 읽기를 계속할 수 있다. replacement 디스크를 넣으면 모든 stripe를 훑으며 빠진 내용을 다시 써서 rebuild한다.

패리티 RAID에서 운영자가 조심해야 할 포인트는 세 가지다.

1. 쓰기 증폭: 작은 write가 parity read/modify/write로 커질 수 있다.
2. degraded 성능 저하: 빠진 디스크의 데이터를 매번 계산해야 하므로 읽기도 느려질 수 있다.
3. rebuild 위험: 남은 모든 디스크를 장시간 읽기 때문에 latent bad sector가 드러날 수 있다.

Linux kernel 문서는 RAID 5/6 배열이 dirty이면서 degraded인 경우 parity를 신뢰할 수 없고 일부 data block이 빠진 상태라 감지되지 않는 corruption이 있을 수 있다고 경고한다. 그래서 md는 이런 배열을 보통 자동으로 시작하지 않는다. mdadm --assemble --force는 마지막 수단에 가까운 명령이며, 데이터 손상 가능성을 이해한 상태에서만 사용해야 한다.

Hot spare는 장애를 없애지 않고 노출 시간을 줄인다

Hot spare는 평소에는 idle 상태로 대기하다가 배열의 멤버가 실패하면 자동으로 rebuild 대상이 되는 예비 디스크다. Thomas-Krenn의 mdadm 복구 설명처럼 spare가 있는 배열에서는 디스크가 faulty로 표시되면 spare가 투입되고 rebuild가 자동으로 시작될 수 있다.

Hot spare의 장점은 명확하다.

• 운영자가 새 디스크를 꽂기 전까지 기다리는 시간을 줄인다.
• 야간·주말 장애에서 degraded 상태로 방치되는 시간을 줄인다.
• rebuild 시작을 자동화해 RTO를 낮춘다.

하지만 hot spare에도 한계가 있다.

• spare 자체가 오래 대기하다가 실제 사용 시 불량일 수 있다.
• rebuild가 시작되면 남은 디스크에 큰 읽기 부하가 걸린다.
• 같은 제조 lot, 같은 사용 시간의 디스크가 동시에 약해질 수 있다.
• hot spare는 논리적 삭제, corruption, 랜섬웨어를 막지 못한다.

그래서 hot spare는 “장애 대응 자동화”이지 “복구 보장”이 아니다. 운영 기준으로는 hot spare를 둔 뒤에도 array event 알림, SMART 지표, 정기 scrub, 백업 복구 리허설을 함께 운영해야 한다.

# mdadm에서 spare 추가 예시. 실제 장비에서는 디스크 식별을 반드시 확인한다.
mdadm --manage /dev/md0 --add /dev/sde1

# 상태 확인
mdadm --detail /dev/md0
cat /proc/mdstat

Rebuild는 복구 작업이면서 가장 위험한 부하 테스트다

디스크 하나가 고장나고 replacement를 넣으면 RAID는 rebuild를 시작한다. rebuild는 남은 멤버에서 데이터를 읽고 새 멤버에 다시 쓰는 작업이다. cat /proc/mdstat에는 보통 recovery, 진행률, 예상 시간, 속도가 표시된다.

md0 : active raid1 sdc1[2] sdb1[3]
      2095040 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.4% finish=3.6min speed=9600K/sec

여기서 [2/1]은 기대하는 RAID device가 2개이고 현재 active가 1개라는 뜻이며, [U_]는 한 멤버가 올라와 있고 다른 멤버가 빠졌거나 rebuild 중이라는 신호다.

운영자는 rebuild를 단순한 진행률로만 보면 안 된다. rebuild 동안에는 다음을 같이 봐야 한다.

대용량 HDD 배열에서는 rebuild가 몇 시간에서 며칠까지 갈 수 있다. 이 시간 동안 배열은 정상 상태보다 취약하다. 특히 RAID 5 degraded 상태에서 남은 디스크 중 하나가 추가로 실패하면 허용 범위를 넘는다. RAID 6은 이 위험을 줄이지만, rebuild 부하 자체가 사라지는 것은 아니다.

Rebuild 속도 조절은 SLO와 함께 결정한다

rebuild를 빠르게 끝내면 degraded 노출 시간은 줄어든다. 대신 운영 workload latency가 나빠질 수 있다. 반대로 rebuild를 너무 느리게 하면 서비스 성능은 보호되지만 위험 창이 길어진다. 운영자는 시간대, workload 중요도, 백업 상태, 남은 디스크 health를 보고 rebuild throttle을 결정해야 한다.

Linux md에는 rebuild 관련 sysfs 제어 지점이 있다. 배포판과 kernel 버전에 따라 세부 값은 다를 수 있으므로 운영 표준을 문서화해야 한다.

# 현재 md 상태 확인
cat /proc/mdstat
mdadm --detail /dev/md0

# md 관련 sysfs 위치 확인
ls /sys/block/md0/md

Scrub과 consistency check는 “나중에 터질 읽기 오류”를 미리 찾는 일이다

RAID 배열에서 무서운 상황은 평소에는 조용하다가 rebuild 중에 남은 디스크에서 읽기 불가능한 sector가 드러나는 경우다. 이때는 이미 degraded 상태이기 때문에 재구성에 필요한 입력이 부족해질 수 있다.

그래서 운영 환경에서는 정기적인 consistency check 또는 scrub이 중요하다. Red Hat 문서는 Linux software RAID의 특징 중 하나로 RAID 데이터의 정기 consistency check와 bad sector 자동 보정을 언급한다. device-mapper RAID 문서도 check, repair 같은 동작을 통해 배열 점검과 수리를 구분한다.

운영 관점에서는 다음처럼 나눠 생각한다.

• check/scrub: parity 또는 mirror 일관성을 읽어 검증한다.
• repair: 발견된 불일치를 수정한다. 잘못된 쪽을 확실히 아는지 주의해야 한다.
• SMART long test: RAID 계층 아래 물리 디스크의 읽기 가능성을 점검한다.
• backup restore drill: RAID가 아니라 백업이 실제로 복구 가능한지 검증한다.

Scrub은 공짜가 아니다. 대량 읽기를 발생시키므로 운영 workload와 충돌할 수 있다. 그렇다고 무기한 미루면 latent error를 rebuild 당일에 처음 발견한다. 보통은 낮은 트래픽 시간대에 주기적으로 실행하고, check 결과와 SMART 변화를 알림으로 연결한다.

Hardware RAID, Software RAID, JBOD의 운영 차이

RAID는 구현 위치에 따라 운영 방식이 크게 달라진다.

하드웨어 RAID는 컨트롤러가 논리 볼륨을 OS에 보여주므로 운영자가 디스크 상세 상태를 놓치기 쉽다. 배터리나 flash-backed cache 상태가 나쁘면 write-back cache 정책이 바뀌어 성능이 갑자기 달라질 수 있다. 또한 컨트롤러 장애 시 동일하거나 호환되는 컨트롤러가 필요할 수 있다.

Linux software RAID는 mdadm --detail, /proc/mdstat, /sys/block/md*/md로 상태를 비교적 투명하게 볼 수 있고, 배열 metadata가 디스크에 있어 다른 Linux 시스템으로 이식하기 쉬운 장점이 있다. 대신 운영자가 initramfs, boot assembly, metadata version, 알림 구성을 이해해야 한다.

DBA 관점에서는 RAID만 보지 말고 상위 계층의 복제와 함께 설계해야 한다. 예를 들어 primary-replica DB 구조라면 한 노드 안의 RAID는 “노드 내부 디스크 장애”를 줄이고, DB replication은 “노드 전체 장애”를 줄인다. 둘 중 하나가 다른 하나를 대체하지 않는다.

DB와 데이터 플랫폼에서의 선택 기준

1. Write-heavy OLTP는 RAID 10을 우선 검토한다

작은 random write가 많은 OLTP DB는 parity RAID의 write penalty에 민감하다. 물론 SSD/NVMe, controller cache, workload 패턴에 따라 결과는 달라진다. 하지만 운영 단순성과 latency 예측 가능성을 중시하면 RAID 10이 여전히 강한 선택지다.

2. 백업 저장소와 읽기 많은 아카이브는 RAID 6을 검토한다

대용량 HDD 기반 백업 저장소는 용량 효율이 중요하다. 이때 RAID 5는 rebuild 창에서 위험할 수 있으므로 RAID 6이 더 안전한 경우가 많다. 단, 백업 저장소는 RAID와 별개로 offsite copy, immutability, restore test가 필요하다.

3. Cloud block storage에서는 provider replication을 먼저 이해한다

EBS, Persistent Disk, Azure Disk 같은 managed block storage는 이미 provider 내부에서 복제된다. 그 위에 OS RAID를 얹는 것은 성능 striping, 용량 확장, 특정 장애 모델을 위한 선택일 수 있지만, 무조건 안전해지는 것은 아니다. cloud에서는 availability zone, snapshot, volume type, IOPS/throughput limit, backup policy가 RAID 레벨보다 더 중요한 경우가 많다.

4. Kubernetes PV에서는 node failure와 disk failure를 분리한다

local PV 위에 RAID를 구성하면 노드 내부 디스크 장애에는 강해질 수 있다. 하지만 노드가 죽으면 pod는 여전히 영향을 받는다. Stateful workload에서는 storage class, replication layer, pod disruption, backup/restore, failover runbook을 같이 설계해야 한다.

운영 런북: 디스크 장애가 났을 때의 순서

장애 상황에서 가장 위험한 행동은 “일단 아무 디스크나 빼고 rebuild를 누르는 것”이다. RAID member 순서, failed disk 식별, stale member 여부를 잘못 판단하면 복구 가능성을 낮출 수 있다.

안전한 런북은 보통 다음 순서다.

1. 쓰기 중단 여부 판단: 데이터 손상 징후가 있거나 다중 장애라면 서비스를 내리고 원본 보존을 우선한다.
2. 현재 상태 캡처: mdadm --detail, /proc/mdstat, controller log, SMART, kernel log를 저장한다.
3. 백업 확인: 최신 백업과 restore 가능성을 확인한다.
4. 정확한 물리 디스크 식별: serial number, slot, enclosure 정보를 대조한다.
5. failed member 제거: 도구가 표시한 failed device만 제거한다.
6. replacement 추가: 같은 크기 이상, 호환되는 디스크를 추가한다.
7. rebuild 모니터링: 진행률, latency, read error, 남은 디스크 SMART를 같이 본다.
8. 완료 후 검증: array state가 clean인지, filesystem/DB consistency check가 필요한지 확인한다.
9. 사후 조치: 원인, 알림, spare 정책, scrub 주기, 백업 복구 시간을 갱신한다.

Linux software RAID에서 대표적인 확인 명령은 다음과 같다.

cat /proc/mdstat
mdadm --detail /dev/md0
journalctl -k --since "2 hours ago"
smartctl -a /dev/sdX

mdadm --assemble --force, --assume-clean, array recreate 같은 명령은 일반 운영 런북의 앞부분에 두면 안 된다. 이런 명령은 metadata와 parity 상태를 바꾸어 원본 복구 가능성을 낮출 수 있다. 다중 장애, 불확실한 member 순서, rebuild 실패가 있으면 먼저 원본 디스크를 보존하고 전문가 복구 또는 image-first 절차를 검토해야 한다.

핵심 정리

• RAID는 디스크 장애에 대한 availability 장치이지 backup이 아니다.
• RAID 0은 중복성이 없으므로 운영 데이터 보호 수단이 아니다.
• RAID 1은 단순하고 복구가 쉽지만 용량 효율이 낮다.
• RAID 5는 용량 효율이 좋지만 단일 장애 허용과 rebuild 위험을 감수해야 한다.
• RAID 6은 대용량 HDD 배열에서 RAID 5보다 안전한 경우가 많지만 write penalty가 더 크다.
• RAID 10은 비용이 높지만 write-heavy DB에서 latency와 rebuild가 예측 가능하다.
• Hot spare는 degraded 노출 시간을 줄이지만, rebuild 부하와 추가 장애 위험을 없애지는 못한다.
• 정기 scrub, SMART 모니터링, 백업 restore drill이 RAID 운영의 일부여야 한다.
• 장애 시에는 상태 캡처, 정확한 디스크 식별, 백업 확인, 신중한 rebuild 순서가 중요하다.

References

• Red Hat Documentation, “Managing RAID,” RHEL 8 Managing storage devices. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_storage_devices/managing-raid_managing-storage-devices
• Linux Kernel Documentation, “RAID arrays.” https://docs.kernel.org/admin-guide/md.html
• mdadm(8) Linux manual page. https://man7.org/linux/man-pages/man8/mdadm.8.html
• Linux RAID Wiki, “RAID setup” archived page. https://raid.wiki.kernel.org/index.php/RAID_setup
• Thomas-Krenn Wiki, “Mdadm recovery and resync.” https://www.thomas-krenn.com/en/wiki/Mdadm_recovery_and_resync