Avamar: OS(Operating System) 용량(해결 경로)

Summary: 이 해결 경로 문서는 Avamar에서 OS(Operating System) 용량 문제를 처리하거나 해결하기 위한 것입니다.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Avamar

에서 OS 용량 문제를 처리하는 방법이 해결 경로 문서는 Avamar의 OS 용량 문제를 해결하도록 설계되었습니다.


OS 용량에 대한 초기 개념 및 이해는 교육 문서 Avamar: 용량 관리 개념 및 교육

교육 문서에서 요약한 대로 이 문서의 나머지 부분을 진행하려면 다음 항목에 대한 합리적인 이해가 필요합니다.

  • 체크포인트(cp), 체크포인트 검증(hfscheck), 가비지 컬렉션(GC) 및 각각의 중요성
  • 차이점: GSAN (일명 "사용자 용량" 및 OS 용량)
  • 체크포인트 오버헤드 데이터
  • 데이터 파티션이 총 물리적 OS 용량 공간의 89%를 초과하는 데이터 파티션이 있으면 가비지 컬렉션을 실행할 수 없습니다.
  • Avamar 그리드가 100% 사용자 용량에 가까울수록 체크포인트 오버헤드에 사용할 수 있는 OS 용량이 줄어듭니다.
  • 체크포인트 오버헤드에 기여하는 요인: 비동기 크런칭, 저장된 체크포인트 수, HFSCheck 및 체크포인트 유효성 검사 중요도 등.
  • OS 용량 수준을 찾는 방법
  • OS 용량을 완화하기 위한 기본 작업

 

OS 용량을 GSAN data(더 구체적으로 말하면 이 데이터에 할당된 공간) 및 Avamar 체크포인트에서 생성된 오버헤드. 체크포인트 수가 많고 변경률이 높을수록 체크포인트 오버헤드가 커집니다.


높은 OS 용량의 영향에는 다음이 포함될 수 있습니다.

  • 가비지 컬렉션 실패: MSG_ERR_DISKFULL로 GC 실패 OS 용량이 89%를 초과하는 경우
  • 백업 또는 복제 실패: OS 용량이 90% 이상으로 증가하면 MSG_ERR_STRIPECREATE 함께 백업 또는 수신 복제가 실패할 수 있습니다. (새 데이터 스트라이프를 만들어야 하는 경우에만 해당됩니다. 새 스트라이프가 필요하지 않은 경우에도 백업 및 복제가 성공적으로 실행될 수 있습니다.)
  • 체크포인트 실패: OS 용량이 96%를 초과하면 체크포인트가 MSG_ERR_DISKFULL와 함께 실패합니다.


위에서 알 수 있듯이 OS 용량은 다른 Avamar 용량이 높을 때 해결해야 하는 첫 번째 Avamar 용량 유형인 경우가 많습니다. 최소한 가비지 컬렉션은 OS 용량이 특정 수준에 도달하면 실행할 수 없습니다. GSAN 또는 사용자 용량도 높습니다.

일반적으로 OS 용량이 89% 이상으로 증가하는 경우 GC가 MSG_ERR_DISKFULL에 실패하면 OS 용량이 높은 것으로 간주됩니다. OS 용량이 89% 미만이면 유지 보수 작업에 영향을 미치지 않습니다. 

 
참고: OS 용량은 하루 종일 변동될 것으로 예상됩니다. 일상적인 유지 보수 작업이 원활하게 실행되는지 확인하는 것이 중요하며, 일반적으로 가능한 경우 OS 용량 문제를 방지하기 위한 최상의 솔루션입니다.
 
참고: 위 항목은 Avamar OS 용량으로 표시되지만 백업 파티션 또는 체크포인트와 직접적인 관련이 없는 OS 용량 문제가 있을 수 있습니다. Linux OS가 설치된 디스크 및 파티션입니다. 이러한 문제는 덜 일반적이지만 아래에서 설명하는 다른 영향을 미칠 수 있습니다.

Cause

Avamar OS 용량은 다음과 같은 복합적인 이유로 인해 증가할 수 있습니다.

  • 백업 데이터의 높은 변경률, "너무 많이, 너무 빠름" 추가
  • 높음 GSAN 또는 "User Capacity"를 사용하면 OS 용량을 위한 공간이 줄어들고 경우에 따라 변경률이 높아질 수도 있습니다.
  • 체크포인트를 완료하지 못하여 출력에 표시된 상태가 "MSG_ERR_DISKFULL"로 나타납니다.
  • 체크포인트 검증(hfscheck) 이(가) 실패했거나 최근에 실행되지 않아 가장 오래된 체크포인트를 롤오프하거나 제거할 수 없습니다.
  • 너무 높은 체크포인트 보존 설정을 포함하여 다른 이유로 체크포인트가 롤오프되지 않음
 

