Avamar: 용량 관리 개념 및 교육

摘要: 이 문서는 Avamar 사용자 및 운영 체제 용량 관리에 대해 설명합니다. Avamar 시스템 관리자 또는 운영 체제 및 사용자 용량 수준을 관리하는 방법에 대한 실무 지식이 필요한 Avamar 그리드를 모니터링하는 사람을 위한 것입니다.

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。

症状

Data Domain과 관련된 용량 관리 문제는 Avamar 및 Data Domain 시스템 통합 가이드의 "전체 Data Domain 시스템에서 스토리지 확보" 섹션을 참조하십시오. 운영 환경과 관련된 가이드는 Dell 지원 사이트에서 Avamar 설명서를 찾는 방법에 있습니다.

이 문서의 목표:
 
  • /data* 파티션에 저장된 데이터 유형 요약
  • "운영 체제 용량" 개념 소개 및 "사용자 용량"("GSAN 용량"이라고도 함) 개념과 비교
  • Avamar를 사용자 용량 한도에 가깝게 실행해서는 안 되는 이유 설명
  • 체크포인트 오버헤드에 영향을 미치는 요인 나열
  • 데이터 파티션 활용도를 모니터링하는 방법 설명
  • 운영 체제 용량을 제어할 수 없는 경우 발생하는 증상 설명
  • 일반적인 메시지의 원인 MSG_ERR_DISKFULL 나열
  • 운영 체제 용량이 큰 경우 정상적인 시스템 작업에 영향을 미치는 복구 방법 사용에 대한 간략한 설명
  • 사용자 용량이 사용자 용량 한도를 초과할 경우 발생하는 증상 설명
  • 사용자 용량이 높은 상황에서 복구하는 방법에 대해 논의

이 문서는 독자가 Avamar 운영 모범 사례 가이드의 "용량 관리" 섹션에 대해 잘 알고 있다고 가정합니다.

운영 환경과 관련된 가이드는 Dell 지원 사이트에서 Avamar 문서를 찾는 방법에 있습니다.

너무 높은 "운영 체제 용량" 증상에 영향을 주거나 증상에 해당하는 일반적인 문제는 다음과 같습니다.
  • 체크포인트 검증(hfscheck)이 실패
  • 가비지 컬렉션이 실행되지 않고 MSG_ERR_DISKFULL 보고
  • 체크포인트 생성 실패
너무 높은 "사용자 용량"과 밀접한 관련이 있는 일반적인 증상은 다음과 같습니다.
  • 백업 실패
  • 예정된 복제 작업 실패
  • 백업 기간 중에 'Admin' 모드에서 관리자 인터페이스 표시

原因

해결 방법 섹션을 참조하십시오.

解决方案

데이터가 Avamar 그리드에 어떻게 저장됩니까?


Avamar 용량 관리는 모든 Avamar 데이터 노드의 /data* 파티션에 있는 데이터와 관련이 있습니다. 구성 요소는 다음과 같습니다.
  • 중복 제거된 백업 데이터
  • RAIN 패리티 데이터
  • 체크포인트 오버헤드 데이터
RAIN 패리티와 체크포인트 데이터는 모두 RAID 및 복제 외에도 Avamar에서 사용할 수 있는 이중화 계층입니다.

가비지 컬렉션 및 비동기 스트라이프 크런칭과 같은 유지 보수 작업을 올바르게 실행하려면 데이터 파티션의 여유 공간도 필요합니다.

아래는 Avamar 스토리지 노드의 데이터 파티션 내에서 사용 가능한 물리적 스토리지 공간을 그림으로 보여 줍니다.

Avamar 용량 분석

 

데이터는 데이터 파티션에 어떻게 저장됩니까?


위의 다이어그램에서는 공간이 데이터 파티션에서 어떻게 사용되는지에 대한 간단한 표현을 볼 수 있습니다.

왼쪽의 100% 값은 데이터 파티션의 운영 체제에서 사용할 수 있는 물리적 공간의 총 크기로 정의됩니다.

