이번 봄에 우리는 이미 몇 가지 소개 주제에 대해 논의했습니다. 드라이브 속도를 확인하는 방법 и RAID 란 무엇입니까?. 두 번째에서는 ZFS의 다양한 다중 디스크 토폴로지 성능을 계속 연구하겠다고 약속했습니다. 이는 현재 전세계 어디에서나 배포되고 있는 차세대 파일 시스템입니다. Apple 에 Ubuntu.

글쎄, 오늘은 호기심 많은 독자들인 ZFS에 대해 알아가기에 가장 좋은 날입니다. OpenZFS 개발자 Matt Ahrens의 겸손한 평가에서 "정말 어렵다"는 점만 알아 두십시오.

하지만 8디스크 ZFS 구성의 모든 변형에 대한 수치를 확인하기 전에(앞으로 그럴 것이라고 약속합니다), 다음 사항에 대해 이야기해야 합니다. как 일반적으로 ZFS는 데이터를 디스크에 저장합니다.

Zpool, vdev 및 장치

이 전체 풀 다이어그램에는 각 클래스마다 하나씩, 2개의 보조 vdev와 RAIDzXNUMX용 XNUMX개가 포함되어 있습니다.

일반적으로 일치하지 않는 vdev 유형 및 크기의 풀을 생성할 이유가 없습니다. 그러나 원한다면 그렇게 하는 것을 막을 수는 없습니다.

ZFS 파일 시스템을 실제로 이해하려면 실제 구조를 자세히 살펴봐야 합니다. 첫째, ZFS는 기존 볼륨 및 파일 시스템 관리 계층을 통합합니다. 둘째, 트랜잭션 쓰기 중 복사 메커니즘을 사용합니다. 이러한 기능은 시스템이 기존 파일 시스템 및 RAID 어레이와 구조적으로 매우 다르다는 것을 의미합니다. 이해해야 할 첫 번째 기본 빌딩 블록 세트는 스토리지 풀(zpool), 가상 장치(vdev) 및 실제 장치(device)입니다.

zpool

zpool 저장소 풀은 최상위 ZFS 구조입니다. 각 풀에는 하나 이상의 가상 장치가 포함되어 있습니다. 차례로, 각각은 하나 이상의 실제 장치(장치)를 포함합니다. 가상 풀은 독립적인 단위입니다. 하나의 물리적 컴퓨터에는 두 개 이상의 별도 풀이 포함될 수 있지만 각 풀은 서로 완전히 독립적입니다. 풀은 가상 장치를 공유할 수 없습니다.

ZFS 중복성은 풀 수준이 아닌 가상 장치 수준에 있습니다. 풀 수준에는 중복성이 전혀 없습니다. vdev 또는 전용 vdev가 손실되면 전체 풀도 함께 손실됩니다.

최신 스토리지 풀은 가상 장치의 캐시나 로그가 손실되더라도 살아남을 수 있습니다. 단, 정전이나 시스템 충돌로 인해 vdev 로그가 손실되면 소량의 더티 데이터가 손실될 수 있습니다.

ZFS "데이터 스트라이프"가 전체 풀에 걸쳐 기록된다는 일반적인 오해가 있습니다. 이것은 사실이 아닙니다. Zpool은 재미있는 RAID0이 아니라 더 재미있는 RAIDXNUMX입니다. JBOD 복잡한 가변 분배 메커니즘을 사용합니다.

대부분의 경우 레코드는 사용 가능한 여유 공간에 따라 사용 가능한 가상 장치에 배포되므로 이론적으로는 모두 동시에 채워집니다. 최신 버전의 ZFS는 현재 vdev 사용량(폐기)을 고려합니다. 한 가상 장치가 다른 가상 장치보다 사용량이 많은 경우(예: 읽기 로드로 인해) 여유 공간 비율이 가장 높음에도 불구하고 쓰기를 위해 일시적으로 건너뜁니다. .

최신 ZFS 쓰기 할당 방법에 내장된 재활용 감지 메커니즘은 비정상적으로 높은 로드 기간 동안 대기 시간을 줄이고 처리량을 늘릴 수 있지만 그렇지 않습니다. 백지 위임장 하나의 풀에서 느린 HDD와 빠른 SSD를 비자발적으로 혼합하는 것입니다. 이러한 불평등한 풀은 여전히 ​​가장 느린 장치의 속도로 작동합니다. 즉, 마치 전체가 그러한 장치로 구성된 것처럼 작동합니다.

vdev

