IP-Gruppen – Beispiele und Validierung

Diese Beispiele zeigen typische IP-Gruppen für Datei-, S3- und iSCSI-Dienste. Alle Namen und IP-Adressen sind Beispielwerte. Verwenden Sie die Werte Ihrer eigenen Umgebung.

Die vollständige Beschreibung aller Einstellungen finden Sie unter IP Gruppen.

Schnelle Auswahl der Platzierung

Anwendungsfall	Beispiel	Empfohlene Platzierung	Client-Konfiguration
Ein SMB- oder NFS-Endpunkt mit Failover	files.example.local → 192.168.50.20	Keep addresses together	Clients verwenden den Dienstnamen, nicht die Adresse eines Cluster-Knotens.
SMB, NFS oder S3 über mehrere Gateways	s3.example.local → 192.168.50.31 und 192.168.50.32	Distribute addresses across gateway nodes	Alle vorgesehenen Adressen werden unter demselben DNS-Namen veröffentlicht.
iSCSI-Multipath	Portale 10.20.30.41 und 10.20.30.42	Distribute addresses across gateway nodes	Der Initiator erkennt alle Portale und verwendet einen unterstützten Multipath-Treiber.

Beispiel 1: SMB oder NFS mit einer Dienstadresse

Dieses Muster eignet sich für einen stabilen Dateidienst-Endpunkt mit automatischem Failover.

IP-Gruppe	FileServices
Dienstadresse	192.168.50.20
Gateway-Reihenfolge	EEKAS-1 → EEKAS-2 → EEKAS-3
Adressplatzierung	Keep addresses together
DNS	files.example.local → 192.168.50.20

1. Reservieren Sie die Adresse und schließen Sie sie von DHCP aus.
2. Erstellen Sie die IP-Gruppe mit den vorgesehenen Gateway-Knoten.
3. Weisen Sie die Gruppe dem SMB- oder NFS-Dienst zu.
4. Verbinden Sie Clients über files.example.local.
5. Prüfen Sie den Zugriff und führen Sie anschließend einen kontrollierten Failover-Test durch.

Beispiel 2: Verteilter S3-Zugriff

Dieses Muster verteilt zwei S3-Adressen bevorzugt auf zwei Gateway-Knoten.

IP-Gruppe	S3Service
Dienstadressen	192.168.50.31, 192.168.50.32
Gateway-Reihenfolge	EEKAS-1 → EEKAS-2 → EEKAS-3
Adressplatzierung	Distribute addresses across gateway nodes
DNS	Zwei A-Einträge für s3.example.local
TLS	Das Zertifikat enthält s3.example.local als gültigen Namen.

1. Erstellen Sie beide DNS-Einträge und prüfen Sie, ob Clients beide Adressen erreichen können.
2. Erstellen Sie die verteilte IP-Gruppe mit mindestens zwei geeigneten Gateway-Knoten.
3. Wählen Sie die IP-Gruppe beim Erstellen des S3-Laufwerks aus.
4. Prüfen Sie, ob beide Adressen in der Übersicht unterschiedlichen Knoten zugeordnet sind.
5. Testen Sie DNS und HTTPS aus jedem benötigten Client-Netz.

nslookup s3.example.local
curl -I https://s3.example.local/

Eine nicht authentifizierte S3-Anfrage kann mit einem HTTP-Fehler wie 403 antworten. Entscheidend für diesen Test ist, dass DNS-Auflösung, Netzwerkverbindung und TLS-Prüfung erfolgreich sind.

Beispiel 3: iSCSI mit Multipath

IP-Gruppe	iSCSI-MPIO
Portaladressen	10.20.30.41, 10.20.30.42
Gateway-Knoten	Mindestens zwei geeignete Knoten
Adressplatzierung	Distribute addresses across gateway nodes
Initiator	Alle Portaladressen und Multipath aktiviert

Unter Linux können Sie die Portale und Pfade beispielsweise so prüfen:

iscsiadm -m discovery -t sendtargets -p 10.20.30.41
iscsiadm -m discovery -t sendtargets -p 10.20.30.42
multipath -ll

Prüfen Sie, ob für jede LUN ein optimierter Pfad vorhanden ist und die übrigen Pfade als Standby verfügbar bleiben.

Aktuellen Zustand prüfen

• Serving nodes: Zeigt die Knoten, die aktuell Adressen bereitstellen.
• Gateway order: Entspricht der geplanten Primary-, Secondary- und Fallback-Reihenfolge.
• Address placement: Zeigt bei verteilten Gruppen die Zuordnung jeder Adresse.
• Members: Enthält alle Dienste, die von der Gruppe abhängen.

Prüfkommandos für Clients

Ziel	Beispiel	Erwartung
DNS-Auflösung	nslookup files.example.local	Der Name liefert alle vorgesehenen Dienstadressen.
Routing unter Linux	ip route get 192.168.50.20	Die erwartete Schnittstelle und das richtige Gateway werden verwendet.
S3 über HTTPS	curl -I https://s3.example.local/	Verbindung und Zertifikatsprüfung funktionieren. Der HTTP-Status hängt von der Authentifizierung ab.
iSCSI-Portalerkennung	iscsiadm -m discovery -t sendtargets -p 10.20.30.41	Die erwarteten Targets und Portale werden angezeigt.
Multipath unter Linux	multipath -ll	Optimierte und verfügbare Standby-Pfade sind sichtbar.

Ein fehlgeschlagener Ping-Test beweist nicht automatisch, dass der Dienst nicht erreichbar ist, da ICMP durch eine Firewall blockiert sein kann. Testen Sie deshalb immer auch das tatsächlich verwendete Dienstprotokoll.

Auswirkungen typischer Änderungen

Änderung	Mögliche Auswirkung	Danach prüfen
Gateway-Reihenfolge ändern	Adressen können auf andere Knoten verschoben werden.	Serving nodes, Adresszuordnung und Dienstzugriff.
Gateway-Knoten deaktivieren	Die von ihm bereitgestellten Adressen wechseln auf geeignete Knoten.	Ausreichende verbleibende Gateways und Client-Zugriff.
IP-Adresse hinzufügen oder entfernen	DNS und Client-Konfiguration können angepasst werden müssen.	DNS, Routing, Firewall und Zugriff über jede Adresse.
S3 einer anderen IP-Gruppe zuweisen	Eine kurze Verbindungsunterbrechung ist möglich.	Fortschrittsmeldung, DNS, TLS und Endpunktzugriff.
IP-Gruppe löschen	Die Dienstadressen werden entfernt.	Vorher alle Mitglieder und abhängigen DNS-Einträge entfernen.

Kontrollierten Failover testen

1. Prüfen Sie Clusterzustand, Quorum und mindestens einen alternativen geeigneten Gateway-Knoten.
2. Notieren Sie die aktuelle Zuordnung von Dienstadressen und Knoten.
3. Starten Sie die genehmigte Wartung oder Failover-Maßnahme.
4. Aktualisieren Sie die IP-Gruppenübersicht und prüfen Sie die neue Zuordnung.
5. Testen Sie den Dienst über den DNS-Namen und jede veröffentlichte Adresse.
6. Stellen Sie den Knoten wieder bereit und prüfen Sie, ob er erneut als geeignet angezeigt wird.

Die Dienstadresse muss nach der Wiederherstellung nicht sofort auf den vorherigen Knoten zurückwechseln. Das Verbleiben auf einem gesunden Knoten vermeidet eine zusätzliche Unterbrechung.