test

系统管理指南：IP 服务

IPMP 故障检测和恢复功能

in.mpathd 守护进程处理以下类型的故障检测：

in.mpathd(1M) 手册页对 in.mpathd 守护进程如何处理接口故障的检测进行了完整说明。

基于链路的故障检测

如果接口支持基于链路的故障检测，应始终启用该类故障检测。在 Oracle Solaris ： 的当前发行版中支持以下 Sun 网络驱动程序：

要确定第三方接口是否支持基于链路的故障检测，请参阅制造商文档。

这些网络接口驱动程序会监视接口的链路状态，并在链路状态更改时通知联网子系统。收到更改通知后，联网子系统会根据需要设置或清除该接口的 RUNNING 标志。守护进程在检测到接口的 RUNNING 标志已被清除时，会立即使该接口失效。

基于探测器的故障检测

in.mpathd 守护进程会对 IPMP 组中具有测试地址的每个接口执行基于探测器的故障检测。基于探测器的故障检测涉及使用测试地址发送和接收 ICMP 探测器消息。这些消息通过接口发送到同一 IP 链路上的一个或多个目标系统。有关测试地址的介绍，请参阅测试地址。有关配置测试地址的信息，请参阅如何配置具有多个接口的 IPMP 组。

in.mpathd 守护进程确定要动态探测的目标系统。会自动将连接到 IP 链路的路由器选为探测目标。如果在链路上不存在路由器，则 in.mpathd 会将探测器发送到链路上的相邻主机。发送到所有主机多点传送地址（在 IPv4 中为 224.0.0.1，在 IPv6 中为 ff02::1）的多点传送包可确定要用作目标系统的主机。对回显包作出响应的前几个主机将被选作探测目标。如果 in.mpathd 找不到响应 ICMP 回显包的路由器或主机，则 in.mpathd 无法检测基于探测器的故障。

可以使用主机路由显式配置要由 in.mpathd 使用的目标系统的列表。有关说明，请参阅配置目标系统。

为确保 IPMP 组中的每个接口都正常工作，in.mpathd 将通过 IPMP 组中的所有接口分别探测所有目标。如果对五个连续的探测器未做出任何响应，则 in.mpathd 认为接口已出现故障。探测速率取决于故障检测时间 (failure detection time, FDT)。故障检测时间的缺省值是 10 秒。不过，可以在 /etc/default/mpathd 文件中调整故障检测时间。有关说明，请转至如何配置 /etc/default/mpathd 文件。

对于 10 秒的修复检测时间，探测速率约为每两秒发送一个探测器。最短的修复检测时间是故障检测时间的两倍，缺省情况下为 20 秒，因为必须收到对 10 个连续探测器的回复。故障检测时间和修复检测时间仅适用于基于探测器的故障检测。

注 –

由 VLAN 组成的 IPMP 组，基于链路的故障检测通过物理链路实现，因此影响该链路上的所有 VLAN。基于探测器的故障检测通过 VLAN 链路执行。例如，同时在一个组内配置bge0/bge1 和 bge1000/bge1001。如果已拔出 bge0 的电缆，那么基于链路的故障检测将立即报告 bge0 和 bge1000 都好像已发生故障。但是，如果 bge0 上的所有探测器目标变得不可访问，将仅报告 bge0 发生故障，因为 bge1000 在其自己的 VLAN 上有其自己的探测器目标。

组故障

当 IPMP 组中的所有接口看起来同时出现故障时，就会出现组故障。对于组故障，in.mpathd 守护进程不执行故障转移。此外，当所有目标系统同时出现故障时，也不会执行故障转移。在这种情况下，in.mpathd 会清除其当前所有的目标系统并搜索新的目标系统。

检测物理接口修复

要使 in.mpathd 守护进程将某个接口视为要进行修复，必须为该接口设置 RUNNING 标志。如果使用基于探测器的故障检测，in.mpathd 守护进程必须先从接口收到对 10 个连续探测器包的响应，才会将该接口视为已修复。接口被视为已修复时，故障转移到其他接口的任何地址都将故障恢复到已修复的接口。如果接口在出现故障之前被配置为“活动”，则在修复之后该接口可以恢复发送和接收通信。

接口故障转移期间发生的情况

以下两个示例说明了一种典型配置，以及该配置在接口出现故障时如何自动更改。当 hme0 接口出现故障时，请注意所有数据地址都将从 hme0 移动到 hme1。

示例 30–1 接口出现故障之前的接口配置


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
示例 30–2 接口出现故障之后的接口配置


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

可以看到，在 hme0 上设置了 FAILED 标志，以指示此接口已出现故障。还可以看到，创建了 hme1:2，而 hme1:2 最初是 hme0。然后，地址 192.168.85.19 变成可通过 hme1 进行访问。

与 192.168.85.19 关联的多点传送成员仍可以接收包，但是它们现在通过 hme1 接收包。当进行地址 192.168.85.19 从 hme0 到 hme1 的故障转移时，在 hme0 上创建了伪地址 0.0.0.0。由于创建了伪地址，因此仍可以访问 hme0。如果没有 hme0，hme0:1 便无法存在。在执行后续的故障恢复时，将删除伪地址。

同样，进行了 IPv6 地址从 hme0 到 hme1 的故障转移。在 IPv6 中，多点传送成员与接口索引关联。多点传送成员也从 hme0 故障转移到 hme1。而且还移动了 in.ndpd 配置的所有地址。示例中未说明此操作。

in.mpathd 守护进程继续通过故障接口 hme0 进行探测。守护进程在 20 秒的缺省修复检测时间内收到 10 个连续回复后，确定该接口已修复。由于在 hme0 上也设置了 RUNNING 标志，因此守护进程调用故障恢复。在故障恢复后，将恢复原始配置。

有关故障和修复期间在控制台上记录的所有错误消息的说明，请参见 in.mpathd(1M) 手册页。