test

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

第 30 章 IPMP の紹介 (概要)

IP ネットワークマルチパス (IPMP) は、同一の IP リンク上に複数のインタフェースを保持するシステムで、物理インタフェースの障害検出および透過的なネットワークアクセスフェイルオーバーを提供します。IPMP も、複数のインタフェースを保持するシステムについて、パケットの負荷分散を提供します。

この章では、次の内容について説明します。

IPMP 構成作業については、第 31 章IPMP の管理 (手順)を参照してください。

IPMP を使用しなければならない理由

IPMP は、複数の物理インタフェースを持つシステムの信頼性、可用性、およびネットワークパフォーマンスを向上させます。物理インタフェースまたはそのインタフェースに接続しているネットワークハードウェアでは、ときどき障害が発生したり、メンテナンスが必要になったりすることがあります。従来、このような場合には、障害が発生したインタフェースに関連するどの IP アドレスを使用しても、システムに接続できなくなっていました。さらに、これらの IP アドレスを使用する既存のシステム接続も妨害されていました。

IPMP を使用すると、1 つ以上の物理インタフェースを IP マルチパスグループ、つまり「IPMP グループ」に構成できます。IPMP を構成すると、IPMP グループのインタフェースに障害が発生していないかどうかをシステムが自動的に監視します。グループ内のインタフェースで障害が発生した場合、またはインタフェースがメンテナンスのために取り外された場合、IPMP は、障害が発生したインタフェースの IP アドレスを自動的に移行、つまり「障害を迂回」します。フェイルオーバーされたアドレスは、障害が発生したインタフェースの IPMP グループ内の機能中のインタフェースが受け取ります。IPMP のフェイルオーバー機能は、接続を保持し、既存の接続の切断を防止します。さらに、IPMP は、ネットワークトラフィックを自動的に IPMP グループ内のインタフェースのセットに分散することによって、ネットワークパフォーマンス全体を向上させます。このプロセスは「負荷分散」と呼ばれます。

Oracle Solaris IPMP コンポーネント

Oracle Solaris IPMP には、次のソフトウェアが必要です。

マルチパスデーモン in.mpathd

in.mpathd デーモンはインタフェース障害を検出し、障害経路の迂回や回復した経路への復帰に対するさまざまな手続を実装します。in.mpathd は、障害または修復を検出すると、ioctl を送信して、フェイルオーバーまたは回復した経路への復帰を実行します。ioctl を実行する ip カーネルモジュールは、ネットワークアクセスのフェイルオーバーを、透過的かつ自動的に行います。

注 –

ネットワークインタフェースカードの同じセットで IPMP を使用している間は、代替パスを使用しないでください。同様に、代替パスを使用している間は、IPMP を使用しないでください。異なるインタフェースセットの場合は、代替パスと IPMP を同時に使用できます。代替パスについては、『Sun Enterprise Server Alternate Pathing 2.3.1 User Guide』を参照してください。

in.mpathd デーモンは、IPMP グループの一部であるインタフェースすべてに検査信号を送信して、障害と回復を検出します。in.mpathd デーモンも、グループに属する各インタフェースで RUNNING フラグを監視することによって障害や回復を検出します。詳細は、in.mpathd(1M) のマニュアルページを参照してください。

注 –

IPMP データアドレスの管理に DHCP は使用できません。これらのアドレスに対して DHCP を使用しようとすると、DHCP は最終的にこれらのアドレスの制御を放棄します。データアドレスには DHCP を使用しないでください。

IPMP の用語と概念

この節では、このマニュアルの IPMP の章を通して使用される用語と概念を紹介します。

IP リンク

