DDR(Data Domain Restorer)의 파일 중복 제거 및 압축률 저하 문제 해결

DDR(Data Domain Restorer)은 물리적(압축 후) 디스크 공간을 최소화하여 대량의 논리적(사전 압축된) 데이터를 저장하도록 설계되었습니다. 이는 다음을 사용하여 달성됩니다.

• 수집된 데이터를 중복 제거하여 DDR의 디스크에 이미 저장된 중복된 데이터 청크를 제거하여 고유한 데이터만 남깁니다.
• 해당 데이터가 디스크에 물리적으로 기록되기 전에 고유한 데이터를 압축합니다.

DDR이 수집할 수 있는 데이터의 전체 압축률은 다음과 같은 여러 요인으로 인해 달라집니다.

• 활용 사례
• 수집 중인 데이터 유형
• 백업 애플리케이션 구성

최적으로 구성된 경우 DDR은 일반적으로 전체 압축률의 10~20배를 달성합니다(경우에 따라 이보다 높은 비율을 표시할 수 있음). 반대로 일부 환경에서는 전체 압축률이 이보다 낮을 수 있으며, 이로 인해 다음이 발생할 수 있습니다.

• 가용 용량을 빠르게 소진하는 DDR
• 백업, 복원 또는 복제 성능에 미치는 영향
• DDR이 고객의 기대치를 충족하지 못하는 경우

이 문서는 다음을 논의하기 위한 것입니다.

• DDR에서의 데이터 중복 제거 및 압축에 대한 간략한 개요
• 시스템 및 개별 파일의 전체 압축률을 확인하는 방법
• 전반적인 압축률 저하를 유발할 수 있는 요인

Data Domain Restorer는 어떻게 새 데이터를 수집합니까?

• 백업 애플리케이션은 DDR에 데이터(파일)를 전송합니다.
• DDR은 이러한 파일을 4~12Kb 크기의 청크로 분할합니다. 각 청크는 '세그먼트'로 표시됩니다.
• DDR은 세그먼트에 포함된 데이터에 따라 각 세그먼트에 대해 고유한 '지문'(체크섬과 유사)을 생성합니다.
• 새로 도착한 세그먼트의 지문은 DDR의 디스크 인덱스에 대해 검사하여 DDR이 이미 동일한 지문을 가진 세그먼트를 보유하고 있는지 확인합니다.
• DDR에 이미 동일한 지문이 있는 세그먼트가 있는 경우 새로 도착한 데이터의 해당 세그먼트가 중복되어 삭제될 수 있습니다(중복 제거됨).
• 새로 도착한 데이터에서 중복 세그먼트가 모두 제거되면 고유 세그먼트 또는 새 세그먼트만 남습니다.
• 이러한 고유하거나 새로운 세그먼트는 128Kb의 '압축 영역'으로 그룹화된 다음 압축됩니다(기본적으로 lz 알고리듬 사용).
• 압축 압축 영역은 '컨테이너'라고 하는 4.5Mb 스토리지 유닛으로 압축된 다음 하드 드라이브에 기록됩니다.

DDR은 특정 파일을 구성하는 세그먼트를 어떻게 추적합니까?

DDR은 새로 도착한 데이터의 중복 제거/압축 외에도 수집된 각 파일에 대해 '세그먼트 트리'를 생성합니다. 이 파일은 기본적으로 해당 파일을 구성하는 세그먼트 '지문' 목록입니다. DDR이 나중에 파일을 다시 읽어야 하는 경우 다음을 수행합니다.

• 파일 세그먼트 트리의 위치를 결정합니다.
• 세그먼트 트리를 읽고 읽을 파일 영역을 구성하는 모든 세그먼트 지문 목록을 가져옵니다.
• 디스크 인덱스를 사용하여 디스크에 있는 데이터의 물리적 위치(컨테이너)를 결정합니다.
• 디스크의 기본 컨테이너에서 물리적 세그먼트 데이터를 읽습니다.
• 물리적 세그먼트 데이터를 사용하여 파일을 재구성합니다.

또한 파일 세그먼트 트리는 디스크의 4.5Mb 컨테이너에 저장되며 대부분의 각 파일 '메타데이터'를 나타냅니다(이 문서의 후반부에서 설명).

DDR의 전체 압축률은 어떻게 확인할 수 있습니까?

DDR(및 압축률)의 전반적인 활용도는 'filesys show space' 명령을 사용하여 확인할 수 있습니다. 예: Active Tier:


Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 115367.8 - - -
/data: post-comp 67 94.2 6242.4 551.8 92% 202.5
/ddvar 49.2 9.1 37.6 20% -


