웹 서버에 권장되는 드라이브 구성

웹 서버에 권장되는 드라이브 구성

일반적인 웹 서버 드라이브 구성은 무엇입니까? 일반적으로 OS용 드라이브와 데이터용 드라이브가 있습니다. 데이터 드라이브는 일반적으로 RAID 5이지만 OS 드라이브에 대해 무엇을 권장했는지 기억이 나지 않습니다. RAID 1이 이에 이상적입니까?

답변1

저는 주요 호스팅 회사에서 일하고 있으며, 서버가 독립 실행형/로컬 스토리지를 사용한다고 가정할 때 엔터프라이즈 부문에서 가장 흔히 볼 수 있는 것은(반드시 권장하는 것은 아니지만 보이는 것) RAID 1 OS 어레이입니다. 및 RAID5 데이터 어레이.

이제 하드 드라이브가 커짐에 따라 단일 드라이브 재구축 중에 URE에 도달할 가능성이 매우 높기 때문에 RAID 5는 실제로 덜 이상적입니다.

그러나 OS 드라이브에 대해 구체적으로 묻는 것 같으므로 해당 드라이브에서 다른 앱을 실행하지 않는 한 RAID 1이 표준이며 일반적으로 충분합니다.

답변2

저는 데이터 센터를 운영하고 있으며 적절한 규모의 호스팅 운영을 위한 CTO입니다. 우리는 절대로 RAID 5를 사용하지 말 것을 강력히 촉구합니다.

가능하면 좋은 SAN을 사용하세요


RAID5는 스트라이프당 하나의 패리티 드라이브만 사용하며 많은 RAID5 어레이는 5개입니다(개수가 다른 경우 적절하게 계산을 조정). 드라이브(4개의 데이터와 1개의 패리티는 RAID 3에서와 같이 모든 패리티를 보유하는 단일 드라이브는 아님) & 4 그러나 계속 읽으십시오).

RAID 5는 낭비지만 RAID 10과 1도 마찬가지입니다. 10개의 드라이브가 있거나 200GB에 대해 각각 20GB라고 말하면 RAID5는 패리티에 20%를 사용하므로(두 개의 5개 드라이브 어레이로 설정했다고 가정) 160GB의 스토리지를 갖게 됩니다.

이제 미러링(RAID1)과 마찬가지로 RAID10은 중복성을 위해 50%를 사용하는 각 기본 드라이브에 대해 1개 이상의 미러 드라이브를 사용하므로 동일한 160GB의 스토리지를 얻으려면 8쌍 또는 16~20GB 드라이브가 필요합니다. RAID5가 왜 그렇게 인기가 있는지. 이 소개는 단지 상황을 관점에서 살펴보기 위한 것입니다.

RAID5는 물리적으로 RAID0과 같은 스트라이프 세트이지만 데이터 복구가 포함되어 있습니다. RAID5는 각 스트라이프 블록 중 하나의 디스크 블록을 패리티 데이터용으로 예약합니다. 패리티 블록에는 RAID5 블록의 모든 오류를 수정할 수 있는 오류 수정 코드가 포함되어 있습니다. 실제로 이는 나머지 데이터 블록과 함께 사용되어 드라이브 오류로 인해 누락된 단일 누락 블록을 다시 생성하는 데 사용됩니다. RAID3 및 RAID4에 대한 RAID5의 혁신은 패리티가 라운드 로빈 기반으로 분산되어 여러 드라이브에서 서로 다른 블록을 독립적으로 읽을 수 있다는 것입니다. 이것이 바로 모든 드라이브에서 동일한 블록을 동시에 읽어야 하는 RAID3 및 RAID4보다 RAID5가 더 널리 사용되는 이유입니다. 따라서 Drive2가 실패하면 블록 1,2,4,5,6 및 7은 이 드라이브의 데이터 블록이고 블록 3과 8은 이 드라이브의 패리티 블록입니다. 즉, 새 드라이브가 Drive2를 교체하기 전이나 새 Drive2 교체를 재구축하는 동안 블록 1이 요청되면 Drive5의 패리티가 Disk2에서 데이터 블록을 다시 생성하는 데 사용됩니다. 마찬가지로 Drive1의 패리티는 블록 2를 복구하는 데 사용되고 Drive3의 패리티는 블록4 등을 복구하는 데 사용됩니다. 블록 2의 경우 모든 데이터는 나머지 드라이브에 안전하게 보관되지만 Drive2 교체를 재구축하는 동안 새 패리티 블록은 다음에서 계산됩니다. 블록 2 데이터는 드라이브 2에 기록됩니다.