IPMP の用語では、「IP リンク」は、ノードがインターネットプロトコル群のデータリンク層で通信を行う通信設備またはメディアです。IP リンクのタイプには、単純な Ethernet、ブリッジ Ethernet、ハブ、または ATM (Asynchronous Transfer Mode) ネットワークなどがあります。IP リンクは、1 つ以上の IPv4 サブネット番号、および適用できる場合は、1 つ以上の IPv6 サブネット接頭辞を持つことができます。同じサブネット番号またはネットワーク接頭辞を複数の IP リンクに割り当てることはできません。ATM LANE では、IP リンクは 1 つのエミュレートされた LAN (Local Area Network) です。ARP (Address Resolution Protocol) を使用する場合、ARP プロトコルの範囲は、1 つの IP リンクです。

注 –

RFC 2460、『Internet Protocol, Version 6 (IPv6) Specification』などのその他の IP 関連文書では、「IP リンク」の代わりに「リンク」という用語を使用します。パート 6 では、IEEE 802 との混乱を避けるために、「IP リンク」という用語を使用します。IEEE 802 では、「リンク」は、Ethernet ネットワークインタフェースカード (NIC) か ら Ethernet スイッチへの一本の配線を指します

物理インタフェース

「物理インタフェース」は、IP リンクにシステム接続を提供します。この接続は、しばしばデバイスドライバや NIC として実装されます。システムが同じリンクに複数のインタフェースを接続している場合は、IPMP を構成して、インタフェースの 1 つで障害が発生した場合に障害を迂回させることができます。物理インタフェースについては、「IPMP インタフェースの構成」を参照してください。

ネットワークインタフェースカード

「ネットワークインタフェースカード」(NIC) は、システム内に組み込むことができるネットワークアダプタです。また、NIC は、システムから IP リンクへのインタフェースとして機能する別のカードの場合もあります。複数の物理インタフェースを持つ NIC もあります。たとえば、qfe NIC は、qfe0 - qfe3 などの 4 つのインタフェースを持つことができます。

IPMP グループ

IP マルチパスグループ、つまり「IPMP」グループは、同じ IPMP グループ名で構成された同じシステム上の 1 つ以上の物理インタフェースで構成されます。IPMP グループ内のインタフェースは、同じ IP リンクに接続してください。同じ (空文字以外の) 文字列の IPMP グループ名は、グループ内のすべてのインタフェースを識別します。NIC のタイプが同じである限り、違った速度の NIC インタフェースを同じ IPMP グループ内に配置できます。たとえば、100M ビット Ethernet NIC のインタフェースと 1G ビット Ethernet NIC のインタフェースを同じグループに構成できます。別の例として、2 つの 100M ビット Ethernet NIC を持っているとします。インタフェースのどちらかを 10M ビットに下げて構成しても、この 2 つのインタフェースを同じ IPMP グループに配置できます。

メディアタイプの異なる 2 つのインタフェースを 1 つの IPMP グループに配置することはできません。たとえば、ATM インタフェースを Ethernet インタフェースと同じグループに配置することはできません。

障害検出とフェイルオーバー

「障害検出」は、インターネット層デバイスへのインタフェースまたはインタフェースからのパスが機能しなくなったことの検出プロセスです。IPMP は、インタフェースでの障害を検出する機能をシステムに提供します。IPMP は、次のタイプの通信障害を検出します。

障害を検出すると、IPMP はフェイルオーバーを開始します。「フェイルオーバー」は、障害が発生したインタフェースから同じグループ内の機能中の物理インタフェースにネットワークアクセスを切り替える自動プロセスです。ネットワークアクセスには、IPv4 のユニキャスト、マルチキャスト、およびブロードキャストと、IPv6 のユニキャストとマルチキャストが含まれます。フェイルオーバーは、IPMP グループ内に複数のインタフェースを構成している場合のみ実行できます。フェイルオーバープロセスにより、ネットワークへのアクセスは中断することなく継続されます。

回復の検出と回復した経路への復帰

