test

Systemverwaltungshandbuch: IP Services

Kapitel 30 Einführung in IPMP (Übersicht)

IP-Netzwerk-Multipathing (IPMP) bietet eine Erkennung von Ausfällen physikalischer Schnittstellen und transparentes Failover des Netzwerkzugriffs bei einem System mit mehreren Schnittstellen in der gleichen IP-Verbindung. Darüber hinaus bietet IPMP Lastverteilung von Paketen für Systeme mit mehreren Schnittstellen.

Dieses Kapitel enthält die folgenden Informationen:

Aufgaben zur Konfiguration von IPMP finden Sie in Kapitel 31Verwaltung von IPMP (Aufgaben).

Gründe für IPMP

IPMP bietet Systemen mit mehreren physikalischen Schnittstellen Verbesserungen bei Zuverlässigkeit, Verfügbarkeit und Netzwerkleistung. Gelegentlich könnte eine physikalische Schnittstelle oder die an diese Schnittstelle angeschlossene Netzwerkhardware ausfallen oder Wartung erfordern. Früher konnte das System in diesem Fall nicht mehr über eine der IP-Adressen erreicht werden, die der ausgefallenen Schnittstelle zugewiesen sind. Darüber hinaus wurden alle bestehenden Verbindungen zu dem System unterbrochen, das diese IP-Adressen verwendet.

Mit IPMP können Sie eine oder mehrere physikalische Schnittstellen als eine IP Multipathing-Gruppe (oder IPMP-Gruppe) konfigurieren. Nach der Konfiguration von IPMP überwacht das System die Schnittstellen in der IPMP-Gruppe automatisch auf Ausfälle. Sollte eine Schnittstelle in der Gruppe ausfallen oder zu Wartungszwecken deaktiviert werden, migriert IPMP automatisch die IP-Adressen der ausgefallenen Schnittstelle oder es findet ein Failover statt. Der Empfänger dieser Adressen wird eine ordnungsgemäß arbeitende Schnittstelle in der IPMP-Gruppe der ausgefallenen Schnittstelle. Die Failover-Funktion von IPMP erhält die Netzfähigkeit und verhindert eine Unterbrechung existierender Verbindungen. Darüber hinaus verbessert IPMP die allgemeine Leistung von Netzverbindungen, in dem Netzverkehr automatisch über das Schnittstellenset in der IPMP-Gruppe verteilt wird. Dieser Vorgang heißt Lastverteilung.

Oracle Solaris IPMP-Komponenten

Oracle Solaris IPMP umfasst die folgende Software:

Multipathing-Daemon, in.mpathd

Der in.mpathd-Daemon erkennt Schnittstellenausfälle und implementiert dann verschiedene Verfahren zum Failover und Failback. Nachdem in.mpathd einen Ausfall oder eine vollzogene Reparatur erkannt hat, sendet der Daemon ein ioctl, um entweder Failover oder Failback durchzuführen. Das ip-Kernelmodul, das ioctl implementiert, führt den Netzwerkzugriff-Failover transparent und automatisch durch.

Hinweis –

Verwenden Sie kein Alternate Pathing, so lange Sie IPMP auf dem gleichen Satz Netzwerkschnittstellenkarten verwenden. Entsprechend sollten Sie kein IPMP verwenden, wenn Sie Alternate Pathing einsetzen. Sie können jedoch Alternate Pathing und IPMP gleichzeitig auf unterschiedlichen Schnittstellensätzen anwenden. Weitere Informationen zum Alternate Pathing finden Sie imSun Enterprise Server Alternate Pathing 2.3.1 User Guide.

Der in.mpathd erkennt Ausfälle und Reparaturen, in dem er Stichproben an alle Schnittstellen sendet, die zu einer IPMP-Gruppe gehören. Darüber hinaus erkennt der in.mpathd-Daemon Ausfälle und Reparaturen durch Überwachen des Flags RUNNING jeder Schnittstelle in der Gruppe. Weitere Informationen finden Sie in der Manpage in.mpathd(1M).

Hinweis –

DHCP unterstützt die Verwaltung von IPMP-Datenadressen nicht. Wenn Sie versuchen, DHCP für diese Adressen zu verwenden, wird DHCP diese Adressen nicht mehr steuern. Verwenden Sie DHCP nicht für Datenadressen.

IPMP-Terminologie und Konzepte

In diesem Abschnitt werden Begriffe und Konzepte vorgestellt, die in den weiteren Kapiteln zum IPMP in diesem Handbuch verwendet werden.

IP-Link

In der IPMP-Terminologie ist ein IP-Link eine Kommunikationseinrichtung bzw. ein -medium, über das Knoten auf der Übertragungsschicht der Internet-Protokollfamilie kommunizieren können. Zu den IP-Links gehören einfache Ethernets, Bridged-Ethernets, Hubs oder Asynchronous Transfer Mode (ATM)-Netzwerke. Ein IP-Link kann über eine oder mehrere IPv4-Teilnetznummern, und, sofern anwendbar, über einen oder mehrere IPv6-Teilnetzpräfixe verfügen. Eine Teilnetznummer oder ein Präfix kann nur einen IP-Link zugeordnet werden. In ATM LANE ist ein IP-Link ein einzelnes, emuliertes Local Area Network (LAN). Beim Address Resolution Protocol (ARP) umfasst der Bereich des ARP-Protokolls einen IP-Link.

Hinweis –

