Skip to main content
설명서에 자주 업데이트를 게시하며 이 페이지의 번역이 계속 진행 중일 수 있습니다. 최신 정보는 영어 설명서를 참조하세요.
All products
엔터프라이즈 관리자

클러스터 네트워크 구성

이 문서의 내용

GitHub Enterprise Server 클러스터링은 제대로 작동하기 위해 DNS 이름 확인, 부하 분산 및 노드 간 통신에 의존합니다.

네트워크 고려 사항

클러스터링을 위한 가장 간단한 네트워크 디자인은 단일 LAN에 노드를 배치하는 것입니다. 클러스터가 여러 서브 네트워크에 걸쳐 있어야 하는 경우 네트워크 간 방화벽 규칙을 구성하지 않는 것이 좋습니다. 노드 간 대기 시간은 1밀리초 미만이어야 합니다.

고가용성을 위해 활성 노드가 있는 네트워크와 수동 노드가 있는 네트워크 간의 대기 시간은 70밀리초 미만이어야 합니다. 두 네트워크 간에 방화벽을 구성하는 것은 권장되지 않습니다.

최종 사용자를 위한 애플리케이션 포트

애플리케이션 포트는 최종 사용자를 위한 웹 애플리케이션 및 Git 액세스를 제공합니다.

포트Description암호화됨
22/TCPSSH를 통한 GitYes
25/TCPSMTPSTARTTLS 필요
80/TCPHTTPNo
(SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨)
443/TCPHTTPSYes
9418/TCP간단한 Git 프로토콜 포트
(프라이빗 모드에서는 사용할 수 없음)		No

관리 포트

최종 사용자가 사용하는 기본 애플리케이션에는 관리 포트가 필요하지 않습니다.

포트Description암호화됨
ICMPICMP PingNo
122/TCP관리 SSHYes
161/UDPSNMPNo
8080/TCP관리 콘솔 HTTPNo
(SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨)
8443/TCP관리 콘솔 HTTPSYes

클러스터 통신 포트

노드 사이에 네트워크 수준 방화벽이 있는 경우 이 포트에 액세스할 수 있어야 합니다. 노드 간 통신은 암호화되지 않습니다. 외부에서는 이 포트에 액세스할 수 없어야 합니다.

포트Description
1336/TCP내부 API
3033/TCP내부 SVN 액세스
3037/TCP내부 SVN 액세스
3306/TCPMySQL
4486/TCP관리자 액세스
5115/TCP스토리지 백 엔드
5208/TCP내부 SVN 액세스
6379/TCPRedis
8001/TCPGrafana
8090/TCP내부 GPG 액세스
8149/TCPGitRPC 파일 서버 액세스
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit 디먼
9102/TCPPages 파일 서버
9105/TCPLFS 서버
9200/TCPElasticsearch
9203/TCP의미 체계 코드 서비스
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

부하 분산 장치 구성

노드에 트래픽을 분산하기 위한 프록시 프로토콜을 지원하는 외부 TCP 기반 부하 분산 장치를 사용하는 것이 좋습니다. 다음 부하 분산 장치 구성을 고려합니다.

  • TCP 포트(아래 참조)는 web-server 서비스를 실행하는 노드로 전달되어야 합니다. 외부 클라이언트 요청을 처리하는 유일한 노드입니다.
  • 고정 세션을 사용할 수 없어야 합니다.

경고: 부하 분산 장치에서 HTTPS 연결을 종료할 때 부하 분산 장치에서 GitHub Enterprise Server로의 요청도 HTTPS를 사용해야 합니다. HTTP에 대한 연결을 다운그레이드하는 것은 지원되지 않습니다.

클라이언트 연결 정보 처리

클러스터에 대한 클라이언트 연결은 부하 분산 장치에서 들어오므로 클라이언트 IP 주소가 손실될 수 있습니다. 클라이언트 연결 정보를 제대로 캡처하려면 추가 고려 사항이 필요합니다.