「回復の検出」は、障害後、 NIC または NIC からインターネット層デバイスへのパスが正しく機能し始めたときの検出プロセスです。NIC が回復されたことを検出すると、IPMP は、ネットワークアクセスを回復されたインタフェースに戻すプロセスである「回復した経路への復帰」を実行します。回復検出が行われるのは、回復した経路への復帰が有効になっている場合のみです。詳細については、「物理インタフェースの回復検出」を参照してください。

ターゲットシステム

検査信号ベースの障害検出は、「ターゲットシステム」を使用して、インタフェースの状態を判断します。各ターゲットシステムは、IPMP グループのメンバーと同じ IP リンクに接続します。 ローカルシステムの in.mpathd デーモンは、ICMP 検査信号メッセージを各ターゲットシステムに送信します。検査信号メッセージは、IPMP グループ内の各インタフェースの状態を判断するのに役立ちます。

検査信号ベースの障害検出での対象システムの使用については、「検査信号ベースの障害検出」を参照してください。

出力負荷の分散

IPMP を構成すると、出力ネットワークパケットは、パケットの順番に影響を与えることなく、複数の NIC に分散されます。このプロセスは、「負荷分散」として知られています。負荷分散の結果、より高いスループットを達成できます。ただし、負荷分散が行われるのは、データが複数の接続を経由して複数の標識に送信される場合だけです。

動的再構成 (DR)

「動的再構成」(DR) は、既存の操作にほとんど、またはまったく影響を与えることなく、システムを実行しながらシステムを再構成する機能です。Sun プラットフォームの一部は、DR をサポートしていません。Sun プラットフォームの一部は、特定のタイプのハードウェアの DR だけをサポートする場合があります。NIC の DR をサポートするプラットフォームでは、IPMP を使用して透過的にネットワークアクセスの障害を迂回し、システムのネットワークアクセスは中断なしで継続させることができます。

IPMP がどのように DR をサポートするかについては、「IPMP と動的再構成」を参照してください。

IPMP の基本要件

IPMP は Oracle Solaris に組み込まれており、特殊なハードウェアを必要としません。Oracle Solaris でサポートされているインタフェースはすべて、IPMP と使用できます。ただし、IPMP はネットワーク構成とトポロジに次の要件を課します。

IPMP アドレス指定

IPMP 障害検出は、IPv4 ネットワークと IPv4 および IPv6 のデュアルスタックネットワークで構成できます。IPMP で構成されたインタフェースは、 データアドレスと検査用 IP アドレスという 2 種類のアドレスをサポートしています。

データアドレス

「データアドレス」は、起動時または手動で ifconfig コマンドによって NIC のインタフェースに割り当てられる従来の IPv4 および IPv6 アドレスです。標準 IPv4 と、適用できる場合は、インタフェースを通した IPv6 パケットトラフィックは、「データトラフィック」とみなされます。

検査用 IP アドレス

「検査用 IP アドレス」は、in.mpathdデーモンが使用する IPMP 固有のアドレスです。検査信号ベースの障害と回復の検出を使用するインタフェースの場合、そのインタフェースは 1 つ以上の検査用 IP アドレスで構成する必要があります。

注 –

DR を使用してプローブベースの障害検出を使用する場合のみ、テストアドレスを構成する必要があります。

in.mpathd デーモンは、検査用 IP アドレスを使用して、「検査信号トラフィック」とも呼ばれる ICMP 検査信号を IP リンク上のほかのターゲットと交換します。検査信号トラフィックは、インタフェースで障害が発生していないかどうかなど、インタフェースと NIC のステータスを判断するのに役立ちます。検査信号は、インタフェースとの送受信パスが正しく機能していることを確認します。

各インタフェースは、IP 検査用 IP アドレスで構成できます。デュアルスタックネットワークのインタフェースの場合、IPv4 検査用 IP アドレス、IPv6 検査用 IP アドレス、または IPv4 と IPv6 検査用 IP アドレスの両方を構成できます。

