면책 조항: 현재 다음 항목을 모두 백업할 수 있는 링크와 참조가 많지 않으며 광범위하게 테스트하지 않았습니다. 이것은 제가 ZFS에 대해 읽은 내용과 지난 5~7년 동안 ZFS가 어떻게 작동하는지, 그리고 제가 직접 수행한 일부 제한된 테스트(조정되지 않았지만 대부분 무작위 재부팅)에 대한 요약입니다.

또한 아래에 언급된 모든 내용은 치명적인 이벤트(완전한 서버 소진), 소프트웨어 버그(ZFS 및 기본 운영 체제 및 하드웨어 컨트롤러의 버그) 및 활성 악의(악성 관리, 관리 오류)를 고려하지 않습니다. 이러한 모든 상황에서도 정기적이고 복구 가능한 백업이 필요합니다!

---

미사용 데이터/디스크 일관성

다른 소프트웨어나 원격 연결로 인해 발생하는 버그나 긴 파일 전송을 조기에 중단하는 것에 대해서는 신경 쓰지 않습니다. 가능한 가장 빠른 방법으로 풀을 오프라인으로 전환하기를 원합니다. 이는 일관성을 유지하는 것과 일치합니다. 보류 중인 쓰기가 완료되고 풀이 데이터 일관성 상태가 된 후의 시간(초)을 제공합니다.

첫째, 좋은 소식: ZFS는 CoW 및 원자 트랜잭션을 사용하므로 갑작스러운 정전이 발생하더라도 기존 데이터는 안전합니다. 여기에는 풀 레이아웃과 메타데이터가 포함됩니다. 새 데이터가 완전히 기록될 때까지 이전 데이터는 이동되지 않으므로(사실 전혀 이동되지 않고 단지 재할당됨) 쓰기가 갑자기 중단되더라도 이 데이터는 위험하지 않습니다.

또한 체크섬(머클 해시 트리)은 다시 시작하는 동안 아무 문제도 발생하지 않았음을 증명하는 데 도움이 되며, 이는 풀을 정리하여 확인할 수 있습니다. 중복 vdev가 있는 경우 ZFS는 알려진 양호한 복제본에서 발견된 모든 오류를 자동으로 수정합니다. 일부 블록이 어떤 방식으로든 손상된 경우(예: 쓰기를 하지 않지만 쓰기를 주장하는 불량 디스크 컨트롤러에 의해) 해당 블록의 체크섬이 다른 vdev의 체크섬과 일치하지 않으며 오류가 표시됩니다.

비행/쓰기 모드의 데이터와 마지막 n초의 데이터가 손실됩니다.

동기식 및 비동기식 쓰기

일반적으로 ZFS는 회전 드라이브에 대한 값비싼 쓰기 속도를 높이기 위해 여러 트랜잭션을 수집합니다. 실제로 쓰는 것보다 HDD의 쓰기 헤드를 배치하는 데 더 많은 시간이 걸리므로 가능한 한 많이 대기열에 넣은 다음 순차적으로(더 빠르게) 써야 합니다! ) 주문(우리에게는 CoW가 있다는 것을 기억하세요. 여기서는 이것이 자연스러운 일입니다).

단점은 수집 시간이 길어질수록 응용 프로그램이 "쓰기 성공" 메시지를 기다려야 한다는 것입니다. 즉, 시스템이 몇 초 동안 잠길 수 없으며 이는 허용되지 않습니다. 더 나쁜 것은, 전원이 꺼지면 디스크에 기록하려고 했지만 아직 기록되지 않은 모든 데이터를 잃게 된다는 것입니다. 응용 프로그램이 이 문제에 대처할 수 없으면 응용 프로그램 계층 손상이 발생할 수 있습니다.

이 문제를 해결하기 위해 ZIL(ZFS Intent Log)이 추가되었습니다. 모든 동기화 트랜잭션은 이 로그에 수집됩니다(기본적으로 느린 풀 디스크에 저장되지만 SLOG 장치라고 하는 더 빠른 미러링 SSD에 저장될 수 있음). 저장 후 계속 수행할 수 있는 애플리케이션에 "쓰기 성공"이 반환됩니다. 해당 작업(더 이상 긴 잠금이 없음) 또한 모든 비동기 트랜잭션은 ZIL 없이 완료되므로 애플리케이션이 해당 데이터에 대해 올바른 쓰기 작업(동기 대 비동기)을 호출하는 한 속도가 더 빨라질 수 있습니다.

ZFS 속성

