Avamar 공간 재확보 프로세스 - 2부: 재정

Avamar에서 '위기'는 무엇입니까?

가비지 컬렉션은 백업에서 더 이상 참조되지 않는 데이터를 식별합니다.
삭제할 청크를 나타내기 위해 청크 헤더 설명자가 수정됩니다. 이러한 청크를 포함하는 데이터 스트라이프는 변경되지 않습니다.
이러한 청크를 제거하는 것은 위기 작업의 부작용으로 발생합니다.

크런칭은 가비지 수집 스트라이프를 수정하여 해당 스트라이프 내의 사용 가능한 공간을 인접하게 만드는 Avamar 유지 보수 작업입니다. 
Avamar는 스트라이프를 조작하여 여유 공간을 연속적으로 만들어 들어오는 백업 데이터를 위한 공간을 효율적으로 재사용합니다.

하드 디스크의 클래식 조각 모음과 비슷한 방식으로 바치는 것을 생각해 보십시오. 
데이터 컨테이너 를 보다 효율적으로 재사용하려면 데이터를 한 곳에서 다른 곳으로 이동해야 합니다.

디스크 조각 모음 유틸리티는 데이터의 관련 요소를 순환 하드 디스크의 인접한 부분으로 이동하여 순차적 액세스 시간을 단축합니다.
하지만 데이터를 스트라이프 하단으로 이동하여 새 청크를 위한 공간을 확보합니다.

비유:

전면 입구 도어가 하나 있고 종료 도어가 없는 버스를 상상해 보십시오. 전면 도어를 사용하여 사람(청크)이 버스에 들어갑니다. 
이 버스는 Star Sinclair 'beam me up Scotty' 기술을 사용하여서만 출발할 수 있는 특별 버스입니다. 
버스가 가득 차서 시작합니다. 
여러 사람이 비물질화되면 버스에 더 많은 승객의 공간이 있습니다.
다른 누구도 입구에서 멀리 떨어진 곳으로 이동할 때까지 다른 사람을 맞출 수 없습니다. 즉, 전면 도어 근처에 공간을 만들기 위해 버스 후면을 향해 '위기'를 가했습니다.

위기 해결이 중요한 이유:

백업 데이터가 Avamar에 기록될 때 발생하는 일에 대해 설명합니다. 이는 위기 해결이 중요한 이유를 설명합니다.

백업 데이터 수락을 준비하기 위해 Avamar는 인접한 사용 가능한 공간이 가장 많은 각 데이터 노드에서 스트라이프를 선택합니다. 스트라이프는 활성 스트라이프로 표시됩니다. 
새로 들어오는 백업 데이터가 활성 스트라이프에 추가됩니다. 
스트라이프가 가득 차면 다음으로 가장 전체 스트라이프가 활성 스트라이프로 표시됩니다.

부족한 위기 상황이 발생한 시스템을 상상해 보십시오.
'위기' 스트라이프(가비지 수집되었지만 아직 처리되지 않은 경우)는 비교적 비어 있을 수 있습니다. 
인접한 여유 공간이 더 많은 다른 스트라이프가 있는 경우 이 비교적 빈 스트라이프가 활성 스트라이프로 선택되지 않습니다. 

아래 다이어그램에서 다이어그램의 두 스트라이프가 모두 가비지 수집되었지만 데이터 스트라이프 2만 처리되었습니다.

데이터 스트라이프 1은 선명하지만 스트라이프 2는 연속된 공간을 더 유용하게 사용합니다. 
Avamar는 스트라이프 2를 활성 스트라이프로 선택합니다. 

Avamar 스토리지 활용도가 증가함에 따라 점점 더 전체 스트라이프 풀에서 활성 스트라이프가 선택됩니다.

바래싱이 기한이 지난 경우 스트라이프 재사용이 비효율적입니다. 
해당 데이터의 양이 변경되지 않더라도 수신되는 데이터를 평균 하루 동안 캡처하려면 더 많은 스트라이프가 필요합니다. 
더 많은 스트라이프를 사용하여 데이터를 캡처하면 스트라이프를 더 효율적으로 재사용할 때보다 체크포인트 오버헤드가 높아집니다.

이러한 이유로 Avamar가 정기적으로 충분한 작업을 수행할 수 있도록 항상 해야 합니다.

위기는 어떻게 작동합니까? 

시스템이 스트라이프에서 바런싱을 수행하는 경우 다음을 수행합니다.

• 커서 디렉토리의 스트라이프 파일에서 메모리로 데이터를 읽습니다.
• 청크 헤더에서 참조되는 청크를 결정합니다.
• 스트라이프 파일 및 청크 헤더를 디스크에 다시 씁니다. 스트라이프 파일은 청크 헤더에서 참조하는 항목으로만 채워집니다.