각 스토리지 풀은 하나 이상의 가상 장치(vdev)로 구성됩니다. 결과적으로 각 vdev에는 하나 이상의 실제 장치가 포함됩니다. 대부분의 가상 장치는 간단한 데이터 저장에 사용되지만 CACHE, LOG 및 SPECIAL을 포함한 여러 vdev 도우미 클래스가 있습니다. 이러한 각 vdev 유형에는 단일 장치, RAIDz1, RAIDz2, RAIDz3 또는 미러의 XNUMX가지 토폴로지 중 하나가 있을 수 있습니다.

RAIDz1, RAIDz2 및 RAIDz3은 옛날 사람들이 이중(대각선) 패리티 RAID라고 부르는 특별한 종류입니다. 1, 2, 3은 각 데이터 레인에 할당된 패리티 블록 수를 나타냅니다. 패리티를 제공하기 위해 별도의 디스크를 사용하는 대신 가상 RAIDz 장치는 패리티를 디스크 전체에 반균등하게 배포합니다. RAIDz 어레이는 패리티 블록이 있는 만큼 많은 디스크를 잃을 수 있습니다. 다른 것을 잃으면 실패하고 스토리지 풀도 함께 가져갑니다.

미러 가상 장치(mirror vdev)에서 각 블록은 vdev의 각 장치에 저장됩니다. 2폭 미러가 가장 일반적이지만 미러에는 임의의 수의 장치를 포함할 수 있습니다. 대규모 설치에서는 읽기 성능과 내결함성을 향상시키기 위해 3중 미러가 자주 사용됩니다. vdev 미러는 vdev에 있는 하나 이상의 장치가 작동 상태로 유지되는 한 어떤 장애에서도 살아남을 수 있습니다.

단일 vdev는 본질적으로 위험합니다. 이러한 가상 장치는 단일 오류가 발생한 후에는 유지되지 않으며, 스토리지 또는 특수 vdev로 사용되는 경우 오류가 발생하면 전체 풀이 파괴됩니다. 여기서는 매우 조심하세요.

CACHE, LOG 및 SPECIAL 가상 장치는 위의 토폴로지에서 생성될 수 있습니다. 그러나 SPECIAL 가상 장치가 손실되면 풀이 손실된다는 점을 기억하십시오. 따라서 중복 토폴로지를 적극 권장합니다.

장치

이것은 아마도 ZFS에서 이해하기 가장 쉬운 용어일 것입니다. 문자 그대로 블록 랜덤 액세스 장치입니다. 가상 장치는 개별 장치로 구성되고 풀은 가상 장치로 구성된다는 점을 기억하세요.

자기 또는 솔리드 스테이트 디스크는 vdev의 빌딩 블록으로 사용되는 가장 일반적인 블록 장치입니다. 그러나 /dev에 설명자가 있는 모든 장치는 가능하므로 전체 하드웨어 RAID 배열을 별도의 장치로 사용할 수 있습니다.

간단한 원시 파일은 vdev를 구축할 수 있는 가장 중요한 대체 블록 장치 중 하나입니다. 테스트 풀 스파스 파일 풀 명령을 확인하고 특정 토폴로지의 풀이나 가상 장치에서 사용 가능한 공간을 확인하는 매우 편리한 방법입니다.

단 몇 초 만에 희소 파일에서 테스트 풀을 만들 수 있습니다. 하지만 나중에 전체 풀과 해당 구성 요소를 삭제하는 것을 잊지 마세요.

10개의 디스크로 구성된 서버를 원하고 9300TB(~2GiB) 디스크를 사용할 계획이지만 어떤 토폴로지가 요구 사항에 가장 적합한지 확신할 수 없다고 가정해 보겠습니다. 위의 예에서는 몇 초 만에 희소 파일에서 테스트 풀을 구축했습니다. 이제 우리는 10개의 50TB 디스크로 구성된 RAIDzXNUMX vdev가 XNUMXTiB의 사용 가능한 용량을 제공한다는 것을 알고 있습니다.

또 다른 특별한 종류의 장치는 SPARE입니다. 핫스왑 장치는 일반 장치와 달리 단일 가상 장치가 아닌 전체 풀에 속합니다. 풀의 vdev 중 하나에 오류가 발생하고 예비 장치가 풀에 연결되어 사용 가능한 경우 영향을 받은 vdev에 자동으로 연결됩니다.

영향을 받은 vdev에 연결되면 교체 장치는 누락된 장치에 있어야 하는 데이터의 복사본 또는 재구성을 받기 시작합니다. 기존 RAID에서는 이를 "재구축"이라고 하며 ZFS에서는 "리실버링"이라고 합니다.