이제 더 흥미로운 부분이 나옵니다. 당신의 글은 어떻게 되나요? 여기에서 파일 시스템의 작동 모드를 식별해야 합니다(각 파일 시스템에 대해 개별적으로 설정할 수 있는 ZFS 등록 정보입니다). 세 가지 가능한 모드는 다음과 같습니다(맨페이지 참조).

sync=standard
  This is the default option. Synchronous file system transactions
  (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
  and then secondly all devices written are flushed to ensure
  the data is stable (not cached by device controllers).

sync=always
  For the ultra-cautious, every file system transaction is
  written and flushed to stable storage by a system call return.
  This obviously has a big performance penalty.

sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.

선택 하더라도 disabled풀 레이아웃/내부 일관성은 영향을 받지 않습니다. 마지막 5초의 데이터만 손실되고이것파일을 잘못된 상태로 만들 수 있습니다(예를 들어 동기 쓰기가 필요한 VM이 맨 위에 있지만 비동기 zvol만 백업 데이터 저장소로 제공했기 때문에).

반면에 지고 싶지 않다면아무것, 적어도 SLOG 장치의 경우 모든 파일 시스템을 always고성능 SSD로 설정하고 전환합니다(그렇지 않으면 대기 시간이 발생합니다).

standard절충안이며 가장 유연한 방식입니다. 애플리케이션 자체가 필요한 쓰기 모드를 결정합니다. 애플리케이션이 불량한 경우 데이터 손실이 발생할 수 있습니다. 성능이 좋으면 특정 보안 기준에 대해 최고의 성능을 얻을 수 있습니다.

풀 내보내기/가져오기:

~에서문서에 대한 zpool export:

이 명령은 계속하기 전에 풀에 마운트된 모든 파일 시스템을 마운트 해제하려고 시도합니다. 마운트 해제할 수 없는 파일 시스템이 있는 경우 -f 옵션을 사용하여 강제로 마운트 해제할 수 있습니다.

내보내기 시점에 기기를 사용할 수 없는 경우 해당 기기는 클린 내보내기로 인식되지 않습니다. 나중에 이러한 장치 중 하나가 작동하는 장치가 없는 시스템에 연결되면 "잠재적 활동"으로 표시됩니다.

풀에서 ZFS 볼륨을 사용 중인 경우 -f 옵션을 사용해도 풀을 내보낼 수 없습니다. ZFS 볼륨이 포함된 풀을 내보내려면 먼저 해당 볼륨의 모든 소비자가 더 이상 활성 상태가 아닌지 확인하십시오.

이는 대략 다음 세 가지를 의미합니다.

• -f활성 상태인 경우에도 모든 파일 시스템을 강제 마운트 해제하여 풀을 강제로 내보냅니다(잠금 또는 애플리케이션 쓰기에 관계없음).
• zvol이는 s 에는 적용되지 않습니다 .
• 풀을 분할하여 다른 시스템에서 사용하면 안 됩니다(조심하세요).장애 조치 상황)

요약:

• 디스크상의 일관성에만 관심이 있다면 export -f완전히 끄도록 선택할 수 있습니다.
• 모든 데이터에 관심이 있다면 sync=always빠른 SSD를 사용하세요
• iSCSI/NFS를 VM의 데이터 저장소로 생각하세요.이 개요도움이 될 수도 있습니다(발췌: 게스트/VM 호스트에서 NFS를 사용하거나 iSCSI 쓰기 저장 캐싱을 비활성화합니다. ZFS 스냅샷을 찍기 전에 VM을 정지합니다. 어쨌든 ZFS는 괜찮지만 게스트 VM은 지속적으로 충돌합니다)

---

댓글의 후속 질문에 대한 답변(유용한 답변이 없는 질문은 제외):

(1) "좋은 소식/COW" - 최상위 블록이 업데이트되려고 하면 어떻게 되나요? (메타데이터 트리의 약간 오래된 버전을 가리키는 경우에도) 항상 사용 가능한 최상위 블록을 찾습니다. 얼마나 나빠질 수 있습니까?

최악의 시나리오는 모든 중복 장치에서 슈퍼블록(다른 모든 블록 위에 있는 블록)이 손상되는 것입니다. 위에 블록이 없기 때문에 위에서 다시 빌드할 수 없으므로 각 슈퍼블록의 복사본이 여러 개(약 3~4개, IIRC) 존재하므로 하나가 손실될 수 있지만 대체 복사본이 여전히 존재합니다.

