로딩로딩중

RAID

최근 수정 시각:

분류

파일:나무위키+유도.png   이 문서는 컴퓨터에 사용되는 기술에 대해 설명합니다. 동명의 BMS에 대한 내용은 Raid 문서를, 다른 동명어에 대한 내용은 레이드 문서를 참조하십시오.

파일:hdtach-read.gif파일:hdtach-write.gif
단일 파티션 및 여러가지 RAID의 벤치마크.(출처)

1. 정의2. 구현 방법
2.1. 하드웨어 RAID2.2. 펌웨어(드라이버) RAID2.3. 소프트웨어 RAID
3. 종류
3.1. RAID 03.2. RAID 13.3. RAID 1E3.4. RAID 2, 3, 43.5. RAID 53.6. RAID 63.7. RAID-Z33.8. 그 외의 RAID Level
3.8.1. JBOD3.8.2. Nested RAID
3.9. 그 외의 RAID 용어
3.9.1. SHR3.9.2. Hot Spare
4. 개인 환경에서의 사용

1. 정의[편집]

Redundant Array of Inexpensive/Independent Disk
저장장치 여러 개를 묶어 고용량·고성능 저장 장치 한 개와 같은 효과를 얻기 위해 개발된 기법이다.

초기에는 업그레이드 후 '폐기하기엔 아깝고, 그렇다고 단독으로 쓰기에는 성능이 부족한'(Inexpensive) 저장장치를 재활용할 목적으로 사용하였다. 저장장치 기술이 발전한 현재는 Inexpensive보다는 Independent로 해석하는 추세.

RAID의 주 사용 목적은 크게 무정지 구현(안정성)과 고성능 구현으로 구분된다. 무정지 구현을 극도로 추구하면 RAID 1, 고성능 구현을 극도로 추구하면 RAID 0이 되며, RAID 5, 6은 둘 사이에서 적당히 타협한 형태. RAID 10이나 RAID 01과 같이 두 가지 방식을 혼용하는 경우도 있다.

RAID의 존재 의의는 데이터의 안정성과 성능 향상에 있지 절대 데이터 백업의 용도로 사용되는 기술은 아니다. 예로, RAID 서버에 바이러스가 침투하면 RAID를 구성하고 있는 모든 디스크가 동시에 다 같이 감염된다. 랜섬웨어 역시 마찬가지. 초대형 서버의 경우에도 RAID 외에 별도로 미러링 서버나 자기 테이프 등 별도의 데이터 백업 솔루션을 마련해 둔다. 데이터 백업의 용도로 RAID를 염두해 두고 있는 사람이 있다면 다른 대책을 고려하자.

보통은 같은 모델 같은 주차의 제품으로 하는 것이 권장되지만, 이를 유지하기 힘든 개인용의 경우 어쩔 수 없이 서로 다른 두 모델을 혼용할 수밖에 없는 상황이 있다. 물론 그렇다고 RAID가 안 되는 것은 아니며 HDD+SSD 같이 이상하게 구성하지 않는 이상은 성능 향상도 확실히 있다. 다만 SLI처럼 성능이 낮은 쪽으로 하향 평준화되어 거기에 배수가 곱해진다는 것이 차이점.

RAID 1의 경우 RAID를 구성 할 시 동일모델, 서로 다른 주차의 제품으로 구성하는것을 추천하기도 하는데, RAID 1의 특성상 구성되어 있는 하드디스크들이 모두 동일하게 움직이기 때문에 그런 말이 생긴것이다.
만일 동일 모델 + 비슷한 시기에 생산된 제품으로만 RAID 1이 구성되어 있을 시 구성하고 있는 모든 하드디스크가 사이좋게 다같이 죽어버리는 대형 참사가 일어날 확률도 높아지는데, 동일한 생산라인에서 비슷한 시기에 생산된 제품이라면 동일 환경하의 불량률 역시 비슷하기 때문.

2. 구현 방법[편집]

아래로 갈수록 성능과 안정성이 떨어지는 편이다.

2.1. 하드웨어 RAID[편집]

별도의 RAID 카드를 장착하여 구현하는 방법이다. 속도와 안정성 모두 최고급이나 별도의 RAID 카드가 필요하다는 게 단점이다. 고가의 서버 메인보드나 완제품에는 RAID 컨트롤러가 온보드 되어 있는 경우도 있기는 한데, RAID 카드 그 자체가 고장 나는 경우도 있기 때문에 보통은 PCIe 슬롯에 따로 장착한다. 하지만 저가나 염가형의 경우엔 저가 컨트롤러를 쓰거나 기판에 솔더링 흔적만 남은 채로 휑한 경우도 있다. 이런 건 하드웨어 RAID가 아니라 드라이버 RAID이다(...).

보통 10만원 이하의 저렴한 카드들에는 당연히 카드 자체에 RAID를 구성하는 디스크를 컨트롤하기 위한 별도의 작은 CPU/메모리가 없으므로 소프트웨어 레이드와 유의미한 차이는 없다. 그래서 이런 카드들은 FakeRAID 카드라고도 불린다.