インタフェースで障害が発生すると、in.mpathd がそれ以降の回復をチェックするために検査信号を送信し続けることができるように、検査用 IP アドレスは障害が発生したインタフェースに留まります。アプリケーションが間違って使用しないように、検査用 IP アドレスは具体的に構成しなければなりません。詳細については、「アプリケーションによる検査用 IP アドレス使用の防止」を参照してください。

検査信号ベースの障害検出については、「検査信号ベースの障害検出」を参照してください。

IPv4 検査用アドレス

一般的に、どの IPv4 アドレスもサブネット上で検査用 IP アドレスとして使用できます。IPv4 検査用 IP アドレスは、ルートが指定できなくても構いません。IPv4 アドレスは、多くのサイトでは限定リソースなので、ルート指定できない RFC 1918 プライベートアドレスを検査用 IP アドレスとして指定したい場合もあります。 in.mpathd デーモンは、ICMP 検査信号を検査用 IP アドレスと同じサブネットのホストとしか交換しません。RFC 1918 形式の検査用 IP アドレスを使用していない場合は、IP リンク上のほかのシステム (ルーターが望ましい) を適切な RFC 1918 サブネットのアドレスで必ず構成してください。この構成により、in.mpathd デーモンは、ターゲットシステムと正常に検査信号を交換できます。

IPMP の例は、192.168.0/24 ネットワークの RFC 1918 アドレスを IPv4 検査用 IP アドレスとして使用します。RFC 1918 プライベートアドレスの詳細については、RFC 1918, Address Allocation for Private Internets を参照してください。

IPv4 検査用 IP アドレスを構成するには、タスク「複数のインタフェースを持つ IPMP グループを構成する方法」を参照してください。

IPv6 検査用 IP アドレス

有効な IPv6 検査用 IP アドレスは、物理インタフェースのリンクローカルアドレスだけです。IPMP 検査用 IP アドレスとして機能する別の IPv6 アドレスは必要ありません。IPv6 リンクローカルアドレスは、インタフェースのメディアアクセスコントロール (MAC) アドレスに基づいています。リンクローカルアドレスは、インタフェースが起動時に IPv6 を使用できるようになったり、ifconfig によって手動で構成された場合に、自動的に構成されます。

インタフェースのリンクローカルアドレスを識別するには、IPv6 が有効なノードで ifconfig interface コマンドを実行します。リンクローカル接頭辞 fe80 で始まるアドレスの出力をチェックします。次の ifconfig の NOFAILOVER フラグは、hme0 インタフェースのリンクローカルアドレスfe80::a00:20ff:feb9:17fa/10 が検査用 IP アドレスとして使用されていることを示しています。 


hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:17fa/10

リンクローカルアドレスについては、リンクローカルユニキャストアドレスを参照してください。

IPMP グループですべてのグループのインタフェースに IPv4 と IPv6 の両方が使用される場合には、別個の IPv4 検査用アドレスは必要ない場合があります。in.mpathd デーモンは、IPv6 リンクローカルアドレスを検査用 IP アドレスとして使用します。

IPv6 検査用 IP アドレスを作成するには、タスク「複数のインタフェースを持つ IPMP グループを構成する方法」を参照してください。

アプリケーションによる検査用 IP アドレス使用の防止

検査用 IP アドレスの構成後、アドレスがアプリケーションによって使用されないことを確認する必要があります。確認しなかった場合、インタフェースで障害が発生しても、検査用 IP アドレスはフェイルオーバー操作でフェイルオーバーできないので、アプリケーションを操作できなくなります。IP が一般的なアプリケーションに対して検査用 IP アドレスを選択しないことを確認するために、検査用 IP アドレスを deprecated とマークします。

deprecated (推奨されない) と指定したアドレスは、アプリケーションで明示的に指定されていない限り、通信のソースアドレスとしては選択されません。in.mpathd デーモンは、検査信号トラフィックを送受信するためにこのようなアドレスを明示的に指定します。

