UTM Ubuntu 환경에서 mdadm RAID 0/1/5 구성 및 장애 복구 실습

1. 개요

UTM Ubuntu 환경에서 mdadm을 사용하여 RAID 0, RAID 1, RAID 5를 구성하고, 실제 가상 디스크를 제거하여 장애 상황을 재현하였다. 단순히 RAID 배열을 생성하는 것에서 끝내지 않고, 다음 흐름까지 함께 확인하였다.

실습 흐름은 다음과 같다

• RAID 0 / RAID 1 / RAID 5 생성
• ext4 파일시스템 생성 및 마운트
• /etc/fstab, /etc/mdadm/mdadm.conf를 통한 자동 마운트 및 자동 조립 설정
• 실제 가상 디스크 제거를 통한 장애 상황 확인
• RAID 1, RAID 5의 degraded 상태 확인
• 새 디스크 추가 후 rebuild
• RAID 0의 데이터 손실 및 재생성 확인

RAID 레벨별 장애 대응 차이

2. 실습 환경

이번 실습은 Apple Silicon Mac에서 UTM으로 Ubuntu 가상머신을 구성한 뒤 진행하였다.

실습 교재에서는 디스크 장치명이 /dev/sdb, /dev/sdc처럼 sd* 형식으로 설명되어 있었으나 UTM의 VirtIO 디스크 환경에서는 /dev/vdb, /dev/vdc처럼 vd* 형식으로 인식된다.

따라서 교재의 /dev/sdX 명령어는 모두 현재 환경에 맞게 /dev/vdX로 변경하여 진행하였다.

3. 초기 디스크 구성

먼저 lsblk 명령으로 확인한 디스크 초기 구성은 다음과 같다.

/dev/vda /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf /dev/vdg /dev/vdh

그리고 용도는 아래와 같이 할당하였다.

OS가 설치된 /dev/vda는 절대 RAID 실습 대상으로 사용하면 안 된다. 실습 대상은 추가한 1GB 디스크인 /dev/vdb부터 /dev/vdh까지이다.

4. RAID용 파티션 생성

각 디스크에는 RAID용 파티션을 생성하였다.

먼저 /dev/vdb에 RAID용 파티션을 만든 뒤, 동일한 파티션 구조를 나머지 디스크에 복사하였다.

for d in /dev/vd{c,d,e,f,g,h}; do
  sudo sfdisk -d /dev/vdb | sudo sfdisk "$d"
done

파티션 생성 후 확인하였다.

sudo fdisk -l /dev/vd* | grep "Linux raid"

확인 결과 /dev/vdb1부터 /dev/vdh1까지 모두 Linux raid autodetect 타입으로 생성되었다.

/dev/vdb1  Linux raid autodetect
/dev/vdc1  Linux raid autodetect
/dev/vdd1  Linux raid autodetect
/dev/vde1  Linux raid autodetect
/dev/vdf1  Linux raid autodetect
/dev/vdg1  Linux raid autodetect
/dev/vdh1  Linux raid autodetect

5. RAID 0, RAID 1, RAID 5 생성

이제 mdadm을 사용하여 RAID 배열을 생성하였다.

RAID 0 생성

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/vdb1 /dev/vdc1

RAID 1 생성

sudo mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/vdd1 /dev/vde1

RAID 5 생성

sudo mdadm --create /dev/md5 --level=5 --raid-devices=3 /dev/vdf1 /dev/vdg1 /dev/vdh1

생성 후 상태는 다음 명령어로 확인하였다.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo mdadm --detail /dev/md1
sudo mdadm --detail /dev/md5

구성 결과는 다음과 같다.

6. 파일시스템 생성 및 마운트

RAID 장치를 생성한 뒤 ext4 파일시스템을 생성하였다.

sudo mkfs.ext4 /dev/md0
sudo mkfs.ext4 /dev/md1
sudo mkfs.ext4 /dev/md5

마운트할 디렉터리를 생성하였다.