RAID 5 읽기-쓰기-페널티:이제 어레이에서 디스크 블록을 읽으면 RAID 소프트웨어/펌웨어는 어떤 RAID 블록에 디스크 블록이 포함되어 있는지, 어떤 드라이브에 디스크 블록이 있는지, 어떤 드라이브에 해당 RAID 블록에 대한 패리티 블록이 포함되어 있는지 계산하고 하나의 데이터 드라이브만 읽습니다. 데이터 블록을 반환합니다. 나중에 데이터 블록을 수정하면 이전 블록을 빼고 새 버전을 추가하여 패리티를 다시 계산한 다음 두 번의 별도 작업을 통해 데이터 블록과 새 패리티 블록을 기록합니다. 이렇게 하려면 먼저 해당 스트라이프 블록에 대한 패리티가 포함된 드라이브에서 패리티 블록을 읽어야 하며 원래 드라이브에서 업데이트된 블록에 대해 수정되지 않은 데이터를 다시 읽어야 합니다.이 읽기-읽기-쓰기-쓰기는 RAID5 쓰기 페널티로 알려져 있습니다. 이 두 쓰기는 순차적이고 동기식이므로 쓰기 시스템 호출은 안전을 위해 다시 읽기와 두 쓰기가 모두 완료될 때까지 반환할 수 없으므로 RAID5에 쓰기가 최대 50% 느려집니다. 동일한 용량의 어레이에 대해서는 RAID0보다 (일부 소프트웨어 RAID5는 원본 블록의 수정되지 않은 복사본을 메모리에 유지하여 다시 읽는 것을 방지합니다.)

RAID10은 가능한 RAID1(미러링)과 RAID0(스트라이핑)의 조합 중 하나입니다. RAID01 또는 RAID10의 의미에 대해 혼란이 있었고 RAID 공급업체마다 이를 다르게 정의했습니다. 약 5년 전쯤에 나는 정착된 것으로 보이는 다음과 같은 표준 언어를 제안했습니다. N개의 미러링된 쌍이 함께 스트라이프되는 경우 미러링(RAID1)이 스트라이핑(RAID0)보다 먼저 적용되므로 이를 RAID10이라고 합니다. 다른 옵션은 두 개의 스트라이프 세트를 생성하여 서로 미러링하는 것입니다. 이를 RAID01이라고 합니다(RAID0이 먼저 적용되기 때문입니다). RAID01 또는 RAID10 시스템에서 각각의 모든 디스크 블록은 해당 드라이브의 미러에 완전히 복제됩니다. 성능 측면에서 RAID01과 RAID10은 모두 기능적으로 동일합니다. RAID01은 RAID5에 영향을 미치는 반면 RAID10은 그렇지 않은 것과 동일한 문제를 겪는 복구 중에 차이점이 나타납니다.

