test

Systemverwaltungshandbuch: IP Services

Teil VI IPMP

Dieser Teil enthält eine Einführung in das IP Network Multipathing (IPMP) und beschreibt Aufgaben zur Verwaltung von IPMP. IPMP bietet eine Ausfallerkennung und Failover für Schnittstellen auf einem System, die an den gleichen Link angeschlossen sind.

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.

Kapitel 31 Verwaltung von IPMP (Aufgaben)

In diesem Kapitel sind die Aufgaben zur Verwaltung von Schnittstellengruppen mit IP Network Multipathing (IPMP) beschrieben. Folgende Themen werden behandelt:

Eine Einführung in das IPMP-Konzept finden Sie in Kapitel 30Einführung in IPMP (Übersicht).

Konfiguration von IPMP (Übersicht der Schritte)

Dieser Abschnitt enthält Links zu den in diesem Kapitel beschriebenen Aufgaben.

Konfiguration und Verwaltung von IPMP-Gruppen (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Planung für eine IPMP-Gruppe. 

Erstellen Sie eine Liste aller Zusatzinformationen und erforderlichen Aufgaben, bevor Sie mit der Konfiguration einer IPMP-Gruppe beginnen. 

So planen Sie für eine IPMP-Gruppe

Konfiguration einer IPMP-Schnittstellengruppe mit mehreren Schnittstellen. 

Konfigurieren Sie mehrere Schnittstellen als Mitglieder einer IPMP-Gruppe. 

So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen

Konfiguration einer IPMP-Gruppe, in der eine Schnittstelle als Standby-Schnittstelle fungiert. 

Konfigurieren Sie eine der Schnittstellen in einer IPMP-Gruppe mit mehreren Schnittstellen als eine Standby-Schnittstelle. 

So konfigurieren Sie eine Standby-Schnittstelle für eine IPMP-Gruppe

Konfiguration einer IPMP-Gruppe, die aus nur einer Schnittstelle besteht. 

Erstellen Sie eine IPMP-Gruppe mit nur einer Schnittstelle.  

So konfigurieren Sie eine IPMP-Gruppe mit nur einer Schnittstelle

Anzeigen der IPMP-Gruppe, zu der eine physikalische Schnittstelle gehört. 

Beziehen Sie den Namen der IPMP-Gruppe einer Schnittstelle aus der Ausgabe des Befehls ifconfig.

So zeigen Sie die IPMP-Gruppenmitgliedschaft einer Schnittstelle an

Hinzufügen einer Schnittstelle zu einer IPMP-Gruppe. 

Konfigurieren Sie eine neue Schnittstelle als ein Mitglied einer bestehenden IPMP-Gruppe. 

So fügen Sie eine Schnittstelle zu einer IPMP-Gruppe hinzu

Entfernen einer Schnittstelle aus einer IPMP-Gruppe. 

Entfernen Sie eine Schnittstelle aus einer IPMP-Gruppe. 

So entfernen Sie eine Schnittstelle aus einer IPMP-Gruppe

Verschieben einer Schnittstelle aus einer vorhandenen IPMP-Gruppe in eine andere Gruppe. 

Verschieben Sie Schnittstellen zwischen IPMP-Gruppen. 

So verschieben Sie eine Schnittstelle von einer IPMP-Gruppe in eine andere

Ändern von drei Standardeinstellungen für den in.mpathd-Daemon.

Ändern Sie die Failure Detection Time sowie andere Parameter des in.mpathd-Daemons.

So konfigurieren Sie die /etc/default/mpathd-Datei

Verwalten von IPMP auf Schnittstellen, die DR unterstützen (Übersicht der Schritte)

Aufgabe 

Beschreibung 

Siehe 

Entfernen einer ausgefallenen Schnittstelle. 

Entfernen Sie eine ausgefallene Schnittstelle von einem System. 

So entfernen Sie eine ausgefallene physikalische Schnittstelle (DR-Detach)

Ersetzen einer ausgefallenen Schnittstelle. 

Ersetzen Sie eine ausgefallene Schnittstelle. 

So ersetzen Sie eine ausgefallene physikalische Schnittstelle (DR-Attach)

Wiederherstellen einer Schnittstelle, die beim Booten nicht konfiguriert wurde. 

Stellen Sie eine ausgefallene Schnittstelle wieder her. 

So stellen Sie eine physikalische Schnittstelle wieder her, die beim Systemstart nicht vorhanden war

Konfiguration von IPMP-Gruppen

In diesem Abschnitt finden Sie Verfahren zur Konfiguration von IPMP-Gruppen. Darüber hinaus wird hier beschrieben, wie eine Schnittstelle als Standby-Schnittstelle konfiguriert wird.

Planung für eine IPMP-Gruppe

Bevor Sie die Schnittstellen eines Systems als Teil einer IPMP-Gruppe konfigurieren können, müssen Sie einige Planungsaufgaben durchführen.

ProcedureSo planen Sie für eine IPMP-Gruppe

Im folgenden Verfahren werden Aufgaben zur Planung und Informationen beschrieben, die vor der Konfiguration einer IPMP-Gruppe zusammengetragen werden müssen. Die Aufgaben müssen nicht in der angegebenen Reihenfolge ausgeführt werden.

  1. Entscheiden Sie, welche Schnittstellen auf dem System Teil der IPMP-Gruppe werden sollen.

    Eine IPMP-Gruppe besteht in der Regel aus mindestens zwei physikalischen Schnittstellen, die an den gleichen IP-Link angeschlossen sind. Falls erforderlich, können Sie auch eine IPMP-Gruppe mit nur einer Schnittstelle konfigurieren. Eine Einführung in IPMP-Gruppen finden Sie unter IPMP-Schnittstellenkonfigurationen. Beispielsweise können Sie den gleichen Ethernet-Switch oder das gleiche IP-Teilnetz unter der gleichen IPMP-Gruppe konfigurieren. Sie können beliebig viele Schnittstellen in der gleichen IPMP-Gruppe konfigurieren.

    Der Parameter group des Befehls ifconfig kann nicht mit logischen Schnittstellen verwendet werden. Entsprechend können Sie den Parameter group mit hme0, aber nicht mit hme0:1 verwenden.

  2. Prüfen Sie, ob jede Schnittstelle in der Gruppe über eine einmalige MAC-Adresse verfügt.

    Anweisungen hierzu finden Sie unter SPARC: So stellen Sie sicher, dass die MAC-Adresse einer Schnittstelle einmalig ist.

  3. Wählen Sie einen Namen für die IPMP-Gruppe.

    Es kann jeder Name außer Null kann für die Gruppe verwendet werden. Sie sollten einen Namen verwenden, der den IP-Link beschreibt, an den die Schnittstellen angeschlossen sind.

  4. Achten Sie darauf, dass der gleiche Satz STREAMS-Module auf alle Schnittstellen in der IPMP-Gruppe gepusht und konfiguriert wird.

    Auf allen Schnittstellen in einer Gruppe müssen die gleichen STREAMS-Module in der gleichen Reihenfolge konfiguriert werden.

    1. Überprüfen Sie an allen Schnittstellen in der künftigen IPMP-Gruppe die Reihenfolge der STREAMS-Module.

      Mit dem Befehl ifconfig Schnittstelle modlist drucken Sie eine Liste der STREAMS-Module. Das Folgende ist die Ausgabe des Befehls ifconfig für die Schnittstelle hme0:


      # ifconfig hme0 modlist
	0 arp
	1 ip
	2 hme

      Schnittstellen existieren normalerweise als Netzwerktreiber direkt unterhalb des IP-Moduls. Diese wird in der Ausgabe von ifconfig hme0 modlist gezeigt. Sie sollten keine zusätzliche Konfiguration erfordern.

      Einige Technologien, z. B. NCA oder IP Filter, fügen sich jedoch selbst als STREAMS-Module zwischen dem IP-Modul und dem Netzwerktreiber ein. Dabei können Probleme durch das Verhalten der Schnittstellen in der gleichen IPMP-Gruppe entstehen.

      Ist ein STREAMS-Modul statusbehaftet, kann bei einem Failover ein unerwartetes Verhalten auftreten. Dies erfolgt unabhängig davon, ob Sie das gleiche Modul auf alle Schnittstellen in einer Gruppe pushen. Sie können jedoch statusfreie STREAMS-Module verwenden, vorausgesetzt, Sie pushen auf allen Schnittstellen in der IPMP-Gruppe in der gleichen Reihenfolge.

    2. Pushen Sie die Module einer Schnittstelle in der Standardreihenfolge für die IPMP-Gruppe.


      ifconfig interface modinsert module-name


      ifconfig hme0 modinsert ip

  5. Verwenden Sie für alle Schnittstellen der IPMP-Gruppe das gleiche IP-Adressierungsformat.

    Wenn eine dieser Schnittstellen für IPv4 konfiguriert ist, müssen alle Schnittstellen der Gruppe für IPv4 konfiguriert sein. Angenommen, es besteht eine IPMP-Gruppe, die aus Schnittstellen von mehreren NICs zusammengesetzt ist. Wenn Sie zu den Schnittstellen einer Netzwerkkarte IPv6-Adressierung hinzufügen, müssen alle Schnittstelle in der IPMP-Gruppe so konfiguriert werden, dass sie IPv6 unterstützen.

  6. Überprüfen Sie, ob alle Schnittstellen in der IPMP-Gruppe an den gleichen IP-Link angeschlossen sind.

  7. Stellen Sie sicher, dass die IPMP-Gruppe keine Schnittstellen unterschiedlicher Netzwerkmedientypen enthält.

    Die gruppierten Schnittstellen müssen den gleichen Schnittstellentyp gemäß Definition in /usr/include/net/if_types.h aufweisen. Beispielsweise können Sie Ethernet- und Token Ring-Schnittstellen nicht in einer IPMP-Gruppe kombinieren. Ein anderes Beispiel: Sie können eine Token Bus-Schnittstelle nicht mit Asynchronous Transfer Mode (ATM)-Schnittstellen in der gleichen IPMP-Gruppe kombinieren.

  8. Bei IPMP mit ATM-Schnittstellen konfigurieren Sie die ATM-Schnittstellen im LAN-Emulationsmodus.

    IPMP wird für Schnittstellen, die klassisches IP über ATM verwenden, nicht unterstützt.

Konfiguration von IPMP-Gruppen

Dieser Abschnitt enthält Aufgaben zur Konfiguration einer typischen IPMP-Gruppe mit mindestens zwei physikalischen Schnittstellen.

ProcedureSo konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen

Die folgenden Schritte zum Konfigurieren einer IPMP-Gruppe gelten auch beim Konfigurieren von VLANs in einer IPMP-Gruppe.

Bevor Sie beginnen

Sie müssen die IPv4-Adressen und, falls zutreffend, die IPv6-Adressen aller Schnittstellen in der geplanten IPMP-Gruppe vorab konfigurieren.

Achtung – Achtung –

Sie müssen für jedes Teilnetz oder jede L2-Broadcast-Domäne nur eine IPMP-Gruppe konfigurieren. Weitere Informationen finden Sie unter Allgemeine Anforderungen von IPMP

  1. Nehmen Sie auf dem System mit den zu konfigurierenden Schnittstellen die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Fügen Sie jede physikalische Schnittstelle einer IPMP-Gruppe hinzu.


    # ifconfig interface group group-name

    Um beispielsweise hme0 und hme1 in die Gruppe testgroup1 einzufügen, geben Sie die folgenden Befehle ein:


    # ifconfig hme0 group testgroup1
# ifconfig hme1 group testgroup1

    Vermeiden Sie Leerzeichen in Gruppennamen. Der ifconfig-Status zeigt keine Leerzeichen an. Entsprechend dürfen Sie keine zwei ähnlichen Gruppennamen erstellen, deren einziger Unterschied darin besteht, dass einer der Gruppennamen ein Leerzeichen enthält. In diesem Fall sehen diese Gruppennamen in der Statusanzeige gleich aus.

    In einer Dual-Stack-Umgebung wird durch das Hinzufügen der IPv4-Instanz einer Schnittstelle in einer bestimmten Gruppe automatisch die IPv6-Instanz der gleichen Gruppe hinzugefügt.

  3. (Optional) Konfigurieren Sie eine IPv4-Testadresse auf einer oder mehreren physikalischen Schnittstellen.

    Sie müssen nur dann eine Testadresse konfigurieren, wenn Sie die Stichproben-basierte Ausfallerkennung für eine bestimmte Schnittstelle verwenden. Testadressen werden als logische Schnittstellen der physikalischen Schnittstellen konfiguriert, die Sie für den Befehl ifconfig angegeben haben.

    Wenn eine Schnittstelle in der Gruppe als Standby-Schnittstelle konfiguriert werden soll, darf zu diesem Zeitpunkt keine Testadresse für die Schnittstelle konfiguriert werden. Die Konfiguration einer Testadresse für die Standby-Schnittstelle erfolgt im Rahmen der Aufgabe So konfigurieren Sie eine Standby-Schnittstelle für eine IPMP-Gruppe.

    Zur Konfiguration einer Testadresse verwenden Sie die folgende Syntax des Befehls ifconfig:


    # ifconfig interface addif ip-address parameters -failover deprecated up

    Angenommen, Sie erstellen die folgende Testadresse für die primäre Netzwerkschnittstelle hme0:


    # ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up

    Dieser Befehl richtet die folgenden Parameter für die primäre Netzwerkschnittstelle hme0 ein:

    • Die Adresse wird auf 192.168.85.21 gesetzt

    • Netzmasken- und Broadcast-Adresse werden auf den Standardwert gesetzt

    • -Failover- und deprecated-Optionen werden gesetzt

      Hinweis –

      Sie müssen eine IPv4-Testadresse als deprecated kennzeichnen, um zu verhindern, das diese Testadresse von Anwendungen verwendet wird.

  4. Prüfen Sie die IPv4-Konfiguration einer bestimmten Schnittstelle.

    Mit dem Befehl ifconfig Schnittstelle können Sie jederzeit den aktuellen Status einer Schnittstelle anzeigen. Weitere Informationen zum Anzeigen eines Schnittstellenstatus finden Sie unter So zeigen Sie Informationen zu einer bestimmten Schnittstelle an.

    Sie erhalten Informationen zur Testadressenkonfiguration einer physikalischen Schnittstelle, indem Sie die logische Schnittstelle angeben, die der Testadresse zugewiesen ist.


    # ifconfig hme0:1
	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

  5. (Optional) Konfigurieren Sie bei Bedarf eine IPv6-Testadresse. 


    # ifconfig interface inet6 -failover

    Physikalische Schnittstellen mit IPv6-Adressen werden in die gleichen IPMP-Gruppe wie die IPv4-Adressen der Schnittstellen eingefügt. Dies geschieht, wenn Sie die physikalische Schnittstelle mit IPv4-Adressen in einer IPMP-Gruppe konfigurieren. Wenn Sie zuerst physikalische Schnittstellen mit IPv6-Adressen in eine IPMP-Gruppe einfügen, werden die physikalischen Schnittstellen mit IPv4-Adressen ebenfalls implizit in die gleiche IPMP-Gruppe eingefügt.

    Wenn Sie z. B. hme0 mit einer IPv6-Testadresse konfigurieren, geben Sie Folgendes ein:


    # ifconfig hme0 inet6 -failover

    Sie müssen eine IPv6-Testadresse nicht als „deprecated“ kennzeichnen, um zu verhindern, dass diese Testadresse von Anwendungen verwendet wird.

  6. Prüfen Sie die IPv6-Konfiguration.


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

    Die IPv6-Testadresse ist die Link-lokale Adresse der Schnittstelle.

  7. (Optional) Behalten Sie die Konfiguration der IPMP-Gruppe nach einem Neustart bei.

    • Bei IPv4 fügen Sie die folgende Zeile zur /etc/hostname.Schnittstelle-Datei hinzu:


      interface-address <parameters> group group-name up \
	addif logical-interface -failover deprecated <parameters> up

      In diesem Fall wird die IPv4-Testadresse erst mit dem nächsten Neustart konfiguriert. Wenn die Konfiguration für die aktuelle Sitzung gelten soll, führen Sie die Schritte 1, 2 und optional 3 aus.

    • Bei IPv6 fügen Sie die folgende Zeile zur /etc/hostname6. Schnittstelle-Datei hinzu:


      -failover group group-name up

      Diese IPv6-Testadresse wird erst mit dem nächsten Neustart konfiguriert. Wenn die Konfiguration für die aktuelle Sitzung gelten soll, führen Sie die Schritte 1, 2 und optional 5 aus.

  8. (Optional) Fügen Sie weitere Schnittstellen zur IPMP-Gruppe hinzu, indem Sie die Schritte 1 bis 6 wiederholen.

    Sie können bei einem laufenden System neue Schnittstellen zu einer vorhandenen Gruppe hinzufügen. Diese Änderungen gehen jedoch nach einem Neustart verloren.

Beispiel 31–1 Konfiguration einer IPMP-Gruppe mit zwei Schnittstellen

Angenommen, Sie möchten Folgendes umsetzen:

Dazu geben Sie den folgenden Befehl ein:


# ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up

Sie müssen eine IPv4-Testadresse als deprecated kennzeichnen, um zu verhindern, das diese Testadresse von Anwendungen verwendet wird. Lesen Sie dazu So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen.

Um das Failover-Attribut der Adresse zu aktivieren, verwenden Sie die Option failover ohne das Minuszeichen.

Alle Testadressen in einer IPMP-Gruppe müssen das gleiche Netzwerkpräfix verwenden. Die IP-Testadressen müssen zum gleichen IP-Teilnetz gehören.

Beispiel 31–2 Beibehalten der Konfiguration einer IPv4-IPMP-Gruppe nach einem Neustart

Angenommen, Sie möchten eine IPMP-Gruppe namens testgroup1 mit der folgenden Konfiguration erstellen:

Sie fügen die folgende Zeile zur /etc/hostname.hme0-Datei hinzu:


192.168.85.19 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.21 deprecated -failover netmask + broadcast + up

Entsprechend fügen Sie die folgende Zeile hinzu, um die zweite Schnittstelle hme1 in der gleichen Gruppe testgroup1 einzufügen und eine Testadresse zu konfigurieren:


192.168.85.20 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.22 deprecated -failover netmask + broadcast + up
Beispiel 31–3 Beibehalten der Konfiguration einer IPv6 IPMP-Gruppe nach einem Neustart

Um eine Testgruppe für die Schnittstelle hme0 mit einer IPv6-Adresse zu konfigurieren, fügen Sie die folgende Zeile zur /etc/hostname6.hme0-Datei hinzu:


-failover group testgroup1 up

Entsprechend fügen Sie die folgende Zeile zur /etc/hostname6.hme1-Datei hinzu, um die zweite Schnittstelle hme1 in die Gruppe testgroup1 einzufügen und eigene Testadresse zu konfigurieren:


-failover group testgroup1 up
Allgemeine Fehler

Während der Konfiguration einer IPMP-Gruppe gibt in.mpathd zahlreiche Meldungen an die Systemkonsole oder in die Datei syslog aus. Diese Meldungen dienen nur zur Information und geben an, dass die IPMP-Konfiguration ordnungsgemäß funktioniert.

Siehe auch

Wenn Sie möchten, dass die IPMP-Gruppe über eine Aktiv-Standby-Konfiguration verfügt, setzen Sie mit So konfigurieren Sie eine Standby-Schnittstelle für eine IPMP-Gruppe fort.

Konfiguration von Zielsystemen

Die Stichproben-basierte Fehlerkennung beruht auf der Verwendung von Zielsystemen. Dies wird unter Stichproben-basierte Ausfallerkennung genauer beschrieben. Für einige IPMP-Gruppen sind die von in.mpathd verwendeten Standardziele ausreichend. Für andere IPMP-Gruppen möchten Sie jedoch bestimmte Ziele für die Stichproben-basierte Ausfallerkennung definieren. Sie führen die Stichproben-basierte Ausfallerkennung durch, indem Sie Host-Routen in der Routing-Tabelle als Stichproben-Ziele einrichten. Alle in der Routing-Tabelle konfigurierten Host-Routen werden vor dem Standard-Router aufgeführt. Aus diesem Grund verwendet IPMP die explizit definierten Host-Routen zur Zielauswahl. Zur direkten Angabe von Zielen verwenden Sie eine von zwei Methoden: manuelles Einrichten der Host-Routen oder Erstellen eines Shell-Skripts, das zu einem Startskript wird.

Beachten Sie die folgenden Kriterien bei der Ermittlung, welche Hosts in Ihrem Netzwerk als Ziele geeignet sind.

ProcedureSo geben Sie Zielsysteme für die Stichproben-basierte Ausfallerkennung manuell an

  1. Melden Sie sich mit Ihrem Benutzerkonto bei dem System an, für das Sie eine Stichprobe-basierte Ausfallerkennung konfigurieren möchten.

  2. Fügen Sie eine Route zu dem Host hinzu, der als Ziel für die Stichproben-basierte Ausfallerkennung verwendet werden soll.


    $ route add -host destination-IP gateway-IP -static

    Ersetzen Sie die Werte Ziel-IP und Gateway-IP durch die IPv4-Adresse des Hosts, der als Ziel verwendet wird. Wenn Sie das Zielsystem 192.168.85.137 angeben möchten, das sich im gleichen Teilnetz wie die Schnittstellen in der IPMP-Gruppe testgroup1 befindet, geben Sie Folgendes ein:


    $ route add -host 192.168.85.137 192.168.85.137 -static

  3. Fügen Sie Routen zu zusätzlichen Hosts im Netzwerk hinzu, die als Zielsysteme verwendet werden.

ProcedureSo geben Sie Zielsysteme in einem Shell-Skript an

  1. Nehmen Sie auf dem System, auf dem eine IPMP-Gruppe konfiguriert werden soll, die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Erstellen Sie ein Shell-Skript, in dem statische Routen zu den geplanten Zielen eingerichtet werden.

    Beispielsweise können Sie ein Shell-Skript namens ipmp.targets mit dem folgenden Inhalt erstellen:


    TARGETS="192.168.85.117 192.168.85.127 192.168.85.137"

case "$1" in
        'start')
            /usr/bin/echo "Adding static routes for use as IPMP targets"
		for target in $TARGETS; do
	  /usr/sbin/route add -host $target $target
		done
                  ;;
        'stop')
              /usr/bin/echo "Removing static routes for use as IPMP targets"
		 for target in $TARGETS; do
		/usr/sbin/route delete -host $target $target
		 done
                  ;;
  esac

  3. Kopieren Sie das Shell-Skript in das Verzeichnis für Startskripten. 


     # cp ipmp.targets /etc/init.d

  4. Ändern Sie die Berechtigungen für das neue Startskript. 


    # chmod 744 /etc/init.d/ipmp.targets

  5. Ändern Sie die Eigentümerschaft für das neue Startskript. 


    # chown root:sys /etc/init.d/ipmp.targets

  6. Erstellen Sie einen Link für das Startskript im Verzeichnis /etc/init.d.


    # ln /etc/init.d/ipmp.targets /etc/rc2.d/S70ipmp.targets

    Das Präfix „S70“ im Dateiname S70ipmp.targets ordnet das neue Skript korrekt mit Bezug auf die anderen Startskripten ein.