sudo mkdir -p /raid0 /raid1 /raid5

각 RAID 장치를 마운트하였다.

sudo mount /dev/md0 /raid0
sudo mount /dev/md1 /raid1
sudo mount /dev/md5 /raid5

마운트 상태는 다음 명령어로 확인하였다.

df -h | grep raid
lsblk

정상적으로 마운트되면 다음과 같이 확인된다.

/dev/md0  /raid0
/dev/md1  /raid1
/dev/md5  /raid5

7. 테스트 파일 생성

장애 테스트 전 각 RAID에 테스트 파일을 생성하였다.

echo "raid0 test" | sudo tee /raid0/test.txt
echo "raid1 test" | sudo tee /raid1/test.txt
echo "raid5 test" | sudo tee /raid5/test.txt

파일이 정상적으로 생성되었는지 확인하였다.

cat /raid0/test.txt
cat /raid1/test.txt
cat /raid5/test.txt

출력 결과는 다음과 같았다.

raid0 test
raid1 test
raid5 test

8. 자동 조립 및 자동 마운트 설정

RAID 장치를 재부팅 후에도 자동으로 사용할 수 있도록 두 가지 설정을 진행하였다.

mdadm 설정 저장

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

이 설정을 통해 부팅 과정에서 /dev/md0, /dev/md1, /dev/md5 배열이 자동으로 조립되도록 하였다.

fstab 등록

파일시스템 UUID를 확인하였다.

blkid /dev/md0 /dev/md1 /dev/md5

/etc/fstab에는 개별 디스크 파티션이 아니라 RAID 장치 위에 생성된 ext4 파일시스템 UUID를 등록하였다.

UUID=<md0의 ext4 UUID> /raid0 ext4 defaults,nofail 0 2
UUID=<md1의 ext4 UUID> /raid1 ext4 defaults,nofail 0 2
UUID=<md5의 ext4 UUID> /raid5 ext4 defaults,nofail 0 2

여기서 nofail 옵션을 넣은 이유는 실습 중 디스크 장애나 RAID 조립 실패가 발생하더라도 부팅이 중단되지 않도록 하기 위해서이다.

설정 후 다음 명령어로 검증하였다.

sudo mount -a
df -h | grep raid

9. 재부팅 후 정상 상태 확인

재부팅 후 RAID 배열과 마운트 상태를 확인하였다.

cat /proc/mdstat
df -h | grep raid
lsblk

확인 결과 /dev/md0, /dev/md1, /dev/md5가 모두 정상적으로 자동 조립되었고, /raid0, /raid1, /raid5에 자동 마운트되었다.

10. 실제 디스크 제거를 통한 장애 테스트

일반적으로는 mdadm --fail 명령으로 장애 상태를 만들 수 있다. 하지만 이번 실습에서는 더 직관적인 장애 상황을 확인하기 위해 UTM에서 실제 가상 디스크를 제거하였다.

각 RAID에서 디스크 하나씩 제거하였다.

디스크를 제거한 뒤 부팅하여 상태를 확인하였다.

cat /proc/mdstat
df -h | grep raid
lsblk

초기 상태에서는 일부 RAID 배열이 inactive 상태로 잡혔다.

md0 : inactive
md1 : inactive
md5 : inactive

RAID 1과 RAID 5는 디스크 하나가 빠져도 동작할 수 있으므로 수동으로 실행하였다.

sudo mdadm --run /dev/md1
sudo mdadm --run /dev/md5

그 후 상태는 다음과 같았다.

md0 : inactive
md1 : active raid1 [2/1] [U_]
md5 : active raid5 [3/2] [U_U]

11. 장애 상태에서 데이터 접근 확인

RAID 1과 RAID 5를 마운트하였다.

sudo mount /raid1
sudo mount /raid5

파일 접근을 확인하였다.

cat /raid1/test.txt
cat /raid5/test.txt
cat /raid0/test.txt