Andere IP-bezogene Dokumente wie z. B. RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, verwenden den Begriff Link anstelle von IP-Link. In Teil VI wird der Begriff IP-Link verwendet, um Verwechslungen mit IEEE 802 zu vermeiden. In IEEE 802 bezeichnet der Begriff Link eine einpolige Verbindung von einer Ethernet-Netzwerkschnittstellenkarte (NIC) zu einem Ethernet-Switch.

Physikalische Schnittstelle

Eine physikalische Schnittstelle sorgt für den Anschluss des Systems an einen IP-Link. Dieser Anschluss wird häufig als ein Gerätetreiber und eine NIC umgesetzt. Wenn Ihr System über mehrere Schnittstellen verfügt, die an den gleichen Link angeschlossen sind, können Sie IPMP so konfigurieren, dass beim Ausfall einer der Schnittstellen ein Failover stattfindet. Weitere Informationen zu physikalischen Schnittstellen finden Sie unter IPMP-Schnittstellenkonfigurationen.

Netzwerkschnittstellenkarte

Eine Netzwerkschnittstelle ist ein Netzwerkadapter, der in ein System integriert werden kann. Alternativ kann die NIC als separate Karte verwendet werden, die als Schnittstelle eines Systems mit einem IP-Link dient. Einige NICs verfügen über mehrere physikalische Schnittstellen. Beispielsweise kann eine qfe-NIC über vier Schnittstellen, qfe0 bis qfe3 verfügen.

IPMP-Gruppe

Eine IP-Multipathing-Gruppe (oder IPMP-Gruppe) setzt sich aus einer oder mehreren physikalischen Schnittstellen im gleichen System zusammen, die unter dem gleichen IPMP-Gruppennamen konfiguriert sind. Alle Schnittstellen in der IPMP-Gruppe müssen an den gleichen IP-Link angeschlossen sein. Alle Schnittstellen in der Gruppe sind durch den gleichen Zeichenstring (nicht-Null) für einen IPMP-Gruppennamen gekennzeichnet. Sie können Schnittstellen von NICs mit unterschiedlichen Geschwindigkeiten in die gleiche IPMP-Gruppe aufnehmen, solange die NICs den gleichen Typ aufweisen. Beispielsweise können Sie die Schnittstellen von 100-Megabit Ethernet-NICs und die Schnittstellen von 1-Gigabit Ethernet-NICs in die gleiche Gruppe aufnehmen. Ein anderes Beispiel geht von zwei 100-Megabit Ethernet-NICs aus. Sie können eine der Schnittstellen als 10-Megabit-NIC konfigurieren und dennoch beide Schnittstellen in die gleiche IPMP-Gruppe aufnehmen.

Es ist jedoch nicht möglich, zwei Schnittstellen unterschiedlichen Medientyps in eine IPMP-Gruppe aufzunehmen. So können Sie eine ATM-Schnittstelle nicht in die gleiche Gruppe wie eine Ethernet-Schnittstelle aufnehmen.

Ausfallerkennung und Failover

Ausfallerkennung ist der Prozess, wenn erkannt wird, dass eine Schnittstelle oder ein Pfad von einer Schnittstelle zu einem Gerät auf der Internetschicht nicht mehr funktioniert. IPMP bietet Systemen die Möglichkeit, den Ausfall einer Schnittstelle zu erkennen. IPMP kann die folgenden Arten von Kommunikationsausfällen erkennen:

Nach einem erkannten Ausfall leitet IPMP einen Failover-Prozess ein. Failover ist der automatische Prozess, den Netzwerkzugriff von einer ausgefallenen Schnittstelle auf eine funktionierende physikalische Schnittstelle in der gleichen Gruppe umzuschalten. Netzwerkzugriff umfasst IPv4 Unicast-, Multicast- und Broadcast-Verkehr sowie IPv6 Unicast- und Multicast-Verkehr. Failover kann nur dann stattfinden, wenn mindestens zwei Schnittstellen in der IPMP-Gruppe konfiguriert sind. Ein Failover-Prozess stellt unterbrechungsfreien Zugriff auf das Netzwerk sicher.

Reparaturerkennung und Failback

Bei einer Reparaturerkennung wird erfasst, dass eine NIC oder der Pfad von einer NIC zu einem Gerät auf der Internetschicht nach einem Ausfall wieder ordnungsgemäß funktioniert. Nachdem die Reparatur einer NIC erkannt wurde, führt IPMP ein Failback durch – der Prozess, bei dem der Netzwerkzugriff auf die reparierte Schnittstelle zurückgeschaltet wird. Für eine Reparaturerkennung wird vorausgesetzt, dass Failbacks aktiviert worden sind. Weitere Informationen finden Sie unter Erkennen der Reparatur physikalischer Schnittstellen.

Zielsysteme

Die Stichproben-basierte Ausfallerkennung verwendet Zielsysteme, um den Zustand einer Schnittstelle zu ermitteln. Jedes Zielsystem muss an den gleichen IP-Link wie die Mitglieder der IPMP-Gruppe angeschlossen sein. Der in.mpathd-Daemon im lokalen System sendet ICMP-Stichprobennachrichten an alle Zielsysteme. Die Stichprobennachrichten helfen dabei, den Zustand jeder Schnittstelle in der IPMP-Gruppe zu ermitteln.

Weitere Informationen zu Zielsystemen, die bei der Stichproben-basierten Ausfallerkennung verwendet werden, finden Sie unter Stichproben-basierte Ausfallerkennung.

Abgehende Lastverteilung