Konfiguration von Standby-Schnittstellen

Verwenden Sie das folgende Verfahren, wenn die IPMP-Gruppe über eine Aktiv-Standby-Konfiguration verfügen soll. Weitere Informationen zu diesem Konfigurationstyp finden Sie unter IPMP-Schnittstellenkonfigurationen.

ProcedureSo konfigurieren Sie eine Standby-Schnittstelle für eine IPMP-Gruppe

Bevor Sie beginnen

Informationen zur Konfiguration einer IPMP-Gruppe und zum Zuweisen von Testadressen finden Sie unter So konfigurieren Sie eine IPMP-Gruppe mit mehreren Schnittstellen.

  1. Nehmen Sie auf dem System mit den zu konfigurierenden Standby-Schnittstellen die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Konfigurieren Sie eine Schnittstelle als eine Standby-Schnittstelle, und weisen Sie eine Testadresse zu.


    # ifconfig interface plumb \
ip-address other-parameters deprecated -failover standby up

    Eine Standby-Schnittstelle kann nur eine IP-Adresse aufweisen, die Testadresse. Sie müssen die Option -failover einrichten, bevor Sie die Option standby up einrichten. Für <andere-Parameter> verwenden Sie die für Ihre Konfiguration erforderlichen Parameter. Lesen Sie dazu die Beschreibung in der Manpage ifconfig(1M).

    • Um beispielsweise eine IPv4-Testadresse zu erstellen, geben Sie den folgenden Befehl ein:


      # ifconfig hme1 plumb 192.168.85.22 netmask + broadcast + deprecated -failover standby up
      hme1

      Definiert hme1 als physikalische Schnittstelle, die als Standby-Schnittstelle konfiguriert werden soll.

      192.168.85.22

      Weist der Standby-Schnittstelle diese Testadresse zu.

      deprecated

      Gibt an, dass die Testadresse nicht für abgehende Pakete verwendet wird.

      -failover

      Gibt an, dass die Testadresse kein Failover ausführt, falls die Schnittstelle ausfällt.

      standby

      Kennzeichnet die Schnittstelle als eine Standby-Schnittstelle.

    • Zum Erstellen einer IPv6-Testadresse geben Sie den folgenden Befehl ein:


      # ifconfig hme1 plumb -failover standby up

  3. Prüfen Sie die Ergebnisse der Konfiguration als Standby-Schnittstelle.


    # ifconfig hme1
