찾기 시간

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

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의 예는 각각 4×3, 6×2, 6×2입니다.

전체 스트라이프 쓰기 처리량 증폭 계수 만 중복 비율과 직접 관련이 있습니다. 단일 청크 경우는 패리티가있는 경우에 더 복잡합니다. 단일 청크를 작성하려면 새 데이터 청크와 함께 패리티 청크를 작성하기 전에 패리티 청크 또는 다른 데이터 청크 중에서 가장 쉬운 것을 읽어야하기 때문에 발생합니다. (유도 된 읽기에 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 차 처리량 열은 중복 비율에 다시 밀접하게 연결됩니다.

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

실제로 ‘증폭 계수’는 풀 스트라이프 처리량 증폭 만 고려 된 문제의 공식보다 훨씬 더 복잡합니다. 특히, 검색 바인딩 할 수있을 정도로 작은 동시 쓰기에 대한 6×2 RAID 1 + 6의 쓰기 성능은 4×3 RAID 1 + 0의 성능보다 떨어집니다. 그리고 모든 검색이 필요한 작은 쓰기의 경우 성능은 절대적으로 최고 4×3 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 쌍을 중첩하는 것은 그렇게 우아하지 않을 수 있습니다. 구현은 어리 석고 스 래시 일 수 있습니다 (아직이 가설을 테스트하지는 않았습니다).

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

답변