고가용성 구성 정보

고가용성을 구성하는 경우 주 어플라이언스의 모든 데이터 저장소(Git 리포지토리, MySQL, Redis, Elasticsearch)를 복제본 어플라이언스로 단방향 비동기 복제하는 자동화된 설정이 있습니다. 관리 콘솔 암호를 포함하여 대부분의 GitHub Enterprise Server 구성 설정도 복제됩니다. 자세한 내용은 "관리 콘솔에서 인스턴스 관리"을 참조하세요.

GitHub Enterprise Server는 복제본 어플라이언스가 데이터베이스 서비스는 복제 모드로 실행되지만 애플리케이션 서비스는 중지된 상태의 대기 어플라이언스로 실행되는 활성/수동 구성을 지원합니다.

복제가 설정된 후에는 복제본 어플라이언스에서 관리 콘솔에 더 이상 액세스할 수 없습니다. 포트 8443에서 복제본의 IP 주소 또는 호스트 이름으로 이동하면 어플라이언스가 현재 복제본으로 구성되어 있음을 나타내는 “복제 모드의 서버” 메시지가 표시됩니다.

참고: GitHub Enterprise Server에 대해 최대 8개의 고가용성 복제본(수동 및 활성/지역 복제본 모두)이 허용됩니다.

대상 지정된 오류 시나리오

다음을 방지하려면 고가용성 구성을 사용합니다.

운영 체제 오류 또는 복구할 수 없는 애플리케이션으로 인해 소프트웨어가 충돌합니다.
스토리지 하드웨어, CPU, RAM, 네트워크 인터페이스 등을 포함한 하드웨어 오류
AWS, Azure 또는 GCP에 대한 계획되지 않은 유지 관리 이벤트 및 예약된 유지 관리 이벤트를 포함하여 가상화 호스트 시스템 오류
장애 조치(failover) 어플라이언스가 오류의 영향을 받지 않는 별도의 네트워크에 있는 경우 논리적 또는 물리적으로 단절된 네트워크입니다.

고가용성 구성은 다음에 적합한 솔루션이 아닙니다.

스케일 아웃. 지역 복제를 사용하여 트래픽을 지리적으로 분산할 수 있지만 쓰기 성능은 주 어플라이언스의 속도와 가용성으로 제한됩니다. 자세한 내용은 "지역 복제 정보"을 참조하세요.
CI/CD 로드. 주 인스턴스와 지리적으로 멀리 떨어져 있는 CI 클라이언트가 많은 경우 리포지토리 캐시를 구성하는 것이 도움이 될 수 있습니다. 자세한 내용은 "리포지토리 캐싱 정보"을 참조하세요.
주 어플라이언스 백업. 고가용성 복제본이 재해 복구 계획의 오프사이트 백업을 대체하는 것은 아닙니다. 일부 형태의 데이터 손상 또는 손실을 주 어플라이언스에서 복제본으로 즉시 복제할 수 있습니다. 안정적인 과거 상태로 안전하게 롤백하려면 기록 스냅샷을 사용하여 정기 백업을 수행해야 합니다.
가동 중지 시간 없는 업그레이드. 제어된 승격 시나리오에서 데이터 손실 및 분할 브레인(split-brain) 상황을 방지하려면 주 어플라이언스를 유지 관리 모드로 두고 모든 쓰기가 완료될 때까지 기다린 후 복제본을 승격합니다.

네트워크 트래픽 장애 조치(failover) 전략

장애 조치(failover) 동안 주 어플라이언스에서 복제본으로의 네트워크 트래픽 리디렉션을 별도로 구성하고 관리해야 합니다.

DNS 장애 조치(failover)

DNS 장애 조치(failover)에서는 주 GitHub Enterprise Server 어플라이언스를 가리키는 DNS 레코드에 짧은 TTL 값을 사용합니다. 60초에서 5분 사이의 TTL을 사용하는 것이 좋습니다.

장애 조치(failover) 동안 주 어플라이언스를 유지 관리 모드로 두고 해당 DNS 레코드를 복제본 어플라이언스의 IP 주소로 리디렉션해야 합니다. 트래픽을 주 어플라이언스에서 복제본으로 리디렉션하는 데 필요한 시간은 TTL 구성과 DNS 레코드를 업데이트하는 데 필요한 시간에 따라 다릅니다.

지역 복제를 사용하는 경우 트래픽을 가장 가까운 복제본으로 보내도록 지역 DNS를 구성해야 합니다. 자세한 내용은 "지역 복제 정보"을 참조하세요.

부하 분산 장치

