무료 도구를 사용하여 수천 대의 가상 머신을 위한 백업 스토리지

안녕하세요. 저는 최근에 흥미로운 문제를 발견했습니다: 다수의 블록 장치를 백업하기 위한 스토리지 설정입니다.

매주 우리는 클라우드의 모든 가상 머신을 백업하므로 수천 개의 백업을 유지 관리하고 가능한 한 빠르고 효율적으로 수행할 수 있어야 합니다.

불행히도 표준 구성 RAID5, RAID6 이 경우에는 그렇게 하는 것이 허용되지 않습니다. 왜냐하면 우리와 같은 대형 디스크의 복구 프로세스는 고통스러울 만큼 길고 결코 끝나지 않을 가능성이 높기 때문입니다.

어떤 대안이 있는지 살펴보겠습니다.

이레이저 코딩 — RAID5, RAID6과 유사하지만 패리티 수준을 구성할 수 있습니다. 이 경우 예약은 블록별로 이루어지지 않고, 객체별로 별도로 이루어집니다. 삭제 코딩을 시도하는 가장 쉬운 방법은 확장하는 것입니다. 미니 오.

드레이드 현재 출시되지 않은 ZFS 기능입니다. RAIDZ와 달리 DRAID에는 분산 패리티 블록이 있으며 복구 중에 어레이의 모든 디스크를 한 번에 사용하므로 디스크 오류를 더 잘 견디고 오류 후 더 빠르게 복구할 수 있습니다.

서버 사용 가능 후지쯔 프라이머지 RX300 S7 프로세서 포함 인텔 제온 CPU E5-2650L 0 @ 1.80GHz, RAM XNUMX개 삼성 DDR3-1333 8Gb PC3L-10600R ECC 등록됨(M393B1K70DH0-YH9), 디스크 선반 슈퍼마이크로 슈퍼섀시 847E26-RJBOD1, 다음을 통해 연결됨 듀얼 LSI SAS2X36 확장기 디스크 45개 씨게이지 ST6000NM0115-1YZ110 에 6TB 모두들.

무엇이든 결정하기 전에 먼저 모든 것을 적절하게 테스트해야 합니다.

이를 위해 다양한 구성을 준비하고 테스트했습니다. 이를 위해 S3 백엔드 역할을 하는 minio를 사용하여 다양한 대상 수를 가진 다양한 모드로 실행했습니다.

기본적으로 미니오 케이스는 동일한 수의 디스크와 디스크 패리티를 사용하여 삭제 코딩과 소프트웨어 RAID에서 테스트되었으며 이는 RAID6, RAIDZ2 및 DRAID2입니다.

참고: 하나의 대상만 사용하여 minio를 시작하면 minio는 S3 게이트웨이 모드에서 작동하여 로컬 파일 시스템을 S3 스토리지 형태로 제공합니다. 여러 대상을 지정하여 minio를 시작하면 Erasure Coding 모드가 자동으로 켜져 내결함성을 제공하면서 대상 간에 데이터를 분산시킵니다.

기본적으로 minio는 대상을 그룹당 16개의 패리티가 있는 2개의 디스크 그룹으로 나눕니다. 저것들. 데이터 손실 없이 두 개의 디스크에 동시에 오류가 발생할 수 있습니다.

성능을 테스트하기 위해 각각 16TB의 디스크 6개를 사용하고 그 위에 1MB 크기의 작은 개체를 썼습니다. 이는 모든 최신 백업 도구가 데이터를 수 메가바이트의 블록으로 나누고 이런 방식으로 쓰기 때문에 이것이 미래의 부하를 가장 정확하게 설명하기 때문입니다.

벤치마크를 수행하기 위해 우리는 s3bench 유틸리티를 사용하여 원격 서버에서 실행하고 수백 개의 스레드로 수만 개의 개체를 minio에 보냈습니다. 그 후 나는 같은 방식으로 다시 요청하려고했습니다.

벤치마크 결과는 다음 표에 나와 있습니다.

보시다시피 자체 삭제 코딩 모드의 minio는 동일한 구성의 소프트웨어 RAID6, RAIDZ2 및 DRAID2에서 실행되는 minio보다 쓰기 성능이 훨씬 나쁩니다.

나 따로 ~가 물었다. ext4와 XFS에서 minio를 테스트합니다. 놀랍게도 내 작업 유형에서는 XFS가 ext4보다 훨씬 느린 것으로 나타났습니다.