Bei konfiguriertem IPMP werden abgehende Netzwerkpakete ohne Auswirkungen auf die Reihenfolge der Pakete auf mehrere NICs verteilt. Dieser Prozess wird als Lastverteilung bezeichnet. Durch eine Lastverteilung wird ein höherer Durchsatz im Netzwerk erreicht. Eine Lastverteilung tritt nur ein, wenn der Netzwerkverkehr über mehrere Verbindungen an mehrere Ziele fließt.

Dynamische Rekonfiguration

Dynamische Rekonfiguration (DR) ist die Fähigkeit, ein System im laufenden Zustand ohne oder mit nur geringen Auswirkungen auf vorhandene Vorgänge neu zu konfigurieren. Nicht alle Sun-Plattformen unterstützen DR. Einige Sun-Plattformen unterstützen DR nur bei bestimmten Hardwaretypen. Auf Plattformen, die die DR von NICs unterstützen, kann IPMP für transparentes Failover des Netzwerkzugriffs verwendet werden und so unterbrechungsfreien Netzwerkzugriff für das System bereitstellen.

Weitere Informationen, wie IPMP die DR unterstützt, finden Sie unter IPMP und Dynamische Rekonfiguration.

Allgemeine Anforderungen von IPMP

IPMP ist in Oracle Solaris integriert und benötigt keine spezielle Hardware. Jede Schnittstelle, die von Oracle Solaris unterstützt wird, kann mit IPMP verwendet werden. IPMP stellt jedoch die folgenden Anforderungen an Netzwerkkonfiguration und -topologie:

IPMP-Adressierung

Sie können die IPMP-Ausfallerkennung sowohl unter IPv4-Netzwerken und Dual-Stack IPv4- und IPv6-Netzwerken konfigurieren. Für IPMP konfigurierte Schnittstellen unterstützen zwei Arten von Adressen: Datenadressen und Testadressen.

Datenadressen

Datenadressen sind konventionelle IPv4- und IPv6-Adressen, die der Schnittstelle einer NIC entweder beim Booten oder manuell über den Befehl ifconfig zugewiesen wurden. Der standardmäßige IPv4- und, sofern anwendbar, IPv6-Paketverkehr über eine Schnittstelle wird als Datenverkehr angesehen.

Testadressen

Testadressen sind IPMP-spezifische Adressen, die vom in.mpathd-Daemon verwendet werden. Damit eine Schnittstelle Stichproben-basierte Ausfall- und Reparaturerkennung unterstützt, muss mindestens eine Testadresse für sie konfiguriert worden sein.

Hinweis –

Testadressen müssen nur dann konfiguriert werden, wenn eine Stichproben-basierte Ausfallerkennung verwendet werden soll.

Der in.mpathd-Daemon verwendet Testadressen, um ICMP-Stichproben (so genannter Stichprobenverkehr) mit anderen Zielen auf dem IP-Link auszutauschen. Über den Stichprobenverkehr kann der Status einer Schnittstelle und der dazugehörigen NIC ermittelt werden; so auch, ob eine Schnittstelle ausgefallen ist. Anhand der Stichprobenwerte wird überprüft, ob Sende- und Empfangspfad zur Schnittstelle ordnungsgemäß funktionieren.

Jede Schnittstelle kann mit einer IP-Testadresse konfiguriert werden. Für eine Schnittstelle in einem Dual-Stack-Netzwerk können Sie eine IPv4-Testadresse, eine IPv6-Testadresse oder sowohl IPv4- als auch IPv6-Testadressen konfigurieren.

Nach dem Ausfall einer Schnittstelle verbleiben die Testadressen bei der ausgefallenen Schnittstelle, so dass in.mpathd weiterhin Stichproben senden kann, um auf den Abschluss einer Reparatur zu prüfen. Sie müssen Testadressen gesondert konfigurieren, so dass sie nicht versehentlich von Anwendungen verwendet werden. Weitere Informationen hierzu finden Sie unter Verwenden der Testadressen durch Anwendungen verhindern.

Weitere Informationen zur Stichproben-basierten Ausfallerkennung finden Sie unter Stichproben-basierte Ausfallerkennung.

IPv4-Testadressen

Im Allgemeinen können Sie jede IPv4-Adresse in Ihren Teilnetz als Testadresse verwenden. IPv4-Testadressen müssen nicht routefähig sein. Da IPv4-Adressen an vielen Standorten nur beschränkt verfügbar sind, sollten Sie eventuell nicht-routefähige RFC 1918-Privatadressen als Testadressen verwenden. Beachten Sie, dass der in.mpathd-Daemon ICMP-Stichproben nur mit anderen Hosts im Teilnetz der Testadresse austauscht. Wenn Sie Testadressen im RFC 1918-Stil verwenden, müssen Sie darauf achten, andere Systeme (vorzugsweise Router) auf dem IP-Link mit Adressen im entsprechenden RFC 1918-Teilnetz zu konfigurieren. Erst dann kann der in.mpathd-Daemon Stichproben erfolgreich mit Zielsystemen austauschen.

Die IPMP-Beispiele verwenden RFC 1918-Adressen aus dem Netzwerk 192.168.0/24 als IPv4-Testadressen. Weitere Informationen zu privaten RFC 1918-Adressen finden Sie unter RFC 1918, Address Allocation for Private Internets.

Informationen zur Konfiguration von IPv4-Testadressen finden Sie unter So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen.

IPv6-Testadressen

Die einzige gültige IPv6-Testadresse ist die Link-lokale Adresse einer physikalischen Schnittstelle. Für eine IPMP-Testadresse ist keine separate IPv6-Adresse erforderlich. Die Link-lokale Adresse basiert auf der Media Access Control (MAC)-Adresse der Schnittstelle. Link-lokale Adressen werden automatisch konfiguriert, wenn die Schnittstelle beim Booten oder manuell mithilfe des Befehls ifconfig für IPv6 aktiviert wird.