최고급 사양은 주로 아답텍, 브로드컴(구 LSI, Avago, 3ware), HP Smart Array, 중고급형엔 하이포인트, 저가형은 프로미스나 SIS, ULi 같이 제조사 별 가격과 성능 차가 크다. 브로드컴의 RAID 컨트롤러는 레퍼런스 디자인을 직접 파는 것도 있지만, 인텔, 델, 레노버 등 다른 서버 제조사에 OEM으로 납품하는 경우도 있다.

2.2. 펌웨어(드라이버) RAID[편집]

파일:RAID_IRST.png
(인텔의 드라이브 관리 펌웨어인 Intel Rapid Storage Technology로 펌웨어 RAID를 구성한 모습.)
값비싼 RAID 카드 대신 기능을 간략화한 RAID 칩을 탑재하고 펌웨어(드라이버)로 제어하여 구현하는 방법이다. 메인보드 RAID라고도 하며, 보통 OS 진입 전 BIOS(UEFI) 메뉴에서 RAID를 구현한다. OS에 관계 없이 작동하며, OS에서는 원래 장착한 디스크 대신 가상의 BIOS(UEFI) RAID 하드웨어가 표시된다.(즉, 별도의 드라이버 소프트웨어를 통한 관리가 불가능하다.) 단, OS를 바꿔도 묶어놓았던 레이드가 계속 유효한 대신에 메인보드를 바꾸게 되면(예를 들어 인텔 보드에서 AMD 보드로) 그 레이드는 더 이상 사용하지 못할 가능성이 크다.

원래 디스크를 가상 디스크가 대체하는 방식이다 보니, 용량이 다른 두 하드웨어를 묶었을 때 남는 공간은 활용을 못 하고 버려지는 단점이 있다. 예를 들어 256GB+512GB로 구성했을 때 512GB(^2) 디스크와 256GB 디스크가 구성되는 것이 아닌, 512GB(^2) 디스크만 구성되고 256GB는 사용할 수 없다. 단, SSD를 RAID할 때에는 여유 공간을 확보하여 성능에 도움이 될 수도 있다.(오버 프로비저닝)

전통적으로는 별도의 RAID 컨트롤러를 사용하는 것이 안정성이 좋고 유지보수 등에 있어서 간편한 것으로 알려져 있으나, 최근의 메인보드 내장 RAID 컨트롤러 또한 상당한 성능을 보여 주고 있다. 인텔의 경우 Intel Rapid Storage Technology라고 부르는 그것. 많이 나아지긴 했지만, 내장 컨트롤러라는 한계가 있어 여러 디스크를 RAID 0으로 묶을 경우 제 성능을 못 내는 경우도 있다. 안정성 면에서도 별도의 RAID 컨트롤러에 비해 부실하기 때문에 RAID 1을 제외하면 RAID Array가 깨졌을 시 데이터 복구는 포기하는 게 편하니 주의하도록 하자.

2.3. 소프트웨어 RAID[편집]

파일:RAID_Windows.png
(Windows의 디스크 관리 기능으로 RAID0을 구성한 모습.)
OS RAID라고도 한다. OS의 디스크 관리 메뉴에서 RAID를 구현하는 방법이다. Windows의 경우에는 부팅 디스크를 OS RAID로 설정할 수 없다. OS RAID는 메인보드를 바꾸더라도 해당 디스크만 제대로 꼽아주면 계속 레이드를 사용할 수 있지만, OS를 바꾸면 (예를 들어 윈도우->리눅스) 보통 사용하지 못한다. Windows의 경우 해당 RAID를 구성한 디스크가 모두 장착되어 있다는 전제 하에 새 OS 설치 이후에도 디스크 가져오기 옵션을 통해 RAID 구성을 그대로 가져올 수 있다. OS에서 관리하므로 다양한 방법으로 RAID를 구성할 수 있으며, 특히 용량이 다른 두 제품의 경우 RAID를 구성하고 남는 공간에 단일 파티션, 또는 또 다른 RAID 어레이를 구성할 수도 있다.

보통 하드웨어를 바꾸는 경우가 OS를 바꾸는 경우보다 더 빈번하기도 하고, OS를 바꾸면 어차피 제공되는 파일 시스템 자체가 달라지기 때문에 기존 레이드를 인식하건 말건 간에 어차피 새로 포맷을 해줘야 하고, 포맷을 할 거면 그냥 다시 레이드를 묶으면 된다. 물론, 예를 들어 윈도의 NTFS 파일 시스템을 리눅스에서 읽고쓰고 하는 게 되긴 하지만, 안정성 문제로 장기간 저렇게 사용하는 것은 보통 추천되지 않는다. 파일시스템은 언제나 해당 OS 에서 네이티브로 잘 지원되는 것을 사용하는 게 안전하다. 따라서, 호환성 측면에서는 메인보드 레이드보다는 OS 레이드가 좀 더 좋다.

3. 종류[편집]

동작 방식에 따라 Level 0 ~ 6으로 분류한다. 주로 사용되는 것은 0, 1, 5, 6이며 컨트롤러 개발사에 따라 다른 방식을 제공하기도 한다.

3.1. RAID 0[편집]

Striping.

여러 개의 멤버 하드디스크를 병렬로 배치하여 거대한 하나의 디스크처럼 사용한다. 데이터 입출력이 각 멤버 디스크에 공평하게 분배되며, 디스크의 수가 N개라면 입출력 속도 및 저장 공간은 이론상 N배가 된다. 다만 멤버 디스크 중 하나만 손상 또는 분실되어도 전체 데이터가 파손되며, 오류검출 기능이 없어 멤버 디스크를 늘릴수록 안정성이 떨어지는 문제가 있다.

