중첩 된 RAID 레벨 1 + 5 또는 1 + 6이 거의 알려지지 않은 이유는 무엇입니까? 중첩 RAID 레벨 위키 백과 문서는 현재 자신의 섹션이 없습니다. RAID 1 + 0 트리플 미러링과 비교할 때 RAID 1 + 0보다 일반적이지 않은 이유를 이해하지 못합니다.

드라이브 용량이 성능이나 안정성보다 빠르게 증가함에 따라 재 구축 시간이 점점 더 문제가되고있는 것은 분명합니다. RAID 1이 더 빨리 재구성되고 RAID 1 쌍의 RAID 0 배열이 문제를 피하지만 RAID 5 또는 6 배열의 RAID 1 쌍은 그렇지 않을 것이라고 들었습니다. 적어도 이들이 RAID 1 + 0의 일반적인 대안이 될 것으로 기대합니다.

1TB 드라이브 중 16 개 드라이브의 경우 백업에 의지 할 수있는 순진한 확률, 즉 드라이브가 확률과 무관하다는 가정을 단순화 한 것입니다.

RAID | storage | cumulative probabilities of resorting to backup /m
 1+0 |     8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
 1+5 |     7TB | 0,  0,   0,  15,  77, 217, 441, 702,  910, 1000, 1000
 1+6 |     6TB | 0,  0,   0,   0,   0,   7,  49, 179,  441,  776, 1000
(m = 0.001, i.e. milli.)

이것이 맞다면 스토리지 용량을 25 % 만 줄이면 RAID 1 + 6이 RAID 1 + 0보다 훨씬 더 안정적이라는 것이 분명합니다. 일반적인 경우와 마찬가지로 이론적 인 쓰기 처리량 (탐색 시간을 계산하지 않음)은 스토리지 용량 / 배열 크기 × 드라이브 수 × 어레이에서 가장 느린 드라이브의 쓰기 처리량입니다 (중복이있는 RAID 레벨은 쓰기에 대한 쓰기 증폭이 높음). 스트라이프를 채우지 않지만 청크 크기에 따라 다름) 이론적 읽기 처리량은 어레이에있는 드라이브의 읽기 처리량의 합계입니다 (RAID 0, RAID 5 및 RAID 6은 여전히 ​​이론적으로 가장 느린 속도, 두 번째로 느린 속도 및 세 번째로 느린 드라이브 읽기 처리량). 즉, 동일한 드라이브를 가정하면 각각 8x, 7x,

또한, RAID 0 고려 쿼드 러플 (12 개) 드라이브의 RAID 1 트리플 즉, RAID 12 개 드라이브 1 + 0 트리플 미러링 및 RAID 1 쌍의 RAID 6 육배, 즉 RAID 1 + 6. 다시, 이들은 동일한 1TB 드라이브입니다. 두 레이아웃 모두 동일한 수의 드라이브 (12), 동일한 스토리지 용량 (4TB), 동일한 비율의 중복성 (2/3), 동일한 최대 쓰기 처리량 (4x) 및 동일한 최대 읽기 처리량 ( 12 ×). 여기 내 계산이 있습니다 (지금까지).

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | 0, 0, 18,  ?,   ?,   ?,   ?,   ?, 1000
1+6 (6×2) | 0, 0,  0,  0,   0,  22, 152, 515, 1000

예, 이것은 과잉으로 보일 수 있지만 3 중 미러링을 사용하여 백업용 복제본을 분리하는 경우 RAID 1 + 6은 RAID 2 개를 제외한 모든 드라이브의 각 드라이브 1 개를 고정하고 제거하는 것만으로도 사용할 수 있습니다. 1 쌍이며, 그렇게하면서 성능이 저하 된 RAID 1 + 0 어레이보다 성능이 저하 될 때 여전히 안정성이 훨씬 뛰어납니다. 다음은이 방식으로 12 개 드라이브에 대한 계산이 4만큼 저하 된 것입니다.

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | (0, 0, 0, 0), 0, 143, 429, 771, 1000
1+6 (6×2) | (0, 0, 0, 0), 0,   0,  71, 414, 1000

