Gitlab Geo 환경 장애 복구 시나리오 실습

 

GitLab Geo는 지리적으로 분산된 팀에게 빠르고 신뢰할 수 있는 Git 저장소 접근을 보장해 주는 이점을 제공한다. 하지만 Geo primary node에 문제가 발생하면 어떻게 될까? 이 블로그 글에서는 Geo primary node에 문제가 발생하여 Geo secondary node를 primary node로 승격시켜 다운타임을 최소화하는 장애 복구 과정에 대해 다뤄보려 한다.

 

시나리오는 다음과 같다.

1. Geo primary node에서 장애 발생을 감지한다.
2. Geo primary node를 전부 비활성화한다.
3. Geo secondary node를 Primary node로 승격시킨다.
4. Primary node를 Geo primary node로 설정하고 새로운 Geo secondary node를 설정하여 Geo 환경을 구성한다.

 

본 글은 [Gitlab 고가용성 환경 구성하기]와 [Gitlab 고가용성 Geo 환경 구성하기] 실습으로 Geo 환경을 구성한 후 장애상황을 가정하여 작성한 글이므로 이전 과정을 참고하여 Geo 환경이 구성되면 진행해야 한다.

 

구성 환경

• AWS EC2 Instance
• OS : Amazon Linux 2023
• Kernel : 6.1.61-85.141.amzn2023.x86_64
• Instance type : c5.large / c5.xlarge(Rails node)

전제 조건

• Gitlab Geo Primary Node (https://wlsdn3004.tistory.com/51)
• Gitlab Geo Secondary Node (https://wlsdn3004.tistory.com/52)

설치 버전

• Gitlab 16.6.0-ee

실습 절차

1. Geo primary node 비활성화
2. Geo secondary node 승격
3. Gitlab 대시보드 확인
4. Geo primary node 설정 & Geo secondary node 구성

 

 

1. Geo primary node 비활성화

---

Geo primary node에서 장애가 발생하면 Split Brain 등 문제가 발생할 수 있기 때문에 빠르게 Geo primary node를 비활성화해야 한다.

 

Postgresql, Gitaly, Rails, Sidekiq 인스턴스에서 Gitlab을 중지하고 재부팅 후 Gtilab이 시작되지 않도록 한다.

$ gitlab-ctl stop
$ systemctl stop gitlab-runsvdir.service

 

여기서는 Geo primary node의 모든 인스턴스를 "중지" 하고 진행하였다.

 

2. Geo secondary node 승격

---

"postgresql -> gitaly -> sidekiq & rails" 인스턴스 순서대로 아래 명령을 통해 primary node로 승격시킨다.

$ gitlab-ctl geo promote

 

아래와 같이 성공 메세지가 나오면 정상적으로 승격된 것이다.

...
You successfully promoted the current node! It might take some time to reload the services, and for the changes to take effect.

 

Postgresql 인스턴스로 들어가 "Standby Leader" Role에서 "Leader" Role로 변경되었는지 확인한다.

$ gitlab-ctl patroni members
+ Cluster: postgresql-ha (7307436727722722598) ----+----+-----------+-----------------+
| Member         | Host        | Role    | State   | TL | Lag in MB | Pending restart |
+----------------+-------------+---------+---------+----+-----------+-----------------+
| ip-10-10-1-155 | 10.10.1.155 | Leader  | running |  2 |           | *               |
| ip-10-10-1-201 | 10.10.1.201 | Replica | running |  2 |         0 | *               |
+----------------+-------------+---------+---------+----+-----------+-----------------+

 

Postgresql 인스턴스로 들어가 설정파일(gitlab.rb)에서 기존 Geo secondary node 설정 때 추가하였던 내용을 삭제 및 주석한다.

## /etc/gitlab/gitlab.rb
...
#patroni['standby_cluster']['enable'] = true
#patroni['standby_cluster']['host'] = '10.10.1.233'
#patroni['standby_cluster']['port'] = 5000
#patroni['standby_cluster']['primary_slot_name'] = 'geo_secondary'
#patroni['replication_password'] = 'test3'
#patroni['use_pg_rewind'] = true

#gitlab_rails['db_password'] = 'test1'
#gitlab_rails['enable'] = true
...

 

변경사항을 적용한다.

$ gitlab-ctl reconfigure

 

 

Rails 인스턴스로 들어가 기존 rails 인스턴스 설정파일(gitlab.rb)에서 geo 관련된 정보를 삭제 및 주석한다.

## /etc/gitlab/gitlab.rb
...
#geo_secondary['enable'] = true
#geo_secondary['db_username'] = 'gitlab_geo'
#geo_secondary['db_password'] = 'test5'
#geo_secondary['db_database'] = 'gitlabhq_geo_production'
#geo_secondary['db_host'] = '10.10.1.131'
#geo_secondary['db_port'] = 6432
#geo_secondary['auto_migrate'] = false

#geo_postgresql['enable'] = false
#geo_logcursor['enable'] = true
...

 

변경사항을 적용한다.

$ gitlab-ctl reconfigure

 

이후 Geo secondary node 구성 때 사용하던 Tracking Database(Postgresql)은 삭제한다.

• 참고 : [Tracking Postgresql & Pgbouncer & Consul 구성]
  

 

3. Gitlab 대시보드 확인

---

브라우저에서 Gitlab 대시보드로 접근하여 기존 Gitlab Geo secondary node가 승격되었는지 확인한다.

 

• Admin Area 이동
  • Search or go to... > Admin Area

 

• Geo site 이동
  • Admin Area > Geo > Sites 

 

아래와 같이 Geo secondary node가 primary site로 승격되어 등록되어 있는 걸 확인할 수 있다.

 

4. Geo primary node 설정 & Geo secondary node 구성

---

[1-2. Geo Primary Node 설정]  글을 참고하여 Geo Primary node 설정 및  PostgreSQL Replication Slot을 구성하고 

[2. Geo Secondary Node 구성] 글을 참고하여 Geo secondary node를 구성하면 된다.

 

 

 

결론

---

장애 상황은 예측할 수 없지만, 장애에 대한 대응은 항상 준비되어 있어야 한다. 장애 발생 시 Geo secondary node를 신속하게 primary 노드로 승격시키는 것은 GitLab Geo 환경에서 높은 가용성과 안정성을 유지하는 데 있어 핵심이 된다. 이 시나리오를 통해, 예기치 못한 문제가 발생하더라도 최소한의 중단으로 Gitlab 환경을 운영할 수 있다.