첫 번째 배치 테스트에서 Mdadm은 ZFS보다 우월한 것으로 나타났지만 나중에는 그멜리코프 자극 받다다음 옵션을 설정하여 ZFS 성능을 향상시킬 수 있습니다.

xattr=sa atime=off recordsize=1M

그 후 ZFS를 사용한 테스트는 훨씬 더 좋아졌습니다.

또한 DRAID는 RAIDZ에 비해 많은 성능 향상을 제공하지 않지만 이론적으로는 훨씬 더 안전합니다.

지난 두 번의 테스트에서는 메타데이터(특수)와 ZIL(로그)도 SSD에서 미러로 전송해 보았습니다. 하지만 메타데이터를 제거해도 녹화 속도가 크게 향상되지 않았고 ZIL을 제거해도 SSDSC2KI128G8 100% 활용도로 상한선에 도달했으므로 이 테스트는 실패라고 생각합니다. 더 빠른 SSD 드라이브가 있다면 결과가 크게 향상될 수 있다는 점을 배제하지는 않지만 안타깝게도 SSD 드라이브가 없었습니다.

결국 저는 DRAID를 사용하기로 결정했고, 베타 버전임에도 불구하고 저희 경우에는 DRAID가 가장 빠르고 효율적인 스토리지 솔루션입니다.

세 개의 그룹과 두 개의 분산 스페어가 포함된 구성으로 간단한 DRAID2를 만들었습니다.

# zpool status data
  pool: data
 state: ONLINE
  scan: none requested
config:

    NAME                 STATE     READ WRITE CKSUM
    data                 ONLINE       0     0     0
      draid2:3g:2s-0     ONLINE       0     0     0
        sdy              ONLINE       0     0     0
        sdam             ONLINE       0     0     0
        sdf              ONLINE       0     0     0
        sdau             ONLINE       0     0     0
        sdab             ONLINE       0     0     0
        sdo              ONLINE       0     0     0
        sdw              ONLINE       0     0     0
        sdak             ONLINE       0     0     0
        sdd              ONLINE       0     0     0
        sdas             ONLINE       0     0     0
        sdm              ONLINE       0     0     0
        sdu              ONLINE       0     0     0
        sdai             ONLINE       0     0     0
        sdaq             ONLINE       0     0     0
        sdk              ONLINE       0     0     0
        sds              ONLINE       0     0     0
        sdag             ONLINE       0     0     0
        sdi              ONLINE       0     0     0
        sdq              ONLINE       0     0     0
        sdae             ONLINE       0     0     0
        sdz              ONLINE       0     0     0
        sdan             ONLINE       0     0     0
        sdg              ONLINE       0     0     0
        sdac             ONLINE       0     0     0
        sdx              ONLINE       0     0     0
        sdal             ONLINE       0     0     0
        sde              ONLINE       0     0     0
        sdat             ONLINE       0     0     0
        sdaa             ONLINE       0     0     0
        sdn              ONLINE       0     0     0
        sdv              ONLINE       0     0     0
        sdaj             ONLINE       0     0     0
        sdc              ONLINE       0     0     0
        sdar             ONLINE       0     0     0
        sdl              ONLINE       0     0     0
        sdt              ONLINE       0     0     0
        sdah             ONLINE       0     0     0
        sdap             ONLINE       0     0     0
        sdj              ONLINE       0     0     0
        sdr              ONLINE       0     0     0
        sdaf             ONLINE       0     0     0
        sdao             ONLINE       0     0     0
        sdh              ONLINE       0     0     0
        sdp              ONLINE       0     0     0
        sdad             ONLINE       0     0     0
    spares
      s0-draid2:3g:2s-0  AVAIL   
      s1-draid2:3g:2s-0  AVAIL   

errors: No known data errors

자, 저장 공간을 정리했으니 이제 백업할 내용에 대해 이야기해 보겠습니다. 여기서는 제가 시도한 세 가지 솔루션에 대해 즉시 이야기하고 싶습니다. 이는 다음과 같습니다.

벤지 백업 - 포크 백키2블록 장치 백업을 위한 전문 솔루션인 는 Ceph와 긴밀하게 통합됩니다. 스냅샷 간의 차이점을 확인하고 스냅샷에서 증분 백업을 구성할 수 있습니다. 로컬 및 S3를 모두 포함하여 다수의 스토리지 백엔드를 지원합니다. 중복 제거 해시 테이블을 저장하려면 별도의 데이터베이스가 필요합니다. 단점: Python으로 작성되었으며 약간 응답하지 않는 cli가 있습니다.

