Skip to main content

Cluster network configuration

GitHub Enterprise Server clustering relies on proper DNS name resolution, load balancing, and communication between nodes to operate properly.

Network considerations

The simplest network design for clustering is to place the nodes on a single LAN. If a cluster must span subnetworks, we do not recommend configuring any firewall rules between the networks. The latency between nodes should be less than 1 millisecond.

Para obtener alta disponibilidad, la latencia entre la red con los nodos activos y la red con los nodos pasivos debe ser inferior a 70 milisegundos. No te recomendamos configurar una firewall entre las dos redes.

Application ports for end users

Application ports provide web application and Git access for end users.

PortDescriptionEncrypted
22/TCPGit over SSHYes
25/TCPSMTPRequires STARTTLS
80/TCPHTTPNo
(When SSL is enabled this port redirects to HTTPS)
443/TCPHTTPSYes
9418/TCPSimple Git protocol port
(Disabled in private mode)
No

Administrative ports

Administrative ports are not required for basic application use by end users.

PortDescriptionEncrypted
ICMPICMP PingNo
122/TCPAdministrative SSHYes
161/UDPSNMPNo
8080/TCPManagement Console HTTPNo
(When SSL is enabled this port redirects to HTTPS)
8443/TCPManagement Console HTTPSYes

Cluster communication ports

If a network level firewall is in place between nodes, these ports will need to be accessible. The communication between nodes is not encrypted. These ports should not be accessible externally.

PortDescription
1336/TCPInternal API
3033/TCPInternal SVN access
3037/TCPInternal SVN access
3306/TCPMySQL
4486/TCPGovernor access
5115/TCPStorage backend
5208/TCPInternal SVN access
6379/TCPRedis
8001/TCPGrafana
8090/TCPInternal GPG access
8149/TCPGitRPC file server access
8300/TCPConsul
8301/TCPConsul
8302/TCPConsul
9000/TCPGit Daemon
9102/TCPPages file server
9105/TCPLFS server
9200/TCPElasticsearch
9203/TCPSemantic code service
9300/TCPElasticsearch
11211/TCPMemcache
161/UDPSNMP
8125/UDPStatsd
8301/UDPConsul
8302/UDPConsul
25827/UDPCollectd

Configuring a load balancer

We recommend an external TCP-based load balancer that supports the PROXY protocol to distribute traffic across nodes. Consider these load balancer configurations:

  • TCP ports (shown below) should be forwarded to nodes running the web-server service. These are the only nodes that serve external client requests.
  • Sticky sessions shouldn't be enabled.

Advertencia: Cuando se termina una conexión HTTPS en un equilibrador de carga, en las solicitudes de este hacia GitHub Enterprise Server también es necesario usar HTTPS. Bajar la conexión de categoría a HTTP no es compatible.

Handling client connection information

Because client connections to the cluster come from the load balancer, the client IP address can be lost. To properly capture the client connection information, additional consideration is required.

Si tu balanceador de carga lo admite, es altamente recomendable implementar el protocolo PROXY. Cuando no está disponible el soporte de PROXY, también se puede equilibrar la carga de los puertos HTTP y HTTPS mediante el encabezado X-Forwarded-For.

Advertencia de seguridad: Cuando está habilitado la compatibilidad con PROXY o el redireccionamiento de HTTP, es muy importante que ningún tráfico externo pueda acceder directamente a los dispositivos de GitHub Enterprise Server. Si el tráfico externo no se bloquea correctamente, las direcciones IP de origen se pueden falsificar.

Enabling PROXY support on GitHub Enterprise Server

We strongly recommend enabling PROXY support for both your instance and the load balancer.

Nota: GitHub Enterprise Server es compatible con el protocolo de PROXY V1, que no es compatible con los equilibradores de carga de red de AWS. Si utilizas balanceadores de carga de red de AWS con GitHub Enterprise Server, no habilites la compatibilidad con el PROXY.

  • For your instance, use this command:

    $ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
  • For the load balancer, use the instructions provided by your vendor.

    Mapeos de puertos de protocolo TCP de PROXY

Puerto de origenPuerto de destinoDescripción del servicio
2223Git sobre SSH
8081HTTP
443444HTTPS
80808081Consola de gestión HTTP
84438444Consola de gestión de HTTPS
94189419Git

Enabling X-Forwarded-For support on GitHub Enterprise Server

Use el protocolo X-Forwarded-For solo cuando el protocolo PROXY no esté disponible. El encabezado X-Forwarded-For solo funciona con HTTP y HTTPS. La dirección IP informada para las conexiones de Git a través de SSH mostrarán la IP del balanceador de carga.

To enable the X-Forwarded-For header, use this command:

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

Mapeos de puertos de protocolo TCP para usar sin soporte de PROXY

Puerto de origenPuerto de destinoDescripción del servicio
2222Git sobre SSH
2525SMTP
8080HTTP
443443HTTPS
80808080Consola de gestión HTTP
84438443Consola de gestión de HTTPS

Configuring Health Checks

Health checks allow a load balancer to stop sending traffic to a node that is not responding if a pre-configured check fails on that node. If a cluster node fails, health checks paired with redundant nodes provides high availability.

Configura el balanceador de carga para verificar una de estas URL:

  • https://HOSTNAME/status si HTTPS está habilitado (valor predeterminado)
  • http://HOSTNAME/status si HTTPS está deshabilitado

La comprobación devolverá el código de estado 200 (correcto) si el nodo es correcto y está disponible para responder a las solicitudes del usuario final.

Nota: Cuando el dispositivo está en modo de mantenimiento, la dirección URL https://HOSTNAME/status devolverá el código de estado 503 (servicio no disponible). Para más información, vea "Habilitación y programación del modo de mantenimiento".

DNS Requirements

Las búsquedas DNS para el nombre del host de GitHub Enterprise Server se deben resolver con el balanceador de carga. Es recomendable que habilites el aislamiento de subdominio. Si el aislamiento de subdominios está habilitado, un registro comodín adicional (*.HOSTNAME) también se debería resolver en el equilibrador de carga. Para más información, vea "Habilitación del aislamiento de subdominios".