Page Comparison

...

재해 복구를 대기하는 Bitbucket의 일반적인 배포는 다음 다이어그램에 나와 있습니다. 대기 비트 버킷 인스턴스는 "콜드"(즉, 실행되지 않음)이고 공유 파일 서버, 데이터베이스 및 (선택 사항) Elasticsearch 인스턴스는 복제가 발생할 수 있도록 "웜"(즉, 실행 중)입니다.

...

데이터 원본 복제

기본 Bitbucket 시스템을 대기 시스템으로 복제하려면 다음이 필요합니다.

1. 원격 대기 상태로의 원자성 스냅샷 수준 복제를 지원하는 파일 시스템에 공유 홈 디렉토리가 있어야 합니다.

2. 데이터베이스를 원격 대기 모드로 복제할 수 있습니다.

파일 시스템

공유 홈 디렉터리에는 리포지토리 데이터, 로그 파일, 사용자가 설치한 플러그인 등이 포함되어 있습니다. 공유 홈 디렉토리를 대기 파일 서버에 복제해야 합니다. 대기 상태가 가능한 최신 상태인지 확인하려면 이 프로세스가 빠르고 안정적이며 증분적이어야 합니다.

예를 들어, 전송 중에 리포지토리가 변경되어 손상이 발생할 수 있으므로 RSync와 같은 복제 기술은 이 요구 사항을 충족하지 못합니다.

원하는 수준의 일관성을 유지하는 가장 좋은 방법은 원자성 블록 수준 스냅샷을 지원하는 파일 시스템을 사용하는 것입니다. 대기 상태로 복제하는데 걸리는 시간에 관계없이 스냅샷의 모든 파일이 동일한 시점에 효율적으로 고정됩니다. 예제 스크립트는 원격 시스템에서 전송 및 복원할 수 있는 경량 스냅샷을 허용하기 때문에 ZFS를 Bitbucket 공유 홈의 파일 시스템으로 구현합니다.

데이터베이스

데이터베이스에는 꺼내기 요청, 주석, 사용자, 그룹, 권한 등에 대한 데이터가 들어 있습니다. RPO를 충족하려면 데이터베이스를 복제하고 지속적으로 최신 상태로 유지해야 합니다.

Elasticsearch

이 데이터 저장소는 데이터베이스와 리포지토리 콘텐츠의 조합에서 추출되므로 기술적으로 핵심 데이터 저장소가 아닙니다. Bitbucket 검색은 오래된 인덱스를 검색하여 점진적으로 재구성합니다. 그러나 특히 대규모 설치의 경우 검색 색인을 재구성하는데 시간이 많이 걸릴 수 있으며, 이 경우 검색 기능에 영향을 미칠 수 있습니다.

Elasticsearch를 사용할 수 없는 경우에도 핵심 Bitbucket 기능은 계속 정상적으로 작동합니다. Elasticsearch가 오프라인이거나 최신 버전이 아닌 경우 검색 기능만 영향을 받습니다. Bitbucket은 인덱스를 재구성하는 동안 검색 쿼리를 제공하지만 인덱스가 완전히 재구성될 때까지 검색 결과가 완전하거나 정확하지는 않습니다. Bitbucket은 검색 색인만 점진적으로 업데이트하므로 Elasticsearch는 데이터베이스 및 파일 시스템보다 낮은 빈도로 복제할 수 있습니다. 예를 들어 검색 인덱스가 동기화되지 않은 날짜인 경우 마지막 날의 변경 내용만 인덱싱하면 됩니다. 다음은 Elasticsearch 복제 전략의 몇 가지 예입니다.

• 복제 없음 – 대기 인스턴스가 온라인 상태가 되면 Bitbucket이 검색 색인을 재구성합니다.

• 백업 및 복원(빈도가 낮음) – Elasticsearch의 정기 백업을 만들어 대기 인스턴스에 복원합니다. Bitbucket은 대기 상태가 온라인 상태가 되면 검색 인덱스를 최신 상태로 유지합니다.

• 백업 및 복원(높은 빈도) – 기본 스냅샷 및 대기 스냅샷의 스냅샷 생성 빈도를 높여 대기 상태가 온라인 상태일 때 인덱스를 최신 상태로 유지할 수 있는 시간을 최소화합니다.

예제 스크립트는 s3 또는 공유 파일 시스템을 스냅샷 저장소로 사용하여 Elasticsearch 스냅샷을 구현합니다. 이러한 스크립트는 스냅샷 저장소를 구성하고 수동 스냅샷을 생성합니다.

이러한 데이터 소스는 Bitbucket 인스턴스의 전체 상태로 구성됩니다. 플러그인에 의해 추가된 파일과 같은 다른 방법을 통해 추가된 파일은 다른 복제 방법이 필요합니다. 이 경우 권장 사항은 플러그인 벤더에 문의하십시오.

