ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Solaris のシステム管理 (IP サービス) Oracle Solaris 10 8/11 Information Library (日本語) |
1. Oracle Solaris TCP/IP プロトコル群 (概要)
5. TCP/IP ネットワークサービスと IPv4 アドレス指定の構成 (作業)
10. TCP/IP と IPv4 の詳細 (リファレンス)
18. DHCP コマンドと DHCP ファイル (リファレンス)
21. IP セキュリティーアーキテクチャー (リファレンス)
25. Oracle Solaris の IP フィルタ (概要)
29. モバイル IP のファイルおよびコマンド (リファレンス)
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) のマニュアルページを参照してください。