데이터 디스크, mdadm RAID1로 구성해야 하나요? LVM RAID1로 구성해야 하나요?
RHEL 환경에서 데이터 디스크를 이중화 하려고 하면 한 번쯤 고민하게 되는 부분이 있습니다.
바로 ‘mdadm RAID1로 구성할지, LVM RAID1을 사용할지’ 인데요, 두 방식 모두 디스크 장애에 대비할 수 있지만 구성 방식과 관리 방법에는 차이가 있습니다.
실제 운영에서는 RAID를 어디에서 관리하느냐에 따라 점검과 복구 절차가 달라집니다.
이번 글에서는 각각의 장단점을 비교하고 RHEL 9 환경에서 LVM RAID1 구성까지 진행해보는 과정을 다루도록 하겠습니다.
RAID, Hardware RAID와 Software RAID
RAID(Redundant Array of Independent Disks)는 여러 디스크를 묶어 RAID 레벨에 따라 장애 허용 능력이나 성능 등을 확보하는 기술입니다.
Hardware RAID는 전용 컨트롤러가, Software RAID는 운영체제의 커널이 RAID를 처리합니다.
mdadm RAID1과 LVM RAID1 모두 Linux Software RAID이며, Hardware RAID와 달리 전용 RAID 컨트롤러 없이 운영이 가능다는 이점이 있습니다.
이 글에서 살펴볼 RAID1은 동일한 데이터를 두 개 이상의 이미지에 복제하는 방식입니다.
RAID0처럼 디스크 장애를 견디지 못하는 레벨도 있으므로 RAID와 이중화를 동일한 의미로 사용하지 않습니다.
장단점, 그래서 뭐가 더 나을까?
mdadm RAID1
장점
1.
mdadm, /proc/mdstat 등 RAID 전용 도구를 사용하여 RAID 구성·확인·복구를 독립적으로 관리할 수 있습니다.
2.
/dev/md* 장치 위에 바로 파일시스템을 만들거나 LVM PV를 올려서 볼륨을 유연하게 나눌 수 있습니다.
3.
운영 경험과 자료가 풍부하며, 부팅 영역의 소프트웨어 RAID 구성에도 활용됩니다. 단, 부팅 가능 여부는 GRUB/UEFI 및 메타데이터 구성에 따라 검증이 필요합니다.
단점
1.
Two-Layer 복잡성: mdadm → LVM 순서로 구성한 경우 RAID와 LV를 각각 관리해야 하기에 오버헤드가 발생할 수 있어요. 다만 mdadm 위에 파일시스템을 직접 만들면 이 단점은 해당하지 않아요.
2.
번거로운 리사이징: mdadm → LVM 구조에서 용량 확장을 하려면 md 어레이 확장 → LVM PV 크기 조정 → VG 크기 조정 → LV 크기 조정 등을 적절한 순서로 처리해야 합니다.
3.
고정된 레이아웃: 전체 파티션/디스크가 통째로 PV에 미러링되기 때문에 특정 볼륨만 콕 집어 미러링할 수 없습니다.
LVM RAID1
장점
1.
명령·관리 체계의 통일: RAID 상태를 lvm 계열 명령으로 PV·VG·LV를 조회·관리할 수 있습니다. /etc/mdadm.conf 파일을 구성하거나 mdadm 관련 서비스를 모니터링할 필요가 없습니다.
2.
원활한 온라인 리사이징: 여유 공간과 적절한 PV 배치가 확보되어 있으면 lvextend 명령어로 논리 볼륨과 기본 RAID1 미러의 크기를 실시간으로 동적 조정할 수 있습니다.
3.
LVM 기능과 연계: LVM RAID 볼륨은 공식적으로 스냅샷을 지원합니다. 캐시·씬 프로비저닝 등의 조합은 기능별 제약과 지원 범위를 별도로 확인해야 하며, 모든 조합이 무조건 호환되는 것은 아닙니다.
단점
1.
/boot나 UEFI ESP 등 부팅 관련 영역을 구성하기에는 부트로더·펌웨어 조건이 개입하므로 다소 까다로울 수 있습니다.
2.
LVM RAID LV는 클러스터 RAID가 아니기에 여러 노드에서 동시에 활성화하는 공유 디스크 용도로 사용해서는 안됩니다.
한 눈에 비교해보기
비교 항목 | mdadm RAID1 | LVM RAID1 |
주요 관리 명령어 | mdadm, /proc/mdstat | lvs, lvconvert, lvchange |
보호 단위 | md RAID 어레이 단위 | LVM 논리 볼륨(LV) |
LVM과의 관계 | 단독 사용 또는 md 위에 LVM 구성 | LVM이 RAID LV를 생성·관리 |
장애 복구 | mdadm 멤버 교체 및 재동기화 | 대체 PV 확보 후 lvconvert --repair |
용량 확장 | md 크기 조정 후 상위 계층 반영 | 여유 PV를 확보한 뒤 LV와 파일시스템 확장 |
권장 상황 | 독립적 RAID 운영, 기존 mdadm 표준, 부팅 설계 검토 | 여러 LV의 관리, LVM 중심 데이터 볼륨 운영 |
RHEL 9에서 LVM RAID1를 구성해보자!
지금까지 두 방식의 장단점을 비교해보았고 이제 RHEL 9 환경에서 LVM RAID1(Mirror)를 직접 구성해보는 시간을 가지도록 하겠습니다.
실습 환경: RHEL 9.6 VM, 미러에 사용할 10GB 디스크 2개(/dev/vdb, /dev/vdc)
구성 순서: 디스크 확인 → PV 생성 → VG 생성 → RAID1 LV 생성 → 동기화 확인 → Filesystem 생성 및 마운트
1. 구성 전 상태 조회
RAID1 구성에는 최소 2개의 디스크가 필요합니다. 아래 lsblk 출력에서 /dev/vdb와 /dev/vdc를 확인할 수 있습니다.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 30G 0 rom
vda 252:0 0 50G 0 disk
├─vda1 252:1 0 600M 0 part /boot/efi
├─vda2 252:2 0 1G 0 part /boot
└─vda3 252:3 0 48.4G 0 part
├─rhel-root 253:0 0 25.4G 0 lvm /
├─rhel-swaplv 253:1 0 8G 0 lvm [SWAP]
└─rhel-crashlv 253:2 0 15G 0 lvm /var/crash
vdb 252:16 0 10G 0 disk
vdc 252:32 0 10G 0 disk
vdd 252:48 0 1M 0 disk
Plain Text
복사
참고: lsblk 출력에 크기가 1M인 /dev/vdd가 확인되지만 해당 디스크는 RAID1 대상이 아니라는 점 참고 해주세요.
2. Mirror LVM 생성
LVM은 PV → VG → LV 순서로 생성하며, 여기서 눈여겨봐야 할 부분은 LV 생성 부분입니다.
lvcreate --type raid1 -m 1을 사용하면 데이터 복제본 두 개를 갖는 RAID1 LV가 생성됩니다. 두 복제본이 서로 다른 PV에 배치되었는지는 생성 후 확인하겠습니다.
$ pvcreate /dev/vdb /dev/vdc
Physical volume "/dev/vdb" successfully created.
Physical volume "/dev/vdc" successfully created.
$ vgcreate mirror_vg /dev/vdb /dev/vdc
Volume group "mirror_vg" successfully created
$ lvcreate --type raid1 -m 1 -l 100%FREE -n mirror_lv mirror_vg
Logical volume "mirror_lv" created.
Plain Text
복사
옵션 이해하기
--type raid1: 기존 LVM mirror 세그먼트가 아닌 MD 기반 LVM RAID1을 생성합니다.
-m 1: 원본 외에 미러 이미지 1개 추가(총 2개 복제본). -m 2면 복제본이 총 3개입니다.
-l 100%FREE: VG의 사용 가능한 논리적 범위를 기준으로 가능한 공간을 전체 할당합니다. 복제본과 RAID 메타데이터가 차지하는 공간도 고려되므로 실제 사용 가능한 용량은 디스크 용량의 합보다 작습니다.
-n mirror_lv mirror_vg: LV 이름과 VG 이름을 지정합니다.
※ 운영 환경에서는 미러 이미지별 용량과 장애 복구용 PV 확보 여부를 함께 계획하세요.
3. LVM 확인
정상적으로 PV, VG, LV가 생성되었다면 아래와 같이 확인됩니다.
lvs 결과에서 Cpy%Sync가 92.18로 출력된 것이 보이는데 이는 현재 초기 동기화가 진행 중이라는 의미입니다.
이 값이 100.00이 될 때까지 잠시 기다려줍니다.
$ pvs
PV VG Fmt Attr PSize PFree
/dev/vda3 rhel lvm2 a-- 48.41g 0
/dev/vdb mirror_vg lvm2 a-- <10.00g 0
/dev/vdc mirror_vg lvm2 a-- <10.00g 0
$ vgs
VG #PV #LV #SN Attr VSize VFree
mirror_vg 2 1 0 wz--n- 19.99g 0
rhel 1 3 0 wz--n- 48.41g 0
$ lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
mirror_lv mirror_vg rwi-a-r--- 9.99g 92.18
crashlv rhel -wi-ao---- 15.00g
root rhel -wi-ao---- 25.41g
swaplv rhel -wi-ao---- 8.00g
Plain Text
복사
동기화가 완료되면 아래와 같이 Cpy%Sync가 100.00으로 표시됩니다.
참고로 Cpy%Sync=100은 초기 동기화가 끝난 상태라는 의미이며, 백업이 완료됐다거나 모든 장애로부터 안전하다는 뜻은 아닙니다.
$ lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
mirror_lv mirror_vg rwi-aor--- 9.99g 100.00
crashlv rhel -wi-ao---- 15.00g
root rhel -wi-ao---- 25.41g
swaplv rhel -wi-ao---- 8.00g
Plain Text
복사
lvs 상세 결과에 _rimage_0, _rimage_1(데이터)과 _rmeta_0, _rmeta_1(메타데이터) 서브 LV가 생성되어 있습니다.
Devices 열을 통해 각 서브 LV가 어느 디스크에 놓였는지도 알 수 있습니다.
데이터 이미지인 rimage_0은 /dev/vdb, rimage_1은 /dev/vdc에 각각 배치되어 있는 것을 확인할 수 있습니다.
두 복제본이 서로 다른 디스크에 배치됐는지 확인하는 것이 중요합니다.
서로 다른 PV이더라도 동일한 물리 장치·스토리지에 있다면 공통 장애 위험이 있습니다.
$ lvs --all --options name,copy_percent,devices mirror_vg
LV Cpy%Sync Devices
mirror_lv 100.00 mirror_lv_rimage_0(0),mirror_lv_rimage_1(0)
[mirror_lv_rimage_0] /dev/vdb(1)
[mirror_lv_rimage_1] /dev/vdc(1)
[mirror_lv_rmeta_0] /dev/vdb(0)
[mirror_lv_rmeta_1] /dev/vdc(0)
Plain Text
복사
4. XFS 파일시스템 포맷
생성한 LV를 XFS 파일시스템으로 포맷하겠습니다.
$ mkfs.xfs /dev/mirror_vg/mirror_lv
meta-data=/dev/mirror_vg/mirror_lv isize=512 agcount=4, agsize=654848 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=2619392, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Discarding blocks...Done.
JavaScript
복사
5. mount 테스트
실습용 디렉토리를 생성한 후 마운트가 정상적으로 되는지 확인하면 LVM RAID1 구성은 끝입니다.
$ mkdir mirror_dir
$ mount /dev/mirror_vg/mirror_lv mirror_dir/
$ df -Th | grep mirror
/dev/mapper/mirror_vg-mirror_lv xfs 10G 104M 9.9G
2% /root/mirror_dir
Plain Text
복사
기본 구성 자체는 어렵지 않지만 운영 환경에서는 하단의 확인 사항까지 준비해야 안심하고 사용할 수 있습니다.
운영 환경에서의 확인사항
1. PV 생성 전, 디스크 상태는 확인 필수!
RAID 작업을 진행하기 전 아래와 같은 명령어를 통해 기존 파티션, 파일시스템, RAID/LVM 메타데이터가 있는지 먼저 확인합니다.
$ lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
$ pvs -o pv_name,vg_name,pv_size,pv_free
$ blkid /dev/vd[b,c]
$ wipefs -n /dev/vd[b,c]
$ ls -l /dev/disk/by-id/
Plain Text
복사
주의: pvcreate, mkfs.xfs, mdadm --create는 대상 장치의 기존 메타데이터·데이터에 영향을 줄 수 있으므로 해당 명령은 반드시 빈 디스크에서만 실행하시기 바랍니다.
2. 디스크 한 개가 실제로 고장났다면?
RAID1 복구에는 새로운 디스크 또는 충분한 여유 공간이 있는 PV가 필요합니다.
아래는 vdd라는 임의의 신규 디스크를 사용하여 복구한 방식이며 실제 환경에서는 장치 이름이 상이할 수 있습니다.
1) fault 발생한 디스크 파악: 읽기 전용 조회
$ lvs --all --options name,copy_percent,devices mirror_vg
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: VG mirror_vg is missing PV 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW (last written to /dev/vde).
LV Cpy%Sync Devices
mirror_lv 100.00 mirror_lv_rimage_0(0),mirror_lv_rimage_1(0)
[mirror_lv_rimage_0] /dev/vdb(1)
[mirror_lv_rimage_1] [unknown](1)
[mirror_lv_rmeta_0] /dev/vdb(0)
[mirror_lv_rmeta_1] [unknown](0)
2) fault 발생 디스크 교체(새로운 디스크가 vdd인 예시)
$ pvcreate /dev/vdd
$ vgextend mirror_vg /dev/vdd
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: VG mirror_vg is missing PV 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW (last written to /dev/vde).
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Volume group "mirror_vg" successfully extended
3) 새 PV로 고장 난 RAID 이미지를 교체하고 재동기화
$ lvconvert --repair mirror_vg/mirror_lv /dev/vdd
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: VG mirror_vg is missing PV 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW (last written to [unknown]).
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Attempt to replace failed RAID images (requires full device resync)? [y/n]: y
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Faulty devices in mirror_vg/mirror_lv successfully replaced.
4) VG 내 실패 장치 제거
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
WARNING: VG mirror_vg is missing PV 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW (last written to [unknown]).
WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Wrote out consistent volume group mirror_vg.
5) 정상 복구 여부 확인
$ pvscan
PV /dev/vda3 VG rhel lvm2 [48.41 GiB / 0 free]
PV /dev/vdb VG mirror_vg lvm2 [<10.00 GiB / 0 free]
PV /dev/vdd VG mirror_vg lvm2 [<10.00 GiB / 0 free]
Total: 3 [68.40 GiB] / in use: 3 [68.40 GiB] / in no VG: 0 [0 ]
$ lvs --all --options name,copy_percent,devices mirror_vg
LV Cpy%Sync Devices
mirror_lv 100.00 mirror_lv_rimage_0(0),mirror_lv_rimage_1(0)
[mirror_lv_rimage_0] /dev/vdb(1)
[mirror_lv_rimage_1] /dev/vdd(1)
[mirror_lv_rmeta_0] /dev/vdb(0)
[mirror_lv_rmeta_1] /dev/vdd(0)
Plain Text
복사
3. 용량 확장과 백업은 별개
LVM RAID1 LV를 확장하려면 각 복제본을 배치할 충분한 물리 공간이 있어야 합니다.
LV 확장 후에는 마운트된 XFS 파일시스템을 xfs_growfs /srv/data로 확장합니다. 참고로 XFS는 축소를 지원하지 않습니다.
RAID1은 디스크 장애에 대응하는 기술이므로 백업과는 목적이 다릅니다.
실수로 삭제한 파일, 랜섬웨어, 파일시스템 손상, 동일 스토리지 장애, 서버 전체 손실은 미러링만으로 대응이 어렵기에 별도의 백업·복원 테스트가 함께 준비되어야 합니다.
마무리하며
이번 비교에서 중요한 차이는 RAID를 독립적인 어레이로 운영할지, LVM 논리 볼륨 단위로 관리할지 입니다.
두 방법 모두 RHEL 9에서 활용할 수 있으며 운영 절차와 기존 구성에 따라 선택이 달라집니다.
이 글의 실습 조건처럼 새 데이터 디스크를 LVM 중심으로 관리한다면 LVM RAID1을 우선 검토하겠습니다.
LV 단위로 RAID를 설계하고 상태를 LVM 명령어로 관리하기 편리하기 때문입니다.
반면 이미 mdadm 중심으로 표준화되어 있거나 RAID 어레이를 LVM과 독립적으로 다뤄야 한다면 mdadm RAID1이 자연스러운 선택입니다.
어느 방법이든 실무 적용 전에는 디스크의 물리적 독립성, 장애 감시, 백업, 교체·재동기화 절차를 확인해야 합니다. /boot와 UEFI ESP 등 부팅 영역은 별도의 복원성 검증이 필요합니다.
이상으로 RHEL 9의 mdadm RAID1과 LVM RAID1 비교를 마치겠습니다.
FAQ
Q1. RAID1만 지원하나요?
아니요. mdadm과 LVM RAID는 RAID 0, 1, 4, 5, 6, 10을 지원합니다. 다만 'Mirror'는 RAID1을 뜻하므로 다른 RAID 레벨까지 모두 Mirror라고 부르지는 않습니다. 이 글은 RAID1에 대해서만 다루었습니다.
Q2. mdadm 위에 LVM을 올려도 되나요?
가능합니다. Red Hat의 RHEL 9 스토리지 관리 문서 18.12에도 소프트웨어 RAID 위에 VG를 구성하는 방법이 나옵니다. RAID1은 mdadm이 관리하고 볼륨은 LVM으로 나눌 수 있습니다. 다만 장애 분석은 md 어레이부터 PV·VG·LV까지 단계 별로 확인해야 합니다.
Q3. 기존 mdadm 구성을 LVM RAID로 바꿀 수 있나요?
RHEL 9 공식 문서에 mdadm 어레이를 LVM RAID1로 직접 변환하는 일반적인 절차는 제시되어 있지 않습니다. mdadm에서 전환한다면 백업 후 새 LVM RAID1을 만들고 데이터를 이관하는 방법을 검토하세요.
Q4. 디스크 장애는 어떻게 알림 받나요?
LVM RAID 장애 이벤트는 dmeventd가 /var/log/messages 로그에 경고를 남기기 때문에 별도의 로그 모니터링 도구나 알림 연동을 붙여주는 게 좋습니다.
아래는 디스크 장애 시 발생하는 로그 발췌입니다. 커널 메시지는 /dev/vdc를 가리키지만 LVM 경고에는 last written to /dev/vde가 함께 나타납니다. 이 문구는 누락 PV의 과거 기록 장치명일 수 있으므로 현재 고장난 장치가 vde라는 뜻으로 바로 해석해서는 안 됩니다.
Oct 13 11:27:49 rhel96 kernel: kworker/0:5: attempt to access beyond end of device#012vdc: rw=169985, sector=2056, nr_sectors = 2 limit=0
Oct 13 11:27:49 rhel96 kernel: md: super_written gets error=-5
Oct 13 11:27:49 rhel96 kernel: md/raid1:mdX: Disk failure on dm-6, disabling device.#012md/raid1:mdX: Operation continuing on 1 devices.
Oct 13 11:27:49 rhel96 dmeventd[713]: WARNING: Device #1 of raid1 array, mirror_vg-mirror_lv, has failed.
Oct 13 11:27:49 rhel96 dmeventd[713]: WARNING: waiting for resynchronization to finish before initiating repair on RAID device mirror_vg-mirror_lv.
Oct 13 11:27:49 rhel96 dmeventd[713]: WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Oct 13 11:27:49 rhel96 dmeventd[713]: WARNING: VG mirror_vg is missing PV 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW (last written to /dev/vde).
Oct 13 11:27:49 rhel96 dmeventd[713]: WARNING: Couldn't find device with uuid 2HG44b-vknk-84iI-cP4e-UC4A-plmc-LuQXcW.
Oct 13 11:27:49 rhel96 dmeventd[713]: Use 'lvconvert --repair mirror_vg/mirror_lv' to replace failed device.
Plain Text
복사
참고 자료
김현진 프로
Red Hat 기술지원 및 DRBD 업무를 담당하고 있어요 