IPv6 リンクローカルアドレスは通常ネームサービス内にないので、DNS と NIS アプリケーションは通信のリンクローカルアドレスを使用しません。結果として、IPv6 リンクローカルアドレスを deprecated とマークする必要はなくなります。

IPv4 検査用 IP アドレス を DNS および NIS ネームサービステーブルに配置しないでください。通常はネームサービステーブルには追加されません。

IPMP インタフェースの構成

IPMP 構成は、通常同じ IP リンクに接続された同じシステムの複数の物理インタフェースで構成されます。これらの物理インタフェースは、同じ NIC 上にある場合とない場合があります。これらのインタフェースは、同じ IPMP グループのメンバーとして構成されます。システムは、2 番目の IP リンクに追加インタフェースを持つので、これらのインタフェースを別の IPMP グループとして構成する必要があります。

単独インタフェースは、それ自体の IPMP グループ内で構成できます。単独インタフェースIPMP グループは、複数のインタフェースを持つ IPMP グループと同じように動作します。ただし、インタフェースが 1 つだけの IPMP グループでは、フェイルオーバーと回復した経路への復帰は実行できません。

IP インタフェースからグループを構成するのと同じ手順を使用して、VLAN を IPMP グループに構成することもできます。手順については、「IPMP グループの構成」を参照してください。VLAN を IPMP グループに構成する際には、「IPMP の基本要件」に記載されているのと同じ要件が適用されます。

注意 – 注意 –

VLAN を IPMP グループとして構成するときに、VLAN の命名に使用される規則によってエラーが生じることがあります。VLAN 名の詳細については、「VLAN タグと物理接続点」 in 『System Administration Guide: IP Services』を参照してください。bge1000、bge1001、bge2000、bge2001 という 4 つの VLAN の例を考えてみます。IPMP の実装では、これらの VLAN を次のようにグループ化する必要があります。つまり、bge1000 と bge1001 は同じ VLAN 1 の 1 つのグループに属し、bge2000 と bge2001 は同じ VLAN 2 の別のグループに属すことが必要です。VLAN 名が原因で、たとえば bge1000 と bge2000 など、異なるリンクに属している VLAN を 1 つの IPMP グループに混在させるといった誤りが発生しやすくなっています。

IPMP グループ内の予備インタフェース

IPMP グループ内の「予備インタフェース」は、グループ内のほかのインタフェースで障害が発生しない限り、データトラフィックには使用されません。障害が発生すると、障害が発生したインタフェースのデータアドレスが予備インタフェースに移行されます。移行後、障害が発生したインタフェースが回復されるまで、予備インタフェースはほかのアクティブなインタフェースと同じように扱われます。一部の障害では、待機インタフェースが選択されないことがあります。そのかわり、フェイルオーバーで、待機インタフェースより少ないデータアドレスを持ち、UP として構成されたアクティブなインタフェースが選択されます。

待機インタフェースには検査用 IP アドレスだけを構成します。IPMP では、ifconfig コマンドによって standby として構成したインタフェースにデータアドレスを追加することはできません。このような構成を作成しようとしても失敗します。同様に、すでにデータアドレスを持っているインタフェースを standby として構成しても、それらのアドレスは、自動的に IPMP グループ内の別のインタフェースにフェイルオーバーされます。これらの制限により、インタフェースを standby として設定する前に、ifconfig コマンドを使用して検査用 IP アドレスを -deprecated および failover としてマークする必要があります。待機インタフェースを構成するには、「IPMP グループの待機インタフェースを構成する方法」を参照してください。

一般的な IPMP インタフェースの構成

「IPMP アドレス指定」のとおり、IPMP グループ内のインタフェースは、インタフェースの構成によって、通常のデータトラフィックと検査信号トラフィックを処理します。ifconfig コマンドの IPMP オプションを使用して、構成を行います。

「アクティブなインタフェース」とは、データトラフィックと検査信号トラフィックの両方を転送する物理インタフェースです。「複数のインタフェースを持つ IPMP グループを構成する方法」または 「単一インタフェースの IPMP グループを構成する方法」のどちらかのタスクを実行すると、インタフェースが「アクティブ」として構成されます。

