Avamar: 복제 쌍이 서로 다른 수준의 용량 사용량을 표시합니다. 원인을 조사하는 방법.

'서버 활용도 값' 간에 차이가 있는 원인과 가능한 이유:

그리드 간의 논리적 또는 물리적 차이:

• 소스와 타겟 그리드의 데이터 노드 수가 다릅니다.
• 각 그리드의 데이터 노드에는 서로 다른 디스크 구성이 있습니다.
• 각 시스템 내의 데이터 노드 전체에 걸쳐 적절하게 균형 잡힌 스트라이프의 분산(2% 이내)
• 스토리지 및 패리티 요구 사항은 Avamar 버전에 따라 다릅니다. 소스 소프트웨어 버전과 타겟 소프트웨어 버전이 다를 경우 사용량의 차이가 보일 수 있습니다.
• Avamar Server 디스크 읽기 전용 레벨은 두 그리드 간에 다를 수 있습니다.   
• 한 그리드는 RAIN 패리티에 대해 구성되었지만, 다른 그리드는 그렇지 않을 수 있습니다.

복제 구성:

• 타겟 시스템에 복제된 백업은 소스와 다른 보존 정책을 가질 수 있습니다. 자세한 내용은 expiredelta 플래그를 검토하십시오. 또는 복제된 백업이 특정 기간만 포함하고 있을 수 있습니다. 예를 들어, 소스에서 지난 4주 동안의 백업만 포함하고 있을 수 있습니다.
• 복제를 구성해서 소스 시스템에서 타겟 시스템으로 클라이언트의 하위 집합만 복제할 수 있습니다. "포함" 또는 "제외" 설정을 사용하고 있는지 확인합니다.
• 클라이언트 및 관련 백업이 소스 시스템에서 삭제되었을 수 있습니다. 소스에서 클라이언트 또는 백업을 삭제해도 타겟 시스템에서 동일한 백업이 제거되지 않습니다. 백업은 보존 설정에 따라 만료될 때까지 타겟에 남아 있습니다.
• 보존 정책은 소스 시스템의 백업 또는 클라이언트에 대해 변경할 수 있습니다. 보존 정책 변경은 새 백업에만 영향을 미칩니다. 새 백업이 타겟에 복제되고 업데이트된 보존 정책을 준수합니다. 타겟에 이미 있는 백업은 복제될 때 적용되는 보존 정책을 유지합니다.

이전 용량 관리 활동:

• 고객이 Avamar 복제 쌍 시스템 중 하나가 용량에 근접하고 있음을 알아차린 후 용량을 줄이기 위한 조치를 취하는 것은 드문 일이 아닙니다. Avamar 복제 쌍이 독립적으로 관리되는 두 개의 시스템으로 구성된다는 점을 기억하십시오. 한 시스템에서 작업을 수행하는 경우 다른 시스템에서도 수행해야 합니다. 
• 소스 시스템에서 백업을 삭제하거나 보존을 감소시키면 반드시 타겟에서 동일한 변경을 수행해야 합니다. 이러한 방식으로 용량을 관리하는 가장 좋은 방법은 modify-snapups 스크립트를 사용하는 것입니다. 이 스크립트는 백업 수정 또는 삭제 옵션이 동일한 두 Avamar Server 모두에서 실행할 수 있습니다.  

다른 스트라이프 구조(예: 한 시스템에 더 많은 패리티 스트라이프가 있는 경우):