Zum Ermitteln der Link-lokalen Adresse einer Schnittstelle führen Sie den Befehl ifconfig Schnittstelle auf einem IPv6-aktivierten Knoten aus. Achten Sie auf die Ausgabe für die Adresse, die mit dem Präfix fe80 (dem Link-lokalen Präfix) beginnt. Das Flag NOFAILOVER in der folgenden ifconfig-Ausgabe zeigt, dass die Link-lokale Adresse fe80::a00:20ff:feb9:17fa/10 der Schnittstelle hme0 als Testadresse verwendet wird. 


hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:17fa/10

Weitere Informationen zu Link-lokalen Adressen finden Sie unter Link-lokale Unicast-Adresse.

Wenn eine IPMP-Gruppe sowohl IPv4 als auch IPv6 für alle Schnittstellen der Gruppe geplumbt (aktiviert) hat, müssen keine separaten IPv4-Testadressen mehr konfiguriert werden. Der in.mpathd-Daemon kann die Link-lokalen IPv6-Adressen als Testadressen verwenden.

Informationen zum Erstellen einer IPv6-Testadresse finden Sie unter So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen.

Verwenden der Testadressen durch Anwendungen verhindern

Nachdem Sie eine Testadresse konfiguriert haben, müssen Sie sicherstellen, dass diese Adresse nicht von Anwendungen verwendet wird. Andernfalls ist die Anwendung bei einem Ausfall der Schnittstelle nicht länger erreichbar, da die Testadressen während eines Failover ignoriert werden. Um sicherzustellen, dass das IP die Testadresse nicht für normale Anwendungen auswählt, markieren Sie die Testadresse als deprecated (eingestellt).

IPv4 verwendet keine eingestellte Adresse als Quelladresse einer Kommunikation, es sei denn, eine Anwendung ist explizit an die Adresse gebunden. Der in.mpathd-Daemon ist explizit an eine solche Adresse gebunden, um Stichprobenverkehr senden und empfangen zu können.

Da Link-lokale IPv6-Adressen in einem Namen-Service normalerweise nicht vorhanden sind, verwenden DNS- und NIS-Anwendungen keine Link-lokale Adressen zur Kommunikation. Entsprechend dürfen Sie Link-lokale IPv6-Adressen nicht als deprecated kennzeichnen.

IPv4-Testadressen dürfen nicht in die DNS-Namen-Servicetabellen eingefügt werden. Unter IPv6 werden Link-lokale Adressen im Allgemeinen nicht in die Namen-Servicetabellen eingefügt.

IPMP-Schnittstellenkonfigurationen

Eine IPMP-Konfiguration setzt sich in Allgemeinen aus mindestens zwei physikalischen Schnittstellen im gleichen System zusammen, die an den gleichen IP-Link angeschlossen sind. Diese physikalischen Schnittstellen können, müssen sich aber nicht auf der gleichen NIC befinden. Die Schnittstellen sind als Mitglieder der gleichen IPMP-Gruppe konfiguriert. Wenn das System über zusätzliche Schnittstellen auf einem zweiten IP-Link verfügt, müssen Sie diese Schnittstellen als eine weitere IPMP-Gruppe konfigurieren.

Eine einzelne Schnittstelle kann in ihrer eigenen IPMP-Gruppe konfiguriert werden. Eine IPMP-Gruppe mit nur einer Schnittstelle weist das gleiche Verhalten wie eine IPMP-Gruppe mit mehreren Schnittstellen auf. Failover und Failback können jedoch nur für eine IPMP-Gruppe mit mehreren Schnittstellen stattfinden.

Sie können VLANs auch mit dem gleichen Verfahren in eine IPMP-Gruppe konfigurieren, mit dem Sie auch eine Gruppe aus IP-Schnittstellen bilden. Die Vorgehensweisen finden Sie unter Konfiguration von IPMP-Gruppen. Die unter Allgemeine Anforderungen von IPMP aufgeführten Vorausssetzungen gelten auch für die Konfiguration von VLANs in eine IPMP-Gruppe.

Achtung – Achtung –

Die zur Benennung von VLANs geltende Konvention kann zu Fehlern führen, wenn Sie VLANs als IPMP-Gruppe konfigurieren. Weitere Details zu VLAN-Namen finden Sie unter VLAN-Tags und physikalischer Anschlusspunkt im System Administration Guide: IP Services. Betrachten wir ein Beispiel mit vier VLANs: bge1000, bge1001, bge2000 und bge2001. Für eine IPMP-Implementierung müssen diese VLANs wie folgt gruppiert werden: bge1000 und bge1001 gehören zu einer Gruppe und zu VLAN 1, wohingegen bge2000 und bge2001 zu einer anderen Gruppe in VLAN 2 gehören. Aufgrund der VLAN-Namen kann es leicht zu Verwechslungen zwischen VLANs kommen, die unterschiedlichen Links in einer IPMP-Gruppe angehören, beispielsweise bge1000 und bge2000.

Standby-Schnittstellen in einer IPMP-Gruppe

Die Standby-Schnittstelle in einer IPMP-Gruppe wird nicht für Datenverkehr verwendet, es sei denn, eine andere Schnittstelle in der Gruppe fällt aus. In diesem Fall migrieren die Datenadressen der ausgefallenen Schnittstelle zur Standby-Schnittstelle. Dann wird die Standby-Schnittstelle wie andere aktive Schnittstellen behandelt, bis die ausgefallene Schnittstelle repariert wurde. Manchmal wird bei einem Failover nicht die Standby-Schnittstelle sondern eine andere aktive Schnittstelle ausgewählt, für die weniger aktive Datenadressen als für die Standby-Schnittstelle konfiguriert sind.