次に IPMP 構成の一般的な種類を 2 つ示します。

アクティブ-アクティブ構成

両方のインタフェースが「アクティブ」である 2 つのインタフェースを持つ IPMP グループです。つまり、検査信号とデータの両方のトラフィックが送信されている可能性があります。

アクティブ-待機構成

一方のインタフェースが「待機」として構成されている、2 つのインタフェースを持つ IPMP グループです。

インタフェースのステータスチェック

インタフェースのステータスは、ifconfig インタフェース コマンドを発行してチェックできます。ifconfig ステータスレポートの一般的な情報については、特定のインタフェースに関する情報を入手する方法を参照してください。

たとえば、ifconfig コマンドを使用して、待機インタフェースのステータスを取得できます。待機インタフェースがデータアドレスのホストになっていない場合は、そのインタフェースのステータスには INACTIVE フラグが付いています。このフラグは、ifconfig の出力の インタフェースのステータス行で見ることができます。

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

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

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

リンクベースの障害検出

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

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

これらのネットワークインタフェースドライバは、インタフェースのリンク状態を監視し、リンク状態が変わったときにネットワークサブシステムに通知します。変更を通知されると、ネットワークサブシステムは、インタフェースの 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) のマニュアルページを参照してください。

IPMP と動的再構成

動的再構成 (DR) 機能によって、システムの実行中にインタフェースなどのシステムハードウェアを再構成できます。この節では、DR が IPMP とどのように相互運用できるかについて説明します。

NIC の DR をサポートするシステム上では、IPMP を使用して接続を保持したり、既存の接続の切断を防止できます。DR をサポートし、IPMP を使用するシステムの NIC は、安全に接続、切断、または再接続できます。これが可能なのは、IPMP が RCM (Reconfiguration Coordination Manager) フレームワークと統合されているからです。「RCM」は、システムコンポーネントの動的再構成を管理します。

一般的には、cfgadm コマンドを使用して、DR 操作を実行します。ただし、ほかの方法で動的再構成を行うプラットフォームもあります。詳細は、お使いのプラットフォームのマニュアルを参照してください。DR に関する具体的な文書は、次のリソースから得ることができます。

表 30–1 動的再構成の文書リソース

説明 

参照先 

cfgadm コマンドの詳細情報

cfgadm(1m) のマニュアルページ

Sun Cluster 環境での DR に関する具体的な情報 

Sun Cluster 3.1 System Administration Guide

Sun Fire 環境での DR に関する具体的な情報 

Sun Fire 880 Dynamic Reconfiguration Guide

DR と cfgadm コマンドに関する紹介情報

『Solaris のシステム管理 (デバイスとファイルシステム)』の第 6 章「デバイスの動的構成 (手順)」

DR をサポートするシステムでの IPMP グループの管理タスク 

「動的再構成をサポートするシステムでの障害が発生した物理インタフェースの交換」

NIC の接続

How to Configure an IPMP Group With Multiple Interfacesの説明どおり、「複数のインタフェースを持つ IPMP グループを構成する方法」 コマンドを使用して、IPMP グループにいつでもインタフェースを追加できます。よって、システム起動後に接続したシステムコンポーネント上のすべてのインタフェースは plumb され、既存の IPMP グループに追加されます。また、適当であれば、新たに追加したインタフェースを独自の IPMP グループで構成することも可能です。

これらのインタフェースとこれらに構成されたデータアドレスは、IPMP グループによって即座に使用できます。ただし、システムが再起動後、自動的にインタフェースを構成し、使用するようにするには、新しいインタフェースごとに /etc/hostname.interface ファイルを作成する必要があります。手順については、システムインストール後に物理インタフェースを構成する方法を参照してください。