이제 RAID5 어레이의 드라이브가 죽거나, 제거되거나, 종료된 경우, 존재하지 않는 드라이브가 해당 RAID에 대한 패리티 블록 드라이브가 아니라는 가정하에 나머지 드라이브에서 블록을 읽고 패리티를 사용하여 누락된 데이터를 계산하여 데이터가 반환됩니다. 차단하다. 5개 디스크 블록 중 4개에 대해 누락된 디스크 블록(5개 드라이브 배열의 경우)을 교체하려면 4번의 물리적 읽기가 필요하며 문제가 발견되고 새 드라이브를 매핑하여 시작할 수 있을 때까지 성능이 64% 저하됩니다. 회복. 교체 드라이브를 재구축하기 위해 모든 드라이브가 적극적으로 액세스되기 때문에 복구 중에 성능이 더욱 저하됩니다(아래 참조).

RAID10 어레이의 드라이브가 작동하지 않는 경우 손상된 쌍에서 두 개의 비연속 블록이 필요할 때 약간의 성능 저하(전체 4쌍 어레이의 경우 평균 6.25%)만 있는 단일 읽기의 미러 드라이브에서 데이터가 반환됩니다. (두 블록은 두 드라이브 모두에서 병렬로 읽을 수 없기 때문에) 그렇지 않으면 아무 것도 없습니다.

무슨 일이 일어나고 있는지, 내가 RAID5를 싫어하는 이유가 무엇인지 짐작하기 시작하지만 심야 정보 광고에서 말하는 것처럼 더 많은 것이 있습니다.

성능이 약간 부족한 것 외에 무엇이 문제인지 모르겠습니다.

자, 그러면 오늘의 마지막 질문인 RAID5의 문제점은 무엇입니까?로 이어집니다. 실패한 드라이브를 복구합니까? 따라서 쓰기 속도가 느려지고 걱정할 만큼 쓰기가 충분하지 않으며 캐시도 많은 도움이 됩니다. 캐시가 많이 있습니다! 문제는 최신 드라이브의 향상된 신뢰성과 대부분의 드라이브의 향상된 오류 정정 코드, 그리고 EMC가 모든 Clariion 드라이브 디스크 블록에 추가하는 8바이트의 오류 정정 기능에도 불구하고(운이 좋게도 EMC 시스템을 사용할 경우) ), 드라이브가 불안정해지고 쓰레기를 반환하기 시작할 가능성이 적습니다. 이를 부분 미디어 오류라고 합니다. 이제 SCSI 컨트롤러는 페이딩 섹터를 사용되지 않는 섹터로 교체하기 위해 다시 매핑할 수백 개의 디스크 블록을 예약합니다. 그러나 드라이브가 작동하는 경우 이러한 블록은 오래 지속되지 않고 고갈되며 SCSI는 수정 가능한 오류를 OS에 다시 보고하지 않습니다! 따라서 너무 늦어서 더 이상 교체 섹터가 없고 드라이브가 쓰레기를 반환하기 시작할 때까지 드라이브가 불안정해지고 있다는 사실을 알 수 없습니다. [최근 인기 있는 IDE/ATA 드라이브에는(TMK) 하드웨어에 불량 섹터 재매핑이 포함되어 있지 않으므로 가비지가 훨씬 빨리 반환됩니다.] 드라이브가 가비지를 반환하면 RAID5는 읽기 시 패리티를 확인하지 않기 때문에(RAID3 및 RAID4) BTW를 수행하고 둘 다 RAID5보다 데이터베이스 성능이 더 좋습니다) 가비지 섹터를 다시 쓰면 가비지 패리티가 계산되고 RAID5 무결성이 손실됩니다! 마찬가지로 드라이브에 오류가 발생하고 나머지 드라이브 중 하나가 불안정한 경우 교체품은 가비지로 재구축되어 문제를 하나가 아닌 두 블록에 전파합니다.