데이터 파티션이 전체 공간의 85% 이상을 차지하는 경우 가비지 컬렉션을 실행할 수 없습니다.

100% 사용자 용량 표시(읽기 전용 제한)는 데이터 파티션의 총 공간의 최대 65%를 중복 제거된 데이터를 저장하는 데 사용할 수 있음을 나타냅니다. 이 100% 사용자 용량 표시 아래의 공간은 Administrator UI에 표시되는 서버 활용도 값과 같습니다. 노드의 데이터 파티션에 저장된 중복 제거된 데이터의 양이 65%에 도달하면 Avamar 시스템은 읽기 전용이 되고 추가 백업 데이터를 거부합니다.

이제 Avamar Administrator UI를 통해 백업에서 사용한 공간은 사용자가 볼 수 있지만 운영 체제 데이터 파티션에서 사용된 공간은 볼 수 없다는 것을 알 수 있습니다.

 

Avamar 시스템을 "사용자 용량" 한도에 가깝게 실행해서는 안 되는 이유는 다음과 같습니다.


높은 "사용자 용량"과 체크포인트 오버헤드 간의 관계는 시스템이 가득 차게 되면 백업 데이터가 조금만 증가하더라도 체크포인트 오버헤드가 크게 증가할 수 있다는 것입니다.

이 경우에 대한 전체 논의는 이 문서의 범위를 벗어나지만 기억해야 할 중요한 사항은 다음과 같습니다. Avamar 시스템이 100% 사용자 용량에 가까울수록 체크포인트 오버헤드에 사용할 수 있는 운영 체제 용량이 줄어듭니다.

위의 다이어그램에서 볼 수 있듯이 전체 시스템에서 체크포인트 오버헤드는 데이터 파티션의 전체 운영 체제 공간의 20%로 제한됩니다.

Avamar 시스템이 높은 수준의 "사용자 용량"에서 안정적으로 실행되려면 다음 기준을 충족해야 합니다. 이러한 설명이 true에서 false로 바뀌면 체크포인트 오버헤드가 점진적으로 증가하거나 갑자기 급증하여 심각한 운영 문제가 발생한다고 예상할 수 있습니다.

 

체크포인트 오버헤드에 영향을 미치는 요인:


다음 요인으로 인해 체크포인트 오버헤드가 증가할 수 있습니다.
  • 비동기 스트라이프 크런칭(기본적으로 활성화됨)
  • 시스템에 저장된 체크포인트 수
  • 체크포인트 검증이 매일 성공적으로 완료되지는 않습니다.
  • Avamar Server에서 스트라이프를 재사용할 때 스트라이프가 비어 있는 정도(서버 활용도가 높을수록 심각해짐)
  • 일일 백업 변경률<
시스템 관리자는 이러한 요인을 어느 정도 제어할 수 있습니다. 비동기 크런칭 구성은 지원용으로만 사용할 수 있지만, 관리자는 초과 체크포인트를 제거하고, 체크포인트 장애를 조사하고, 서버 활용도 및 일일 데이터 변경률에 영향을 줄 수 있습니다.

 

데이터 파티션 활용도를 모니터링하는 방법:


운영 체제 데이터 파티션의 활용도를 모니터링하는 올바른 방법은 Avamar Utility Node에서 다음 Avamar 명령을 사용하는 것입니다.

예시:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        fs-percent-full="7.8"
        fs-percent-full="6.3"
        fs-percent-full="6.4"
        fs-percent-full="6.4"
        fs-percent-full="7.6"
        fs-percent-full="6.2"
        fs-percent-full="6.1"
        fs-percent-full="6.6"
        fs-percent-full="7.8"
        fs-percent-full="6.4"
        fs-percent-full="6.5"
        fs-percent-full="6.8"
이 출력을 통해 운영 체제 용량 활용도를 정확히 알 수 있습니다. 데이터 노드가 파일 풀을 사용하는 그리드에서 Linux df 명령은 의미가 없습니다. 스트라이프가 파일 풀에 사전 할당되어 있고 많은 스트라이프가 사용되고 있지 않을 수 있기 때문입니다.

 