결과는 다음과 같았다.

raid1 test
raid5 test
cat: /raid0/test.txt: 그런 파일이나 디렉터리가 없습니다

이 결과를 통해 다음을 확인할 수 있었다.

RAID 0은 스트라이핑 구조이기 때문에 디스크 하나가 사라지면 전체 데이터 구조가 깨진다. 반면 RAID 1은 미러링 구조이고, RAID 5는 패리티 기반 구조이므로 단일 디스크 장애 상황에서도 데이터를 읽을 수 있었다.

12. 새 디스크 추가

장애 상황을 확인한 뒤, UTM에서 새 1GB 디스크 3개를 추가하였다.

부팅 후 lsblk로 확인한 결과 새 디스크는 다음과 같이 인식되었다.

/dev/vdf
/dev/vdg
/dev/vdh

새 디스크에 기존 RAID용 파티션 구조를 복사하였다.

sudo sfdisk -d /dev/vdb | sudo sfdisk /dev/vdf
sudo sfdisk -d /dev/vdb | sudo sfdisk /dev/vdg
sudo sfdisk -d /dev/vdb | sudo sfdisk /dev/vdh
sudo partprobe

확인 결과 /dev/vdf1, /dev/vdg1, /dev/vdh1 파티션이 생성되었다.

13. RAID 1 복구

RAID 1은 /dev/vdc1 하나만으로 degraded 상태로 동작 중이었다. 여기에 새 디스크 /dev/vdg1을 추가하였다.

sudo mdadm /dev/md1 --add /dev/vdg1

복구 진행 상황은 다음 명령어로 확인하였다.

watch cat /proc/mdstat

복구 후 상세 상태를 확인하였다.

sudo mdadm --detail /dev/md1

결과는 다음과 같았다.

State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0

기존 파일도 정상적으로 유지되었다.

cat /raid1/test.txt

raid1 test

14. RAID 5 복구

RAID 5는 /dev/vdd1, /dev/vde1 두 개만으로 degraded 상태로 동작 중이었다. 여기에 새 디스크 /dev/vdh1을 추가하였다.

sudo mdadm /dev/md5 --add /dev/vdh1

복구 진행 상황을 확인하였다.

watch cat /proc/mdstat

복구 후 상세 상태를 확인하였다.

sudo mdadm --detail /dev/md5

결과는 다음과 같았다.

State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0

기존 파일도 정상적으로 유지되었다.

cat /raid5/test.txt

raid5 test

실제 실습 로그에서도 RAID 1과 RAID 5는 새 디스크 추가 후 clean 상태로 복구되었고, 기존 테스트 파일을 정상적으로 읽을 수 있었다.

15. RAID 0 재생성

RAID 0은 장애 허용 기능이 없다. 따라서 디스크 하나가 제거된 이후 기존 데이터를 복구할 수 없었다.

기존 inactive 상태의 RAID 0 배열을 중지하였다.

sudo mdadm --stop /dev/md0

남아 있던 RAID 0 구성 디스크와 새 디스크의 superblock을 정리하였다.

sudo mdadm --zero-superblock /dev/vdb1
sudo mdadm --zero-superblock /dev/vdf1

새로 RAID 0을 생성하였다.

sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/vdb1 /dev/vdf1

그리고 ext4 파일시스템을 다시 생성하였다.

sudo mkfs.ext4 /dev/md0

파일시스템을 다시 만들었기 때문에 기존 /raid0/test.txt는 사라지는 것이 정상이다.

마운트하였다.

sudo mount /dev/md0 /raid0

RAID 0은 재생성 과정에서 파일시스템 UUID가 바뀌었으므로 /etc/fstab의 /raid0 UUID도 새 값으로 수정하였다.

blkid /dev/md0
sudo nano /etc/fstab

최종적으로 /raid0 줄은 새 ext4 UUID를 사용하도록 수정하였다.

UUID=b61d3c02-eff1-4b6a-877c-257086af7798 /raid0 ext4 defaults,nofail 0 2