---------------- -------- -------- --------- ---- -------------- 이 경우 다음을 확인할 수 있습니다.

• DDR에 저장된 사전 압축 또는 논리적 데이터: 115367.8Gb
• DDR에서 사용되는 압축 후 또는 물리적 공간: 6242.4Gb
• 전체 압축률은 115367.8/6242.4 = 18.48x입니다.

'filesys show compression' 명령의 출력은 저장된 데이터, 사용된 공간 및 압축 비율을 확인합니다. 예:

                   Pre-Comp Post-Comp Global-Comp Local-Comp GiB(Total-Comp
) (GiB) Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:*   115367.8 6242.4 - 18.5x(94.6) <=== 참고
작성:                                                                          
  지난 7일 42214.7 1863.2 11.0x 2.1x 22.7x(95.6)
  마지막 24시간 4924.8 274.0 8.8x 2.0x 18.0x(94.4)
---------------- -------- --------- ----------- ---------- -------------

DDR의 오버올 활용도 수치는 다음과 같이 계산됩니다.

• 압축 전 총 데이터: DDR이 보유한 모든 파일의 사전 압축(논리적) 크기의 합계입니다.
• 압축 후 총 데이터: 디스크에서 사용 중인 '컨테이너'의 개수는 4.5Mb(단일 컨테이너의 크기)를 곱한 것입니다.
• 총 압축 후 크기: 시스템에서 사용 가능한 디스크 공간을 지정하여 생성된 최대 '컨테이너' 수입니다.

사용 컨테이너의 최대값에 대한 통계는 자동 지원에서 사용할 수 있습니다. 예:

Container set 73fcacadea763b48:b66f6a65133e6c73:
...
    attrs.psize = 4718592 <=== 컨테이너 크기(바이트
)
    attrs.max_containers = 1546057 <=== 최대 가능한 컨테이너
attrs.free_containers = 125562 <=== 현재 사용 중인 컨테이너
attrs.used_containers = 1420495 <=== 현재 사용 중인 컨테이너
...

다음을 참조하십시오.
 
개별 파일, 디렉토리 또는 디렉토리 트리에 대한 중복 제거 및 압축 비율을 어떻게 확인할 수 있습니까?

파일을 수집할 때 DDR은 다음과 같은 파일에 대한 통계를 기록합니다.

• 사전 압축(논리적) 바이트
• 중복 제거 후 고유한 세그먼트의 크기
• 중복 제거 및 압축 후 고유한 세그먼트의 크기
• 파일의 메타데이터 크기(세그먼트 트리 등)

'filesys show compression [path]' 명령을 사용하여 이러한 통계 중 일부를 덤프할 수 있습니다. 예를 들어 단일 파일에 대한 통계를 보고할 수 있습니다.

SE@DDVE60_JF## filesys show compression /data/col1/backup/testfile
Total files: 1;  바이트/storage_used: 2.9
원래 바이트:        3,242,460,364
전 세계적으로 압축됨:        1,113,584,070
로컬 압축:        1,130,871,915
메타 데이터:            4,772,672

전체 디렉토리 트리에 대한 통계를 보고하려면 :SE@DDVE60_JF## filesys show compression /data/col1/backup
Total files:

3;  바이트/storage_used: 1.4
원래 바이트:        7,554,284,280
전 세계적으로 압축됨:        5,425,407,986
로컬 압축:        5,510,685,100
메타 데이터:           23,263,692

그러나 다음과 같은 통계를 사용하는 데 몇 가지 주의 사항이 있습니다.

• 이 통계는 파일 또는 데이터 수집 시 생성되며 이 다음에는 업데이트되지 않습니다. DDR의 작동 방식, 새 파일 수집 또는 동일한 데이터를 참조하는 파일 삭제 등으로 인해 시간이 지남에 따라 파일 중복 제거 방식이 변경되어 이러한 통계가 유효하지 않을 수 있습니다.
• 또한 DDR의 특정 활용 사례(예: 파일의 빠른 범위, 원래 파일 삭제)로 인해 이러한 통계가 잘못되거나 잘못될 수 있습니다.

따라서 이러한 수치는 추정치로만 간주되어야 합니다.