교체 장치는 고장난 장치를 영구적으로 교체하지 않는다는 점에 유의하는 것이 중요합니다. 이는 vdev의 성능 저하에 걸리는 시간을 줄이기 위한 임시 교체일 뿐입니다. 관리자가 장애가 발생한 vdev 장치를 교체한 후 해당 영구 장치에 중복성이 복원되고 SPARE는 vdev에서 연결이 끊어지고 전체 풀에 대한 예비 장치로 돌아갑니다.

데이터 세트, 블록 및 섹터

ZFS 여정에서 이해해야 할 다음 구성 요소 세트는 하드웨어보다는 데이터 자체가 구성되고 저장되는 방식과 더 관련이 있습니다. 전체 구조에 대한 이해를 유지하면서 세부 사항이 복잡해지는 것을 방지하기 위해 여기서는 메타슬래브와 같은 몇 가지 레이어를 건너뛰었습니다.

데이터세트

데이터세트를 처음 생성하면 사용 가능한 풀 공간이 모두 표시됩니다. 그런 다음 할당량을 설정하고 마운트 지점을 변경합니다. 마법!

Zvol은 대부분 파일 시스템 계층이 제거된 데이터 세트일 뿐이며 여기서는 완전히 일반적인 ext4 파일 시스템으로 대체합니다.

ZFS 데이터 세트는 표준 마운트 파일 시스템과 거의 동일합니다. 일반 파일 시스템과 마찬가지로 언뜻 보면 "그냥 또 다른 폴더"처럼 보입니다. 그러나 일반 마운트된 파일 시스템과 마찬가지로 각 ZFS 데이터 세트에는 고유한 기본 등록 정보 세트가 있습니다.

우선, 데이터 세트에는 할당량이 할당되어 있을 수 있습니다. 설치하면 zfs set quota=100G poolname/datasetname, 그러면 마운트된 폴더에 쓸 수 없습니다. /poolname/datasetname 100GiB 이상.

각 줄의 시작 부분에 슬래시가 있거나 없는 것을 확인하셨나요? 각 데이터 세트는 ZFS 계층과 시스템 마운트 계층 모두에서 고유한 위치를 갖습니다. ZFS 계층 구조에는 앞에 슬래시가 없습니다. 풀 이름으로 시작한 다음 한 데이터 세트에서 다음 데이터 세트로의 경로를 지정합니다. 예를 들어, pool/parent/child 이름이 지정된 데이터 세트의 경우 child 상위 데이터 세트 아래 parent 광고 소재 이름이 있는 풀에 있음 pool.

기본적으로 데이터 세트의 마운트 지점은 ZFS 계층의 이름과 동일하며 앞에 슬래시가 붙습니다. pool 다음으로 마운트됨 /pool, 데이터 세트 parent 에 장착 /pool/parent및 하위 데이터 세트 child 에 장착 /pool/parent/child. 그러나 데이터 세트의 시스템 마운트 지점은 변경될 수 있습니다.

표기하면 zfs set mountpoint=/lol pool/parent/child, 데이터 세트 pool/parent/child 다음과 같이 시스템에 마운트되었습니다. /lol.

데이터 세트 외에도 볼륨(zvols)을 언급해야 합니다. 볼륨은 실제로 파일 시스템이 없고 단지 블록 장치라는 점을 제외하면 데이터 세트와 거의 동일합니다. 예를 들어 다음을 만들 수 있습니다. zvol 이름으로 mypool/myzvol, 그런 다음 ext4 파일 시스템으로 포맷하고 해당 파일 시스템을 마운트합니다. 이제 ext4 파일 시스템이 있지만 ZFS의 모든 보안 기능이 있습니다! 이는 한 컴퓨터에서는 어리석은 것처럼 보일 수 있지만 iSCSI 장치를 내보낼 때 백엔드로는 훨씬 더 의미가 있습니다.

블록

파일은 하나 이상의 블록으로 표시됩니다. 각 블록은 하나의 가상 장치에 저장됩니다. 블록 크기는 일반적으로 매개변수와 동일합니다. 기록 크기, 그러나 다음과 같이 줄일 수 있습니다. 2^ashift, 메타데이터나 작은 파일이 포함된 경우.

우리는 정말 정말로 변속을 너무 낮게 설정하면 성능이 크게 저하된다는 농담이 아닙니다.