그러나 RAID 1 + 6의 경우이 시간 동안 읽기 처리량이 6 배로 저하 될 수 있지만 RAID 1 + 0은 8 배로 감소됩니다. 그럼에도 불구하고 어레이가이 성능 저하 상태에있는 동안 드라이브에 장애가 발생하면 RAID 1 + 6 어레이는 약 50 배의 확률로 약 6 배로 유지되거나 5 배로 제한 될 수 있지만 RAID 1 + 0 어레이는 병목 현상 이 4 배로 제한됩니다 . 쓰기 처리량은 거의 영향을받지 않아야합니다 (백업에 사용 된 드라이브가 가장 느린 드라이브 인 경우 증가 할 수도 있음).

사실, 성능이 저하 된 RAID 1 + 6 어레이가 추가 RAID 6 그룹 4 드라이브를 분리 할 수 ​​있기 때문에 둘 다 '트리플 미러링'으로 볼 수 있습니다. 다시 말해,이 12 드라이브 RAID 1 + 6 레이아웃은 성능이 저하 된 3 개의 RAID 6 어레이로 나눌 수 있습니다!

그렇다면 대부분의 사람들이 수학에 대해 자세히 설명하지 않은 것입니까? 앞으로 더 많은 RAID 1 + 6을 보게 될까요?

일반적으로 RAID 1 + 0은 1 + 5 또는 1 + 6보다 널리 사용되는 경향이 있는데, 이는 RAID 1 + 0이 충분히 신뢰할 수 있고 약간 더 나은 성능과 더 유용한 스토리지를 제공하기 때문입니다.

나는 대부분의 사람들이 RAID 1 + 0 그룹 내에서 전체 RAID 1 쌍의 실패를 백업을 파괴 할 가치가있는 매우 드문 사건으로 생각할 것입니다. 아마도 물리적인의 50 % 미만을 얻는 것에 대해 너무 열성적이지 않을 것입니다 사용 가능한 공간으로 디스크.

RAID 1 + 0보다 더 나은 안정성이 필요하다면 바로 사용하십시오! .. 그러나 대부분의 사람들은 그럴 필요가 없습니다.

실질적인 대답은 하드웨어 RAID 컨트롤러 사양, 평균 디스크 크기, 드라이브 폼 팩터 및 서버 디자인의 교차점에 있습니다.

대부분의 하드웨어 RAID 컨트롤러는 지원하는 RAID 레벨로 제한됩니다. 다음은 HP ProLiant Smart Array 컨트롤러에 대한 RAID 옵션입니다.

[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]

참고 : "adm"은 3 중 미러링입니다.

LSI RAID 컨트롤러는 다음을 지원합니다. 0, 1, 5, 6, 10, 50, and 60

따라서이 컨트롤러는 RAID 50 및 60 만 중첩 수준으로 사용할 수 있습니다. LSI (예 : Dell PERC ) 및 HP는 대부분의 엔터프라이즈 서버 스토리지 어댑터 시장을 구성합니다. 이것이 현장에서 RAID 1 + 6 또는 RAID 61과 같은 것이 보이지 않는 주요 이유입니다.

이러한 고려 사항 외에도 RAID 10 이상의 중첩 RAID 레벨에는 비교적 많은 수의 디스크가 필요합니다. 오늘날 사용 가능한 드라이브 용량 (3.5 인치 니어 라인 SAS 및 SATA 드라이브 사용)이 증가하고 많은 서버 섀시가 약 8 x 2.5 "드라이브 케이지로 설계되어 있다는 사실과 함께 RAID 1+를 물리적으로 구성 할 수있는 기회는 많지 않습니다. 6 또는 RAID 61.

RAID 1 + 6과 같은 영역은 대형 섀시 소프트웨어 RAID 솔루션입니다. Linux MD RAID 또는 ZFS는 확실히 가능합니다. 그러나 그때까지는 핫 또는 콜드 스페어 디스크로 드라이브 오류를 완화 할 수 있습니다. 유독 한 RAID 레벨과 하드웨어 조합 (예 : RAID 5 및 6TB 디스크)을 피한다면 RAID 안정성은 요즘 큰 문제가되지 않습니다. 또한 계층화 및 캐싱 계층을 통해 읽기 및 쓰기 성능이 추상화됩니다. 평균 스토리지 워크로드는 일반적으로 하나 이상의 이점을 얻습니다.