스트라이프 파일을 수정하면 하드 링크가 끊어지면서 파일 시스템 활용도가 높아집니다. 
Avamar 버전 5.0 이상에서 스트라이프는 바닝 후 전체 크기로 유지됩니다. 이렇게 하면 시간이 지남에 따라 파일 시스템 조각화를 방지할 수 있습니다.

위기는 언제 발생합니까?

비동기식 위기 - 기본값과 바닝을 수행하는 기본 방법입니다.

비동기식 위기는 "Blackout Window"의 후자의 부분에서 가비지 컬렉션 시간이 초과된 후 다음 상황에서만 실행됩니다.

• 비동기식 매개변수가 true로 설정된 경우
• 바런치 스트라이프가 있는 경우*.
• 그리고 목표 또는 일일 한도에 도달하지 못한 경우*.
• 그리고 시스템이 유휴 상태인 경우*(백업 또는 기타 유지 보수가 진행 중이 아님).
• 시스템에 쓰기가 가능하고 disknoflush에 도달하지 않은 경우

비동기식 위기는 선제적인 작업입니다. 
전용 시간과 리소스를 사용하여 백업 기간 전에 스트라이프를 준비합니다. 
이를 보여주는 연결된 다이어그램 blackout-window.jpg를 참조하십시오.

위기 처리가 수행하는 작업은 얼마나 됩니까?

블랙아웃 기간 동안 사용할 스트라이프를 미리 준비하면 Avamar가 백업 스케줄 중에 가능한 한 빨리 데이터를 수집할 수 있습니다. 
바치는 것은 스트라이프의 내용을 바뀝니다. 많은 위기로 인해 'cur' 디렉토리에 저장된 데이터와 큰 차이가 발생합니다. 
이로 인해 체크포인트 오버헤드가 증가하고 데이터 노드 데이터/ 파티션의 공간 사용량이 증가합니다.

Avamar는 다음 날 예상되는 수신 데이터의 양을 수용하기 위해 준비해야 하는 스트라이프 수를 예측합니다. 
계산은 이전 N 일수의 이동 평균(예: N은 최대 10 또는 14)을 기준으로 합니다. 
이 자체 튜닝 메커니즘을 통해 Avamar는 불필요한 양의 체크포인트 오버헤드를 유발하지 않으면서 백업이 최적으로 수행될 수 있도록 충분한 스트라이프를 처리할 수 있습니다. 

이제 시스템의 변경률이 갑자기 증가하면 Avamar가 증가된 위기 제한을 점진적으로 도입하는 데 며칠이 걸린다는 것을 이해할 수 있습니다.

비동기식 크런칭이 스트라이프를 충분히 준비하지 못하는 경우 동기식 위기 처리로 처리됩니다.

동기식 위기 해결:

비동기식 크런칭으로 충분한 스트라이프를 미리 준비할 수 없거나 비동기식 매개변수가 false로 설정된 경우, 백업과 동기식으로 크런싱이 실행됩니다. 
필요 시 위기 처리라고도 하는 이 위기 처리 모드는 필요할 때 실행되며 스트라이프를 처리할 수 있고 노드의 활성 스트라이프가 될 준비를 하는 경우 스트라이프에서 작동합니다.

백업과 동기식으로 실행되도록 허용하면 디스크 I/O 리소스에 대한 경쟁이 심화됩니다. 
사용량이 많은 시스템에서 백업 작업이 완료되는 데 시간이 오래 걸릴 수 있습니다. 

시스템에서 체크포인트 오버헤드가 높은 상황에서는 동기식 위기만 수행하도록 Avamar를 설정할 수 있습니다. 이 작업이 완료되면 고객에게 왜 필요하다고 생각되는지 알리고 타협을 설명합니다.

A 두 가지 위기 모드 요약:

비동기식 위기 해결:

• Avamar 서버 매개변수 설정은 asynccrunching=true.
• 일반적인 데이터 수집 시 백업 성능이 향상됩니다.
• 체크포인트 오버헤드가 높아질 수 있습니다.
• 기본 작동 모드입니다.
• 운영 체제 용량이 많은 상황에서 체크포인트 오버헤드를 줄이기 위해 비활성화할 수 있습니다.

동기식 위기 해결:

• Avamar 서버 매개변수 설정은 asynccrunching=false
• 필요에 따라 실행
• 체크포인트 오버헤드 요구 사항 감소
• 백업 시간이 길어질 수 있습니다.
• 기본 작업 모드가 아님

비동기식 위기 발생을 방지할 수 있는 것은 무엇입니까?

 비동기식 구성 매개변수는 false입니다.

• 백업이 진행 중입니다.
• 일일 제한에 도달했습니다.
• 서버는 읽기 전용입니다.
• 서버 실행 레벨이 "admin"보다 낮습니다.
• 스트라이프 변환이 진행 중입니다.
• disknoflush 제한에 도달했습니다.
• 적용된 Avamar 서버가 hfscheck 인스턴스를 실행합니다(CGSAN이라고도 함).
• HFScheck 시작 중