운영 체제 용량 사용을 제어할 수 없으면 어떻게 됩니까?


사용자의 관점에서 볼 때, 첫 번째 표시는 데이터 파티션 활용도가 85% 이상 상승하면 제어되지 않는다는 것입니다.

가비지 컬렉션이 더 이상 실행될 수 없으며 더 이상 오류 메시지와 함께 MSG_ERR_DISKFULL 장애가 발생합니다.

다음은 오해가 자주 발생하는 부분입니다. 사용자가 MSG_ERR_DISKFULL 메시지를 시스템에 더 이상 백업 공간이 없음을 나타내는 것으로 해석하는 경우가 많습니다.

이러한 해석은 정확하지 않지만 일반적으로 사용자는 Avamar Administrator UI에서 서버 활용도 값을 확인하여 60%와 같이 허용 가능한 값을 찾습니다.

사용자는 Avamar UI의 백업 관리 인터페이스에서 백업을 삭제하려고 할 수 있습니다. 가비지 컬렉션이 실행될 수 없고 시스템에서 만료된 데이터 청크를 제거할 수 없기 때문에 사용자 용량 레벨이 높은 상태에서 백업을 삭제해도 상황이 완화되지 않습니다.

시스템에 높은 운영 체제 용량 문제와 높은 사용자 용량이 모두 발생하는 경우 먼저 높은 운영 체제 용량 문제를 해결하는 데 중점을 두십시오.

운영 체제 용량 활용도가 높은 경우, 시스템 공간이 부족해 체크포인트가 생성될 수 있습니다.

 

MSG_ERR_DISKFULL 메시지의 원인은 무엇입니까?


가장 일반적인 원인은 체크포인트 오버헤드가 너무 높은 것입니다. 체크포인트 오버헤드가 높은 일반적인 원인은 다음과 같습니다.
  • 체크포인트 검증(hfscheck)이 반복적으로 실패했습니다.
  • hfscheck 실패의 근본 원인은 여러 가지입니다(갑작스러운 취소, 소프트웨어 오류 등).
  • 시스템이 가득 찬 상태로 실행되고 있어서 일일 데이터 변경률이 매우 높습니다.
  • 데이터 변경률을 처리하고 데이터를 저장하기 위해 시스템에 더 많은 데이터 노드가 필요합니다.
  • 시스템이 설계된 것보다 더 많은 데이터 또는 클라이언트를 백업하도록 구성되었습니다.
  • 너무 많은 체크포인트가 저장되고 있습니다(Avamar는 기본적으로 두 개의 체크포인트를 저장하며, 이 중 하나는 검증되었음).
  • 시스템 관리자가 초과 체크포인트를 생성했습니다.
  • 최근에 유지 보수가 수행되었지만, 기본 체크포인트 보존이 회복되지 않았습니다.

MSG_ERR_DISKFULL 시나리오를 해결하려면 다음 문서를 참조하십시오. >89%인 "데이터" 파티션 운영 체제 용량으로 인해 "MSG_ERR_DISKFULL"이 표시되며 Avamar 유지 보수 작업 실패

 

높은 운영 체제 용량을 조사하고 완화하는 데 도움이 되는 조치


1. 마지막 hfscheck가 언제 완료되었는지 확인합니다. 이 작업은 Avamar Administrator 또는 Avamar Utility Node의 명령줄을 사용하여 수행할 수 있습니다.
  • Avamar Administrator에서 Server > Checkpoint Management 탭으로 이동합니다.
  • Checkpoint Validation 열에 나열된 가장 최근 날짜와 시간을 확인합니다. 최근 24시간 내에 수행한 작업이어야 합니다.
또는
 
  • Avamar Utility Node 명령줄을 사용하여 cplist 명령을 실행합니다.
다음은 CLI 출력의 예입니다.
 
admin@utilitynode:~/>: cplist
cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131
 