이미지 프로세싱, 데이터베이스 캐시 등 빠른 입출력 성능을 필요로 하며, 데이터 손실이 문제되지 않는 환경에서 쓰일 수 있지만, 상용 환경에서는 위험성 문제로 RAID 5나 6을 이용하는 경우가 많다고 한다.

이 때문에 고성능을 경험하고 싶은 파워유저가 구축해 보는 경우가 많다. SSD를 단독 사용하기에는 용량이 많이 부족하니, 여러 개를 묶어서 초고속 저장 장치를 구축하는 것. 이런 점을 간파하고 노트북 제조 업체에서 공식적으로 RAID0 기술을 구현한 최초의 사례로는 소니의 노트북 브랜드인 VAIO이다. VGN-Z 라인업의 고급형 모델에 한시적으로 탑재한 적이 있었으며, 이 라인업의 후속작인 프리미엄 모델 Z 시리즈 VPCZ1부터 본격적으로 적용했다. 소니는 자사의 프리미엄 노트북 라인업에 SSD를 RAID 0으로 묶어서 탑재할 계획이 있었다. 소니의 2011년 신모델로 나온 바이오 SB 시리즈의 고급형 모델의 경우 128GB SSD 두 개를 RAID0로 묶어서 256GB의 용량을 가진다.하지만 소니는 2014년 현재 노트북 사업부를 매각했다(...)



VAIO Z 시리즈의 홍보 영상에서 RAID 0(0^4) SSD와 5400rpm 2.5인치 하드디스크를 비교 대상으로 놓고 1GB 용량의 파일을 복사하는데 걸리는 시간을 측정하는 장면이 있다. RAID 0 SSD는 1GB 파일을 복사하는데 걸리는 시간이 겨우 4초에 불과할 정도로 엄청난 속도다. 사실 VAIO Z에 장착된 SSD의 경우 일반적인 공식 SSD 규격이 아닌 소니의 자체적인 소형화 규격으로 재설계 하였기 때문에 그 비좁은 메인보드 공간 안에 탑재 될 수 있었던 것이다. 바이오 Z(VPCZ1)는 13인치급 노트북이지만 배터리 포함 무게는 1.4kg 정도로 넷북과 맞먹는 수준이며, ODD까지 내장하고 있어서 실제 메인보드가 장착되는 면적은 본체 면적의 절반 정도에 불과하다.... 흠좀무 국내에서 판매되었던 VPCZ1의 일반형 모델은 용량이 128GB로 64GB SSD 두 개를 RAID0로 묶은 것이며, 고급형 모델의 경우 용량이 256GB로 64GB SSD 4개를 RAID0로 묶은 형태다. 게다가 일본 내수용 주문 제작 방식인 오너메이드 모델의 경우 RAID 0로 128GB SSD 4개를 묶은 512GB 용량과, 256GB SSD 4개를 묶은 1TB 용량까지도 선택이 가능했다. 물론 이들을 선택하면 견적이 어마어마하기에 이를 선택하는 사람은 실제로 얼마나 될 지 의문이지만...

삼성의 SSD 24개를 한 개의 볼륨으로 묶기 같은 것도 할 수 있으며, 2.0GB/s(MB가 아니다!)의 속도가 나오는 6TB 볼륨을 구축한 삼성 SSD 광고 영상도 있다. 물론 2009년에는 저 정도 속도도 빠른 편이었지만 2018년 기준으로 NVMe 방식의 단일 SSD가 2.5GB/s를 내는 세상이라..

RAID 0뿐만 아니라 모든 RAID 볼륨은 기록 시 한 디스크에 한번에 기록할 데이터 크기인 Stripe size를 지정할 수 있다. 컨트롤러에 따라 다르지만 Intel RST에서는 4~128KB를 지원한다. Stripe size가 4KB이고 멤버 디스크가 4개라면 16KB짜리 파일을 기록할 때 디스크당 4KB씩 돌아가면서 한 번씩 기록한다. Stripe size가 128KB이고 멤버 디스크가 2개, 기록할 파일이 2MB(2048KB)라면, 첫 번째 디스크에 128KB, 두 번째 디스크에 128KB를 순차적으로 기록하는 것을 디스크당 8번씩 반복한다. SSD에서는 128KB 이상이 추천되며, 하드디스크라면 32KB 정도가 추천된다. 하지만 사용자의 환경에 따라 최적의 성능을 내는 Stripe size가 다르므로 하나하나 적용해 보는 것이 좋다.

3.2. RAID 1[편집]

Mirroring.

각 멤버 디스크에 같은 데이터를 중복 기록한다. 멤버 디스크 중 하나만 살아남으면 데이터는 보존되며 복원도 1:1 복사로 매우 간단하기 때문에, 서버 또는 연구 목적 PC에서 혹시 모를 데이터 손실에 대비하기 위해 사용한다.

