1. 개요

가상화 백업 기술은 VMware에서 처음 제공하고 시작했습니다. 기업 및 다양한 산업 분야에서 가상화 애플리케이션이 인기를 끌면서 주류 백업 제품은 기본적으로 VMware, Hyper-V, Citrix 및 Xen 또는 KVM에서 파생된 가상화 플랫폼을 지원합니다. .

가상 머신 백업은 가상 머신 스냅샷과 달리, 가상 머신 백업은 가상화 데이터 보호를 위한 가장 중요한 기본 조치입니다. 가상화를 처음 접하는 많은 사용자들은 가상 머신 스냅샷을 백업으로 생각하는 경우가 많지만 이는 실제로 심각한 실수입니다. 그 이유는 다음과 같습니다.

1. 스냅샷은 결코 가상화된 로컬 백업을 위한 솔루션이 될 수 없습니다.

2. 스냅샷을 사용하여 이전 상태로 복원하면 절대 현재 상태로 돌아갈 수 없습니다.

3. 가상 머신 디스크 파일이 손상되면 스냅샷도 무효화됩니다.

4. 스냅샷은 전체 가상 머신 이미지를 기반으로만 복원할 수 있으며 파일 수준이나 애플리케이션 단위로 복원할 수 없습니다.

5. 스냅샷은 가상화의 신속한 복구를 보호하기 위한 보조 수단으로만 사용할 수 있습니다.

6. 모든 가상 머신이 스냅샷을 사용할 수 있는 것은 아니지만 모든 가상 머신이 백업을 사용할 수 있습니다.

7. 스냅샷이 너무 많으면 가상 머신 성능에 큰 영향을 미칠 수 있으며, 스냅샷 생성 또는 삭제 중에 가상 머신 데이터가 손상될 수 있습니다.

현재 가상화 플랫폼 백업에는 두 가지 주류 백업 솔루션이 있습니다. 하나는 에이전트 없는 백업(Agentless)이고 다른 하나는 에이전트 백업(Agent) 또는 게스트 OS 수준 백업이라고 합니다. 이 문서에서는 에이전트 없는 백업과 에이전트 기반 백업의 장단점을 분석하고 비교하여 가상화 백업의 모범 사례를 요약합니다.

2. 에이전트 없는 백업 분석

에이전트 없는 백업은 일반적으로 가상 머신에 백업 에이전트(또는 클라이언트, 프로브)를 설치할 필요가 없음을 의미합니다. 여러 프록시 VM(백업 프록시 애플리케이션)을 사용하여 캡처합니다. 백업 VM.

에이전트 없는 백업의 장점은 매우 분명합니다.

1. 배포 및 설치가 간단합니다. 각 가상 머신에 백업 에이전트를 설치할 필요가 없습니다. 하이퍼바이저 통합을 구성하기만 하면 완전히 자동으로 배포될 수 있습니다.

2. 에이전트 없는 백업은 가상화 제조업체에서 제공하는 전용 백업 인터페이스를 최대한 활용하여 가상 머신을 백업할 때 리소스 소비를 최적화하고 백업 중 가상 머신 자체의 부하 부담을 줄일 수 있습니다.

3. 특별히 조정된 가상화 플랫폼에서 에이전트 없는 백업 제품을 사용하면 가상화 플랫폼 고유의 일부 백업 및 복구 기능을 실현할 수 있습니다. (CBTRCT 블록 추적, 즉시 복구, 가상 머신 복제 등)

4. 가상화 제조업체의 홍보에 따라 에이전트 없는 백업 및 복구가 더 빨라졌습니다.

5. 에이전트 없는 백업은 LAN-FREE 또는 Server-Free 백업 방법을 구현할 때 더 많은 이점을 갖습니다.

위에서 언급했듯이 에이전트 없는 백업은 많은 백업 제조업체, 특히 가상화 제조업체에서 적극 권장합니다. 또한 많은 사용자는 에이전트 없는 백업이 가상화 플랫폼과 더 잘 통합될 수 있다고 믿습니다.

그러나 실제 적용 시 에이전트 없는 백업에는 다음과 같은 결함이 발견됩니다.

1. 가상화 제조업체에서 제공하는 백업 인터페이스에 따라 일부 에이전트 없는 백업 제품은 이를 수행할 수 없습니다. 애플리케이션 인식, 세분화된 데이터 복구 및 RDM(원시 디스크 매핑) 가상 머신 백업을 달성합니다.