여기에 나열된 가장 최근에 검증된 체크포인트는 1월 14일 11시 14분에 검증된 것입니다. 'valid' 표시 바로 뒤에 있는 플래그를 통해 식별할 수 있습니다. 시스템에 설정된 hfscheck 유형에 따라 플래그는 'rol' 또는 'hfs'일 수 있습니다. 여기에 rol(rolling hfscheck)이 있습니다.

결과에 가장 최근에 검증된 체크포인트가 24시간 이상 지난 것으로 나타나면 그 이유를 알아보십시오. HFScheck가 실행되지 않았거나 실패했기 때문일 수 있습니다.


2. HFScheck 실행 또는 실패 확인
 
Avamar Utility Node에서 status.dpn을 실행하고 Last hfscheck가 포함된 줄을 찾습니다.

예:
 
Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)
완료된 시간과 상태를 기록해 둡니다(상태 위의 줄에 'OK'로 표시됨).
 
참고: 'sched.sh' 스크립트는 HFScheck가 마지막으로 실행된 시간과 성공 여부를 식별하는 데에 사용할 수도 있습니다.
 
hfscheck 작업이 실패한 경우, 즉시 조사해야 합니다.
 
hfscheck가 최근에 실행되지 않은 경우 Avamar Utility Node에서 dpnctl status maint 명령을 실행하여 유지 보수 스케줄러가 활성화되었는지 확인합니다
.
admin@utilitynode:~/>: dpnctl status maint
Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

  • 유지 보수 기간 스케줄러가 다운되었거나 비활성화되었거나 일시 중단된 경우 dpnctl start maint 명령을 사용하여 스케줄러를 활성화합니다.
  • 필요에 따라 새 체크포인트를 생성하고 hfscheck를 실행하거나 예약된 다음 유지 보수 기간이 완료될 때까지 기다립니다.


문제를 해결하거나 유지 보수 스케줄러를 다시 시작한 후 hfscheck가 성공적으로 완료되면 가장 오래된 체크포인트가 'rolled off' 상태가 되고 운영 체제 용량이 크게 줄어듭니다.

  • 운영 체제 용량이 여전히 너무 높고 MSG_ERR_DISKFULL 메시지가 표시되면서 가비지 컬렉션이 계속 실패하는 경우, Dell 기술 지원 팀에 지원을 요청하십시오.
  • 그렇지 않고 운영 체제 용량이 부족하여 가비지 컬렉션을 완료할 수 없는 경우, "사용자 용량"을 낮춘 상태로 작업하고 "서버 활용도" 수치를 낮춥니다.

 

 

높은 사용자 용량을 낮추는 조치:


운영 체제 용량과 달리 사용자 용량 수준은 Avamar 시스템 관리자의 영향을 더욱더 쉽고 직접적으로 받습니다.

1. 가비지 컬렉션이 매일 실행되고 있는지, 백업으로 인해 중단되지 않는지 확인합니다.


가비지 컬렉션이 정기적으로 실행되지 않거나 안정적으로 실행되지 않을 경우 적절한 크기의 시스템에서도 사용자 용량이 빠르게 증가하기 때문에 이는 가장 중요한 포인트입니다.

앞서 설명한 것처럼 유지 보수 기간이 활성화되어 있는지 확인하고 capacity.shsched.sh 스크립트를 사용하여 가비지 컬렉션이 실행 중인지, 데이터가 제거되고 있는지 확인합니다.

Avamar v7.x 이전에는 가비지 컬렉션 "제한" 기간 동안 백업을 실행할 수 없었습니다.

Avamar v7.x 기능에 도입된 해시 참조 비트 맵 기능을 사용하면 가비지 컬렉션 유지 보수 작업 중에 백업을 수행할 수 있습니다. 이 기능을 사용하려면 이러한 "maps"를 재설정할 수 있도록 백업이 실행되지 않는 동안 매일 5분 이상의 "quiet" 시간이 있어야 합니다.