ZFS 풀에서는 메타데이터를 포함한 모든 데이터가 블록에 저장됩니다. 각 데이터 세트의 최대 블록 크기는 속성에 정의되어 있습니다. recordsize (레코드 크기). 레코드 크기는 변경될 수 있지만 이미 데이터 세트에 기록된 블록의 크기나 위치는 변경되지 않습니다. 기록된 새 블록에만 영향을 미칩니다.

별도로 지정하지 않는 한 현재 기본 항목 크기는 128KiB입니다. 성능이 완벽하지는 않지만 대부분의 경우 끔찍하지는 않은 일종의 어려운 절충안입니다. Recordsize 4K에서 1M 사이의 값으로 설정할 수 있습니다(추가 설정 사용). recordsize 더 많이 설치할 수도 있지만 이는 좋은 생각이 아닌 경우가 많습니다.)

모든 블록은 단 하나의 파일 데이터만 참조합니다. 두 개의 서로 다른 파일을 하나의 블록으로 압축할 수는 없습니다. 각 파일은 크기에 따라 하나 이상의 블록으로 구성됩니다. 파일 크기가 레코드 크기보다 작은 경우 더 작은 블록에 저장됩니다. 예를 들어 2KiB 파일이 있는 블록은 디스크에서 4KiB 섹터 하나만 차지합니다.

파일이 여러 블록을 필요로 할 정도로 큰 경우 해당 파일의 모든 항목 크기는 다음과 같습니다. recordsize - 마지막 항목을 포함하여 주요 부분은 다음과 같습니다. 사용하지 않은 공간.

zvol 볼륨에는 속성이 없습니다. recordsize - 대신 그들은 동등한 속성을 가지고 있습니다. volblocksize.

분야

마지막으로 가장 기본적인 빌딩 블록은 섹터입니다. 호스트 장치에 쓰거나 읽을 수 있는 가장 작은 물리적 단위입니다. 수십 년 동안 대부분의 디스크는 512바이트 섹터를 사용했습니다. 요즘 대부분의 드라이브는 4KiB 섹터로 구성되며 일부, 특히 SSD는 8KiB 섹터 이상으로 구성됩니다.

ZFS에는 섹터 크기를 수동으로 설정할 수 있는 기능이 있습니다. 이 부동산 ashift. 다소 혼란스럽게도 ashift는 2의 거듭제곱입니다. 예를 들어, ashift=9 섹터 크기 2^9 또는 512바이트를 의미합니다.

ZFS는 새로운 vdev에 블록 장치가 추가될 때 운영 체제에 각 블록 장치에 대한 자세한 정보를 요청하고, 이론적으로는 이 정보를 기반으로 ashift 값을 자동으로 적절하게 설정합니다. 하지만 안타깝게도 많은 드라이브는 호환성을 유지하기 위해 섹터 크기를 속이는 경우가 많습니다. Windows XP(섹터 크기가 다른 드라이브를 인식할 수 없었던 운영체제).

즉, ZFS 관리자는 장치의 실제 섹터 크기를 알고 수동으로 설정하는 것이 좋습니다. ashift. ashift를 너무 작게 설정하면 읽기/쓰기 작업 횟수가 천문학적으로 증가합니다. 따라서 실제 512KiB 섹터에 4바이트 "섹터"를 쓰는 것은 첫 번째 "섹터"를 쓴 다음 4KiB 섹터를 읽고 두 번째 512바이트 "섹터"로 수정한 다음 새 섹터에 다시 써야 함을 의미합니다. 4 KiB 섹터 등 각 항목에 대해 계속됩니다.

현실 세계에서는 이러한 페널티가 적용되어야 하는 Samsung EVO SSD에 영향을 미칩니다. ashift=13, 그러나 이러한 SSD는 섹터 크기에 따라 결정되므로 기본값은 ashift=9. 숙련된 시스템 관리자가 이 설정을 변경하지 않는 한 이 SSD는 작동합니다. 느린 일반 자기 HDD.

비교하자면 너무 커서 ashift 사실상 페널티가 없습니다. 실제 성능 저하가 없으며 사용되지 않는 공간의 증가는 극히 미미합니다(압축이 활성화된 경우 512). 따라서 XNUMX바이트 섹터를 사용하는 드라이브라도 설치를 강력히 권장합니다. ashift=12 또는 ashift=13미래를 자신 있게 바라보는 것.

속성 ashift 각 가상 장치 vdev에 대해 설치됩니다. 수영장용이 아닌, 많은 사람들이 실수로 생각하는 것처럼 설치 후에도 변경되지 않습니다. 실수로 부딪힌 경우 ashift 풀에 새 vdev를 추가하면 해당 풀이 저성능 장치로 인해 영구적으로 오염된 것이므로 일반적으로 풀을 파괴하고 다시 시작하는 것 외에는 다른 옵션이 없습니다. vdev를 삭제해도 깨진 설정이 저장되지 않습니다. ashift!