멤버 디스크를 늘리더라도 저장 공간은 증가하지 않으며, 대신 안정성이 크게 증가하게 된다. 상용 환경에서는 디스크를 2개를 초과해서 쓰는 경우가 드물지만, 극한 환경에서는 3개 이상의 멤버 디스크를 사용하기도 한다. 데이터 가치가 하드디스크 가격이 껌값으로 여겨질 정도로 높은 경우 (국가 비밀 문서 등) 사용한다. 읽기 성능은 Non-RAID와 별 차이가 없고, 쓰기 성능은 이론적으로는 소폭 하락한다. 다만, 이 하락이 하향 평준화가 기준이므로 동일 모델 동일 주차 생산품으로 구성한 경우 크게 차이가 없을 수 있다.

데이터 복구 서비스를 쓰면 되지 않냐고 반박할 수도 있지만,

  1. 복구에 장시간이 소모됨

  2. 데이터를 100% 복구하기 어려움

  3. 극비 데이터의 유출 가능성


등의 이유로 복구 서비스에만 의존할 수는 없기 때문에 RAID 1을 쓰는 것이다. 아예 데이터를 중복 저장해서 하드가 망가졌을 때 백업 등 최소한의 대처할 시간을 버는 것. 한 가지 주의할 점이 있는데 RAID 1 사용 중 HDD가 고장나면 최우선 순위는 하드 교체가 아니고 데이터 백업이다. RAID 1을 구성할 때에는 같은 제조 회사의 같은 모델 같은 주차 생산품을 쓰게 되는데(그게 권장되기도 하고) 이 말은 한쪽이 맛 간 상태면 다른 쪽도 맛 가기 일보 직전 상황일 확률이 크다는 얘기가 된다. 이 상태에서 디스크만 교체하면 RAID 컨트롤러가 리빌드(Rebuild)작업을 하면서 남은 한쪽의 하드디스크에 큰 부담을 주게 되고 결국 리빌드 중간에 남은 하나의 하드마저 뻗어버리는 사태를 당하게 된다.

3.3. RAID 1E[편집]

일부 H/W 레이드 카드에서 지원하는 홀수 개수의 HDD 어레이를 위한 RAID 10이다. 예를 들어 3개의 1TB HDD가 있을 때, 이것을 RAID 1로 구성하면 세 장의 HDD에 모든 데이터가 중복 기록되며 가용 용량은 1TB이다. RAID 1E로 구성하면 HDD 1과 HDD 2의 절반에 데이터를 기록하고, HDD 2의 나머지 절반과 HDD 3에 데이터를 중복 기록한다. 가용 용량은 1.5TB이다.

3.4. RAID 2, 3, 4[편집]

Fault Tolerance using Dedicated Parity Bit.

오류정정부호(ECC)를 기록하는 전용의 하드디스크를 이용해서 안정성을 확보한다. RAID 2는 비트 단위에 Hamming code를 적용하며, RAID 3, 4는 각각 바이트, 워드 단위로 패리티를 저장한다. 하나의 멤버 디스크가 고장나도 ECC를 이용하여 정상적으로 작동할 수 있지만, 추가적인 연산이 필요하여 입출력 속도가 매우 떨어진다. 쉽게 말해 값들을 미적분으로 저장해서 디스크 중 하나 둘 정도가 날아가도 일단 돌아가기는 하는 형태로, 함수를 저장하기 위해 용량을 약간 희생하지만 하드 하나만 뻑가도 망할 수 있는 일부 레이드 시스템에 비해 미친듯한 신뢰성과 저장용량 효율을 보인다. 디스크가 고장 나면 시스템을 가동 시키지 말고, 무조건 일단 교체 하드들을 구입해서 백업해야 한다. 성능이 많이 떨어져서 이용에 지장이 많기도 하고, 멤버 디스크 숫자에 따라 한 개에서 세 개 내외까지의 실패만 복원해 줄 뿐이지, 하나라도 더 고장나면 아예 먹통이 되기 때문.

모든 I/O에서 ECC 계산이 필요하므로 입출력 병목 현상이 발생하며, ECC 기록용으로 쓰이는 디스크의 수명이 다른 디스크들에 비해 짧아지는 문제가 있어 현재는 사용하지 않는다.

3.5. RAID 5[편집]

Fault Tolerance using Distributed Parity Bit.

기본 원리는 RAID 4와 비슷하나, 패리티를 한 디스크에 밀어 넣지 않고 각 멤버 디스크에 돌아가면서 순환적으로 저장하여 입출력 병목 현상을 해결한다. N개의 디스크를 사용하면 (N-1)배의 저장 공간을 사용할 수 있다. RAID 4처럼 하나의 멤버 디스크 고장에는 견딜 수 있지만 디스크가 두 개 이상 고장 나면 데이터가 모두 손실된다. 데이터베이스 서버 등 큰 용량과 무정지 복구 기능을 동시에 필요로 하는 환경에서 주로 쓰인다.

매번 쓰기 작업 때마다 패리티 연산 과정이 추가되어, 성능을 보장하려면 고가의 패리티 연산 전용 프로세서와 메모리를 사용해야 한다. 멤버 디스크도 최소 3개 이상 사용해야 하므로 초기 구축 비용이 비싸다는 단점이 있다. 다만 멤버 디스크의 수가 5개 이하인 중소규모 파일서버라면 소프트웨어 RAID도 괜찮다. 부팅용 하드가 별도로 필요하다는 게(그리고 부팅 하드가 뻑나면 RAID까지 풀려서 복구하기 짜증난다는) 애로점이긴 하지만... 읽기 작업은 전체 디스크에 분산되어 속도가 향상되지만, 쓰기 작업은 적어도 둘 이상의 디스크(데이터+패리티)에서 진행되어야 하므로 성능이 약간 떨어진다.