이 기능에 대한 내용은 다음 문서에 대한 링크를 사용하여 액세스할 수 있습니다. Avamar: Avamar v7에서 가비지 컬렉션이 데이터가 사용 중일 때 "Hash Referenced Bit Maps"으로 인해 정리할 수 없는 "skipped-hashes"를 보고합니다.


2. 그리드에 새 클라이언트 추가를 중지
 


Avamar 그리드가 용량에 도달하면 상황이 악화되지 않도록 새 클라이언트 추가를 즉시 중지해야 합니다.

서버 활용도가 낮은 다른 Avamar 그리드가 실행 중인 경우 서버가 꽉 차는 대신 해당 그리드에 새 클라이언트를 추가하는 것이 좋습니다.


3. 가장 많은 스토리지 공간을 소비하고 있는 클라이언트에 대해 알아봅니다.

용량 문제를 해결하려면 Avamar 시스템에 가장 많은 데이터를 추가해야 하는 클라이언트를 식별해야 합니다.

Avamar Utility Node 명령줄에서 실행되는 capacity.sh 스크립트를 사용하여 변경률이 가장 높은 클라이언트를 식별할 수도 있습니다.

Dell 등록 사용자는 문서 Avamar: 스크립트를 사용하여 용량을 관리하는 방법에서 capacity.sh 스크립트 사용 방법에 대한 자세한 내용을 참조하십시오.

'가장 시급한' 클라이언트는 SQL 데이터베이스나 이메일 서버를 백업하는 클라이언트이므로 이들에게 특히 주의를 기울여야 합니다.


4. 보존 정책 재평가
 

변경률이 높은 클라이언트를 식별한 후 보존 정책을 재평가하여 스토리지 요구 사항을 허용 가능한 수준으로 낮추기 위해 정책을 축소할 수 있는지 확인합니다.

참고: 보존 정책을 14일 이상으로 설정하는 것이 좋습니다.

시스템이 오래되어 가장 오래 보존된 백업을 만료하기 시작한 경우, 보존 정책을 축소한 후 가비지 컬렉션으로 매일 제거된 데이터의 양이 증가할 것으로 예상됩니다. capacity.sh를 사용하여 이 추세를 모니터링합니다.

Avamar 시스템이 아직 오래되지 않아 백업 만료가 시작되지 않은 경우, 가장 오래된 백업이 이제 만료되기 시작하도록 보존 정책을 변경해야 할 수 있습니다.

규제 요건으로 인해 보존 정책을 축소할 수 없는 경우, Avamar 시스템을 확장하거나 클라이언트를 활용도가 낮은 다른 Avamar 시스템으로 마이그레이션할 것을 고려해야 합니다.


5. 클라이언트를 다른 Avamar 시스템으로 마이그레이션


다른 Avamar 시스템을 사용할 수 있는 경우, Avamar Client Manager 인터페이스를 사용하여 변경률이 크거나 높은 클라이언트를 활용도가 높은 시스템에서 활용도가 낮은 시스템으로 마이그레이션할 수 있는지 고려합니다.

참고:
  • 새 Avamar Server에는 마이그레이션하려는 Avamar Client를 위한 충분한 스토리지가 필요합니다.
  • 클라이언트가 동일한 Avamar 시스템에서 유사한 유형의 데이터를 유지하도록 하여 중복 제거 효율성을 이용합니다.
  • 이 전략은 Avamar 시스템이 동일한 LAN(Local Area Network)에 있는 경우 가장 많이 사용됩니다.


6. 이전 백업 삭제
 

사용자 용량 수준이 심각한 경우(>90%) 백업 관리 인터페이스를 통해 또는 modify-snapups 툴을 사용하여 이전 백업을 만료해야 할 수 있습니다. 

Dell 사용자는 문서 Avamar 용량 관리: "modify-snapup" 툴을 사용하여 대량으로 백업을 삭제하거나 만료하는 방법에 대한 링크를 사용하여 콘텐츠에 액세스할 수 있습니다.

