작성자 VPS 스토리지 RAID 10 구성 원리와 특징 완벽 정리
VPS 호스트가 NVMe 환경에서 RAID 10을 선호하는 이유와 RAID 1, 5, 6의 장애 대응 능력을 비교합니다. /proc/mdstat 확인 방법 및 RAID가 백업을 대체할 수 없는 이유를 기술적으로 설명합니다.
RAID 10의 정의와 VPS 호스트가 이를 사용하는 이유
RAID 10은 가상화된 NVMe(non-volatile memory express) 드라이브 환경에서 대부분의 VPS 호스트가 사용하는 스토리지 레이아웃입니다. 일반적인 2개 복사본 레이아웃에서는 모든 드라이브를 파트너 드라이브에 미러링한 뒤, 해당 미러 쌍 전체에 데이터를 스트라이핑합니다. 드라이브 하나가 고장 나더라도 어레이는 멈추지 않으며, 복구 작업은 세트 내의 다른 모든 드라이브를 읽어 계산하는 방식이 아니라 생존한 파트너 드라이브에서 데이터를 그대로 복사하는 방식으로 진행됩니다.
RAID는 독립 디스크의 중복 어레이(redundant array of independent disks)를 의미합니다. RAID의 목적은 단 하나, 디스크가 고장 나거나 교체되는 동안에도 서버가 계속 작동하도록 유지하는 것입니다. 이 목적은 가용성을 위한 것이며, 가용성이 곧 데이터의 안전을 보장하지는 않습니다.
RAID는 쓰기 작업을 복제합니다. rm -rf /srv은 쓰기 작업입니다. 미러의 양쪽 절반 모두에서 동일한 밀리초에 디렉터리가 삭제되더라도, 어레이는 이후에도 정상 상태라고 보고합니다.
이 문장을 기억하십시오. 이 페이지의 나머지 부분에서는 각 RAID 레벨이 어떤 장애를 견딜 수 있는지, 그리고 쓰기 작업마다 어떤 비용이 발생하는지 다룹니다. 마지막 섹션에서는 사용자가 소유한 머신에서 어레이 상태를 읽는 명령어와 RAID가 결코 보장하지 못하는 장애 유형에 대해 설명합니다.
호스팅 구매자가 실제로 접하는 수준: 1, 5, 6, 10
플랜 페이지에는 숫자 하나만 적혀 있습니다. 이 숫자는 두 가지 질문에 답합니다. 드라이브가 몇 개까지 고장 날 수 있는지, 그리고 모든 쓰기 작업에 어떤 비용이 드는지입니다.
RAID 1은 미러링입니다. 두 개의 드라이브가 동일한 블록을 보관합니다. 모든 쓰기 작업은 양쪽 드라이브에 수행됩니다. 읽기 작업은 어느 드라이브에서든 처리할 수 있습니다. 드라이브 하나가 고장 나도 데이터 손실은 없으며, 전체 용량의 절반을 사용할 수 있습니다. 계산할 패리티가 없으므로 쓰기 경로가 짧습니다.
RAID 5는 스트라이프당 하나의 패리티 블록을 사용하는 스트라이핑입니다. n개의 드라이브를 사용하면 n-1개의 용량을 얻게 되며, 어레이는 정확히 하나의 드라이브 고장까지 견딜 수 있습니다. 패리티는 특정 드라이브 하나에 고정되지 않습니다. 모든 드라이브에 걸쳐 순환하므로, 모든 드라이브가 데이터와 패리티를 함께 담고 있습니다.
RAID 6은 각 스트라이프에 두 번째 독립 패리티 블록을 추가하며, 보통 P와 Q로 기록합니다. 이는 동시에 두 개의 드라이브가 고장 나도 데이터를 보존합니다. 두 번째 고장은 대개 첫 번째 고장을 복구하는 도중에 발생하기 때문에, 이는 생각보다 훨씬 중요한 의미를 갖습니다.
RAID 10은 미러의 스트라이프입니다. 드라이브는 쌍으로 미러링되며, 데이터는 이 쌍들에 걸쳐 분산됩니다. 사용 가능한 용량은 RAID 1과 동일한 전체 용량의 절반이며, 여기에 스트라이핑의 병렬성이 더해집니다.
RAID 1+0으로 표기된 경우도 볼 수 있는데, 이는 미러링을 먼저 수행한 뒤 미러들 사이에서 스트라이핑한다는 정직한 설명입니다. RAID 0+1은 그 반대 순서로, 스트라이핑을 먼저 수행한 뒤 두 스트라이프를 미러링합니다. 이는 더 좋지 않은 방식인데, 드라이브 하나만 고장 나도 스트라이프 전체가 서비스에서 제외되며 복구 시 반대편 전체를 복사해야 하기 때문입니다.
Linux는 알아둘 가치가 있는 특별한 경우입니다. 커널의 raid10은 두 계층을 쌓아 올린 것이 아니라 단일한 특성을 가지므로, 홀수 개의 드라이브에서도 실행되며 중첩된 설정으로는 표현할 수 없는 레이아웃(near, far, offset)을 지원합니다. 이것이 Linux 장비의 상태 줄에 두 개의 어레이를 명시하는 대신 2 near-copies라고 표시되는 이유입니다.
이 차트의 데이터
[
{
"label": "RAID 1 (eight copies)",
"usable_tb": 1,
"worst_case_drives_lost": 7,
"best_case_drives_lost": 7
},
{
"label": "RAID 5",
"usable_tb": 7,
"worst_case_drives_lost": 1,
"best_case_drives_lost": 1
},
{
"label": "RAID 6",
"usable_tb": 6,
"worst_case_drives_lost": 2,
"best_case_drives_lost": 2
},
{
"label": "RAID 10",
"usable_tb": 4,
"worst_case_drives_lost": 1,
"best_case_drives_lost": 4
}
]8개의 1 TB 드라이브를 사용할 경우 RAID 5에서는 7 TB의 가용 공간을, RAID 10에서는 4 TB의 가용 공간을 얻습니다. 이 차이는 곧 실제 비용이며, 패리티 방식이 계속해서 제안되는 이유이기도 합니다. RAID 6은 어떤 패턴으로든 2개의 고장까지 견딥니다. RAID 10은 오직 1개까지만 보장하는데, 이는 이미 고장 난 드라이브의 파트너 드라이브에서 발생하는 위험한 두 번째 고장 때문입니다. 고장 난 드라이브들이 서로 같은 쌍에 속하지 않는 운 좋은 경우에는 최대 4개까지 견딜 수 있지만, 이는 설계상의 특성이 아니라 운에 따른 결과입니다.
쓰기 작업 시 레벨별 비용
미러에 대한 쓰기 작업은 두 번의 쓰기로 이루어지며, 두 멤버에 동시에 발행됩니다. 패리티 스트라이프에 대한 쓰기는 더 많은 작업이 필요합니다. 해당 스트라이프의 패리티 블록이 유효하지 않게 되어 다시 계산해야 하기 때문입니다.
읽기-수정-쓰기(read-modify-write) 방식에서 컨트롤러는 먼저 기존 데이터와 기존 패리티를 읽습니다. 캐시되지 않은 단일 블록 덮어쓰기가 RAID 5에서 발생하면 읽기, 읽기, 쓰기, 쓰기 순서로 진행됩니다. RAID 6는 두 개의 패리티 블록을 유지하므로 읽기-수정-쓰기 과정은 읽기, 읽기, 읽기, 쓰기, 쓰기, 쓰기로 늘어납니다. Linux는 변경되지 않은 데이터를 읽어 패리티를 계산하는 재구성-쓰기(reconstruct-write) 방식도 사용합니다. 3개의 드라이브로 구성된 RAID 5에서 해당 덮어쓰기는 1회의 데이터 읽기와 2회의 쓰기가 발생할 수 있으며, 4개의 드라이브로 구성된 RAID 6에서는 1회의 데이터 읽기와 3회의 쓰기가 발생합니다. 4와 6이라는 수치는 읽기-수정-쓰기 횟수이며, 모든 작은 무작위 쓰기에 고정된 비용은 아닙니다.
이 차트의 데이터
[
{
"label": "RAID 1 (2 drives)",
"write_ops_per_host_write": 2,
"drives_read_to_rebuild": 1
},
{
"label": "RAID 5 (8 drives)",
"write_ops_per_host_write": 4,
"drives_read_to_rebuild": 7
},
{
"label": "RAID 6 (8 drives)",
"write_ops_per_host_write": 6,
"drives_read_to_rebuild": 7
},
{
"label": "RAID 10 (8 drives, fixed mirror pairs)",
"write_ops_per_host_write": 2,
"drives_read_to_rebuild": 1
}
]캐시되지 않은 단일 블록 읽기-수정-쓰기 비용은 RAID 6에서 6회의 장치 작업이 발생하며, 동일한 덮어쓰기를 수행하는 2카피 RAID 10에서는 2회가 발생합니다. 이 수치는 지연 시간의 차이를 충분히 반영하지 못합니다. 미러 쓰기 두 번은 병렬로 처리되므로 게스트는 둘 중 더 느린 작업이 끝날 때까지 기다립니다. 반면 읽기-수정-쓰기 경로에는 새로운 패리티를 계산하기 전에 완료되어야 하는 읽기 작업이 포함되어 있으므로, 게스트는 읽기 작업 후 쓰기 작업이 순차적으로 완료되기를 기다려야 합니다. 부하가 많은 호스트에서는 해당 읽기 작업이 다른 모든 I/O 뒤에 대기하게 됩니다.
중요한 예외가 있습니다. 전체 스트라이프를 채울 만큼 큰 쓰기 작업은 기존 데이터가 필요하지 않습니다. 스트라이프의 모든 블록이 교체되기 때문입니다. 패리티는 이미 메모리에 있는 데이터로부터 계산되므로, 오버헤드는 RAID 5의 경우 스트라이프당 1회의 패리티 쓰기, RAID 6의 경우 2회로 줄어들며 사전 읽기(preread) 과정도 없습니다. 이것이 바로 RAID 5가 순차 벤치마크에서는 괜찮아 보이지만, 다수의 테넌트로부터 발생하는 작은 쓰기 작업이 섞인 부하에서는 성능이 저하되는 이유입니다. 실제 운영하는 패턴을 테스트하십시오. VPS 디스크를 올바르게 벤치마킹하는 방법은 하나의 큰 dd이 아니라 현실적인 큐 깊이에서의 무작위 I/O를 의미합니다.
재빌드 과정이 위험한 이유
RAID 5 전체 재빌드는 나머지 모든 드라이브를 사용하여 손실된 드라이브를 복구해야 합니다. 따라서 8개 드라이브 구성 예시에서는 첫 번째 블록부터 마지막 블록까지 7개의 생존 드라이브를 모두 읽어야 합니다. 반면 고정된 2개 복사본 미러 쌍을 사용하는 RAID 10 재빌드는 1개만 읽습니다. 즉, 고장 난 드라이브의 미러 파트너만 읽으면 되며 다른 드라이브는 읽지 않습니다. 다른 Linux RAID10 레이아웃은 복사본을 다르게 분산하므로, 3개 장치 near 레이아웃의 멤버를 재빌드할 때는 생존한 멤버 2개를 모두 읽습니다.
이로 인해 두 가지 비용이 발생합니다. 첫째는 시간입니다. 재빌드 시간은 생존 드라이브의 성능, 복구 작업량, 복구 속도 목표에 따라 제한됩니다. 둘째는 부하입니다. 패리티 재빌드는 I/O를 생존 드라이브 전체에 분산합니다. 고정 미러 쌍을 사용하는 RAID 10 재빌드는 해당 I/O를 특정 쌍에 집중시키지만, 공유 컨트롤러와 호스트 자원은 여전히 다른 쌍에도 영향을 미칩니다.
동일한 시간대에 데이터 무결성 위험도 존재합니다. 드라이브가 하나 고장 난 RAID 5 어레이는 더 이상 중복성이 없으므로, 생존 드라이브의 어느 곳에서든 읽을 수 없는 섹터가 발생하면 복구가 불가능합니다. 재빌드는 1년 동안 아무도 접근하지 않은 섹터를 포함하여 모든 섹터를 읽는 유일한 작업입니다. 공개된 데이터시트 수치에 따르면 일반 소비자용 하드 드라이브는 10^14비트 읽기당 1회, 엔터프라이즈 NVMe 드라이브는 10^17비트 읽기당 1회 이하의 읽기 오류율을 보입니다. 이는 측정값이 아닌 제조사의 사양이지만, RAID 5 재빌드가 실패할 것이라는 과거의 경고가 왜 대용량 회전식 디스크에 대해 작성되었는지, 그리고 왜 NVMe에서는 그 위험이 훨씬 낮은지를 설명해 줍니다. 부하에 관한 논리는 어떤 매체에서든 동일하게 적용됩니다.
재빌드가 발생하기 전에 스크러빙(scrubbing)을 통해 잠재적 오류를 미리 찾으십시오. Debian과 Ubuntu는 md 어레이를 위한 주기적인 스크러빙을 제공하며, 메커니즘은 릴리스마다 다르므로 현재 버전을 확인한 후 수동으로 작업을 실행하십시오.
systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cntsync_action 작업이 완료되면 idle로 돌아가며, mismatch_cnt는 0을 표시해야 합니다. 미러에서 0보다 큰 숫자가 나오면 두 절반의 데이터가 일치하지 않음을 의미합니다. 각 복사본에 체크섬이 없으므로 커널은 어느 쪽이 올바른지 판단할 수 없습니다. 일부 불일치는 무해하며, 주로 스왑 파티션에서 발생합니다. 커널이 페이지를 쓰는 도중에 데이터가 변경될 수 있기 때문입니다. 데이터 어레이에서 불일치 카운트가 증가하면 조사가 필요합니다. 단지 카운트 수치만으로는 교체해야 할 드라이브를 식별할 수 없습니다.
VPS 제공업체가 NVMe에 RAID 10을 표준으로 사용하는 이유
하이퍼바이저 노드는 단 하나의 워크로드만 실행하지 않습니다. 수십 개의 서로 관련 없는 게스트를 실행하며, 이들의 I/O는 서로 연관성 없는 작은 쓰기 작업의 스트림으로 뒤섞여 들어옵니다. 이는 패리티(parity) 기반의 읽기-수정-쓰기(read-modify-write) 주기가 가장 큰 비용을 유발하는 패턴이며, 공유 노드에서 하루 종일 발생하는 패턴이기도 합니다.
재빌드(rebuild) 동작까지 고려하면 선택은 자명해집니다. 패리티 노드에서 드라이브가 하나 실패하면 살아남은 모든 드라이브에 복구 작업 부하가 추가됩니다. 반면 고정된 미러 쌍을 사용하는 RAID 10 노드에서는 드라이브가 실패해도 해당 쌍에만 재빌드 I/O가 추가되며, Linux MD는 다른 작업이 진행 중일 때 복구 속도를 조절합니다. 제공업체는 지연 시간이 급증하지 않는 서비스를 판매해야 하므로, 용량을 희생하여 이를 구매합니다. 즉, 원시 NVMe 용량의 절반을 미러링에 할당하는 것입니다.
드라이브 크기 역시 같은 방향으로 작용합니다. 드라이브가 커질수록 재빌드에 걸리는 시간은 길어집니다. RAID 5의 경우 이 시간 동안 복구 작업으로 부하가 가중되는데, 이때는 중복성이 전혀 남지 않습니다. RAID 6는 드라이브가 하나 더 실패해도 보호 기능을 유지합니다. 가상화 환경에서 ZFS를 배포할 때 광범위한 raidz 대신 미러링된 vdev 풀을 사용하는 이유도 같습니다. 미러 리실버링(resilvering)은 실제로 사용 중인 블록만 복사하며, 특정 쌍 내에서만 수행되기 때문입니다.
물론 이 모든 이유가 RAID 10이 모든 곳에 정답이라는 뜻은 아닙니다. 백업 대상은 긴 순차 쓰기 작업으로 기록되고 읽기는 드물게 발생하므로, RAID 6가 더 나은 선택입니다. RAID 6는 두 개의 드라이브 실패를 견딜 수 있고 더 많은 용량을 확보할 수 있습니다. 중요한 것은 숫자가 아니라 워크로드입니다. 오늘 선택하려는 계획에 있어서는 보통 레이아웃보다 매체 자체가 더 중요하며, SATA SSD에서 NVMe로의 전환이 어떤 RAID 구성 차이보다 더 큰 성능 향상을 가져옵니다.
/proc/mdstat 읽는 법
직접 관리하는 어레이(전용 서버, 가정용 장비, 또는 직접 구성한 볼륨 2개가 연결된 VPS)에서 다음 명령을 실행하십시오. 출력 결과를 직접 확인하십시오. 아래 블록은 사용자의 출력 결과와 형태를 대조할 수 있도록 작성된 예시입니다.
cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS정상적인 4개 드라이브 RAID 10 구성은 이와 유사하게 출력됩니다.
Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>출력의 모든 부분은 정보를 담고 있습니다.
Personalities은 현재 커널에 로드된 md 모듈을 나열합니다.raid10가 표시된다면 해당 코드를 사용할 수 있다는 의미일 뿐, 그 이상은 아닙니다.md0 : active raid10은 어레이 장치, 상태, 그리고 레벨을 나타냅니다.- 그 뒤에 나오는 이름들은 구성원(member)입니다. 대괄호 안의 숫자는 어레이 메타데이터 내의 장치 인덱스이며, 줄에서의 위치나 항상 슬롯 번호를 의미하지는 않습니다.
- 드라이브 교체 후 새 구성원은 보통 기존 슬롯보다 높은 인덱스를 유지하므로,
nvme4n1p3[4]가 슬롯 2에 위치할 수 있습니다.mdadm --detail는RaidDevice열에 실제 슬롯을 출력하므로, 차이가 중요할 때는 이 값을 사용하십시오. - 구성원 뒤의
(F)은 결함을 의미합니다.(S)은 예비(spare)를 의미하며, 현재 유휴 상태로 장애 발생을 대기 중임을 뜻합니다. 3906764800 blocks super 1.2는 1 KiB 블록 단위의 사용 가능한 크기이며, 그 뒤는 메타데이터 형식입니다.512K chunks 2 near-copies은 스트라이프 청크 크기와 RAID 10 레이아웃을 나타내며, 여기서는 각 블록의 복사본 2개를 인접하게 유지합니다.[4/4]은 어레이가 예상하는 구성원 수와 현재 동기화된 구성원 수입니다.[UUUU]는 슬롯 순서대로 슬롯당 한 문자씩 표시합니다.U은 정상 작동 중이며 동기화된 슬롯입니다._는 작동 중인 장치가 없는 슬롯입니다.bitmap:는 쓰기 의도 비트맵(write intent bitmap)입니다. 쓰기가 진행 중이던 영역을 기록하므로, 연결이 끊겼다 복구된 구성원은 전체 드라이브가 아닌 해당 영역만 재동기화합니다.
문제가 발생했을 때 [4/3]과 [UU_U]의 의미
성능이 저하된 어레이는 다음과 같이 보입니다.
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]두 대괄호를 함께 읽으십시오. [4/3]은 4개 슬롯 중 하나가 작동하지 않음을 나타냅니다. [UU_U]은 어느 슬롯인지 알려주는데, 밑줄(_)이 세 번째 문자이고 슬롯은 0부터 번호가 매겨지므로 슬롯 2가 다운된 상태입니다. (F) 플래그는 실패한 드라이브가 여전히 연결되어 있는 동안에만 장치 이름을 표시합니다. 장비에서 드라이브를 제거하면 줄에서 이름은 사라지지만 밑줄은 그대로 남습니다.
어레이는 이 상황에서도 계속 서비스를 제공하며, RAID 10의 경우 거의 최대 속도로 작동하는 경우가 많아 체감상으로는 아무도 문제를 알아차리지 못합니다. 따라서 별도의 알림이 필요합니다.
grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i mdmdadm 패키지는 /etc/mdadm/mdadm.conf에서 MAILADDR을 읽는 모니터 데몬을 설치합니다. 유닛 이름은 릴리스마다 변경되었으므로 추측하지 말고 마지막 명령으로 찾으십시오. --test 실행은 어레이당 즉시 메시지를 하나씩 보냅니다. 실행 후 받은 편지함이 비어 있다면 메일 경로가 깨진 것이며, 따라서 실제로 중요한 메시지도 같은 방식으로 유실되었을 것입니다.
교체 드라이브가 재구축(rebuild) 중일 때는 어레이 아래에 진행률 줄이 나타납니다.
md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
[==>..................] recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/secrecovery은 교체 드라이브로의 재구축입니다. resync는 초기 패스 및 비정상 종료 후 복구를 포함한 일관성 검사입니다. check는 위에서 트리거한 스크럽(scrub) 작업입니다. 괄호 안의 쌍은 장치별 전체 용량 대비 1 KiB 블록 단위의 진행률이며, finish은 현재 속도를 기준으로 커널이 추정한 완료 시간입니다. Linux MD는 /proc/sys/dev/raid/speed_limit_min과 speed_limit_max을 복구 속도 목표로 사용하며, sync_speed_min와 sync_speed_max에서 어레이별로 재정의할 수 있습니다. 기본 최대 목표치는 장치당 200,000 KiB/s입니다. 이 목표치는 복구 작업이 프로덕션 I/O에 양보하도록 설정된 것이며, 엄격한 속도 제한은 아닙니다.
재구축 중의 전체 mdadm --detail
/dev/md0:
Version : 1.2
Creation Time : Tue Mar 10 09:14:22 2026
Raid Level : raid10
Array Size : 3906764800 (3.64 TiB 4.00 TB)
Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Wed Aug 5 11:02:41 2026
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1
Layout : near=2
Chunk Size : 512K
Rebuild Status : 12% complete
Name : storage:0
Events : 4184
Number Major Minor RaidDevice State
0 259 3 0 active sync set-A /dev/nvme0n1p3
1 259 7 1 active sync set-B /dev/nvme1n1p3
4 259 11 2 spare rebuilding /dev/nvme4n1p3
3 259 15 3 active sync set-B /dev/nvme3n1p3Number 열은 /proc/mdstat의 괄호 안에 출력된 메타데이터 인덱스입니다. RaidDevice 열은 [UU_U] 문자열 내의 위치인 슬롯입니다. 여기서는 장치 4가 슬롯 2를 차지하던 드라이브를 대체했기 때문에 두 값이 다릅니다. set-A과 set-B은 각 미러의 두 절반을 나타내므로, 동일한 데이터를 담고 있는 set-A의 구성원과 set-B의 구성원이 같은 쌍에 있다면, 이 두 드라이브를 동시에 잃지 않도록 주의해야 합니다.
직접 관리하는 어레이에서 드라이브를 교체하는 과정은 4개의 명령으로 이루어지며, 마지막 명령은 확인 작업입니다.
sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat복구 줄은 1~2초 내에 나타나야 합니다. 교체 파티션은 mdadm --detail의 Used Dev Size보다 크거나 같아야 하며, 조금이라도 작은 파티션은 not large enough to join array 형태의 메시지와 함께 거부됩니다. 새 드라이브를 추가하기 전에 기존 드라이브와 동일하게 파티션을 나누십시오.
VPS 내부에서 확인할 수 있는 정보와 없는 정보
대부분의 게스트는 호스트의 RAID 구성을 볼 수 없으며, 이는 의도된 설계입니다. 하이퍼바이저는 사용자에게 하나의 가상 디스크를 제공합니다. 해당 디스크가 NVMe 드라이브로 구성된 RAID 10 풀에서 할당되었는지, 아니면 단일 드라이브에 위치하는지는 호스트의 속성이며 게스트 내부에는 표시되지 않습니다.
systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstatsystemd-detect-virt은 KVM 게스트에서 kvm을 출력하며, 컨테이너에서는 lxc와 같은 컨테이너 유형을, 베어메탈에서는 none을 출력합니다. KVM 게스트에서는 일반적으로 lsblk 내에 단일 vda 또는 sda가 보이며, 게스트 내부에는 어레이가 존재하지 않으므로 /proc/mdstat에는 어레이가 나타나지 않습니다.
컨테이너 기반 VPS에서 읽어 들인 정보는 신뢰할 수 없습니다. 컨테이너는 호스트 커널을 공유하며 /proc의 일부는 네임스페이스로 격리되지 않으므로, 그곳에서 읽은 내용은 사용자의 슬라이스가 아닌 호스트의 정보를 설명할 수 있습니다. 해당 정보를 본인의 스토리지에 대한 사실로 간주하지 마십시오. 스토리지 구성이 중요하다면 제공업체에 직접 문의하여 서면으로 답변을 받으십시오.
내부에서 확인할 수 있는 것은 제공받은 디스크의 동작 방식입니다. VPS 디스크가 실제로 NVMe인지 확인하는 방법에서는 실제 정보를 보고하는 명령어를 다루며, SSD VPS에 실제로 포함되는 내용에서는 요금제 페이지의 명칭이 의미하는 바를 다룹니다.
VPS 내부에서 RAID를 구성해야 합니까?
일반적으로는 그렇지 않습니다. 그 이유는 장애 도메인 때문입니다. 한 대의 VPS에 두 개의 볼륨을 연결하고 mdadm로 미러링을 구성하더라도, 두 볼륨은 동일한 물리적 어레이, 동일한 노드, 그리고 동일한 전원 공급 장치 뒤에 위치할 수 있습니다. 이미 갖추고 있는 중복성을 위해 모든 쓰기 작업의 비용을 두 배로 지불하게 되며, 정작 중요한 장애가 발생하면 두 복사본을 모두 잃게 됩니다.
제공업체가 볼륨들이 서로 다른 장애 도메인에 위치한다고 명시하거나, 직접 지정할 수 있는 드라이브가 있는 전용 서버를 사용하는 경우에는 RAID 구성이 가치가 있습니다. 그렇지 않은 경우라면, 해당 장비를 벗어나는 복사본을 만드는 데 노력을 기울이는 것이 더 효과적입니다.
RAID가 보호하지 못하는 것
RAID는 단 하나의 상황, 즉 드라이브가 정상적으로 작동하지 않는 경우만을 대비합니다. 아래에 나열된 모든 작업은 유효한 쓰기 작업으로 간주되므로, 어레이는 이를 모든 복사본에 적용하고 스스로를 정상 상태로 보고합니다.
- 삭제. 잘못된 디렉터리에서
rm -rf를 실행하거나, 경로 변수가 설정되지 않은 배포 스크립트를 실행하는 경우입니다. 어레이는 이를 합법적인 쓰기 작업으로 인식하여 두 번 수행합니다. - 랜섬웨어. 암호화는 쓰기 작업입니다. 정상적인 어레이는 미러의 양쪽 모두에 암호화된 버전을 저장합니다.
- 애플리케이션 오류. 데이터베이스에 잘못된 데이터를 기록하는 버그가 발생하면, 중복 드라이브에도 동일한 잘못된 데이터가 기록됩니다.
- 노드 전체 장애. 호스트가 실패하거나 계정이 실수로 정지된 경우입니다. 어레이는 완벽한 상태일지라도 접근할 수 없게 됩니다.
- 사용자 본인의 실수. 월요일에 삭제한 파일은 월요일에 모든 드라이브에서 사라집니다. 그 이전에 생성된 복사본만이 파일을 복구할 수 있습니다.
동일한 스토리지에 저장된 스냅샷도 해결책이 될 수 없습니다. 스냅샷은 삭제 방지에는 도움이 되지만, 해당 스냅샷이 위치한 어레이가 고장 나면 함께 사라집니다. 백업이 진정한 백업이 되기 위한 조건은 데이터가 다른 곳에 존재해야 한다는 점입니다. restic을 이용한 서버 외부 암호화 백업은 이 페이지의 나머지 절반을 구성합니다. 어레이는 드라이브 고장 시에도 서비스를 지속하게 해주며, restic은 어레이가 정상적으로 수행한 쓰기 작업으로 인해 데이터가 손상되었을 때 이를 복구해 줍니다.
FAQ
RAID 10을 사용하면 백업이 필요 없습니까?
아니요. RAID 10은 드라이브가 작동을 멈추는 상황으로부터 보호합니다. 유효한 모든 쓰기 작업을 미러의 양쪽 절반에 동일하게 적용하므로, 파일 삭제나 랜섬웨어 공격이 발생하면 즉시 중복 드라이브에도 동일하게 반영됩니다. 어레이 관점에서는 아무런 오류가 발생하지 않았으므로 어레이는 정상 상태로 보고됩니다. 따라서 기기 외부로 분리된 백업본이 여전히 필요하며, 백업이 정상적으로 작동하는지 확인하기 위해 주기적으로 복구 테스트를 수행해야 합니다.
VPS 제공업체는 왜 RAID 5나 RAID 6 대신 RAID 10을 선택합니까?
두 가지 이유가 있으며, 모두 작은 크기의 무작위 쓰기 작업과 관련이 있습니다. 캐시되지 않은 단일 블록 읽기-수정-쓰기(read-modify-write) 작업은 새로운 패리티를 계산하기 전에 기존 데이터와 패리티를 읽어야 합니다. 이 과정에서 RAID 5는 4회, RAID 6는 6회의 작업이 발생하지만, 2개 복사본 미러는 2회만 발생합니다. 재구성 쓰기(reconstruct-write)는 변경되지 않은 데이터를 사용하며, 전체 스트라이프 쓰기는 기존 데이터나 패리티를 미리 읽을 필요가 없습니다. RAID 5의 전체 재구축은 모든 생존 드라이브를 처음부터 끝까지 읽어야 하지만, 고정 미러 쌍을 사용하는 일반적인 RAID 10은 생존한 파트너 드라이브에서 데이터를 복사합니다. 다른 Linux RAID10 레이아웃은 여러 소스 멤버를 사용합니다. Linux MD는 다른 작업이 진행 중일 때 복구 속도를 조절합니다. 제공업체는 전체 원시 NVMe 용량의 절반을 포기하는 대가로 이러한 성능을 얻습니다.
/proc/mdstat에서 [U_] 또는 [UU_U]는 무엇을 의미합니까?
각 문자는 어레이 내의 슬롯 하나를 나타내며, 슬롯 순서대로 한 문자씩 대응됩니다. U은 해당 슬롯에 정상적으로 작동하며 동기화된 멤버가 있음을 의미합니다. _은 해당 슬롯에 작동하는 것이 없음을 의미합니다. 2개 드라이브 미러에서 [U_]는 두 번째 슬롯이 다운되어 중복성이 남아있지 않음을 의미합니다. 앞의 쌍과 함께 읽어야 하며, 예를 들어 [4/3]은 어레이가 4개의 멤버를 예상하지만 3개만 있음을 나타냅니다. 슬롯 순서는 장치 이름이 나타나는 순서가 아니라 mdadm --detail의 RaidDevice 열과 일치합니다.
RAID 10 어레이는 드라이브를 몇 개까지 잃을 수 있습니까?
고정 미러 쌍을 사용하는 일반적인 2개 복사본 RAID 10의 경우, 어떤 패턴이든 1개까지 허용됩니다. 그 이상은 장애가 발생하는 위치에 따라 다릅니다. 각 미러 쌍은 멤버 2개 중 1개를 잃을 수 있으므로, 8개 드라이브 어레이는 같은 쌍에 장애가 겹치지 않는다면 최대 4개까지 장애를 견딜 수 있지만, 같은 쌍에 2개의 장애가 발생하면 어레이가 중단됩니다. 보장되는 수치인 1개를 기준으로 계획을 세우고, 그 이상의 생존은 보호가 아닌 운으로 간주하십시오.
VPS 내부의 볼륨 2개를 mdadm으로 미러링해야 합니까?
대개는 그렇지 않습니다. 하나의 VPS에 연결된 2개의 볼륨은 종종 동일한 호스트의 같은 물리적 어레이에 위치합니다. 이 경우 미러링을 하면 모든 쓰기 비용이 두 배로 늘어나며, 호스트의 RAID가 이미 보호하고 있는 것 외에 추가적인 보호 효과는 없습니다. 제공업체가 해당 볼륨들이 서로 다른 장애 도메인에 위치한다고 명시한 경우에만 미러링을 고려할 가치가 있습니다. 그렇지 않다면 해당 노력을 기기 외부로 데이터를 내보내는 백업에 투자하십시오.