부하 분산 장치 디자인은 네트워크 디바이스를 사용하여 Git 및 HTTP 트래픽을 개별 GitHub Enterprise Server 어플라이언스로 전달합니다. 부하 분산 장치를 사용하여 보안 목적으로 어플라이언스로 직접 트래픽을 제한하거나 DNS 레코드 변경 없이 필요한 경우 트래픽을 리디렉션할 수 있습니다. 프록시 프로토콜을 지원하는 TCP 기반 부하 분산 장치를 사용하는 것이 좋습니다. GitHub Enterprise Server 호스트 이름에 대한 DNS 조회는 부하 분산 장치로 확인되어야 합니다. 하위 도메인 격리를 사용하도록 설정하는 것이 좋습니다. 하위 도메인 격리를 사용하도록 설정하면 추가 와일드카드 레코드(*.HOSTNAME)도 부하 분산 장치로 확인되어야 합니다. 자세한 내용은 "하위 도메인 격리 사용"을 참조하세요.

장애 조치(failover) 동안 주 어플라이언스를 유지 관리 모드로 두어야 합니다. 복제본이 주 어플라이언스로 승격되었거나 수동 구성 변경이 필요한 경우 자동으로 감지하도록 부하 분산 장치를 구성할 수 있습니다. 복제본을 주 어플라이언스로 수동으로 승격해야 복제본이 사용자 트래픽에 응답합니다. 자세한 내용은 "부하 분산 장치로 GitHub Enterprise Server 사용"을 참조하세요.

https://HOSTNAME/status URL에 대해 반환되는 상태 코드를 확인하여 GitHub Enterprise Server의 가용성을 모니터링할 수 있습니다. 사용자 트래픽을 서비스할 수 있는 어플라이언스는 상태 코드 200(확인)을 반환합니다. 어플라이언스는 다음과 같은 몇 가지 이유로 503(서비스를 사용할 수 없음)을 반환할 수 있습니다.

어플라이언스는 2노드 고가용성 구성의 복제본과 같은 수동 복제본입니다.
어플라이언스를 유지 관리 모드로 전환합니다.
어플라이언스는 지역 복제 구성의 일부이지만 비활성 복제본입니다.

다음 위치에서 사용할 수 있는 복제 개요 대시보드를 사용할 수도 있습니다.

https://HOSTNAME/setup/replication

복제 관리용 유틸리티

GitHub Enterprise Server에서 복제를 관리하려면 SSH를 통해 복제본 어플라이언스에 연결하여 다음 명령줄 유틸리티를 사용합니다.

ghe-repl-setup

ghe-repl-setup 명령은 GitHub Enterprise Server 어플라이언스를 복제본 대기 모드로 둡니다.

두 어플라이언스 간 통신을 위해 암호화된 WireGuard VPN 터널이 구성됩니다.
데이터베이스 서비스가 복제를 위해 구성되고 시작됩니다.
애플리케이션 서비스를 사용할 수 없습니다. HTTP, Git 또는 기타 지원되는 프로토콜을 통해 복제본 어플라이언스에 액세스하려고 하면 “복제본 모드의 어플라이언스” 유지 관리 페이지 또는 오류 메시지가 표시됩니다.

admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

ghe-repl-start 명령은 모든 데이터 저장소의 활성 복제를 켭니다.

admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

ghe-repl-status 명령은 각 데이터 저장소 복제 스트림에 대해 OK, WARNING 또는 CRITICAL 상태를 반환합니다. WARNING 상태인 복제 채널이 있으면 명령이 종료되고 코드 1이 표시됩니다. 마찬가지로, CRITICAL 상태인 채널이 있으면 명령이 종료되고 코드 2가 표시됩니다.

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

-v 및 -vv 옵션은 각 데이터 저장소의 복제 상태에 대한 세부 정보를 제공합니다.

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-stop

ghe-repl-stop 명령은 모든 데이터 저장소에 대해 일시적으로 복제를 사용하지 않도록 설정하고 복제 서비스를 중지합니다. 복제를 다시 시작하려면 ghe-repl-start 명령을 사용합니다.

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Success: replication was stopped for all services.

ghe-repl-promote

ghe-repl-promote 명령은 복제를 사용하지 않도록 설정하고 복제본 어플라이언스를 주 어플라이언스로 변환합니다. 어플라이언스가 원래 주 어플라이언스와 동일한 설정으로 구성되고 모든 서비스를 사용할 수 있습니다.

복제본을 승격해도 기존 어플라이언스에 대한 복제가 자동으로 설정되지는 않습니다. 복제본을 승격한 후 원하는 경우 새 주 복제본에서 기존 어플라이언스 및 이전 주 복제본으로 복제를 설정할 수 있습니다.

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

ghe-repl-teardown 명령은 복제 모드를 완전히 사용하지 않도록 설정하고 복제본 구성을 제거합니다.