インタフェースの接続時に、/etc/hostname.interface ファイルがすでに存在する場合は、RCM は、このファイルの内容に従って、自動的にインタフェースを構成します。よって、インタフェースは、システム起動後に受け取るのと同じ構成を受け取ります。

NIC の切断

NIC を含むシステムコンポーネントを切断するすべての要求は、まず接続性を保持できるかどうかチェックされます。たとえば、デフォルトでは、IPMP グループ外の NIC を切断することはできません。IPMP グループ内の機能中のインタフェースだけを含む NIC も切断できません。ただし、システムコンポーネントを削除しなければならない場合は、cfgadm(1m) のマニュアルページに説明されている cfgadm の -f オプションを使用して、この動作を無効にできます。

チェックが成功すると、切断された NIC に関連するデータアドレスは、切断された NIC で障害が発生した場合のように、同じグループ内の機能中の NIC にフェイルオーバーされます。 NIC が切断されると、NIC のインタフェースのすべての検査用 IP アドレスの構成が解除されます。次に、NIC はシステムを unplumb します。これらの手順のいずれかが失敗した場合、または同じシステムコンポーネントのその他のハードウェアの DR で障害が発生した場合は、前の構成が元の状態にリストアされます。ユーザーは、このイベントに関するステータスメッセージを受け取るはずです。メッセージがない場合は、切断要求は正常に完了しています。システムからコンポーネントを削除できます。既存の接続は切断されません。

NIC の再接続

RCM は、実行中のシステムから切断された NIC と関連する構成情報を記録します。結果として、RCM は、新しい NIC の接続と同様に、以前切断された NIC の再接続を扱います。つまり、RCM は plumb することだけを行います。

ただし、再接続された NIC は、通常既存の /etc/hostname.interface ファイルを持っています。この場合、RCM は、既存の /etc/hostname.interface ファイルの内容に従って、自動的にインタフェースを構成します。さらに、RCM は、再接続されたインタフェースに元々あった各データアドレスを in.mpathdデーモンに通知します。よって、再接続されたインタフェースが正しく機能するようになると、そのすべてのデータアドレスが、回復時のように再接続されたインタフェースに復帰されます。

再接続されている NIC に /etc/hostname.interfaceファイルがない場合は、構成情報は使用できません。RCM は、インタフェースの構成方法に関する情報をまったく持ちません。このため、以前別のインタフェースにフェイルオーバーされたアドレスが回復した経路へ復帰されないことになります。

システム起動時にない NIC

システム起動時にない NIC は、特別な障害検出です。起動時、起動スクリプトは、plumb できない /etc/hostname.interface ファイルを持つインタフェースを追跡します。このようなインタフェースの/etc/hostname.interface ファイル内のデータアドレスは、IPMP グループ内の代替インタフェースに自動的に配置されます。

このような場合は、次のようなエラーメッセージを受け取ります。


moving addresses from failed IPv4 interfaces: hme0 (moved to hme1)
moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)

代替インタフェースが存在しない場合は、次のようなエラーメッセージを受け取ります。


moving addresses from failed IPv4 interfaces: hme0 (couldn't move; 
   no alternative interface) 
 moving addresses from failed IPv6 interfaces: hme0 (couldn't move; 
   no alternative interface)
注 –

このような障害検出では、不足インタフェースの /etc/hostname.interfaceファイルで明示的に指定されているデータアドレスだけが、代替インタフェースに移されます。通常、RARP または DHCP などのほかの手段で取得されるアドレスは、取得または移動されません。

DR を使用して、システム起動時に不足していた別のインタフェースと同じ名前のインタフェースが再接続される場合、RCM は、インタフェースを自動的に plumb します。次に、RCM は、インタフェースの /etc/hostname.interfaceファイルの内容に従って、インタフェースを構成します。最後に、インタフェースが回復したときのように、RCM はデータアドレスを回復した経路へ復帰させます。よって、最終的なネットワーク構成は、システムが現在のインタフェースで起動された場合と同一の構成になります。