Data Domain: 정리 가능 크기는 추정치입니다.
Summary: Data Domain 시스템에 표시되는 "Cleanable GiB" 값과 정리 실행 시 복구될 공간의 양에 대해 잘못된 기대를 갖는 경우가 많습니다
Instructions
Data Domain 시스템에 표시되는 "Cleanable GiB" 값과 정리 실행 시 복구될 공간의 양에 대해 잘못된 기대를 하는 경우가 많습니다.
제공된 "Cleanable GiB" 수치는 순전히 추정치이며 Data Domain 파일 시스템을 개발할 때 선택한 기술적인 사항으로 인해 정리를 실행하여 복구되는 공간의 양에 대한 정확한 값을 얻을 수 없습니다.
다음은 정리 가능한 공간의 추정치가 복구된 실제 공간과 크게 다를 수 있는 이유에 대한 간결한 설명입니다. 그러나 여기에 설명되지 않은 다른 요인이 있으므로 정리 실행 시 실제로 확보되는 디스크 공간의 양과 추정치가 크게 다를 수 있습니다
Data Domain 시스템에서 데이터를 수집하면 압축 후 값이 계산되어 모든 파일에 대해 정적 데이터로 저장됩니다. "Cleanable" 값은 단순히 DD 정리가 마지막으로 실행된 이후 완료될 때까지 삭제된 모든 파일에 대한 압축 후 값의 합계입니다.
삭제된 파일의 파일 세그먼트가 삭제되지 않은 다른 파일의 데이터 중복 제거에 사용된 경우 정리 가능 값이 부정확해집니다. 기존의 고유 세그먼트를 참조하는 파일이 하나라도 있는 한 DD Clean 프로세스는 해당 세그먼트의 재확보를 고려하지 않습니다. 따라서 모든 고유 세그먼트가 폐기되는 것처럼 파일의 post-comp가 "Cleanable GiB" 카운터에 추가되더라도 일부(또는 다수)는 다른 파일에서 재사용되기 때문에 추가되지 않을 수 있습니다.
이 효과를 보여주는 자세한 예는 다음과 같습니다.
이전에 저장된 다른 데이터 없이 Data Domain 시스템에 5개의 파일이 하나씩 추가되었다고 가정합니다.
처음 100GB 파일에는 모든 고유 데이터가 포함되어 있으므로 압축률은 1배입니다(첫 번째 파일에 파일 자체 내에 중복성이 없다고 가정). 2번째-5번째 파일은 첫 번째 파일의 데이터와 추가되는 각 이전 파일에 대해 중복 제거할 수 있었으며, 중복을 제거할 파일이 증가함에 따라 중복 제거가 증가합니다.
File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x File 2: precomp: 100 GB postcomp: 50 GB compression ratio: 2x File 3: precomp: 100 GB postcomp: 25 GB compression ratio: 4x File 4: precomp: 100 GB postcomp: 25 GB compression ratio: 4x File 5: precomp: 100 GB postcomp: 1 GB compression ratio: 100x Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 500 - - - /backup: post-comp 1000 201 799 20% 0 ---------------- --------- --------- --------- ---- --------------
예 1. / backup에서 처음 3 개의 파일을 삭제 한 후 상태 :
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 200 - - - /backup: post-comp 1000 201 799 20% 175 ---------------- --------- --------- --------- ---- --------------
그 후에 정리를 실행하면 전체 175개의 정리 가능 대신 125개를 회수할 수 있습니다. 이는 마지막 2개의 파일이 파일 1-3과 세그먼트를 공유하기 때문입니다. 나머지 50GB의 공간은 해당 세그먼트가 파일 3-5에서 계속 사용 중이기 때문에 복구되지 않습니다.
예 2: 예제 1과 동일한 시작점을 사용하여 파일 1이 삭제된 다음 전체 /backup 폴더(즉, 5개 파일 모두)에서 fastcopy가 수행된 다음 파일 2-4가 삭제되었다고 가정합니다.
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 800 - - - /backup: post-comp 1000 201 799 20% 200 ---------------- --------- --------- --------- ---- --------------
사전 압축의 "Size GiB" 수치는 (500-100)=400*2=800이며, 원본 파일 5개에 대해 500을 제공하고 파일 1 삭제에 대해 100을 빼면 400GiB가 됩니다. 다음으로, 나머지 4개 파일 모두에 대한 fastcopy로 인해 400GiB에 2를 곱합니다.
filecopy는 원본 데이터에 대한 메타데이터 포인터로 구성된 극소량의 공간만 추가하기 때문에 사용되는 post-comp 공간은 여전히 동일합니다. (정리를 시작하기 위해) "filesys clean start"가 실행되지 않았기 때문에 파일 1을 삭제했음에도 불구하고 공간 사용량이 변경되지 않았습니다.
청소 후 다음을 볼 수 있습니다.
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- --------- --------- --------- ---- -------------- /backup: pre-comp - 800 - - - /backup: post-comp 1000 176 824 18% 0 ---------------- --------- --------- --------- ---- --------------
200GB가 정리 가능한 것으로 표시되었지만 실제로는 25GB만 정리되었습니다. 파일 1에서 4까지의 "post-comp" 파일 크기가 200GB까지 추가되어 "Cleanable GiB"가 200으로 표시되었습니다. 100GB인 "파일 1"만 제거되었지만 그 중 75GB는 다른 4개의 파일에서 여전히 사용 중이었습니다(중복 제거로 인해).
"파일 2"부터 "파일 4"까지도 삭제되었기 때문에 이상하게 보일 수 있지만 시스템에서 "파일 2"부터 "파일 4"까지 제거된 것으로 표시되지만 해당 파일의 실제 데이터 세그먼트는 해당 파일이 다른 폴더로 빠르게 복사되었기 때문에 제거할 수 없습니다. 모든 fastcopy 버전도 제거한 후에만 정리를 통해 공간을 완전히 복구할 수 있습니다.
정리 가능 GiB는 추정치일 뿐이므로 정확하지 않을 수 있습니다. 심지어 Data Domain의 물리적 용량과 크거나 같은 크기를 반영할 수도 있습니다.
이로 인해 Cleanable GiB가 "/data: post-comp"에 가깝거나 동일한 값을 표시하여 DDFS 공간 사용량이 100%에 근접한 경우 예약된 DDFS 정리를 실행하도록 허용할지 아니면 수동으로 실행할지 혼동될 수 있습니다.
실행 시 정리 공간이 회수되는 양을 예측하는 더 신뢰할 수 있는 더 나은 방법을 얻기 위해 DDOS 7.7.x부터는 이제 CLI에서 활성 계층의 다음 GC가 회수할 수 있는 실제 '총 정리 가능 공간'을 확인할 수 있습니다. 다음은 CLI를 요약한 것입니다.
# filesys cleanable-space calculate Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.
프로세스는 일반 GC와 동일하게 1-4단계를 거치지만 컨테이너를 효과적으로 전달하여 비활성 디스크 공간을 회수하는 5단계(복사)는 건너뜁니다. 따라서 일반 GC가 값을 반환하기 위해 1-4 단계를 완료하는 데 걸리는 시간만큼 오래 걸리므로 업데이트 된 추정치를 위해 정기적으로 실행하는 것이 아니라 필요할 때만 실행해야합니다. 즉, "filesys cleanable-space calculate"는 활성 계층에서 GC를 실행하여 공간을 회수하는 부분을 건너뜁니다.
프로세스는 다음과 같이 모니터링 할 수 있습니다.
# filesys cleanable-space watch Beginning 'filesys cleanable-space calculation' monitoring. Use Control-C to stop monitoring. Cleaning: phase 1 of 4 (pre-merge) 100.0% complete, 96233 GiB free; time: phase 0:02:07, total 0:02:07 Cleaning: phase 2 of 4 (pre-analysis) 100.0% complete, 96233 GiB free; time: phase 0:06:51, total 0:08:59 Cleaning: phase 3 of 4 (pre-enumeration) 100.0% complete, 96233 GiB free; time: phase 0:00:20, total 0:09:20 Cleaning: phase 4 of 4 (pre-select) 100.0% complete, 96233 GiB free; time: phase 0:00:25, total 0:09:46
완료되면 정리 가능한 측정 결과에 액세스할 수 있습니다.
# filesys cleanable-space status Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51 Cleanable space calculation finished at 2023/08/25 03:29:51.
여기 위의 테스트 예에서 DD GC를 지금 실행하면 94649698202바이트가 확보됩니다. 이는 88.1GiB이지만, 계산 당시 DD 사용 랩에서 "df"가 보고한 추정치는 41.9GiB였습니다. 물론 FS가 변경되면(새 백업, 추가 삭제, 스냅샷 생성 및 만료 등) 계산이 중단됩니다.
필요한 경우 아래 명령을 사용하여 위의 프로세스를 중지할 수 있습니다.
# filesys cleanable-space stop The 'filesys cleanable-space stop' command stops calculating cleanable space in the system. Are you sure? (yes|no) [no]: yes ok, proceeding. # filesys cleanable-space status Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05 Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19. Cleaning was aborted by user.
이 CLI는 DD 활성 계층에만 적용됩니다. 위에서 설명한 것과 동일한 불확실성을 조건으로 자체 추정치가 있는 DD 클라우드 유닛의 정리 가능 용량을 계산하는 동등한 프로세스는 없습니다.