클러스터에 대한 고가용성 복제 구성

클러스터에 대한 고가용성 복제 정보

고가용성을 위해 GitHub Enterprise Server의 클러스터 배포를 구성하여 데이터 센터 또는 클라우드 지역의 중단으로부터 보호할 수 있습니다. 고가용성 구성에서 동일한 복제본 노드 집합은 활성 클러스터의 노드와 동기화됩니다. 하드웨어 또는 소프트웨어 오류가 활성 클러스터의 데이터 센터에 영향을 미치는 경우 수동으로 복제본 노드로 장애 조치(failover)하고 사용자 요청을 계속 처리하여 중단의 영향을 최소화할 수 있습니다.

고가용성 구성에서 데이터 서비스를 호스트하는 노드는 복제본 클러스터와 정기적으로 동기화됩니다. 복제본 노드는 대기 상태로 실행되며 애플리케이션을 제공하거나 사용자 요청을 처리하지 않습니다.

GitHub Enterprise Server 클러스터링에 대한 포괄적인 재해 복구 계획의 일부로 고가용성을 구성하는 것이 좋습니다. 또한 정기적인 백업을 수행하는 것이 좋습니다. 자세한 내용은 "인스턴스에서 백업 구성"을(를) 참조하세요.

필수 조건

하드웨어 및 소프트웨어

활성 클러스터의 각 기존 노드에 대해 동일한 하드웨어 리소스를 사용하여 두 번째 가상 머신을 프로비저닝해야 합니다. 예를 들어 클러스터에 13개의 노드가 있고 각 노드에 12개의 vCPU, 96GB RAM 및 750GB의 연결된 스토리지가 있는 경우 각각 12개의 vCPU, 96GB RAM 및 750GB의 연결된 스토리지가 있는 13개의 새 가상 머신을 프로비저닝해야 합니다.

각 새 가상 머신에서 활성 클러스터의 노드에서 실행되는 동일한 버전의 GitHub Enterprise Server를 설치합니다. 라이선스를 업로드하거나 추가 구성을 수행할 필요가 없습니다. 자세한 내용은 "GitHub Enterprise Server 인스턴스 설정"을(를) 참조하세요.

Note

고가용성 복제에 사용하려는 노드는 독립 실행형 GitHub Enterprise Server 인스턴스여야 합니다. 복제본 노드를 두 번째 클러스터로 초기화하지 마세요.

네트워크

프로비저닝하는 각 새 노드에 고정 IP 주소를 할당해야 하며, 연결을 수락하고 클러스터의 프런트 엔드 계층의 노드로 전달하도록 부하 분산 장치를 구성해야 합니다.

주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다. 복제본 클러스터의 노드 간 네트워크 연결에 대한 자세한 내용은 "클러스터 네트워크 구성"을 참조하세요.

클러스터에 대한 고가용성 복제본 만들기

클러스터에 대한 고가용성 복제본을 만들려면 다음 작업을 완료해야 합니다. 예시 구성을 검토할 수도 있습니다.

활성 노드를 기본 데이터센터에 할당합니다.
클러스터 구성 파일에 복제 노드를 추가합니다.
구성 예시를 검토합니다.

1. 기본 데이터 센터에 활성 노드 할당

복제본 노드에 대한 보조 데이터 센터를 정의하기 전에 활성 노드를 기본 데이터 센터에 할당해야 합니다.

클러스터의 모든 노드에 대한 SSH입니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.
텍스트 편집기의 /data/user/common/cluster.conf에서 클러스터 구성 파일을 엽니다. 예를 들어 Vim을 사용할 수 있습니다. 파일을 편집하기 전에 cluster.conf 파일의 백업을 만듭니다.
Shell
```
sudo vim /data/user/common/cluster.conf
```
```
sudo vim /data/user/common/cluster.conf
```
클러스터의 기본 데이터 센터의 이름을 확인합니다. 클러스터 구성 파일의 맨 위에 있는 [cluster] 섹션은 primary-datacenter 키-값 쌍을 사용하여 기본 데이터 센터의 이름을 정의합니다.
```
[cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
```
- 필요에 따라 primary-datacenter의 값을 편집하여 기본 데이터 센터의 이름을 더욱 설명적이고 정확하게 변경합니다.
클러스터 구성 파일에는 [cluster "HOSTNAME"] 제목 아래에 각 노드가 나열됩니다. 각 노드의 제목 아래에 새 키-값 쌍을 추가하여 데이터 센터에 노드를 할당합니다. 위 3단계의 primary-datacenter와 동일한 값을 사용합니다. 예를 들어 기본 이름(default)을 사용하려는 경우 각 노드의 섹션에 다음 키-값 쌍을 추가합니다.
```
datacenter = primary
```
완료되면 클러스터 구성 파일의 각 노드에 대한 섹션이 다음 예제와 같이 표시됩니다. 키-값 쌍의 순서는 중요하지 않습니다.
```
[cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP-ADDRESS
  ...
...
```
Note

