チャネル インターフェイス プロセッサおよびチャネル ポート アダプタは、IBM(およびプラグ互換性がある)メインフレームへのネットワーク接続に広く使用されており、TN3270 変換および TCP/IP オフロードなどのサービスを提供します。シスコではこれらの製品の販売終了を発表しているため、この機器を所有しているユーザは代替ソリューションの計画を始める場合があります。このドキュメントは、そのためのガイダンスです。
まず、重要となるのは、慌てて変更する必要はないという点です。CIP および CPA の機能の代わりとして使用できるオプションを検討し、実際の環境に最適な移行戦略を進めていく時間は十分にあります。これらの機器は、何千もの顧客環境でテストされてきた完成度の高い製品です。多様なバリエーションがあり、現在も実稼働ネットワークで数百万のエンド ユーザを支えています。機器のサポートは 2011 年まで継続されます。ほとんどのお客様は、シスコがメインフレーム チャネル製品のサービスを終了するかどうかに関係なく、他の要因によりメインフレーム データセンター ネットワークの変更を計画していると予想されます。
過去 10 年間で、メインフレーム ネットワーキングの設計の方向性は大きく変化しました。IBM メインフレームのプラグ互換機ベンダーは姿を消し、メインフレームの物理的なネットワーク接続に、単一のアプローチで取り組むことが可能になっています。従来は SNA サブエリア テクノロジーが重要視されていましたが、HPR SNA が優勢となり、特に HPR/IP やブランチ ネットワーク ノードの機能活用に重点が置かれるようになりました。同時に IBM もメインフレームのネットワーキング アプローチを大きく変化さえました。メインフレームは企業内で重要な役割を担うために高度なアベイラビリティを提供してきましたが、これと同じレベルのアベイラビリティをオープン システム モデルで維持しようとしています。QDIO モードで動作する、IP パケット処理に最適化された Ethernet Open Systems Adapter(OSA)を使用すれば、ESCON チャネルよりも効率的にネットワークからメインフレームへとデータを移動できます。これをさらに、仮想 IP アドレス(VIPA)、ダイナミック ルーティング プロトコル、QoS の機能と組み合わせることで、アベイラビリティとパフォーマンスに優れた IP ネットワーキングを実現する包括的な基盤が確立されます。
ほとんどの場合、CIP および CPA から OSA に移行する新しい設計には、強力なルーティング プロトコルと再配布のサポート、そして多様なサービス モジュールのサポート機能を備えた Catalyst 6000 など、インテリジェントなレイヤ 3 スイッチが含まれています。
ここでは、CIP および CPA 製品の IP データグラム ルーティング機能について説明します。
メインフレームへの IP パケットのルーティングは、Cisco CIP で実装された最初の機能です。そして、シスコの CLAW チャネル プロトコルと CMPC+ チャネル プロトコルは、CIP および CIA に実装された最初と最後のチャネル プロトコルです。これらのプロトコルは、置き換えるのが最も簡単な機能です。IP ルーティング機能は、すべての Cisco ルータおよびレイヤ 3 スイッチがサポートしているうえに、IP はその特質として物理メディアから独立したものと考えられるからです。
上の図に示されているとおり、データセンターの集約レイヤに OSA インターフェイスを直接接続すれば、データセンターの設計はシンプルになる可能性があります。いずれのシナリオでも、アベイラビリティを最大限確保するには、メインフレームに直接接続されたスイッチまたはルータでダイナミック ルーティング プロトコルを稼働させる必要があります。この 2 つの大きな違いは、IP ルート集約は集約レイヤ スイッチの主要な機能であり、ワイヤ レートでのレイヤ 3 スイッチングを実行するように設計されていて、IP ルート再配布の制御ポイントとして機能するという点です。
この新しい設計では、メンテナンスおよび運用のコスト要因となる機器や、遅延の拡大を招いたり、障害点となったりする可能性のある機器が排除されます。
OSA インターフェイスが 100 Mb イーサネットの一種であり、QDIO モードで動作するように設定されていれば、このインターフェイスは、IP データグラムに関して、最適な構成(CMPC+ または CLAW PACKED)の CIP または CPA と同様、あるいは若干優れたスループット(ポート単位)を提供するはずです。また、1000 Gb イーサネットについては、OSA 設計を使用すれば大幅にパフォーマンスが向上する可能性があることは明らかです。
ここでは、CIP および CPA 製品の Cisco SNA 機能について説明します。
CSNA 機能は、メインフレーム チャネルによる LLC SNA トラフィックのブリッジングを提供します。SNA トラフィックを CSNA が処理する方法はさまざまであるため、一般的にソリューション全体は IP ルーティングよりも複雑になります。つまり、SNA マシンが接続されたローカル LAN、リモート ロケーションから SNA トラフィックを配信する DLSw+、APPN を使用して SNA トラフィックをルーティングする SNA スイッチング サービス(SNASw)を、何らかの方法で組み合わせている場合が考えられます。CSNA が稼働している CIP および CPA は、ネットワーク内にわずかに残されているトークンリング テクノロジーの配置場所である可能性も高く、その場合、CSNA からの移行にはトークンリングからイーサネットへの移行も含まれることになります。
SNA 用の CIP または CPA 環境には、次の要素が含まれている可能性があります。
ブランチ ルータで SNASw を使用する、最適な変換
最もシンプルで包括的なソリューションは、SNASw ルータに接続して、既存のレイヤ 2 SNA トラフィックを変換し、レイヤ 3 で IP を使用するようにすることです。これを、レイヤ 2 SNA マシンの近接ポイントで実行すると、レイヤ 2 SNA ドメインが LAN の小さなセグメントに制限されるので、DLSw を使用して WAN つまり LAN 間でこのトラフィックをブリッジングする必要がなくなります。
ブランチ ルータで DLSw+ を使用する、SNASw の変換
リモート ルータに SNASw をインストールできない場合の代替ソリューションとして、DLSw+ により SNA トラフィックをデータセンターへ伝送し、これを SNASw に渡して EE に変換する方法があります。この方法では、データセンター内にレイヤ 2 SNA トラフィックが残りますが、同じルータに DLSw+ と SNASw の機能が両方あれば、レイヤ 2 SNA が存在するのはそのルータ内の接続上だけになります。WAN から来るトラフィックとメインフレームに向かうトラフィックは IP になります。
アクセス レイヤを通じて LCS モードの OSA に LLC SNA をブリッジング
SNA デバイスとメインフレームの間のレイヤ 2 直接接続が必要であり、IP ベースの OSA-E は使いにくいという場合もあります。たとえば、ローカル SNA マシンしかなく、これらのマシンからメインフレームへの接続に、かなり大きな帯域幅が必要とされる場合などです。また、SNASw を通じて伝送し、EE トラフィックに変換することが不可能なトラフィックが、サブエリア ホスト内に含まれている場合も同様です。特に、OSA を通じて Communication Controller for Linux(CCL)ベースの NCP に送信される SNI またはその他のトラフィックは、明らかにこれに該当します。LLC/SNA、または CDLC for CCL の処理が設定されている OSA インターフェイスの設定および管理については、該当する IBM のドキュメントを参照してください。最大限のパフォーマンスと制御機能を得るためには、これらの SNA マシンすべてを 1 ヵ所に置くか、またはデータセンター ネットワークのアクセス レイヤ内に少数のレイヤ 2 クラスタを配置します。トークン リングで接続されているデバイス固有の問題もあります。すべてのデータセンター インフラストラクチャがトークンリング接続をサポートしているとは限らず、ほとんどの場合、今からトークン リング用のスイッチを追加することは妥当ではないためです。このため、トークンリング デバイスを直接ブランチ ルータに接続し、そのルータで変換ブリッジングを実行することを推奨します。イーサネット環境では、2 通りの方法で冗長構成による可能性を提供できます。まず、SNA デバイスがネットワークに接続するポイントで、1 つの LAN に重複したイーサネット MAC アドレスを使用し、一方のアドレスは HSRP が必要になるまで使用されないようにする方法です。もう 1 つは、接続のホスト エンドで重複したイーサネット MAC アドレスを使用する方法です。これらのアドレスが別々の LAN に属するようにして、何らかの形式のスパニング ツリーを使用し、これらが共通の LAN に含まれないようにします。
ここでは、CIP および CPA 製品の TN3270 サーバ プロトコル機能について説明します。
TN3270 サーバは、同時に数千もの 3270 セッションを高い信頼性で提供できる産業用の強力なサーバです。ネットワーク インフラストラクチャで重要な役割を果たし、設計の柔軟性によって高度なアベイラビリティを実現します。
同様の拡張性とアベイラビリティを確保する唯一の方法として、TN3270 サーバの機能を直接メインフレーム上に配置することを推奨します。これにより信頼性の高い環境が確立され、メインフレームで複数のインターフェイスとダイナミック ルーティングを使用することで、ネットワーク アベイラビリティも維持されます。また、この方法では、SNA 自体とそれを TN3270 に変換することで発生する複雑さの多くが 1 ヵ所に集まるので、これらを管理する機能を用意しやすいという利点もあります。IBM は、メインフレーム ベースの TN3270 サーバ プログラムを 2 種類提供しています。1 つは Communication Server(CS)for z/OS で、これは z/OS ソフトウェアに含まれています。もう 1 つは Communications Server for Linux の一部です。
ここでは、CIP および CPA 製品の TCP/IP オフロード機能について説明します。
TCP/IP オフロードは、メインフレーム チャネルを通じて IP データグラムで伝送される、ペイロード データを軽減する手段の 1 つです。オフロード デバイスで TCP/IP プロトコルの日常業務の一部を処理することが目的で、これによりメインフレームで実行しなければならない作業が減少します。TCP/IP オフロードはかつて広く使用されていましたが、メインフレームの TCP/IP 処理効率の向上によって、これを使用する理由はほとんどなくなりました。
IBM TCP/IP プログラムを使用する MVS システムの場合、TCP/IP オフロードのサポートは MVS バージョン 2.4 で終了するので、TCP/IP オフロードからの移行はすでに決定されているはずです。
一部のお客様は、CA の Unicenter TCPaccess Communications Server 製品を使用して TCP/IP オフロードを活用しています。この構成が最適なパフォーマンス モデルだった時代もありました。この製品は、X.25 over TCP(XOT)によって X.25 ネットワークへの TCP アクセスを提供するソリューションに含まれている場合もあります。 最も簡単な移行方法は、おそらく TCP/IP オフロード機能を使用する部分だけを変更して、代わりに OSA-Express アダプタを使用することです。Unicenter TCPaccess Communications Server の他の機能を使用している場合は、それらの機能に影響が生じないという利点もあります。また、より積極的なアプローチも使用できます。IP データグラム アクセスを変更して IBM が提供するスタックの使用を検討します。XOT 機能が使用されている場合は、CCL ベース NCP に対する NPSI API インターフェイスを通じて、これらを有効にできるかどうかを調べます。
TPF オペレーティング システムは、2000 年以降、フル TCP スタック、OSA-Express、および VIPA を提供してきました。これが最初に実現されたのは、TPF バージョン 4.1 PUT 13 の PJ27333 です。IBM によると、このモデルによってパフォーマンスとリソースの利用が大きく向上したとのことです。TPF サービス モデルでは、お客様は TCP/IP オフロードを引き続き使用できます。しかし、TCP/IP ネイティブ スタック サポートに移行する利点と簡便さは TRF のお客様にとって魅力的であるため、TCP/IP オフロードのサポート終了前に、お客様はこのモデルへの変更を望まれると考えられます。
現在配置されている CIP および CPA は、今後数年間は有効な接続手段であり続け、TN3270 サーバ ソリューションとして利用することができます。その後も、ある程度の CIP および CPA が在庫を修正して提供される見込みです。現在 CIP と CPA が提供している機能には、それぞれ実際的な代替ソリューションが存在します。このため、現在 CIP および CIA のどのような機能を、どの程度利用しているのかを、最初に明らかにする必要があります。これに基づいて計画を策定し、高いアベイラビリティとメインフレームへの高速アクセスを提供できる、堅牢かつ高速なインテリジェント レイヤ 3 スイッチ インフラストラクチャへの移行を今後数年間のうちに実現してください。