hme1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,
      STANDBY,INACTIVE mtu 1500 
         index 4 inet 192.168.85.22 netmask ffffff00 broadcast 19.16.85.255
         groupname test

    Das Flag INACTIVE kennzeichnet, dass diese Schnittstelle nicht für abgehende Pakete verwendet wird. Falls an dieser Standby-Schnittstelle ein Failover auftritt, wird das Flag INACTIVE gelöscht.

    Hinweis –

    Mit dem Befehl ifconfig Schnittstelle können Sie jederzeit den aktuellen Status einer Schnittstelle anzeigen. Weitere Informationen zum Anzeigen des Schnittstellenstatus finden Sie unter So zeigen Sie Informationen zu einer bestimmten Schnittstelle an.

  4. (Optional) Behalten Sie die IPv4-Standby-Schnittstelle nach einem Neustart bei.

    Weisen Sie die Standby-Schnittstelle der gleichen IPMP-Gruppe zu, und konfigurieren Sie eine Testadresse für die Standby-Schnittstelle.

    Um beispielsweise hme1 als Standby-Schnittstelle zu konfigurieren, fügen Sie die folgende Zeile zur /etc/hostname.hme1-Datei hinzu:


    192.168.85.22 netmask + broadcast + deprecated group test -failover standby up

  5. (Optional) Behalten Sie die IPv6-Standby-Schnittstelle nach einem Neustart bei.

    Weisen Sie die Standby-Schnittstelle der gleichen IPMP-Gruppe zu, und konfigurieren Sie eine Testadresse für die Standby-Schnittstelle.

    Um beispielsweise hme1 als Standby-Schnittstelle zu konfigurieren, fügen Sie die folgende Zeile zur /etc/hostname6.hme1-Datei hinzu:


    -failover group test standby up
