z/OS Communications Server のルーティング責任の最小化

OMPROUTE はさまざまな理由から、z/OS® Communications Server 上で実行されます。z/OS Communications Server ホストがアプリケーション・ホストまたはサーバー・ホストとして使用されていて、ルーティング・デーモンが主にネットワーク・リソースへのアクセスまたは z/OS Communications Server ホストへネットワーク・リソースがアクセスするために実行されている場合には、z/OS Communications Server ホストにルーティング作業の負担がかかり過ぎないように注意しなければなりません。ルーティングだけを目的としたルーターや他のネットワーク・ボックスとは異なり、アプリケーション・ホスト z/OS Communications Server は、ルーティング以外にもさまざまな作業を行っています。そのため、非常に複雑なネットワークや不安定なネットワークで起こりがちなように、マシン・リソース (メモリーや CPU) の多くの割合をルーティングの作業に使用するのは望ましくありません。この場合、z/OS Communications Server が意図的にも偶然にもバックボーン・ルーターとして構成されないようにする必要があります。注意深くネットワーク設計をすることによって z/OS Communications Server アプリケーション・ホストのルーティングの負担を最小化し、かつ、z/OS Communications Server リソースからネットワークへの、またその逆の、アクセス可能性の低下を避けることができます。z/OS Communications Server ホストに要求されるルーティング作業の最小化に注意を払わない場合、OMPROUTE はネットワークからの膨大な数のルーティング更新の処理に過度のサイクルまたはメモリーを費やすことがあります。または、ルーティング更新の負担が大きくなりすぎて、マシン上の他のワークロードのために z/OS Communications Server は処理を継続できなくなくなることもあります。OSPF はタイマーによって駆動されている部分が大きいので、このような状態になると隣接関係が失われたり、ルーティングの問題が発生したりすることがあります。

z/OS Communications Server ホストのルーティングの負担を減らす基本的な方法は、OSPF エリアの使用です。詳しくは、ステップ 3 を参照してください。z/OS Communications Server アプリケーション・ホストまたはシスプレックスは、エリア・ボーダー・ルーターとして動作する専用ルーターを持つ非バックボーン・エリアに入れることができます。エリア・ボーダー・ルーターは、z/OS Communications Server のリソースを、接続された他のエリア (例えばバックボーン) に公示し、ローカル・エリアの外部のネットワークを z/OS Communications Server ホストに要約して伝えます。可能ならば、RANGE および IPV6_RANGE ステートメントによって OMPROUTE エリア・ボーダー・ルーターで実行される、またエリア範囲コマンドによって Cisco ルーターで実行されるエリア間経路要約を使用して、ルーティング・プロトコルのトラフィックを減らすよう、これをさらに改善することができます。詳しくは、「z/OS Communications Server: IP 構成解説書」およびステップ 4 を参照してください。

さらに理想的な最適化を行うのであれば、z/OS Communications Server アプリケーション・ホストまたはシスプレックスが入っているエリアをスタブ・エリアにします。スタブ・エリアは、他のエリアからの経路の要約 (IPv4) または接頭部 (IPv6) が、エリア・ボーダー・ルーターによってスタブ・エリア内にフラッディングしないように構成できます。そのようにした場合は、スタブ・エリア内の宛先への経路のみがホスト間で共用されます。デフォルトの経路は、スタブ・エリア外のすべての宛先を表すために使用されます。スタブ・エリアのリソースは、エリア・ボーダー・ルーターによって広くネットワークに公示されます。この最適化 (完全なスタブ・エリアとも呼ばれます) を使用できるのは、ネットワークに以下の条件が当てはまる場合です。

スタブ・エリア外の宛先に到達するためにデフォルト経路を使用することが許容できる。すなわち、スタブ・エリアをネットワークの残りの部分に接続するエリア・ボーダー・ルーターが 1 つだけしかないか、そのような接続が複数ある場合は冗長接続で、どれを使用してスタブ・エリアの外部に到達してもかまわないことを意味します。
ネットワークに広く公示する非 OSPF 宛先がない。スタブ・エリアでは、OSPF 外部経路のインポートは許可されません。すなわち、例えばスタブ・エリアに付加された RIP ネットワークがないか、もしある場合はその宛先をスタブ・エリアから到達可能にしたいと思わないことを意味します。スタブ・エリアにインポートできないその他のタイプの経路には、直接経路 (例えば、OSPF プロトコルを実行していないインターフェースに付加されたネットワークへの経路) および静的経路などがあります。 RIP または静的経路は、それを確認する z/OS Communications Server は使用できますが、公示することはできません。
ヒント: OMPROUTE 構成ファイルで VIPA を OSPF インターフェースとして定義すると、それらのアドレスへの経路は OSPF 経路と見なされ、したがって、スタブ・エリアへのインポートが可能で、エリア・ボーダー・ルーターによってネットワークに広く公示することができます。

z/OS Communications Server アプリケーション・ホストまたはシスプレックスは、可能であればスタブ・エリアに入れることを、強くお勧めします。

さらなる最適化では、この機能を実行できる専用ルーターがある場合、z/OS Communications Server がマルチアクセス・メディアの指定ルーターにならないようにします。マルチアクセスの中間では、指定ルーターおよびバックアップ指定ルーターが、すべての中間のホストのルーティング・プロトコル負荷の大半を担います。z/OS Communications Server はこの役割を行う能力がありますが、システムに追加のルーティング・オーバーヘッドを負わせることになります。可能であれば、専用ルーターにこの役割を行わせることの方が好ましいです。これは、中間の専用ルーターのインターフェースに、同じ中間上の z/OS Communications Server インターフェースよりも高い ROUTER_PRIORITY 値を持たせることにより、可能となります。しかし、HiperSockets™ 通信の場合のように、メディア上のホストが z/OS Communications Server のみであれば、それらの 1 つまたは 2 つが指定ルーターまたはバックアップ指定ルーターでなければなりません。

ヒント: IBM® Health Checker for z/OS を使用して、TCP/IP スタックのルーティング・テーブル内の間接経路の総数が最大しきい値を超えているかどうかチェックできます。このしきい値を超えた場合、OMPROUTE と TCP/IP スタックが経路変更により高 CPU 消費率の状態となる可能性があります。IBM Health Checker for z/OS について詳しくは、「z/OS Communications Server: IP Diagnosis Guide」および「IBM Health Checker for z/OS: ユーザーズ・ガイド」を参照してください。