사전 압축된 바이트가 반드시 파일의 사전 압축/논리적 크기는 아닙니다. 대신, 파일에 기록된 총 바이트 수입니다. 따라서 기존 파일이 일반적으로 덮어쓰여지는 환경(예: 가상 테이프 라이브러리 기능 사용)에서 이 그림은 해당 파일의 논리적 크기보다 클 수 있습니다.

'품질이 낮은' 데이터를 수집하면 전체 압축률에서 저하가 발생할 수 있습니까?

예 - DDR이 수집된 데이터의 전반적인 압축률을 양호하게 달성하려면 해당 데이터를 중복 제거 및 압축할 수 있어야 합니다. 아래에 설명된 대로 이를 방지할 수 있는 다양한 유형의 데이터가 있습니다.

사전 압축/사전 암호화된 데이터:

클라이언트 시스템 또는 백업 애플리케이션에서 압축 또는 암호화되는 데이터 유형입니다. 여기에는 설계에 의해 압축 또는 암호화되는 애플리케이션별 파일(예: 미디어 파일) 및 미디어 파일과 같은 압축 또는 암호화 또는 내장된 바이너리 객체가 포함된 데이터베이스 파일도 포함될 수 있습니다.

압축 또는 암호화 알고리듬이 작동하는 방식 때문에 파일의 기본 데이터에 대한 비교적 작은 변경으로 인해 파일 전체에서 '파급 효과'가 변경됩니다. 예를 들어 클라이언트에는 10Kb가 수정되는 100Mb 암호화된 파일이 있을 수 있습니다. 일반적으로 결과 파일은 변경된 10Kb 섹션과는 별도로 수정 전과 후에 동일합니다. 암호화를 사용하는 경우 수정 전과 수정 후 암호화되지 않은 데이터의 10Kb만 변경되었지만 암호화 알고리듬으로 인해 파일의 전체 콘텐츠가 변경됩니다.

이러한 데이터가 정기적으로 수정되고 DDR로 주기적으로 전송되는 경우 이 '파급 효과'로 인해 파일의 각 세대는 동일한 파일의 이전 세대와 다르게 보입니다. 따라서 각 세대에는 고유한 세그먼트 세트(및 세그먼트 지문)가 포함되어 있어 중복 제거율이 낮은 것으로 표시됩니다.

또한 사전 압축된 파일 대신 lz 알고리듬이 구성 세그먼트 데이터를 더 압축할 수 없으므로 디스크에 쓰기 전에 데이터를 압축할 수 없습니다.

일반적인 지침 사전 압축/사전 암호화로 인해 다음이 발생합니다.

• 사전 암호화된 데이터: 중복 제거율이 좋지만 허용 가능한 압축률
• 사전 압축된 데이터: 낮은 중복 제거율 및 낮은 압축률

DDR에서 사전 압축/사전 암호화된 동일한 데이터를 여러 번 수집하면 압축 또는 암호화 알고리즘을 사용함에도 불구하고 각 백업 중에 유사한 세그먼트 세트(및 세그먼트 지문)가 표시되므로 데이터의 중복 제거 비율이 향상됩니다.

DDR로 전송될 수 있는 데이터는 암호화 또는 압축되어서는 안 됩니다. 따라서 최종 클라이언트 또는 해당 백업 애플리케이션 내에서 암호화 또는 압축을 비활성화해야 할 수 있습니다.

특정 백업, 클라이언트 애플리케이션 또는 운영 체제 내에서 암호화 또는 압축 설정을 확인, 수정하는 데 도움이 필요한 경우 해당 지원 공급업체에 문의하십시오.

미디어 파일:

특정 파일 형식에는 설계에 따라 사전 압축되거나 사전 암호화된 데이터가 포함되어 있습니다. 예:

• PDF 파일
• 특정 오디오 파일(mp3, wma, ogg 등)
• 비디오 파일(avi, mkv 등)
• 이미지 파일(png, bmp, jpeg 등)
• 애플리케이션별 파일(Microsoft Office, Open Office, Libre Office 등)

파일 내의 데이터는 파일의 코덱에 의해 압축 또는 암호화되므로 사전 압축되거나 사전 암호화된 데이터에 대해 위에서 설명한 대로 DDR에 수집할 때 동일한 문제가 발생합니다.

'고유성'이 높은 파일:

중복 제거율이 양호한 경우 동일한 세그먼트 세트(및 세그먼트 지문)를 여러 번 보는 DDR에 따라 달라집니다. 그러나 특정 데이터 유형에는 '고유한' 데이터가 포함된 고유한 트랜잭션 데이터만 포함되어 있습니다.