Beispiel 31–4 Konfigurieren einer Standby-Schnittstelle für eine IPMP-Gruppe

Angenommen, Sie möchten eine Testadresse mit der folgenden Konfiguration erstellen:

In diesem Fall geben Sie Folgendes ein:


# ifconfig hme2 plumb 192.168.85.22 netmask + broadcast + \
deprecated -failover standby up

Die Schnittstelle wird erst dann als eine Standby-Schnittstelle übernommen, nachdem die Adresse als eine NOFAILOVER-Adresse gekennzeichnet wurde.

Sie entfernen den Standby-Status einer Schnittstelle durch Eingabe von:


# ifconfig interface -standby

Konfiguration von IPMP-Gruppen mit einer physikalischen Schnittstelle

Wenn nur eine Schnittstelle in einer IPMP-Gruppe vorhanden ist, kann kein Failover durchgeführt werden. Sie können jedoch eine Ausfallerkennung für diese Schnittstelle aktivieren, indem Sie die Schnittstelle einer IPMP-Gruppe zuweisen. Für diese Ausfallerkennung müssen Sie keine spezielle IP-Testadresse konfigurieren. Sie können eine einzelne IP-Adresse zum Senden von Daten und Erkennen eines Ausfalls verwenden.

ProcedureSo konfigurieren Sie eine IPMP-Gruppe mit nur einer Schnittstelle

  1. Nehmen Sie auf dem System mit der geplanten IPMP-Gruppe mit nur einer Schnittstelle die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Bei IPv4 erstellen Sie eine IPMP-Gruppe mit nur einer Schnittstelle.

    Verwenden Sie die folgende Syntax, um einer IPMP-Gruppe nur eine Schnittstelle zuzuweisen.


    # ifconfig interface group group-name

    Das folgende Beispiel weist die Schnittstelle hme0 der IPMP-Gruppe v4test zu:


    # ifconfig hme0 group v4test

    Nachdem dieser Schritt durchgeführt wurde, ermöglicht IPMP eine Link-basierte Ausfallerkennung für die Schnittstelle.

    Darüber hinaus können Sie den Unterbefehl -failover des Befehls ifconfig verwenden, um eine stichprobenbasierte Ausfallerkennung durchzuführen. Das folgende Beispiel ermöglicht eine stichprobenbasierte Ausfallerkennnung an hme0 durch Verwenden der IP-Adresse, die derzeit folgender Schnittstelle zugewiesen ist: hme0:


    # ifconfig hme0 -failover

    Anders als bei Gruppen mit mehreren Schnittstellen kann die gleiche IP-Adresse sowohl als Daten- als auch als Testadresse verwendet werden. Damit Anwendungen die Testadresse auch als Datenadresse verwenden können, dürfen Testadressen auf IPMP-Gruppen mit nur einer Schnittstelle nie als deprecated gekennzeichnet werden.

  3. Bei IPv6 erstellen Sie eine IPMP-Gruppe mit nur einer Schnittstelle.

    Verwenden Sie die folgende Syntax, um einer IPMP-Gruppe nur eine Schnittstelle zuzuweisen:


    # ifconfig interface inet6 group group-name

    Beispiel: Um die einzelne Schnittstelle hme0 in die IPMP-Gruppe v6test einzufügen, geben Sie Folgendes ein:


    # ifconfig hme0 inet6 group v6test

    Nachdem dieser Schritt durchgeführt wurde, ermöglicht IPMP eine Link-basierte Ausfallerkennung für die Schnittstelle.

    Darüber hinaus können Sie den Unterbefehl -failover des Befehls ifconfig verwenden, um eine stichprobenbasierte Ausfallerkennung durchzuführen. Das folgende Beispiel ermöglicht eine stichprobenbasierte Ausfallerkennnung an hme0 durch Verwenden der IP-Adresse, die derzeit folgender Schnittstelle zugewiesen ist: hme0:


    # ifconfig hme0 inet6 -failover

    Anders als bei Gruppen mit mehreren Schnittstellen kann die gleiche IP-Adresse sowohl als Daten- als auch als Testadresse verwendet werden. Damit Anwendungen die Testadresse auch als Datenadresse verwenden können, dürfen Testadressen auf IPMP-Gruppen mit nur einer Schnittstelle nie als deprecated gekennzeichnet werden.

    Bei einer Konfiguration mit einer physikalischen Schnittstelle können Sie nicht überprüfen, ob ein Ausfall des Zielsystems, an das Stichproben gesendet werden oder der Schnittstelle aufgetreten ist. Die Stichproben können nur über eine physikalische Schnittstelle an das Zielsystem gesendet werden. Wenn sich nur ein Standard-Router im Teilnetz befindet, deaktivieren Sie IPMP, falls sich nur eine einzelne physikalische Schnittstelle in der Gruppe befindet. Wenn separate IPv4- und IPv6-Standard-Router vorhanden sind oder mehrere Standard-Router existieren, müssen die Stichproben an mehrere Zielsysteme gesendet werden. In diesem Fall können Sie IPMP sicher aktivieren.

