2.5. Das Netzwerk planen¶

2.5.1. Allgemeine Netzwerkanforderungen¶

• Der interne Storage-Traffic muss von anderen Traffic-Typen separiert werden.

2.5.2. Netzwerkbeschränkungen¶

• Die Knoten werden den Clustern über ihre IP-Adressen hinzugefügt und nicht über FQDNs (vollqualifizierte Domain-Namen). Wenn die IP-Adresse eines Knotens im Cluster geändert wird, wird dieser Knoten auch aus dem Cluster entfernt. Wenn Sie in einem Cluster DHCP verwenden wollen, stellen Sie sicher, dass die IP-Adressen an die MAC-Adressen der Netzwerkschnittstellen der jeweiligen Knoten gebunden sind.
• Jeder Knoten muss einen Internetzugang haben, um Updates installieren zu können.
• Der MTU-Wert ist standardmäßig auf 1500 eingestellt. Informationen zur Einstellung eines optimalen MTU-Wertes finden Sie im Abschnitt ‚Schritt 2: Das Netzwerk konfigurieren‘.
• Um korrekte Statistiken durchführen zu können, ist NTP (Network Time Synchornization) erforderlich. NTP ist standardmäßig aktiviert und verwendet den chronyd-Dienst. Wenn Sie stattdessen ntpdate oder ntpd verwenden wollen, müssen Sie chronyd vorher stoppen und deaktivieren.
• Der Traffic-Typ Interne Verwaltung wird bei der Installation automatisch zugewiesen und kann nicht mehr später im Management-Panel geändert werden.
• Auch wenn der Management-Knoten vom Webbrowser aus per Host-Namen erreichbar ist, dürfen Sie bei der Installation keine Host-Namen, sondern nur IP-Adresse angeben.

2.5.3. Anforderungen und Empfehlungen für das Netzwerk pro Knoten¶

• Alle Netzwerkschnittstellen auf einem Knoten müssen mit verschiedenen Subnetzen verbunden sein. Eine Netzwerkschnittstelle kann eine logische getaggte VLAN-Schnittstelle, eine ungetaggte gebündelte Verbindung oder eine Ethernet-Verbindung sein.

• Auch wenn für die Cluster-Knoten die notwendigen iptables-Regeln konfiguriert sind, empfehlen wir bei nicht vertrauenswürdigen öffentlichen Netzwerken (wie dem Internet) die Verwendung einer externen Firewall.

• Welche Ports auf den Cluster-Knoten geöffnet werden, hängt davon ab, welche Services auf dem jeweiligen Knoten ausgeführt werden und welche Traffic-Typen mit diesen assoziiert sind. Bevor Sie einen bestimmten Service auf einem Cluster-Knoten aktivieren, müssen Sie den entsprechenden Traffic-Typ einem Netzwerk zuweisen, mit dem dieser Knoten verbunden ist. Einem Netzwerk einen Traffic-Typ zuzuweisen bedeutet, dass auf den Knoten, die mit diesem Netzwerk verbunden sind, eine Firewall konfiguriert wird, bestimmte Ports auf den Knoten-Netzwerkschnittstellen geöffnet werden und die notwendigen iptables-Regeln festgelegt werden.

  In der nachfolgenden Tabelle sind alle erforderlichen Ports und die Services aufgeführt, die mit diesen assoziiert sind.

  Tab. 2.5.3.1 Offene Ports auf Cluster-Knoten¶

  Service	Traffic-Typ	Port	Beschreibung
  Webbasiertes Control-Panel	Admin-Panel*	TCP 8888	Externer Zugriff auf das Admin-Panel.
  	Self-Service-Panel	TCP 8800	Externer Zugriff auf das Self-Service-Panel.
  Verwaltung	Interne Verwaltung	jeder verfügbare Port	Interne Cluster-Verwaltung und Übertragung von Knoten-Überwachungsdaten an das Admin-Panel.
  Metadaten-Service	Storage	jeder verfügbare Port	Interne Kommunikation zwischen Metadaten-Services sowie mit Chunk-Services und Clients.
  Chunk-Service		jeder verfügbare Port	Interne Kommunikation mit Metadaten-Services und Clients.
  Client		jeder verfügbare Port	Interne Kommunikation mit Metadaten- und Chunk-Services.
  Backup Gateway	ABGW öffentlich	TCP 44445	Externer Datenaustausch mit den Acronis Backup Agenten und der Acronis Backup Cloud.
  	ABGW privat	jeder verfügbare Port	Interne Verwaltung und Datenaustausch zwischen mehreren Backup Gateway-Services.
  iSCSI	iSCSI	TCP 3260	Externer Datenaustausch mit dem iSCSI-Zugriffspunkt.
  S3	S3 öffentlich	TCP 80, 443	Externer Datenaustausch mit dem S3-Zugriffspunkt.
  	OSTOR privat	jeder verfügbare Port	Interner Datenaustausch zwischen mehreren S3-Services.
  NFS	NFS	TCP/UDP 111, 892, 2049	Externer Datenaustausch mit dem NFS-Zugriffspunkt.
  	OSTOR privat	jeder verfügbare Port	Interner Datenaustausch zwischen mehreren NFS-Services.
  Compute	Compute API*		Externer Zugriff auf Standard-OpenStack-API-Endpunkte:
  		TCP 5000	Identity API v3
  		TCP 6080	noVNC Websocket Proxy
  		TCP 8004	Orchestration Service API v1
  		TCP 8041	Gnocchi API (Billing Metering Service)
  		TCP 8774	Compute API
  		TCP 8776	Block Storage API v3
  		TCP 8780	Placement API
  		TCP 9292	Image Service API v2
  		TCP 9313	Key Manager API v1
  		TCP 9513	Container Infrastructure Management API (Kubernetes Service)
  		TCP 9696	Networking API v2
  		TCP 9888	Octavia API v2 (Load Balancer Service)
  	VM privat	UDP 4789	Netzwerkverkehr zwischen VMs in privaten virtuellen Netzwerken.
  		TCP 5900-5999	VNC-Konsolenverkehr
  	VM-Backups	TCP 49300-65535	Externer Zugriff auf NBD-Endpunkte.
  SSH	SSH	TCP 22	Remote-Zugriff per SSH auf Knoten.
  SNMP	SNMP*	UDP 161	Externer Zugriff auf die Storage-Cluster-Überwachungsstatistiken per SNMP-Protokoll.

  * Ports für diese Traffic-Typen dürfen nur auf Management-Knoten offen sein.

