Configuração de rede de cluster

Considerações de rede

A composição de rede mais simples para o clustering é deixar os nós em uma única LAN. Se um cluster abranger sub-redes, não recomendamos configurar quaisquer regras de firewall entre as redes. A latência entre os nós deve ser inferior a 1 milissegundo.

Para alta disponibilidade, a latência entre a rede com os nós ativos e a rede com os nós passivos deve ser inferior a 70 milissegundos. Não recomendamos configurar um firewall entre as duas redes.

Portas de aplicativo para usuários finais

As portas de aplicativo fornecem aplicativos da web e acesso dos usuários finais ao Git.

Porta	Descrição	Criptografia
22/TCP	Git em SSH	Sim
25/TCP	SMTP	Requer STARTTLS
80/TCP	HTTP	Não (com SSL habilitado, essa porta redireciona para HTTPS)
443/TCP	HTTPS	Sim
9418/TCP	Porta de protocolo simples do Git (desabilitada no modo privado)	Não

Portas administrativas

Não é preciso haver portas administrativas para os usuários finais aproveitarem os recursos básicos do aplicativo.

Porta	Descrição	Criptografia
ICMP	Ping ICMP	Não
122/TCP	SSH administrativa	Sim
161/UDP	SNMP	Não
8080/TCP	HTTP de console de gerenciamento	Não (com SSL habilitado, essa porta redireciona para HTTPS)
8443/TCP	HTTPS de console de gerenciamento	Sim

Portas de comunicação de cluster

Se houver um firewall no nível da rede entre os nós, essas portas terão que estar acessíveis. A comunicação entre os nós não é criptografada, e essas portas não devem ficar acessíveis externamente.

Porta	Descrição
1336/TCP	API interna
3033/TCP	Acesso SVN interno
3037/TCP	Acesso SVN interno
3306/TCP	MySQL
4486/TCP	Acesso do controlador
5115/TCP	Backend de armazenamento
5208/TCP	Acesso SVN interno
6379/TCP	Redis
8001/TCP	Grafana
8090/TCP	Acesso GPG interno
8149/TCP	Acesso GitRPC ao servidor de arquivos
8300/TCP	Consul
8301/TCP	Consul
8302/TCP	Consul
9000/TCP	Git Daemon
9102/TCP	Servidor de arquivos do Pages
9105/TCP	Servidor LFS
9200/TCP	ElasticSearch
9203/TCP	Serviço de código semântico
9300/TCP	ElasticSearch
11211/TCP	Memcache
161/UDP	SNMP
8125/UDP	Statsd
8301/UDP	Consul
8302/UDP	Consul
25827/UDP	Collectd

Configurar um balanceador de carga

É recomendável usar um balanceador de carga baseado em TCP compatível com o protocolo PROXY para distribuir o tráfego entre os nós. Veja estas configurações de balanceador de carga:

• Portas TCP (abaixo) devem ser encaminhadas para nós que executem o serviço web-server; são os únicos nós que funcionam com solicitações de clientes externos.
• Sessões temporárias não devem ser habilitadas.

Informações de conexão do cliente

Como as conexões do cliente com o cluster vêm do balanceador de carga, pode ocorrer a perda do endereço IP do cliente. Para captar as informações de conexão do cliente de maneira adequada, é preciso fazer considerações adicionais.

Se o seu balanceador de carga puder apoiá-lo, recomendamos fortemente a implementação do protocolo PROXY. Quando não há suporte PROXY disponível, também é possível carregar o saldo das portas HTTP e HTTPS usando o cabeçalho X-Forwarded-For.

Habilitar o suporte PROXY no GitHub Enterprise Server

É altamente recomendável ativar o suporte PROXY para sua instância e o balanceador de carga.

• Na instância, use este comando:

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

• No balanceador de carga, siga as instruções do seu fornecedor.

  Mapeamentos das portas TCP PROXY

Porta de origem	Porta de destino	Descrição do serviço
22	23	Git em SSH
80	81	HTTP
443	444	HTTPS
8080	8081	HTTP de console de gerenciamento
8443	8444	HTTPS de console de gerenciamento
9418	9419	Git

Habilitar o suporte X-Forwarded-For no GitHub Enterprise Server

Usar o protocolo X-Forwarded-For only quando o protocolo PROXY não estiver disponível. O cabeçalho X-Forwarded-For funciona somente com HTTP e HTTPS. O endereço IP informado para conexões Git por SSH mostrará o IP do balanceador de carga.

Para habilitar o header X-Fowarded-For, use este comando:

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

Mapeamentos de portas TCP para uso sem suporte PROXY

Porta de origem	Porta de destino	Descrição do serviço
22	22	Git em SSH
25	25	SMTP
80	80	HTTP
443	443	HTTPS
8080	8080	HTTP de console de gerenciamento
8443	8443	HTTPS de console de gerenciamento

Configurar verificações de integridade

As verificações de integridade permitem que um balanceador de carga pare de enviar tráfego para um nó que não responde em caso de falha na verificação pré-configurada do nó em questão. Em caso de falha em um nó do cluster, as verificações de integridade emparelhadas com nós redundantes fornecerão alta disponibilidade.

Configure o balanceador de carga para verificar uma destas URLs:

• https://HOSTNAME/status if HTTPS is enabled (default)
• http://HOSTNAME/status if HTTPS is disabled

A verificação retornará o código de estado 200 (OK) se o nó estiver saudável e disponível para solicitações de usuário final.

Requisitos de DNS

Buscas de DNS para o nome de host GitHub Enterprise Server devem se resolver para o balanceador de carga. Recomendamos que você ative o isolamento de subdomínio. Se o isolamento do subdomínio estiver ativado, um registro adicional de curinga (*.HOSTNAME) também deve resolver para o balanceador de carga. Para obter mais informações, consulte "Habilitar isolamento de subdomínio".