Skip to main content

클러스터 네트워크 구성

GitHub Enterprise Server 클러스터에는 DNS 이름 확인, 부하 분산 및 노드 간 통신이 필요합니다.

누가 이 기능을 사용할 수 있나요?

GitHub은(는) 클러스터링 자격을 결정하며 인스턴스의 라이선스 구성을 사용하도록 설정해야 합니다. 클러스터링은 신중하게 계획해야 하며 관리 오버헤드가 추가로 필요합니다. 자세한 내용은 "클러스터링 정보"을(를) 참조하세요.

GitHub Enterprise Server 클러스터의 네트워킹 정보

GitHub Enterprise Server 클러스터의 각 노드는 네트워크를 통해 클러스터의 다른 모든 노드와 통신할 수 있어야 합니다. 최종 사용자, 관리 및 노드 간의 통신에 필요한 포트 및 프로토콜을 검토할 수 있습니다. GitHub에서는 프런트 엔드 노드 간에 트래픽을 분산하기 위해 외부 부하 분산 장치를 구성할 것을 권장합니다.

네트워크 고려 사항

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

주 노드와 복제본(replica) 노드 사이 대기 시간은 70밀리초 미만이어야 합니다. 노드의 네트워크 사이에 방화벽을 구성하지 않는 것이 좋습니다.

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

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

포트설명암호화됨
22/TCPSSH를 통한 Git
25/TCPSMTPSTARTTLS 필요
80/TCPHTTP

SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨
443/TCPHTTPS
9418/TCP간단한 Git 프로토콜 포트
(프라이빗 모드에서는 사용할 수 없음)

관리 포트

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

포트설명암호화됨
ICMPICMP Ping
122/TCP관리 SSH
161/UDPSNMP
8080/TCP관리 콘솔 HTTP

SSL을 사용할 수 있는 경우 이 포트는 HTTPS로 리디렉션됨
8443/TCP관리 콘솔 HTTPS

클러스터 통신 포트

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

포트설명
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을 확인하도록 Load Balancer를 구성합니다.

http(s)://HOSTNAME/status

노드가 정상이고 서비스 최종 사용자 요청에 사용할 수 있는 경우 엔드포인트는 상태 코드 200(OK)을 반환합니다. 자세한 내용은 "고가용성 구성 모니터링"을(를) 참조하세요.

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

DNS 요구 사항

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