집에 있는 Linux NAS의 모든 HDD를 재구성하려고 하며 데이터 보호와 어레이 재구성을 위한 유연성을 위해 mdadm raid를 사용하고 싶습니다. 하지만 mdadm을 사용하기 전에 어떻게 처리하는지 알고 싶습니다.비트 썩음. 특히, HDD에서 전송되는 복구 불가능한 읽기 오류 메시지를 유발하지 않는 비트 붕괴 유형입니다.
NAS와 다양한 견적에서 8개 디스크에 최소 21TB HDD를 사용할 것이라는 점을 고려하면개연성~의실패하다HDD에서는 단일 디스크 오류로 인한 재구축 중에 나머지 디스크에서 일종의 비트 손상이 발생할 가능성이 가장 높습니다. 드라이브 중 하나에서 복구할 수 없는 읽기 오류가 발생하고 해당 드라이브가 실제로 이를 오류로 보고하는 경우 raid6이 괜찮을 것이라고 생각합니다(맞습니까?). 하지만 디스크에서 읽은 데이터가 불량한데 디스크가 이를 그대로 보고하지 않는 경우, raid6을 사용해도 이를 자동으로 수정하는 방법을 모르겠습니다. 이것이 우리가 관심을 가져야 할 부분입니까? 기사를 보면2010년이고 RAID5는 여전히 작동합니다.집과 직장에서의 성공에 대한 내 자신의 경험뿐만 아니라 유행어나 마케팅에서 우리가 믿게 되는 것처럼 상황이 파멸적이고 암울할 필요는 없지만 하드 드라이브가 고장났다는 이유로 백업에서 복원해야 하는 것은 싫습니다.
사용 패턴이 최대 몇 번의 쓰기와 가끔 읽기라는 점을 고려하면 다음을 수행해야 합니다.데이터 정리. 나는 보았다 아치리눅스 위키 mdadm 명령데이터 정리다음과 같은 배열
echo check > /sys/block/md0/md/sync_action
그런 다음 진행 상황을 모니터링하세요.
cat /proc/mdstat
그것은 모든 디스크의 모든 섹터를 읽고 데이터가 패리티와 일치하는지 또는 그 반대인지 확인하는 것 같습니다. 일부 중요한 경우에는 "확인" 작업이 자동 수정이 불가능하고 감지만 가능하며 이를 직접 수정하는 것은 사용자의 몫이라는 점이 문서에서 매우 강조되어 있음을 알았습니다.
비트 손상으로부터 보호를 극대화하려면 어떤 mdadm RAID 레벨을 선택해야 하며, 어떤 유지 관리 및 기타 보호 단계를 수행해야 합니까? 이것이 나를 어떤 것으로부터도 보호해주지 않나요?
편집: ZFS 또는 다른 기술 QA로 RAID를 시작하고 싶지 않습니다. mdadm raid에 대해 구체적으로 알고 싶습니다. 이것이 내가 대신 Unix & Linux에 관해 질문한 이유이기도 합니다.뿌리.
편집: 대답은 다음과 같습니다mdadm은 데이터 스크러빙 중에 디스크 시스템에서 보고한 URE만 수정할 수 있고 스크러빙 중에 자동 비트 부패를 감지할 수 있지만 수정할 수 없거나 수정할 수 없습니까?
답변1
의견을 제시할 담당자가 충분하지 않지만 Linux의 mdadm 시스템은 오류를 수정하지 않는다는 점을 지적하고 싶었습니다. 스크러빙(예: RAID6) 중에 오류를 "수정"하도록 지시한 경우 불일치가 있으면 데이터가 부분적으로 정확하다고 가정하고 패리티를 다시 계산하여 오류를 "수정"합니다.
답변2
솔직히 말해서 귀하가 RAIDZ2 ZFS를 거부했다는 사실에 상당히 놀랐습니다. 거의 정확히 필요한 것 같습니다.와는 별개로리눅스 MD가 아니기 때문이죠. 나는 ZFS를 대중에게 알리는 데 전념하지 않지만 간단한 사실은 귀하의 문제가 ZFS의 설계 문제 중 하나라는 것입니다.처음부터 시작하세요해결하다. 중복성을 줄이거나 중복 없이 오류 감지 및 수정 기능을 제공하기 위해 RAID("일반" RAID)에 의존하는 것은 위험해 보입니다. ZFS가 실행되지 않는 경우에도옳은데이터 오류를 수정하세요. 최소한발각오류를 확인하고 문제가 있음을 알려 사용자가 수정 조치를 취할 수 있도록 합니다.
당신은하지 않습니다가지다권장되는 사항이지만 ZFS를 사용하여 정기적으로 전체 스크럽을 수행합니다. ZFS는 디스크에서 읽은 데이터가 데이터를 읽을 때 기록된 데이터와 일치하는지 확인하고, 일치하지 않으면 (a) 중복성을 사용하여 원본 데이터를 재구성하거나 (b) I/O 오류를 앱에 보고합니다. . 또한 정리는 우선순위가 낮은 온라인 작업으로, 대부분의 파일 시스템에서 우선순위가 높고 오프라인일 수 있는 파일 시스템 검사와는 상당히 다릅니다. 스크럽 프로그램을 실행 중이고 스크럽 프로그램 이외의 프로그램이 I/O를 수행하려는 경우 스크럽 프로그램은 이 시간 동안 뒷자리를 차지합니다. ZFS 스크러빙은 RAID 스크러빙을 대체합니다.그리고파일 시스템 메타데이터그리고 데이터무결성 검사는 비트 손상을 감지하기 위해 RAID 어레이를 청소하는 것보다 훨씬 더 철저합니다(이는 데이터가 의미가 있는지 알려주는 것이 아니라 RAID 컨트롤러에 의해 데이터가 올바르게 기록되었다는 것만 알 수 있습니다).
ZFS 중복성(RAIDZ, 미러링 등)의 장점은 스크러빙 중에 사용되지 않은 디스크 위치의 일관성을 확인할 필요가 없다는 것입니다. 도구가 할당 블록체인을 통과할 때 스크러빙 중에 실제 데이터만 확인됩니다. 이는 비중복 풀과 동일합니다. "일반" RAID를 사용하면 RAID 컨트롤러(하드웨어 또는 소프트웨어 여부)가 실제로 어떤 데이터가 관련되어 있는지 알 수 없기 때문에 모든 데이터(디스크에서 사용되지 않는 위치 포함)를 확인해야 합니다.
RAIDZ2 vdev를 사용하면 두 개의 드라이브가 중복되므로 다른 드라이브 장애로 인해 실제 데이터 손실이 발생하기 전에 두 개의 구성 드라이브에 장애가 발생할 수 있습니다. 이는 기본적으로 RAID6과 동일합니다.
ZFS에서는 모든 데이터(사용자 데이터 및 메타데이터)가 체크섬 처리되며(권장되지 않는 한) 이러한 체크섬은 데이터가 어떤 이유로든 변경되지 않았는지 확인하는 데 사용됩니다. 마찬가지로 체크섬이 예상 값과 일치하지 않으면 데이터가 투명하게 재구성되거나 I/O 오류가 보고됩니다. I/O 오류가 보고되거나 정리 작업에서 손상된 파일이 식별되면 파일의 데이터가 손상되었을 수 있으며 해당 특정 파일을 백업에서 복원할 수 있다는 것을 알게 됩니다. 전체 어레이 복구는 필요하지 않습니다.
일반 RAID 및 이중 패리티도 한 드라이브가 고장나고 다른 드라이브가 디스크에서 데이터를 잘못 읽는 것과 같은 상황으로부터 사용자를 보호하지 못합니다. 하나의 드라이브에 오류가 발생하고 다른 드라이브에서 단일 비트 반전이 발생한다고 가정해 보겠습니다. 갑자기 감지되지 않은 손상이 발생하고 만족스럽지 않은 경우 최소한 이를 감지할 수 있는 방법이 필요합니다. 이 위험을 완화하는 방법은 디스크에 있는 모든 블록의 체크섬을 확인하고 체크섬이 데이터와 함께 손상되지 않았는지 확인하는 것입니다(엉뚱한 쓰기, 고아 쓰기, 디스크의 잘못된 위치에 쓰기 등을 방지). 오류) 이는 체크섬이 활성화된 상태에서 ZFS가 수행하는 작업과 정확히 같습니다.
유일한 단점은 장치를 추가하여 RAIDZ vdev를 쉽게 확장할 수 없다는 것입니다.일반적으로 vdev의 장치로 스파스 파일을 포함하는 몇 가지 해결 방법이 있습니다.종종 "이것이 내 데이터라면 나는 이것을 하지 않을 것이다"라고 말합니다. 따라서 RAIDZ 경로(RAIDZ, RAIDZ2 또는 RAIDZ3 중 무엇을 선택하든)를 선택하는 경우 각 vdev에 필요한 드라이브 수를 미리 결정해야 합니다. vdev의 드라이브 수는 고정되어 있지만할 수 있는점진적으로(vdev의 중복성 임계값 내에서 유지) 드라이브를 더 큰 용량의 드라이브로 교체하고 전체 재동기화를 허용하여 vdev를 늘립니다.
답변3
이 답변은 제가 발견한 다양한 증거를 바탕으로 추론한 결과입니다. 저는 커널 개발자가 아니기 때문에 Linux 커널 구현이 어떻게 작동하는지 전혀 모르고, 의미 없는 오류 메시지가 많이 나타나는 것 같습니다. 나는 리눅스 커널이 현명한 선택을 했다고 생각한다. 내가 착각하지 않는 한 내 대답이 적용되어야합니다.
많은 드라이브는 ECC(Error Correcting Code)를 사용하여 읽기 오류를 감지합니다. 데이터가 손상된 경우 커널은 ECC 가능 드라이버로부터 해당 블록에 대한 URE(복구할 수 없는 읽기 오류)를 수신해야 합니다. 이러한 경우(아래 예외 제외) 좋은 데이터 위에 손상되었거나 비어 있는 데이터를 복사하는 것은 정신 나간 행위에 해당합니다. 이 경우 커널은 어떤 데이터가 좋은 데이터이고 어떤 데이터가 나쁜 데이터인지 알아야 합니다. ~에 따르면2010년인데 RAID5가 여전히 작동합니다...기사:
이 대안을 고려해 보십시오. 저는 이를 사용하는 어레이 공급업체가 최소한 몇 군데 있다는 것을 알고 있습니다. RAID 볼륨의 드라이브가 URE를 보고하면 어레이 컨트롤러는 개수를 늘리고 I/O를 충족시키기 위해 패리티가 있는 블록을 재구축합니다. 그런 다음 URE를 보고하는 디스크에 재작성(검증 포함)을 수행하고, 섹터가 손상된 경우 마이크로코드가 해당 섹터를 다시 매핑하고 모든 것이 정상이 될 것입니다.
그러나 이제 예외가 있습니다. 드라이브가 ECC를 지원하지 않거나, 드라이브에서 데이터 손상이 발생하거나, 펌웨어가 오작동하는 경우 URE가 보고되지 않고 손상된 데이터가 커널에 공급됩니다. 데이터 불일치의 경우: 2 디스크 RAID1 또는 RAID5를 사용하는 경우 성능이 저하되지 않은 상태에서도 패리티 블록이 하나만 있고 URE가 없기 때문에 커널은 어떤 데이터가 올바른지 알 방법이 없는 것 같습니다. 보고되었습니다. 3-디스크 RAID1 또는 RAID6에서 손상된 단일 비-URE 표시 블록은 중복 패리티(다른 관련 블록과 결합)와 일치하지 않으므로 적절한 자동 복구가 가능해야 합니다.
이야기의 교훈: ECC와 함께 드라이브를 사용하십시오. 불행하게도 ECC를 지원하는 모든 드라이브가 이 기능을 광고하는 것은 아닙니다. 반면에 주의하세요. 2디스크 RAID1(또는 2카피 RAID10)에서 값싼 SSD를 사용하는 사람들을 알고 있습니다. 드라이브 중 하나는 특정 섹터를 읽을 때마다 무작위로 손상된 데이터를 반환합니다. 손상된 데이터는 자동으로 복사되어 올바른 데이터가 됩니다. SSD가 ECC를 사용하고 제대로 작동하는 경우 커널은 적절한 수정 조치를 취해야 합니다.
답변4
원하는 보호를 얻으려면 2개 위치에서 RAID6 + 일반 오프사이트 백업을 사용하겠습니다.
그럼에도 불구하고 저는 개인적으로 데이터 중요성과 변화 속도에 따라 매일 밤, 매주, 매월 매주 정리 및 백업을 수행합니다.