Clusternetzwerk-Konfiguration

Informationen zum Netzwerk für ein GitHub Enterprise Server-Cluster

Jeder Knoten in deinem GitHub Enterprise Server-Cluster muss über das Netzwerk mit allen anderen Knoten im Cluster kommunizieren können. Du kannst die erforderlichen Ports und Protokolle für Endbenutzer*innen, Verwaltung und Kommunikation zwischen den Knoten überprüfen. Um Datenverkehr auf Front-End-Knoten zu verteilen, empfiehlt GitHub die Konfiguration eines externen Lastenausgleichs.

Überlegungen zu Netzwerken

Das einfachste Netzwerkdesign für Clustering besteht darin, die Knoten in einem einzelnen LAN zu platzieren. Wenn ein Cluster mehrere Subnetzwerke abdecken muss, sollten zwischen den Netzwerken keine Firewallregeln konfiguriert werden. Zudem sollte die Latenz kleiner als 1 ms sein.

Die Latenz zwischen primären und Replikatknoten muss kleiner als 70 Millisekunden sein. Es wird nicht empfohlen, eine Firewall zwischen den Netzwerken der Knoten zu konfigurieren.

• Anwendungsports für Endbenutzer
• Verwaltungsports
• Clusterkommunikationsports

Anwendungsports für Endbenutzer

Mit Anwendungsports können Endbenutzer auf Webanwendungen und Git zugreifen.

Port	BESCHREIBUNG	Verschlüsselt
22/TCP	Git über SSH
25/TCP	SMTP	Erfordert STARTTLS
80/TCP	HTTP	Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter.
443/TCP	HTTPS
9418/TCP	Einfacher Git-Protokollport (Im privaten Modus deaktiviert)

Verwaltungsports

Verwaltungsports sind für die einfache Verwendung von Anwendungen durch Endbenutzer nicht erforderlich.

Port	BESCHREIBUNG	Verschlüsselt
ICMP	ICMP-Ping
122/TCP	Verwaltungs-SSH
161/UDP	SNMP
8080/TCP	HTTP für Managementkonsole	Wenn SSL aktiviert ist, leitet dieser Port Elemente an HTTPS weiter.
8443/TCP	HTTPS für Managementkonsole

Clusterkommunikationsports

Wenn sich zwischen Knoten eine Firewall auf Netzwerkebene befindet, müssen diese Ports zugänglich sein. Die Kommunikation zwischen Knoten ist nicht verschlüsselt. Diese Ports sollten extern nicht zugänglich sein.

Port	BESCHREIBUNG
1336/TCP	Interne API
3033/TCP	Interner SVN-Zugriff
3037/TCP	Interner SVN-Zugriff
3306/TCP	MySQL
4486/TCP	Governor-Zugriff
5115/TCP	Speicher-Back-End
5208/TCP	Interner SVN-Zugriff
6379/TCP	Redis
8001/TCP	Grafana
8090/TCP	Interner GPG-Zugriff
8149/TCP	GitRPC-Dateiserverzugriff
8300/TCP	Consul
8301/TCP	Consul
8302/TCP	Consul
9000/TCP	Git-Daemon
9102/TCP	Pages-Dateiserver
9105/TCP	LFS-Server
9200/TCP	Elasticsearch
9203/TCP	Dienst für semantischen Code
9300/TCP	Elasticsearch
11211/TCP	Memcache
161/UDP	SNMP
8125/UDP	Statsd
8301/UDP	Consul
8302/UDP	Consul
25827/UDP	Collectd

Load-Balancer konfigurieren

Du solltest einen externen TCP-basierten Load-Balancer verwenden, der das PROXY-Protokoll unterstützt, um den Traffic auf die Knoten zu verteilen. Beachte die folgenden Load-Balancer-Konfigurationen:

• TCP-Ports (siehe unten) sollten an Knoten weitergeleitet werden, auf denen der Dienst web-server ausgeführt wird. Dies sind die einzigen Knoten, die externe Clientanfragen verarbeiten.
• Sticky Sessions sollten nicht aktiviert werden.

Clientverbindungsinformationen verarbeiten

Da Clientverbindungen zum Cluster vom Load-Balancer stammen, kann die Client-IP-Adresse verloren gehen. Zum entsprechenden Erfassen der Clientverbindungsinformationen sind zusätzliche Überlegungen nötig.

Wenn Dein Load-Balancer das PROXY-Protokoll unterstützen kann, wird dringend empfohlen, es zu implementieren. Wenn keine PROXY-Unterstützung verfügbar ist, kann auch mithilfe des X-Forwarded-For-Headers der Lastenausgleich auf den HTTP- und HTTPS-Ports vorgenommen werden.

PROXY-Unterstützung auf GitHub Enterprise Server

aktivieren

Es wird dringend empfohlen, die PROXY-Unterstützung für deine Instanz und für den Load-Balancer zu aktivieren.

• Führe für deine Instanz den folgenden Befehl aus:

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

• Verwende für den Load-Balancer die von deinem Anbieter bereitgestellten Anweisungen.

PROXY-Protokoll – TCP-Portzuordnungen

Quellport	Zielport	Dienstbeschreibung
22	23	Git über SSH
80	81	HTTP
443	444	HTTPS
8080	8081	HTTP für Managementkonsole
8443	8444	HTTPS für Managementkonsole
9418	9419	Git

X-Forwarded-For-Unterstützung für GitHub Enterprise Server

aktivieren

Verwende das X-Forwarded-For-Protokoll nur, wenn das PROXY-Protokoll nicht verfügbar ist. Der X-Forwarded-For-Header ist nur mit HTTP und HTTPS kompatibel. Bei Git-Verbindungen über SSH wird als IP-Adresse die des Load Balancers angegeben. In einigen Umgebungen werden Client-IP-Adressen im Überwachungsprotokoll der Instanz möglicherweise fälschlicherweise als 127.0.0.1angezeigt.

Führe zum Aktivieren des Headers X-Forwarded-For den folgenden Befehl aus:

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

Protokoll – TCP-Portzuordnungen für die Verwendung ohne PROXY-Unterstützung

Quellport	Zielport	Dienstbeschreibung
22	22	Git über SSH
25	25	SMTP
80	80	HTTP
443	443	HTTPS
8080	8080	HTTP für Managementkonsole
8443	8443	HTTPS für Managementkonsole

Zustandsprüfungen konfigurieren

Zustandsprüfungen ermöglichen einem Load-Balancer, das Senden von Traffic an einen nicht antwortenden Knoten zu stoppen, wenn eine vorkonfigurierte Prüfung auf diesem Knoten fehlschlägt. Wenn ein Clusterknoten fehlschlägt, bieten die mit den redundanten Knoten gekoppelten Zustandsprüfungen Hochverfügbarkeit.

Konfiguriere den Lastenausgleich, um die folgende URL zu überprüfen.

http(s)://HOSTNAME/status

Der Endpunkt gibt den Statuscode 200 (OK) zurück, wenn der Knoten fehlerfrei ist und zum Beantworten von Endbenutzeranforderungen verfügbar ist. Weitere Informationen findest du unter Überwachen einer Hochverfügbarkeitskonfiguration.

DNS-Anforderungen

DNS-Nachschlagevorgänge für den GitHub Enterprise Server-Hostnamen sollten im Load-Balancer aufgelöst werden. Es wird empfohlen, dass Du die Subdomain-Isolation aktivierst. Bei aktivierter Subdomain-Isolation sollte ein zusätzlicher Platzhaltereintrag (*.HOSTNAME) ebenfalls im Lastenausgleich aufgelöst werden. Weitere Informationen findest du unter Subdomain-Isolation aktivieren.