Direct to S3 Backup을 활성화하면 MongoDB Agent는 Ops Manager가 제공하는 사전 서명된 URL을 사용하여 스냅샷 블록을 S3에 직접 업로드합니다. Ops Manager는 사전 서명된 URL 생성, 블록 매니페스트 추적, 완료 신호 전송과 같은 업로드에 대한 메타데이터만 처리합니다. 스냅샷 데이터 경로는 Ops Manager를 우회하며 더 이상 Ops Manager 서버를 통과하지 않습니다. 이렇게 하면 대규모 배포서버 및 빈번한 백업 예정에 대한 프록시 병목 현상이 제거됩니다.
이 주제에서는 Direct to S3 Backup을 활성화하는 방법과 선택 사항을 구성하는 방법을 설명합니다.
중요
S3 백업으로 직접 이동하려면 Ops Manager 9.0.0 이상 또는 Ops Manager 8.0.27 이상이 필요하며, 백업을 실행하는 모든 호스팅하다에 최소 MongoDB Agent 버전이 필요합니다.
Ops Manager 버전 | 최소 MongoDB Agent 버전 |
|---|---|
9.0 |
|
8.0 |
|
S3 로 직접 백업 작동 방식
백업 작업에서 Direct to S3 Backup이 활성화되고 배포서버의 MongoDB Agent가 최소 버전 요구 사항을 충족하면 MongoDB Ops Manager는 다음 조치를 수행합니다.
Ops Manager는 스냅샷 블록 저장소에 대해 구성된 S3 자격 증명을 사용하여 사전 서명된 업로드 URL을 생성합니다. 이 URL은 블록 저장소가 사용하는 것과 동일한 S3 버킷을 가리킵니다.
MongoDB Ops Manager는 백업 커서 설명에
uploadPath=AGENT_DIRECT_S3을(를) 설정합니다. MongoDB Agent는 이 값을 읽고, 작업에 대한 업로드 경로를 고정하며, 해당 사전 서명된 URL을 사용하여 스냅샷 블록을 S3 (으)로 직접 업로드합니다.MongoDB Ops Manager는 block manifest API를 통해 업로드 완료를 추적합니다.
/dataBlocks프록시 업로드 호출이 발생하지 않습니다.
MongoDB Agent가 스냅샷 데이터를 S3에 직접 업로드하므로 Ops Manager는 더 이상 백업 데이터 경로에 위치하지 않습니다. Ops Manager는 백업 메타데이터에 대해서만 책임을 집니다.
공존 및 폴백
S3 Backup으로 직접 전송되는 백업과 MongoDB Ops Manager를 통해 데이터를 스트리밍하는 표준 백업은 공존할 수 있습니다.
Direct to S3 Backup을 활성화한 작업에서 MongoDB Agent 버전이 최소 버전 미만인 경우 Ops Manager는 표준 경로로 대체됩니다. 이 대체는 MongoDB Agent를 업그레이드할 때까지 지속됩니다. 혼합 버전 플릿은 계속해서 성공적으로 백업됩니다.
버전 요구 사항을 충족하는 배포서버는 Direct to S3 Backup을 사용합니다.
버전 요구 사항을 충족하지 않는 배포서버는 표준 데이터 경로를 사용합니다. MongoDB Agent를 업그레이드한 후 첫 번째 스냅샷에서 작업이 자동으로 Direct to S3 Backup으로 전환되며, 추가 조치는 필요하지 않습니다. 이미 진행 중인 스냅샷은 원래 업로드 경로에서 완료됩니다.
추가적으로, 아래에 설명된 대로 작업에 대해 Direct to S3 백업을 수동으로 활성화하거나 비활성화할 수 있습니다.
참고
S3 백업으로 직접 이동은 스냅샷 블록 데이터에만 적용됩니다. 특정 시점 복구를 위한 oplog 데이터는 구성된 oplog 저장소를 통해 표준 백업 경로를 계속 사용합니다.
전제 조건
S3 로 직접 백업을 활성화하기 전에:
MongoDB Ops Manager 9.0.0 버전 이상 또는 MongoDB Ops Manager 8.0.27 버전 이상을 사용 중인지 확인하세요.
백업을 실행하는 모든 호스트에서 MongoDB Ops Manager 9.0 배포서버의 경우 최소
109.0.0.9279-1, MongoDB Ops Manager 8.0 배포서버의 경우108.0.27.9088-1이상의 MongoDB Agent 버전을 확보 하세요.배포서버에 S3 스냅샷 저장소 (블록 저장소)가 있는지 확인합니다. MongoDB Ops Manager는 블록 저장소가 사용하는 것과 동일한 S3 버킷 및 자격 증명을 사용합니다.
백업 호스팅하다 네트워크 액세스
백업을 실행하는 각 호스팅하다 다음을 수행할 수 있어야 합니다.
S3 또는 S3호환 엔드포인트의 DNS 이름 확인
해당 엔드포인트에 대한 아웃바운드 HTTPS 연결 설정
MongoDB Ops Manager 생성하는 S3 사전 서명된 URL을 사용하여 데이터 업로드
Direct to S3 백업을 활성화하면 대용량 업로드 경로가 MongoDB Ops Manager 애플리케이션 서버에서 MongoDB Agent를 실행하는 모든 호스팅하다로 이동합니다. 이전에는 MongoDB Ops Manager 서버만 S3에 대한 네트워크 액세스 권한이 필요했습니다. 이 기능을 활성화하기 전에 백업 호스트에서 S3 엔드포인트로의 아웃바운드 연결을 확인하십시오.
MongoDB 에이전트는 S3 액세스 키 또는 IAM 역할을 필요로 하지 않습니다. Ops Manager는 스냅샷 저장소에 대해 구성된 S3 자격 증명 사용하여 모든 사전 서명된 URL을 생성합니다. 해당 자격 증명은 읽기뿐만 아니라 버킷에 대한 사전 서명된 PUT 작업도 허용해야 합니다.
S3 으로 직접 백업 활성화합니다.
Direct to S3 백업을 활성화하려면 다음 단계를 완료하세요.
(조건부) 프로젝트에서 S3로 직접 백업을 활성화합니다.
이전 단계에서 플래그를 controlled (으)로 설정한 경우 프로젝트 설정에서 기능을 활성화하세요.
MongoDB Ops Manager 프로젝트 에서 Settings을(를) 클릭합니다.
Beta Features 탭 클릭하고 Backup Direct To S3을 클릭합니다.
(조건부) 기존 백업 작업에서 Direct to S3 Backup을 활성화합니다.
Direct to S3 Backup을 활성화한 프로젝트에서는 새 백업 작업이 이미 Direct to S3 Backup이 활성화된 상태로 시작됩니다. 각 새 작업의 첫 번째 스냅샷은 S3에 직접 업로드되며 작업별 조치는 필요하지 않습니다.
이 기능을 활성화하기 전에 존재했던 백업 작업은 기존 설정을 유지합니다. 모든 작업에서 Direct to S3 Backup을 활성화하거나 비활성화할 수도 있습니다. 작업 설정을 변경하려면 다음을 수행합니다.
Admin, Backup을 클릭한 다음 Jobs을 클릭합니다.
대상 작업의 경우 Direct S3 Backup 행을 찾습니다. 이 행은 작업의 스냅샷 저장소가 S3 블록 저장소인 경우에만 나타납니다.
Direct S3 Backup을 Enabled 또는 Disabled로 설정합니다.
샤딩된 클러스터의 경우 Apply to all cluster members을(를) 선택하여 모든 샤드 및 config 서버에서 기능을 활성화합니다.
Save를 클릭합니다.
모든 호스트에서 에이전트 버전을 확인하세요.
백업을 실행하는 모든 MongoDB Agent의 버전을 확인 하고 MongoDB Ops Manager 배포서버의 최소 버전 요구 사항을 충족하는지 확인하세요.
다음 표는 백업 작업이 Direct to S3 Backup을 사용하는 경우를 요약한 것입니다.
Scenario | 업로드 경로 |
|---|---|
프로젝트에서 기능을 활성화한 후 생성된 작업 | 첫 번째 스냅샷부터 S3 백업으로 직접 이동 |
프로젝트에서 이 기능을 활성화하기 전에 생성된 작업 | 작업에서 Direct to S3 Backup을 활성화하기 전까지의 표준 경로 |
Direct to S3 Backup이 활성화되어 있고 최소 버전 미만의 MongoDB Agent가 있는 작업 | MongoDB Agent를 업그레이드할 때까지의 표준 경로입니다. 업그레이드 후 첫 번째 스냅샷에서 작업이 Direct to S3 Backup으로 전환됩니다. |
선택 사항 관리
다음 선택 사항 설정은 Direct to S3 백업 업로드 성능을 조정합니다.
mms.backup.d2s3.transfer.numWorkersDirect to S3 백업 업로드에 MongoDB Agent가 사용하는 병렬 업로드 작업자 수입니다. 기본값:
2. 작업별 재정의를 설정할 수도 있습니다.다른
mms.backup.*속성과 함께 MongoDB Ops Manager 설정 파일에서 이 설정을 구성합니다. 이 속성을 설정하면 MongoDB Agent는 해당 작업자 수를 정확히 사용하고 자체 자동 튜닝을 건너뜁니다. 설정하지 않으면 MongoDB Agent는 호스팅하는 CPU 및 메모리를 기반으로 작업자 수를 조정합니다.mms.backup.d2s3.transfer.maxNumUnitOfWorkBlocksDirect to S3 업로드 경로에 대한 작업 단위당 최대 블록 수입니다. 설정하지 않으면 MongoDB Agent는 내부 기본값인
100(으)로 대체됩니다.다음 중 하나를 사용하여 이 설정을 구성합니다.
MongoDB Ops Manager 인터페이스에서 전역 MongoDB Ops Manager 구성 설정을 적용합니다.
Jobs 페이지에서 WTCheckpoint Config 대화 상자를 사용하여 작업별 구성을 적용하세요.
참고
S3에 대한 동시 연결 수는 동시에 실행 백업 작업 수에 따라 증가합니다. 배포서버에서 많은 백업 작업을 동시에 실행하는 경우 S3 연결의 총 수가 많을 수 있습니다.
운영 고려 사항
성능 및 크기 조정
MongoDB Ops Manager 부하: MongoDB Ops Manager 애플리케이션 서버는 더 이상 스냅샷 블록 페이로드를 전달하지 않지만, 여전히 사전 서명, 매니페스트 유효성 검사, 작업 상태 및 메타데이터 쓰기 (write)를 처리합니다. 제어 평면 워크로드를 위해 MongoDB Ops Manager의 크기를 조정합니다.
에이전트 호스트 사이징: S3 백업으로 직접 이동하면 압축, 해싱, TLS 및 병렬 S3 업로드가 MongoDB Ops Manager 서버에서 MongoDB Agent를 실행하는 각 호스트로 이동됩니다. 기능을 활성화하기 전에 이러한 호스트가 추가 워크로드를 수행할 충분한 CPU, 메모리 및 외부 네트워크 용량을 가지고 있는지 확인하세요. Direct to S3을 활성화한 후의 영향을 비교하기 위해 기준 스냅샷 기간과 리소스 사용량을 확보하세요.
mms.backup.d2s3.transfer.numWorkers이(가) 설정되지 않은 경우, MongoDB Agent는 호스트가 사용할 수 있는 CPU 및 메모리를 기반으로 백업 작업자 수를 자동으로 조정합니다. 이 작업은 해당 허용량의 4 vCPU당 약 1명의 작업자로 시작하여 최대 16 명의 작업자까지 늘어납니다. 각 워커는 최대 부하 시 CPU 코어 약 1개를 사용할 수 있으므로, 호스트의 허용된 CPU 용량 중 최소 25%는 백업을 위해 확보해 두어야 합니다.스냅샷을 생성하는 동안 MongoDB Agent CPU 사용량과 데이터베이스 지연 시간을 모니터링하세요. MongoDB Agent가 CPU 제한 상태이거나 데이터베이스 지연 시간이 증가하면 용량을 추가하거나
numWorkers을(를) 줄이는 것을 고려하세요.
네트워크 경로: 총 백업 처리량은 모든 MongoDB 에이전트에서 S3 로의 경로의 합계입니다. 사용자의 S3 엔드포인트, VPC 엔드포인트 또는 프록시가 동시에 백업되는 모든 호스트에서 예상되는 동시성을 처리할 수 있는지 확인하십시오.
보안 및 IAM
MongoDB Ops Manager 권한: 스냅샷 저장소에 구성된 S3 자격 증명은 스냅샷에 사용되는 버킷 및 접두사에 대한 사전 서명된
PUT작업을 허용해야 합니다.MongoDB Agent 권한: MongoDB Agent에는 S3 자격 증명이 없습니다. MongoDB Ops Manager는 모든 블록 업로드 및 확인을 위해 사전 서명된 URL을 생성합니다.
불변성: S3으로 직접 백업은 S3 객체 잠금과 호환됩니다. 변경 불가능한 스냅샷에 필요한 객체 버전 ID는 블록 매니페스트에 기록됩니다.
자세히 알아보기
복원 중에 S3에서 직접 스냅샷 데이터를 다운로드하는 동반 기능에 대해 알아보려면 S3에서 직접 복원을 참조하세요.
Ops Manager에서 백업이 작동하는 방식을 알아보려면 백업 프로세스를 참조하세요.
필요한 백업 리소스에 대해 알아보려면 S3호환 스냅샷 저장 관리를 참조하세요.