Avamar: 백업 성능 행동 및 이론

이 문서의 목적은 독자가 백업 성능 동작을 이해하는 데 중점을 두고 Avamar 백업 중에 발생하는 상황을 설명하는 것입니다.

이 문서는 다음 문서와 함께 제공됩니다.

• Avamar: 백업 성능 저하 문제 해결
• Avamar: 신속하게 완료되도록 백업 튜닝

Avamar 백업 중에는 어떻게 됩니까?

avtar 백업 프로세스:

1) 파일 및 해시 캐시 파일을 메모리에 로드합니다.

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) VSS 스냅샷을 생성합니다(Windows의 경우).

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) 데이터 세트에 의해 정의된 모든 파일 안내 소스 데이터 세트
내의 모든 파일에 대해 avtar는 전체 경로를 가져와서 통계와 유사한 메타데이터와 결합하여 해시를 계산하여 파일을 고유하게 식별합니다.

자세한 내용은 다음을 참조하십시오. Avamar: avtar가 파일 검색 단계에서 파일을 읽으면 어떻게 됩니까?

4) 계산된 해시를 로컬 클라이언트 캐시의 해시와 비교합니다

. Avtar는 파일 캐시에서 파일의 해시를 조회합니다. 새 백업인지 또는 이전 백업 이후에 수정되었는지 여부를 확인합니다.

파일 캐시 조회가 성공하면 파일이 존재하고 변경되지 않습니다.

조회에 실패하면 파일이 새 파일이거나 변경된 파일입니다. 읽고 처리해야 합니다.

자세한 내용은 Avamar Client - avtar에서 파일이 수정된 것으로 간주하기 전에 변경해야 할 사항은 무엇입니까?를 참조하십시오.

5) 새 파일 및 수정된 파일

처리 avtar는 다음을 수행해야 합니다.

• 전체 파일 읽기
• 가변 크기의 청크로 나눕니다.
• 각 청크 압축
• 각 청크에 대한 해시 계산

6) Avamar Server에 누락된 해시가 있는지 확인합니다.

Avtar 는 누락된 해시에 대한 데이터를 네트워크를 통해 Avamar Server로 전송하여 해시가 이미 존재하는지 확인합니다. 이를 'ispresent' 요청이라고 합니다.

7) 데이터가 Avamar Server(및 필요한 경우 Data Domain)에 기록됩니다. 

워크플로에 대한 자세한 내용은 첨부된 Avtarprocess.pdf 참조하십시오.


성능 관점에서 본 Avamar 백업 개요:

위의 단계를 따라 백업 성능

에 가장 큰 영향을 미치는 '단계'로 구분합니다. 0단계. VSS 스냅샷을 생성합니다.

VSS(Volume Shadowcopy Service)는 소스 데이터 세트 내에 지정된 볼륨의 스냅샷을 생성합니다. 백업이 실행되는 동안 애플리케이션은 볼륨에 계속 쓸 수 있습니다.
Avamar는 쓰기 가능한 볼륨이 아닌 볼륨의 읽기 전용 '고정' 스냅샷을 백업합니다. 이를 통해 백업할 데이터 세트의 일관성을 유지할 수 있습니다.

VSS 스냅샷은 완료하는 데 몇 초 정도 걸립니다. 클라이언트에 VSS 문제가 발생하면 백업이 지연되거나 진행되지 않습니다.

1 단계. 파일 검사 단계. avtar 프로세스는 타겟 데이터 세트

의 모든 파일을 통계합니다수백만 개의 파일이 있는 클라이언트의 경우 이 단계가 가장 많은 시간이 소요될 수 있습니다.
데이터베이스 데이터에는 크기가 큰 파일이 거의 포함되어 있지 않으므로 파일 검색 단계는 시간이 거의 걸리지 않습니다. 데이터베이스 클라이언트는 일반적으로 #2 단계에서 시간을 소비합니다.

RAID 5 구성의 회전 디스크가 있는 클라이언트의 경우 시간당 ~100만 개의 파일 스캔 성능이 일반적입니다. 이것은 시간당 300,000에서 300만까지 다양합니다. 클라이언트 환경 및 백업되는 데이터의 특성에 따라 다릅니다.

v7.3부터 Data Domain으로 백업하는 Linux 클라이언트는 Linux LFI(Fast Incremental) 기능을 활용할 수 있습니다. 이렇게 하면 백업이 실행될 때마다 전체 데이터 세트를 검사하지 않아도 됩니다.

중요 리소스: 백업 데이터가 저장된 디스크의 임의 탐색 성능입니다.

2 단계. Avtar는 변경된 파일을 읽은 다음 데이터를 청크, 압축 및 해시합니다.

이 단계에서는 많은 계산이 수행됩니다. 수정된 파일 또는 새 파일 각각에 대해 avtar은 이 파일을 작은 청크로 나눕니다. 각 청크를 압축하고 해시를 '지문'으로 계산하여 청크를 식별합니다.

