최근에 나는 ECC가 아닌 RAM과 일반적인 파일 시스템을 사용하는 시스템의 손상률에 대한 몇 가지 놀라운 통계를 읽었습니다. 내가 Google에서 검색한 바에 따르면 ZFS를 실행하는 ECC RAM이 있는 시스템을 보유하는 것이 아마도 손상을 방지하는 가장 좋은 방법일 것입니다. 해당 정보의 대부분은 NAS 논의의 맥락에서 이루어졌습니다.
소스 시스템에서 파일이 아직 손상되지 않았고 네트워크를 통해 완벽하게 전송된다는 가정 하에 이러한 시스템을 사용하면 파일을 보관하는 데 얼마나 유용할지 알 수 있습니다.
제가 Google에서 검색할 수 없었던 것은 다음과 같습니다. 안정성이 떨어지는 컴퓨터에서 파일로 작업할 때 가장 안정적인 NAS 호스팅 파일(또는 백업)을 갖는 것이 무슨 의미가 있습니까? 또한 Samba(FreeNAS 또는 OpenIndiana와 같은 ZFS 지원 OS의 최신 버전이 무엇이든)의 오류 수정에 대한 좋은 정보를 찾을 수 없습니다. 오류가 발생하기 쉬운 경우 다른 거의 모든 것이 의미가 없습니다. 개인적으로 모든 것을 해시하고 모든 전송을 확인합니다).
비트 부패 등을 걱정하고 싶지 않다면 현재 시스템을 (비유적으로) 버리고 (미니) 서버급 하드웨어로 교체해야 합니까? 그리고 그 길을 간다면 ZFS 실행 이상의 리소스를 확보할 수 있다고 합리적으로 기대할 수 있습니까? 수천 달러를 쓰지 않고?
내 사용 사례:
나는 단순한 재생 이상의 것(예: 영화 및 기타 미디어)에 관심이 있습니다. 나는 집에 있는 컴퓨터로 프로그래밍 작업을 자주 합니다. 예를 들어, 다양한 프로젝트에 대한 SQLite 데이터베이스 파일 수가 점점 늘어나고 있습니다. 그 중 하나가 손상되면 문제가 될 수 있습니다. 또한 보관하고 싶을 뿐만 아니라 정리하고 태그도 달고 싶은 기가바이트급의 가족 사진과 휴가 사진이 있습니다. 그래서 은행을 운영하지 않더라도 대체하기 어렵고 생각하기도 싫은 것들이 있습니다. 그들은 "조용히 손상"되었습니다.
답변1
ZFS는 실행되는 하드웨어에 대해 매우 까다롭습니다.
정확히 맞는 칩셋, 그래픽 카드, 디스크 펌웨어 버전 등이 있어야 한다는 의미가 아니라 하드웨어가 제공하는 기능이라는 의미입니다. ZFS는 고급 서버 솔루션으로 설계되었으며 ZFS의 특정 가정은 이를 반영한다는 점을 기억하십시오.
ZFS가 관심 있는 데이터를 저장하는 데 탁월한 이유는 두 가지 모두를 감지할 수 있는 방식으로 ZFS를 설정할 수 있다는 것입니다.그리고 맞다보관상의 오류. 이는 어딘가에서 단일 비트 플립과 같은 사소한 오류일 수도 있고 여러 디스크가 동시에 충돌하는 것과 같은 치명적인 오류일 수도 있습니다. 스토리지 레이아웃의 중복 임계값(예: raidz2 vdev에서 동시에 문제가 발생하는 두 개 이하의 디스크) 이상을 유지하는 한 ZFS는 중복 데이터를 사용하여 모든 오류를 수정할 수 있습니다. 추가 오류는 발생 장소와 방법에 따라 (반) 정상적인 시스템 패닉이나 단순한 I/O 오류로 이어질 수 있습니다.
올바르게 수행하면 정기적으로 ZFS 풀을 스크러빙하도록 시스템을 설정하게 됩니다. 이렇게 하면 문제가 발생하기 전에 성능 저하를 포착하고 문제가 발생하기 전에 데이터를 유지하는 데 문제가 있는 저장 장치 교체를 고려할 수 있도록 이를 알려줍니다.
그러나 그 위대함은RAM을 신뢰할 수 있다는 사실에 달려 있습니다.이 모든 검증, 수정, 재작성 등은 주로 RAM에서 발생합니다. 고급 서버에서는 ECC RAM 외에는 아무것도 찾을 수 없습니다.
ZFS는 풀 메타데이터, 파일 시스템 메타데이터 및 사용자 데이터를 동일한 방식으로 보호하고 처리합니다.여기에는 실질적인 차이가 없습니다.
워크스테이션 시스템에서 RAM 비트 반전이 발생하는 경우 비트 반전된 데이터를 ZFS에 쓸 때 비트 반전된 데이터는 ZFS가 결국 디스크에 쓰는 내용의 기초가 됩니다. 이는 파일이 손상될 수 있음을 의미하므로 분명히 나쁜 것입니다. 그러나 비트 반전된 데이터는ZFS에 관한 한 정확합니다.. 이것은 실제로좋은, 이는 모든 일반적인 ZFS 복구 방법이 작동함을 의미하기 때문입니다. 예, 문제의 파일의 가장 최근 복사본이 손상되었지만어쨌든 부패했을 겁니다.어떤 파일 시스템을 사용하든 상관없습니다.ZFS의 스냅샷을 활용할 수 있습니다.최소한 손상되지 않은 복사본으로 시간을 되돌릴 수 있어야 합니다. 다음과 같은 것을 설정하십시오zfs-자동-스냅정기적으로 가까운 간격으로 파일 시스템의 스냅샷을 찍고, 뒤로 갈수록 대략적인 기록을 유지하고, 필요할 때까지 잊어버리십시오. (예를 들어, 10분 간격으로 10개의 스냅샷을 유지하고, 1시간 간격으로 50개의 스냅샷을 유지하고, 6시간 간격으로 30개의 스냅샷을 유지하는 등) 스냅샷은 ZFS에서 실질적으로 무료입니다. ZFS를 사용하는 경우스냅샷 사용또한.
ZFS를 실행하는 스토리지 서버에서 비트 뒤집기 또는 멈춤(1개 이상의 비트) 등 불량 RAM이 발생하고 스토리지 서버에 ECC RAM이 있는 경우 이는 감지되어 이벤트가 기록되거나 시스템에서 중지됩니다(오류를 수정할 수 없는 경우). 어느 쪽이든 서버에 저장된 데이터의 무결성은 유지됩니다. ZFS 저장소 서버에 비ECC RAM이 있는 경우그러면 모든 데이터와 메타데이터에 오류가 전파될 수 있습니다.ZFS는 실제로는 컴퓨터 상상의 산물일 뿐인 오류를 "수정"하려고 시도합니다. 최악의 시나리오로는,실제로 사람들에게 일어나는 일, 이로 인해 전체 풀이 손상되고 모든 데이터가 사라질 것입니다. 스토리지 수준/vdev 수준 중복성은 여기서도 도움이 되지 않습니다. 자동 수정 동작이 없는 대부분의 다른 파일 시스템에서는 비트 플립의 직접적인 영향을 받은 한 곳만 손상되며, 이러한 일이 발생하면 파일 시스템 메타데이터는 기존 파일 시스템 검사기 및 복구를 통해 쉽게 수정될 수 있습니다. 도구. ZFS에는 이러한 탈출구가 없습니다.fsck.zfs가 없습니다.(있다.zpool 스크럽, 그러나 수영장이 수리할 수 없을 정도로 파손된 경우에는 작동하지 않습니다.)
제가 Google에서 검색할 수 없었던 것은 다음과 같습니다. 안정성이 떨어지는 컴퓨터에서 파일로 작업할 때 가장 안정적인 NAS 호스팅 파일(또는 백업)을 갖는 것이 무슨 의미가 있습니까?
이는 신뢰할 수 있는 데이터 저장소가 있다는 것을 의미합니다.데이터가 NAS에 일단 전송되면 손상으로부터 안전하다는 것을 알고 계실 것입니다. 모든 손상은 자동으로 복구되거나 문제에 대한 정보를 받게 됩니다(ZFS의 경우 I/O 오류를 통해). 안정성이 떨어지는 시스템을 사용하여 작업하는 동안 데이터가 여전히 손상될 수 있지만 손상되지 않은 것으로 알려진 복사본을 찾을 수 있는 곳이 있습니다. 이는 NAS 시스템에만 ECC RAM, ZFS 및 고품질 스토리지 모니터링 및 경고 설정이 있는 경우에도 이점이 있습니다.
그런 다음 원하는 경우 예산이 허용하는 대로 다른 시스템에 (특히) ECC RAM을 추가하여 마지막 구멍을 막을 수 있습니다.
비트 부패 등을 걱정하고 싶지 않다면 현재 시스템을 (비유적으로) 버리고 (미니) 서버급 하드웨어로 교체해야 합니까? 그리고 그 길을 간다면 ZFS 실행 이상의 리소스를 확보할 수 있다고 합리적으로 기대할 수 있습니까? 수천 달러를 쓰지 않고?
첫째, 서버급 하드웨어가 실제로 필요하지 않습니다.필요한 것은 주로 ECC RAM(및 ECC RAM을 지원하는 CPU 및 메모리 컨트롤러/칩셋)입니다.합리적으로 신뢰할 수 있는 영구 스토리지, 이상적으로는 시스템이 실행되는 동안 디스크를 쉽게 추가하고 제거할 수 있는 케이스입니다. 이것은 매우 비쌀 필요도 없고 확실히 "수천 달러"의 비용이 들 필요도 없습니다.
둘째, ZFS는 RAM을 선호하지만 주로 캐싱에 사용됩니다. 대부분의 작업 부하에서는 8~16GB RAM이면 충분하며, 24~32GB("소비자" 마더보드에서도 쉽게 얻을 수 있음)는 고품질 브랜드 ECC RAM을 구입하는 경우에도 여전히 합리적인 가격입니다. ZFS는 CPU를 많이 소모하지 않습니다. 많은 CPU가 필요하도록 만들 수 있습니다(예:ZoL, sha256, gzip-9 압축 및 중복 제거를 함께 설정하여) 그러나 반드시 그럴 필요는 없습니다. 내 시스템은 ZFS를 실행하고 전력이 매우 높지 않으며(FX-6100 CPU 클럭 다운) 모든 곳에서 sha256을 사용하며 순차 I/O에서도 디스크가 제한 요소입니다. 스크럽의 무작위 읽기 부분을 사용하면 기본 스토리지 장치의 원시에서 수행하는 것과 거의 동일한 처리량을 얻을 수 있으며 ddCPU는 여유가 있습니다.
답변2
제가 Google에서 검색할 수 없었던 것은 다음과 같습니다. 안정성이 떨어지는 컴퓨터에서 파일로 작업할 때 가장 안정적인 NAS 호스팅 파일(또는 백업)을 갖는 것이 무슨 의미가 있습니까?
뭔가 잘못될 확률은 누적됩니다.
다시 말하면 (그리고 가짜 숫자로):
NAS에서 문제가 발생할 확률이 10%이고,
다른 장치에서 문제가 발생할 확률이 10%라면
다음과 같은 경우 실패할 확률은 20%입니다. NAS에서 무언가를 읽고 다른 장치에서 재생하는 것입니다.
또한 Samba의 오류 수정에 대한 좋은 정보를 찾을 수 없습니다.
삼바 버전. 프로토콜은 세 가지 버전 사이에서 상당히 변경되었습니다.
오류가 발생하기 쉬운 경우 다른 거의 모든 것은 의미가 없습니다(개인적으로 모든 것을 해시하고 모든 전송을 확인하지 않는 한).
항상 오류의 위험이 있습니다. 이것은 단순히 발생합니다. 그리고 그것들은 감지되고 수정됩니다(예: 체크섬을 통해). RAM을 사용할 때 이것이 항상 사실인 것은 아닙니다. 이는 패리티 및/또는 ECC를 사용하여 개선할 수 있는 사항입니다. 그러나 이러한 문제는 상대적으로 발생할 가능성이 낮으며 금도금(그리고 값비싼) 디자인과 "충분히 좋은" 디자인 사이의 균형을 찾아야 합니다.
이 균형은 우리 중 일부에게는 상당히 다를 것입니다(예: 은행에는 완벽하게 필요한 것이 있습니다). 아마도 영화를 재생하기 위한 개인 시스템에서 ECC를 사용하는 것을 보증하지 않을 것입니다.
답변3
연결:
Samba 웹사이트의 문서를 읽으려고 했지만 Samba에 오류 수정 기능이 있는지 확인할 수 없었습니다. 나는 최악의 경우, 즉 Samba가 오류가 없는 기본 네트워크에 의존한다는 가정을 해야 했습니다. 기본 네트워크가 TCP/IP인 경우 유일한 보호는 약한 체크섬인 것 같습니다.
CRC32C 알고리즘을 사용하는 선택적 헤더와 데이터 다이제스트를 지원하기 때문에 iSCSI를 선택하게 되었습니다. 이는 TCP/IP 검사 이상입니다.
어떤 이점이 있습니까?
나에게 대답은 "적어도 하나의 시나리오에서는 그렇습니다."입니다. 내가 신뢰하는 프로그램을 사용하여 서버급 ZFS 시스템에 파일을 백업할 수 있습니다. 그러면 주기적으로아마도원래 컴퓨터의 수정되지 않은 파일은실제로수정되지 않은. 불일치가 있으면 서버에서 백업을 복원할 수 있습니다.
유일한 약점은 신뢰할 수 없는 소비자급 컴퓨터에서 파일이 의도적으로 수정되는 경우입니다. 그 짧은 기간 동안에는 부패가 일어날 가능성이 매우 낮기 때문에 나는 그것이 허용된다고 생각합니다. 수정 중에 손상이 발생한 것을 발견하면 대체할 증분 백업을 갖게 됩니다.
내 컴퓨터를 ZFS를 실행할 만큼 강력한 서버로 교체하고 기본 컴퓨터로 사용할 리소스를 남겨두시겠습니까?
아마도 그럴 수도 있겠지만, 엄청나게 비쌀 것입니다. 위에서 설명한 시나리오에 만족하므로 이 작업을 시도하지 않겠습니다.