Solaris のシステム管理 (IP サービス)

IPMP 障害検出とリカバリ機能

in.mpathdデーモンは、次の種類の障害検出を処理します。

リンクベースの障害検出 (NIC ドライバがサポートしている場合)
検査信号ベースの障害検出 (検査用 IP アドレスが構成されている場合)
起動時に不足しているインタフェースの検出

in.mpathd デーモンがどのようにインタフェース障害の検出を処理するかについては、in.mpathd(1M) のマニュアルページに詳細に説明されています。

リンクベースの障害検出

リンクベースの障害検出は、インタフェースがその種の障害検出をサポートしている場合は、常に有効です。次の Sun ネットワークドライバは、Oracle Solaris の現在のリリースでサポートされています。

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

サン以外のインタフェースがリンクベースの障害検出をサポートしているかどうかを判断するには、メーカーのマニュアルを参照してください。

これらのネットワークインタフェースドライバは、インタフェースのリンク状態を監視し、リンク状態が変わったときにネットワークサブシステムに通知します。変更を通知されると、ネットワークサブシステムは、インタフェースの RUNNING フラグを適宜設定または解除します。インタフェースの RUNNING フラグが解除されたことを検出すると、デーモンは即座にインタフェースに障害があるものとみなします。

検査信号ベースの障害検出

in.mpathd デーモンは、検査用 IP アドレスを持つ IPMP グループの各インタフェースで検査信号ベースの障害検出を実行します。検査信号ベースの障害検出では、検査用 IP アドレスを使用して ICMP 検査信号メッセージを送受信します。これらのメッセージは、インタフェースを経由して同じ IP リンクの 1 つ以上のターゲットシステムに届きます。検査用 IP アドレスの紹介については、「検査用 IP アドレス」を参照してください。検査用 IP アドレスの構成については、「複数のインタフェースを持つ IPMP グループを構成する方法」を参照してください。

in.mpathd デーモンは、動的に検査信号を送信するターゲットシステムを検出します。IP リンクに接続されているルーターは、自動的に検査信号のターゲットとして選択されます。リンクにルーターがない場合、in.mpathd は検査信号をリンクの隣接ホストに送信します。ターゲットシステムとして使用するホストの選択にあたっては、すべてのホストを意味するマルチキャストアドレス (IPv4 では 224.0.0.1、IPv6 では ff02::1) にマルチキャストパケットが送信されます。検査信号は、ICMP エコーパケットに応答する最初のいくつかのホストに送信されます。in.mpathd が ICMP エコーパケットに応答したルーターまたはホストを検出できなかった場合、in.mpathd は検査信号ベースの障害を検出できません。

ホストルートを使用して、in.mpathd が使用するターゲットシステムのリストを明示的に構成できます。手順については、「ターゲットシステムの構成」を参照してください。

IPMP グループの各インタフェースが正常に機能するかどうかを確認するために、in.mpathd は、IPMP グループのすべてのインタフェースを通してすべてのターゲットに個別に検査信号を送信します。連続する 5 つの検査信号に対して応答がない場合、in.mpathd はそのインタフェースに障害があるものとみなします。検査信号を発信する頻度は、「障害検出時間」に依存します。障害検出時間のデフォルト値は 10 秒です。ただし、障害検出時間は /etc/default/mpathd ファイルで調整できます。手順については、「/etc/default/mpathd ファイルを構成する方法」を参照してください。

回復検出時間が 10 秒の場合、検査信号を発信する頻度はおよそ 2 秒に 1 度になります。最短の回復検出時間は障害検出時間の倍の時間となり、デフォルトは 20 秒です。これは、検査信号に対する応答を連続して 10 回受け取る必要があるためです。障害および回復検出時間は、検査信号ベースの障害検出だけに適用されます。

注 –

VLAN から構成される IPMP グループでは、リンクベースの障害検出が物理リンクごとに実装されるため、そのリンク上のすべての VLAN に影響します。検査信号ベースの障害検出は、VLAN リンクごとに実行されます。たとえば、bge0/bge1 と bge1000/bge1001 は、1 つのグループに構成されます。bge0 のケーブルが取り外されると、リンクベースの障害検出では、即時の障害発生場所として bge0 と bge1000 の両方が報告されます。ただし、bge0 上のすべての検査ターゲットが到達不可能になった場合は、障害発生場所として bge0 のみが報告されます。これは、 bge1000 は自身の VLAN 上の検査ターゲットを持つためです。

グループ障害

「グループ障害」は、IPMP グループ内のすべてのインタフェースで同じ時間に障害が起こったと考えられる場合に、発生します。in.mpathd デーモンは、グループ障害に対するフェイルオーバーは実行しません。これは、すべてのターゲットシステムで同時に障害が発生した場合も同様です。この場合 in.mpathd は、現在のすべてのターゲットシステム選択を取り消し、新しくターゲットシステムを見つけます。

物理インタフェースの回復検出

in.mpathd デーモンが回復するインタフェースを考慮できるように、インタフェースに RUNNING フラグを設定する必要があります。検査信号ベースの障害検出を使用する場合、in.mpathdデーモンは、インタフェースが回復したとみなされる前に、10 の連続する検査信号パケットへの応答を受信する必要があります。インタフェースが回復したとみなされると、別のインタフェースにフェイルオーバーしていたアドレスが、回復したインタフェースに復帰されます。障害前に「アクティブ」として構成されていたインタフェースは、回復後、トラフィックの送受信を再開できます。

インタフェースのフェイルオーバー時の処理

次の 2 つの例は、一般的な構成とインタフェースの障害時に構成がどのように自動的に変更されるかを示します。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

上記の例では、このインタフェースに障害が発生したことを示す FAILED フラグが hme0 に設定されています。また、hme1:2 が新しく作成されているのがわかります。hme0 の構成は hme1:2 に引き継がれました。アドレス192.168.85.19 は、hme1 によってアクセス可能になります。

192.168.85.19 と関連するマルチキャストメンバーシップは、そのままパケットを受信できますが、パケットの受信は hme1 を通して行われます。アドレス 192.168.85.19 が hme0 から hme1 にフェイルオーバーされると、ダミーアドレス 0.0.0.0 が hme0 に作成されます。ダミーアドレスは、hme0 を引き続きアクセスできる状態に保つために作成されます。hme0 がなければ、hme0:1 は存在できません。ダミーアドレスは、回復した経路への復帰時に削除されます。

同様に、IPv6 アドレスが hme0 から hme1 へ移されています。IPv6 では、マルチキャストメンバーシップはインタフェースインデックスに関連付けられています。マルチキャストメンバーシップも、障害経路の迂回処理により、hme0 から hme1 へ移されます。 in.ndpd によって構成されたすべてのアドレスも移動します。この動作は、上記の例には示されていません。

in.mpathd デーモンは引き続き、障害が発生したインタフェースの hme0 を通して検査を行います。デーモンは、デフォルトの回復検出時間 20 秒の間に連続して 10 回の応答を受け取った時点で、インタフェースが回復されたものとみなします。RUNNING フラグも hme0 で設定されるので、デーモンは回復した経路への復帰を呼び出します。回復した経路への復帰が行われると、元の構成が再びリストアされます。

障害時および回復時にコンソールに記録されるすべてのエラーメッセージの説明については、in.mpathd(1M) のマニュアルページを参照してください。