데이터베이스 백업의 파일은 크기가 크고 매일 변경되는 경우가 많습니다. Avtar 는 이 단계에서 대부분의 시간을 보냅니다. 증분 백업 기능, 트랜잭션 로그 등을 활용하여 데이터베이스를 효율적으로 처리하려면 공식 Avamar 데이터베이스 플러그인을 사용하는 것이 가장 좋습니다.

일반적인 파일 처리 성능은 시간당 약 100GB이지만 시간당 최대 300GB까지 달라질 수 있습니다. 이는 환경에 따라 다릅니다.

중요 리소스: 클라이언트 디스크 및 CPU

Avamar Server로 데이터를 전송하는 데 병목 현상이 없는 LAN 백업의 경우 #1 및 #2 단계에서 가장 많은 시간이 소요됩니다.

다음 차트에서 그래프 막대의 영역 크기는 백업 시간에 해당한다고 가정합니다. 파일이 변경되면 특히 파일이 큰 경우 필요한 시간이 크게 늘어날 수 있습니다.

파일 시스템 데이터 세트의 경우 매일 파일의 ~0-3%가 변경될 것으로 예상됩니다.

Avtar 는 파일 특성을 확인하는 작업과 보안 속성을 확인하는 I/O 작업 등 두 개의 I/O 작업을 수행하여 변경되는 각 파일을 'stat()'해야 합니다.

파일 시스템 백업에 대해 시간당 1~100만 개의 파일 벤치마크 검색 속도 성능을 달성하려면 avtar 에 시간당 약 200만 개의 seek 작업 또는 초당 600개의 seek 작업이 필요합니다.

예: 백업의 변경률이 3%인 경우 변경 여부를 식별하기 위해 100개 파일 중 97개 파일에 대해 두 개의 디스크 검색 작업이 필요합니다. 변경된 나머지 세 개는 스캔, 청크, 압축 및 해싱해야 합니다.

파일 검색 단계만 고려하고 수정된 파일을 처리하는 데 필요한 I/O 리소스는 고려하지 않습니다.
수정된 파일 내에 데이터가 많을수록 백업을 완료하는 데 더 많은 작업이 필요합니다.

3 단계. Avamar Server

에 해시가 있는지 확인#1 및 #2단계는 백업의 요소를 가리키는 해시를 생성합니다. 이러한 요소는 고유한 파일 청크, 파일 시스템 또는 전체 백업일 수 있습니다.

해시는 클라이언트 캐시 파일에 기록되고 Avamar Server에 있는 해시와 비교하여 추가해야 할 새 데이터가 있는지 확인합니다. 이는 Avamar Server 또는 Data Domain이 타겟 스토리지인 경우에도 마찬가지입니다.

Avamar Client와 Server 간의 해시 비교는 일반적으로 빠릅니다. Avamar Server가 백업 병목 현상을 일으키지 않아야 합니다.

• 건강
• 일정한 부하 수준에서
• 클라이언트와 동일한 LAN 세그먼트에 위치

해시의 크기가 20바이트에 불과하기 때문에 이 단계는 네트워크 대역폭보다 네트워크 대기 시간의 영향을 더 많이 받습니다. 해시가 Avamar Server에 도착하면 데이터 노드 디스크 하위 시스템의 일반적인 로드 및 임의 검색 성능에 따라 해시가 검색되고 클라이언트에서 보낸 해시와 비교되는 속도가 결정됩니다.

중요 리소스: 네트워크 응답 시간 및 Avamar 데이터 노드 Random Seek 성능

물리적 Avamar의 임의 검색 성능은 데이터 노드의 수와 크기에 따라 달라집니다. AVE 시스템은 단일 노드 시스템에 비해 성능이 떨어집니다.

4 단계. 네트워크를 통해 새 청크를 Avamar Server 또는 Data Domain

으로 전송클라이언트가 새로운 고유 청크(최대 64KB 크기)를 서버로 보낼 때 성능은 주로 네트워크 대역폭에 좌우됩니다. 이는 주로 매일 많은 양의 변경된 데이터를 생성하는 WAN 기반 클라이언트에 영향을 줍니다. 또한 혼잡한 네트워크 링크를 통해 작동하는 사람들에게도 영향을 미칠 수 있습니다. 

다음은 클라이언트가 Avamar 시스템과 Avamar - Data Domain 통합 시스템으로 데이터를 전송하는 데이터 흐름을 보여주는 회로도입니다.






중요 리소스: 클라이언트와 서버

간의 네트워크 대역폭5단계. Avamar Server 또는 Data Domain

에 쓴 데이터백업 데이터는 Avamar Server 또는 Data Domain 시스템에 기록해야 합니다.

중요 리소스: Avamar Server 디스크 쓰기 성능 및 일반 로드