2. 에이전트 없는 백업으로 VM을 백업할 때 가상화 플랫폼은 먼저 백업할 VM의 스냅샷을 캡처한 다음 스냅샷 정보를 에이전트 없는 백업 소프트웨어에 전달합니다. I/O가 높거나 데이터 양이 많은 VM(TB 수준 VM) 및 여러 디스크 구조가 있는 VM에 문제를 일으킬 가능성이 가장 높은 것은 이 VM 스냅샷입니다. 스냅샷 시간은 몇 시간 또는 며칠 동안 지속될 수 있습니다. 스냅샷 프로세스 중에 가상 머신 디스크 파일이 비정상이 되면 VM이 충돌할 가능성이 높습니다. 백업이 끝날 무렵 스냅샷이 삭제되면 비슷한 상황이 발생할 수 있습니다. 더욱이 가상화 플랫폼 자체의 스냅샷은 자동으로 적용할 수 없는 경우가 많습니다. 특히 데이터베이스 유형 VM의 경우 복구 중에 데이터 일관성 문제가 발생할 수 있습니다.

3. 실제 시나리오에서 에이전트 없는 백업 리소스 소비는 에이전트 기반 백업보다 낮지 않으며 어떤 경우에는 더 많이 소비합니다. 에이전트 없는 가상화 백업에서는 호스트 CPU가 더 제한된 리소스이기 때문에 CPU 리소스 소비에 특별한 주의가 필요합니다. 일반적으로 1개의 코어가 6개 이상의 가상 머신과 공유됩니다. 자세히 분석해 보면 백업 중 CPU 사용량이 급증하는 데에는 두 가지 주요 이유가 있습니다. 첫째, 백업 에이전트가 전체 파일 시스템에서 백업에 적합한 파일(일반적으로 마지막 백업 이후 변경된 파일)을 검색해야 할 때 CPU 스파이크가 발생합니다. 예를 들어, 증분 또는 차등 백업 중에 이러한 디렉터리 트리 탐색은 시간이 많이 걸리고 많은 CPU 리소스가 필요합니다. 둘째, 백업 프로세스 중 실제 데이터 전송으로 인해 CPU 스파이크가 발생합니다. 현재 가상화 제조업체는 첫 번째 CPU 피크 문제를 해결하기 위해 블록 추적 기술(예: VMware의 CBT, Hyper-V 2016의 RCT 등)을 연속적으로 개발했습니다. 기본 디스크 블록의 변경 사항을 추적함으로써 더 이상 내부 디렉터리를 탐색하고 비교하지 않습니다. 증분 차등 백업 중에 리소스 소비를 최적화하기 위한 VM 파일입니다.

4. 실제 시나리오에서는 에이전트 없는 백업이 느립니다. 비즈니스 애플리케이션 속도를 저하시키지 않으면서 에이전트 없는 백업은 일반적으로 백업을 호스트당 동시에 2개의 VM으로 제한합니다. 에이전트 없는 솔루션의 주장된 장점에도 불구하고 그들은 전송되는 데이터의 양을 줄이는 블록 추적 기술을 사용합니다. 그러나 에이전트 없는 백업 방법은 백업 프로세스에 "풀" 방법이 필요한 블라인드 스캔에 가깝고 이로 인해 CPU 속도가 저하됩니다. 많은 에이전트 없는 백업 제품은 VM의 동시 백업 수를 조정할 수 있습니다. 일반적으로 최대 동시 백업 수는 약 10~15개입니다. 최대 수 제한은 가상화 플랫폼 자체에 의해 제한되며 백업 소프트웨어와는 아무 관련이 없습니다. 그러나 실제 시나리오에서는 최대 동시성을 활성화하는 것이 권장되지 않습니다. 이로 인해 가상화 플랫폼의 로드 압력이 크게 증가하므로 실제 가상 머신 수와 플랫폼 성능을 기반으로 가장 합리적인 동시 백업 수를 결정해야 합니다.

5. 에이전트 없는 백업은 도구 도구(예: VMware 도구, Hyper-v 시스템 통합 도구, KVM의 virt-tools 등)에 크게 의존합니다. VM 도구가 제대로 실행되지 않거나 제때 업데이트되지 않으면 에이전트 없는 백업이 수행됩니다. CBT/RCT 블록 추적을 사용할 수 없으며 스냅샷 예외가 발생하고 VM을 정지할 수 없습니다.