결국, 그것은 필요 / 수요가없는 것처럼 보입니다.

• 신뢰성에 대한 수익이 감소하고 있습니다. RAID 6은 10 ^ 14 UBER 비율의 1 인 불쾌한 SATA 드라이브에서도 복합 오류가 발생하지 않을 것입니다. FC / SAS 드라이브에서 UBER은 10 ^ 16의 1이며 성능도 상당히 향상됩니다.

• RAID 그룹 안정성은 실수로 삭제되는 것을 방지하지 않습니다. (그래도 백업이 필요합니다)

• 특정 수준의 RAID를 넘어 서면 디스크에서의 복합 장애 가능성은 인프라 (전력, 네트워크, 에어컨 누출 등)의 복합 장애보다 낮아집니다.

• 페널티를 씁니다. RAID 61에서 들어오는 각 쓰기 작업은 12 개의 IO 작업을 시작합니다 (순진하게 완료). RAID 6은 TB 랜덤 쓰기 당 IOP와 관련하여 '낮은 계층'시나리오에서 이미 고통 스럽습니다. (더 높은 계층에서는 실패율이 100 배 더 좋습니다)

• '25 % 감소 '가 아니라 추가 25 % 감소입니다. 16TB가 6TB로 바뀌고 있습니다. 따라서 사용 가능한 스토리지는 37.5 %입니다. 용량 당 3 배 많은 디스크와 3 배 많은 데이터 센터 공간이 필요합니다. 더 작은 RAID6 세트를 만들면 더 높은 안정성을 얻을 수 있습니다. 나는 숫자 크 런칭을하지 않았지만 예를 들어 3x 3 + 2 세트 (15 드라이브, RAID10보다 스토리지 오버 헤드가 적음)의 RAID 6 합계를 시도하십시오. 또는 대신 3 방향 미러를 수행하십시오.

다중 사이트 DR에 대해 생각하는 것보다 일반적입니다. DR5 사이트에 대해 비동기식 또는 동기식으로 RAID5 / 6 / DP RAID 그룹이있는 복제 된 스토리지 배열을 실행합니다. (피할 수 있으면 동기화하지 마십시오.보기에 좋지 않습니다. 실제로는 끔찍합니다).

내 NetApp의 경우 미러링 된 집계가있는 메트로 클러스터입니다. VMAX를 사용하면 SRDF (Symmetrix Remote Data Facility)가 있습니다. 그리고 내 3PAR은 원격 복사를 수행합니다.

비싸지 만 DR의 '데이터 센터 잡기 화재'수준을 제공합니다.

트리플 미러와 관련하여-직접 RAID 복원력 측정 방법이 아니라 백업 전략의 일부로 전체 복제본으로 사용했습니다. 세 번째 미러를 동기화하고 분할 한 후 별도의 서버에 마운트하고 완전히 다른 인프라를 사용하여 백업하십시오. 그리고 때로는 복구 옵션으로 세 번째 미러를 회전시킵니다.

내가하려고하는 요점은 스토리지 관리자로서의 직접 경험에서 ~ 40,000 개의 스핀들 영역에서 (예, 매일 수십 개의 드라이브를 교체하고 있음)-다양한 백업을 위해 백업을해야한다는 것입니다 지난 5 년 동안의 이유가 있지만 RAID 그룹 오류는 없었습니다. 우리는 상대적인 장점과 수용 가능한 복구 시간, 복구 지점 및 중단 기간에 대해 논의합니다. 그리고이 모든 것을 뒷받침하는 것은 항상 추가 탄력성의 비용입니다.

당사의 모든 미디어 스크럽 및 장애는 드라이브를 예측하고 적극적으로 예비 및 테스트합니다.

적절한 RAID 구현이 있었더라도 비용 편익은 존재하지 않습니다. 스토리지 공간에 소비되는 비용은 더 긴 보존 기간 또는 더 자주 백업주기에 더 잘 투자됩니다. 또는 더 빠른 통신. 또는 동일한 복원력 수를 가지더라도 스페어를 더 빨리 재구성하면 복합 고장 확률이 향상되므로 일반적으로 더 빠른 스핀들입니다.