작업 예제 스크립트

Atlassian은 선택적으로 재해 복구 복제 및 페일오버 프로세스를 자동화하는 데 사용할 수 있는 몇 가지 작업 예제 스크립트를 atlassian-bucket-di-backup 저장소에 제공합니다. 현재 작업 예는 다음 기술에 대해서만 제공됩니다.

이러한 스크립트는 완벽하게 작동하는 DR 솔루션이 아니라 시작 지점으로 사용하기 위한 것으로, 특정 환경에 맞게 스크립트를 구성하고 사용자 정의한 후에만 사용해야 합니다.

스크립트를 가져오려면 최신 버전의 atlassian-bucket-di-backup을 복제하거나 꺼냅니다.

git clone git@bitbucket.org:atlassianlabs/atlassian-bitbucket-diy-backup.git

스크립트를 구성하기 전에 bitbucket.diy-backup.vars.sh.example 를 bitbucket.diy-backup.vars.sh로 복사하고 환경에 맞게 편집해야 합니다. 재해 복구를 위한 유효한 구성은 다음과 같습니다.

STANDBY_HOME_TYPE=zfs
STANDBY_DATABASE_TYPE=amazon-rds or postgresql

이러한 홈 및 데이터베이스 유형에 대한 추가 변수를 구성하고 기본 시스템과 대기 시스템에 동일한 스크립트를 설치하여 재해 복구에 사용해야 합니다. 재해 복구 스크립트 구성에 대한 자세한 내용은 bitbucket.diy-backup.vars.sh.example을 참조하십시오.

대기 시스템 설정

단계 1. Bitbucket Data Center 4.8 이상 설치

기본 인스턴스를 설정하는 것과 동일한 방법으로 대기 인스턴스에 Bitbucket Data Center를 설치합니다. 대기 인스턴스는 사실상 주 인스턴스의 정확한 복제본이므로 주 인스턴스에 배포된 모든 구성 요소를 대기 상태로 배포해야 합니다. 여기에는 단일 노드 또는 클러스터된 데이터 센터 인스턴스, 데이터베이스, Elastic 검색 및 공유 홈 폴더를 지원하는 파일 서버가 포함됩니다.

단계 2. 대기 인스턴스에 대한 복제 설정

이 섹션에서는 재해 발생 시 데이터 손실을 최소화하면서 페일오버할 수 있도록 대기 인스턴스에 대한 복제를 설정하는 방법에 대해 설명합니다.

1. 파일 서버 복제 설정 - 대기 파일 서버를 주 복제본으로 설정합니다. Bitbucket의 공유 홈 디렉토리와 추가된 데이터 저장소를 포함하는 볼륨만 복제하면 됩니다. 자세한 내용은 파일 서버 공급업체의 설명서를 참조하십시오.
   atlassian-bucket-diy-backup 작업 예제 스크립트를 사용하는 경우 주 파일 서버에서 다음 명령을 실행할 수 있습니다

   Code Block
   ./setup-disk-replication.sh

2. 데이터베이스 복제 설정 - 대기 데이터베이스를 기본 데이터베이스의 읽기 복제본으로 설정합니다. 자세한 내용은 데이터베이스 공급업체의 설명서를 참조하십시오.
   atlassian-bucket-diy-backup 작업 예제 스크립트를 사용하는 경우 주 파일 서버에서 다음 명령을 실행할 수 있습니다

   Code Block
   ./setup-db-replication.sh

3. Elasticsearch 복제 설정(선택 사항) - Elasticsearch 개발자는 스냅샷 리포지토리 설정과 이러한 리포지토리에 포함된 스냅샷을 대기 클러스터로 전송하는 방법에 대한 자세한 지침을 제공합니다. 예제 스크립트는 스냅샷 저장소를 구성하고 s3 또는 공유 파일 시스템 저장소를 사용하여 수동 스냅샷을 생성합니다.

단계3. 복제 시작

복제를 설정한 후에는 기본 인스턴스가 대기 인스턴스로 복제되고 있는지 확인합니다. 복제 방법은 선택한 기술에 따라 다릅니다. 올바르게 설정되면 대부분의 데이터베이스 복제 기술은 자동으로 수행되므로 지속적인 수동 단계가 필요하지 않습니다. 파일 시스템 복제 기술을 사용하려면 기본 시스템에서 대기 상태로 스냅샷을 지속적으로 전송해야 할 수 있습니다(예: cron을 통해).

atlassian-bucket-diy-backup 작업 예제 스크립트를 사용하는 경우 주 파일 서버에서 이 명령을 실행하여 파일 시스템 복제를 수동으로 테스트할 수 있습니다.