3단계에서 기본 데이터 센터의 이름을 변경한 경우 각 노드에 대한 섹션에서 consul-datacenter 키-값 쌍을 찾아 이름이 변경된 기본 데이터 센터로 값을 변경합니다. 예를 들어 기본 데이터 센터를 primary로 이름을 지정한 경우 각 노드에 대해 다음 키-값 쌍을 사용합니다.
```
consul-datacenter = primary
```
새 구성을 적용합니다. 이 명령을 완료하는 데 다소 시간이 걸릴 수 있으므로 screen 또는 tmux 같은 터미널 멀티플렉서에서 명령을 실행하는 것이 좋습니다.
```
 ghe-cluster-config-apply
```
구성 실행이 완료되면 GitHub Enterprise Server에서 다음 메시지를 표시합니다.
```
Finished cluster configuration
```

GitHub Enterprise Server에서 프롬프트를 표시하면 클러스터의 기본 데이터 센터에 노드에 할당이 완료됩니다.

2. 클러스터 구성 파일에 복제본 노드 추가

고가용성을 구성하려면 클러스터의 모든 활성 노드에 해당하는 복제본 노드를 정의해야 합니다. 활성 노드와 복제본 노드를 모두 정의하는 새 클러스터 구성을 만들려면 다음 작업을 완료합니다.

활성 클러스터 구성 파일의 복사본을 만듭니다.
복사본을 편집하여 활성 노드에 해당하는 복제본 노드를 정의하고 프로비저닝한 새 가상 머신의 IP 주소를 추가합니다.
클러스터 구성의 수정된 복사본을 활성 구성에 다시 병합합니다.
새 구성을 적용하여 복제를 시작합니다.

예제 구성은 “예제 구성 검토”를 참조하세요.

클러스터의 각 노드에 대해 동일한 사양으로 일치하는 가상 머신을 프로비저닝하고 동일한 버전의 GitHub Enterprise Server를 실행합니다. 각 새 클러스터 노드에 대한 IPv4 주소 및 호스트 이름을 확인합니다. 자세한 내용은 “필수 구성 요소”를 참조하세요.

Note

장애 조치(failover) 후 고가용성을 다시 구성하는 경우 기본 데이터 센터의 이전 노드를 대신 사용할 수 있습니다.
클러스터의 모든 노드에 대한 SSH입니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.

기존 클러스터 구성을 백업합니다.

cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

/home/admin/cluster-replica.conf와 같은 임시 위치에 기존 클러스터 구성 파일의 복사본을 만듭니다.
```
grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf
```
이전 단계에서 복사한 임시 클러스터 구성 파일에서 [cluster] 섹션을 제거합니다.
```
git config -f ~/cluster-replica.conf --remove-section cluster
```
복제본 노드를 프로비저닝한 보조 데이터 센터의 이름을 결정한 다음 임시 클러스터 구성 파일을 새 데이터 센터 이름으로 업데이트합니다. SECONDARY를 선택한 이름으로 바꿉니다.
```
sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf
```
복제본 노드의 호스트 이름에 대한 패턴을 결정합니다.

Warning