따라서 귀하의 질문에 대한 답변을 제공 할 것이라고 생각합니다.

비용 이점이 단순히 누적되지 않기 때문에 RAID 1 + 6 및 1 + 5가 자주 표시되지 않습니다. 금액이 한정되어 있고 처음에 백업 솔루션을 구현해야하는 경우 중단 빈도를 줄이기 위해 비용을 지출하면됩니다. 그 돈을 쓰는 더 좋은 방법이 있습니다.

현대식 시스템과 고급 시스템은 모양이 너무 복잡하고 완전히 불필요하며 효율성과 비슷하기 때문에 모양을 구현하지 않습니다.

다른 사람들이 지적했듯이 원시 공간과 사용 가능한 공간의 비율은 본질적으로 3 : 1입니다. 기본적으로 3 개의 사본 (2 개의 중복 사본)입니다. "raid6"의 계산 비용 (미러 된 경우 두 번 이상)과 그에 따른 IOPS 손실로 인해 이는 매우 비효율적입니다. 잘 설계되고 조정 된 ZFS에서 동등한 솔루션은 용량면에서 3 웨이 미러 스트라이프를 만드는 것입니다.

예를 들어, 6 웨이 raid6 / raidz2 모양의 미러 (총 12 개의 드라이브) 대신 매우 비효율적이며 (ZFS에 구현할 메커니즘이없는) 4 개의 3 웨이 미러 (12 개)도 있습니다 드라이브). 그리고 1 개의 드라이브 가치의 IOPS 대신 4 개의 드라이브 가치의 IOPS가 있습니다. 특히 가상 머신의 경우에는 큰 차이가 있습니다. 두 모양의 총 대역폭은 순차적 읽기 / 쓰기에서 매우 유사 할 수 있지만 3 방향 미러 스트라이프는 임의 읽기 / 쓰기로 더욱 응답 성이 좋습니다.

요약하면 : raid1 + 6은 일반적으로 비실용적이며 비효율적이며 당연히 스토리지에 대해 진지한 사람이 개발을 고려하지 않을 것입니다.

IOPS 불일치를 명확히하려면 : 각 쓰기마다 raid6 / raidz2 모양의 미러를 사용하여 12 개의 드라이브 모두 하나의 역할을해야합니다. 전체 모양이 활동을 여러 동작으로 분할하여 여러 모양이 독립적으로 수행 할 수있는 기능은 없습니다. 3 웨이 미러 스트라이프를 사용하는 경우 각 쓰기는 4 개의 미러 중 하나만 처리해야 할 수 있으므로 추가 쓰기 작업은 추가 작업을보기 전에 전체 옴니버스 모양이 처리 될 때까지 기다릴 필요가 없습니다. .

아무도 직접 언급하지 않았기 때문에 : Raid6 쓰기 성능은 그리 나쁘지 않습니다. 부하가 가해지면 설명을 넘어서는 끔찍한 일입니다.

순차적 쓰기는 가능하며 캐싱, 쓰기 병합 등이이를 수행 할 수있는 한 괜찮습니다. 부하가 높을 때 상황이 나빠 보이며 이것이 1 + 5 / 6 설정이 거의 사용되지 않는 주된 이유입니다.

찾기 시간

문제는 쓰기 탐색 증폭이 쓰기 처리량 증폭 과 매우 다르게 작동한다는 것 입니다. 패리티를 사용하여 최소 쓰기 처리량 증폭은 전체 스트라이프가 한 번에 기록 될 때 발생하지만 (이 형용사를 '전체 스트라이프'라고 부름), 최소 쓰기 탐색 증폭은 반대로, 가상 장치에서 검색 후 전체 쓰기가 적합 할 때 발생합니다. 단일 덩어리. 자세히 설명하기 전에 관계를 표 형식으로 전달하기가 훨씬 쉽습니다.

