GitLab이 대규모 NextCloud 스토리지 백업을 지원하는 방법

헤이 하브르!

오늘은 다양한 구성으로 Nextcloud 스토리지에서 빅데이터 백업을 자동화한 경험에 대해 이야기하고 싶습니다. 저는 Molniya AK에서 서비스 스테이션으로 근무하며 IT 시스템의 구성 관리를 담당하고 있으며 Nextcloud는 데이터 저장에 사용됩니다. 분산 구조와 중복성을 포함합니다.

설치 기능에서 발생하는 문제는 데이터가 많다는 것입니다. Nextcloud에서 제공하는 버전 관리, 중복성, 주관적인 이유 등 많은 중복이 생성됩니다.

선사 시대

Nextcloud를 관리할 때 데이터가 중요하기 때문에 암호화해야 하는 효과적인 백업을 구성하는 문제가 발생합니다.

우리는 관리에 대한 유연하고 자동화된 접근 방식이 필요한 Nextcloud와는 별도의 시스템에 백업을 저장하거나 고객의 장소에 백업을 저장할 수 있는 옵션을 제공합니다.

많은 클라이언트가 있으며 모두 구성이 다르고 모두 자체 사이트와 특성을 가지고 있습니다. 이는 전체 사이트가 귀하에게 속해 있고 백업이 크라운으로 만들어지는 경우 표준 기술이므로 잘 맞지 않습니다.

먼저 입력 데이터를 살펴보겠습니다. 우리는 다음이 필요합니다:

• 하나 또는 여러 노드 측면에서 확장성. 대규모 설치의 경우 minio를 스토리지로 사용합니다.
• 백업 수행 시 발생하는 문제에 대해 알아보세요.
• 귀하는 귀하의 고객 및/또는 당사에 백업을 보관해야 합니다.
• 빠르고 쉽게 문제를 처리하세요.
• 클라이언트와 설치는 서로 매우 다르기 때문에 통일성을 달성할 수 없습니다.
• 복구 속도는 전체 복구(재해), 실수로 하나의 폴더가 지워진 두 가지 시나리오에서 최소화되어야 합니다.
• 중복 제거 기능이 필요합니다.

백업 관리 문제를 해결하기 위해 GitLab을 설치했습니다. 자세한 내용은 태클별로 확인하세요.

물론, 우리가 이러한 문제를 해결한 최초의 사람은 아니지만, 우리의 실용적이고 힘들게 얻은 경험이 흥미로울 수 있다고 생각하고 이를 공유할 준비가 되어 있습니다.

우리 회사는 오픈소스 정책을 갖고 있기 때문에 오픈소스 솔루션을 찾고 있었습니다. 차례로 우리는 개발 내용을 공유하고 게시합니다. 예를 들어 GitHub에는 다음이 있습니다. Nextcloud용 플러그인, 실수로 또는 의도적으로 삭제되는 경우 데이터 보안을 강화하여 고객에게 제공합니다.

백업 도구

우리는 백업 생성 도구를 선택하여 솔루션 방법을 찾기 시작했습니다.

일반 tar + gzip은 제대로 작동하지 않습니다. 데이터가 중복됩니다. 증분에는 실제 변경 사항이 거의 포함되지 않으며 단일 파일 내의 많은 데이터가 반복되는 경우가 많습니다.
또 다른 문제는 분산 데이터 저장의 중복성입니다. 우리는 minio를 사용하는데 그 데이터는 기본적으로 중복됩니다. 또는 minio 자체를 통해 백업을 만들어야 했습니다. 이를 로드하고 파일 시스템 사이의 모든 스페이서를 사용해야 했습니다. 그리고 덜 중요한 것은 일부 버킷과 메타 정보를 잊어버릴 위험이 있다는 것입니다. 아니면 중복 제거를 사용하세요.

복제 기능이 있는 백업 도구는 오픈 소스에서 사용할 수 있습니다(Habré에는 조항 이 주제에) 최종 후보는 보그 и 레스스틱. 두 응용 프로그램에 대한 비교는 아래에 있지만 지금은 전체 구성표를 어떻게 구성했는지 알려 드리겠습니다.

백업 관리

Borg와 Restic은 훌륭하지만 두 제품 모두 중앙 집중식 제어 메커니즘이 없습니다. 관리 및 제어를 위해 우리는 자동화를 포함하여 작업을 상상할 수 없는 이미 구현한 도구를 선택했습니다. 이것이 바로 잘 알려진 CI/CD인 GitLab입니다.