복제본 노드의 호스트 이름은 고유해야 하며 해당 활성 노드의 호스트 이름과 달라야 합니다.
텍스트 편집기에서 3단계의 임시 클러스터 구성 파일을 엽니다. 예를 들어 Vim을 사용할 수 있습니다.
```
sudo vim ~/cluster-replica.conf
```
임시 클러스터 구성 파일 내의 각 섹션에서 노드의 구성을 업데이트합니다. 클러스터 구성 파일에는 [cluster "HOSTNAME"] 제목 아래에 각 노드가 나열됩니다.
- 섹션 제목에서 따옴표 붙은 호스트 이름과 섹션 내의 hostname 값을 위의 7단계에서 선택한 패턴에 따라 복제본 노드의 호스트 이름으로 변경합니다.
- 이름이 ipv4인 새 키를 추가하고 값을 복제본 노드의 고정 IPv4 주소로 설정합니다.
- 새 키-값 쌍 replica = enabled를 추가합니다.
```
[cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...
```
4단계에서 만든 임시 클러스터 구성 파일의 내용을 활성 구성 파일에 추가합니다.
```
cat ~/cluster-replica.conf >> /data/user/common/cluster.conf
```
보조 데이터 센터에서 기본 MySQL 및 Redis 노드를 지정합니다. REPLICA MYSQL PRIMARY HOSTNAME 및 REPLICA REDIS PRIMARY HOSTNAME을 기존 MySQL 및 Redis 기본 노드와 일치하도록 프로비저닝한 복제본 노드의 호스트 이름으로 바꿉니다.
```
git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME
```
Warning

계속하기 전에 클러스터 구성 파일을 검토합니다.
- 최상위 [cluster] 섹션에서 mysql-master-replica 및 redis-master-replica의 값이 장애 조치(failover) 후 MySQL 및 Redis 기본 데이터 센터로 사용될 보조 데이터 센터의 복제본 노드에 대해 올바른 호스트 이름인지 확인합니다.
- 이름이 [cluster "ACTIVE NODE HOSTNAME"]인 활성 노드에 대한 각 섹션에서 다음 키-값 쌍을 다시 확인합니다.
  - datacenter는 최상위 [cluster] 섹션의 primary-datacenter 값과 일치해야 합니다.
  - consul-datacenter는 datacenter의 값과 일치해야 합니다. 이 값은 최상위 [cluster] 섹션의 primary-datacenter 값과 같아야 합니다.
- 각 활성 노드에 대해 구성에 동일한 역할을 가진 하나의 복제본 노드에 대해 일치하는 섹션이 하나 있는지 확인합니다. 복제본 노드에 대한 각 섹션에서 각 키-값 쌍을 다시 확인합니다.
  - datacenter는 다른 모든 복제본 노드와 일치해야 합니다.
  - consul-datacenter는 다른 모든 복제본 노드와 일치해야 합니다.
  - hostname은 섹션 제목의 호스트 이름과 일치해야 합니다.
  - ipv4는 노드의 고유한 정적 IPv4 주소와 일치해야 합니다.
  - replica는 enabled로 구성되어야 합니다.
- 더 이상 사용되지 않는 오프라인 노드에 대한 섹션을 제거할 수 있습니다.
예제 구성을 검토하려면 “예제 구성 검토”를 참조하세요.
새 클러스터 구성을 초기화합니다. 이 명령을 완료하는 데 다소 시간이 걸릴 수 있으므로 screen 또는 tmux 같은 터미널 멀티플렉서에서 명령을 실행하는 것이 좋습니다.
```
ghe-cluster-config-init
```
초기화가 완료되면 GitHub Enterprise Server에서 다음 메시지를 표시합니다.
```
Finished cluster initialization
```
새 구성을 적용합니다. 이 명령을 완료하는 데 다소 시간이 걸릴 수 있으므로 screen 또는 tmux 같은 터미널 멀티플렉서에서 명령을 실행하는 것이 좋습니다.
```
 ghe-cluster-config-apply
```
구성 실행이 완료되면 클러스터 복제가 올바르게 설정되고 작동하는지 확인합니다.
```
ghe-cluster-repl-status
```
구성 실행이 완료되면 GitHub Enterprise Server에서 다음 메시지를 표시합니다.
```
Finished cluster configuration
```
복제본 노드로 장애 조치(failover)한 후 사용자의 연결을 허용하는 부하 분산 장치를 구성합니다. 자세한 내용은 "클러스터 네트워크 구성"을(를) 참조하세요.

