IPMP 故障检测和恢复功能

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

基于链路的故障检测（如果 NIC 驱动程序支持该故障检测）
基于探测器的故障检测（配置测试地址时）
检测引导时缺少的接口

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

基于链路的故障检测

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

hme
eri
ce
ge
bge
qfe
dmfe
e1000g
ixgb
nge
nxge
rge
xge

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

这些网络接口驱动程序会监视接口的链路状态，并在链路状态更改时通知联网子系统。收到更改通知后，联网子系统会根据需要设置或清除该接口的 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) 手册页。

跳过导航链接
退出打印视图
	系统管理指南：IP 服务 Oracle Solaris 10 8/11 Information Library (简体中文)