• 두 Avamar 시스템은 독립적이므로 스트라이프 구조가 서로 다를 수 있습니다. 멀티 노드 시스템은 패리티 스트라이프를 사용하여 데이터를 보호하므로 차이를 나타낼 수 있습니다. 용량 기록에 따라 두 개의 멀티 노드 시스템에 동일한 백업이 포함되어 있지만 한 시스템에 다른 시스템보다 더 많은 패리티 스트라이프가 있을 수 있습니다.
• 일반 스트라이프와 마찬가지로 생성된 패리티 스트라이프는 항상 시스템에 남아 있습니다. 패리티 스트라이프는 일반 스트라이프와는 달리 Avamar Server 내에서 고정 용량의 공간을 항상 사용합니다. 패리티 그룹 안전-스트라이프에 데이터가 포함되어 있지 않은 경우에도 마찬가지입니다. 가비지 컬렉션은 이 동작에 영향을 미치지 않습니다.
• 복제 타겟 시스템은 복제 소스의 주요 용량 문제로부터 간접적으로 보호됩니다. 그러나 이 중 하나에서 용량 측면이 제대로 관리되지 않으면 두 시스템 모두에서 이런 상황이 발생할 수 있습니다.
• 관련 문서: 모든 백업이 삭제되고 가비지가 수집된 후에도 Avamar는 최대 30%의 사용률을 보임

백업이 여전히 MC_DELETED에 있음:

• 주의해야 하는 한 가지 드문 시나리오는 클라이언트를 소스에서 삭제하지만 백업이 유지되는 경우입니다. 이로 인해 백업이 자연스럽게 만료될 것으로 예상되는 타겟보다 소스 사용률이 더 높아질 수 있습니다. backupcompare 옵션과 함께 dump_root_hashes.rb 스크립트를 사용하면 이 시나리오를 확인하는 데 도움이 됩니다.

복제되지 않은 백업의 타겟 시스템 데이터:

• 시스템이 *한 방향으로만* 복제되는 경우에는 타겟에서 /REPLICATE 및 MC_SYSTEM 외의 클라이언트가 없는지 확인해야 합니다.

기타 동작:

• 복제 작업이 안정적으로 완료되지 않을 수 있습니다. 타겟으로 전송된 데이터는 소스보다 며칠 동안 '지연'될 수 있습니다.
• 두 시스템 모두 동일한 양의 중복 제거된 데이터를 포함하지만 각 시스템의 패리티 오버헤드는 서로 다릅니다. 이 문제는 다음과 같은 시나리오에서 발생합니다. 
  • Avamar 소스 시스템이 거의 가득 찼습니다. 
  • 많은 백업이 소스 시스템에서 삭제되어 용량 수준이 낮아졌습니다. 
  • 그런 다음 중복 제거된 데이터의 복제가 소스에서 타겟으로 수행되었습니다. 
  • 중복 제거된 데이터의 양은 두 시스템에서 동일합니다.
  • 소스 시스템은 처음에 타겟보다 더 많은 패리티 오버헤드를 저장합니다.
• 복제는 소스에서 타겟 그리드로 물리적 스트라이프를 복제하지 않습니다. 대신 타겟 그리드는 데이터 스트립과 청크가 저장되는 위치를 스스로 결정할 수 있습니다.
• 경우에 따라 타겟 Avamar 시스템은 데이터가 원래 백업된 소스 그리드보다 데이터를 더 효율적으로 저장할 수 있습니다.

복제 환경 이해:

• 소스 Avamar 그리드의 전체 호스트 이름을 기록해 둡니다.
• 영향을 받는 시스템의 복제 구성을 검토하여 어떤 시스템이 어떤 데이터를 어디로 복제하는지 파악합니다. 
  • 환경이 한 Avamar Server에서 다른 Avamar Server로 복제하는 것보다 복잡할 경우 환경의 도식을 나타내는 것이 도움이 될 수 있습니다.
• 소스가 DD(Data Domain)와 통합되는 경우 고객의 우려 사항이 DD 디바이스 간에 복제된 백업과 관련이 있는지 알아보십시오.
• 복제된 백업을 수신하는 타겟 Avamar 그리드 및 연결된 DD 디바이스의 전체 호스트 이름을 기록해 둡니다.

그리드의 전반적인 상태와 상황을 확인합니다.