Für eine Standby-Schnittstelle sollten nur Testadressen konfiguriert werden. IPMP gestattet es nicht, eine Datenadresse zu einer Schnittstelle hinzuzufügen, die mithilfe des Befehls ifconfig als Standby-Schnittstelle konfiguriert wurde. Jeder Versuch, diesen Konfigurationstyp zu erstellen, schlägt fehl. Entsprechend gilt, wenn Sie eine Schnittstelle, die bereits über Datenadressen verfügt, als eine Standby-Schnittstelle konfigurieren, führen diese Adressen automatisch einen Failover auf eine andere Schnittstelle in der IPMP-Gruppe durch. Aufgrund dieser Einschränkungen müssen Sie den ifconfig-Befehl verwenden, um Testadressen als deprecated und -failover zu kennzeichnen, bevor die Schnittstelle als Standby eingerichtet wird. Informationen zur Konfiguration von Standby-Schnittstellen finden Sie unter So konfigurieren Sie eine Standby-Schnittstelle für eine IPMP-Gruppe.

Allgemeine IPMP-Schnittstellenkonfigurationen

Wie bereits unter IPMP-Adressierung beschrieben, wickeln Schnittstellen in einer IPMP-Gruppe, abhängig von der Schnittstellenkonfiguration, normalen Datenverkehr und Stichprobenverkehr ab. Mit dem IPMP-Optionen des Befehls ifconfig können Sie eine entsprechende Konfiguration erstellen.

Eine aktive Schnittstelle ist eine physikalische Schnittstelle, die sowohl Datenverkehr als auch Stichprobenverkehr übermittelt. Die Konfiguration einer Schnittstelle als „aktive Schnittstelle“ erfolgt mithilfe der Aufgabe So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen oder der Aufgabe So konfigurieren Sie eine IPMP-Gruppe mit nur einer Schnittstelle.

im Folgenden sind zwei allgemeine IPMP-Konfigurationsarten beschrieben:

Aktiv-aktive Konfiguration

Eine IPMP-Gruppe mit zwei Schnittstellen, die beide „aktiv” sind, d. h. sie übertragen zu jeder Zeit sowohl Stichprobendaten als auch den regulären Datenverkehr.

Aktiv-Standby-Konfiguration

Eine IPMP-Gruppe mit zwei Schnittstellen, von denen eine als „Standby“ konfiguriert ist.”

Überprüfen des Status einer Schnittstelle

Mit dem Befehl ifconfig Schnittstelle können Sie den Status einer Schnittstelle überprüfen. Allgemeine Informationen zum Statusbericht des Befehls ifconfig finden Sie unter So zeigen Sie Informationen zu einer bestimmten Schnittstelle an.

Beispielsweise können Sie den Status einer Standby-Schnittstelle mit dem Befehl ifconfig abrufen. Wenn die Standby-Schnittstelle keine Datenadresse hostet, hat sie Flag INACTIVE für ihren Status gesetzt. Sie finden dieses Flag in den Statuszeilen der Schnittstelle in der Ausgabe des Befehls ifconfig.

IPMP-Funktionen zur Ausfall- und Reparaturerkennung

Der in.mpathd-Daemon kann die folgenden Arten einer Ausfallerkennung verarbeiten:

In der Manpage in.mpathd(1M) wird ausführlich beschrieben, wie der in.mpathd-Daemon die Erkennung von ausgefallenen Schnittstellen verarbeitet.

Stichproben-basierte Ausfallerkennung

Die Stichproben-basierte Ausfallerkennung ist immer aktiviert, vorausgesetzt, die Schnittstelle unterstützt diese Art der Ausfallerkennung. In der aktuellen Version von Oracle Solaris werden die folgenden Sun-Netzwerktreiber unterstützt:

Informationen, ob eine Schnittstelle eines Drittanbieters die Stichproben-basierte Ausfallerkennung unterstützt, entnehmen Sie bitte der Dokumentation des jeweiligen Herstellers.

Diese Netzwerk-Schnittstellentreiber überwachen den Verbindungsstatus einer Schnittstelle und benachrichtigen das Netzwerk-Untersystem, wenn sich der Verbindungsstatus ändert. Wenn das Netzwerk-Untersystem über eine Änderung informiert wird, setzt oder löscht es das Flag RUNNING für diese Schnittstelle. Erkennt der Daemon, dass das Flag RUNNING einer Schnittstelle gelöscht wurde, lässt er die Schnittstelle unverzüglich ausfallen.

Stichproben-basierte Ausfallerkennung

Der in.mpathd-Daemon führt für jede Schnittstelle in der IPMP-Gruppe, die über eine Testadresse verfügt, eine Stichproben-basierte Ausfallerkennung durch. Eine Stichproben-basierte Ausfallerkennung umfasst das Senden und Empfangen von ICMP-Stichprobennachrichten an bzw. von den Testadressen. Diese Nachrichten werden über die Schnittstelle an eines oder mehrere Zielsysteme auf dem gleichen IP-Link gesendet. Eine Einführung in das Konzept der Testadressen finden Sie unter Testadressen. Informationen zur Konfiguration von Testadressen finden Sie unter So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen.