16. mdadm 설정 재저장

RAID 0을 새로 만들었기 때문에 mdadm 배열 정보도 다시 저장하였다.

sudo cp /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak.after-rebuild
sudo sed -i '/^ARRAY/d' /etc/mdadm/mdadm.conf
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

이를 통해 재부팅 후에도 새로 구성한 RAID 0 배열이 자동 조립되도록 하였다.

17. 최종 재부팅 검증

모든 복구 작업을 마친 후 재부팅하여 최종 상태를 확인하였다.

cat /proc/mdstat
df -h | grep raid
lsblk -f

재부팅 후 상태는 다음과 같았다.

md1 : active raid1 vdg1[2] vdc1[0]
      [2/2] [UU]

md0 : active raid0 vdb1[0] vdf1[1]

md5 : active raid5 vdd1[0] vde1[3] vdh1[4]
      [3/3] [UUU]

마운트 상태도 정상적으로 확인되었다.

/dev/md5 /raid5
/dev/md0 /raid0
/dev/md1 /raid1

파일 상태를 확인하였다.

ls /raid0
ls /raid1
ls /raid5

결과는 다음과 같았다.

/raid0 : lost+found
/raid1 : lost+found test.txt
/raid5 : lost+found test.txt

테스트 파일을 읽어보았다.

cat /raid0/test.txt
cat /raid1/test.txt
cat /raid5/test.txt

출력 결과는 다음과 같았다.

cat: /raid0/test.txt: 그런 파일이나 디렉터리가 없습니다
raid1 test
raid5 test

이는 의도한 결과이다. RAID 0은 재생성 과정에서 파일시스템을 다시 만들었으므로 기존 파일이 사라졌다. 반면 RAID 1과 RAID 5는 rebuild를 통해 기존 데이터를 유지하였다.

실제 최종 검증에서도 재부팅 후 RAID 0, RAID 1, RAID 5가 모두 자동 조립 및 자동 마운트되었고, RAID 1과 RAID 5의 테스트 파일은 유지된 반면 RAID 0의 테스트 파일은 존재하지 않았다.

18. 정리

이번 실습을 통해 RAID 레벨별 장애 대응 차이를 직접 확인할 수 있었다.

RAID 0

RAID 0은 스트라이핑 방식으로 여러 디스크에 데이터를 나누어 저장한다. 용량과 성능 측면에서는 장점이 있지만, 디스크 하나가 사라지면 전체 배열을 정상적으로 사용할 수 없다.

이번 실습에서도 RAID 0 디스크 하나를 제거하자 배열은 inactive 상태가 되었고, 기존 파일에 접근할 수 없었다. 이후 새 디스크를 추가해 RAID 0을 다시 생성했지만, 기존 데이터는 복구되지 않았다.

RAID 1

RAID 1은 미러링 방식으로 동일한 데이터를 여러 디스크에 저장한다. 디스크 하나가 제거되어도 남은 디스크만으로 데이터를 읽을 수 있다.

이번 실습에서는 RAID 1 디스크 하나를 제거한 뒤에도 degraded 상태로 배열을 실행할 수 있었고, 기존 test.txt 파일도 정상적으로 읽을 수 있었다. 새 디스크를 추가한 뒤 rebuild를 수행하자 다시 [2/2] [UU] 상태로 복구되었다.

RAID 5

RAID 5는 패리티를 사용해 단일 디스크 장애를 허용한다. 디스크 하나가 제거되어도 남은 디스크와 패리티 정보를 이용해 데이터를 읽을 수 있다.

이번 실습에서는 RAID 5 디스크 하나를 제거한 뒤에도 degraded 상태로 배열을 실행할 수 있었고, 기존 test.txt 파일도 정상적으로 읽을 수 있었다. 새 디스크를 추가한 뒤 rebuild를 수행하자 [3/3] [UUU] 상태로 복구되었다.