다른 디스크 파티션의 높은 OS 용량은 잘못된 데이터 배치, 로그 파일 너무 크기 등 다양한 원인으로 인해 발생할 수 있습니다.

 
높은 OS 용량의 원인으로 "너무 많이, 너무 빠르게"라는 문구에 대한 간략한 설명은 다음과 같이 설명할 수 있습니다.
  • 간단히 배경을 설명하자면, Avamar 체크포인트는 읽기 전용 스냅샷이며 라이브 데이터에 대한 링크입니다. 이 체크포인트는 링크를 사용하여 생성되기 때문에 체크포인트는 생성된 직후 추가 디스크 공간을 0으로 사용합니다. 라이브 데이터에 변경 사항이 없는 경우 체크포인트는 추가 공간을 사용하지 않습니다.
  • 이는 체크포인트가 동일하게 유지되는 동안 라이브 데이터가 수정됨에 따라 변경됩니다. 이 시점에서 체크포인트에 데이터의 원본 복사본과 수정된 데이터의 업데이트된 Live Copy가 있습니다. 이것은 전적으로 의도적이고 의도적인 것입니다. 따라서 예약된 OS 용량 공간이 있습니다.
  • 그러나 변경 데이터의 양 또는 비율이 급격하고 갑작스럽게 증가하는 경우 OS 용량 크기가 드물게 급증하여 "너무 많이, 너무 빠른" 것으로 간주될 수 있습니다.
  • 이 capacity.sh 도구는 며칠 동안 출력을 비교할 때 이를 원인으로 표시합니다.

Resolution

높은 Avamar OS 용량으로 인해 가비지 컬렉션을 포함한 유지 보수 작업이 실패하는 경우 다음 단계를 수행하십시오.

1. 모든 Avamar 용량 정보를 수집하여 상황을 그림으로 그립니다. Avamar: 용량 문제 해결에 필요한 정보를 수집하는 방법


2. 그런 다음 OS 용량이 얼마나 높은지, 어떤 조치가 필요할 수 있는지 검토합니다. 데이터 수집 문서에서 다음 명령을 사용하여 찾을 수 있습니다. 

avmaint nodelist | egrep 'nodetag|fs-percent-full'
 

Avamar의 작동 방식은 표시된 fs-percent-full의 HIGHEST 값이 현재 OS 용량의 제한 요소입니다. 노드 유형 생성 및 크기에 따라 백업 및 체크포인트 데이터를 저장하는 데이터 파티션 수가 달라질 수 있습니다. Linux 운영 체제에서 볼 수 있듯이 이는 "/data0*"과 같은 디스크 또는 파티션일 수 있습니다. 여기서 "*"는 한 자리 숫자일 수 있습니다. 데이터 파티션 수는 노드 유형, 하드웨어 세대 및 크기에 따라 다릅니다(변경할 수 없음).


3. 검색된 체크포인트의 수와 명령에서 얼마나 최근에 검증되었는지 검토합니다.

cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980
 
참고: 일부 체크포인트는 항상 유지해야 합니다.
 
 

4. 다음 명령을 실행하여 "MSG_ERR_DISKFULL"에서 체크포인트 작업이 실패하는지 확인합니다.

dumpmaintlogs --types=cp --days=4 | grep "\<430"


체크포인트가 성공적으로 완료되면 다음과 유사한 출력이 표시됩니다.

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance


MSG_ERR_DISKFULL으로 인해 실패한 경우 다음 출력이 표시됩니다.

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
 
체크포인트 작업이 MSG_ERR_DISKFULL 오류로 인해 실패하는 경우 Dell Technologies Avamar 지원 팀에 서비스 요청을 개설 합니다. 그렇지 않은 경우 5단계부터 계속합니다.
 
 
5. 다른 체크포인트 문제가 있는지 확인합니다.
 
이 cplist comm만드 검색된 체크포인트 수와 체크포인트가 얼마나 최근에 검증되었는지를 보여줍니다. 데이터 수집 문서에도 나와 있듯이 Avamar - cplist 명령으로 생성된 출력을 이해하는 방법을 참조하여 cplist 출력.

2개 또는 3개의 체크포인트가 있어야 하며, 지난 24시간 동안의 체크포인트 중 하나 이상이 hfscheck명령을 수행할 수 있는 충분한 공간이 있어야 합니다. 이는 정상적으로 실행되며 성공적으로 실행된 모든 작업과 정상적인 체크포인트 보존 설정의 출력입니다.

3개 이상의 체크포인트가 있거나 지난 24시간 이내에 검증된 체크포인트가 없는 경우 OS 용량을 줄이는 유일한 방법일 수 있으므로 이 문제를 먼저 해결해야 합니다. 이 시나리오가 발생하면 Dell Technologies 에 서비스 요청을 개설 합니다. 그렇지 않으면 6단계부터 계속합니다.
 
 

6. 변경률을 결정합니다.

capacity.sh

 

예시 출력:

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

 


때때로 높은 변화율 또는 "너무 많이, 너무 빠른" 상황이 재발하는 경우 이는 전반적인 GSAN 또는 사용자 용량. 더 낮은 GSAN 용량을 선택할 수 있습니다. OS 용량 오버헤드를 위한 공간이 조금 더 많고 결과적으로 데이터 스토리지 컨테이너의 변경 사항도 줄어듭니다. 이 시나리오에 대한 지원을 받으려면 Dell Technologies Avamar 지원 팀에 서비스 요청을 개설 하십시오. 그렇지 않으면 7단계부터 계속합니다.

 

7. 다른 디스크 파티션에서 OS 용량이 높은 문제에는 다양한 원인이 있지만 해결 방법에는 기술 지원이 필요합니다. Dell Technologies Avamar 지원 팀에 서비스 요청을 개설하십시오. 그렇지 않은 경우 7단계부터 계속합니다.

 
 

OS 용량 문제가 해결되면, GSAN 용량 또는 기타 Avamar 용량을 검토할 수 있습니다. Avamar 용량 문제 해결, 문제 및 질문 - 모든 용량(해결 경로)을 참조하십시오.

 

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000169014
Article Type: Solution
Last Modified: 12 Mar 2025
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.