• 두 그리드 모두에서 사전 예방적인 검사 스크립트를 실행하고 hc_results.txt의 사본을 얻어서 검토하여 시스템의 전반적인 상황을 파악합니다. 

용량 차이가 얼마나 심각합니까?

• 고객은 소스 및 타겟 간에 용량 소비 차이가 있다고 생각하는 내용을 보여주는 스크린샷을 제공해야 합니다.
• 용량 차이가 5% 미만일 경우 경보할 이유가 없다고 간주합니다.
• Avamar Administrator UI를 확인하여 Avamar Server 용량 수준과 Data Domain이 통합된 경우의 메타데이터 용량을 파악합니다.
• UI 용량 표시가 작동하는 방식에 유념하십시오(v7.2 이상 버전의 Avamar UI 대시보드에는 Avamar 사용률 대신 메타데이터 사용률 표시에서 논의).
• 두 시스템 모두에서 다음 명령을 실행합니다. 서버 사용률 값은 Avamar Server(Data Domain 제외)의 전체 용량 수준을 제공합니다.

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

두 그리드 모두에서 하드웨어가 동일한지 확인합니다.

• "유사" 시스템의 경우 용량 차이만 비교하는 것이 좋습니다. 
• 사전 예방적인 출력을 사용하여 시스템에 있는 노드 유형을 확인합니다.
• 다음 명령은 물리적 노드의 전체 수, 크기, 공간 사용량을 보여 줍니다.

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• 이 출력을 사용하면 시스템의 노드 수와 크기를 쉽게 확인할 수 있습니다. (23.3/3 = ~7.8TB)입니다. 
• 각 노드의 하드 드라이브 파티션 수와 크기는 이를 확증해야 합니다.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• 이 정보를 사용하여 다음을 확인합니다.

소프트웨어 버전 및 구성을 확인합니다.

• status.dpn 명령의 출력을 사용하여 각 시스템에서 실행되는 Avamar 버전을 비교합니다.
• 멀티 노드 시스템의 경우, 두 시스템 모두 Avamar당 RAIN 패리티로 구성되어 있는지 확인합니다(서버가 RAIN인지 비RAIN인지 확인하는 방법).
• 두 시스템의 용량 관련 Avamar Server 구성 매개변수를 확인하고 비교합니다. 예:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

스트라이프 밸런싱 확인:

• status.dpn 출력을 확인하고 각 데이터 노드의 총 스트라이프 수를 기록합니다. 스트라이프 수가 괄호 안에 표시됩니다(예: onl:xxx). 
• 각 데이터 노드의 총 스트라이프 수 간에 차이가 2% 미만이어야 합니다.  

모든 시스템에서 가비지 컬렉션이 정상적으로 작동하고 있는지 확인합니다.

• 가비지 컬렉션이 일관되고 효과적으로 실행되지 않으면 만료된 데이터가 제거되지 않습니다. 시스템이 예상보다 높은 용량 사용량을 보고합니다. 
  • 자세한 내용은 제한된 참고 사항의 GC 해결 경로 문서를 참조하십시오.  

복제가 성공적으로 완료되었는지 확인합니다.

• 소스에서 타겟으로의 모든 복제 작업이 성공적으로 완료되었는지 확인합니다. 이 문제가 발생하지 않은 경우 소스에서 타겟으로 복제해야 할 데이터가 남아 있을 수 있습니다.  

복제 구성을 확인합니다.

• 복제 구성(UI, CLI 또는 로그)에서 다음 플래그를 확인합니다.  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

모든 시스템의 수집 및 데이터 제거 속도를 확인합니다.