Der in.mpathd-Daemon legt fest, an welche Zielsysteme dynamisch Stichproben gesendet werden. Router, die mit dem IP-Link verbunden sind, werden automatisch als Ziele für Stichproben ausgewählt. Falls keine Router auf dem Link vorhanden sind, sendet in.mpathd die Stichproben an die Nachbar-Hosts auf dem Link. Ein Multicast-Paket, das die Multicast-Adresse aller Hosts (224.0.0.1 bei IPv4 und ff02::1 bei IPv6) gesendet wird, legt fest, welche Hosts als Zielsysteme verwendet werden. Die ersten Hosts, die auf die Echo-Pakete antworten, werden als Ziele für die Stichproben ausgewählt. Wenn in.mpathd keine Router findet oder keine Hosts auf die ICMP-Echo-Pakete antworten, kann der in.mpathd-Daemon keine Ausfälle anhand von Stichproben erkennen.

Sie können Host-Routen verwenden, um explizit eine Liste mit Zielsystemen zu konfigurieren, die von in.mpathd verwendet werden sollen. Anweisungen hierzu finden Sie unter Konfiguration von Zielsystemen.

Um sicherzustellen, dass jede Schnittstelle in der IPMP-Gruppe ordnungsgemäß funktioniert, testet der in.mpathd-Daemon alle Ziele separat über alle Schnittstellen in der IPMP-Gruppe. Falls auf fünf aufeinander folgende Stichproben keine Antworten eingehen, betrachtet in.mpathd die Schnittstelle als ausgefallen. Die Stichprobenrate hängt von der Failure Detection Time (FDT) ab. Der Standardwert der Failure Detection Time beträgt 10 Sekunden. Sie können die Failure Detection Time jedoch in der Datei /etc/default/mpathd ändern. Anweisungen finden Sie in So konfigurieren Sie die /etc/default/mpathd-Datei.

Bei einer Reparatur-Erkennungszeit von 10 Sekunden beträgt die Stichprobenrate etwa eine Stichprobe alle 2 Sekunden. Die Reparatur-Erkennungszeit beträgt das Doppelte der Failure Detection Time (standardmäßig 20 Sekunden), da Antworten auf 10 aufeinander folgende Stichproben empfangen werden müssen. Die Ausfall- und Reparatur-Erkennungszeiten gelten nur für die Stichproben-basierte Ausfallerkennung.

Hinweis –

In einer aus VLANs bestehenden IPMP-Gruppe wird die Link-basierte Fehlererkennung über physische Links implementiert und wirkt sich deswegen auf alle VLANs dieses Links aus. Die stichprobenbasierte Fehlererkennung wird pro VLAN-Link durchgeführt. So sind bge0/bge1 und bge1000/bge1001 beispielsweise zusammen in einer Gruppe konfiguriert. Wenn das Kabel für bge0 herausgezogen wird, meldet die Link-basierte Fehlererkennung sowohl bge0 als auch bge1000 sofort als ausgefallen. Wenn jedoch alle Stichprobenziele auf bge0 nicht erreichbar sind, wird nur bge0 als ausgefallen gemeldet, da bge1000 seine eigenen Stichprobenziele in seinem eigenen VLAN besitzt.

Ausfall einer Gruppe

Ein Ausfall einer Gruppe tritt auf, wenn alle Schnittstellen in einer IPMP-Gruppe scheinbar gleichzeitig ausfallen. Bei einem Ausfall einer Gruppe kann der in.mpathd-Daemon keinen Failover durchführen. Darüber hinaus findet kein Failover statt, wenn alle Zielsysteme gleichzeitig ausfallen. In diesem Fall löscht in.mpathd alle aktuellen Zielsysteme und beginnt mit der Erkennung neuer Zielsysteme.

Erkennen der Reparatur physikalischer Schnittstellen

Damit der in.mpathd-Daemon eine Schnittstelle als repariert ansehen kann, muss das Flag RUNNING für die Schnittstelle gesetzt sein. Wenn die Stichproben-basierte Ausfallerkennung verwendet wird, muss der in.mpathd-Daemon Antworten auf 10 aufeinander folgende Stichprobenpakete von der Schnittstelle empfangen. Erst dann wird die Schnittstelle als repariert angesehen. Anschließend wandern alle Adressen, für die ein Failover auf eine andere Schnittstelle stattgefunden hat, zur reparierten Schnittstelle zurück (Failback). Wurde eine Schnittstelle vor dem Ausfall als „aktiv“ konfiguriert, kann die Schnittstelle nach der Reparatur das Senden und Empfangen von Verkehr wieder aufnehmen.

Vorgänge während eines Schnittstellen-Failover

In den folgenden zwei Beispielen wird eine typische Konfiguration gezeigt und wie sich diese Konfiguration automatisch ändert, wenn eine Schnittstelle ausfällt. Wenn die Schnittstelle hme0 ausfällt, achten Sie darauf, wie alle Datenadressen von hme0 zu hme1 geändert werden.

Beispiel 30–1 Schnittstellenkonfiguration vor dem Ausfall einer Schnittstelle


hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> 
     mtu 1500 index 2
     inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme0:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.21 netmask ffffff00 broadcast 192.168.85.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
8     inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.22 netmask ffffff00 broadcast 192.168.85.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:19fa/10
     groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:1bfc/10
     groupname test
Beispiel 30–2 Schnittstellenkonfiguration nach dem Ausfall einer Schnittstelle


hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4,
      NOFAILOVER,FAILED> mtu 0 index 2
      inet 0.0.0.0 netmask 0 
      groupname test