6. 에이전트 없는 백업에는 일반적으로 가상 머신이 있는 스토리지 볼륨에 최소 25%의 공간이 남아 있어야 합니다. 스토리지 공간이 부족한 경우 에이전트 없는 백업 스냅샷으로 인해 스토리지 볼륨 경보 또는 가상 머신 스냅샷 오류가 발생합니다.

7. 가상 머신이 위치한 스토리지 볼륨이 손실되거나 비활성화되면 에이전트 없는 백업이 실패합니다.

3. 프록시 백업 분석

프록시는 특정 기능을 수행하기 위해 서버에 설치되는 작은 애플리케이션을 말합니다. 일반적인 예는 서버를 백업하고 해당 서버에서 실행되는 애플리케이션에 특정 서비스를 제공하는 서버의 백업 애플리케이션에 의해 설치된 클라이언트입니다. 가상화가 대중화되면서 프록시 백업 방법은 가상화 사용자들 사이에서 대중화되지 않았습니다. 그 이유는 다음과 같습니다.

1. 배포 방법이 복잡하고 백업할 가상 머신에 클라이언트 에이전트를 설치해야 합니다. 이는 가상 머신 수가 많은 사용자에게는 치명적인 문제입니다.

2. 소프트웨어 호환성 문제. VM에 에이전트를 설치하는 경우 일반적으로 백업 소프트웨어(예: 바이러스 백신, 시스템 호환성, 특수 보안 응용 프로그램 등)와의 비호환성을 배제하기 위해 먼저 환경 검사를 수행해야 합니다. ).

3. 백업할 VM이 클러스터의 특정 호스트에 너무 집중되면 동시 백업 중에 호스트 리소스의 로드가 증가하고 비즈니스 가상 네트워크에 영향을 미칩니다.

4. 일부 백업 소프트웨어에는 물리적 장치에 대한 디스크 블록 추적 기능이 없습니다. 프록시 백업이 있는 경우 증분 차등 백업이 사용되어 VM에 대한 부하 압력이 증가합니다. 그리고 백업 속도도 느립니다.

5. 에이전트가 있는 유지 관리는 에이전트가 없는 것보다 더 어렵습니다. 예를 들어, 종료된 VM을 백업할 수 없거나 개별 VM이 보안 요구로 인해 일부 포트만 열어 에이전트가 연결하거나 데이터를 전송할 수 없는 등의 문제가 발생합니다.

프록시 백업 방법은 가상화된 환경에서 명백한 단점이 있지만 많은 장점도 있습니다.

1. VM을 백업할 때 가상화 플랫폼 스냅샷에 의존하지 않고 시스템 스냅샷(시스템 vss)을 직접 호출합니다. 또는 LVM 스냅샷)을 사용하면 I/O가 높고 데이터 볼륨이 큰 VM과 다중 디스크 구조를 가진 VM의 백업에 안정성이 더 좋습니다.

2. VM 백업 시 애플리케이션을 인식하여 Exchange, SQL 서버, AD, Oracle, SharePoint, 파일 등의 세분화된 복구를 지원합니다.

3. 물리적 장치 블록 추적을 지원하는 백업 소프트웨어의 경우 에이전트 백업은 에이전트 없는 백업보다 백업 및 복구 속도가 더 빠릅니다.

4. 프록시 백업을 사용하면 데이터베이스 서비스를 사용하여 가상 머신을 백업할 때 데이터베이스를 별도로 백업할 뿐만 아니라 데이터베이스의 데이터 일관성을 보장하도록 데이터베이스 백업 스크립트를 구성할 수 있습니다.

5. 프록시 백업은 가상화 플랫폼의 동시 백업 수에 의해 제한되지 않습니다. 네트워크가 이를 견딜 수 있는 한 동시 VM 백업 수에는 상한이 없습니다.

6. 광범위한 가상화 플랫폼을 지원합니다. 프록시 백업 방법은 소프트웨어 인증이 허용되는 경우 기본적으로 가상화 제조업체에 의해 제한되지 않습니다.

4. 가상화 백업의 실제 경험

제 프로젝트 구현 경험을 바탕으로 대규모 가상 머신 백업에 다음 백업 단계를 사용할 수 있습니다(예: VMware 가상화).

1. 가상화 플랫폼의 모든 가상 머신 정보를 EXCEL 형식으로 추출하고 대용량 데이터(TB 이상), 멀티 디스크 구조, RDM, 핵심 데이터베이스 유형(높은 I/O), 삭제된 스토리지 볼륨(또는 스토리지 볼륨)을 추가합니다. 모든 활성 VM이 필터링되지 않습니다. 에이전트 없는 백업을 사용할 수 없는 VM에는 에이전트 백업이 설치됩니다.