하드디스크가 하나가 사망해도 데이터가 살아있어서, 안전성이 굉장히 높아 보이나 실제로는 패리티 연산을 통해서 데이터를 저장한다는 특징 때문에 취급상 유의가 필요하며 까다롭다. 다음은 RAID 5를 고려한다면 알아야 할 사항이다.

  1. RAID 0보단 안전하다는 인식과 달리 오히려 많은 량(보통 8개 이상)의 디스크를 스토리지로 묶으면, 패리티 연산오류 발생 확률이 높아져서 인해 RAID 0으로 묶은 것보다 깨질 확률이 높아진다고 한다. 그러므로 대단위로 스토리지를 만드려는 사람이 있다면 RAID 6 또는 RAID 10을 권한다.

  2. 데이터가 분산 저장되어 있기 때문에 어레이가 깨지거나 보장되는 내결함 디스크 개수(RAID 5는 최대 1개)를 초과하는 경우 전자는 데이터를 살리기가 대단히 어렵고 후자는 사실상 데이터를 살릴 수 없다.

  3. RAID 1에서 언급했듯, RAID 5 볼륨의 HDD가 사망했다면 RAID 볼륨의 데이터를 먼저 백업해 두는 게 좋다. 이런 상황은 RAID 5에서 심심치 않게 발생하니 주의하도록 할것. RAID 6은 디스크 1개가 사망해도 1개의 여유가 있기 때문에 해당 상황의 위험성은 심각한 정도는 아니다.

  4. 어레이를 복구하려고 하드를 뽑았는데, 하필 정상이었던 하드를 잘못 뽑아서 어레이가 깨지는 경우도 심심치 않게 발생하니 주의하도록 할 것. 고급 레이드카드/소프트웨어 레이드들은 다시 붙이면 잘 붙긴 하나, 그래도 안 붙는 경우도 있으니 주의...

  5. 리빌딩을 하고 있을 때 해당 어레이에 부하를 주지 말 것. 리빌딩 도중에 사용하면 리빌딩 시간이 늘어나고, 무엇보다 리빌딩 하다가 깨질 수도 있다.

3.6. RAID 6[편집]

Fault Tolerance using Distributed Double Parity Bit.

RAID 5와 원리는 같으며, 서로 다른 방식의 패리티 2개를 동시에 사용한다. 성능과 용량을 희생해서 안정성을 높인 셈. N개의 디스크를 사용하면 (N-2)배의 저장 공간을 사용할 수 있다.

스토리지 서버와 같이 디스크를 빼곡히 꽂는(기본 10개 단위) 환경에서 RAID 5는 유지보수가 어려우며, 안정성을 높이기 위한 목적으로 주로 사용된다. 하드 하나가 고장난 RAID 5 장비에서 교체 하려다가 실수로 멀쩡한 하드 하나를 뽑았다 → 데이터는 천국으로. 동일 상황에서 RAID 6는 문제가 없다. 컨트롤러가 RAID 5보다 더 비싸고, 멤버 디스크도 기본 4개 이상 확보해야 하므로 초기 구축 비용이 비싸다.

하드디스크를 대단위로 물려야 하고, 데이터 안정성의 필요성이 RAID 5보다 높아야 하는 상황에서 쓰인다.

3.7. RAID-Z3[편집]

오라클의 ZFS라는 파일 시스템에서 지원하는 소프트웨어 RAID에서 제공하는 모드. Z1과 Z2는 각각 RAID 5와 RAID 6과 유사하지만, Z3은 RAID 6 / Z2보다 패리티를 하나 더 쓴다.RAID-7? 그만큼 최소 구성 멤버 디스크도 하나 더 많고, 위에서 언급한 것처럼 스토리지 서버와 같이 디스크를 빼곡히 꽂는(기본 10개 단위) 환경에서, 특히 최근 또는 근미래의 고용량 HDD(개당 수 TB 이상)를 이용한 구성에서 고장난 HDD를 교체 시 거기에 데이터를 채워넣는 데 시간이 오래 걸리므로 그 사이에 또 다른 HDD가 죽고...하는 경우까지 생각해서 유지보수를 돕기 위해 패리티를 늘린 것이다. 패리티를 3중으로 사용하는 만큼 하드웨어 자원도 대단히 많이 사용한다.
출처 https://en.wikipedia.org/wiki/ZFS

3.8. 그 외의 RAID Level[편집]

3.8.1. JBOD[편집]

Just Bunch of Disks.

그냥 여러 디스크를 하나의 디스크처럼 보이게 수평적으로 섹터를 이어 붙인 개념이다. RAID 0처럼 멤버 디스크 중 하나만 깨져도 모든 데이터가 손실되지는 않고 고장난 디스크에 해당하는 부분만 날아간다. 때문에 로그 기록같이 부분적으로 데이터가 파손되어도 괜찮은 환경에서 가끔 사용된다. 현실에서는 굳이 로그용 디스크를 따로 할당하는 경우가 별로 없고 그냥 RAID5 볼륨에서 로그까지 기록하는 경우가 많다.