2.5.4. Kubernetes-Netzwerkanforderungen¶

Wenn Sie Kubernetes-Cluster im Compute-Cluster bereitstellen und mit diesen arbeiten wollen, müssen Sie sicherstellen, dass Ihre Netzwerkkonfiguration es den Compute- und Kubernetes-Services erlaubt, folgende Netzwerkanfragen zu senden:

1. Die Anfrage, den etcd-Cluster im öffentlichen Discovery Service zu laden — von allen Management-Knoten bis https://discovery.etcd.io über das öffentliche Netzwerk.
2. Die Anfrage, die ‚kubeconfig‘-Datei abzurufen — von allen Management-Knoten über das öffentliche Netzwerk:
   • Wenn HV für die Master-VM aktiviert ist, wird die Anfrage an die öffentliche oder die Floating-IP-Adresse der Load Balancer-VM gesendet, die mit der Kubernetes-API auf Port 6443 assoziiert ist.
   • Wenn HV für die Master-VM deaktiviert ist, wird die Anfrage an die öffentliche oder die Floating-IP-Adresse der Kubernetes Master-VM auf Port 6443 gesendet.
3. Anfragen von Kubernetes Master-VMs an die Compute-APIs (der Traffic-Typ Compute-API) über das Netzwerk mit dem Traffic-Typ VM öffentlich (über eine öffentlich zugängliche VM-Netzwerkschnittstelle oder einen virtuellen Router mit aktivierter SNAT). Standardmäßig wird die Compute-API über die IP-Adresse des Management-Knotens verfügbar gemacht (oder über dessen virtuelle IP-Adresse, wenn Hochverfügbarkeit aktiviert wurde). Aber Sie können auch über einen DNS-Namen auf die Compute-API zugreifen (siehe: Setting a DNS Name for the Compute API).
4. Die Anfrage, das etcd-Cluster-Mitgliederstadium im öffentlichen Discovery Service zu aktualisieren — von Kubernetes Master-VMs bis https://discovery.etcd.io über das Netzwerk mit dem Traffic-Typ VM öffentlich (über eine öffentlich zugängliche VM-Netzwerkschnittstelle oder einen virtuellen Router mit aktivierter SNAT).
5. Die Anfrage, Container-Images aus dem öffentlichen Docker Hub-Repository herunterzuladen — von Kubernetes Master-VMs bis https://registry-1.docker.io über das Netzwerk mit dem Traffic-Typ VM öffentlich (über eine öffentlich zugängliche VM-Netzwerkschnittstelle oder einen virtuellen Router mit aktivierter SNAT).

Es ist außerdem notwendig, dass sich das Netzwerk, in dem Sie einen Kubernetes-Cluster erstellen, nicht mit diesen Standardnetzwerken überschneidet:

• 10.100.0.0/24 — für Netzwerke auf Pod-Ebene verwendet
• 10.254.0.0/16 — für die Zuweisung von Kubernetes-Cluster-IP-Adressen verwendet

2.5.5. Netzwerkempfehlungen für Clients¶

Die nachfolgende Tabelle listet die maximale Netzwerk-Performance auf, die ein Client mit der spezifizierten Netzwerkschnittstelle erreichen kann. Für Clients wird empfohlen, zwischen zwei beliebigen Cluster-Knoten eine 10-Gbit-Netzwerk-Hardware zu verwenden und die Netzwerklatenzen zu minimieren, insbesondere wenn SSD-Laufwerke verwendet werden.