ZFS 데이터 손실 시나리오

지연되는 ZFS 풀 (150TB +)을 구축하려고합니다. 특히 하드웨어 장애로 인한 데이터 손실 시나리오에 대한 사람들의 경험을 듣고 싶습니다. 특히 일부 데이터 만 손실 된 인스턴스와 전체 파일 시스템 ( ZFS에 이러한 차이점이있는 경우).

예를 들어 외부 드라이브 인클로저의 전원 공급이 끊기거나 컨트롤러 카드가 고장 나서 vdev가 손실되었다고 가정 해 봅시다. 내가 읽은 것에서 풀은 오류 모드로 들어가야하지만 vdev가 반환되면 풀을 복구해야합니까? 또는 아닙니다? 또는 vdev가 부분적으로 손상된 경우 전체 풀, 일부 ​​파일 등이 손실됩니까?

ZIL 장치가 실패하면 어떻게됩니까? 아니면 여러 ZIL 중 하나입니까?

깊은 기술 지식으로 뒷받침되는 모든 일화 또는 가설 시나리오는 진심으로 감사합니다!

감사!

최신 정보:

우리는 소규모 비즈니스 (9 명 정도)이기 때문에 저렴한 가격으로이 작업을 수행하고 있지만 상당한 양의 이미징 데이터를 생성합니다.

내 데이터에 따르면 TB 당 약 500k 개의 파일이 주로 작은 파일입니다.

데이터는 중요하지만 중요하지는 않습니다. ZFS 풀을 사용하여 48TB "실시간"데이터 어레이 (3 년 정도 사용)를 미러링하고 나머지 스토리지는 '보관 된'데이터에 사용할 계획입니다.

풀은 NFS를 사용하여 공유됩니다.

랙은 아마도 건물 백업 발전기 라인에 있으며 5 분 정도 전 부하 상태에서 랙에 전원을 공급할 수있는 2 개의 APC UPS가 있습니다.

올바른 방식으로 설계하면 ZFS의 데이터 손실 가능성을 최소화 할 수 있습니다. 그러나 풀에 무엇을 저장하고 있는지 설명하지 않았습니다. 내 응용 프로그램에서는 주로 VMWare VMDK를 제공하고 iSCSI를 통해 zvol을 내보내고 있습니다. 150TB는 사소한 금액이 아니므로 전문가의 조언에 의지 할 것입니다.

ZFS로 데이터를 잃어버린 적이 없습니다.

나는 한 다른 모든 경험 :

• 12 개의 SSD 장애 (일부 L2ARC 의무 )
• 여러 개의 실패한 풀 디스크
• 니어 라인 SAS 디스크로 최종 교체해야하는 예기치 않은 SATA 드라이브 오류
• 잘못 구성된 중복 제거 노력으로 인한 낙진
• 안전 모드에서 손상되거나 결함이있는 zpool 복구
• 잘못된 10GbE NIC 포트 / 캐빈
• 빈번한 OS 충돌
• 번개 ...

그러나이 모든 것을 통해 눈에 띄는 데이터 손실은 없었습니다. 가동 중지 시간 VMWare VMDK가이 스토리지 위에 있으면 이벤트 후에 fsck 또는 재부팅이 종종 필요하지만 다른 서버 충돌보다 나쁘지 않습니다.

ZIL 장치 손실은 디자인, 저장 대상 및 I / O 및 쓰기 패턴에 따라 다릅니다. 내가 사용하는 ZIL 장치는 비교적 작으며 (4GB-8GB) 쓰기 캐시처럼 작동합니다. 어떤 사람들은 ZIL 장치를 미러링합니다. 고급 STEC SSD 장치를 사용하면 미러링 비용이 엄청납니다. 대신 단일 DDRDrive PCIe 카드를 사용합니다. 배터리 / UPS 보호 계획을 세우고 수퍼 커패시터 백업 (RAID 컨트롤러 BBWC 및 FBWC 구현과 유사)과 함께 SSD 또는 PCIe 카드를 사용하십시오 .

내 경험의 대부분은 Solaris / OpenSolaris와 NexentaStor 에 관한 것입니다. 사람들이 FreeBSD에서 ZFS를 사용한다는 것을 알고 있지만 zpool 버전과 다른 기능이 얼마나 뒤떨어져 있는지 잘 모르겠습니다. 순수한 스토리지 배포의 경우 Nexentastor 경로를 사용하고 경험이 풍부한 파트너 와 대화하는 것이 좋습니다. 이는 목적에 맞게 작성된 OS이며 FreeBSD보다 Solaris 파생물에서 실행되는 더 중요한 배포가 있기 때문입니다.

