GitHub Enterprise Server 클러스터 노드 대체 정보
GitHub Enterprise Server 클러스터의 기능 노드를 대체하거나 예기치 않게 실패한 노드를 대체할 수 있습니다.
노드를 대체한 후 GitHub Enterprise Server 인스턴스는 작업을 새 노드에 자동으로 분산하지 않습니다. 인스턴스가 노드 간에 작업을 밸런싱하도록 강제할 수 있습니다. 자세한 내용은 클러스터 워크로드 리밸런싱을(를) 참조하세요.
Warning
충돌을 방지하기 위해, 이전에 클러스터의 노드에 할당된 호스트 이름을 다시 사용하지 마세요.
기능 노드 바꾸기
클러스터의 기존 기능 노드를 대체할 수 있습니다. 예를 들어 VM(가상 머신)에 추가 CPU, 메모리 또는 스토리지 리소스를 제공할 수 있습니다.
기능 노드를 대체하려면 새 VM에 GitHub Enterprise Server 어플라이언스를 설치하고, IP 주소를 구성하고, 클러스터 구성 파일에 새 노드를 추가하고, 클러스터를 초기화하고 구성을 적용한 다음, 대체된 노드를 오프라인으로 전환합니다.
Note
주 데이터베이스 노드를 교체하는 경우, 주 데이터베이스 노드 교체를 참조하세요.
-
대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.
-
관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.
-
모든 노드에서 새로 프로비저닝된 대체 노드를 추가하려면
cluster.conf
파일을 수정하여 실패한 노드를 제거하고 대체 노드를 추가합니다. 예를 들어 이 수정된cluster.conf
파일은ghe-data-node-3
을 새로 프로비저닝된 노드인ghe-replacement-data-node-3
으로 바꿉니다.[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 consul-datacenter = PRIMARY-DATACENTER git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
새 MySQL 복제본(replica) 노드의 데이터베이스 시드를 연기하도록 선택할 수 있습니다. 그러면 트래픽에 대한 어플라이언스를 더 빨리 열 수 있습니다. 자세한 내용은 데이터베이스 시드 연기을(를) 참조하세요.
-
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-init
를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다. -
동일한 노드에서
ghe-cluster-config-apply
를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되고, 수정된cluster.conf
파일에 따라 각 노드가 구성됩니다. -
git-server
,pages-server
, 또는storage-server
등의 데이터 서비스를 제공하는 노드를 오프라인으로 전환하는 경우 해당 노드를 이동하세요. 자세한 내용은 데이터 서비스를 실행하는 클러스터 노드 이동을(를) 참조하세요. -
모든 노드에서 실패한 노드를 오프라인으로 표시하려면 관련 노드 섹션에서 클러스터 구성 파일(
cluster.conf
)을 수정하여offline = true
텍스트를 포함합니다.예를 들어 이 수정된
cluster.conf
는ghe-data-node-3
노드를 오프라인으로 표시합니다.[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
-
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-apply
를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되며, 노드가 오프라인으로 표시됩니다.
응급 상황에서 노드 바꾸기
클러스터에서 실패한 노드를 대체할 수 있습니다. 예를 들어 소프트웨어 또는 하드웨어 문제가 노드의 가용성에 영향을 줄 수 있습니다.
Note
주 데이터베이스 노드를 교체하는 경우, 주 데이터베이스 노드 교체를 참조하세요.
긴급 상황에서 노드를 대체하려면 새 VM에 GitHub Enterprise Server 어플라이언스를 설치하고, IP 주소를 구성하고, 실패한 노드를 오프라인으로 전환하고, 구성을 적용하고, 클러스터 구성 파일에 새 노드를 추가하고, 클러스터를 초기화하고 구성을 적용하고, 필요에 따라 실패한 노드를 제거합니다.
-
대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.
-
관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.
-
모든 노드에서 실패한 노드를 오프라인으로 표시하려면 관련 노드 섹션에서 클러스터 구성 파일(
cluster.conf
)을 수정하여offline = true
텍스트를 포함합니다.예를 들어 이 수정된
cluster.conf
는ghe-data-node-3
노드를 오프라인으로 표시합니다.[cluster "ghe-data-node-3"] hostname = ghe-data-node-3 offline = true ipv4 = 192.168.0.6 # ipv6 = fd12:3456:789a:1::6
-
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-apply
를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되며, 노드가 오프라인으로 표시됩니다. -
모든 노드에서 새로 프로비저닝된 대체 노드를 추가하려면
cluster.conf
파일을 수정하여 실패한 노드를 제거하고 대체 노드를 추가합니다. 예를 들어 이 수정된cluster.conf
파일은ghe-data-node-3
을 새로 프로비저닝된 노드인ghe-replacement-data-node-3
으로 바꿉니다.[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 consul-datacenter = PRIMARY-DATACENTER git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
새 MySQL 복제본(replica) 노드의 데이터베이스 시드를 연기하도록 선택할 수 있습니다. 그러면 트래픽에 대한 어플라이언스를 더 빨리 열 수 있습니다. 자세한 내용은 데이터베이스 시드 연기을(를) 참조하세요.
-
기본 Redis 노드를 교체하는 경우,
cluster.conf
에서redis-master
값을 교체 노드 이름으로 수정합니다.Note
I기본 Redis 노드가 기본 MySQL 노드이기도 한 경우, 주 데이터베이스 노드 교체를 참조하세요.
예를 들어, 이 수정된
cluster.conf
파일은 새로 프로비저닝된 클러스터 노드ghe-replacement-data-node-1
을(를) 기본 Redis 노드로 지정합니다.redis-master = ghe-replacement-data-node-1
-
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-init
를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다. -
동일한 노드에서
ghe-cluster-config-apply
를 실행합니다. 이렇게 하면 구성 파일의 유효성이 검사되고, 클러스터의 각 노드에 복사되고, 수정된cluster.conf
파일에 따라 각 노드가 구성됩니다. -
git-server
,pages-server
, 또는storage-server
등의 데이터 서비스를 제공하는 노드를 오프라인으로 전환하는 경우 해당 노드를 이동하세요. 자세한 내용은 데이터 서비스를 실행하는 클러스터 노드 이동을(를) 참조하세요.
주 데이터베이스 노드 바꾸기(MySQL 또는 MySQL 및 MSSQL)
데이터베이스 서비스를 제공하려면 클러스터에 기본 MySQL 노드와 하나 이상의 복제본(replica) MySQL 노드가 필요합니다. 자세한 내용은 클러스터 노드 정보을(를) 참조하세요.
클러스터에 GitHub Actions가 사용하도록 설정된 경우 다음 단계에서 MSSQL도 고려해야 합니다.
주 MySQL(또는 MySQL 및 MSSQL) 노드에 더 많은 리소스를 할당해야 하거나 실패한 노드를 교체해야 하는 경우 클러스터에 새 노드를 추가할 수 있습니다. 가동 중지 시간을 최소화하려면 새 노드를 추가하고 MySQL(또는 MySQL 및 MSSQL) 데이터를 복제한 다음, 주 노드로 승격합니다. 승격 과정에는 약간의 가동 중지 시간이 필요합니다.
-
대체 노드에 고유한 호스트 이름을 사용하여 GitHub Enterprise Server를 프로비저닝하고 설치합니다.
-
관리 셸 또는 DHCP를 사용하여 대체 노드의 IP 주소만 구성합니다. 다른 설정은 구성하지 마세요.
-
GitHub Enterprise Server 인스턴스에 연결하려면 클러스터의 노드 중 하나에 SSH합니다. 워크스테이션에서 다음 명령을 실행합니다. HOSTNAME을 노드의 호스트 이름으로 바꿉니다. 자세한 내용은 관리 셸(SSH)에 액세스을(를) 참조하세요.
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
텍스트 편집기의
/data/user/common/cluster.conf
에서 클러스터 구성 파일을 엽니다. 예를 들어 Vim을 사용할 수 있습니다. 파일을 편집하기 전에cluster.conf
파일의 백업을 만듭니다.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
클러스터 구성 파일에는
[cluster "HOSTNAME"]
제목 아래에 각 노드가 나열됩니다. 노드에 대한 새 제목을 추가하고 구성을 위한 키-값 쌍을 입력하여 자리 표시자를 실제 값으로 바꿉니다.mysql-server = true
키-값 쌍을 포함해야 합니다.- 클러스터에서 GitHub Actions를 사용하도록 설정한 경우
mssql-server = true
키-값 쌍도 포함해야 합니다. - 다음 섹션은 예시이며 노드의 구성은 다를 수 있습니다.
... [cluster "HOSTNAME"] hostname = HOSTNAME ipv4 = IPV4-ADDRESS # ipv6 = IPV6-ADDRESS consul-datacenter = PRIMARY-DATACENTER datacenter = DATACENTER mysql-server = true redis-server = true ... ...
-
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-init
를 실행합니다. 그러면 클러스터에서 새로 추가된 노드가 초기화됩니다. -
수정된
cluster.conf
를 사용하여 노드의 관리 셸에서ghe-cluster-config-apply
를 실행합니다. 새로 추가된 노드는 복제본 MySQL 노드가 되며 다른 구성된 서비스는 그곳에서 실행됩니다.Note
이전 코드 조각에서는 클러스터에서 GitHub Actions가 사용하도록 설정되어 있다고 가정하지 않습니다.
-
MySQL 복제가 완료될 때까지 기다립니다. 클러스터의 모든 노드에서 MySQL 복제를 모니터링하려면
ghe-cluster-status -v
을(를) 실행합니다.클러스터에서 GitHub Actions를 사용하도록 설정한 경우 MSSQL 복제가 완료될 때까지 기다려야 합니다.
클러스터에 노드를 추가한 직후, 복제가 완료되는 동안 복제 상태에 대한 오류가 표시 될 수 있습니다. 복제는 인스턴스의 로드, 데이터베이스 데이터의 양 및 인스턴스가 데이터베이스 시드를 마지막으로 생성한 시간에 따라 몇 시간이 걸릴 수 있습니다.
-
예약된 유지 관리 기간 동안 유지 관리 모드를 사용하도록 설정합니다. 자세한 내용은 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.
-
ghe-cluster-status -v
를 실행하여 클러스터의 모든 노드에서 MySQL(또는 MySQL 및 MSSQL) 복제가 완료되었는지 확인합니다.Warning
MySQL(또는 MySQL 및 MSSQL) 복제가 완료될 때까지 기다리지 않으면 인스턴스에서 데이터가 손실될 위험이 있습니다.
-
현재 MySQL 기본 노드를 읽기 전용 모드로 설정하려면 MySQL 기본 노드에서 다음 명령을 실행합니다.
Shell echo "SET GLOBAL super_read_only = 1;" | sudo mysql
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
기본 및 복제본 MySQL 노드에 설정된 GTID(전역 트랜잭션 식별자)가 동일해질 때까지 기다립니다. GTID를 검사하려면 클러스터 노드에서 다음 명령을 실행합니다.
Shell ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
- 전역 MySQL 변수가 성공적으로 설정되었는지 확인하려면 다음 명령을 실행합니다.
Shell echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
-
클러스터에서 GitHub Actions가 활성화되면 SSH가 새로운 주 MSSQL 노드가 될 노드로 연결됩니다.
Shell ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
screen
세션 내에서 다음 명령을 실행하여 MSSQL을 새 노드로 승격합니다.
Shell /usr/local/share/enterprise/ghe-mssql-repl-promote
/usr/local/share/enterprise/ghe-mssql-repl-promote
이렇게 하면 현재 주 MSSQL 노드에 액세스하고 정상적인 장애 조치(failover)를 수행할 수 있습니다.
-
기본 및 복제본 MySQL 노드의 GTID가 일치하면 텍스트 편집기에서
/data/user/common/cluster.conf
에 있는 클러스터 구성 파일을 열어 클러스터 구성을 업데이트합니다.- 파일을 편집하기 전에
cluster.conf
파일의 백업을 만듭니다. - 최상위
[cluster]
섹션에서mysql-master
키-값 쌍에서 대체한 노드의 호스트 이름을 제거한 다음, 대신 새 노드를 할당합니다. 새 노드가 기본 Redis 노드이기도 한 경우redis-master
키-값 쌍을 조정합니다. - 클러스터에서 GitHub Actions를 사용하도록 설정한 경우
mssql-server = true
키-값 쌍도 포함해야 합니다.
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- 파일을 편집하기 전에
-
cluster.conf
를 수정한 노드의 셸에서screen
을 시작하고ghe-cluster-config-apply
를 실행합니다. 이 명령은 클러스터를 다시 구성하여 새로 추가된 노드를 주 MySQL 노드로 승격하고 원래 주 MySQL 노드를 복제본으로 변환합니다.Note
이전 코드 조각에서는 클러스터에서 GitHub Actions가 사용하도록 설정되어 있다고 가정하지 않습니다.
-
ghe-cluster-status -v
를 실행하여 클러스터의 모든 노드에서 MySQL(또는 MySQL 및 MSSQL) 복제 상태를 확인합니다. -
클러스터에서 GitHub Actions가 활성화된 경우 새 MySQL 및 MSSQL 노드에서 다음 명령을 실행합니다.
Shell /usr/local/share/enterprise/ghe-repl-post-failover-mssql
/usr/local/share/enterprise/ghe-repl-post-failover-mssql
-
MySQL(또는 MySQL 및 MSSQL) 복제가 완료되면 클러스터의 모든 노드에서 유지 관리 모드를 사용하지 않도록 설정합니다. 유지 관리 모드 사용 설정 및 예약을(를) 참조하세요.