더 필요하신가요? 복구 중에는 RAID5 어레이의 읽기 성능이 80%까지 저하됩니다. 일부 고급 어레이를 사용하면 복구 또는 성능에 대한 기본 설정을 구성할 수 있습니다. 그러나 그렇게 하면 복구 시간이 늘어나고 복구가 완료되기 전에 어레이의 두 번째 드라이브가 손실되어 심각한 데이터 손실이 발생할 가능성이 높아집니다. 반면에 RAID10은 4개 이상의 쌍 중 하나의 드라이브만 복구하며 복구 쌍의 읽기 성능만 저하되어 어레이 전체 성능이 약 20%만 저하됩니다! 또한 복구 중에 패리티 계산 시간이 사용되지 않습니다. 이는 바로 데이터 복사본입니다.

두 번째 드라이브를 잃어버린 것은 어떻습니까? RAID10을 사용하면 복구 중인 하나의 미러도 실패하지 않는 한 위험이 없으며 이는 RAID5 어레이의 다른 드라이브가 실패할 가능성보다 80% 이상 낮습니다! 그리고 대부분의 여러 드라이브 오류는 감지되지 않은 제조 결함으로 인해 발생하므로 모든 드라이브를 다른 제조업체의 로트 번호에 있는 드라이브로 미러링하여 이러한 가능성을 아주 작게 만들 수 있습니다. ("오", 당신은 "이 시나리오는 그럴 것 같지 않다"고 말합니다. 푸우, 200개의 IBM 드라이브 배치가 실패하기 시작했을 때 우리는 2주 동안 50개의 드라이브를 잃었습니다. IBM은 단일 드라이브 로트에 스핀들 베어링이 있다는 것을 발견했습니다. 많은 시간의 작업 후 정지됨 다행스럽게도 부분적으로는 RAID10으로 인해 부분적으로는 2주에 걸친 DG 기술과 직원의 엄청난 노력으로 인해 데이터가 손실되지 않았습니다. 그러나 두 번째 드라이브가 실패한 후 하나의 RAID5 파일 시스템이 완전히 손실되었습니다. 복구하는 동안 다행히 모든 것이 테이프에 있었습니다.

결론? 안전과 성능을 위해 RAID10을 먼저, RAID3을 두 번째, RAID4를 세 번째, RAID5를 마지막으로 선호하세요! RAID2-5 사양의 원래 이유는 높은 디스크 비용으로 인해 RAID1, 미러링이 실용적이지 않기 때문입니다. 더 이상 그렇지 않습니다! 드라이브는 상품 가격으로 책정되며 가장 빠른 드라이브라도 당시 드라이브보다 절대적 비용이 더 저렴하며 MB당 비용은 예전에 비해 매우 작습니다. RAID5가 더 이상 의미가 있습니까? 분명히 나는 ​​그렇지 않다고 생각합니다.

상황을 고려해 보면 드라이브 가격이 US $1000(그리고 대부분이 그보다 훨씬 저렴함)인 경우 4쌍 RAID10 어레이에서 5드라이브 RAID5 어레이로 전환하면 드라이브 3개 또는 US $3000가 절약됩니다. 기술자, DBA, 관리자 및 복구에 대한 두려움이 있는 고객의 초과 근무, 마모 비용은 얼마입니까? 성능 저하와 고객 만족도 저하로 인한 비용은 얼마입니까? 마지막으로 데이터를 복구할 수 없는 경우 비즈니스 손실로 인한 비용은 얼마입니까?

BAARF 웹사이트에서 복사했지만 확실히 주목할 가치가 있습니다.

가능하다면 RAID 10을 사용하세요. 추가 디스크에 투자하세요.

답변3

응용 프로그램이 실행되지 않고 OS 파일만 호스팅한다고 가정하면 RAID 1이 완벽하게 적합해야 합니다.

OS 볼륨에서 추가 애플리케이션을 실행하는 경우 로드를 고려해야 합니다.

답변4

속도라면그리고신뢰성이 중요하므로 RAID0+1은 최대 2개의 드라이브 오류 생존 가능성을 통해 최고의 성능(계산할 패리티 없음)을 제공해야 합니다. 그러나 모든 컨트롤러가 이를 지원하는 것은 아닙니다.

관련 정보