• 모든 시스템에서 proactive_check.pl --capacity 명령을 실행하여 소스 시스템과 타겟 시스템의 데이터 수집 속도를 비교합니다.
• 타겟이 온전히 타겟 시스템이고 소스에서 모든 백업을 수신하는 경우 수집 속도는 소스의 수집 속도에 근접해야 합니다.
• Avamar NEW 또는 DDR NEW 열은 해당 시스템에 추가되는 새 데이터의 양을 보여줍니다.
• 또한 "제거됨", "최소" 및 "통과" 열에 주의를 기울여 두 시스템의 가비지 컬렉션 동작을 이해합니다.
• 이 정보를 통해 두 시스템에서 무슨 일이 일어나고 있는지 명확하게 파악할 수 있습니다.
• 출력 해석에 대한 자세한 내용은 다음을 참조하십시오. Avamar: capacity.sh 스크립트를 사용하여 용량을 관리하는 방법  

각 시스템에 있는 백업 목록을 덤프합니다.

• dump_root_hashes.rb 스크립트는 Avamar 소스와 타겟 시스템 간에 저장된 백업의 차이를 비교하는 데 도움이 되는 유틸리티입니다. 이 스크립트는 백업이 Data Domain 스토리지에서 호스팅되는 경우에도 사용할 수 있습니다.   
• 다음을 참조하십시오. Avamar: Avamar: dump_root_hashes.rb 스크립트를 사용하여 클라이언트 및 백업 목록을 생성하는 방법 - 여기에서 두 Avamar 시스템의 콘텐츠를 비교하는 등 유틸리티 및 사용 사례를 다운로드하는 방법에 대한 정보를 알아보십시오.
  • 툴을 실행합니다. 모든 클라이언트에서 백업 수가 일치하지 않는지 확인합니다. +/-2)의 차이에 주의하십시오.  
• 원인 섹션에서 설명한 것처럼 비대칭 용량 관리는 두 시스템 간의 차이를 초래합니다. 출력을 검토하여 이런 시나리오가 발생할 수 있는지 확인합니다.
• 또한,
  • 타겟 데이터에 복제되지 않은 백업이 있는지 타겟 시스템을 확인합니다.
  • 타겟으로 복제되지 않은 데이터가 있는지 소스를 확인합니다.  

다른 스트라이프 구조를 확인합니다(예를 들어 한 시스템에 더 많은 패리티 스트라이프가 있는 경우).

• 두 Avamar 시스템은 독립적이므로 스트라이프 구조가 서로 다를 수 있습니다. 멀티 노드 시스템은 패리티 스트라이프를 사용하여 데이터를 보호하므로 차이를 나타낼 수 있습니다. 용량 기록에 따라 두 개의 멀티 노드 시스템에 동일한 백업이 포함되어 있지만 한 시스템에 다른 시스템보다 더 많은 패리티 스트라이프가 있을 수 있습니다.  
• 일반 스트라이프와 마찬가지로 생성된 후에는 패리티 스트라이프가 시스템에 남아 있습니다. 일반 스트라이프와는 달리, 패리티 그룹의 안전 스트라이프에 데이터가 포함되어 있지 않더라도 Avamar 내에서 고정 용량의 공간을 항상 사용합니다. 가비지 컬렉션은 이 동작에 영향을 미치지 않습니다.
• 복제 타겟 시스템은 복제 소스의 주요 용량 문제로부터 간접적으로 보호됩니다. 그러나 이 중 하나에서 용량 측면이 제대로 관리되지 않으면 두 시스템 모두에서 이런 상황이 발생할 수 있습니다.
• 관련 문서:  모든 백업이 삭제되고 가비지가 수집된 후에도 Avamar는 최대 30%의 사용률을 보임  

백업이 여전히 MC_DELETED에 있음:

• 주의해야 하는 한 가지 드문 시나리오는 클라이언트를 소스에서 삭제했지만 백업이 유지되었던 경우입니다. 이로 인해 백업이 자연스럽게 만료될 것으로 예상되는 타겟보다 소스 사용률이 더 높아질 수 있습니다. dump_root_hashes.rb 스크립트를 backupcompare 옵션과 함께 사용하면 이 시나리오를 확인하는 데 도움이 됩니다.