클러스터에 대한 고가용성 복제 정보
고가용성을 위해 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 인스턴스 설정"을(를) 참조하세요.
참고: 고가용성 복제에 사용하려는 노드는 독립 실행형 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 ... ...
참고: 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 주소 및 호스트 이름을 확인합니다. 자세한 내용은 “필수 구성 요소”를 참조하세요.
참고: 장애 조치(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
-
복제본 노드의 호스트 이름에 대한 패턴을 결정합니다.
경고: 복제본 노드의 호스트 이름은 고유해야 하며 해당 활성 노드의 호스트 이름과 달라야 합니다.
-
텍스트 편집기에서 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
경고: 계속하기 전에 클러스터 구성 파일을 검토합니다.
- 최상위
[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