이러한 파일이 DDR로 전송되는 경우 백업의 각 세대에는 고유한 세그먼트 또는 세그먼트 지문 세트가 포함되어 있으므로 중복 제거율이 저하됩니다.

이러한 파일의 예는 다음과 같습니다.

• 데이터베이스 트랜잭션 로그(예: Oracle 아카이브 로그).
• Microsoft Exchange 트랜잭션 로그

DDR에 대한 '새' 클라이언트의 첫 번째 백업은 이 문제를 일으킬 수도 있습니다(DDR에서 이전에 데이터가 보이지 않았기 때문에 백업의 해당 세그먼트 또는 세그먼트 지문은 고유합니다). 그러나 시간이 지남에 따라 동일한 백업의 미래 세대가 DDR로 전송됨에 따라 각 새 백업의 세그먼트 수가 줄어들면서 백업의 중복 제거 비율이 향상됩니다. 따라서 대부분 새 백업을 수신하는 새로 설치된 DDR의 전체 중복 제거 또는 압축 비율이 저하되지만 시간이 지남에 따라 개선될 것으로 예상됩니다.

작은 파일:

작은 파일은 DDR에 쓸 때 다양한 문제를 일으킵니다. 여기에는 다음이 포함됩니다.

• 메타데이터 bloat - DDR이 물리적 데이터와 비교할 때 예상보다 많은 양의 파일 메타데이터를 보유하기 시작합니다.
• 컨테이너 활용도 불량 - 설계상(Data Domain Stream Informed Segment Layout 또는 SISL 아키텍처로 인해 이 문서의 범위를 벗어나는) 디스크의 4.5Mb 컨테이너는 단일 파일의 데이터만 저장합니다. 따라서 단일 10Kb 파일을 백업하면 해당 파일에 대해 하나 이상의 전체 4.5Mb 컨테이너가 기록됩니다. 즉, 이러한 파일의 경우 DDR은 백업되는 사전 압축된(논리적) 데이터의 해당 양보다 훨씬 더 많은 사후 압축(물리적) 공간을 사용하므로 전체 압축률이 저하될 수 있습니다.
• 낮은 중복 제거율 - 4Kb보다 작은 파일(DDR에서 지원되는 최소 세그먼트 크기)은 4Kb로 패딩된 단일 세그먼트로 구성됩니다. 이러한 세그먼트는 중복 제거되지 않고 디스크에 직접 기록됩니다. 이로 인해 DDR이 동일한 세그먼트의 여러 복제본(중복 세그먼트로 표시)을 유지할 수 있습니다.
• 낮은 백업, 복원 또는 클린 성능 - 한 파일에서 다음 파일로 이동할 때 백업, 복원 또는 정리 중에 큰 오버헤드가 발생합니다(사용 중인 메타데이터의 컨텍스트를 전환해야 하므로).

다음을 참조하십시오.

• DDOS 5.5 이상에서 물리적 정리 또는 가비지 컬렉션이 도입되어 소규모 파일을 사용할 때 성능 정리에 미치는 영향이 어느 정도 완화되었습니다.
• 사용률이 낮은 컨테이너의 데이터를 복제 단계에서 더 단단히 포장된 컨테이너에 통합하여 컨테이너 활용도가 낮은 '실행 취소'를 시도합니다.
• 복제 단계에서 과도한 중복 세그먼트 제거를 시도합니다.

위의 내용에도 불구하고 주로 작은 파일로 구성된 많은 수의 소규모 파일 또는 워크로드를 사용하지 않아야 합니다. 작은 파일을 기본 상태의 DDR로 전송하는 것보다 백업 전에 많은 수의 작은 파일을 압축되지 않은/암호화되지 않은 단일 아카이브로 결합하는 것이 좋습니다. 예를 들어 모든 1048576 파일보다 개별 10Kb 파일이 1048576 포함된 단일 10Gb 파일을 백업하는 것이 훨씬 낫습니다.

백업 애플리케이션에 의한 과도한 멀티플렉싱:

백업 애플리케이션은 백업 디바이스로 전송되는 스트림에 걸쳐 데이터의 멀티플렉싱을 수행하도록 구성할 수 있습니다. 즉, 입력 스트림(클라이언트가 서로 다른)의 데이터가 단일 스트림에서 백업 디바이스로 전송됩니다. 이 기능은 주로 물리적 테이프 디바이스에 다음과 같이 쓸 때 사용됩니다.