아이디어는 다음과 같습니다. Nextcloud 데이터를 저장하는 각 노드에 gitlab-runner가 설치됩니다. 실행기는 백업 프로세스를 모니터링하는 일정에 따라 스크립트를 실행하고 Borg 또는 Restic을 시작합니다.

우리는 무엇을 얻었나요? 실행 피드백, 변경 사항에 대한 편리한 제어, 오류 발생 시 세부 정보.

여기에 여기 GitHub에서 다양한 작업에 대한 스크립트 예제를 게시했고 결국 이를 Nextcloud뿐만 아니라 다른 여러 서비스의 백업에도 첨부했습니다. 수동으로 구성하고 싶지 않은 경우(저희도 원하지 않는 경우) .gitlab-ci.yml 스케줄러도 있습니다.

아직 Gitlab API에서 CI/CD 시간 초과를 변경할 수 있는 방법은 없지만 크기가 작습니다. 늘려야 한다고 하더군요 1d.

다행스럽게도 GitLab은 커밋뿐만 아니라 일정에 따라서만 시작할 수 있습니다. 이것이 바로 우리에게 필요한 것입니다.

이제 래퍼 스크립트에 대해 알아보겠습니다.

이 스크립트에 대해 다음 조건을 설정했습니다.

• 동일한 기능을 사용하여 러너와 콘솔에서 직접 실행해야 합니다.
• 오류 처리기가 있어야 합니다.
• 반환 코드.
• 로그에서 문자열을 검색하세요. 예를 들어, 우리에게 오류는 프로그램이 치명적이라고 간주하지 않는 메시지일 수 있습니다.
• 처리 시간이 초과되었습니다. 리드타임은 합리적이어야 합니다.
• 매우 상세한 기록이 필요합니다. 단, 오류가 발생한 경우에만 해당됩니다.
• 시작하기 전에 여러 가지 테스트도 수행됩니다.
• 지원 과정에서 유용하다고 판단한 편의를 위한 작은 보너스:
• 시작과 끝은 로컬 시스템의 syslog에 기록됩니다. 이는 시스템 오류와 백업 작업을 연결하는 데 도움이 됩니다.
• 오류 로그의 일부가 stdout으로 출력되고, 전체 로그는 별도의 파일에 기록됩니다. CI를 보고 사소한 오류라면 바로 평가해 보는 것이 편리합니다.
• 디버깅 모드.

전체 로그는 GitLab에 아티팩트로 저장되며, 오류가 없으면 로그가 삭제됩니다. 우리는 bash로 스크립트를 작성합니다.

오픈 소스에 관한 모든 제안과 의견을 기꺼이 고려하겠습니다. 환영합니다.

이거 어떻게 작동 시켜요

Bash 실행기가 있는 실행기가 백업 노드에서 시작됩니다. 스케줄러에 따르면 작업 CI/CD가 특수 순무에서 실행됩니다. Runner는 이러한 작업을 위해 범용 래퍼 스크립트를 시작하고 백업 저장소, 마운트 지점 및 원하는 모든 항목의 유효성을 확인한 다음 이전 항목을 백업하고 정리합니다. 완료된 백업 자체는 S3로 전송됩니다.

우리는 이 체계에 따라 작업합니다. 이는 외부 AWS 공급자이거나 이에 상응하는 러시아 공급자입니다(더 빠르고 데이터가 러시아 연방을 떠나지 않습니다). 또는 이러한 목적을 위해 클라이언트의 사이트에 별도의 미니오 클러스터를 설치합니다. 일반적으로 클라이언트가 데이터가 회로를 떠나는 것을 원하지 않을 때 보안상의 이유로 이 작업을 수행합니다.

SSH를 통해 백업을 보내는 기능을 사용하지 않았습니다. 이는 보안을 추가하지 않으며 S3 공급자의 네트워크 기능은 단일 SSH 시스템보다 훨씬 높습니다.

해커가 S3의 데이터를 지울 수 있으므로 로컬 시스템을 해커로부터 보호하려면 버전 관리를 활성화해야 합니다.
백업은 항상 백업을 암호화합니다.

Borg에는 암호화되지 않은 모드가 있습니다 none, 그러나 켜는 것을 강력히 권장하지 않습니다. 이 모드에서는 암호화가 없을 뿐만 아니라 기록되는 항목의 체크섬도 계산되지 않습니다. 즉, 인덱스를 사용하여 간접적으로만 무결성을 확인할 수 있습니다.