클러스터의 노드에 대한 고가용성 복제 구성을 완료했습니다. 각 활성 노드는 구성 및 데이터를 해당 복제본 노드로 복제하기 시작하며 오류가 발생할 경우 보조 데이터 센터에 대한 부하 분산 장치로 트래픽을 보낼 수 있습니다. 장애 조치(failover)에 대한 자세한 내용은 "복제본 클러스터로 장애 조치(failover) 시작"을 참조하세요.

3. 구성 예시 검토

최상위 [cluster] 구성은 다음 예제와 유사합니다.

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

클러스터 스토리지 계층의 활성 노드에 대한 구성은 다음 예제와 같습니다.

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

스토리지 계층의 해당 복제본 노드에 대한 구성은 다음 예제와 같습니다.

해당 활성 노드와의 중요한 차이점은 굵게 표시됩니다.
GitHub Enterprise Server는 uuid 값을 자동으로 할당하므로 초기화할 복제본 노드에 대해 이 값을 정의해서는 안 됩니다.
*-server 키로 정의된 서버 역할은 해당 활성 노드와 일치합니다.

...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

활성 및 복제본 클러스터 노드 간의 복제 모니터링

클러스터의 활성 노드와 복제본 노드 간의 초기 복제에는 시간이 걸립니다. 시간은 복제할 데이터의 양과 GitHub Enterprise Server의 활동 수준에 따라 달라집니다.

GitHub Enterprise Server 관리 셸을 통해 사용할 수 있는 명령줄 도구를 사용하여 클러스터의 모든 노드에서 진행률을 모니터링할 수 있습니다. 관리 셸에 대한 자세한 내용은 “관리 셸(SSH)에 액세스”를 참조하세요.

모든 서비스의 복제를 모니터링하려면 다음 명령을 사용합니다.

ghe-cluster-repl-status

ghe-cluster-status를 사용하여 클러스터의 전반적인 상태를 검토할 수 있습니다. 자세한 내용은 "명령줄 유틸리티"을(를) 참조하세요.

장애 조치(failover) 후 고가용성 복제 다시 구성

클러스터의 활성 노드에서 클러스터의 복제본 노드로 장애 조치(failover)한 후 두 가지 방법 중 하나로 고가용성을 재구성할 수 있습니다. 선택하는 방법은 장애 조치(failover)한 이유와 원래 활성 노드의 상태에 따라 달라집니다.

보조 데이터 센터의 각 새 활성 노드에 대해 새 복제본 노드 집합을 프로비저닝하고 구성합니다.
원래 활성 노드를 새 복제본 노드로 사용합니다.

고가용성을 다시 구성하는 프로세스는 고가용성을 초기 구성하는 프로세스와 동일합니다. 자세한 내용은 “클러스터에 대한 고가용성 복제본 만들기”를 참조하세요.

원래 활성 노드를 사용하는 경우 고가용성을 재구성한 후 노드에서 유지 관리 모드를 설정 해제해야 합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을(를) 참조하세요.

클러스터에 대한 고가용성 복제를 사용하지 않도록 설정

ghe-cluster-repl-teardown 유틸리티를 사용하는 GitHub Enterprise Server

클러스터의 모든 노드에 대한 SSH입니다. 자세한 내용은 "관리 셸(SSH)에 액세스"을(를) 참조하세요.
텍스트 편집기의 /data/user/common/cluster.conf에서 클러스터 구성 파일을 엽니다. 예를 들어 Vim을 사용할 수 있습니다. 파일을 편집하기 전에 cluster.conf 파일의 백업을 만듭니다.
Shell
```
sudo vim /data/user/common/cluster.conf
```
```
sudo vim /data/user/common/cluster.conf
```
최상위 [cluster] 섹션에서 redis-master-replica 및 mysql-master-replica 키-값 쌍을 삭제합니다.
복제본 노드에 대한 각 섹션을 삭제합니다. 복제본 노드에 대해 replica가 enabled로 구성됩니다.
새 구성을 적용합니다. 이 명령을 완료하는 데 다소 시간이 걸릴 수 있으므로 screen 또는 tmux 같은 터미널 멀티플렉서에서 명령을 실행하는 것이 좋습니다.
```
 ghe-cluster-config-apply
```
구성 실행이 완료되면 GitHub Enterprise Server에서 다음 메시지를 표시합니다.
```
Finished cluster configuration
```

클러스터에 대한 고가용성 복제 구성

이 문서의 내용