작성자 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 호스트가 사용하는 스토리지 레이아웃입니다. 이 방식은 모든 드라이브를 파트너 드라이브에 미러링한 뒤, 해당 미러 쌍들에 데이터를 스트라이핑합니다. 드라이브 하나가 고장 나더라도 어레이는 멈추지 않으며, 복구 작업은 세트 내의 다른 모든 드라이브를 읽어 재계산하는 방식이 아니라 생존한 파트너 드라이브에서 데이터를 그대로 복사하는 방식으로 이루어집니다.
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이라고 표시되는 이유입니다.
The data behind this chart
[
{
"label": "RAID 1 (four mirrored pairs)",
"usable_tb": 4,
"worst_case_drives_lost": 1,
"best_case_drives_lost": 4
},
{
"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
}
]1 TB 드라이브 8개를 사용하면 RAID 5 환경에서는 7 TB의 가용 공간을 얻고, RAID 10 환경에서는 4 TB를 얻습니다. 이 차이는 곧 실제 비용이며, 패리티 방식이 계속 제안되는 이유이기도 합니다. RAID 6은 어떤 패턴으로든 2개의 고장까지 견딥니다. RAID 10은 오직 1개의 고장만을 보장하는데, 이는 이미 고장 난 드라이브의 파트너 드라이브가 고장 나는 위험한 상황이 발생할 수 있기 때문입니다. 고장 난 두 드라이브가 같은 쌍에 속하지 않는 운 좋은 경우에는 최대 4개까지 견딜 수 있지만, 이는 설계적 특성이 아닌 운에 따른 결과입니다.
쓰기 작업 시 레벨별 비용
미러에 대한 쓰기 작업은 두 번의 쓰기로 이루어지며, 두 멤버에 동시에 발행됩니다. 패리티 스트라이프에 대한 쓰기 작업은 더 많은 노력이 필요합니다. 해당 스트라이프의 패리티 블록이 더 이상 유효하지 않게 되어 다시 계산해야 하기 때문입니다.
컨트롤러는 새로운 블록만으로는 패리티를 다시 계산할 수 없습니다. 먼저 이전 데이터 블록과 이전 패리티 블록이 필요합니다. 따라서 RAID 5에서의 작은 무작위 쓰기 한 번은 읽기, 읽기, 쓰기, 쓰기 과정이 됩니다. RAID 6는 유지해야 할 두 번째 신드롬이 있으므로, 같은 쓰기 작업이 읽기, 읽기, 읽기, 쓰기, 쓰기, 쓰기 과정이 됩니다.
The data behind this chart
[
{
"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)",
"write_ops_per_host_write": 2,
"drives_read_to_rebuild": 1
}
]작은 무작위 쓰기 한 번의 비용은 RAID 6에서 6회의 장치 작업이며, RAID 10에서는 2회입니다. 이 수치는 지연 시간의 차이를 충분히 반영하지 못합니다. 두 번의 미러 쓰기는 병렬로 진행되므로, 게스트는 둘 중 더 느린 작업이 끝날 때까지 기다립니다. 패리티 경로에는 새로운 패리티를 계산하기 전에 완료되어야 하는 읽기 작업이 포함되어 있으므로, 게스트는 읽기 작업 후 쓰기 작업을 순차적으로 기다려야 합니다. 부하가 많은 호스트에서는 해당 읽기 작업이 다른 모든 I/O 뒤에서 대기하게 됩니다.
중요한 예외가 있습니다. 스트라이프 전체를 채울 만큼 큰 쓰기 작업은 이전 데이터가 필요하지 않습니다. 스트라이프의 모든 블록이 교체되기 때문입니다. 패리티는 이미 메모리에 있는 데이터로부터 계산되므로, 비용은 추가 쓰기 한 번으로 줄어듭니다. 이것이 바로 RAID 5가 순차 벤치마크에서는 괜찮아 보이지만, 다수의 테넌트로부터 발생하는 작은 쓰기 작업이 혼합된 부하에서는 성능이 저하되는 이유입니다. 실제로 운영할 패턴을 테스트하십시오. VPS 디스크를 올바르게 벤치마킹하는 방법은 하나의 큰 dd이 아니라, 현실적인 큐 깊이에서의 무작위 I/O를 의미합니다.
재빌드가 위험한 이유
패리티 재빌드는 나머지 모든 드라이브를 사용하여 손실된 드라이브를 복구해야 하므로, 첫 번째 블록부터 마지막 블록까지 7개의 살아있는 드라이브를 모두 읽습니다. 반면 RAID 10 재빌드는 1개만 읽습니다. 즉, 죽은 드라이브의 미러 파트너만 읽으면 되며 다른 드라이브는 읽지 않습니다.
이로 인해 두 가지 비용이 발생합니다. 첫째는 시간입니다. 재빌드 속도는 가장 느린 생존 드라이브와 그 위에 수행되는 패리티 연산에 의해 제한되기 때문입니다. 둘째는 부하입니다. 패리티 세트의 모든 드라이브가 재빌드 기간 내내 바쁘게 작동하므로, 해당 노드의 모든 게스트는 작업이 끝날 때까지 더 높은 지연 시간을 경험하게 됩니다. RAID 10에서는 한 쌍만 바쁘게 작동하고 나머지 쌍들은 정상 속도로 서비스를 제공합니다.
같은 기간 동안 데이터 무결성 위험도 존재합니다. 드라이브가 하나 죽은 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는 서로 간의 지역성(locality)이 없는 작은 쓰기 스트림으로 섞여서 들어옵니다. 이는 패리티(parity) 방식의 읽기-수정-쓰기(read-modify-write) 주기가 가장 큰 비용을 발생시키는 패턴이며, 공유 노드에서 하루 종일 발생하는 패턴이기도 합니다.
여기에 재빌드(rebuild) 동작까지 고려하면 선택은 자명해집니다. 패리티 노드에서 드라이브 하나가 고장 나면 해당 박스의 모든 게스트 성능이 몇 시간 동안 저하됩니다. 반면 RAID 10 노드에서 드라이브가 고장 나면 한 쌍의 성능만 저하되며, 복사 작업은 드라이브 속도에 맞춰 순차적으로 진행됩니다. 제공업체는 지연 시간이 급증하지 않는 서비스를 판매해야 하므로, 원시 NVMe 용량의 절반을 미러링에 할당하여 이를 보장합니다.
드라이브 용량이 커지는 추세도 같은 방향을 가리킵니다. 드라이브가 커질수록 재빌드 시간은 길어지며, 패리티 방식에서는 그 시간 동안 모든 성능이 느려지고 보호 기능도 취약해집니다. 가상화를 위한 ZFS 배포 시 넓은 raidz 대신 미러링된 vdev 풀을 사용하는 이유도 같습니다. 미러링 리실버링(resilver)은 실제로 사용 중인 블록만 한 쌍 내에서 복사하기 때문입니다.
물론 이 모든 것이 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는 어레이 장치, 상태, 레벨을 나타냅니다.- 그 뒤에 나오는 이름들은 구성원입니다. 대괄호 안의 숫자는 라인상의 위치나 슬롯 번호가 아니라, 어레이 메타데이터 내의 장치 인덱스입니다.
- 드라이브 교체 후 새 구성원은 보통 기존 슬롯보다 높은 인덱스를 유지하므로,
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은 현재 속도를 기준으로 한 커널의 예상 완료 시간입니다. 이 속도는 /proc/sys/dev/raid/speed_limit_min 및 speed_limit_max에 의해 제한되며, 이러한 제한은 재구축 작업이 실제 운영 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을 선택합니까?
두 가지 이유가 있으며, 모두 작은 단위의 무작위 쓰기 작업과 관련이 있습니다. 패리티 쓰기 방식은 새로운 패리티를 계산하기 전에 기존 데이터와 패리티를 다시 읽어야 하므로, 작은 쓰기 작업 시 RAID 5는 4회, RAID 6는 6회의 작업이 필요하지만, 미러링 방식은 2회면 충분합니다. 또한 패리티 재구축은 모든 생존 드라이브를 처음부터 끝까지 읽어야 하므로 노드 내 모든 게스트의 성능을 수 시간 동안 저하시키지만, RAID 10은 한 드라이브의 내용을 다른 드라이브로 복사하기만 하면 되며 나머지 쌍에는 영향을 주지 않습니다. 제공업체는 전체 NVMe 용량의 절반을 포기하는 대신 이러한 성능 이점을 얻습니다.
/proc/mdstat에서 [U_] 또는 [UU_U]는 무엇을 의미합니까?
각 문자는 어레이 내 슬롯을 순서대로 나타냅니다. U은 해당 슬롯의 구성 요소가 정상 작동 중이며 동기화되었음을 의미합니다. _는 해당 슬롯이 작동하지 않음을 의미합니다. 두 개의 드라이브로 구성된 미러에서 [U_]이 표시되면 두 번째 슬롯이 다운되어 중복성이 사라졌음을 뜻합니다. 앞의 쌍과 함께 읽어야 하며, 예를 들어 [4/3]는 어레이가 4개의 구성 요소를 예상하지만 현재 3개만 있음을 나타냅니다. 슬롯 순서는 장치 이름이 나열된 순서가 아니라 mdadm --detail의 RaidDevice 열 순서와 일치합니다.
RAID 10 어레이에서 최대 몇 개의 드라이브까지 고장을 허용합니까?
어떤 패턴이든 최소 1개는 보장됩니다. 그 이상은 고장이 발생한 위치에 따라 다릅니다. 각 미러 쌍은 구성 요소 중 하나가 고장 나도 버틸 수 있으므로, 8개 드라이브로 구성된 어레이는 고장이 같은 쌍에 겹치지 않는다면 최대 4개까지 버틸 수 있지만, 같은 쌍에 2개가 고장 나면 어레이가 중단됩니다. 보장되는 고장 허용 개수인 1개를 기준으로 계획을 세우고, 그 이상의 생존은 보호 기능이 아닌 운으로 간주해야 합니다.
VPS 내부에서 mdadm으로 두 볼륨을 미러링해야 합니까?
대개는 그렇지 않습니다. 하나의 VPS에 연결된 두 볼륨은 종종 동일한 호스트의 물리적 어레이에 위치합니다. 이 경우 미러링을 해도 쓰기 비용만 두 배가 될 뿐, 호스트의 RAID가 이미 처리하고 있는 문제 외에는 추가적인 보호 효과가 없습니다. 제공업체가 해당 볼륨들이 서로 다른 장애 도메인(failure domain)에 위치한다고 명시한 경우에만 미러링을 고려하십시오. 그렇지 않다면 그 노력을 서버 외부로 데이터를 보내는 백업에 투자하는 것이 좋습니다.