저는 최근 데이터 중복성과 가용성을 위해 고급 파일 시스템(Btrfs, ZFS)을 조사했으며 이들이 제공하는 추가 기능, 특히 데이터 손상에 대한 "자가 치유" 기능에 관심을 갖게 되었습니다.
그러나 한 걸음 물러서서 일반 가정/SMB 사용에 대한 이러한 이점이 기존 mdadm-Raid1 + Ext4 솔루션. 미러링된 백업은 어느 쪽이든 사용할 수 있습니다.
보관 목적으로 사용되며 리소스가 제한되어 있지만 ECC 메모리와 안정적인 전원이 있는 두 개의 파일 서버가 있다고 가정해 보겠습니다.
- 파일을 읽을 수 없게 만드는 실제 데이터 손상이 발생할 가능성은 얼마나 됩니까? 어떻게?
- Ext4 또는 시스템 파일 관리자가 이미 복사/이동 작업 시 데이터 오류를 감지하여 최소한 문제를 인식할 수 있습니까?
- madam-Raid1 드라이브 중 하나가 불량 섹터가 있는 드라이브로 인해 다른 데이터를 보유하는 경우 어떻게 됩니까? 여전히 올바른 파일을 검색할 수 있습니까? 아니면 어레이에서 어떤 파일이 올바른지 결정할 수 없어 파일이 완전히 손실됩니까?
답변1
예, 기능적인 체크섬 파일 시스템은 매우 좋습니다. 그러나 진정한 동기는 신화적인 "비트로트"에서 찾을 수 없습니다.하다일어나는 일은 매우 드뭅니다. 오히려 가장 큰 장점은 이러한 파일 시스템이 다음을 제공한다는 것입니다.엔드투엔드 데이터 체크섬, 디스크 자체의 개인 DRAM 캐시 실패 및/또는 전원 공급 문제로 인한 오작동과 관련된 잘못된 쓰기 및 데이터 손상과 같은 잘못된 디스크 동작으로 사용자를 적극적으로 보호합니다.
나는 전원 공급 장치 문제로 인해 Linux RAID 1 어레이가 손상되었을 때 이 문제를 직접 경험했습니다. 한 디스크의 캐시가 데이터를 손상시키기 시작했고 디스크 섹터 자체에 내장된 ECC는 아무 것도 포착하지 못했습니다.이미 손상됐어ECC는 손상된 데이터 자체에 대해 계산되었습니다.
이상한 점을 감지하고 파일 시스템을 일시 중지하는 체크섬 저널 덕분에 XFS는 피해를 제한했습니다. 그러나 일부 파일/디렉토리는 복구할 수 없을 정도로 손상되었습니다. 이는 즉각적인 다운타임 부담이 없는 백업 머신이었기 때문에 ZFS로 다시 구축했습니다. 문제가 다시 발생했을 때 첫 번째 스크러빙 중에 ZFS는 다른 디스크에서 양호한 복사본을 읽어 영향을 받은 블록을 수정했습니다. 결과: 데이터 손실이 없고 가동 중지 시간도 없습니다. 체크섬 파일 시스템을 사용하는 두 가지 좋은 이유가 있습니다.
데이터 체크섬은 매우 중요하므로 장치 매퍼 대상에서 T-10 DIF/DIX 사양을 에뮬레이션하여 이를 제공합니다.DM-무결성는 이러한 보호 기능을 기존 블록 장치(특히 RAID1/5/6과 같은 중복 장치)로 확장하기 위해 정확하게 개발되었습니다. 의 덕택으로스트라티스 프로젝트, 종합 관리 CLI/API로 통합될 예정입니다.
그러나 그러한 파일 시스템이 가져오는 잠재적 이점은 상속받은 단점과 비교되어야 한다는 점이 있습니다. ZFS의 주요 문제는 표준 커널에 메인라인이 포함되어 있지 않다는 것입니다. 하지만 그 외에는 매우 빠르고 안정적입니다. 반면에 BTRFS는 주류를 이루면서,중요한 문제가 많다및 성능 문제(데이터베이스 또는 VM에 대한 일반적인 제안은 CoW를 비활성화하는 것입니다. 그러면 체크섬이 비활성화됩니다. 이는 솔직히 허용 가능한 대답이 아닙니다). BTRFS를 사용하는 대신 XFS를 사용하고 최선을 다하거나 dm 무결성 보호 장치를 사용하겠습니다.
답변2
zfs 스크럽을 실행할 때마다 체크섬이 실패하기 시작하는 Seagate HDD가 있었습니다. 몇 주 후에 실패했습니다. ZFS 및 Btrfs에는 데이터 및 메타데이터에 대한 체크섬이 있습니다. ext4에는 메타데이터 chcksum만 있습니다.
CRC 오류 및 메타데이터 체크섬 오류만 해당됩니다. 데이터 손상이 발생할 수 있습니다.
불량 섹터가 있으면 문제가 되지 않습니다. 전체 디스크는 "실패"하지만 다른 디스크는 "정상"입니다. 문제는 데이터에 올바른 CRC가 있지만 데이터가 손상된 경우입니다. 이는 대용량 디스크로 인해 무작위로 발생할 수 있습니다.
답변3
저는 6년 넘게 Linux와 FreeBSD를 사용하여 서버와 홈 오피스 NAS 모두에 프로덕션 환경에서 ZFS를 사용해 왔습니다. 나는 그것이 안정적이고 빠르며 신뢰할 수 있다는 것을 알았고 간단한 md장치나 ext4파일 시스템에서는 불가능했던 오류를 감지하고 (가능할 때) 수정하는 것을 개인적으로 보았습니다 .
그러나 한 걸음 물러서서 이 이점이 단점보다 더 큰지 이해하려고 노력해야 한다고 생각합니다(Btrfs 버그 및 해결되지 않은 문제 및 ZFS 가용성 및 성능 영향).
라이센스와 관련하여 ZFS는 오픈 소스이며 CDDL 라이센스에 따라 방금 출시되었습니다.합법적으로Linux 커널이 출시되는 GPLv2 라이센스와 호환됩니다.자세한 내용은 여기. 이는 "당분간 라이센스 불명예" 상태에 있다는 의미도 아니고, 아무런 문제가 없다는 의미도 아닙니다.인위적인비호환성. 이는 단순히 메인라인 Linux 커널 소스에 모듈이 없으며 다음과 같은 곳에서 검색해야 함을 의미합니다.https://zfsonlinux.org.데비안과 같은 일부 배포판에는 배포판에 ZFS가 포함되어 있습니다.Debian/Ubuntu에 ZFS를 설치하는 것은 일반적으로 단일 apt명령으로 수행할 수 있습니다.
성능에 관해서는 충분한 RAM이 주어지면 ZFS 성능은 메모리, 사용 가능한 풀 공간 및 데이터 압축성에 따라 ext4에 가깝거나 ext4를 능가하는 수준입니다. 내 생각에 ZFS의 가장 큰 단점은 메모리 사용량입니다. 프로덕션 서버의 RAM이 16GiB 미만인 경우 ZFS를 피하는 것이 좋습니다. 이는 지나치게 단순화된 경험 법칙입니다. ZFS의 메모리 요구 사항에 대한 많은 정보가 온라인에 있습니다. 저는 개인적으로 32GB RAM을 갖춘 홈 오피스 Linux 시스템에서 일부 백업 풀과 함께 10TB 풀과 800GB 풀을 실행하고 있으며 성능이 뛰어납니다. 이 서버또한LXC를 실행하고 여러 서비스가 실행 중입니다.
ZFS 기능은 데이터 체크섬 및 자가 복구 기능 그 이상입니다. 강력한 스냅샷은 LVM 스냅샷보다 훨씬 뛰어나며 인라인 lz4 압축은 실제로 디스크 쓰기를 줄여 성능을 향상시킬 수 있습니다. 저는 개인적으로 10TB 풀에서 1.55배의 비용 절감을 달성했습니다(단 6.3GiB의 디스크 공간에 9.76GiB의 데이터 저장).
내 경험에 따르면 풀 사용량이 75% 또는 80%에 도달하면 ZFS 성능이 저하됩니다. 해당 지점 이하로 유지되는 한 성능은 일반 가정/SMB 사용에 충분할 것입니다.
ZFS가 불량 데이터를 감지하고 수정하는 경우 근본 원인은 불분명하지만 불량 디스크 블록일 가능성이 높습니다. 저도 ECC 메모리가 있고 UPS를 사용하기 때문에 RAM의 데이터가 손상되었다고는 생각하지 않습니다. 실제로 ZFS 체크섬의 이점을 얻으려면 ECC RAM이 필요합니다. 그러나 나는 지난 6년 동안 체크섬에 실패한 소수의(~10-15) 블록 사례를 보았습니다.md RAID에 비해 ZFS의 주요 장점 중 하나는 ZFS가 체크섬 오류의 영향을 받는 파일을 알고 있다는 것입니다.. 따라서 중복성이 없는 백업 풀에 체크섬 오류가 있는 경우 ZFS는 나에게 다음과 같이 말했습니다.정확한영향을 받은 파일을 교체할 수 있습니다.
ZFS가 사용하는 라이센스는 Linux 커널과 호환되지 않지만 모듈 설치는 매우 쉽고(적어도 Debian에서는) 도구 세트에 익숙해지면 관리도 간단합니다. 많은 사람들이 인터넷에서 ZFS의 전체 데이터 손실에 대한 두려움을 언급하고 있음에도 불구하고 저는절대ZFS로 이동한 이후 모든 데이터가 손실되었으며 ZFS 스냅샷과 데이터 체크섬/중복성의 조합으로 인해 개인적으로 데이터 손실이 여러 번 발생하는 것을 방지했습니다. 이는 분명한 승리이며 개인적으로 결코 배열로 돌아가지 않을 것입니다 md.
답변4
ZFS는 그 기원(2001년에 Sun Microsystems에서 개발됨) 덕분에 놀라울 정도로 강력하다고 덧붙일 수 있습니다. 현재 사용 가능한 오픈 소스 버전은 약 10년 전 Sun Microsystems가 출시한 마지막 오픈 소스 버전 중 하나의 포크로, Oracle이 Sun Microsystems를 인수한 후 ZFS 소스를 폐쇄한 후 오픈 소스 커뮤니티에서 추가로 개발되었습니다.
Oracle 자체도 여전히 엔터프라이즈 스토리지 시스템에 사용되는 ZFS의 폐쇄 소스 버전을 유지 관리하고 있습니다.
ZFS에는 약간의 학습 곡선이 있습니다. 매우 강력하기 때문에 조정할 수 있는 부분이 상당히 많습니다. 또한 이는 유지 관리가 실제로 쉬운 몇 안 되는 스토리지 파일 시스템 중 하나입니다. 풀을 RAID5 설정에서 RAID6(더 정확하게는 RAID-Z1에서 RAID-Z2로)으로 마이그레이션해야 하는 경우가 있었습니다. 일반적으로 이와 같은 작업은 모든 데이터를 복사하고, RAID를 재구성하고, 데이터를 다시 복사하는 것을 의미합니다. ZFS에서는 보조 저장소를 연결하고 하나의 명령으로 풀을 복사하고 원하는 대로 어레이를 재구성합니다. , 다른 명령을 사용하여 풀을 다시 복사합니다.
하지만 몇 가지 문제가 있습니다.
- ZFS의 이점을 얻으려면 ZFS가 디스크 자체를 처리하도록 해야 합니다. 따라서 드라이브 컨트롤러는 JBOD를 지원해야 ZFS가 디스크를 직접 볼 수 있습니다. 모든 RAID 구성은 스크러빙 및 기타 작업에 패리티 데이터를 사용하므로 ZFS에서 처리되며 RAID 컨트롤러로 숨길 수 없습니다.
- 다른 사람들이 언급했듯이 ECC 메모리는권장. ZFS는 이를 요구하지 않지만 RAM에 기록된 모든 내용은 변경할 수 없으며 손상되지 않을 것으로 완전히 예상합니다. 따라서 ECC가 아닌 RAM이 있는 시스템에서 실행하고 메모리가 나빠지면 ZFS가 어레이를 스크러빙하는 동안 실제로 데이터가 손상될 수 있습니다. 스크러빙은 ZFS가 풀에서 데이터를 읽고 패리티에서 읽어야 할 내용을 계산한다는 의미입니다. 다른 드라이브에 저장된 정보를 확인하고 발견된 오류를 수정합니다.)
- ZFS는 데이터 손실 방지에 매우 탁월하지만 RAID-Z1은 여전히 RAID5(일명)와 동일한 문제를 겪고 있습니다. 드라이브 URE 비율이 너무 높으면 어레이를 재구축할 때 단일 디스크 오류 후 대형(1TB+) 드라이브의 대규모 어레이가 완전히 실패할 수 있습니다. 수학적으로 재구축하는 동안 나머지 드라이브의 패리티에서 모든 데이터를 다시 읽는 것만으로도 거의 보장되기 때문입니다. 드라이브 크기로 인한 복구 불가능한 읽기 오류. 스토리지 시스템 운영 전문가가 아니고 자신이 무엇을 하고 있는지 알고 있는 경우에는 RAID6/RAID-Z2를 실행하십시오.
저는 일반적으로 초보자와 가정 환경의 경우 FreeNAS를 추천합니다. 유지 관리가 매우 잘되고 설정이 간단하여 초보자에게 좋습니다.