hme0:1: flags=19040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER,FAILED> mtu 1500 index 2 
      inet 192.168.85.21 netmask ffffff00 broadcast 10.0.0.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
      groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER> mtu 1500 
      index 2 inet 192.168.85.22 netmask ffffff00 broadcast 10.0.0.255
hme1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
      inet 192.168.85.19 netmask ffffff00 broadcast 192.168.18.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER,FAILED> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:19fa/10 
      groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:1bfc/10 
      groupname test

Sie sehen, dass das Flag FAILED für die Schnittstelle hme0 gesetzt ist, um zu kennzeichnen, dass diese Schnittstelle ausgefallen ist. Sie sehen auch, dass hme1:2 erstellt wurde. hme1:2 war ursprünglich hme0. Die Adresse 192.168.85.19 wurde daraufhin über hme1 zugänglich.

Multicast-Mitgliedschaften, die 192.168.85.19 zugeordnet sind, können noch immer Pakete empfangen, jetzt jedoch über hme1. Nachdem der Failover der Adresse 192.168.85.19 von hme0 auf hme1 stattgefunden hat, wurde eine Dummy-Adresse 0.0.0.0 auf hme0 erstellt. Die Dummy-Adresse wurde so erstellt, dass weiterhin auf hme0 zugegriffen werden kann. hme0:1 kann nicht ohne hme0 existieren. Die Dummy-Adresse wurde wieder entfernt, nachdem letztlich ein Failback stattgefunden hat.

Entsprechend fand ein Failover der IPv6-Adresse von hme0 zu hme1 statt. Bei IPv6 sind Multicast-Mitgliedschaften den Schnittstellenindexen zugeordnet. Auch für Multicast-Mitgliedschaften findet ein Failover von hme0 zu hme1 statt. Alle von in.ndpd konfigurierten Adressen werden ebenfalls verschoben. Diese Aktion wird in den Beispielen jedoch nicht gezeigt.

Der in.mpathd-Daemon sendet weiterhin Stichproben über die ausgefallene Schnittstelle hme0. Nachdem der Daemon 10 aufeinander folgende Antworten über die Standard-Reparaturerkennungszeit von 20 Sekunden empfangen hat, betrachtet der Daemon die Schnittstelle als repariert. Da auch das Flag RUNNING für die Schnittstelle hme0 gesetzt ist, ruft der Daemon den Failback-Prozess auf. Nach dem Failback wird die ursprüngliche Konfiguration wieder hergestellt.

Eine Beschreibung aller Fehlermeldungen, die während des Ausfalls und den Reparaturen auf der Konsole protokolliert wurden, finden Sie in der Manpage in.mpathd(1M).

IPMP und Dynamische Rekonfiguration

Mit der dynamischen Rekonfiguration (DR) können Sie bei laufendem System Systemhardware wie z. B. Schnittstellen neu konfigurieren. In diesem Abschnitt wird beschrieben, wie DR mit IPMP zusammenarbeitet.

Bei einem System, das die DR von NICs unterstützt, kann IPMP dazu beitragen, die Konnektivität aufrecht zu erhalten und eine Unterbrechung von bestehenden Verbindungen zu verhindern. Auf einem System, das DR unterstützt und IPMP verwendet, können Sie NICs problemlos anschließen, trennen oder erneut anschließen, denn IPMP ist in das Reconfiguration Coordination Manager (RCM)-Framework integriert. RCM verwaltet die dynamische Rekonfiguration von Systemkomponenten.

Normalerweise verwenden Sie den Befehl cfgadm zum Ausführen von DR-Vorgängen. Einige Plattformen unterstützen jedoch auch andere Methoden. Einzelheiten finden Sie in der Dokumentation Ihrer Plattform. Dokumentationen zur DR finden Sie in den folgenden Ressourcen.

Tabelle 30–1 Dokumentationen zur dynamischen Rekonfiguration

Beschreibung 

Weitere Informationen 

Ausführliche Informationen zum Befehl cfgadm

Manpage cfgadm(1M)

Spezifische Informationen zur DR in der Sun Cluster-Umgebung 

Sun Cluster 3.1 System Administration Guide

Spezifische Informationen zur DR in der Sun Fire-Umgebung 

Sun Fire 880 Dynamic Reconfiguration Guide

Einführung in die DR und den Befehl cfgadm

Kapitel 6, Dynamically Configuring Devices (Tasks) in System Administration Guide: Devices and File Systems

Aufgaben zur Verwaltung von IPMP-Gruppen auf einem System, das DR unterstützt 

Ersetzen einer ausgefallenen physikalischen Schnittstelle auf Systemen, die DR unterstützen

Anschließen von NICs

Mit dem Befehl ifconfig können Sie einer IPMP-Gruppe jederzeit Schnittstellen hinzufügen. Dies wird ausführlich unter So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen beschrieben. Somit können alle Schnittstellen auf Systemkomponenten, die nach dem Systemstart angeschlossen wurde, geplumbt und zu einer bestehenden IPMP-Gruppe hinzugefügt werden. Gegebenenfalls können Sie neu hinzugefügte Schnittstellen auch in einer eigenen IPMP-Gruppe konfigurieren.

Diese Schnittstellen und die darauf konfigurierten Datenadresse stehen unmittelbar für die Verwendung durch die IPMP-Gruppe zur Verfügung. Sie müssen jedoch eine /etc/hostname.Schnittstelle-Datei für jede neue Schnittstelle erstellen, damit das System diese Schnittstellen nach einem Neustart automatisch konfiguriert und verwendet. Anweisungen hierzu finden Sie unter So konfigurieren Sie eine physikalische Schnittstelle nach der Systeminstallation.