별도의 스케줄러가 백업에서 인덱스와 콘텐츠의 무결성을 확인합니다. 점검이 느리고 길어서 한 달에 한 번씩 따로 실행해드리고 있습니다. 며칠이 걸릴 수 있습니다.

러시아어로 읽어보기

주요 기능

• prepare 훈련
• testcheck 준비 상태 확인
• maincommand 핵심 팀
• forcepostscript 결국 또는 오류로 인해 실행되는 기능입니다. 파티션을 마운트 해제하는 데 사용합니다.

서비스 기능

• cleanup 오류를 기록하거나 로그 파일을 삭제합니다.
• checklog 오류가 있는 줄이 발생했는지 로그를 구문 분석합니다.
• ret 종료 핸들러.
• checktimeout 시간 초과를 확인하세요.

환경

• VERBOSE=1 오류는 즉시 화면에 표시됩니다(stdout).
• SAVELOGSONSUCCES=1 성공 시 로그를 저장합니다.
• INIT_REPO_IF_NOT_EXIST=1 저장소가 없으면 만듭니다. 기본적으로 비활성화되어 있습니다.
• TIMEOUT 주요 작업의 최대 시간. 마지막에 'm', 'h', 'd'로 설정할 수 있습니다.

오래된 사본의 저장 모드입니다. 기본:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

스크립트 내부의 변수

• ERROR_STRING — 오류에 대한 체크인 로그 문자열입니다.
• EXTRACT_ERROR_STRING — 오류가 발생한 경우 문자열 표시에 대한 표현식입니다.
• KILL_TIMEOUT_SIGNAL — 시간이 초과되면 종료하라는 신호입니다.
• TAIL — 화면에 오류가 있는 문자열 수.
• COLORMSG — 메시지 색상(기본값 노란색).

wordpress라고 불리는 해당 스크립트에는 조건부 이름이 있으며, 그 비결은 mysql 데이터베이스도 백업한다는 것입니다. 즉, 단일 노드 Nexcloud 설치에 사용할 수 있으며 데이터베이스를 백업할 수도 있습니다. 편리함은 모든 것이 한 곳에 있을 뿐만 아니라 시간 차이가 최소화되므로 데이터베이스의 내용이 파일의 내용과 가깝다는 것입니다.

레스틱 vs 보그

Borg와 Restic의 비교도 있습니다. 여기 하브레에서, 그리고 우리는 또 다른 것을 만드는 임무가 아니라 우리 자신의 것을 만드는 임무를 가졌습니다. 우리의 세부 사항과 함께 데이터가 어떻게 보이는지 우리에게 중요했습니다. 우리는 그들을 가져옵니다.

이미 언급한 사항(중복 제거, 빠른 복구 등) 외에 선택 기준은 다음과 같습니다.

• 미완성 작업에 대한 저항. kill -9를 확인하십시오.
• 디스크 크기.
• 리소스(CPU, 메모리) 요구 사항입니다.
• 저장된 Blob의 크기입니다.
• S3와 협력합니다.
• 무결성 검사.

테스트를 위해 실제 데이터와 총 크기가 1,6TB인 클라이언트 하나를 사용했습니다.
조건.

Borg는 S3로 직접 작업하는 방법을 모르므로 다음을 통해 디스크를 퓨즈로 마운트했습니다. 바보. Restic은 이를 S3 자체로 보냈습니다.

Goofys는 매우 빠르고 잘 작동하며, 디스크 캐시 모듈, 작업 속도가 더욱 빨라집니다. 베타 단계에 있으며, 솔직히 테스트 중에 데이터 손실로 인해 충돌이 발생했습니다(기타). 하지만 편리한 점은 백업 절차 자체에는 읽기가 많이 필요하지 않고 대부분 쓰기가 필요하므로 무결성 검사 중에만 캐시를 사용한다는 것입니다.

네트워크의 영향을 줄이기 위해 우리는 로컬 공급자인 Yandex Cloud를 사용했습니다.

비교 테스트 결과.

• 추가 재시작으로 Kill -9가 모두 성공했습니다.
• 디스크 크기. Borg는 압축할 수 있으므로 결과는 예상대로입니다.

백업퍼
크기

보그
562Gb

레스스틱
628Gb

• CPU별
  Borg 자체는 기본 압축을 사용하여 거의 소비하지 않지만 Goofys 프로세스와 함께 평가되어야 합니다. 전체적으로 이들은 동일하며 동일한 테스트 가상 머신에서 약 1,2개의 코어를 사용합니다.