RAID | write throughput amplification factor | write seek amplification factor
     | full-stripe (e.g.) | single-chunk     | full-stripe  | single-chunk
   0 | 1           ;  1   | 1           ;  1 | n       ; 12 | 1           ;  1
   1 | n           ; 12   | n           ; 12 | n       ; 12 | n           ; 12
   5 | n/(n - 1)   ; ~1.1 | min [3, n]  ;  3 | n       ; 12 | min [3, n]  ;  3
   6 | n/(n - 2)   ;  1.2 | min [5, n]  ;  5 | n       ; 12 | min [5, n]  ;  5
*1+0 | n₁          ;  3   | n₁          ;  3 | n       ; 12 | n₁          ;  3*
 1+5 | n/(n₅ - 1)  ;  2.4 | expr₁       ;  5 | n       ; 12 | expr₁       ;  5
*1+6 | n/(n₆ - 2)  ;  3   | expr₂       ;  8 | n       ; 12 | expr₂       ;  8*
expr₁ = 2n₁ + min [1, n₅ - 2]
expr₂ = 3n₁ + min [2, n₆ - 3]

여기서 n은 총 드라이브 수, n₁는 RAID 1 그룹의 드라이브 수, n₅ 및 n₅은 각각 RAID 5 또는 RAID 6 어레이의 그룹 수입니다. 예제는 문제의 12 개 드라이브 예제와 관련이 있습니다 (관련 행은 ' *bolded*'). RAID 레벨 1 + 0, 1 + 5, 1 + 6의 예는 각각 4x3, 6x2, 6x2입니다.

전체 스트라이프 쓰기 처리량 증폭 계수 만 중복 비율과 직접 관련이 있습니다. 단일 청크 경우는 패리티가있는 경우에 더 복잡합니다. 단일 청크를 작성하려면 새 데이터 청크와 함께 패리티 청크를 작성하기 전에 패리티 청크 또는 다른 데이터 청크 중에서 가장 쉬운 것을 읽어야하기 때문에 발생합니다. (유도 된 읽기에 RAID 1에 대한 각각의 읽기 처리량 / 탐색 증폭 계수를 곱해야하기 때문에 직접 곱셈은 아닙니다. 둘 다 1입니다. 아래를 참조하십시오.)

불행히도이 추가 쓰기 처리량 증폭을 최소화하는 청크 크기를 선택하면 실제로 최대화 하는 부작용이 있습니다. 쓰기 탐색 증폭 있습니다. 검색 시간과 비교하여 쓰기 시간이 무시할 수있는 작은 쓰기의 경우, 아주 작은 청크 크기 (전체 스트라이핑)를 가진 스트라이핑의 쓰기 성능은 모든 드라이브를 검색해야하기 때문에 미러링과 같은 1 배입니다. 각 쓰기에 대한 청크와 이러한 모든 드라이브를 동원하여 얻은 처리량은 관련이 없습니다. 탐색 시간의 쓰기 시간 비율을 어레이의 드라이브 수로 나누었지만 작은 쓰기의 경우 이미 무시할 수 있습니다. 작은 크기의 쓰기조차도 전체 스트라이프를 만들 정도로 작은 청크 크기를 사용하는 것은 이치에 맞지 않습니다. 탐색의 효과를 느낄 정도로 작 으면 쓰기는 단일 청크 내에 들어가는 것이 가장 좋습니다.

RAID | large contiguous write throughput    | concurrent tiny writes throughput
     | full-stripe    | single-chunk        | full-stripe | single-chunk
   0 | n×       ; 12× | n×          ; 12×   | 1×     ; 1× | n×          ; 12×
   1 | 1×       ;  1× | 1×          ;  1×   | 1×     ; 1× | 1×          ;  1×
   5 | (n - 1)× ; 11× | max[n/3, 1]×;  4×   | 1×     ; 1× | max[n/3, 1]×;  4×
   6 | (n - 2)× ; 10× | max[n/5, 1]×;  2.4× | 1×     ; 1× | max[n/5, 1]×;  2.4×
*1+0 | n₀×      ;  4× | n₀×         ;  4×   | 1×     ; 1× | n₀×         ;  4×  *
 1+5 | (n₅ - 1)×;  5× | expr₃×      ;  2.4× | 1×     ; 1× | expr₃×      ;  2.4×