(2) TXG에 익숙하고 ESXi를 사용하고 있습니다. APC UPS + 우수한 PSU/하드웨어 + P3700 NVMe ZIL을 사용하므로 적절한 전력 + 빠른 ZIL을 갖습니다. 그러나 현재 쓰기가 모두 동기화될 가능성은 낮으며 말씀하신 대로 sync=always는 느립니다. 하지만 귀하의 답변을 통해 제가 몇 가지 성능 테스트를 수행할 수 있다는 생각이 촉발되었습니다. 저는 dedup(4배 절약, 그만한 가치가 있음)을 사용하고 있으므로 어쨌든 write=slow입니다(DDT를 찾아야 합니다). 그 이유는 sync=always가 DDT로 인해 느린 쓰기에만 영향을 미치기 때문입니다. 그러나 sync=always로 설정하면 매우 빠른 ZIL이 강제 적용되어 긴 TXG를 안전하게 만들어 디스크 액세스가 더 효율적일 수 있습니다. 아니면 지연을 없앨 수도 있습니다. 어느 쪽인지 모르겠어요! 어쩌면 그것을 시도해야 할 수도 있습니다!

저는 중복 제거에 대한 실제 경험이 없기 때문에 하드웨어(낮은 대기 시간, 높은 임의 64k 쓰기 IOPS, NVMe 인터페이스)를 잘 선택했다는 것 외에는 여기서 유용한 내용을 말할 수 없습니다. 매우 값비싼 영구 RAM 드라이브(ZeusRAM 외)에 투자하는 경우에만 속도가 더 빨라집니다.

(6) "디스크상의 일관성"은 ZFS가 충족되고 풀이 자체 일관성을 갖는다는 것을 의미합니까? 특정 파일/디렉토리에 대해 걱정하지 마십시오. 잘못된 콘텐츠로 끝나거나 풀이 이동/삭제되지 않고 갑자기 사라지거나 zvol의 NTFWS/VMFS와 같은 파일 시스템이 내부적으로 손상되었습니다(예: ZFS zvol이 되는 것은 괜찮지만 클라이언트 관점에서는 fsck/chkdsk가 필요함). ) (풀 제공) ZFS는 안전하고 일관성 있는 것으로 간주합니다.

예. 본질적으로 "내 풀은 망가지지 않았습니다!" 다중 사용자 설정에서는 한 사용자가 파일에 문제가 있어도 다른 사용자는 영향을 받지 않습니다.

(7) "충돌 일관성"이란 무슨 뜻인가요? (그렇다고 가정합니다.) - ZFS는 괜찮고 ZFS의 경우 풀도 괜찮지만 원격 클라이언트의 데이터가 클라이언트의 데이터와 다를 수 있습니다. 데이터가 난독화되었습니다. 갑작스러운 디스크 IO 오류가 발생하고 쓰기가 손실되는 클라이언트와 유사합니까? == 풀은 괜찮습니다. 다른 디스크 IO 오류나 시스템 충돌과 마찬가지로 클라이언트에 데이터가 손실되거나 일관성이 없으며 복구하는 데 도움이 필요할 수 있습니다.

예, 완전히 종료한 다음 스냅샷을 찍는 것이 아니라 기본적으로 VM을 강제 종료합니다. 나중에 전원을 켜 fsck거나 파일 시스템이 실행될 대상에 따라 유사한 경우 비정상 종료에 대해 불평할 수 있습니다. 이는 아무 일도 일어나지 않은 것처럼 정확한 시점에 복원되지만 게스트와의 상호 작용(게스트 추가 설치)이 필요하고 가상 머신의 가상 메모리를 포함하는 ESXi 스냅샷과 대조됩니다.

두 가지를 결합하여 이점을 얻을 수 있습니다. 먼저 ESXi 스냅샷을 만든 다음 데이터 저장소의 ZFS 스냅샷을 만듭니다(ESXi는 스냅샷을 가상 머신에 저장합니다). 그런 다음 ESXi 스냅샷을 삭제하고 ZFS 스냅샷은 유지합니다(블록 수준 복사본으로 인해 훨씬 ​​적은 공간을 차지함). 복원할 때 먼저 ZFS 스냅샷을 복원한 다음 (저장된) ESXi 스냅샷으로 복원한 다음 중단한 부분부터 다시 시작합니다. napp-it(웹 인터페이스를 갖춘 뛰어난 ZFS 관리 시스템)에는 이 개념이 내장되어 있습니다(적어도 NFS 데이터 저장소의 경우 iSCSI를 확인하지는 않았지만 유사하다고 가정합니다).