メル・ベックマン著 AS/400のTCP/IPサポートは、V4R4以来大きく変わってはいませんが、ルータやプリンタなどといったTCP/IP対応の機器はこの間に多くの新機能を追加しています。たとえば、最近のTCP/IP対応機器は共通の現在時刻時計を共有して内蔵の時計を同期させることができます。これはトラブルシューティングの際に複数のTCP/IPエージェントからのログエントリを互いに関係付けるのに重要な機能です。また、TCP/IP対応プリンタにはWebブラウザで管理が可能な内臓式のスプーラがあり、スプール管理の手間をOS/400から完全に分離しています。ルータも新機能をサポートしています。たとえばローカルエリアネットワークの分離や管理を助ける仮想LAN機能などはこの新機能の1つです。これらは、最新のTCP/IP対応機器やサービスを使用することによってiSeriesが得ることのできるの有用な機能のほんの一部で、すでに皆さんのネットワーク上で稼動していることでしょう。 OS/400ネイティブではない一般的なTCP/IP機能の利用方法を学ぶことにより、iSeriesの新たな役割を見つけてその適用範囲を広げることができます。ここで述べるTCP/IP利用に関する多くの情報は、皆さんをTCP/IP機能の金鉱にご案内するものです。 時刻の砂金探し まずは簡単でしかも魅力的な機能である時刻同期機能から紹介しましょう。長年、iSeriesユーザにとって、OS/400の時計とカレンダー制御に関するIBMのサポートが不十分であったことは頭痛の種でした。iSeriesの時計は週単位、月単位で大幅に狂うだけでなく、その狂い方がまちまちであるため、iSeriesマシンをネットワーク上で複数台使用している場合はマシンごとの時計が結果として同期しなくなってしまいます。CLプログラミングをなんとか駆使してiSeriesボックス同士で時刻に関しておおよその同期が取れるようにしたとしても、ネットワーク上に無数にある他の機器との同期は依然として取れません。このような状況では、異なる装置が記録したログ上のイベント発生時刻の差が鍵となるようなトラブルシューティングが複雑なものとなり、Kerberosなどの特定の認証サービスなど一部のプロトコルに支障をきたすこともあります。 インターネット標準プロトコルであるSNTP(Simple Network Time Protocol)というプロトコルがこの種の問題を少しでも解決するために既に存在しています。V5R1の新規サービス一覧にSNTPのサポートがあるのを見て、iSeriesのユーザは大いに喜びました。SNTPの使用はとても簡単です。まず、QUTCOFFSETというシステム値にタイムゾーンのオフセットを、ローカル時刻と協定世界時との差として(WRKSYSVAL SYSVAL(QUTCOFFSET)コマンドを使用して)設定します。たとえば太平洋標準時の場合、QUTCOFFSETの値を08:00に設定しなければなりません。 次に、以下のコマンドを使ってSNTPクライアントを構成します。 CHGNTPA RMTSS('＜ip address of NTP server＞') AUTOSTART(*YES) POLLITV(60) MINADJ(100) MAXADJ(20) ACTLOG(*NONE) GUIを使って構成したい場合は、オペレーションナビゲータ(OpsNav)もSNTPの構成および管理をサポートしています。 適切な時刻サーバーのIPアドレスはhttp://www.eecis.udel.edu/~mills/ntp/servers.htm (英文サイト)から取得します。いずれにしろ、米国海軍天文台の公式ネットワーク時刻サーバーは使用しないでください。このサーバーは過負荷になりすぎています。このサーバーの代わりに、地理的に近い公開時刻サーバーを選択して、ネットワーク上の1〜2台のホストだけがその時刻サーバーを参照するようにしてください。時刻同期を必要とするネットワーク上の他の装置については、PCまたはネットワークルータ上にNTPサーバーを設置します。 最後に、(OS/400下でサーバーとして稼動する)NTPクライアントはIPLを自動起動するように上記で設定しましたが、iSeriesマシンを再IPL起動しないのであれば、次のコマンドでサーバーマシンを最初に起動する必要があります。 STRTCPSVR *NTP システム時計と実際の正しい時刻との誤差がMAXADJ分以内である限り、OS/400のSNTPクライアントは時刻を調整します。残念なことに、OS/400のSNTPクライアントは若干洗練されていない部分があり、必要な仕事の半分しかこなしてくれません。たしかにV5R1のSNTPサポートは1つのOS/400の時計で公開時刻サーバーと同期を取ることができます。しかし、この「1つの」というところが曲者なのです。OS/400には2つの現在時刻時計があってSNTPはそのうちの1つだけを同期させるのです。 OS/400はマシンクロックを管理しています。この時計はQTIMEシステム値で表され、OS/400のコマンドやHLLプログラムが使用します。これとは別にソフトウェアクロックも管理していて、ネットワーク認証サービスなどの中で使用されているpthread_cond_timedwait() APIなどといったPOSIXベースのサービスだけが使用します。 IBMはこの問題に対する解をまだ提示できていませんが、幸いなことに、OS/400開発の独創的なサードパーティがその解を持っています。エクスポートベンチャー社(http://www.export-ventures.com)（英文サイト）はIBMロチェスター研究所にいたプログラマ達が幹部におり、OS/400のマシンクロックをSNTPサーバーと完全に同期させるMSNTP/400という製品を100ドルで提供しています。さらに嬉しいことに、MSNTP/400はOS/400のV5だけでなくV4でもSNTPが利用できるようにしてくれるのです。 時刻の同期はネットワーク上に今すぐにでも導入を検討すべき簡単でしかも強力なTCP/IP機能の一例です。もう一つの例はもっと複雑なサービスであるプリンタ機能ですが、得られる恩恵もそれなりに大きいものです。 プリントサービスの採掘 今日のプリンタは今までになく高機能になっており、ホストベースの立派なプリントサーバーと肩を並べるほどにまでなっています。TCP/IPは事実上すべてのネットワークプリンタの標準インタフェースになっていて、多くのプリンタがスプーリング、ジョブスケジューリング、分散レンダリング、Webブラウザを使用した管理などといった先進の機能を備えています。これに比べると、OS/400のWRKOUTQコマンドはまことに貧弱です。 TCP/IP経由での印刷に関する問題の1つに、OS/400からリモートプリンタに印刷ジョブが一旦送られてしまうとOS/400とリモートプリンタが切断されてしまうという問題があります。OS/400から印刷ジョブの停止、再開、キャンセルを行おうとすると問題が発生します。解決方法の1つはOS/400からプリンタを制御することをあきらめることです。その代わりにリモートプリントサーバー固有の機能を利用するのです。 図1 は典型的なTCP/IPプリンタインタフェースのWebブラウザを使用した管理機能の画面ショットです。これなら社内ユーザにトレーニングをしても十分受け入れられるユーザーインタフェースだと思いませんか。OS/400の緑色の画面上でコマンドやOpsNavを使ってプリンタの制御を管理しようとするよりも、Webブラウザを使用した管理が可能なプリンタ管理機能にユーザが直接アクセスできるようにしてはいかがでしょうか。プリンタの出力に対する制御が今まで以上にできればユーザも喜びますし、そうすればiSeriesボックスのCPUサイクルを使用するタスクが1つ少なくなります。 ユーザに対してアプリケーション「ポータル」のWebページを提供しているのであれば、そのポータルページからリンクを貼ることでTCP/IPプリンタへのアクセスを簡単にポータルページに統合することができます。また、印刷ジョブがプリンタに対して送信されたときにジョブを要求したユーザに対して印刷ジョブのURLを電子メールで送信し、ユーザに出力先を確認させたり印刷プロセスを制御させたりすることができます。 VLANの金塊 OS/400はTCP/IPに関連しない機能にCPUサイクルをつぎ込んできましたが、OS/400の外の世界では仮想LANあるいはVLANと呼ばれるイーサネットLAN上のTCP/IPに対して主な強化を行っていました。VLANは純粋にローカルなものですから、インターネット上で動作する仮想プライベートネットワークであるVPNとは混同しないでください。 VLANでは、ローカルネットワーク上で広範囲に分布しているユーザを、まるで同じ1つの部屋の中の専用のプライベートなイーサネットセグメント上にいるような、セキュアなプライベート領域にグループ化することができます。たとえば、3階にいるフレッドと2階にいるボブとメアリーと、隣のビルにいるドナを一つの会計部門VLAN上に統合して、彼らの間でやりとりされるトラフィックが(たとえば営業部門などといった)他のユーザのトラフィックと、たとえ同じイーサネットスイッチ上に接続されていたとしても、混合されないようにすることができます。 VLANの利点は、セキュリティあるいは性能管理の目的から、関連するユーザを1つの論理グループとして扱うことができるということです。会計部門VLANに対して特定のTCP/IPプリンタなどの一定のサービスへのアクセス権を与え、営業部門VLANのユーザには与えないといったことができます。一方、営業部門LANに対するネットワークトラフィックに優先権を与えて、営業部門のユーザがネットワークの混雑によって身動きが取れなくなることを防ぐこともできます。 VLAN標準は802.1Qプロトコルで定義されていて、OS/400はこれを直接サポートしていませんが、制御用ルータを複数のVLAN対応のイーサネットスイッチからのトラフィックを監視する交通整理役として使用します(図2)。各VLANには一意の番号があり、定義された1つのイーサネットネットワークは数千のVLANをサポートすることができます。VLAN識別番号は必ずしも連続していなくても構いません。 VLANは、AppleTalk、NetBIOSなどといったTCP/IP以外のプロトコルとも使用できますが、その最大の機能メリットを利用できるのはTCP/IPを使用したVLANを導入したときです。各VLANは個別のIPサブネットであり、制御用ルータはIPサブネットを特定のVLANに関連付け、VLAN対応スイッチはイーサネットのポートを特定のVLANに関連付けます。 IP VLANを構成する一般的な例では、VLAN番号をIPサブネットアドレスに組み入れます。図2では、IPサブネット10.1.23.0がVLAN番号23用のクラスC(または/24)ネットワーク、10.1.45.0がVLAN番号45用のサブネットといった具合になっています。通常は、貴重なパブリックIPアドレスを無駄使いしないためとIP/VLANの対応を取るために、プライベートIPアドレスを使用してVLANを設定します。 図3はVLANの動作を示しています。会計部門VLAN(VLAN番号23)上のメアリーからきたプリンタVLAN(VLAN番号99)行きのパケットはまずVLANルータを通過します。一般的な規則として、IPパケットがIPサブネット間で移動する際は常にルータを通過しなければなりません。802.1Q標準では、ルータはVLANコミュニティ内の各イーサネットスイッチと通信してどのIPアドレスが各スイッチに属しているのかを知り、この情報をVLANアドレス解決プロトコル(ARP)テーブル中に格納します。 ルータはメアリーからのパケットを受信し、IPアドレス10.1.99.5(プリンタVLAN上のメアリーのプリンタ)行きであることを確認し、VLAN ARPテーブルに問い合わせて、該当するIPが現在スイッチ4上にあることを知ります。ルータはパケットをスイッチ4に直接送信し、スイッチ4はメアリーのプリンタが割り当てられているポート9にそのパケットを転送します。 営業部門のウォルターが同じプリンタに対してデータを送信しようとすると、ウォルターとプリンタが同じ物理LAN上にあって同じイーサネットスイッチに接続されていたとしても、VLANルータ内の規則によりこのアクセスが禁止されます。セキュリティポリシーの他にも、VLANルータはサービス品質の規則を適用して特定のトラフィックに優先権を与えることもできます。 またVLANルータはプロトコル間ベースで各VLANが利用できる帯域幅の絶対値を制御することもできます。たとえば、特定のVLANに対しては無制限のHTTPアクセスを許可する一方で、通常の勤務時間帯はFTP転送を256Kbpsまでに制限したいなどといった場合です。ほとんどのVLANルータはこういった複雑な帯域幅制御機能をサポートしています。実際、VLANルータやVLANスイッチは一般的にWebブラウザを使用した使い勝手の良い管理機能をもっていて、VLAN対応機器ネットワーク全体を同じWebページから簡単に管理することができます(図4)。 DHCPの金脈 VLANが提供する高度なネットワーク管理は簡単に見えますが、その元になっているIPアドレス空間は複雑です。VLAN上の各ユーザにはVLANサブネットのスコープ内におけるIPアドレスが割り当てられていなければならず、ユーザは正しいサブネットマスクとIPデフォルトゲートウェイを構成しなければなりません。 通常は、動的ホスト構成プロトコル(DHCP)サーバーを使用してIPアドレスをエンドユーザーに自動的に配布することができます。ただし、DHCPのブロードキャストは通常特定のIPサブネット内、つまり今回の場合1つのVLAN内にしか行き渡りません。DHCPクライアントは、IPアドレスが欲しいときにDISCOVERパケットをブロードキャストします。しかし、このクライアントはVLAN番号を知らないので、動的に割り当てられたIPアドレスを取得する先のIPサブネットを知ることができません。OS/400のDHCPサーバーは複数のサブネットに対してIPアドレスを割り当てることができますが、通常はiSeriesマシンが各サブネットに物理的に接続されている場合に限ります。 最近のTCP/IPルータの機能の1つにDHCPリレーという機能があり、これが問題を解決してくれます。DHCPリレーでは、各VLANをサポートしているDHCPサーバーのIPアドレスをVLANルータに知らせます。「ヘルパーアドレス」と呼ばれる設定により、特定のVLAN上のユーザからのDHCPリクエストをルータがリモートのDHCPサーバーに転送します。 図5にこのプロセスを図示します。会計部門LAN上のドナというユーザがコンピュータの電源を入れると、そのコンピュータがDISCOVERパケットをブロードキャストしてアドレスを割り当ててくれるDHCPサーバーの位置を確認します。VLANルータはDISCOVERパケットを確認し、DHCPヘルパーに対して会計部門VLANのアドレスが10.1.55.9であることを通知します。ルータはドナのDISCOVERパケットに、ドナのコンピュータが10.1.23.0ネットワーク上のサブネット255.255.255.0およびゲートウェイアドレス10.1.23.1にあることを付加して、10.1.55.9にあるOS/400のDHCPサーバーに引き渡します。OS/400のDHCPサーバーはルータに対して、メアリーのコンピュータに対して割り当てられたIPアドレスとサブネットマスクおよびゲートウェイ情報をDHCP応答として返します。またDHCP応答にはメアリーのコンピュータの構成に対するDNSサーバーが指定されている場合もあります。 このシナリオの場合、OS/400のDHCPサーバーは複数のDHCP配布ポリシー用に各VLANサブネットに対して1つのポリシーが構成されていなければなりません。各サブネットに対してサブネットマスクとゲートウェイIPアドレスを手操作で構成しなければなりませんが、これは1度だけ行えばよいものです。 富める者の悩み SNTP、TCP/IP印刷機能、仮想LAN、マルチサブネットDHCPなどはiSeriesが既存のネットワーク上で利用できる強力なTCP/IP機能のほんの一部に過ぎません。今回ご紹介したテクニックを実際に実装してみたら、さらに大きな金鉱を掘り当てるべくTCP/IPの金山に戻ってきてください。 メル・ベックマン氏はiSeries News誌のシニアテクニカルエディタです。
