| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 管理: ネットワークインタフェースとネットワーク仮想化 Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 管理: ネットワークインタフェースとネットワーク仮想化 Oracle Solaris 11 Information Library (日本語) |
この Oracle Solaris リリースでのネットワーク構成
7. プロファイルでのデータリンクおよびインタフェース構成コマンドの使用
10. Oracle Solaris 上での無線インタフェース通信の構成
この節は、IPMP グループの使用に関するさまざまなトピックについて説明します。
さまざまな要因によりインタフェースが使用不可能になる可能性があります。一般に、IP インタフェースは故障する可能性があります。また、インタフェースは、ハードウェア保守のためにオフラインに切り替えられる可能性もあります。そのような場合、IPMP グループを使用しないと、その使用不可能になったインタフェースに関連付けられたどの IP アドレスを使用しても、システムと通信できなくなります。さらに、それらの IP アドレスを使用する既存の接続が切断されます。
IPMP を使用すると、1 つ以上の IP インタフェースを 1 つの「IPMP グループ」に構成できます。このグループは、ネットワークトラフィックを送受信するデータアドレス付きの IP インタフェースのように機能します。グループ内のベースとなるインタフェースの 1 つが故障すると、グループ内の残りのアクティブなベースとなるインタフェースの間でデータアドレスが再分配されます。したがって、インタフェースの 1 つが故障しても、グループはネットワークの接続性を維持します。IPMP では、グループで最低 1 つのインタフェースが使用可能であれば、ネットワーク接続を常に使用できます。
また、IPMP は、IPMP グループ内のインタフェースセット全体にアウトバウンドネットワークトラフィックを自動的に分散させることにより、全体的なネットワークパフォーマンスを向上させます。このプロセスは、アウトバウンド「負荷分散」と呼ばれます。システムはさらに、アプリケーションによって発信元 IP アドレスが指定されなかったパケットに対して発信元アドレス選択を実行することにより、インバウンド負荷分散も間接的に制御します。ただし、アプリケーションが発信元 IP アドレスを明示的に選択した場合は、システムはその発信元アドレスを変更しません。
IPMP グループの構成はシステムの構成によって決まります。次の規則に従います。
同じローカルエリアネットワーク (LAN) 上の複数の IP インタフェースは、1 つの IPMP グループに構成される必要があります。LAN は大まかに、「同じリンク層ブロードキャストドメイン」に属するノードを含む VLAN や有線/無線の両ローカルネットワークなど、さまざまなローカルネットワーク構成を指します。
注 - 同じリンク層 (L2) ブロードキャストドメイン上の複数の IPMP グループはサポートされていません。通常、L2 ブロードキャストドメインは特定のサブネットに対応します。したがって、サブネットごとに IPMP グループを 1 つだけ構成する必要があります。
IPMP グループのベースとなる IP インタフェースが異なる LAN にまたがってはいけません。
たとえば、3 つのインタフェースを備えたシステムが 2 つの別個の LAN に接続されているとします。一方の LAN に 2 つの IP インタフェースがリンクし、他方に単一の IP インタフェースが接続します。この場合、最初の規則により、1 つ目の LAN に接続する 2 つの IP インタフェースは 1 つの IPMP グループとして構成される必要があります。2 番目の規則のため、2 つ目の LAN に接続する単一の IP インタフェースがその IPMP グループのメンバーになることはできません。その単一の IP インタフェースでは、IPMP 構成は必須ではありません。ただし、その単一のインタフェースの可用性を監視するために、そのインタフェースを 1 つの IPMP グループに構成してもかまいません。単一インタフェースの IPMP 構成の詳細については、「IPMP インタフェース構成のタイプ」を参照してください。
別のケースとして、1 つ目の LAN へのリンクが 3 つの IP インタフェースから構成され、もう 1 つのリンクが 2 つのインタフェースから構成される場合を考えます。この設定は 2 つの IPMP グループの構成を必要とします。1 つ目の LAN にリンクする、3 つのインタフェースから成るグループと、2 つ目に接続する、2 つのインタフェースから成るグループです。
IPMP とリンク集約は、改善されたネットワークパフォーマンスの実現とネットワーク可用性の維持のための異なるテクノロジです。一般に、高いネットワークパフォーマンスを得るためにリンク集約を配備し、高い可用性を確保するために IPMP を使用します。
次の表は、リンク集約と IPMP の全般的な比較を示します。
|
リンク集約では、受信トラフィックは、その集約を構成する複数のリンクにわたって分散されます。したがって、より多くの NIC を取り付けて集約にリンクを追加すると、ネットワークのパフォーマンスが向上します。IPMP のトラフィックは IPMP インタフェースのデータアドレスを使用しますが、これは、それらのデータアドレスが、使用可能なアクティブインタフェースにバインドされるからです。たとえば、すべてのデータトラフィックは 2 つの IP アドレスの間のみを流れるが、それらのトラフィックが同じ接続上を流れるとはかぎらない場合には、より多くの NIC を追加しても IPMP のパフォーマンスは改善しません。なぜなら、使用可能な IP アドレスは依然として 2 つだけだからです。
この 2 つのテクノロジは互いに補い合うため、両者を一緒に配備して、ネットワークパフォーマンスと可用性の両方の利点を提供できます。たとえば、特定のベンダーによって独自のソリューションが提供されないかぎり、現時点ではリンク集約が複数のスイッチにまたがることはできません。したがって、あるスイッチとホスト間のリンク集約では、そのスイッチがシングルポイント障害となります。スイッチが故障するとリンク集約も同様に失われ、ネットワークのパフォーマンスが低下します。IPMP グループにはこのスイッチの制限がありません。したがって、複数のスイッチを使用する LAN のシナリオでは、ホスト上で、それぞれのスイッチに接続するリンク集約をまとめて 1 つの IPMP グループにすることができます。この構成では、高いネットワークパフォーマンスと高可用性の両方が得られます。あるスイッチが故障すると、その故障したスイッチへのリンク集約のデータアドレスが、グループ内の残りのリンク集約の間で再分配されます。
リンク集約の詳細については、第 12 章リンク集約の管理を参照してください。
カスタマイズリンク名のサポートにより、リンクの構成が、そのリンクが関連付けられている物理的な NIC に拘束されなくなります。カスタマイズリンク名を使用すると、IP インタフェースを管理する場合の柔軟性が高まります。この柔軟性は IPMP の管理にも及びます。ある IPMP グループのベースとなるインタフェースの 1 つが故障し、交換する必要がある場合に、そのインタフェースを交換する手順が大幅に簡素化されます。交換用の NIC が故障した NIC と同じタイプである場合、その名前を変更して、故障した NIC の構成を継承できます。新しいインタフェースを IPMP グループに追加する前に新しい構成を作成する必要はありません。故障した NIC のリンク名を新しい NIC に割り当てると、故障したインタフェースと同じ設定で新しい NIC が構成されます。その後、マルチパスデーモンは、アクティブインタフェースとスタンバイインタフェースの IPMP 構成に従ってそのインタフェースを配備します。
したがって、ネットワーク構成を最適化し、IPMP の管理を簡素化するには、インタフェースに汎用名を割り当てることで、インタフェースで柔軟なリンク名を採用する必要があります。次の節 「IPMP の動作方法」では、すべての例が、IPMP グループとそのベースとなるインタフェースに柔軟なリンク名を使用しています。カスタマイズリンク名を使用するネットワーク環境で、NIC 交換の背後のプロセスの詳細については、「IPMP と動的再構成」を参照してください。ネットワークスタックの概要やカスタマイズリンク名の使用方法については、「Oracle Solaris のネットワークスタック」を参照してください。
IPMP は、グループが作成されたときのアクティブインタフェースとスタンバイインタフェースの元の数を維持しようとすることによって、ネットワークの可用性を維持します。
グループ内の特定のベースとなる IP インタフェースの可用性を判定するための IPMP 障害検出は、リンクベースまたはプローブベース、あるいはその両方にすることができます。あるベースとなるインタフェースが故障したと IPMP が判定した場合、そのインタフェースは故障としてフラグが付けられ、使用できなくなります。次に、故障したインタフェースに関連付けられていたデータ IP アドレスが、グループ内で機能している別のインタフェースに再分配されます。さらに、使用可能な場合は、スタンバイインタフェースも配備され、アクティブインタフェースの元の数を維持します。
図 14-1 に示すような、3 つのインタフェースを含むアクティブ - スタンバイ構成の IPMP グループ itops0 を考えます。
図 14-1 IPMP アクティブ – スタンバイ構成
グループ itops0 は次のように構成されています。
このグループには、2 つのデータアドレス 192.168.10.10 と 192.168.10.15 が割り当てられています。
ベースとなる 2 つのインタフェースがアクティブインタフェースとして構成され、柔軟なリンク名 net0 と net1 が割り当てられています。
このグループにはスタンバイインタフェースが 1 つ含まれており、これにも柔軟なリンク名 net2 が割り当てられています。
プローブベースの障害検出が使用されるため、アクティブインタフェースとスタンバイインタフェースは次のような検査用アドレスで構成されています。
net0: 192.168.10.30
net1: 192.168.10.32
net2: 192.168.10.34
注 - 図の Active、Offline、Reserve、および Failed の各領域は、ベースとなるインタフェースのステータスを示しているだけであり、物理的な場所を示しているわけではありません。この IPMP 実装内では、インタフェースやアドレスの物理的な移動や IP インタフェースの転送は一切発生しません。これらの領域の役割は、ベースとなるインタフェースのステータスが故障、修復のいずれかの結果としてどのように変化するかを示すことだけです。
さまざまなオプションとともに ipmpstat コマンドを使用して、既存の IPMP グループに関する特定の種類の情報を表示できます。その他の例については、「IPMP 情報の監視」を参照してください。
図 14-1 の IPMP 構成は、次の ipmpstat コマンドを使用して表示できます。
# ipmpstat -g GROUP GROUPNAME STATE FDT INTERFACES itops0 itops0 ok 10.00s net1 net0 (net2)
グループのベースとなるインタフェースに関する情報を表示するには、次のように入力します。
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE net0 yes itops0 ------- up ok ok net1 yes itops0 --mb--- up ok ok net2 no itops0 is----- up ok ok
IPMP は、アクティブインタフェースの元の数を維持できるようにベースとなるインタフェースを管理することで、ネットワークの可用性を維持します。したがって、net0 が故障すると、グループが引き続き 2 つのアクティブインタフェースを持てるように、net2 が配備されます。net2 のアクティブ化を図 14-2 に示します。
図 14-2 IPMP でのインタフェースの故障
注 - 図 14-2 のデータアドレスとアクティブインタフェースとの 1 対 1 のマッピングは、図を単純化するためのものにすぎません。IP カーネルモジュールは、データアドレスとインタフェースとの間の 1 対 1 の関係に必ずしも縛られることなく、データアドレスをランダムに割り当てることができます。
ipmpstat ユーティリティーは、図 14-2 の情報を次のように表示します。
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE net0 no itops0 ------- up failed failed net1 yes itops0 --mb--- up ok ok net2 yes itops0 -s----- up ok ok
net0 が修復されると、アクティブインタフェースとしてのステータスに戻ります。一方、net2 は元のスタンバイステータスに戻されます。
別の故障シナリオを図 14-3 に示します。このシナリオでは、スタンバイインタフェース net が故障し (1)、そのあと、アクティブインタフェースの 1 つである net1 が管理者によってオフラインに切り替えられます (2)。その結果、この IPMP グループには、機能しているインタフェース net0 が 1 つ残されます。
図 14-3 IPMP でのスタンバイインタフェースの故障
ipmpstat ユーティリティーは、図 14-3 に示された情報を次のように表示します。
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE net0 yes itops0 ------- up ok ok net1 no itops0 --mb-d- up ok offline net2 no itops0 is----- up failed failed
この特定の故障では、インタフェースが修復されたあとの回復の動作は異なります。この復元は、修復後の構成と比較した IPMP グループのアクティブインタフェースの元の数に依存します。この回復プロセスを、図 14-4 に視覚的に示します。
図 14-4 IPMP の回復プロセス
図 14-4 で、net2 が修復されると、通常、スタンバイインタフェースとしての元のステータスに戻ります (1)。ところが、この IPMP グループは依然として、アクティブインタフェースの元の数である 2 個を反映していません。なぜなら、net1 が引き続きオフラインのままになっているからです (2)。したがって、IPMP は代わりに net2 をアクティブインタフェースとして配備します (3)。
ipmpstat ユーティリティーは、修復後の IPMP シナリオを次のように表示します。
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE net0 yes itops0 ------- up ok ok net1 no itops0 --mb-d- up ok offline net2 yes itops0 -s----- up ok ok
FAILBACK=no モードも構成されたアクティブインタフェースが故障に関与している場合にも、同様の復元シーケンスが発生します。その場合、故障したアクティブインタフェースが修復されても、自動的にアクティブステータスには戻りません。図 14-2 の net0 が FAILBACK=no モードに構成されているとします。そのモードでは、修復された net0 は、最初はアクティブインタフェースであったとしても、スタンバイインタフェースとしての予約ステータスに切り替えられます。この IPMP グループのアクティブインタフェースの元の数である 2 個を維持するように、インタフェース net2 はアクティブのままになります。ipmpstat ユーティリティーは、次のように回復情報を表示します。
# ipmpstat -i INTERFACE ACTIVE GROUP FLAGS LINK PROBE STATE net0 no itops0 i------ up ok ok net1 yes itops0 --mb--- up ok ok net2 yes itops0 -s----- up ok ok
このタイプの構成の詳細については、「FAILBACK=no モード」を参照してください。
|