ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris の管理: IP サービス Oracle Solaris 10 1/13 Information Library (日本語) |
1. Oracle Solaris TCP/IP プロトコル群 (概要)
5. TCP/IP ネットワークサービスと IPv4 アドレス指定の構成 (作業)
10. TCP/IP と IPv4 の詳細 (リファレンス)
17. DHCP のトラブルシューティング (リファレンス)
18. DHCP コマンドと DHCP ファイル (リファレンス)
21. IP セキュリティーアーキテクチャー (リファレンス)
25. Oracle Solaris の IP フィルタ (概要)
in.mpathdデーモンは次の種類の障害検出を処理します。
リンクベースの障害検出 (NIC ドライバがサポートしている場合)
検査信号ベースの障害検出 (検査用アドレスが構成されている場合)
ブート時に不足しているインタフェースの検出
in.mpathd デーモンがどのようにインタフェース障害の検出を処理するかについては、in.mpathd(1M) のマニュアルページに詳細に説明されています。
リンクベースの障害検出は、インタフェースでサポートされている場合は常に有効です。次の Sun ネットワークドライバは Oracle Solaris の現在のリリースでサポートされています。
hme
eri
ce
ge
bge
qfe
dmfe
e1000g
igb
ixgb
nge
nxge
rge
xge
サン以外のインタフェースがリンクベースの障害検出をサポートしているかどうかを判断するには、メーカーのマニュアルを参照してください。
これらのネットワークインタフェースドライバは、インタフェースのリンク状態を監視し、リンク状態が変わったときにネットワークサブシステムに通知します。変更を通知されると、ネットワークサブシステムは、インタフェースの RUNNING フラグを適宜設定または解除します。インタフェースの RUNNING フラグが解除されたことを検出すると、デーモンは即座にインタフェースに障害があるものとみなします。
in.mpathd デーモンは、検査用アドレスを持つ IPMP グループの各インタフェースで検査信号ベースの障害検出を実行します。検査信号ベースの障害検出では、検査用アドレスを使用して ICMP 検査信号メッセージを送受信します。これらのメッセージは、インタフェースを経由して同じ IP リンクの 1 つ以上のターゲットシステムに届きます。検査用アドレスの紹介については、「検査用アドレス」を参照してください。検査用アドレスの構成については、「複数のインタフェースを持つ 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 に移されます。
例 27-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
例 27-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) のマニュアルページを参照してください。