./replicate-disk.sh

파일 시스템 복제가 작동하면 조직의 RPO에 따라 정기적으로(예: 매분) 이 명령에 crontab 항목을 추가할 수 있습니다.

재해 복구 테스트

연습은 완벽합니다. 이는 DR 페일오버 프로세스를 검증하는데 적용되지만 심각한 주의사항이 있습니다. Bitbucket의 구성이 Primary에서 복제된 공유 홈 폴더에 있으므로 bitbucket.properties파일의 설정은 테스트를 위해 대기 인스턴스를 시작하기 전에 변경해야 합니다.

재해 복구 계획을 테스트할 때는 각별히 주의해야 합니다. 예를 들어 테스트 업데이트를 프로덕션 데이터베이스에 삽입하는 경우 간단한 오류로 인해 라이브 인스턴스가 손상될 수 있습니다. 재해 복구 계획을 테스트하는 동안 실제 재해로부터 복구하는 능력에 악영향을 미칠 수 있습니다.

대기 인스턴스가 기본 인스턴스인 것처럼 구성되어 재해 복구 계획을 테스트할 때 문제가 발생할 수 있습니다. Bitbucket을 재해 복구 모드로 실행할 때 무결성 검사기가 파일 서버가 데이터베이스와 동기화되지 않을 때 발견한 오류를 수정하려고 할 수 있습니다. 여기에는 앱 링크를 통해 Jira 티켓을 업데이트하고 이메일 알림을 보낼 수 있는 꺼내기 요청 병합, 다시 열기 및 거절 요청이 포함됩니다.

DR 구축 테스트 전 단계

대기 인스턴스를 기본 인스턴스와 분리하려면

1. 데이터베이스 격리 - 대기 데이터베이스에 대한 모든 복제를 일시적으로 일시 중지한 다음 대기 데이터베이스를 승격합니다.
   atlassian-bucket-diy-backup worked 예제 스크립트를 사용하는 경우 대기 데이터베이스에서 다음 명령을 실행할 수 있습니다.

   Code Block
   ./promote-db.sh

2. 파일 시스템 격리 - 대기 파일 시스템에 대한 복제를 일시적으로 일시 중지한 다음 대기 파일 시스템을 승격합니다.
   atlassian-bucket-diy-backup worked 예제 스크립트를 사용하는 경우 대기 파일 시스템에서 다음 명령을 실행할 수 있습니다.

   Code Block
   ./promote-home.sh

3. 대기 중인 bitbucket.properties 파일 편집 - 대기 파일 서버의 Bitbucket 공유 홈에 있는 bitbucket.properties 파일을 업데이트합니다. 다음 속성을 변경합니다:

   1. JDBC 연결 속성

   2. Elasticsearch 연결 속성

   3. disaster.recovery=true 설정

   4. 운영 인스턴스를 가리키는 다른 설정을 업데이트하여 대기 중인 인스턴스를 사용합니다.

재해 복구 테스트 수행

대기 인스턴스를 분리한 후에는 재해 복구 계획을 테스트할 수 있습니다.

DR 배포를 테스트하려면

1. 대기 데이터베이스가 승격되고 쓰기 가능해야 합니다.

2. 새 공유 홈 디렉토리가 준비되었는지 확인합니다.

3. bitbucket.properties 파일이 올바르게 구성되었는지 확인합니다.

4. Bitbucket을 시작합니다.

5. Bitbucket 데이터 센터의 무결성 검사 실행에 설명된 대로 Bitbucket 로그 파일을 모니터링하고 일관성 문제가 있는지 확인합니다.

테스트 후 DR 배포 재설정

DR 배포를 재설정하려면 대기 구성 요소를 복제가 발생할 수 있는 상태로 복원해야 하며, 이 상태는 선택한 파일 서버 및 데이터베이스 복제 기술에 따라 다릅니다. 대부분의 경우 대기 인프라를 다시 설정하는 것이 더 쉬울 수 있습니다.

DR 배포를 재설정하려면

1. 대기 인스턴스의 유효성 검사가 완료되면 Bitbucket을 중지합니다.

2. 파일 서버를 복제가 시작될 수 있는 상태로 복원합니다.

3. 데이터베이스를 복제가 시작될 수 있는 상태로 복원합니다.

페일오버 처리

기본 인스턴스를 사용할 수 없는 경우 대기 시스템으로 페일오버해야 합니다. 이 절에서는 대기 시스템의 데이터를 확인하는 방법에 대한 지침을 포함하여 이 작업을 수행하는 방법에 대해 설명합니다.

대기 인스턴스로 페일오버하려면