Verwalten von IPMP-Gruppen

In diesem Abschnitt finden Sie Aufgaben zur Verwaltung vorhandener IPMP-Gruppen und der Schnittstellen, die diesen Gruppen zugewiesen sind. Bei dem beschriebenen Aufgaben wird davon ausgegangen, dass bereits eine IPMP-Gruppe konfiguriert ist. Anweisungen hierzu finden Sie unter Konfiguration von IPMP-Gruppen.

ProcedureSo zeigen Sie die IPMP-Gruppenmitgliedschaft einer Schnittstelle an

  1. Melden Sie sich auf dem System mit der IPMP-Gruppenkonfiguration als Superuser an, oder nehmen Sie eine entsprechende Rolle an.

    Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Zeigen Sie Informationen zur Schnittstelle an, einschließlich der Gruppe, zu der die Schnittstelle gehört.


    # ifconfig interface

  3. Wenn anwendbar, zeigen Sie die IPv6-Informationen für die Schnittstelle an.


    # ifconfig interface inet6
Beispiel 31–5 Anzeigen der Gruppen mit physikalischen Schnittstellen

Geben Sie das Folgende ein, um den Gruppennamen für die Schnittstelle hme0 anzuzeigen:


# ifconfig hme0
	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 testgroup1

Um den Gruppennamen nur für die IPv6-Informationen anzuzeigen, geben Sie das Folgende ein:


# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:19fa/10 
        	groupname testgroup1

ProcedureSo fügen Sie eine Schnittstelle zu einer IPMP-Gruppe hinzu

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Fügen Sie der IPMP-Gruppe die Schnittstelle hinzu.


    # ifconfig interface group group-name

    Die für Schnittstelle angegebene Schnittstelle wird Mitglied der IPMP-Gruppe Gruppenname.

Beispiel 31–6 Hinzufügen einer Schnittstelle zu einer IPMP-Gruppe

Geben Sie den folgenden Befehl ein, um die Schnittstelle hme0 zur IPMP-Gruppe testgroup2 hinzuzufügen:


# ifconfig hme0 group testgroup2
  hme0: flags=9000843<UP ,BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER> mtu 1500 index 2
  inet 192.168.85.19 netmask ff000000 broadcast 10.255.255.255
  groupname testgroup2
  ether 8:0:20:c1:8b:c3

ProcedureSo entfernen Sie eine Schnittstelle aus einer IPMP-Gruppe

Durch den Befehl ifconfig mit dem Parameter group und einer Null-Zeichenfolge wird die Schnittstelle aus der aktuellen IPMP-Gruppe entfernt. Seien Sie beim Entfernen von Schnittstellen aus einer Gruppe vorsichtig. Falls eine andere Schnittstelle in der IPMP-Gruppe ausgefallen ist, könnte ein Failover stattgefunden haben. Angenommen, die Schnittstelle hme0 ist zuvor ausgefallen, so gingen alle Adressen an hme1 über, vorausgesetzt, hme1 ist Teil der gleichen Gruppe. Durch Entfernen von hme1 setzt der in.mpathd-Daemon alle Failover-Adressen auf eine andere Schnittstelle in der Gruppe zurück. Wenn keine weitere Schnittstelle in der Gruppe funktioniert, wird bestimmter Netzwerkzugriff durch das Failover nicht wiederhergestellt.

Entsprechend gilt, wenn das Plumbing einer Schnittstelle in der Gruppe aufgehoben wurde, müssen Sie die Schnittstelle zunächst aus der Gruppe entfernen. Dann stellen Sie sicher, dass alle ursprünglichen IP-Adressen für die Schnittstelle konfiguriert sind. Der in.mpathd-Daemon versucht, die ursprüngliche Konfiguration einer Schnittstelle, die aus einer Gruppe entfernt wird, wiederherzustellen. Bevor Sie das Plumbing einer Schnittstelle aufheben, müssen Sie sicherstellen, dass die Konfiguration wieder hergestellt wurde. Informationen zum Zustand von Schnittstellen vor und nach einem Failover finden Sie unter Vorgänge während eines Schnittstellen-Failover.

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Entfernen Sie die Schnittstelle aus der IPMP-Gruppe.


    # ifconfig interface group ""

    Die Anführungszeichen kennzeichnen eine Null-Zeichenfolge.

Beispiel 31–7 Entfernen einer Schnittstelle aus einer Gruppe

Geben Sie den folgenden Befehl ein, um die Schnittstelle hme0 aus der IPMP-Gruppe test zu entfernen:


# ifconfig hme0 group ""
	# ifconfig hme0
	hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
    index 2 inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
	# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
    inet6 fe80::a00:20ff:feb9:19fa/10

ProcedureSo verschieben Sie eine Schnittstelle von einer IPMP-Gruppe in eine andere

Sie können eine Schnittstelle in eine neue IPMP-Gruppe verschieben, wenn die Schnittstelle einer existierenden IPMP-Gruppe angehört. Dazu müssen Sie die Schnittstelle nicht aus der aktuellen IPMP-Gruppe entfernen. Wenn Sie die Schnittstelle in eine neue Gruppe einfügen, wird sie automatisch aus der existierenden IPMP-Gruppe entfernt.

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Verschieben Sie eine Schnittstelle in eine neue IPMP-Gruppe.


    # ifconfig interface group group-name

    Durch das Einfügen der Schnittstelle in einer neuen Gruppe wird sie automatisch aus einer vorhandenen Gruppe entfernt.

