단일 8TB WD 드라이브에 약 6TB의 미디어 파일이 있는 서버가 있습니다.
질문을 하기 전에 몇 가지 배경 지식을 제공해야 할 것 같습니다.
파일은 몇 주 동안 BTRFS에 있었지만 관련 없는 하드웨어 문제와 후속 OS 재구축 후 실수로 디스크를 파괴하고 백업에서 파일을 복원해야 했기 때문에 이번을 기회로 ZFS 사용을 시도하기로 결정했습니다.
제가 zfs를 사용하고 싶은 주된 이유는 데이터 무결성을 유지하는 능력 때문입니다. btrfs(지금은 zfs)로 이동하기 전에는 ext4에 이러한 파일이 있었고 드라이브에서 비트 부패 문제가 발생한 후 조용히 손상된 파일이 많이 있었습니다.
따라서 데이터를 zfs에 다시 로드한 후 몇 주 동안 모든 것이 잘 작동했지만 오늘 아침까지 디스크가 무자비하게 휘핑되는 것을 발견했습니다.
약간의 조사 끝에 zfs가 어지러울 정도로 빠른 586K/s의 속도로 "스크러빙"하고 있음을 발견했습니다. 이 속도로는 절대 끝나지 않을 거예요!
이제 이 프로세스의 일부는 ZFS에 더 익숙해지는 것입니다. 따라서 여기서 뭔가 잘못 이해하고 있으면 알려 주시기 바랍니다. 그러나 전체 데이터 세트가 단일 물리적 저장소에 저장되므로 데이터 무결성을 위해 스크러빙이 필요하다고 생각합니다. 디스크?
이것이 맞다면 디스크를 더 구입하고 어떤 형태로든 raidz를 사용하면 위플래시 문제가 해결됩니까?
그렇다면 이 문제를 해결하는 가장 좋은 방법은 무엇입니까?
1) 2개의 4TB 디스크를 구입하고 비중복 스트라이핑을 사용하시겠습니까? (가장 저렴함)
2) 4TB 디스크 3개를 구입하고 중복 스트라이핑을 사용하시겠습니까? (더 비싼)
3) 두 번째 8TB 디스크를 구입하여 미러링하시겠습니까? (가장 비싼)
옵션 2와 3의 중복성(가용성)은 실제로 필요하지 않으며 디스크를 지속적으로 청소하지 않고 데이터(무결성)를 유지하는 데 더 관심이 있다는 점을 명심하세요.
시스템 세부 정보: intel i3 6100T 16Gb RAM 8TB WD Red Ubuntu 16.04(별도 SSD)
zfs 압축 및 중복 제거가 꺼졌습니다(처음에는 켜졌다가 나중에 꺼졌습니다)
읽어 주셔서 감사합니다
답변1
전체 데이터 세트가 단일 물리적 디스크에 저장되므로 데이터 무결성을 위해 스크러빙이 필요하다고 가정합니까?
ZFS 정리는 ZFS의 일반 파일 검사 메커니즘이 문제를 신속하게 감지할 수 있을 만큼 데이터 세트가 데이터 세트의 모든 중요한 파일에 자주 액세스하는 경우에만 필요합니다. 일주일에 한 번 정리하도록 선택했지만 일반적인 사용 패턴이 하루에 한 번 모든 중요한 데이터 블록을 읽거나 수정하는 경우 정리가 중복됩니다.
귀하와 같은 상황에서는 일부 파일에 수년 동안 액세스할 수 없을 수도 있지만 나중에는저기그들이 마침내하다정기적인 수술을 받는 것은 참으로 좋은 생각입니다.
이제 단일 디스크 풀에서 수행되는 모든 정리 작업은 손상된 블록이 있는 파일을 액세스할 수 없는 것으로 표시하는 것입니다. 맞습니다. ZFS가 해당 파일에서 단 하나의 비트 오류도 감지하면 전체 파일을 읽을 수 없도록 거부합니다. ZFS는 손상되지 않은 것으로 확인된 데이터만 전달합니다.
이것이 가능한 경우 일정량의 중복 저장소와 함께 ZFS를 사용하려는 이유입니다. ZFS에 사용할 미러를 제공하면 동일한 블록이둘 다동일한 결과를 얻으려면 거울을 파괴해야 합니다.
ZFS를 사용하면 단일 디스크 풀에서 이 상황을 수동으로 복구할 수 있습니다. 즉, 백업에서 파일을 복원할 수 있습니다. (유사한 체크섬이 있었으면 파일의 손상되지 않은 버전을 복구하고 있다는 것을 알 수 있었을 것입니다.) 왜냐하면 ZFS는쓰기 중 복사파일 시스템에서 복구된 파일은 사용되지 않는 데이터 블록에 저장되고 손상된 데이터 블록을 포함하여 이전 버전이 삭제됩니다.
디스크를 더 구입하고 일종의 raidz를 사용하면 경추 문제가 해결됩니까?
풀이 유휴 상태인 경우 정리하는 데는 전체 풀을 읽는 것과 거의 같은 시간이 걸립니다. 이렇게 큰 디스크의 경우 8~24시간이 걸릴 것으로 예상됩니다.
이보다 훨씬 오래 걸리는 경우 풀이 유휴 상태가 되어서는 안 됩니다. 만약 너라면아이디어풀이 유휴 상태인 경우 정리를 자주 중단하는 일부 백그라운드 작업이 있어 ZFS가 우선 순위가 낮은 백그라운드 정리 작업을 신속하게 완료하지 못할 수 있습니다.
나는 이것이 일종의 홈 미디어 서버라는 느낌을 받았기 때문에 이 실험을 시도해 보았습니다. 잠자리에 들기 전에 Scrub을 시작하고 단일 사용자 모드로 시스템을 종료한 후 다음 명령을 실행하십시오.
# watch -n 120 zpool status
스크럽에 걸리는 시간을 기록한 다음 잠자리에 드세요. N시간 자고 아침에 일어났을 때 예상 시간이 N시간 이상인지 이하인지 확인해보세요. 나는 그것이 N보다 훨씬 더 많이 다운될 것이라고 생각합니다. 이제 시스템은 해당 디스크를 정리하는 것 외에는 할 일이 거의 없기 때문입니다.
이 경우 다중 사용자 모드에서 실행 중인 백그라운드 프로세스가 ZFS를 계속 흔들어서 많은 유용한 작업을 수행하지 못하게 하는지 알아내야 합니다.
실제 질문에 대해서는 아니요. 더 많은 디스크를 구입한다고 해서 정리가 더 빨라지는 것은 아닙니다. 이는 단순히 ZFS에 데이터 손상 이벤트를 자동으로 복구할 수 있는 더 많은 기회를 제공합니다. 프로비저닝한 디스크 수에 관계없이 ZFS는 디스크를 정리하기 위해 디스크의 모든 데이터 블록을 읽어야 하며, 오늘날의 멀티테라바이트 디스크에서는 이 작업에 몇 시간이 걸립니다.
참고: 디스크를 추가하면 전체 풀의 MTBF도 감소하지만 이는 절충점입니다. 백업에 의존하는 것보다 오류를 복구하는 데 더 많은 비용이 들고 장기적으로 더 많은 비용이 듭니다. ZFS는 백업이 아니지만 중복 저장소를 통해 파일 백업으로 돌아가야 하는 횟수를 줄일 수 있습니다.
(백업은 실수로 인한 삭제, 맬웨어, 오프사이트 재해 복구 등 저장 매체 오류 그 이상으로부터 보호합니다. 백업에는 여전히 ZFS를 사용해야 합니다.)
2개의 4TB 디스크를 구입하고 비중복 스트라이핑을 사용하시겠습니까? (가장 저렴함)
이는 MTBF의 절반이며 속도 외에는 이점이 없습니다. 전체 풀을 잃을 여유가 있는 풀에서만 이 작업을 수행하십시오.
4TB 디스크 3개를 구입하고 중복 스트라이핑을 사용하시겠습니까? (더 비싼)
최신 멀티 테라바이트 풀에서 드라이브를 교체하는 데 몇 시간이 걸릴 수 있다는 점을 고려하면 최소한 이중 중복성을 사용하는 것이 좋습니다.4개디스크와 raidz2. 단순 양방향 미러의 경우 디스크 중 하나에 오류가 발생하면 불량 디스크를 직접 교체하여 복구하면 중복성이 없습니다. 또한 교체품이 도착할 때까지 기다리는 동안 여유 시간도 없습니다. (이미 교체품을 보유하고 있다면 백업용으로 풀에 보관하시겠습니까?옳은?)
한 가지 제한된 예외를 제외하고, 저장소 시스템에 사용 가능한 슬롯이 있는 경우 ZFS 미러링을 사용하면 N 방향 미러에 대체 항목을 추가하여 일시적으로 N+1 방향 미러로 만들 수 있습니다. 그런 다음 ZFS 재구축 프로세스에서는 불량 디스크의 양호한 블록을 확인하여 디스크의 불량 블록을 확인할 수 있습니다.생각하다나쁘지 않다. 그러나 이는 소프트 오류가 있는 디스크에서만 작동합니다. 디스크에 치명적인 오류가 발생하면 N-1 중복으로 돌아가고, N이 2이면 중복이 없습니다.
두 번째 8TB 디스크를 구입하여 미러링하시겠습니까? (가장 비싼)
세 가지 옵션 중 미러 그룹을 통해 ZFS 풀을 확장하는 것이 가장 쉬운 옵션이기 때문에 이것이 제가 선택한 옵션입니다. 3방향 미러로 쉽게 이동할 수 있는 옵션을 제공하는 반면, 전체 풀을 재구축하지 않으면 raidz1에서 raidz2로 이동하는 것이 불가능합니다.
옵션 2와 3(가용성)의 중복성은 실제로 필요하지 않으며 데이터 유지(무결성)에 더 관심이 있습니다.
백업에 대해 100% 확신하지 않는 한 이는 별 차이가 없는 것처럼 보일 수 있습니다. 백업을 획득한 후 백업이 약간 손상될 가능성이 있거나 복원해야 하는 파일의 백업이 없는 경우 사용할 수 없는 데이터의 남은 무결성은 0입니다.
솔직히 말해서 다른 중복 ZFS 풀을 사용하여 중복 ZFS 풀을 백업하는 것이 좋습니다. 그렇지 않으면 백업을 어떻게 신뢰할 수 있습니까?
예, 비싸집니다. 이제 컴퓨터에 8TB의 데이터를 연결할 것인지 결정해야 합니다.