1. 대기 데이터베이스 승격 - 대기 데이터베이스가 연결을 허용할 준비가 되어 있는지 확인하고 더 이상 기본 데이터베이스로부터 업데이트를 받을 수 없도록 합니다. 자세한 내용은 데이터베이스 공급업체의 설명서를 참조하십시오.

   atlassian-bucket-diy-backup worked 예제 스크립트를 사용하는 경우 대기 데이터베이스에서 다음 명령을 실행할 수 있습니다.

   Code Block
   ./promote-db.sh

2. 대기 파일 서버 승격 - 대기 파일 서버가 주 파일 서버로부터 추가 업데이트를 받을 수 없도록 합니다. 자세한 내용은 파일 서버 공급업체의 설명서를 참조하십시오.
   atlassian-bucket-diy-backup worked 예제 스크립트를 사용하는 경우 대기 파일 서버에서 다음 명령을 실행할 수 있습니다.

   Code Block
   ./promote-home.sh

3. 대기 중인 bitbucket.properties 파일 편집 - 대기 파일 서버의 Bitbucket 공유 홈에 있는 bitbucket.properties 파일을 업데이트합니다. disaster.recovery=true를 설정하고 모든 속성이 대기 환경에 적합한지 확인합니다. 최소한 다음과 같은 속성이 정의되어 있는지 확인합니다.

   Code Block
   disaster.recovery=true jdbc.url=<the URL of your standby database> plugin.search.elasticsearch.baseurl=<the URL of your standby Elasticsearch instance> hazelcast.network.tcpip.members=<the IP addresses of your standby cluster nodes>

   일반 복제 중에는 대기 상태의 bitbucket.properties가 기본 시스템과 동일합니다. 페일오버 중에는 대기 환경에서 Bitbucket을 시작하기 전에 bitbucket.properties 파일의 구성이 대기 시스템의 구성과 일치하는지 확인하는 것이 중요합니다. 그렇지 않으면 대기 상태가 시작되지 않거나 기본 환경의 서비스에 연결을 시도할 수 없습니다.

4. 대기 인스턴스의 한 노드에서 Bitbucket을 시작합니다.

5. Bitbucket 데이터 센터의 무결성 검사 실행에 설명된 대로 Bitbucket 로그 파일을 모니터링하고 일관성 문제가 있는지 확인합니다.

6. 필요한 경우 다른 Bitbucket 노드를 시작합니다.

7. DNS, HTTP 프록시 또는 기타 프런트 엔드 장치를 업데이트하여 트래픽을 대기 서버로 라우트합니다.

8. 메일 서버가 프로덕션 메일 서버와 다른 경우 메일 서버 구성을 업데이트합니다.

기본 인스턴스로 돌아가기

대부분의 경우 재해의 원인이 된 문제를 해결한 후 기본 인스턴스를 다시 사용하려고 합니다. 여기에는 기본적으로 두 가지 방법이 있습니다.

1. 적절한 크기의 중단 기간을 예약합니다. 대기 시스템의 홈 디렉토리 및 데이터베이스(예: 데이터 복구 및 백업에서 설명하는 도구)를 전체 백업한 후 기본 시스템에 복원합니다.

2. 복제 및 페일오버 단계를 반대로 실행하여 이제 대기 시스템이 기본 역할을 수행하고 원래 기본 시스템이 컷오버될 때까지 대기 상태로 작동합니다.

기타 자원

문제 해결

대기 인스턴스로 페일오버한 후 문제가 발생하는 경우 다음 FAQ에서 지침을 확인하십시오.

데이터베이스가 올바르게 동기화되지 않은 경우 어떻게 해야 합니까?

데이터베이스에 사용 가능한 데이터가 없는 경우 백업에서 데이터베이스를 복원해야 합니다.

페일오버 중에 애플리케이션 링크가 어떻게 됩니까?

응용프로그램 링크는 데이터베이스에 저장됩니다. 데이터베이스 복제본이 최신 상태이면 응용프로그램 링크는 보존됩니다.

그러나 링크의 각 단부가 다른 쪽 주소를 어떻게 알고 있는지도 고려해야 합니다.

• 호스트 이름을 사용하여 링크의 파트너 주소를 지정하는 경우 백업 Bitbucket 서버의 호스트 이름이 DNS 업데이트 등을 통해 동일한 경우 링크가 그대로 유지되고 작동해야 합니다. 

• 응용 프로그램 링크가 IP 주소를 사용하여 작성되었지만 동일하지 않은 경우 응용 프로그램 링크를 다시 설정해야 합니다. 

• 회사 내부 네트워크에서 유효한 IP 주소를 사용하지만 백업 시스템이 원격이고 원래 방화벽 외부에 있는 경우 응용 프로그램 링크를 다시 설정해야 합니다.