*1+6 | (n₆ - 2)×;  4× | expr₄×      ;  1.5× | 1×     ; 1× | expr₄×      ;  1.5×*
expr₃ = n/(2n₁ + min [1, n₅ - 2]) = max [n/(2n₁ + 1), n/(2n₁ + n₅ - 2)]
expr₄ = n/(3n₁ + min [2, n₆ - 3]) = max [n/(3n₁ + 2), n/(3n₁ + n₆ - 3)]

참고 : 검색 시간이 중요한 쓰기보다 크지 만 큰 쓰기가 전체 스트라이핑 될 수있을 정도로 작은 적당한 청크 크기를 고려하면 중간 2 처리량 열을 무시할 수 있습니다. 2 차 처리량 열의 큰 청크 크기는 스팬 드라이브와 더 유사합니다. '작은'쓰기는 처리량의 영향을 무시할 수있는 곳입니다.

청크 크기가 부적절하면 읽기에 대한 탐색 증폭의 효과도 증가하지만 전체 스트라이프의 경우에만 그러하지는 않습니다.

RAID | read throughput amplification factor | read seek amplification factor
     | full-stripe      | single-chunk      | full-stripe (e.g.) | single-chunk
   0 | 1                | 1                 | n      to n;    12 | 1
   1 | 1                | 1                 | 1      to n;  1–12 | 1
   5 | 1                | 1                 | n - 1  to n; 11–12 | 1
   6 | 1                | 1                 | n - 2  to n; 10–12 | 1
*1+0 | 1                | 1                 | n₀     to n;  4–12 | 1           *
 1+5 | 1                | 1                 | n₅ - 1 to n;  5–12 | 1
*1+6 | 1                | 1                 | n₆ - 2 to n;  4–12 | 1           *

참고 : 'to n'은 동시에 발생하는 읽기가 하나 뿐인 경우 이론적으로 모든 드라이브를 동원하여 적절한 위치를 찾고 데이터를 전체적으로 읽을 수있어 최대 연속 읽기 처리량을 극대화 할 수 있기 때문입니다.

RAID | large contiguous read throughput | concurrent tiny reads throughput
     | full-stripe (e.g.)| single-chunk | full-stripe         | single-chunk
   0 | n×          ; 12× | n×     ; 12× | 1×          ;  1×   | n×     ; 12×
   1 | n×          ; 12× | n×     ; 12× | n×          ; 12×   | n×     ; 12×
   5 | n×          ; 12× | n×     ; 12× | n/(n - 1)×  ; ~1.1× | n×     ; 12×
   6 | n×          ; 12× | n×     ; 12× | n/(n - 2)×  ;  1.2× | n×     ; 12×
*1+0 | n×          ; 12× | n×     ; 12× | n₁×         ;  3×   | n×     ; 12×*
 1+5 | n×          ; 12× | n×     ; 12× | n/(n₅ - 1)× ;  2.4× | n×     ; 12×
*1+6 | n×          ; 12× | n×     ; 12× | n/(n₆ - 2)× ;  3×   | n×     ; 12×*

참고 : 적당한 청크 크기가 주어지면 중간 2 개의 처리량 열을 무시할 수 있습니다. 3 차 처리량 열은 중복 비율에 다시 밀접하게 연결됩니다.

그러나 청크 크기가 충분히 크면 작은 판독 값이 전체 스트라이핑되지 않습니다. 따라서 효율적인 구현과 적절한 청크 크기가 주어지면 읽기 성능이 저하되지 않을 때 동일한 드라이브 수에 비례해야합니다.

실제로 '증폭 계수'는 풀 스트라이프 처리량 증폭 만 고려 된 문제의 공식보다 훨씬 더 복잡합니다. 특히, 검색 바인딩 할 수있을 정도로 작은 동시 쓰기에 대한 6x2 RAID 1 + 6의 쓰기 성능은 4x3 RAID 1 + 0의 성능보다 떨어집니다. 그리고 모든 검색이 필요한 작은 쓰기의 경우 성능은 절대적으로 최고 4x3 RAID 1 + 0의 3 분의 1에 불과합니다 (즉, 완벽한 구현).