기록 중 복사 메커니즘

일반 파일 시스템이 데이터를 다시 써야 하는 경우 해당 데이터가 있는 각 블록을 수정합니다.

쓰기 중 복사(Copy-On-Write) 파일 시스템은 블록의 새 버전을 쓴 다음 이전 버전의 잠금을 해제합니다.

추상적으로, 블록의 실제 물리적 배열을 무시하면 "데이터 혜성"은 사용 가능한 공간 맵을 가로질러 왼쪽에서 오른쪽으로 이동하는 "데이터 웜"으로 단순화됩니다.

이제 기록 중 복사 스냅샷이 어떻게 작동하는지 잘 알 수 있습니다. 각 블록은 여러 스냅샷에 속할 수 있으며 관련된 모든 스냅샷이 삭제될 때까지 지속됩니다.

CoW(Copy on Write) 메커니즘은 ZFS를 놀라운 시스템으로 만드는 기본 기반입니다. 기본 개념은 간단합니다. 기존 파일 시스템에 파일 변경을 요청하면 요청한 대로 정확하게 수행됩니다. Copy-On-Write 파일 시스템에 동일한 작업을 수행하도록 요청하면 "괜찮습니다"라고 대답하지만 거짓말을 할 것입니다.

대신, Copy-On-Write 파일 시스템은 수정된 블록의 새 버전을 작성한 다음 파일의 메타데이터를 업데이트하여 이전 블록의 링크를 해제하고 방금 작성한 새 블록과 연결합니다.

이전 블록 연결 해제와 새 블록 연결은 한 번의 작업으로 완료되므로 중단할 수 없습니다. 이 일이 발생한 후 전원을 재설정하면 파일의 새 버전이 있고, 이전에 전원을 재설정하면 이전 버전. 어떤 경우에도 파일 시스템에는 충돌이 발생하지 않습니다.

ZFS의 쓰기 중 복사는 파일 시스템 수준뿐만 아니라 디스크 관리 수준에서도 발생합니다. 이는 ZFS가 레코드의 공백에 영향을 받지 않음을 의미합니다(RAID의 구멍) - 시스템이 충돌하기 전에 스트립이 부분적으로만 기록되어 재부팅 후 어레이가 손상되는 현상입니다. 여기서 스트라이프는 원자적으로 작성되고 vdev는 항상 순차적이며 밥은 당신의 삼촌이에요.

ZIL: ZFS 의도 로그

ZFS는 동기식 쓰기를 특별한 방식으로 처리합니다. 즉, 일시적으로 저장하지만 즉시 ZIL에 저장한 후 나중에 비동기식 쓰기와 함께 영구적으로 쓰기 시작합니다.

일반적으로 ZIL에 기록된 데이터는 다시 읽혀지지 않습니다. 하지만 이는 시스템 장애 이후에도 가능합니다.

SLOG 또는 보조 LOG 장치는 ZIL을 주 저장소와 별도로 저장할 수 있는 특수한 vdev이며 바람직하게는 매우 빠른 vdev입니다.

충돌 후 ZIL의 모든 더티 데이터가 재생됩니다. 이 경우 ZIL은 SLOG에 있으므로 SLOG에서 재생됩니다.

쓰기에는 동기(sync)와 비동기(async)라는 두 가지 주요 범주가 있습니다. 대부분의 워크로드에서 대부분의 쓰기는 비동기식입니다. 파일 시스템을 사용하면 쓰기를 일괄적으로 집계하고 발행할 수 있으므로 조각화가 줄어들고 처리량이 크게 늘어납니다.

동기식 녹음은 완전히 다른 문제입니다. 애플리케이션이 동기 쓰기를 요청하면 파일 시스템에 "이를 비휘발성 메모리에 커밋해야 합니다. 지금 당장, 그리고 그때까지는 제가 더 이상 할 수 있는 일이 없습니다.” 따라서 동기식 쓰기는 즉시 디스크에 커밋되어야 하며 이로 인해 조각화가 증가하거나 처리량이 감소하는 경우에도 마찬가지입니다.