디스크를 Spanning한 환경이기 때문에 다중 사용자 환경에서 분산도가 높은 데이터를 다루는 경우 RAID 0에 근접하는 성능을 얻을 수도 있으나... 현실은 20%의 핵심 데이터에 모든 액세스가 집중되므로 현실은 시궁창... 같은 환경에서 RAID 0은 20%의 핫존이 모든 디스크에 고루 분포돼있지만 JBOD는 한두개의 디스크에 몰려 있다.

RAID는 모든 멤버 디스크의 성능(저장 공간이나 I/O 성능 등)이 같은 환경을 전제하기 때문에 멤버 디스크 성능에 차이가 있으면, 가장 낮은 성능으로 하향 평준화된다. 예를 들어 160GB짜리와 1000GB짜리 하드디스크를 RAID 0으로 묶으면 160 × 2인 320GB만 쓸 수 있고, 840GB는 단일 파티션을 구성하든 해야 한다. 반면 JBOD는 멤버 디스크의 성능이 서로 달라도 무방하므로 어떻게 돈지랄을 해도 저장해야 할 데이터 크기만큼의 하드를 확보할 수 없을 때에 쓴다. 예를 들면 과거 HDD의 용량 단위가 MB 단위로 나오던 시절.

이러한 문제로 WD에서는 Raid Edition이라는 기업 대상 레이드 전용 제품군을 출시한 적도 있다. 이 녀석은 무상 A/S기간도 5년이나 된다.

3.8.2. Nested RAID[편집]

레이드 볼륨의 멤버로 다른 레이드 볼륨을 사용하는 형태. 볼륨 확장 과정에서 구성 편의성 문제로 형성되는 경우가 많다. 이 때 멤버 디스크를 묶는 배열을 하위 배열, 하위 배열을 묶는 배열을 상위 배열이라고 한다. 대표적인 예시로 10, 0+1, 15, 50, 0+5, 51 등이 존재한다. 표기 방법은 m(하위 배열)n(상위 배열)이며 m=0이면 뒤에 +를 붙인다. 아래 예시는 1TB 디스크 6개로 구성한다는 상황을 가정한다.

  • RAID 10
    하위 배열은 RAID 1, 상위 배열은 RAID 0이다. RAID 1로 미러링 된 볼륨을 RAID 0으로 스트라이핑 한다.
    퍼포먼스 및 용량 위주로 구성한다면, 디스크 2개를 RAID 1로 묶은 미러 볼륨 3개를 RAID 0으로 스트라이핑 한다. 이 경우 사용 가능한 총 용량은 3TB가 된다.
    안정성 위주로 구성한다면, 디스크 3개를 RAID 1로 묶은 미러 볼륨 2개를 RAID 0으로 스트라이핑 한다. 이 경우 사용 가능한 총 용량은 2TB가 된다.
    RAID 0+1에 비해 디스크 장애 발생 시 복구가 수월하다.

  • RAID 0+1
    하위 배열은 RAID 0, 상위 배열은 RAID 1이다. RAID 0으로 스트라이핑 된 볼륨을 RAID 1로 미러링 한다.
    퍼포먼스 및 용량 위주로 구성한다면 디스크 3개를 RAID 0으로 묶은 스트라이프 볼륨 2개를 RAID 1로 미러링 한다. 이 경우 사용 가능한 총 용량은 3TB가 된다.
    안정성 위주로 구성한다면, 디스크 2개를 RAID 0으로 묶은 스트라이프 볼륨 3개를 RAID 1로 미러링 한다. 이 경우 사용 가능한 총 용량은 2TB가 된다.
    RAID 10에 비해 RAID 볼륨이 깨졌을 경우 복구가 번거롭다. RAID 10과 비교하자면, 미러 볼륨으로 구성된 어레이에서 디스크 하나가 고장이 났다면, 미러 볼륨 자체는 깨지지 않는다. 즉, 디스크만 바꿔 넣어주면 알아서 리빌딩하여 원래 상태로 돌아간다. 하지만 RAID 0+1의 경우 디스크 하나가 고장이 났다면, 해당 RAID 0 어레이 전체가 깨져 버린다. 디스크를 교체한 뒤 RAID 0 어레이를 다시 구성한 다음, 미러링해야 한다.

  • RAID 15
    하위 배열은 RAID 1, 상위 배열은 RAID 5다. 개인 사용자 레벨에서는 사용할 일이 거의 없는 RAID 레벨이다. RAID 1로 미러링 된 볼륨을 RAID 5 볼륨으로 묶는다. RAID 5의 경우 최소 3개 이상의 디스크가 필요하기 때문에 디스크 6개로 구성할 수 있는 경우의 수는 하나밖에 없다.
    디스크 2개를 RAID 1로 묶은 미러 볼륨 3개를 RAID 5로 묶는다. 이 경우 사용 가능한 총 용량은 2TB가 된다.

  • RAID 50
    하위 배열은 RAID 5, 상위 배열은 RAID 0이다. 마찬가지로 개인 사용자 레벨에서는 사용할 일이 거의 없다. RAID 5 볼륨을 RAID 0으로 스트라이핑 한다. 마찬가지로 RAID 5의 경우 최소 3개 이상의 디스크가 필요하기 때문에 디스크 6개로 구성할 수 있는 경우의 수는 하나밖에 없다.
    디스크 3개를 RAID 5 볼륨으로 묶은 것을 RAID 0으로 스트라이핑 한다. 이 경우 사용 가능한 총 용량은 4TB가 된다.
    RAID 0+5에 비해서 디스크 장애 발생 시 복구가 수월하다.

  • RAID 0+5
    하위 배열은 RAID 0, 상위 배열은 RAID 5이다. 역시 개인 사용자 레벨에서는 사용할 일이 거의 없다. RAID 0 볼륨을 RAID 5 볼륨으로 묶는다. 역시 RAID 5의 경우 최소 3개 이상의 디스크를 필요로 하므로 디스크 6개로 구성할 수 있는 경우의 수는 하나밖에 없다.
    디스크 2개를 RAID 0으로 묶은 스트라이프 볼륨 3개를 RAID 5로 묶는다. 이 경우 사용 가능한 총 용량은 4TB가 된다.
    RAID 50에 비해 장애 조치가 힘들다. 이유는 RAID 0+1에도 나와 있지만 디스크 장애 발생시 해당 RAID 0 볼륨이 깨져 버리기 때문.

  • RAID 51
    하위 배열은 RAID 5, 상위 배열은 RAID 1이다. 이 역시 개인 사용자 레벨에서는 사용할 일이 거의 없다. RAID 5 볼륨을 RAID 1로 미러링 한다. 역시 RAID 5 볼륨의 경우 디스크 3개 이상을 필요로 하므로 역시 구성할 수 있는 경우의 수는 하나밖에 없다.
    디스크 3개를 RAID 5 볼륨으로 묶고, 그 볼륨 두개를 RAID 1로 미러링 한다. 이 경우 사용 가능한 총 용량은 2TB가 된다. RAID 15나 51이나 장애 발생시 복구하는 데 필요한 노력은 비슷하다. RAID 1 환경에서 디스크가 깨진 경우에도 디스크를 교체해 주면 리빌딩하여 복구가 되지만, 그건 RAID 5도 마찬가지다.