• 메모리. Restic은 약 0,5GB, Borg는 약 200MB입니다. 그러나 이것은 시스템 파일 캐시에 비해 모두 중요하지 않습니다. 따라서 더 많은 메모리를 할당하는 것이 좋습니다.
• 덩어리 크기의 차이가 눈에 띄었습니다.

백업퍼
크기

보그
약 500MB

레스스틱
약 5MB

• Restic의 S3 사용 경험은 훌륭했습니다. goofys를 통해 Borg로 작업하는 것은 어떤 질문도 제기하지 않지만, 캐시를 완전히 재설정하려면 백업이 완료된 후 umount를 수행하는 것이 바람직하다고 언급되었습니다. S3의 특징은 덜 펌핑된 청크가 버킷으로 전송되지 않는다는 것입니다. 이는 불완전하게 채워진 데이터가 큰 손상을 초래한다는 것을 의미합니다.
• 무결성 검사는 두 경우 모두 잘 작동하지만 속도에는 상당한 차이가 있습니다.
  레스틱 3,5 시간.
  100GB SSD 파일 캐시를 갖춘 Borg – 5 시간.데이터가 로컬 디스크에 있는 경우 속도는 거의 동일합니다.
  Borg는 캐시 없이 S3에서 직접 읽습니다. 33 시간. 엄청나게 길다.

결론적으로 Borg는 압축할 수 있고 더 큰 blob을 가질 수 있으므로 S3의 스토리지 및 GET/PUT 작업이 더 저렴해집니다. 그러나 이는 더 복잡하고 느린 검증의 대가를 치르게 됩니다. 복구 속도는 아무런 차이를 느끼지 못했습니다. Restic은 후속 백업(첫 번째 백업 이후)이 조금 더 오래 걸리지만 크게 다르지는 않습니다.

마지막으로 선택의 여지가 있는 것은 커뮤니티의 규모였습니다.

그리고 우리는 보그를 선택했습니다.

압축에 대한 몇 마디

Borg의 무기고에는 zstd라는 뛰어난 새로운 압축 알고리즘이 있습니다. 압축 품질은 gzip보다 나쁘지 않지만 훨씬 빠릅니다. 속도는 기본 lz4와 비슷합니다.

예를 들어, MySQL 데이터베이스 덤프는 동일한 속도에서 lz4보다 두 배 더 잘 압축됩니다. 하지만 실제 데이터를 경험해 본 결과 Nextcloud 노드의 압축률에는 거의 차이가 없는 것으로 나타났습니다.

Borg에는 다소 보너스 압축 모드가 있습니다. 파일의 엔트로피가 높으면 압축이 전혀 적용되지 않아 속도가 빨라집니다. 생성 시 옵션으로 활성화
-C auto,zstd
zstd 알고리즘의 경우
따라서 이 옵션을 사용하면 기본 압축과 비교하여 다음과 같은 결과를 얻을 수 있습니다.
각각 560Gb 및 562Gb. 위 예의 데이터를 보면 압축하지 않은 결과는 628Gb입니다. 2GB 차이의 결과는 다소 놀랐지만 결국 우리는 그것을 선택할 것이라고 생각했습니다. auto,zstd.

백업 확인 방법

스케줄러에 따르면 가상 머신은 공급자 또는 클라이언트에서 직접 시작되므로 네트워크 부하가 크게 줄어듭니다. 적어도 직접 키우고 교통을 운전하는 것보다 저렴합니다.

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

동일한 구성표를 사용하여 바이러스 백신으로 파일을 검사합니다(사후). 결국 사용자는 Nextcloud에 다양한 것을 업로드하지만 모든 사람이 바이러스 백신을 사용하는 것은 아닙니다. 타설 시 점검을 실시하는 것은 너무 많은 시간이 소요되고 업무에 지장을 줍니다.

확장성은 서로 다른 태그를 사용하여 서로 다른 노드에서 실행기를 실행함으로써 달성됩니다.
우리의 모니터링은 하나의 창에서 GitLab API를 통해 백업 상태를 수집하며, 필요한 경우 문제를 쉽게 발견하고 쉽게 현지화할 수 있습니다.

결론

결과적으로 우리는 백업을 만들고 있고, 백업이 유효하며, 백업과 관련하여 발생하는 문제는 시간이 거의 걸리지 않으며 담당 관리자 수준에서 해결된다는 것을 확실히 알고 있습니다. 백업은 tar.gz 또는 Bacula에 비해 공간을 거의 차지하지 않습니다.

출처 : habr.com