ZFS는 동기식 쓰기를 일반 파일 시스템과 다르게 처리합니다. 즉, 일반 저장소로 즉시 플러시하는 대신 ZFS는 이를 ZFS 의도 로그(ZIL)라는 특수 저장소 영역에 커밋합니다. 비결은 이 기록들이 또한 정상적인 비동기 쓰기 요청과 함께 집계되어 메모리에 남아 나중에 완전히 정상적인 TXG(트랜잭션 그룹)로 스토리지에 플러시됩니다.

정상 작동 중에는 ZIL이 기록되고 다시 읽혀지지 않습니다. 잠시 후 ZIL의 레코드가 RAM의 일반 TXG로 주 스토리지에 커밋되면 ZIL에서 분리됩니다. ZIL에서 무언가를 읽는 유일한 시간은 풀을 가져올 때입니다.

ZIL에 데이터가 있는 동안 운영 체제 충돌 또는 정전 등 ZFS 오류가 발생하면 해당 데이터는 다음 풀 가져오기 중에(예: 장애 조치 시스템이 다시 시작될 때) 읽혀집니다. ZIL에 있는 모든 내용을 읽고 TXG로 그룹화하고 기본 저장소에 커밋한 다음 가져오기 프로세스 중에 ZIL에서 분리합니다.

vdev 도우미 클래스 중 하나는 보조 LOG 장치인 LOG 또는 SLOG라고 합니다. 여기에는 하나의 작업이 있습니다. 즉, 기본 vdev 스토리지에 ZIL을 저장하는 대신 ZIL을 저장하기 위한 별도의, 바람직하게는 훨씬 더 빠르고 쓰기 저항이 매우 높은 vdev 장치를 풀에 제공하는 것입니다. ZIL 자체는 저장 위치에 관계없이 동일하게 작동하지만 LOG가 있는 vdev의 쓰기 성능이 매우 높으면 동기 쓰기가 더 빨라집니다.

LOG가 포함된 vdev를 풀에 추가하면 작동하지 않습니다. ~ 할 수 없다. 비동기 쓰기 성능 향상 - 모든 쓰기를 ZIL에 강제로 적용하더라도 zfs set sync=always, 로그가 없을 때와 동일한 방식과 속도로 TXG의 메인 스토리지에 계속 연결됩니다. 유일한 직접적인 성능 개선은 동기식 쓰기 대기 시간입니다(로그 속도가 높을수록 작업이 더 빨라짐). sync).

그러나 이미 동기식 쓰기가 많이 필요한 환경에서는 vdev LOG를 사용하여 비동기식 쓰기 및 캐시되지 않은 읽기 속도를 간접적으로 높일 수 있습니다. ZIL 레코드를 별도의 vdev LOG로 오프로드하면 기본 스토리지의 IOPS 경합이 줄어들어 모든 읽기 및 쓰기 성능이 어느 정도 향상됩니다.

스냅샷

쓰기 중 복사 메커니즘은 ZFS 원자 스냅샷 및 증분 비동기 복제에 필요한 기반이기도 합니다. 활성 파일 시스템에는 모든 항목에 현재 데이터를 표시하는 포인터 트리가 있습니다. 스냅샷을 찍을 때 이 포인터 트리의 복사본을 만들기만 하면 됩니다.

활성 파일 시스템에서 레코드를 덮어쓰면 ZFS는 먼저 사용되지 않은 공간에 블록의 새 버전을 씁니다. 그런 다음 현재 파일 시스템에서 이전 버전의 블록을 분리합니다. 그러나 일부 스냅샷이 이전 블록을 참조하는 경우 여전히 변경되지 않습니다. 이전 블록은 해당 블록을 참조하는 모든 스냅샷이 파괴될 때까지 실제로 여유 공간으로 복원되지 않습니다!

복제

2015년 내 Steam 라이브러리는 158GiB였으며 126개의 파일이 포함되어 있었습니다. 이는 rsync의 최적 상황에 매우 가깝습니다. 네트워크를 통한 ZFS 복제는 "단지" 927% 더 빨랐습니다.

동일 네트워크에서 40기가바이트 크기의 가상 머신 이미지 파일 하나를 복제합니다. Windows 7은 완전히 다른 이야기입니다. ZFS 복제는 rsync보다 289배 빠릅니다. 하지만 rsync에 --inplace 스위치를 붙여서 호출하면 "겨우" 161배 빨라집니다.

VM 이미지가 확장되면 rsync 문제도 함께 확장됩니다. 1,9TiB 크기는 최신 VM 이미지에서는 그다지 크지 않지만 rsync --inplace 인수를 사용하더라도 ZFS 복제가 rsync보다 1148배 더 빠를 만큼 충분히 큽니다.