3.9. 그 외의 RAID 용어[편집]

3.9.1. SHR[편집]

Synology Hybrid RAID

NAS 제조사인 Synology에서 만든 레이드 방식으로, 서로 다른 용량의 HDD를 사용할 때 남는 부분의 낭비 없이 사용 가능하도록 하는 기술이다. 간단히 예를 들어 1TB 하드와 3TB 하드가 있다고 할 때, RAID 1 미러로 묶으면 1TB만 사용 가능하며, 3TB의 2/3는 사용이 불가능하다. SHR에서는 이것을 미러링되는 1TB와 단독 하드 2TB를 묶어 놓은 것처럼 해 준다. RAID HDD를 점차 용량이 큰 것으로 업그레이드 하고자 할 때 유용하게 사용 가능하다.

제조사의 설명 문서

3.9.2. Hot Spare[편집]

RAID 1, 5, 6 등 소수의 하드디스크가 고장나더라도 운영에 지장이 없는 RAID Level을 위해 존재한다. 전체 멤버 디스크에서 1개 이상의 디스크를 Spare로 지정해서, 평소에는 데이터를 읽고 쓰는 행위를 하지 않고 그냥 대기(stand-by) 시키다가 디스크가 고장났을 때 자동으로 해당 디스크에 리빌딩하여 원래 RAID 볼륨을 복구한다. 디스크가 1개 고장났을 때 RAID 볼륨을 알아서 복구해 주기 때문에 약간의 시간을 벌 수 있지만, 고장난 HDD를 빠르게 교체해 주지 않으면 Hot Spare가 없는 것과 마찬가지가 된다. 일반적으로 RAID 1에서는 2 + 1 의 구성으로, RAID 5에서는 멤버 디스크+1로, RAID 6에서는 멤버 디스크 + 2로 구성한다.

단점이라면 Hot Spare로 지정한 디스크는 평소에는 하는 일이 없기 때문에 전체 디스크 개수가 적다면 사용 용량 감소분이 상대적으로 더 커진다. RAID 볼륨을 여러 개 지정하는 중대형 스토리지에서는 Global Spare 기능으로 여러 RAID 볼륨에서 공용으로 Hot Spare를 사용하게 하는 경우도 있다.

4. 개인 환경에서의 사용[편집]

유닉스 계열은 볼륨 매니징과 RAID 기능 자체를 파일 시스템에서 제공하는 경우가 늘고 있다. 대표적인 것이 ZFS이고, 리눅스에서는 mdadm을 사용하여 파일 시스템보다 아래쪽인 블록 장치 단위에서 RAID 기능을 사용하거나, Btrfs라는 파일 시스템에서는 자체 레이드를 제공한다. 사용 OS가 유닉스 계열이라면 이쪽도 고려해 볼만 하다.

흔히 파코즈2CPU 등에서 이를 구축한 사람을 쉽게 볼 수 있다. 만약 하드디스크 사망으로 인한 데이터 손실을 경험해 보았다면, RAID 1 정도는 구축해 보아도 나쁘지 않을 것이다. 물론 용량 및 성능 대비 비용이 크다는 단점이 있다. 사실 그 비용은 안정성을 위해 지출하는 것이기는 하지만.