2. 위 유형 이외의 가상머신은 에이전트 없이 백업이 가능합니다.

3. 가상 머신(특히 Windows 시스템 가상 머신)의 에이전트 없는 백업을 사용하는 경우 VMware Tools가 올바르게 설치되었고 모든 VMware Tools 시스템 서비스가 정상적으로 실행되고 있는지 확인하십시오. VMware Tools가 업데이트되었거나 실행할 수 없다는 메시지가 표시되면 VMware Tools를 적시에 업데이트하거나 제거하고 다시 설치해야 합니다.

4. 백업 네트워크 아키텍처와 환경 요구 사항이 LAN-BASELAN-FREESERVER-FREE와 같은 구성 요구 사항을 충족하는지 여부를 계획합니다.

1) 기존 LAN-BASE 아키텍처에서 에이전트 없는 가상화 백업 네트워크는 최소한 기가비트 네트워크 표준을 충족해야 합니다(10기가비트 네트워크 권장). 모범 사례에서는 각 ESXI 호스트에 하나 이상의 물리적 네트워크 포트를 남겨두고, 물리적 네트워크 포트를 백업 전용 가상 네트워크에 할당해야 합니다. 백업 데이터는 ESXI 전용 네트워크 포트를 통해 백업 전송 네트워크를 통해 전송되어야 합니다. 각 ESXI 호스트는 비즈니스와 통신합니다. 네트워크 격리는 백업 중에 비즈니스 네트워크에 대한 대규모 데이터 전송의 영향을 방지합니다. 백업 스토리지 서버의 경우 여러 네트워크 카드 바인딩 사용을 고려할 수 있으며, 스위치가 이를 지원하는 경우 백업 스토리지 서버에 연결된 스위치 포트에서 다중 링크 통합을 사용하여 백업 스토리지의 대역폭을 늘릴 수 있습니다. 섬기는 사람. 모범 사례 요구 사항을 충족할 수 없는 경우 가상 네트워크의 로드 압력이 낮은 비핵심 비즈니스 네트워크 세그먼트에서 백업 데이터가 이동하는 것이 좋습니다.

2) LAN-FREE 아키텍처에서는 주로 VMFS 볼륨 구조 및 스토리지 상태, 다중 경로 매핑, 스토리지 LUN 구조 등을 확인하는 사전 구현 환경 검사에 특히 주의해야 합니다. 가상화된 스토리지에 결합된 볼륨(여러 스토리지 LUN으로 구성된 VMFS 볼륨)이 있는 것으로 확인되면 VMware 자체에서는 이러한 종류의 볼륨에 대해 LAN-FREE 백업을 지원하지 않으며 LAN-BASE 방법만 사용할 수 있습니다. 또한 LAN-FREE 아키텍처의 백업에는 프로덕션 스토리지 매핑이 포함되며 구현 시 특정 위험이 있습니다. 제대로 작동하지 않으면 결과가 심각해집니다.

3) Server-Free 아키텍처는 일반적으로 저장 장치와 백업 소프트웨어가 서로 호환되어야 합니다. 백업 제품마다 지원하는 저장 장치가 다르기 때문에 이 방법은 실제 프로젝트에서는 자주 사용되지 않습니다.

5. 가상 머신 백업을 위해 별도의 백업 저장 서버나 백업 저장 장치를 준비해야 하며, 귀중한 프로덕션 저장 공간을 점유해서는 안 됩니다. 동시에 보안 고려 사항에 따라 백업 데이터가 프로덕션 데이터와 동일한 스토리지에 배치되면 스토리지에 장애가 발생하면 복구할 백업 데이터가 없습니다. 백업 데이터는 프로덕션 데이터와 별도로 저장되어야 합니다.

6. 백업 시간 계획. 모든 백업 제품은 백업 중에 프런트엔드 애플리케이션에 다양한 수준의 비즈니스 영향을 미칩니다. 따라서 백업 프로젝트를 구현할 때 적절한 백업 시간 창을 확보해야 합니다. 백업 시간 창은 일반적으로 업무가 적은 기간에 예약됩니다. 백업 시간은 백업 데이터의 전체 크기와 전송 속도를 기준으로 대략적으로 계산할 수 있습니다. 가상화 플랫폼은 다수의 가상 머신을 보유하고 있으므로 업무 유형에 따라 가상 머신 그룹으로 나누고 가상 머신 그룹별로 백업 창을 다르게 예약하는 것이 좋습니다.