스냅샷의 작동 방식을 이해하면 복제의 본질을 쉽게 파악할 수 있습니다. 스냅샷은 단순히 레코드 포인터의 트리이므로 다음과 같습니다. zfs send 스냅샷을 생성한 다음 이 트리와 이와 관련된 모든 레코드를 보냅니다. 우리가 이것을 통과할 때 zfs send в zfs receive 대상 객체에서는 블록의 실제 내용과 블록을 참조하는 포인터 트리를 대상 데이터 세트에 기록합니다.

두 번째로 상황이 더욱 흥미로워집니다. zfs send. 이제 우리는 두 개의 시스템을 갖게 되었는데, 각각은 다음을 포함합니다. poolname/datasetname@1, 새 스냅샷을 찍습니다. poolname/datasetname@2. 따라서 소스 풀에는 datasetname@1 и datasetname@2, 대상 풀에는 첫 번째 스냅샷만 있습니다. datasetname@1.

소스와 타겟 사이에 공통 스냅샷이 있기 때문입니다. datasetname@1, 우리는 할 수있다 증분 zfs send 그 위에. 우리가 시스템에 말할 때 zfs send -i poolname/datasetname@1 poolname/datasetname@2, 두 개의 포인터 트리를 비교합니다. 다음에만 존재하는 모든 포인터 @2, 분명히 새 블록을 참조하므로 해당 블록의 내용이 필요합니다.

원격 시스템에서 증분 처리 send 마찬가지로 간단합니다. 먼저 스트림에 포함된 모든 새 항목을 작성합니다. send를 누른 다음 이 블록에 포인터를 추가합니다. 짜잔, 우리는 @2 새로운 시스템에서!

ZFS 비동기 증분 복제는 rsync와 같은 스냅샷 기반이 아닌 이전 방법에 비해 크게 개선되었습니다. 두 경우 모두 변경된 데이터만 전송되지만 rsync가 먼저 전송되어야 합니다. 그 디스크에서 양쪽의 모든 데이터를 꺼내 합계를 확인하고 비교합니다. 대조적으로, ZFS 복제는 포인터 트리와 전체 스냅샷에 표시되지 않는 블록 이외의 어떤 것도 읽지 않습니다.

내장된 압축

기록 중 복사 메커니즘은 내장된 압축 시스템도 단순화합니다. 기존 파일 시스템에서는 압축에 문제가 있습니다. 변경된 데이터의 이전 버전과 새 버전이 모두 동일한 공간에 있습니다.

0x00000000 등의 256 메가바이트로 수명을 시작하는 파일 중간에 있는 데이터 조각을 고려하면 디스크의 단일 섹터로 압축하는 것이 매우 쉽습니다. 하지만 이 메가바이트의 4을 JPEG 또는 의사 무작위 노이즈와 같은 압축할 수 없는 메가바이트의 데이터로 대체하면 어떻게 될까요? 갑자기 해당 메가바이트의 데이터에는 하나가 아닌 XNUMX개의 XNUMXKiB 섹터가 필요하게 되었고 해당 디스크 공간에는 단 하나의 섹터만 예약되었습니다.

수정된 레코드는 항상 사용되지 않은 공간에 기록되기 때문에 ZFS에는 이 문제가 없습니다. 원래 블록은 4KiB 섹터 256개만 차지하고 새 쓰기는 XNUMX개를 차지하지만 이는 문제가 되지 않습니다. 파일의 "중간"은 크기 변경 여부에 관계없이 사용되지 않은 공간에 기록되므로 이는 ZFS의 완전히 정상적인 상황입니다.

내장된 ZFS 압축은 기본적으로 비활성화되어 있으며 시스템은 현재 LZ4, gzip(1-9), LZJB 및 ZLE를 포함한 플러그형 알고리즘을 제공합니다.

• LZ4 상당히 느린 CPU에서도 대부분의 사용 사례에 매우 빠른 압축 및 압축 해제와 성능 이점을 제공하는 스트리밍 알고리즘입니다.
• GZIP 모든 Unix 사용자가 알고 사랑하는 유서 깊은 알고리즘입니다. 압축 수준 1-9로 구현할 수 있으며 수준 9에 접근하면 압축 비율과 CPU 사용량이 증가합니다. 이 알고리즘은 모든 텍스트(또는 기타 압축률이 높은) 사용 사례에 적합하지만 그렇지 않은 경우 CPU 문제를 일으키는 경우가 많습니다. 사용하세요. 특히 높은 수준에서는 주의해야 합니다.
• LZJB - ZFS의 원래 알고리즘. 더 이상 사용되지 않으며 더 이상 사용해서는 안 됩니다. LZ4는 모든 면에서 우수합니다.
• ZLE — 제로 레벨 인코딩, 제로 레벨 인코딩. 일반 데이터는 전혀 건드리지 않지만 큰 4 시퀀스를 압축합니다. 압축할 수 없는 데이터를 무시하지만 결과 레코드에서 사용되지 않는 공간을 압축하므로 완전히 압축할 수 없는 데이터 세트(예: JPEG, MPXNUMX 또는 기타 이미 압축된 형식)에 유용합니다.