• 물리적 테이프 디바이스는 하나의 수신 쓰기 스트림만 지원할 수 있습니다.
• 백업 애플리케이션은 테이프 시작, 중지 또는 되감기(구두 비추기라고도 함)를 방지하기 위해 테이프 디바이스에 충분한 처리량을 유지해야 합니다. 테이프 디바이스로 가는 스트림에 두 개 이상의 클라이언트에서 읽는 데이터가 포함되어 있는 경우 더 쉽습니다.

그러나 DDR의 경우 DDR의 단일 파일에 임의의 순서 또는 청크 크기로 인터리빙된 여러 클라이언트의 데이터가 포함됩니다. 이로 인해 DDR이 각 세대의 지정된 클라이언트 백업에서 중복 세그먼트를 정확하게 파악하지 못할 수 있으므로 중복 제거율이 저하될 수 있습니다. 일반적으로 멀티플렉싱 세분화가 작을수록 중복 제거율에 미치는 영향이 더 심합니다.

또한 특정 클라이언트 데이터를 복원하려면 DDR이 파일 또는 컨테이너에 있는 대부분의 데이터가 다른 클라이언트 백업과 관련하여 불필요하게 발생하는 많은 파일 또는 컨테이너를 읽어야 하므로 복원 성능이 저하될 수 있습니다.

DDR은 각 스트림이 가변 속도로 쓸 수 있는 물리적 테이프 디바이스보다 더 많은 수신 스트림 수를 지원하므로 백업 애플리케이션은 DDR에 쓸 때 멀티플렉싱을 사용하지 않아야 합니다. 따라서 백업 애플리케이션별 멀티플렉싱을 비활성화해야 합니다. 멀티플렉싱을 비활성화한 후 백업 성능에 영향을 미치는 경우 다음을 수행합니다.

• CIFS, NFS 또는 OST(DDBoost)를 사용하는 백업 애플리케이션의 쓰기 스트림 수가 증가해야 합니다(DDR에 병렬로 더 많은 파일을 쓸 수 있도록).
• VTL을 사용하는 환경에서는 각 드라이브가 추가 병렬 쓰기 스트림을 지원할 수 있으므로 DDR에 드라이브를 추가해야 합니다.

멀티플렉싱을 비활성화하는 데 도움이 필요하거나 특정 백업 애플리케이션에 권장되는 멀티플렉싱 구성에 대해 논의하려는 경우 계약된 지원 공급업체에 문의하십시오.

과도한 테이프 마커를 삽입하는 백업 애플리케이션:

일부 백업 애플리케이션은 반복되는 데이터 구조를 '마커'라고 하는 백업 스트림에 삽입할 수 있습니다. 마커는 백업 내의 물리적 데이터를 나타내지 않고 백업 애플리케이션에서 인덱싱 또는 포지셔닝 시스템으로 사용됩니다.