7. 가상 머신 백업 주기는 데이터가 복구될 수 있는 시점에 직접적인 영향을 미칩니다. 따라서 다양한 비즈니스의 가상 머신 그룹에 대한 RPO/RTO 요구 사항에 따라 서로 다른 백업 주기를 공식화해야 합니다.

8. 중복 제거 사용 여부. 중복 제거 사용 여부는 가상화된 스토리지 데이터의 양, 백업 스토리지에 필요한 공간, 백업 기간을 기준으로 결정해야 합니다. 백업할 가상 머신이 많고, 데이터 양이 많고, 백업에 필요한 저장 공간이 부족하고, 백업 기간이 짧은 경우에는 데이터 중복 제거가 최선의 솔루션입니다. 그러나 중복 제거에는 백업 스토리지 서버의 하드웨어 성능에 대한 특정 요구 사항이 있으므로 백업 제품 제조업체의 요구 사항을 참조하여 중복 제거 서버를 구성하는 것이 좋습니다. 또한 중복 제거에는 특정 위험이 있습니다. 중복 제거 데이터베이스가 손상되면 모든 백업을 복구할 수 없습니다. 중복 제거가 활성화된 백업 데이터의 경우 3-2-1 백업 원칙을 충족하려면 두 번째 복사본이 있어야 하는 것이 좋습니다. 마지막으로 각 백업 제조업체에는 데이터 중복 제거에 대한 모범 사례가 있지만 기본 아이디어는 동일합니다. 일반적으로 먼저 가상화 플랫폼에서 몇 가지 일반적인 가상 머신을 백업한 다음 배치 백업을 수행하여 최고의 중복 제거 효과를 얻습니다.

9. 에이전트 없는 백업 가상 머신 동시성 제한, 일반적으로 백업 계획은 VMware의 기본 2개 가상 머신 동시 백업을 따르는 것이 좋습니다. 동시성 수는 가상화 플랫폼 성능과 네트워크 대역폭 사용량을 종합적으로 고려하여 조정할 수 있습니다. 그러나 동시성 수를 너무 많이 조정하거나 최대 동시성을 활성화하지 않는 것이 좋습니다. 그렇지 않으면 가상화 플랫폼이 큰 압박을 받게 되고, 통신 문제가 발생할 수 있으며, 가상 머신 비즈니스 사고가 발생하고, 백업이 실패할 수 있습니다.

10. 업무에 따라 백업 계획을 수립하고 백업 계획 사이에 일정한 시간 간격이 있는지 확인하세요. 동시에 많은 수의 가상 머신 백업을 시작하면 네트워크 및 CPU 로드에 큰 변동이 발생하지 않도록 하십시오.

11. 다양한 업종에 따라 백업 보관 기간을 결정하세요. 시간에 민감한 서비스의 백업은 1~2주 동안 보관하는 것이 좋습니다. 보관해야 하는 가상 머신의 보존 기간은 3개월 이상으로 설정하는 것이 좋습니다. 보존 기간은 백업 스토리지 사용량과 밀접한 관련이 있으므로 다양한 가상 머신 그룹의 데이터 보존 시간을 신중하게 계획해야 합니다.

12. 에이전트 백업이 포함된 Windows VM을 사용하면 배포 편의를 위해 원격 푸시 방식을 사용하여 백업 에이전트를 설치할 수 있습니다. 푸시 조건이 충족되지 않으면 로컬 설치가 사용됩니다. 에이전트를 로컬로 푸시하거나 설치하기 전에 설치 환경을 주의 깊게 확인해야 하며, 패치, 호환성, 네트워크, 구성 등의 측면을 하나씩 확인할 수 있습니다.

13. 가상화 백업 계획이 구현된 후 1~2주 동안 일일 백업 상황과 비즈니스 영향을 면밀히 관찰해야 합니다. 백업이 비정상적이거나 정상적인 비즈니스에 영향을 미치는 경우 적시에 백업 전략을 조정해야 합니다. 방식으로 이루어지며, 백업이 안정될 때까지 백업 계획을 지속적으로 최적화해야 합니다.

5. 요약

가상화 백업 프로젝트는 간단해 보이지만 가상머신 수, 스토리지 아키텍처, 네트워크 아키텍처, 백업 계획 주기 등을 고려하여 백업 계획을 고려하고, 가상화 플랫폼의 실제 상황을 바탕으로 구현 프로세스를 결정하고, 지속적으로 백업 전략을 최적화합니다.