거의 모든 사용 사례에 LZ4 압축을 권장합니다. 압축할 수 없는 데이터를 처리할 때 성능 저하가 매우 작습니다. 이득 일반적인 데이터의 경우 성능 저하가 상당합니다. 새 운영 체제 설치를 위해 가상 머신 이미지를 복사하는 경우입니다. Windows (새로 설치된 운영체제이며, 아직 데이터가 없습니다.) compression=lz4 이전보다 27% 더 빠르게 통과했습니다. compression=none에 이 테스트는 2015년부터.

ARC - 적응형 교체 캐시

ZFS는 최근 읽은 블록의 복사본을 RAM에 저장하기 위해 운영 체제의 페이지 캐시에 의존하는 대신 자체 읽기 캐싱 메커니즘을 사용하는 유일한 최신 파일 시스템입니다.

기본 캐시에 문제가 없는 것은 아니지만 ZFS는 커널만큼 빠르게 새로운 메모리 할당 요청에 응답할 수 없으므로 새로운 호출이 malloc() 현재 ARC가 차지하는 RAM이 필요한 경우 메모리 할당이 실패할 수 있습니다. 그러나 적어도 현재로서는 자체 캐시를 사용해야 할 충분한 이유가 있습니다.

MacOS를 포함한 모든 최신 운영 체제는 Windows, Linux BSD 계열 운영체제는 LRU(최근 사용 빈도가 가장 낮은) 알고리즘을 사용하여 페이지 캐시를 구현합니다. 이 알고리즘은 캐시된 블록을 읽을 때마다 "큐의 맨 위로" 이동시키고, 필요에 따라 블록을 "큐의 맨 아래로" 이동시켜 캐시 미스(캐시가 아닌 디스크에서 읽어야 했던 블록)를 맨 위로 추가합니다.

일반적으로 알고리즘은 잘 작동하지만 대규모 작업 데이터 세트가 있는 시스템에서는 LRU가 쉽게 스래싱으로 이어집니다. 즉, 캐시에서 다시는 읽지 않을 블록을 위한 공간을 만들기 위해 자주 필요한 블록을 제거합니다.

ARC "가중치" 캐시로 간주될 수 있는 훨씬 덜 순진한 알고리즘입니다. 캐시된 블록을 읽을 때마다 조금 더 무거워지고 제거하기가 더 어려워집니다. 심지어 블록이 제거된 후에도 추적됨 일정 기간 동안. 제거되었지만 다시 캐시로 읽어야 하는 블록도 무거워집니다.

이 모든 것의 최종 결과는 적중률, 즉 캐시 적중(캐시에서 읽기)과 누락(디스크에서 읽기) 간의 비율이 훨씬 더 높은 캐시입니다. 이는 매우 중요한 통계입니다. 캐시 적중 자체가 훨씬 더 빠르게 처리될 뿐만 아니라, 캐시 적중도 더 빠르게 처리될 수 있습니다. 캐시 적중이 많을수록 디스크에 대한 병렬 요청이 줄어들고 나머지 미스에 대한 대기 시간이 짧아지기 때문입니다. 디스크로 서비스해야 합니다.

결론

이제 ZFS의 기본 의미(기록 중 복사 작동 방식, 저장소 풀, 가상 장치, 블록, 섹터 및 파일 간의 관계)를 다루었으므로 실제 성능에 대해 논의할 준비가 되었습니다. 실수.

다음 섹션에서는 미러링된 vdev와 RAIDz를 사용하는 풀의 실제 성능을 서로 비교하고, 기존 커널 RAID 토폴로지와도 비교해 보겠습니다. Linux우리가 연구한 것 이전.

처음에는 기본 사항(ZFS 토폴로지 자체)만 다루고 싶었지만 나중에는 그런 L2ARC, SLOG 및 특별 할당과 같은 보조 vdev 유형의 사용을 포함하여 ZFS의 고급 구성 및 조정에 대해 이야기할 준비가 되어 있습니다.

출처 : habr.com