OpenSolaris의 마지막 버전에서 실수로 두 ZIL을 모두 덮어 써서 풀 전체를 잃을 수 없게되었습니다. (실제로 나쁜 실수입니다! ZIL을 잃는다는 것은 풀을 잃는다는 것을 이해하지 못했습니다. 운 좋게도 다운 타임으로 백업에서 복구했습니다.)

그러나 버전 151a (ZPool 버전의 의미를 알 수 없음) 이후이 문제가 해결되었습니다. 그리고 그것이 효과가 있다고 간증 할 수 있습니다.

그 외에는 사용자 오류, 다중 전원 장애, 디스크 오해 관리, 구성 오류, 디스크 오류 발생 등 몇 가지 추가 사례로 인해 20TB 서버에서 ZERO 데이터가 손실되었습니다. Solaris의 구성 인터페이스는 버전마다 빈번하게 변경되며 중요한 기술 목표를 제시하며 ZFS에 가장 적합한 옵션입니다.

ZFS에 대한 데이터를 잃지 않았을뿐만 아니라 (끔찍한 실수 이후) 지속적으로 나를 보호합니다. 더 이상 데이터 손상이 발생하지 않습니다. 지난 20 년 동안 서버와 워크 스테이션에서 저의 일로 인해 어려움을 겪었습니다. 데이터가 백업 회전을 롤오프 할 때 자동 (또는 "조용히 조용한") 데이터 손상으로 인해 여러 번 사망했지만 실제로 디스크에서 손상되었습니다. 또는 백업에서 손상된 버전을 백업 한 다른 시나리오. 이것은 한 번에 많은 양의 데이터를 잃어 버리는 것보다 훨씬 더 큰 문제로 거의 항상 백업됩니다. 이러한 이유 때문에 ZFS를 좋아하는데 왜 10 년 동안 체크섬 및 자동 복구가 파일 시스템의 표준 기능이 아닌지 이해할 수 없습니다. (진실하고 진실한 생명 또는 죽음의 시스템은 일반적으로 무결성을 보장하는 다른 방법을 가지고 있습니다.

현명한 말로, ACL 지옥으로 내려 가지 않으려면 ZFS에 내장 된 CIFS 서버를 사용하지 마십시오. 삼바를 사용하십시오. (NFS를 사용한다고 말했습니다.)

SAS와 SATA의 주장에 동의하지 않습니다. 적어도 ZFS의 경우 SAS가 항상 SATA보다 선호된다는 제안입니다. 그 의견 (들)이 플래터 회전 속도, 추정 된 신뢰성, 인터페이스 속도 또는 다른 속성 (들)을 참조하고 있는지 모르겠다. (또는 아마도 "그들은 더 비싸고 일반적으로 소비자가 사용하지 않기 때문에 더 우수합니다."최근에 발표 된 업계 설문 조사 (여전히 확실하다고 알려진 뉴스에서)는 SATA가 실제로 평균적으로 SAS보다 평균 수명보다 길다는 것을 보여주었습니다. 설문 조사의 중요한 표본 크기 (확실히 저에게 충격을주었습니다.) 그것이 "기업"버전의 SATA 또는 소비자인지 또는 어떤 속도인지 기억할 수는 없지만, 상당한 경험에서 엔터프라이즈 및 소비자 모델은 동일하게 실패합니다. 통계적으로 유의 한 비율. (실제 드라이브에서는 고장에 너무 오래 걸리는 소비자 용 드라이브의 문제가 있지만, 이는 기업에서 분명히 중요하지만, 물린 것은 아니며 전체를 차지할 수있는 하드웨어 컨트롤러와 관련이 있다고 생각합니다 SAS와 SATA의 문제는 아니며 ZFS는이 문제를 해결하지 못했으며, 그 결과, 1/3 엔터프라이즈와 2/3 소비자 SATA 드라이브를 함께 사용합니다. .) 또한 올바르게 구성된 경우 (예 : 3 방향 미러 스트라이프)이 SATA 혼합으로 성능이 크게 저하되지는 않았지만 매장 규모와 크기에 따라 IOPS 수요가 낮습니다. 일반적인 사용 사례, YMMV. 필자는 디스크 당 내장 캐시 크기가 유스 케이스에서 플래터 회전 속도보다 대기 시간 문제에 더 중요하다는 것을 분명히 알았습니다.

다시 말해 비용, 처리량, IOPS, 데이터 유형, 사용자 수, 관리 대역폭 및 일반적인 사용 사례와 같은 여러 매개 변수가 포함 된 봉투입니다. SAS가 항상 올바른 해결책이라고 말하는 것은 그러한 요소들의 순열의 넓은 세계를 무시하는 것입니다.

그러나 ZFS는 절대적으로 흔들립니다.