LUKS 암호화 파티션 위에 ZFS를 사용하는 것과 ZFS의 기본 데이터 세트별 암호화를 사용하는 것에 대한 논의가 있었습니다. 그러나 항상 둘 중 하나 또는 둘 중 하나의 방식으로 표시됩니다.
제 질문은 LUKS 파티션을 생성한 다음 이를 zpool 컨테이너로 사용한 다음 해당 zpool에 ZFS 암호화 데이터 세트를 생성하는 두 가지 방법을 모두 사용하는 것에 관한 것입니다. 이는 메타데이터 유출 없이 저장 시 암호화를 제공하는 동시에 zfs send
암호화된 데이터 세트를 신뢰할 수 없는 백업 저장소에 저장하는 것과 같은 몇 가지 깔끔한 트릭을 허용해야 합니다.
이 경우 이 "이중 암호화"는 ZFS 기본 암호화와 비교하여 성능에 어떤 영향을 미치나요?
답변1
이에 대해 몇 가지 테스트를 수행했으므로 여기에 몇 가지 숫자가 있습니다. 이것은 내가 생각할 수 있는 첫 번째 측면에서 측정된다는 점을 명심하세요. 더 자세한 내용이 포함된 다른 답변을 원합니다.
모든 테스트는 32G RAM, 스왑 없음, 최소 ARC 크기 1G, 최대 ARC 크기 3G(영향을 받는 경우)를 사용하여 수행되었습니다.
FIO 사용
나는 이것을 시도했고 fio --refill_buffers --rw=randrw --name=test --size=5G --numjobs=5
보고된 헤더 번호는 다음과 같습니다:
ZFS 기본 데이터세트 암호화만 가능
READ: bw=25.6MiB/s (26.9MB/s), 5252KiB/s-5325KiB/s (5378kB/s-5453kB/s), io=12.5GiB (13.4GB), run=492550-499123msec
WRITE: bw=25.7MiB/s (26.9MB/s), 5252KiB/s-5320KiB/s (5378kB/s-5447kB/s), io=12.5GiB (13.4GB), run=492550-499123msec
LUKS 암호화 zpool의 ZFS 기본 데이터 세트 암호화
READ: bw=17.5MiB/s (18.4MB/s), 3589KiB/s-3619KiB/s (3676kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec
WRITE: bw=17.6MiB/s (18.4MB/s), 3596KiB/s-3619KiB/s (3682kB/s-3706kB/s), io=12.5GiB (13.4GB), run=724349-729360msec
따라서 FIO는 상당한 대역폭 차이를 보여줍니다. 하지만 실제 사용에 더 가까운 것을 시도하고 싶어서 소스에서 Glasgow Haskell Compiler 9.8.2 및 LLVM 0e5a53cc01e406436cb7c703c84598e474d635de를 컴파일해 보았습니다.
GHC 9.8.2 컴파일
Hadrian의 내장 프로파일링 도구를 사용하여 기본 설정과 32개의 스레드를 사용하여 새로운 빌드를 실행했습니다.
ZFS 전용
빌드 시간: 직렬 3시간 30분, 병렬 25분 21초. 가장 긴 단일 빌드 규칙 GHC/Hs/Instances.p_o
은 1분 23초입니다.
ZFS가 LUKS보다 낫습니다.
빌드 시간: 직렬 3시간 34분, 병렬 25분 16초. 가장 긴 단일 빌드 규칙 GHC/Hs/Instances.p_o
은 1분 23초입니다.
LLVM 컴파일
기본 플래그를 사용하여 Ninja 빌더는 18개의 컴파일 스레드와 2개의 링커 스레드를 사용합니다(메모리 부족을 방지하기 위해). Ninja에 프로파일링 지원이 있는지 모르므로 그냥 time
.
ZFS 전용
real 61m40.229s
user 542m57.056s
sys 49m29.346s
ZFS가 LUKS보다 낫습니다.
real 61m25.019s
user 542m51.777s
sys 48m58.462s
일부 무작위 SQLite 벤치마크
ZFS 전용
fillseq : 38.833 micros/op;
fillseqsync : 1391.493 micros/op;
fillseqbatch : 1.954 micros/op;
fillrandom : 62.420 micros/op;
fillrandsync : 1406.985 micros/op;
fillrandbatch : 36.149 micros/op;
overwrite : 84.639 micros/op; 1.3 MB/s
overwritebatch : 68.687 micros/op;
readrandom : 58.584 micros/op;
readseq : 42.483 micros/op;
fillrand100K : 867.440 micros/op; 1
fillseq100K : 851.599 micros/op; 11
readseq : 0.461 micros/op;
readrand100K : 99.846 micros/op;
ZFS가 LUKS보다 낫습니다.
fillseq : 38.453 micros/op;
fillseqsync : 1454.040 micros/op;
fillseqbatch : 2.035 micros/op;
fillrandom : 63.107 micros/op;
fillrandsync : 1531.823 micros/op;
fillrandbatch : 36.717 micros/op;
overwrite : 82.490 micros/op; 1.3 MB/s
overwritebatch : 68.175 micros/op;
readrandom : 46.421 micros/op;
readseq : 42.086 micros/op;
fillrand100K : 849.366 micros/op; 11
fillseq100K : 837.989 micros/op; 11
readseq : 0.461 micros/op;
readrand100K : 98.598 micros/op;
요컨대
FIO의 원시 IO 성능만 보면 상당한 격차가 있음을 알 수 있습니다. 읽기 및 쓰기 대역폭 모두 약 30% 감소한 것으로 보입니다. 그러나 인터리브된 IO 및 계산이 많이 포함되는 실제 사용에서는 차이가 본질적으로 사라집니다.