Beispiel 31–8 Verschieben einer Schnittstelle in eine andere IPMP-Gruppe

Geben Sie das Folgende ein, um die IPMP-Gruppe der Schnittstelle hme0 zu ändern: 


# ifconfig hme0 group cs-link

Mit diesem Befehl entfernen Sie die Schnittstelle hme0 aus der IPMP-Gruppe test und fügen die Schnittstelle dann der Gruppe cs-link hinzu.

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

In diesem Abschnitt finden Sie Verfahren zur Verwaltung von Systemen, die eine dynamische Rekonfiguration (DR) unterstützen.

Hinweis –

Diese Aufgaben beziehen sich nur auf IP-Schichten, die mithilfe des Befehls ifconfig konfiguriert wurden. Schichten über oder unter der IP-Schicht, z. B. ATM oder andere Services, erfordern spezielle manuelle Schritte, falls die Schichten nicht automatisiert sind. Die Schritte im folgenden Verfahren dienen zum Dekonfigurieren von Schnittstellen als Vorbereitung zum Trennen und Konfigurieren der Schnittstellen nach dem Wiederanschließen.

ProcedureSo entfernen Sie eine ausgefallene physikalische Schnittstelle (DR-Detach)

In diesem Verfahren wird gezeigt, wie Sie eine physikalische Schnittstelle von einem System entfernen, das DR unterstützt. Es wird davon ausgegangen, dass die folgenden Bedingungen bestehen:

Hinweis –

Sie können Schritt 2 überspringen, wenn die Testadresse mithilfe der Datei /etc/hostname.hme0 geplumbt wurde.

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Zeigen Sie die Testadressenkonfiguration an.


    # ifconfig hme0:1

hme0:1:
flags=9040842<BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 192.168.233.250 netmask ffffff00 broadcast 192.168.233.255

    Sie benötigen diese Informationen, um die Testadresse nach dem Ersetzen der physikalischen Schnittstelle erneut zu plumben.

  3. Entfernen Sie die physikalische Schnittstelle.

    Eine vollständige Beschreibung zum Entfernen einer physikalischen Schnittstelle finden Sie in den folgenden Quellen:

    • Manpage cfgadm(1M)

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

    • Sun Enterprise 10000 DR Configuration Guide

ProcedureSo ersetzen Sie eine ausgefallene physikalische Schnittstelle (DR-Attach)

In diesem Verfahren wird gezeigt, wie Sie eine physikalische Schnittstelle auf einem System ersetzen, das DR unterstützt.

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Ersetzen Sie die physikalische Schnittstelle.

    Anweisungen hierzu finden Sie in den folgenden Quellen:

    • Manpage cfgadm(1M)

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

    • Sun Enterprise 10000 DR Configuration Guide, or Sun Fire 880 Dynamic Reconfiguration User's Guide

Wiederherstellung einer physikalischen Schnittstelle, die beim Systemstart nicht vorhanden war

Hinweis –

Das folgende Verfahren gilt nur für IP-Schichten, die mithilfe des Befehls ifconfig konfiguriert wurden. Schichten über oder unter der IP-Schicht, z. B. ATM oder andere Services, erfordern spezielle manuelle Schritte, falls die Schichten nicht automatisiert sind. Die besonderen Schritte im folgenden Verfahren dienen zum Dekonfigurieren von Schnittstellen als Vorbereitung zum Trennen und Konfigurieren der Schnittstellen nach dem Wiederanschließen.

Die Wiederherstellung nach einer dynamischen Rekonfiguration wird automatisch für eine Schnittstelle durchgeführt, die Teil eines I/O-Boards auf einer Sun Fire™-Plattform ist. Handelt es sich bei der NIC um ein Sun Crypto Accelerator I - cPCI-Board, erfolgt die Wiederherstellung ebenfalls automatisch. Folglich sind die folgenden Schritte nicht für eine Schnittstelle erforderlich, die im Rahmen eines DR-Vorgangs wiederhergestellt werden. Weitere Informationen zu den Systemen Sun Fire x800 und Sun Fire 15000 finden Sie in der Manpage cfgadm_sbd(1M) Die physikalische Schnittstelle für ein Failback auf die Konfiguration aus, die in der /etc/hostname. Schnittstelle-Datei angegeben ist. Informationen zur Konfiguration von Schnittstellen, die ihre Konfiguration auch nach einem Neustart beibehalten, finden Sie unter Konfiguration von IPMP-Gruppen.

Hinweis –

Bei Sun Fire Legacy (Exx00)-Systemen werden DR-Detachments noch immer manuell vorgenommen. DR-Attachments sind jedoch automatisiert.

ProcedureSo stellen Sie eine physikalische Schnittstelle wieder her, die beim Systemstart nicht vorhanden war

Sie müssen das folgende Verfahren vollständig abschließen, bevor Sie eine physikalische Schnittstelle wiederherstellen können, die beim Systemstart nicht vorhanden war. Das Beispiel in diesem Verfahren hat die folgende Konfiguration:

Hinweis –

Das Failback von IP-Adressen während der Wiederherstellung einer ausgefallenen physikalischen Schnittstelle dauert bis zu 3 Minuten. Diese Zeit kann je nach Netzverkehr variieren. Außerdem hängt sie von der Stabilität der eingehenden Schnittstelle beim Failback der Failover-Schnittstellen vom in.mpathd-Daemon ab.

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Rufen Sie die Informationen zum ausgefallenen Netzwerk aus der Ausfall-Fehlermeldung im Konsolenprotokoll ab.

    Weitere Informationen finden Sie in der Manpage syslog(3C) Die Fehlermeldung könnte wie folgt angezeigt werden:


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

    Diese Meldung gibt an, dass die IPv4-Adressen der ausgefallenen Schnittstelle hme1 ein Failover auf die Schnittstelle hme0 durchgeführt haben.

    Alternativ empfangen Sie die folgende Meldung:


    moving addresses from failed IPv4 interfaces:
hme1 (couldn't move, no alternative interface)

    Diese Meldung kennzeichnet, dass keine aktive Schnittstelle in der gleichen Gruppe wie die ausgefallene Schnittstelle hme1 gefunden wurde. Aus diesem Grund konnte kein Failover für die IPv4-Adressen von hme1 durchgeführt werden.

  3. Schließen Sie die physikalische Schnittstelle im System an.

    Anweisungen zum Ersetzen einer physikalischen Schnittstelle finden Sie in den folgenden Quellen:

    • Manpage cfgadm(1M)

    • Sun Enterprise 10000 DR Configuration Guide

    • Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

  4. Siehe Meldung aus Schritt 2. Gehen Sie zu Schritt 6, wenn die Adressen nicht verschoben werden konnten. Gehen Sie zu Schritt 5, wenn die Adressen verschoben wurden.

  5. Heben Sie das Plumbing der logischen Schnittstellen auf, die im Rahmen des Failover-Prozesses konfiguriert wurden.

    1. Lesen Sie den Inhalt der /etc/hostname.verschoben-von-Schnittstelle-Datei, um festzustellen, welche logischen Schnittstellen im Rahmen des Failover-Prozesses konfiguriert wurden.

    2. Heben Sie das Plumbing aller Failover-IP-Adressen auf.


      # ifconfig moved-to-interface removeif moved-ip-address
      Hinweis –

      Failover-Adressen sind mit dem Parameter failover markiert oder mit dem Parameter -failover nicht markiert. Bei IP-Adressen, die mit dem Parameter -failover markiert sind, muss das Plumbing nicht aufgehoben werden.

      Angenommen, die Datei /etc/hostname.hme0 enthält die folgenden Zeilen:


      inet 10.0.0.4 -failover up group one
addif 10.0.0.5 failover up
addif 10.0.0.6 failover up

      Um alle Failover-IP-Adressen zu löschen, geben Sie die folgenden Befehle ein:


      # ifconfig hme0 removeif 10.0.0.5
# ifconfig hme0 removeif 10.0.0.6

  6. Konfigurieren Sie die IPv4-Informationen für die ersetzte physikalische Schnittstellen neu, indem Sie den folgenden Befehl für jede entfernte Schnittstelle eingeben:


    # ifconfig removed-from-NIC <parameters>

    Beispielsweise können Sie die folgenden Befehle eingeben:


    # ifconfig hme1 inet plumb
# ifconfig hme1 inet 10.0.0.4 -failover up group one
# ifconfig hme1 addif 10.0.0.5 failover up
# ifconfig hme1 addif 10.0.0.6 failover up

Ändern von IPMP-Konfigurationen

In der IPMP-Konfigurationsdatei /etc/default/mpathd werden die folgenden systemweit geltenden Parameter für IPMP-Gruppen konfiguriert.

ProcedureSo konfigurieren Sie die /etc/default/mpathd-Datei

  1. Nehmen Sie auf dem System mit der IPMP-Gruppenkonfiguration die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

    Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

  2. Bearbeiten Sie die Datei /etc/default/mpathd.

    Ändern Sie den Standardwert eines oder mehrerer der drei Parameter.

    1. Geben Sie den neuen Wert für den Parameter FAILURE_DETECTION_TIME ein.


      FAILURE_DETECTION_TIME=n

      n ist die Zeit in Sekunden für ICMP-Stichproben, um zu erkennen, ob eine Schnittstelle ausgefallen ist. Der Standardwert beträgt 10 Sekunden.

    2. Geben Sie einen neuen Wert für den Parameter FAILBACK ein.


      FAILBACK=[yes | no]

      • yes - Der Wert yes ist das Standard-Failback-Verhalten für IPMP. Wenn die Reparatur einer ausgefallenen Schnittstelle erkannt wird, findet ein Failback-Prozess des Netzwerkzugriffs auf die reparierte Schnittstelle statt. Dies wird unter IPMP-Funktionen zur Ausfall- und Reparaturerkennung ausführlich beschrieben.

      • no - Der Wert no gibt an, dass Datenverkehr kein Failback auf eine reparierte Schnittstelle durchführt. Wenn eine ausgefallene Schnittstelle als repariert erkannt wird, wird das Flag INACTIVE für diese Schnittstelle gesetzt. Dieses Flag weist darauf hin, dass die Schnittstelle derzeit nicht für Datenverkehr verwendet wird. Die Schnittstelle kann dennoch für Stichprobenverkehr verwendet werden.

        Angenommen, eine IPMP-Gruppe besteht aus zwei Schnittstellen, ce0 und ce1. Der Wert FAILBACK=no ist in der Datei /etc/default/mpathd eingerichtet. Wenn ce0 ausfällt, führt dessen Datenverkehr ein Failover auf ce1 durch. Dies ist das erwartete Standardverhalten von IPMP. Wenn IPMP jedoch erkennt, dass ce0 repariert wurde, findet kein Failback von ce1 statt, da der Parameter FAILBACK=no in der Datei /etc/default/mpathd eingerichtet ist. Die Schnittstelle ce0 behält den Status INACTIVE bei und wird nicht für Datenverkehr verwendet, es sei denn, die Schnittstelle ce1 fällt aus. Falls die Schnittstelle ce1 ausfällt, werden die Adressen von ce1 zurück zu ce0 migriert, dessen Flag INACTIVE gelöscht wird. Diese Migration findet nur dann statt, wenn ce0 die einzige Schnittstelle mit dem Flag INACTIVE in der Gruppe ist. Falls weitere INACTIVE-Schnittstellen in der Gruppe vorhanden sind, migrieren die Adressen eventuell zu einer anderen INACTIVE-Schnittstelle als ce0.

    3. Geben Sie den neuen Wert für den Parameter TRACK_INTERFACES_ONLY_WITH_GROUPS ein.


      TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]

      • yes - Der Wert yes ist das Standardverhalten für IPMP. Dieser Parameter führt dazu, dass IPMP Netzwerkschnittstellen ignoriert, die nicht in einer IPMP-Gruppe konfiguriert sind.

      • no - Der Wert no richtet eine Ausfall- oder Reparaturerkennung für alle Netzwerkschnittstellen ein, unabhängig davon, ob sie in einer IPMP-Gruppe konfiguriert sind. Wird ein Ausfall oder eine Reparatur einer Schnittstelle erkannt, die nicht in einer IPMP-Gruppe konfiguriert ist, findet kein Failover oder Failback statt. Aus diesem Grund eignet sich der Wert no nur zum Anzeigen von Ausfällen und führt zu keiner Verbesserung der Netzwerkverfügbarkeit.

  3. Starten Sie den in.mpathd-Daemon neu.


    # pkill -HUP in.mpathd