Borg 백업 - 포크 다락방오랫동안 알려지고 검증된 백업 도구인 는 데이터를 잘 백업하고 중복 제거할 수 있습니다. scp를 통해 로컬 및 원격 서버에 백업을 저장할 수 있습니다. 플래그를 사용하여 실행하면 블록 장치를 백업할 수 있습니다. --special, 단점 중 하나: 백업을 생성할 때 저장소가 완전히 차단되므로 각 가상 머신에 대해 별도의 저장소를 생성하는 것이 좋습니다. 원칙적으로 이것은 문제가 되지 않으며 다행히 매우 쉽게 생성됩니다.

레스스틱 활발하게 개발 중인 프로젝트로 go로 작성되었으며 매우 빠르며 로컬 스토리지, scp, S3 등을 포함한 수많은 스토리지 백엔드를 지원합니다. 이와 별도로 특별히 만들어진 것이 있다는 점에 주목하고 싶습니다. 나머지 서버 Restic의 경우 원격으로 사용하기 위해 스토리지를 빠르게 내보낼 수 있습니다. 위의 것 중에서 가장 마음에 들었습니다. stdin에서 백업할 수 있습니다. 눈에 띄는 단점은 거의 없지만 몇 가지 기능이 있습니다.

• 첫째, 모든 가상 머신(예: Benji)에 대해 일반 저장소 모드에서 사용하려고 시도했는데 꽤 잘 작동했지만 복원 작업에 시간이 너무 오래 걸렸습니다. Restic은 복원하기 전에 매번 모든 백업의 메타데이터를 읽으려고 시도합니다. 이 문제는 borg와 마찬가지로 각 가상 머신에 대해 별도의 저장소를 생성하여 쉽게 해결되었습니다. 이 접근 방식은 백업 관리에도 매우 효과적인 것으로 입증되었습니다. 별도의 리포지토리는 데이터에 액세스하기 위해 별도의 비밀번호를 가질 수 있으며, 글로벌 리포지토리가 어떻게든 손상될 수도 있다는 것을 두려워할 필요도 없습니다. borg 백업에서처럼 쉽게 새 저장소를 생성할 수 있습니다.

  어떤 경우든 중복 제거는 이전 버전의 백업과 관련해서만 수행됩니다. 이전 백업은 지정된 백업의 경로에 따라 결정되므로 stdin에서 공통 저장소로 다양한 개체를 백업하는 경우 옵션 --stdin-filename, 또는 매번 옵션을 명시적으로 지정 --parent.

• 둘째, stdout으로의 복구는 병렬 특성으로 인해 파일 시스템으로의 복구보다 훨씬 오래 걸립니다. 앞으로는 블록 장치에 대한 백업 지원을 더욱 긴밀하게 추가할 계획입니다.

• 셋째, 현재 사용하는 것이 좋습니다. 마스터의 버전, 왜냐하면 버전 0.9.6에는 대용량 파일의 복구 시간이 오래 걸리는 버그가 있습니다.

백업의 효율성과 백업 쓰기/복원 속도를 테스트하기 위해 별도의 저장소를 생성하고 가상 머신의 작은 이미지(21GB)를 백업해 보았습니다. 중복 제거된 데이터가 얼마나 빠르게/느리게 복사되었는지 확인하기 위해 나열된 각 솔루션을 사용하여 원본을 변경하지 않고 두 번의 백업을 수행했습니다.

보시다시피 Borg Backup은 초기 백업 효율성 비율이 가장 높지만 쓰기 및 복원 속도 측면에서 열등합니다.

Restic은 Benji Backup보다 빠른 것으로 밝혀졌지만 stdout으로 복원하는 데 시간이 더 오래 걸리고 안타깝게도 아직 블록 장치에 직접 쓰는 방법을 모릅니다.

장단점을 모두 따져본 후 결정했습니다 소박한 с 나머지 서버 가장 편리하고 유망한 백업 솔루션입니다.

이 스크린캐스트에서는 동시에 실행되는 여러 백업 작업 중에 10기가비트 채널이 어떻게 완전히 활용되는지 확인할 수 있습니다. 디스크 재활용이 30% 이상 증가하지 않는다는 점은 주목할 가치가 있습니다.

제가 받은 솔루션에 매우 만족했습니다!

출처 : habr.com