백업을 삭제해도 서버 활용도 수준이 즉시 낮아지지 않습니다. 다음에 가비지 컬렉션이 실행될 때 가비지 컬렉션을 통해 데이터 제거를 시작할 수 있습니다. 오래된 백업을 삭제하는 것은 단기적인 해결 방법입니다. 백업은 향후 며칠 동안 교체됩니다. 백업이 삭제되면 보존 정책도 조정해야 합니다.


7. capacity.sh를 사용하여 데이터 변경 모니터링
 

백업이 삭제되고 보존 정책이 변경된 후 capacity.sh 스크립트를 사용하여 시스템의 데이터 변경 양을 면밀하게 모니터링합니다. "Removed" 데이터값이 증가하기 시작하고 "Net Change" 값이 음수가 되어야 합니다. 결국 초과 데이터가 시스템에서 지워지기 때문에 "Removed" 값이 더 일반적인 수준으로 돌아가기 시작합니다. "Removed" 값을 계속 모니터링합니다.

Net Change 값이 음수가 되지 않는 경우 가비지 컬렉션 로그를 확인하여 가비지 컬렉션이 실행되는 시간과 유지 보수 기간 내에서 수행되는 작업의 양을 확인합니다.

Dell 사용자는 문서 Avamar: 스크립트를 사용하여 용량을 관리하는 방법에 대한 링크를 사용하여 capacity.sh 스크립트 사용 방법에 대한 자세한 내용에 액세스할 수 있습니다.


8. Avamar 시스템 확장:


Avamar 시스템의 높은 활용도는 자연스럽고 예상되는 데이터 증가로 인해 발생하는 경우가 많습니다. 운영 백업을 계속하려면 더 많은 공간을 사용할 수 있어야 합니다.

이 작업을 수행하는 방법은 Avamar 시스템의 유형에 따라 다릅니다.

  • 단일 노드 시스템 및 AVE(Avamar Virtual Edition) 시스템

이러한 시스템은 확장할 수 없습니다. 더 큰 규모의 두 번째 Avamar 시스템을 시운전하고 소규모 시스템에서 대규모 시스템으로 시스템 마이그레이션을 수행하도록 Dell Professional Services에 요청합니다. 전문 서비스는 Dell 어카운트 매니저를 통해 문의할 수 있습니다.

새 시스템은 소스보다 더 많은 스토리지 공간을 제공하는 경우 단일 노드, AVE 또는 다중 노드 시스템일 수 있습니다.

  • 다중 노드 시스템

이러한 시스템은 최대 16개의 데이터 노드로 확장될 수 있습니다. 자세한 내용은 Dell 어카운트 매니저에게 문의하십시오. 일반 지원 채널에서는 노드 추가를 수행하지 않으므로 이 작업을 요청하기 위해 서비스 요청을 열어서는 안 됩니다.

  • Data Domain 통합

Data Domain 시스템을 백엔드 스토리지 디바이스로 통합하는 것은 Avamar에 백업하는 클라이언트에서 사용할 수 있는 용량을 확장하는 유용한 방법입니다. Dell 어카운트 매니저와 함께 옵션을 논의하십시오.

 

其他信息

유용한 툴

  • status.dpn
  • capacity.sh
  • Avalanche
  • DPN 요약 보고서
  • replcnt.sh
  • Avamar Client Manager


모범 사례:

  • Avamar Server 활용도(사용자 용량) 값이 80% 이상 상승하지 않도록 합니다.
  • 사용자 용량이 낮으면 추가된 데이터양의 예기치 않은 변경에 대한 회복탄력성이 제공되며, 예기치 않은 장애 또는 유지 보수 작업에 대한 단기 문제가 발생할 경우 시스템을 사용할 수 없게 되는 것을 방지할 수 있습니다.
  • Avamar 시스템에서 80% 이상의 사용자 용량을 실행하려면 시스템 관리자가 유지 보수 작업을 성공적으로 완료하고 시스템이 읽기 전용이 되지 않도록 더 철저하게 모니터링해야 합니다.

受影响的产品

Avamar

产品

Avamar
文章属性
文章编号: 000079977
文章类型: Solution
上次修改时间: 07 6月 2024
版本:  18
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。