경우에 따라 백업 스트림에 마커를 포함하면 중복 제거 비율이 저하될 수 있습니다( 예:

• 1세대 백업에는 연속된 12Kb의 데이터가 있었습니다. 이는 DDR이 단일 세그먼트로 인식했습니다.
• 그러나 2세대 백업에서는 동일한 12Kb의 데이터가 6Kb의 데이터, 백업 마커, 6Kb의 데이터로 표시될 수 있는 백업 마커를 포함함으로써 분할됩니다.
• 따라서 2세대 백업 중에 생성된 세그먼트가 1세대 백업 중에 생성된 세그먼트와 일치하지 않으므로 중복 제거가 제대로 되지 않습니다.

마커의 간격이 높을수록 중복 제거율에 미치는 영향이 더 빠집니다(예: 32Kb마다 마커를 삽입하는 백업 애플리케이션은 1Mb마다 마커를 삽입하는 것보다 더 많은 문제를 일으킵니다).

이 문제를 방지하기 위해 DDR은 다음을 허용하는 마커 인식 기술을 사용합니다.

• 백업을 수집하는 동안 백업 스트림에서 투명하게 제거되도록 백업 마커를 백업합니다.
• 백업 복원 중에 백업 스트림에 다시 삽입할 백업 마커

이를 통해 백업 마커를 통해 데이터 또는 세그먼트의 조각화를 방지하고 해당 백업의 중복 제거 비율을 개선할 수 있습니다.

그러나 이 기술을 최대한 활용하려면 DDR이 백업 스트림에 삽입되는 마커를 올바르게 인식할 수 있습니다. DDR은 '마커 유형' 옵션의 설정에 따라 마커를 찾습니다( 예:

SE@DDVE60_JF## filesys option show
Option Value
-------------------------------- --------
...
마커 유형 자동
...


-------------------------------- --------일 때 DDR이 가장 일반적인 마커 유형과 자동으로 일치하도록 허용하므로 이 옵션을 'auto'로 설정해야 합니다. 시스템이 마커를 삽입하는 하나의 백업 애플리케이션에서만 데이터를 수집하는 경우, 특정 마커 유형을 지정하면 성능 이점이 있을 수 있습니다. 즉:

# filesys option set marker-type {auto | nw1 | cv1 | tsm1 | tsm2 | eti1 | fdr1 | hpdr1 | besr1 | ssrt1 | ism1 | bti1| none}

다음을 참조하십시오.

• 특정 마커 유형을 선택하면 성능에 대한 이점이 거의 없을 수 있습니다.
• 잘못된 마커 유형을 선택하면 백업 또는 복원 성능 및 중복 제거 비율이 크게 저하될 수 있습니다.

따라서 Data Domain은 일반적으로 마커 유형을 'auto'로 설정하는 것을 권장합니다. 마커 유형 수정에 대한 자세한 내용은 계약된 지원 공급업체에 문의하십시오.

백업 마커를 사용하지만 자동화된 마커 처리 기술(예: BridgeHead 소프트웨어의 제품)으로 인식되지 않는 애플리케이션에서 데이터를 수집하는 시스템의 경우 계약된 지원 공급업체에 문의하여 Data Domain 지원 부서와 협력하여 DDR에 필요한 설정을 확인하여 표준이 아닌 마커를 감지할 수 있습니다.

DDR에서 수신되는 '품질이 낮은' 데이터의 표시:

다음 표에는 위에 나열된 다양한 데이터 유형에 대한 예상 중복 제거 및 압축 비율이 나와 있습니다. 이 목록은 완전하지 않으며 DDR에서 수집한 워크로드 또는 데이터로 인해 특정 시스템에서 표시되는 정확한 그림에 약간의 차이가 있을 수 있습니다.
 

글로벌 압축	로컬 압축	원인일 수 있습니다.
낮음(1x~4x)	낮음(1x~1.5x)	사전 압축 또는 암호화된 데이터
낮음(1x~2x)	높음(>2x)	데이터베이스 아카이브 로그와 같은 고유하지만 압축 가능한 데이터
낮음(2x~5x)	높음(>1.5x)	탐지되지 않거나 데이터 변경률이 높거나 멀티플렉싱 스트림이 아닌 마커입니다.
높음(>10x)	낮음(<1.5x)	동일한 압축 또는 암호화된 데이터의 백업입니다. 이는 드문 일입니다.

DDR에 전체 중복 제거율에 영향을 줄 수 있는 특정 요인이 있습니까?

예. DDR의 디스크에 이전/수퍼플레이션 데이터를 보존할 수 있는 여러 가지 요인이 있으며, 이로 인해 압축 후(물리적) 디스크 공간이 증가하고 전체 압축률이 감소합니다. 이러한 요인은 아래에 설명되어 있습니다.

파일 시스템 정리를 정기적으로 실행하지 못하는 경우:

파일 시스템 정리는 더 이상 DDR의 파일에서 참조되지 않는 디스크의 이전/불필요한 데이터를 물리적으로 제거하는 유일한 방법입니다. 따라서 사용자는 시스템에서 여러 파일을 삭제할 수 있지만(사전 압축된 사용률이 감소함) 새로 실행되지 않을 수 있습니다(사후 압축/물리적 활용도가 높게 남음). 이로 인해 전체 압축률이 저하될 수 있습니다.

Data Domain은 다음과 같이 주기적으로 실행되도록 정리 예약을 권장합니다.

• 일반 DDR: 주당 1회
• 확장 보존을 사용하는 DDR: 2주에 한 번씩

디스크의 데이터가 조각화되어 복원/복제 성능이 저하될 수 있으므로 정리를 일주일에 한 번 이상 실행해서는 안 됩니다.

시스템에서 오래된 스냅샷이 과도하게 표시됨:

DDR은 스냅샷이 생성된 시점에 mtree의 콘텐츠를 나타내는 mtree 스냅샷을 생성할 수 있습니다. 그러나 시스템에 이전 스냅샷을 남겨 두면 압축 후/물리적 활용도가 증가하여 전체 압축 비율이 감소할 수 있습니다. 예:

• mtree에는 많은 파일이 포함되어 있습니다(따라서 사전 압축된 활용도가 높음).
• mtree의 스냅샷이 생성됩니다.
• 많은 파일이 삭제됩니다(사전 압축된 활용도가 저하됨).
• 파일 시스템 정리가 실행됩니다. 그러나 삭제된 파일의 복제본이 mtree 스냅샷에 유지되므로 최소 하드 드라이브 공간이 확보되므로 해당 파일이 참조하는 데이터를 디스크에서 제거할 수 없습니다.
• 그 결과, 압축 후/물리적 활용도가 높게 유지됨

Data Domain은 mtree 스냅샷을 사용하는 경우(예: 우발적인 데이터 삭제로부터 복구) 스냅샷이 정의된 만료 기간(스냅샷이 자동으로 제거되기 전의 시간)을 사용하여 정기적으로 생성되도록 자동화된 스냅샷 스케줄을 사용하여 관리하는 것이 좋습니다. 또한 만료 기간은 최대한 짧아야 합니다(단, 이러한 스냅샷이 제공하는 스냅샷의 사용 사례 또는 보호 수준에 따라 분명히 달라질 수 있음). 이렇게 하면 만료 기간이 긴 이전 스냅샷이 생성되지 않습니다.

스냅샷 및 스냅샷 스케줄 작업에 대한 자세한 내용은 다음 문서에서 확인할 수 있습니다. Data Domain - 스냅샷 스케줄

관리과도한 복제 지연:

기본 Data Domain 복제는 복제 로그 또는 mtree 스냅샷(복제 유형에 따라 다름)을 사용하여 원격 DDR에 대한 복제 보류 중인 파일 또는 데이터를 추적합니다. 복제 지연은 복제본이 소스 DDR 변경에 뒤쳐지는 개념입니다. 이 문제는 다음과 같은 다양한 요인으로 인해 발생할 수 있습니다.

• 비활성화 중인 복제 컨텍스트
• DDR 간의 네트워크 대역폭 부족
• 네트워크 연결이 자주 끊어집니다.

복제 지연이 크면 복제 로그에 소스 DDR 또는 소스 및 대상 DDR의 오래된 또는 오래된 mtree 스냅샷에서 삭제된 파일에 대한 참조가 계속 포함될 수 있습니다. 위에서 설명한 대로 이러한 스냅샷(또는 복제 로그)에서 참조하는 데이터는 해당 파일이 시스템에서 삭제된 경우에도 DDR의 디스크에서 물리적으로 제거할 수 없습니다. 이로 인해 DDR의 압축 후 또는 물리적 활용도가 증가하여 중복 제거 비율이 저하될 수 있습니다.

DDR의 활용도가 높고 복제 지연으로 인한 것으로 판단되는 경우 계약된 지원 공급업체에 문의하여 추가 지원을 받으십시오.

전체 압축률을 높일 수 있는 DDR의 구성 변경 사항 또는 특정 요인이 있습니까?

예 - 이 문서에서 이전에 설명한 문제를 제거하거나 해결하면 DDR이 시간이 지남에 따라 전반적인 압축률 향상을 표시할 수 있습니다. 또한 DDR에는 중복 제거 비율이 증가할 수 있는 다양한 요인 또는 작업 로드가 있습니다. 일반적으로 다음과 같은 사항이 포함됩니다.

• DDR의 파일에 사용되는 하드 드라이브 공간의 양을 줄입니다(예: DDR에서 사용하는 압축 알고리즘의 공격성 증가).
• 압축 후/물리적 활용도가 증가하지 않고 DDR에서 사전 압축된(논리적) 데이터의 양이 갑자기 증가합니다.

압축 알고리즘 수정:

기본적으로 DDR은 lz 알고리듬을 사용하여 디스크에 기록되는 데이터를 압축합니다. 앞서 언급했듯이 lz 는 압축 또는 압축 해제에 필요한 CPU 측면에서 상대적으로 오버헤드가 적지만 데이터 크기를 줄이는 데 합당한 효과를 발휘하기 때문에 사용됩니다.

압축 알고리즘의 공격성을 높여 압축 후 또는 하드 드라이브 활용도를 추가로 절감할 수 있습니다(결과적으로 전체 압축 비율이 향상됨). 지원되는 압축 알고리듬은 저효율에서 높은 효율성 순으로 다음과 같습니다.

• 출발지
• gzfast
• Gz

각 알고리듬의 일반적인 비교는 다음과 같습니다.

• gzfast에 비해 lz는 최대 15% 더 나은 압축을 제공하고 2개의 CPU를 소비합니다.
• gz에 비해 lz는 최대 30% 더 나은 압축을 제공하고 5개의 CPU를 소비합니다.
• gz에 비해 gzfast는 최대 10~15% 더 나은 압축을 제공합니다.

압축을 완전히 비활성화(없음 알고리듬 지정)할 수도 있습니다. 그러나 이는 고객 시스템에서 사용할 수 없으며 내부 테스트 전용입니다.

위의 표에 따르면 압축 알고리즘이 더 공격적일수록 데이터의 압축 또는 압축 해제 중에 더 많은 CPU가 필요합니다. 따라서 보다 공격적인 알고리즘에 대한 변경은 일반 워크로드 아래에 가볍게 로드된 시스템에서만 이루어져야 합니다. 로드가 많은 시스템에서 알고리듬을 변경하면 백업 또는 복원 성능이 극도로 저하되고 파일 시스템 패닉 또는 재시작이 발생할 수 있습니다(DDR이 중단됨).

압축 유형 변경에 대한 자세한 내용은 다음 문서를 참조하십시오. Data Domain 시스템 및 GZ 압축으로 변환의 성능 개선

영향압축 알고리듬 변경의 잠재적 영향으로 인해 이 작업을 수행하는 데 관심이 있는 고객은 계약된 지원 공급업체에 문의하여 변경 사항을 계속 진행하기 전에 더 자세히 논의하는 것이 좋습니다.

파일 시스템 fastcopy 사용:

DDR을 사용하면 'file system fastcopy' 명령을 사용하여 파일(또는 디렉토리 트리)을 빠르게 복사할 수 있습니다. 이 기능은 기존 파일(또는 파일 그룹)의 메타데이터를 클론 생성하여 새 파일이 원래 파일에 물리적으로 연결되지는 않지만 원래 파일과 동일한 데이터를 디스크에 참조하도록 합니다. 즉, 원래 파일의 크기에 관계없이 새 파일은 디스크의 공간을 거의 사용하지 않습니다(기존 데이터와 완벽하게 중복 제거되므로).

이 동작의 결과는 파일 시스템 빠른 복사를 사용할 때 DDR에 있는 데이터의 사전 압축(논리적) 크기가 빠르게 증가하지만 DDR의 압축 후/물리적 활용도는 정적으로 유지된다는 것입니다.

예를 들어 다음 DDR의 활용도는 다음과 같습니다(전체 압축률 ~1.8배 표시):

Active Tier:
Resource Size GiB Used GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 12.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

이 포함된 대용량 파일(/data/col1/backup/testfile):

!!! 데이터가 위험에 DDVE60_JF !!! # ls -al /data/col1/backup/testfile-rw-r
--r-- 1 root root 3221225472 Jul 29 04:20 /data/col1/backup/testfile

파일이 여러 번 빠르게 처리됩니다.

sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy1
sysadmin@DDVE60_JF# filesys fastcopy source /data /col1/backup/testfile destination /data/col1/backup/testfile_copy2
sysadmin@DDVE60_JF# filesys fastcopy source /data/col1/backup/testfile destination /data/col1/backup/testfile_copy3

이로 인해 사전 압축된 활용도가 증가하여 압축 후 활용도가 거의 변경되지 않음: Active Tier:


리소스 크기 GiB 사용 GiB 사용 GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 21.0 - -
/data: post-comp 71.5 6.8 64.7 10% 0.0
/ddvar 49.2 1.1 45.6 2% -
/ddvar/core 158.5 0.2 150.2 0% -
---------------- -------- -------- --------- ---- --------------

DDR은 이제 전체 압축률 ~3.1x를 보여줍니다.

위에서 언급했듯이 복제본의 압축 통계는 완벽하게 중복 제거되는 것으로 나타납니다.

sysadmin@DDVE60_JF# filesys는 압축 /data/col1/backup/testfile_copy1
Total 파일을 보여줍니다. 1;  바이트/storage_used: 21331976.1
원래 바이트:        3,242,460,364
전 세계적으로 압축됨:                    0
로컬 압축:                    0
메타 데이터:                  152

Fastcopy 기능은 DDR의 물리적 활용도를 줄여 전반적인 압축률을 개선하는 데 사용할 수 없지만, 전체 압축률이 높은 원인일 수 있습니다(특히 Avamar 6.x와 같은 Fastcopy를 광범위하게 사용하는 환경에서는).