이 문제를 해결 한 12 드라이브 비교에는 완벽한 승자가 없습니다.

                                  | 4×3 RAID 1+0 | 6×2 RAID 1+6
   number of identical 1TB drives | 12           | 12
                 storage capacity | 4TB          | 4TB
            redundancy proportion | 2/3          | 2/3
large contiguous write throughput | 4×           | 4×
 large contiguous read throughput | 12×          | 12×
concurrent tiny writes throughput |*4×           | 1.5×
 concurrent tiny reads throughput | 12×          | 12×
safe number of random drive loses | 2            |*5
    12 - 1 large write throughput | 4×           | 4×
     12 - 1 large read throughput | 8×           |*11×
    12 - 1 tiny writes throughput |*4×           | ~1.42×
     12 - 1 tiny reads throughput | 8×           |*~9.33×
  can split-off a copy for backup | yes[1]       | yes[1]
                  2-site failover | yes          | yes
    2-copy large write throughput | 4×           | 4×
     2-copy large read throughput |*8×           | 6×
    2-copy tiny writes throughput |*4×           | ~1.28×
     2-copy tiny reads throughput |*8×           | 6×
   2-copy safe random drive loses | 1            |*2
2-copy - 1 large write throughput | 4×           | 4×
 2-copy - 1 large read throughput | 4×           |*5× or 6×[2]
2-copy - 1 tiny writes throughput |*4×           | ~1.46× or 1.2×[2]
 2-copy - 1 tiny reads throughput | 4×           |*3.6x or 6×[2]
can be divided into 3 full copies | yes          | yes
                  3-site failover | yes          | yes
    1-copy large write throughput | 4×           | 4×
     1-copy large read throughput | 4×           | 4×
    1-copy tiny writes throughput |*4×           | ~0.85×
     1-copy tiny reads throughput |*4×           | 2×
   1-copy safe random drive loses | 0            | 0
                       complexity |*simple       | more complex

참고 1 : 저장된 데이터의 전체 사본은 각각 RAID 0 4 배 또는 4/6 저하 된 RAID 6 어레이입니다. 참고 2 : 드라이브 장애가 4 개의 저하 된 RAID 1 쌍 중 하나를 오프라인으로 오프라인 상태로 만들거나 2 개의 정상 쌍 중 하나를 저하시킬 수있는 가능성이 있습니다.

그럼에도 불구하고, 6 개의 드라이브로 구성된 RAID 6 어레이의 읽기 성능은 두 배가되며 RAID 1 쌍간에 필요한 읽기가 나누어 져 있기 때문에 작은 쓰기 처리량은 25 % 향상 (1.5 / 1.2)해야합니다. 적절한 응용 프로그램이 있으므로 쓰기가 더 많거나 쓰기 성능보다 읽기 성능에 더 관심이있는 고 가용성 응용 프로그램 에서는 RAID 1 + 6에 대한 틈새 가 있을 수 있습니다 . 그러나 이것이 전부는 아닙니다 ...

복잡성

이것은 지금까지 이론에 불과하지만 (대개 조합론 ) 실제로는 복잡성으로 인해 RAID 1 + 6 구현에는 기회를 놓치고 이론적 결과를 달성하지 못하는 결함이있을 수 있습니다. RAID 6은 이미 더 복잡하며 중첩은 이보다 약간 더 복잡합니다.

예를 들어, 6 × 2 RAID 1 + 6은 4 × 3 RAID 1 + 0과 같이 각각 4 × 처리량으로 3 개의 연속 된 큰 판독 값을 동시에 읽을 수있는 3 개의 독립적 인 가상 판독 헤드를 갖는 것으로 추상화 될 수 있습니다. 소프트웨어 RAID를 사용하여 RAID 6 어레이에 6 개의 RAID 1 쌍을 중첩하는 것은 그렇게 우아하지 않을 수 있습니다. 구현은 어리 석고 스 래시 일 수 있습니다 (아직이 가설을 테스트하지는 않았습니다).

또한 복잡성으로 인해 구현 및 도구 개발 비용이 증가합니다. 이러한 중첩을 통해 이점을 얻을 수있는 응용 프로그램이있을 수 있지만 개선 비용으로 개발 비용이 들지 않을 수 있습니다.