ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Oracle Solaris 管理: ネットワークインタフェースとネットワーク仮想化 Oracle Solaris 11 Information Library (日本語) |
この Oracle Solaris リリースでのネットワーク構成
7. プロファイルでのデータリンクおよびインタフェース構成コマンドの使用
10. Oracle Solaris 上での無線インタフェース通信の構成
IPMP は、トラフィックを送受信するネットワークの継続的な可用性を保証するために、IPMP グループのベースとなる IP インタフェースに対して障害検出を実行します。故障したインタフェースは、修復されるまで使用不可能なままになります。残りのアクティブインタフェースが機能し続ける一方で、既存のスタンバイインタフェースが必要に応じて配備されます。
in.mpathd デーモンは、次の種類の障害検出を処理します。
プローブベースの障害検出 (2 種類)
検査用アドレスが構成されない (推移的プローブ)。
検査用アドレスが構成される。
リンクベースの障害検出 (NIC ドライバがサポートしている場合)
プローブベースの障害検出では、ICMP プローブを使用してインタフェースが故障しているかどうかをチェックします。この障害検出手法の実装は、検査用アドレスが使用されるかどうかによって決まります。
検査用アドレスを使用しないこの手法は、2 種類のプローブを使用して実装されています。
ICMP プローブ
ICMP プローブは、経路指定テーブルに定義されたターゲットをプローブするために、グループ内のアクティブインタフェースによって送信されます。「アクティブ」インタフェースとは、そのインタフェースのリンク層 (L2) アドレス宛てのインバウンド IP パケットを受信できるベースとなるインタフェースのことです。ICMP プローブは、データアドレスをそのプローブの発信元アドレスとして使用します。ICMP プローブがそのターゲットに到達し、ターゲットから応答が得られた場合、そのアクティブインタフェースは動作しています。
推移的プローブ
推移的プローブは、アクティブインタフェースをプローブするために、グループ内の代替インタフェースによって送信されます。代替インタフェースとは、インバウンド IP パケットを能動的に受信しないベースとなるインタフェースのことです。
たとえば、4 つのベースとなるインタフェースから成る IPMP グループを考えます。このグループでは、データアドレスは 1 つ構成されていますが、検査用アドレスは 1 つも構成されていません。この構成では、アウトバウンドパケットはベースとなるインタフェースをすべて使用できます。一方、インバウンドパケットは、データアドレスがバインドされたインタフェースによってのみ受信できます。インバウンドパケットを受信できない残り 3 つのベースとなるインタフェースが、「代替」インタフェースとなります。
代替インタフェースがアクティブインタフェースへのプローブの送信と応答の受信に成功した場合、そのアクティブインタフェースは機能しており、推論により、プローブを送信した代替インタフェースも機能しています。
注 - 検査用アドレスを必要としないこの障害検出手法を使用するには、推移的プローブを有効にする必要があります。
この障害検出手法では、検査用アドレスを使用する ICMP 検査信号メッセージを送受信します。「プローブトラフィック」またはテストトラフィックとも呼ばれるこれらのメッセージは、インタフェース上から同じローカルネットワーク上の 1 つ以上のターゲットシステムへと送信されます。デーモンは、プローブベースの障害検出用に構成されたすべてのインタフェースを経由してすべてのターゲットを個別にプローブします。ある特定のインタフェースで、連続する 5 つの検査信号に対して応答がない場合、in.mpathd はそのインタフェースに障害があるものとみなします。検査信号を発信する頻度は、「障害検出時間」に依存します。障害検出時間のデフォルト値は 10 秒です。ただし、障害検出時間は IPMP 構成ファイルで調整できます。手順については、「IPMP デーモンの動作を構成する方法」を参照してください。プローブベースの障害検出を最適化するには、マルチパスデーモンからのプローブを受信する複数のターゲットシステムを設定する必要があります。複数のターゲットシステムを設定することで、報告された障害の性質をより正確に判定できます。たとえば、唯一定義されたターゲットシステムから応答がない場合、そのターゲットシステムの障害を示している可能性もあれば、IPMP グループのインタフェースの 1 つの障害を示している可能性もあります。これに対し、いくつかのターゲットシステムのうちの 1 つのシステムだけがプローブに応答しない場合は、IPMP グループ自体ではなく、ターゲットシステムで障害が発生している可能性があります。
in.mpathd デーモンは、プローブするターゲットシステムを動的に決定します。まず、デーモンは経路指定テーブル内で、IPMP グループのインタフェースに関連付けられた検査用アドレスと同じサブネット上にあるターゲットシステムを検索します。そのようなターゲットが見つかった場合、デーモンはそれらをプローブのターゲットとして使用します。同じサブネット上でターゲットシステムが見つからない場合、in.mpathd は、リンク上の近くのホストをプローブするマルチキャストパケットを送信します。ターゲットシステムとして使用するホストの決定にあたっては、すべてのホストを意味するマルチキャストアドレス (IPv4 では 224.0.0.1、IPv6 では ff02::1) にマルチキャストパケットが送信されます。エコーパケットに応答する最初の 5 つのホストが、プローブのターゲットとして選択されます。in.mpathd がマルチキャストプローブに続いて ICMP エコーパケットに応答したルーターまたはホストを検出できなかった場合、in.mpathd は検査信号ベースの障害を検出できません。この場合、ipmpstat -i ユーティリティーはプローブの状態を unknown として報告します。
ホストルートを使用して、in.mpathd が使用するターゲットシステムのリストを明示的に構成できます。手順については、「プローブベースの障害検出のための構成」を参照してください。
「グループ障害」は、IPMP グループ内のすべてのインタフェースが同時に故障したと思われる場合に発生します。この場合、ベースとなるインタフェースは一切使用できません。また、すべてのターゲットシステムが同時に故障したときに、プローブベースの障害検出が有効になっていた場合、in.mpathd デーモンはその現在のターゲットシステムをすべてフラッシュし、新しいターゲットシステムに対してプローブします。
検査用アドレスを持たない IPMP グループでは、アクティブインタフェースをプローブできる単一のインタフェースがプローバとして指定されます。この指定されたインタフェースには、FAILED フラグと PROBER フラグが両方とも設定されます。このインタフェースにデータアドレスがバインドされるため、このインタフェースは引き続き、ターゲットをプローブして回復を検出できます。
リンクベースの障害検出は、インタフェースがその種の障害検出をサポートしている場合は、常に有効です。
他社製のインタフェースがリンクベースの障害検出をサポートしているかどうかを判定するには、ipmpstat -i コマンドを使用します。ある特定のインタフェースの出力の LINK 列に unknown ステータスが含まれる場合、そのインタフェースはリンクベースの障害検出をサポートしません。デバイスに関するより具体的な情報については、製造元のドキュメントを参照してください。
リンクベースの障害検出をサポートするこれらのネットワークドライバは、インタフェースのリンク状態を監視し、リンク状態が変わったときにネットワークサブシステムに通知します。変更を通知されると、ネットワークサブシステムは、インタフェースの RUNNING フラグを適宜設定または解除します。インタフェースの RUNNING フラグが解除されたことを検出すると、in.mpathd デーモンは即座にインタフェースに障害があるものとみなします。
IPMP は匿名グループでの障害検出をサポートしています。デフォルトでは、IPMP は IPMP グループに属するインタフェースのステータスのみを監視します。ただし、どの IPMP グループにも属さないインタフェースのステータスも追跡するように IPMP デーモンを構成することもできます。したがって、これらのインタフェースは「匿名グループ」の一部とみなされます。コマンド ipmpstat -g を発行した場合、匿名グループは二重ダッシュ (--) として表示されます。匿名グループ内のインタフェースでは、データアドレスが検査用アドレスとしても機能します。これらのインタフェースは名前付きの IPMP グループに属していないため、これらのアドレスはアプリケーションから可視となります。IPMP グループの一部でないインタフェースの追跡を有効にする方法については、「IPMP デーモンの動作を構成する方法」を参照してください。
「修復検出時間」は障害検出時間の 2 倍です。障害検出のデフォルト時間は 10 秒です。したがって、修復検出のデフォルト時間は 20 秒です。故障したインタフェースが RUNNING フラグで再びマークされ、障害検出手法が修復済みとして検出すると、in.mpathd はそのインタフェースの FAILED フラグをクリアーします。修復されたインタフェースは、管理者が最初に設定したアクティブインタフェースの数に応じて再配備されます。
あるベースとなるインタフェースが故障したときに、プローブベースの障害検出が使用されていた場合、in.mpathd デーモンは、検査用アドレスが構成されていない場合は指定されたプローバ経由で、またはそのインタフェースの検査用アドレスを使用して、プローブを継続します。インタフェース修復時の復元は、故障したインタフェースの元の構成に応じて進みます。
故障したインタフェースが最初アクティブインタフェースだった – 修復されたインタフェースは元のアクティブステータスに戻ります。システム管理者によって定義された数のインタフェースがそのグループでアクティブになっていれば、故障中に代用品として機能していたスタンバイインタフェースは元のスタンバイステータスに切り替えられます。
故障したインタフェースが最初スタンバイインタフェースだった – IPMP グループがアクティブインタフェースの元の数を反映している場合、修復されたインタフェースは元のスタンバイステータスに戻ります。それ以外の場合、スタンバイインタフェースはアクティブインタフェースに切り替わります。
インタフェースの故障や修復時の IPMP の動作方法のグラフィカル表現を確認するには、「IPMP の動作方法」を参照してください。
デフォルトでは、故障したあと修復されたアクティブインタフェースは自動的に、グループ内で元のアクティブインタフェースに戻ります。この動作は、デーモンの構成ファイル内の FAILBACK パラメータの設定によって制御されます。ただし、管理者によっては、データアドレスが修復されたインタフェースに再マッピングされるときに発生する短い中断でも許容できない可能性もあります。そうした管理者は、起動されたスタンバイインタフェースが引き続きアクティブインタフェースとして機能できるようにすることを好む可能性があります。IPMP では、管理者がデフォルト動作を上書きして、インタフェースが修復時に自動的にアクティブにならないようにすることができます。これらのインタフェースは FAILBACK=no モードで構成する必要があります。関連する手順については、「IPMP デーモンの動作を構成する方法」を参照してください。
FAILBACK=no モードのアクティブインタフェースが故障したあと修復された場合、IPMP デーモンは IPMP の構成を次のように復元します。
IPMP グループがアクティブインタフェースの元の構成を反映している場合、デーモンはこのインタフェースの INACTIVE ステータスを維持します。
修復時点での IPMP の構成が、グループのアクティブインタフェースの元の構成を反映していない場合、FAILBACK=no ステータスであるにもかかわらず、修復されたインタフェースがアクティブインタフェースとして再配備されます。
注 - FAILBACK=NO モードは IPMP グループ全体に対して設定されます。これは、インタフェース単位でチューニング可能なパラメータではありません。