부하 분산 장치가 지원할 수 있는 경우 PROXY 프로토콜을 구현하는 것이 좋습니다. 프록시 지원을 사용할 수 없는 경우 X-Forwarded-For 헤더를 사용하여 HTTP 및 HTTPS 포트의 부하를 분산할 수도 있습니다.

보안 경고: 프록시 지원 또는 HTTP 전달을 사용하는 경우 외부 트래픽이 GitHub Enterprise Server 어플라이언스에 직접 연결할 수 없는 것이 중요합니다. 외부 트래픽이 제대로 차단되지 않으면 원본 IP 주소가 위조될 수 있습니다.

GitHub Enterprise Server에서 프록시 지원 사용

인스턴스와 부하 분산 장치에서 모두 프록시 지원을 사용하도록 설정하는 것이 좋습니다.

참고: GitHub Enterprise Server는 AWS Network Load Balancer와 호환되지 않는 PROXY 프로토콜 V1을 지원합니다. GitHub Enterprise Server에서 AWS Network Load Balancer를 사용하는 경우 PROXY 지원을 사용하지 마세요.

  • 인스턴스의 경우 다음 명령을 사용합니다.

    $ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply

  • 부하 분산 장치의 경우 공급업체에서 제공하는 지침을 사용합니다.

    PROXY 프로토콜 TCP 포트 매핑

원본 포트대상 포트서비스 설명
2223SSH를 통한 Git
8081HTTP
443444HTTPS
80808081관리 콘솔 HTTP
84438444관리 콘솔 HTTPS
94189419Git

GitHub Enterprise Server에서 X-Forwarded-For 지원 사용

PROXY 프로토콜을 사용할 수 없는 경우에만 X-Forwarded-For 프로토콜을 사용합니다. X-Forwarded-For 헤더는 HTTP 및 HTTPS에서만 작동합니다. SSH를 통한 Git 연결에 대해 보고된 IP 주소는 부하 분산 장치 IP를 표시합니다.

X-Forwarded-For 헤더를 사용하도록 설정하려면 다음 명령을 사용합니다.

$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply

PROXY 지원 없이 사용할 프로토콜 TCP 포트 매핑

원본 포트대상 포트서비스 설명
2222SSH를 통한 Git
2525SMTP
8080HTTP
443443HTTPS
80808080관리 콘솔 HTTP
84438443관리 콘솔 HTTPS

상태 검사 구성

상태 검사를 사용하면 미리 구성된 검사가 노드에서 실패할 경우 응답하지 않는 노드에 대한 트래픽 전송을 부하 분산 장치에서 중지할 수 있습니다. 클러스터 노드에서 오류가 발생할 경우 중복 노드와 페어링된 상태 검사가 고가용성을 제공합니다.

다음 URL 중 하나를 확인하도록 부하 분산 장치를 구성합니다.

  • https://HOSTNAME/status HTTPS를 사용하는 경우(기본값)
  • http://HOSTNAME/status HTTPS를 사용하지 않는 경우

노드가 정상 상태이고 서비스 최종 사용자 요청에 사용할 수 있는 경우 검사는 상태 코드 200(OK)을 반환합니다.

참고: 어플라이언스가 유지 관리 모드인 경우 https://HOSTNAME/status URL은 상태 코드 503(서비스를 사용할 수 없음)을 반환합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을 참조하세요.

DNS 요구 사항

GitHub Enterprise Server 호스트 이름에 대한 DNS 조회는 부하 분산 장치로 확인되어야 합니다. 하위 도메인 격리를 사용하도록 설정하는 것이 좋습니다. 하위 도메인 격리를 사용하도록 설정하면 추가 와일드카드 레코드(*.HOSTNAME)도 부하 분산 장치로 확인되어야 합니다. 자세한 내용은 "하위 도메인 격리 사용"을 참조하세요.