test

Systemverwaltungshandbuch: IP Services

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).