Falls diese /etc/hostname.Schnittstelle-Datei schon beim Anschließen der Schnittstelle vorhanden ist, konfiguriert RCM die Schnittstelle automatisch gemäß dem Inhalt dieser Datei. Somit erhält die Schnittstelle die gleiche Konfiguration, die sie nach einem Systemstart erhalten würde.

Trennen von NICs

Alle Anforderungen zum Trennen von Systemkomponenten mit NICs werden zunächst daraufhin geprüft, ob die Konnektivität aufrechterhalten werden kann. Beispielsweise können Sie standardmäßig keine NIC trennen, die sich nicht in einer IPMP-Gruppe befindet. Außerdem können Sie keine NIC trennen, die die einzigen ordnungsgemäß arbeitenden Schnittstellen in einer IPMP-Gruppe enthält. Wenn Sie die Systemkomponente entfernen müssen, können Sie dieses Verhalten jedoch mit der Option -f des Befehls cfgadm außer Kraft setzen. Lesen Sie dazu die Manpage cfgadm(1M).

Wenn die Prüfungen erfolgreich abgeschlossen wurden, führen die Datenadressen, die der zu trennenden NIC zugeordnet sind, einen Failover zu einer ordnungsgemäß arbeitenden NIC in der gleichen Gruppe aus, als ob die zu trennende NIC ausgefallen wäre. Nachdem die NIC getrennt wurde, sind alle Testadressen der Schnittstellen auf der NIC in einem dekonfigurierten Zustand. Erst dann kann das Plumbing der NIC rückgängig gemacht werden. Wenn einer dieser Schritte fehlschlägt, oder wenn die DR einer anderen Hardware auf der gleichen Systemkomponente ausfällt, wird die vorherige Konfiguration im ursprünglichen Zustand wiederhergestellt. In diesem Fall erhalten Sie jedoch eine Statusnachricht. Andernfalls wird die Aufforderung zum Trennen erfolgreich abgeschlossen. Sie können die Komponente vom System entfernen. Bestehende Verbindungen werden nicht unterbrochen.

Wiederanschließen von NICs

RCM zeichnet die Konfigurationsinformationen von NICs auf, die von einem laufenden System getrennt wurden. Daher behandelt RCM das Wiederanschließen einer NIC, die zuvor getrennt wurde, genauso, als ob eine neue NIC angeschlossen wird. Das heißt, RCM führt lediglich das Plumbing der Schnittstelle durch.

Für wieder angeschlossene NICs existiert·jedoch in der Regel eine /etc/hostname. Schnittstelle-Datei. In diesem Fall konfiguriert RCM die Schnittstelle automatisch gemäß dem Inhalt der vorhandenen /etc/hostname. Schnittstelle-Datei. Zusätzlich informiert RCM den in.mpathd-Daemon über jede Datenadresse, die ursprünglich auf der wieder angeschlossenen Schnittstelle gehostet wurde. Das heißt, nachdem die wieder angeschlossene Schnittstelle ordnungsgemäß funktioniert, führen alle Datenadressen ein Failback auf die wieder angeschlossene Schnittstelle aus, als wäre sie repariert worden.

Verfügt die wieder angeschlossene NIC nicht über eine /etc/hostname.Schnittstelle-Datei, stehen keine Konfigurationsinformationen zur Verfügung. In diesem Fall hat RCM keine Informationen, wie die Schnittstelle konfiguriert werden soll. Adressen, die zuvor ein Failover zu einer anderen Schnittstelle durchgeführt haben, führen kein Failback durch.

Bei einem Systemstart fehlende NICs

NICs, die bei einem Systemstart nicht vorhanden sind, stellen einen Sonderfall bei der Ausfallerkennung dar. Beim Booten verfolgen die Startskripten alle Schnittstellen mit /etc/hostname.Schnittstelle-Dateien, für die kein Plumbing stattgefunden hat. Alle Datenadressen in der /etc/hostname. Schnittstelle-Datei einer solchen Schnittstelle werden automatisch unter einer alternativen Schnittstelle in der IPMP-Gruppe gehostet.

In diesem Fall erhalten Sie Fehlermeldungen ähnlich der Folgenden:


moving addresses from failed IPv4 interfaces: hme0 (moved to hme1)
moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)

Falls keine alternative Schnittstelle vorhanden ist, erhalten Sie eine Fehlermeldung ähnlich der Folgenden:


moving addresses from failed IPv4 interfaces: hme0 (couldn't move; 
   no alternative interface) 
 moving addresses from failed IPv6 interfaces: hme0 (couldn't move; 
   no alternative interface)
Hinweis –

Bei dieser Ausfallerkennung wandern nur die Datenadressen, die explizit in der /etc/hostname.Schnittstelle-Datei aufgelistet sind, zu einer alternativen Schnittstelle. Alle Adressen, die normalerweise über andere Mittel, z. B. RARP oder DHCP erworben wurden, werden nicht übernommen oder verschoben.

Wenn eine Schnittstelle mit den gleichen Namen wie eine beim Booten des Systems fehlende Schnittstellt mit DR wieder angeschlossen wird, führt RCM das Plumbing der Schnittstelle durch. Dann konfiguriert RCM die Schnittstelle gemäß dem Inhalt der zugehörigen /etc/hostname.Schnittstelle-Datei. Schließlich führt RCM ein Failback aller Datenadressen durch, als ob die Schnittstelle repariert wurde. Somit ist die endgültige Netzwerkkonfiguration identisch mit der Konfiguration, die übernommen worden wäre, wenn das System mit vorhandener Schnittstelle gebootet wäre.