최근 들어 NAS의 보급으로 인해 개인 환경에서 사용하는 경우도 많아졌다. 주로 사진과 같이 다량의 데이터를 보관하거나 미디어 서버의 용도로 사용하는 경우가 많은데 예전에 비해 많이 저렴한 가격으로 사용할 수 있다. 또한 4-bay 이상의 NAS도 많이 저렴해져 개인 level 에서 RAID 5 이상을 구현하는 경우도 예전보다는 늘었다. 2011년 4월 기준 2베이 정도는 20-30에도 NAS 본체를 구입 가능하며 4베이 이상은 100만원 정도부터 시작. 2-3년 전에 비해 정말 정말 저렴해졌다.

하지만 명심해야 할 것은 RAID는 백업이 아니다! RAID 백업하는 것과 RAID 백업으로 사용하는 것은 엄연히 다르다. 실제로 저 문구는 RAID를 설명하는 글에서 자주 등장한다. 데이터 안정성 목적으로 RAID는 전통적인 백업을 절대로 대체하지 못하며, 데이터 안정성보다는 디스크 몇 개가 고장나서 갈아 끼워야 할 때도 나머지 디스크로 중단 없이 서비스를 하려는 목적이 오히려 더 강하다.

사실 하드디스크가 뻑날 확률은 디스크 개수만큼, 그리고 돌아가는 시간만큼 뻥튀기가 되기 때문에 수십개를 주렁주렁 달아놓고 24시간 돌아가는 서버의 경우에는 커다란 문제이고 RAID가 가뭄에 단비와도 같은 존재지만, 4-5개 정도의 디스크만 사용하며 실제 하드디스크를 사용하는 정도도 훨씬 덜한 개인 사용자들의 경우에는 사실 디스크가 뻑나서 날려먹는 경우보다 본인 실수로 잘못 지운다거나 해서 날려먹는 경우가 훨씬 많다고 볼 수 있다. 이 때문에 개인 사용자의 경우에는 RAID보다 백업이 훨씬 가치가 크다. RAID에 대한 지식이 별로 없는 개인 사용자들이 흔히 범하는 실수가, 몇 개 안되는 디스크로 데이터 안정성을 목적으로 백업 없이 4개 정도의 디스크를 RAID 1로 구축해 버리는 경우다. 아무것도 안 하는 것보단 낫긴 하지만 차라리 안정성 구현을 원한다면 주기적으로 백업하는 편이 훨씬 낫다. HDD가 정말 많다면 RAID 10을 구성하고 따로 또 백업하는 게 그냥 그 HDD들을 하나의 컨트롤러에 몰아넣고 미러링 해버리는 것보다 나은 방법이다.

소비자 수준에서는 RAID 5로 적절한 가격에 적절한 신뢰성과 용량 확장을 노릴 수도 있다. 하지만 제대로 RAID를 하기 위해 컨트롤러를 따로 구매하면 가격은 가격대로 비싸진다. 소프트웨어 RAID도 RAID 5를 지원하지만 정말 지원만 하는 수준이고 성능은 기대하기 힘든 경우가 많다. RAID 컨트롤러에 연결되어 있는 디스크 상태를 자주 모니터링해 주지 않으면 관리 소홀로 두 개가 죽을 때까지 모르다가 데이터만 날리는 경우도 있다. 대부분 같은 시기에 생산된 같은 HDD를 이용하기 때문에 하나가 죽으면 다른 것도 비슷한 시기에 죽을 확률이 높다. 그리고 HDD를 교체하고 나서도 리빌딩 하다가 다른 HDD가 죽으면 그 길로 데이터는 바이바이...

그냥 수작업이나 반자동으로 백업하면서 디스크에 필요 없는 그녀것들좀 지우고 정리나 하자. 요즘 백업 솔루션들이 워낙에 강력해져서 필수적인 파일들만 내 문서 같은 폴더 안에 넣어서 저장하고 폴더 타게팅 백업 하면 포맷해도 꼭 필요한 자료들은 남게 된다. 무료 백업이나 동기화 소프트웨어도 많으니 이들 중 괜찮은 거 하나 잘 골라서 활용하면 레알 수작업보단 훨씬 편리한 백업을 구축할 수 있을 것이다. 클라우드 백업도 마찬가지이긴 하지만 약간 골때리는 게 시스템 내의 폴더들을 지정해서 클라우드로 백업 시켰다가 저질, 혹은 무료 서비스를 이용해서 버전별 백업이 안 되어 있다면 시스템 상에서 문제가 생겨 파일이 손상될 경우 손상된 파일로 업데이트 되기 때문에 복구가 불가능해 진다. NAS 사라 걍

특히 데이터베이스 같은 경우에도 레이드는 사용해선 안 된다. 실무에서는 캐싱메모리조차 무결성에 문제가 발생되면 복구가 힘들기 때문이다. 굳이 레이드를 사용해야 할 경우, 차라리 DB 서버를 추가하여 구성하는 것이 좋을 것이다. DB 서버가 원래 병렬화에 적합하게 설계되었기 때문.