IBM i 上の仮想IPアドレス(VIPA)ゾーン
仮想IPアドレスをハイ・アベイラビリティー、ディザスター・リカバリー、ロード・バランシングなどに活用
これから別次元の旅をすることになります。その別次元とは、見た目と中身が異なる世界です。アドレスとインタフェースに関する次元の話です。道しるべがありますからそれに従って進んでください。VIPAゾーンへ・・・
このちょっと滑稽な導入部分についてはロッド・サーリング氏(アメリカの脚本家。テレビドラマを中心に活躍。代表作はテレビシリーズ「トワイライト・ゾーン」。)にお詫びしなければならないかもしれませんが、興味深くそして役に立つIBM i OSのテクノロジー(IBMのAIXやz/OSにも実装されています)の探検に皆さんをお連れしたいと思います。このテクノロジーは仮想IPアドレス(VIPA)と呼ばれ、単一の物理インタフェース(たとえばイーサネット・カードやNICなど)には紐付かないIPアドレスを割り当てるというものです。実際のところ、このアドレスは単一の物理マシンへさえも紐付けられている必要がなく、ハイ・アベイラビリティーやディザスター・リカバリー(HA/DR)のシナリオにとっては理想的なアドレスです。耐障害性、送信ロード・バランス、あるマシンから別のマシンへのフェイル・オーバーをユーザーから見えない状態で行うなどの機能を提供できるからです。VIPAが提供する利点がわかったところで、皆さんは、VIPAゾーンへ一歩踏み入れVIPAとは何なのかを正しく理解し、どのように設定できるのかについて学習しなければなりません。
まず、「VIPA」の発音についてコツをお教えします。VIPAの概念はほとんどの人にとって新しいものでしょうから、他の人と異なった発音をすることで混乱を招くことは避けたいものです。私の経験では、VIPAの「i」の発音は短い「i」(トーク・ショーの司会をしているケリー・リパの姓のような音)ではなく、長い「i」で発音します。ボストンの地元の人が「バイパー」(毒まむし：レッドソックスの帽子に描かれている蛇と覚えておけば忘れないでしょう)と発音するのと同じと考えてください。
VIPAの説明： VIPAとは何か、何が良いのか
そもそもVIPAとは正確に言うと何者なのでしょう。IBM ｉ以外の世界では特に、あるコンピュータがネットワーク上で一つのＩＰアドレスを割り当てられている状態を思い浮かべる人がほとんどのようです。もちろん、IBM iは多数の同時インタフェースをサポートしています(アダプタを装着できる限りはいくつでも、そしてそれ以外に仮想イーサネットや仮想OptiConnectも)。実際、一台のIBM iシステムを複数のネットワーク上に同時に接続させることもまったくもって可能なのです。このような状況は複数の企業が合併し、IBM iサーバー上の同じアプリケーションにそれぞれ別のネットワークからアクセスする場合に目にするかもしれません。そのようなシステム上の各インタフェースは、それぞれが存在する側のネットワークに固有なIPアドレスを持っています。VIPAはこの概念をさらに一歩進め、依然としてインタフェースを使用するけれども、そのインタフェースに必ずしも割り当てられるとは限らないIPアドレスを使用できるようにしたものです。実際、任意の時点において、複数のインタフェースのうちの一つを使用しているかもしれないのです。このアプローチにはいくつかの利点があります。
冗長性とフェイル・オーバー
まず、VIPAは冗長性のレイヤーを増やすことができます。VIPAに関連付けられた物理インタフェースの一つが故障すると別の物理インタフェースがテイクオーバーします。このフェイル・オーバーはインタフェースにつながっているクライアントにはわかりません。なぜならクライアントが使用しているIPアドレスは変わらないからです。後述しますが、このアプローチはあるサーバーから別のサーバーへシームレスな移行へ拡張することもできます。たとえサーバーがそれぞれ別のサブネットに存在していたとしても可能です。
ですからユーザーが実運用のシステムをターゲットにしていて、その後別のネットワーク上の別の位置にあるディザスター・リカバリー・システムへ移行することも可能です。IBM iにおけるIBMのクラスタリングの実装では、このような移行が自動的に行われるように設定することが可能です。クラスタリング自体は本稿の範囲外ですが、クラスタリングを使用していなくても、VIPAを一台のサーバーから別のサーバーに手動でフェイル・オーバーさせることが可能です。実際には、切り替え中にタイムアウトが発生するかもしれませんが、これにうまく対処するTCP/IPアプリケーションが多いようです。切断されてしまう場合もありますが、重要なのは再接続した時にターゲットのIPアドレスを変更することなく、またDNSエントリの変更を伝える必要もなく新しいサーバーに接続されるということです。
もちろんディザスター・リカバリー・サーバー上で稼働しているアプリケーションは、今まで実運用システムに接続されていたユーザーに対して準備が整っていなければなりません。データの同期がとれていなければ困ったことになります。そうした状況をうまく処理するハイ・アベイラビリティー/ディザスターリカバリー・アプリケーションがいくつかありますが、それも本稿の範囲外となります。前述しました通り、IBM i上で利用できるクラスタリング・サービスに注目すべきです。クラスタリング対応のアプリケーションを使用すれば、実運用システムからディザスター・リカバリー・システムへの切り替えはユーザーには全く見えません。本稿で説明するVIPAテクノロジーは、クラスタリングを利用した自動フェイル・オーバーに役立ちます。
ロード・バランシング
冗長性とフェイル・オーバーの他にも、VIPAは物理インタフェース周辺の使用を拡張してくれます。VIPA自体は受信トラフィックのロード・バランスを取ることはできませんが、外部のロード・バランス対応デバイスと協調することは可能です。こうしたデバイスは受信トラフィックをVIPAに関連付けられた物理インタフェースにラウンド・ロビン方式で割り当てることができます。
VIPAはどちらかというと「外向き」のものと考えることができますが、後述する通り、送信パケットを複数のインタフェース上に拡散させることができるような関連する構成についても説明します。この機能は、特定の物理インタフェースのトラフィックがNICを飽和状態にする恐れがあるような場合に特に有効です。このような状況に至らしめる主たる犯人は、リモート・ジャーナル機能等といった帯域の広いアプリケーションです。
シームレスなサーバーの移行
VIPAのもう一つの利用方法は、二つの異なるプライベート・ネットワークに対して一つのIPアドレスでサーバーを認識させることができるというものです。この設定は、前述の会社合併時等のような状況で有益で、特に合併した各企業がお互いにオーバーラップするようなプライベート・アドレスを有する場合にはさらに有益です。こうした場合は、ネットワーク・アドレス変換(NAT: Network Address Translation)によってネットワークを結合し、IPアドレスの重複を回避する場合が多いです。通常、その目標とするところは一つのアドレス空間にデバイスのアドレスを再割り当てすることで、時間がかかるのが常です。その一時的な期間に、両ネットワーク上のデバイスは同じサーバーをターゲットとする必要がある場合があります。VIPAを使用すると、両方のネットワークに有効なアドレスを導入することでこれが可能になります。このようにネットワークが完全に統合される時、マシンとDNSエントリを変更する必要はなく、サーバーに対する新しいアドレスを反映させることができます。ただしこのアプローチには注意すべき点がありますが、それについては後述します。
VIPAの作成
上記のいずれのシナリオにおいても、最初のステップはVIPAを作成することです。VIPAの作成自体は容易ですが、VIPAをネットワークに認識させる方法を選択するのは計画的に行う必要があります。環境内にある、関連するすべてのネットワーク上にVIPAへのルートを手動で作成することも可能ですが、最善の方法はVIPAに自分自身をネットワークに対して通知させる方法で、これにより構成に必要な作業量を最小化することができます。これについては基本的な方法が二つあり、共に利点と欠点があります。プロキシ・アドレス解決プロトコル(ARP: Address Resolution Protocol)は、VIPAへのリクエストに対して物理インタフェースに応えさせます(「私がスパルタカスだ」と叫ぶ方法だと考えてください)。もう一つはルーティング情報プロトコル・バージョン2(RIPv2)で、サーバー上で稼働しているジョブがVIPAへのルートを送出します。
このアプローチについてもう少し詳しく説明する前に、VIPAを作成する簡単なステップについて説明しましょう。本稿ではIPv4が実装されている環境に焦点を当てている点に注意してください。IPv4は業界標準であり、ほとんどの人が良くご存じでしょう。この機能の一部はIPv6用としてIBM i 6.1で導入されており、詳細はIBMインフォメーション・センターに掲載されています。
VIPAを作成するもっとも簡単な方法は図―1に示す通りSystem i Navigatorを使用する方法です。[システム]-[ネットワーク]-[TCP/IP設定]-［IPv4］とメニューを選択してください。[インタフェース]を右クリックし、[新規のインタフェース]-[仮想IP]を選択してください。
前述のメニュー選択をすると、新しいIPv4インタフェース・ウィザードが開きます。図―2および図―3にこのウィザードを示します。VIPAは独自のネットワーク上にありますから、サブネット・マスクは255.255.255.255でなければなりません。これについては後でもう一度触れます。
VIPAは図―4に示すように緑色画面からADDTCPIFCコマンドを使用して作成することもできますが、Navigatorを使用した方が複数の関連したインタフェースを処理できるという利点があるので、プロキシARPを使用する場合は有用です。プロキシARPを使用する場合は、少なくとも一つの物理IPインタフェースを指定しなければなりません。RIPv2を使用する場合は、関連するインタフェースを割り当てたくない場合がほとんどでしょう。最大送信ユニット(MTU: Maximum Transmission Unit)値(図―4にあります)はあまり重要ではないという点に注意してください。VIPA自身は物理インタフェースを持ちませんので、現在関連付けられているインタフェースのMTUを使用します。実際は、使用できる物理インタフェースのいずれかの最大値と同じ値をMTU値とするのが最善ですが、本当にそんなに重要ではありません。
選択肢：プロキシARPかRIPv2か
プロキシARPを使用するのかRIPv2を使用するのかの決断をするためには、TCP/IPのルーティングについての基礎的な理解が必要です。TCP/IPネットワークはサブネットに分かれており、一緒になって連続するアドレスのグループを構成しています。これは192.168.1.0とサブネット・マスク255.255.255.0 (別の書き方をすると192.168.1.0/24となります)のように、254個のホストIPアドレスしか持たないような小さなサブネットの場合もありますし、10.0.0.0とサブネット・マスク255.0.0.0 (10.0.0.0/8)のように、16,777,214個のホストを持つ(実際にはこのようなクラスAのネットワークは多数のサブネットに分割されます)ような大規模なサブネットもあります。
こうしたサブネットはすべて、通常はルーターで結合されます。ルーターはサブネット上のすべてのデバイスをそのMACアドレスで認識しています。MACアドレスとは、物理カードのメーカーによってカードに焼きこまれたアドレスです。これを上書きすることもできますが、肝心なのは物理的なNICのユニークな識別子であるということです。ルーターはサブネットを順々に他のルーターに通知します。
プロセス全体は以下のようになります(もちろんかなり簡略化しています)。たとえばPower Systemsインタフェースの一つにパブリック・アドレスとして1.1.1.1が与えられたとしましょう(このアドレスは実際には絶対に使用しないでください)。これをブラウザに入力する場合もあります(あるいは入力した名前からそのアドレスに案内されDNSサーバーがアドレスを1.1．1.1に解決します)。このリクエストは一番外側のルーターにヒットしプライベート・アドレス、たとえば10.1.1.10に変換されます。ルーター自体は10.2.1.1ですから10.1.0.0のネットワークを検索します。下流のあるルーターがそのネットワークを認識していると言ったとします。そのルーター10.1.0.1は他の二つのルーター10.1.1.1および10.2.1.1.を認識しています。10.1.1.1のルーターは10.1.1.10を認識していますので、リクエストを受け取りARPキャッシュの中にあるMACアドレスを調べてシステムに送信します。
仮想IPの問題点は、MACアドレスを持っていないことです。トラフィックはMACアドレスを持つ物理的なNICを使用しますが、VIPAのトラフィックは一つの特定のNICには紐付けられていません。さらに、VIPAは実際には同じネットワーク上にはないのです。したがって、物理インタフェースが172.20.1.2と172.20.1.3であったとしても、172.20.1.4というVIAPは、実際はサブネット・マスクが255.255.255.255である一つのアドレスしか持たない固有の小さなネットワーク上にあるのです。さらに混乱しやすいのは、RIPv2ルートを使用している場合、VIPAは物理アドレスには見えず、たとえば192.168.1.10といったように見えるのです。パブリック・アドレスである場合さえあるのです(本稿ではプライベート・アドレスを使用していますが、これはその方が実際にはより一般的ですし、他人が所有しているアドレスを公開することを避けるためです)。
さて、もちろんこうしたアドレス・スキーマを使用するとVIPAへの静的なルートを細部まで正確に作成することができます。この作業は、VIPAがサブネットと連続していれば(たとえば前述の172.20.1.4のように)骨の折れる作業ではありませんが、サブネットと連続していない場合(たとえば192.16.8.1.10のように)は、ルーターごとにルートを作成しなければなりません。もちろんこのアプローチでは、ローカル・サブネット上のすべてのデバイスがVIPAへ到達したいのであれば、このVIPAへのルートを持たなければならないということを意味します。そしてたとえこの問題を解決したとしても、TCP/IPの動的性質の強みを失うことになります。VIPAは所定の場所に根を下ろすので、何か変更があれば再構成しなければなりません。うわぁー大変だ。
VIPAを通知して耐障害性を提供する
こうした難局を回避する方法が二つありますが、いずれもVIPAを通知することが含まれます。一つ目の方法はプロキシARPです。これはデバイスが自分自身を認識できるようにするというものです。二つ目の方法は、RIPv2でルーター・デーモン(RouteD)を使用します。プロキシARPを使用する方法についてまず説明しましょう。あるインタフェースが別のインタフェースと連絡を取る必要がある場合、まず相手までどのように到達するかに関して設定されたあるいはキャッシュされた情報があるかを探します。そのような情報がなければARPリクエストを発行します。サブネット上の他のデバイスがターゲットそのものであるか、あるいはターゲットへ到達する方法を知っているのであれば、このリクエストへの回答があります。したがってあるサーバーがそのMACアドレスを回答するかもしれませんし、そのパケットを適切な場所へ送信すると約束したルーターが回答するかもしれません。
しかしVIPAをネットワークにプラグすることはできません。仮想イーサネット・ケーブルが作成されるまでは、物理的インタフェースがVIPAのために回答しなければなりません。この「プロキシ」インタフェースがARPのリクエストに対してMACアドレスを回答します。次にデバイスは物理アドレスに対してパケットを送信し、ARPキャッシュ中にあるMACアドレスをログに記録します(VIPAだけでは受信ロード・バランスを調整できない理由でもあります。異なる物理インタフェースが各ARPリクエストに回答した場合でも、ARPのキャッシュが期限切れになるかあるいはクリアされるまでは、ARPキャッシュ中にある有効なルートを持ったデバイスが新しいリクエストを作ることはありません)。
これはVIPAと同じサブネット上にあるデバイスにとっては良いことですが、ルーターの向こう側にあるデバイスについてはどうでしょうか。VIPAがサブネット・アドレスと連続している場合は、ルーターはそのアドレス空間内にあるすべてのトラフィックを通知し、ルーターのARPキャッシュ内のエントリが残りの処理をします。したがって前述の例と同様に、ルーターが172.20.1.0/24の範囲にあるすべてのアドレスを通知します。VIPA 172.20.1.4宛のパケットがこのルーターに到達した時、ルーターはARPキャッシュ内でこのアドレスを検索します。エントリがキャッシュ内になければルーターはどれか一つのプロキシ、たとえば172.20.1.3に対してARPリクエストを送出しそのアドレスを回答します。「私がスパルタカスだ」と。幸いなことに、映画と違ってこう応えてくれるのは一度に一人だけですが。
IBM i 5.4およびそれ以降のバージョンでは、プロキシARPを使用する際のVIPA用の優先インタフェースの一覧があります。この一覧の最初のインタフェースが利用可能でなければ、図―5にある通りその次の行にあるインタフェースがVIPAと関連付けられます。この例では希望するインタフェースを選択し(この場合172.16.1.2と172.16.1.3の両方)、それぞれに対して順番に[追加]をクリックして優先インタフェースの一覧に追加します。詳細(およびその他のTCP/IPのヒント群)については、IBMのレッドペーパーi5/OSでTCP/IPを使用する際のヒントとテクニックを参照ください。
またバージョン5.4からは、プロキシARPを使用して別のサブネット上にあるVIPAを通知できるようになりましたが、これはCisco社のIOS (IBMのi OSのことではなくCisco社のIOSのことです)のローカル・エリア・モビリティ(LAM: Local Area Mobility)を使用している場合に限ります。IBM iシステムをあるサブネットから別のサブネットに永久的に移動するような状況では、これを使用すると良いかもしれません。このシステムは別のリモートにあるサブネットに物理的に接続されていますが、Cisco LAM対応のルーターはそれでも、「古い」アドレス(今はVIPAになっていますが)とそのアドレスへのルートを新しいサブネットに対してブロードキャストします。この構成の概要については、IBMのドキュメント「仮想IP - ロード・バランス、耐障害性、IOA共有」を参照ください。
ディザスター・リカバリー用VIPAを他のシステムに使用して元に戻したいとしたらどうしますか。そして実運用マシンがカリフォルニアにあってそのアドレスが10.1.3.10/24で、ディザスター・リカバリー・システムのアドレスが10.2.4.10/24でニュージャージーにあったとしたらどうでしょう。カリフォルニアのルーターは10.1.3.1から10.1.3.254のアドレスを通知しますので、10.1.3.11のようなVIPAを作成した場合は、ニュージャージーのプロキシARPがある10.2.4.0ネットワーク上では動作しません(前述の通りLAMを使用した場合は例外ですが、その場合どうやって素早く元に戻すのでしょうか)。
この場合、あるサブネットから別のサブネットに移動してさらに元に戻すことができるようなVIPAを作成するには、ユニークなVIPAを作成します。ネットワーク上で他に使われていないアドレスであれば何でも構いません。パブリック(つまりNATなしでインターネットに到達可能な)アドレスでなくても良いのであれば、会社内の別の場所で使用されていないアドレスを使っても構いません。今回の192.168.1.10の例では、実運用とディザスター・リカバリー・システムの両方にVIPAをまず作成します。要は、任意の時点ではこのアドレスは両システムのうちの一つだけでアクティブになっているという考え方です。クラスタリングを有効にしている場合はこれが自動的に処理されます。自動のオプションについては、IBMインフォメーション・センターの「サブネット間でアプリケーションを切り替える方法」を参照ください。
両システム上でVIPAを確立したら、プロキシARPを介してそのVIPAと物理的なインタフェースとを関連付けることはしないでください(インタフェースを関連付けしてはならず、プロキシARPボックスも選択されない状態にしておかなければなりません)。では、ネットワーク上の他の機器はどのようにしてこのアドレスを知るのでしょうか。この質問はVIPAを通知する二番目の方法につながります。
ルーティング情報プロトコル、もう少し具体的に言うとRIPv2は、ルーティング・プロトコルの一種でネットワーク上のルーターやデバイスに対して、デバイスからルートを送信できるようにするためのプロトコルです。つまり、静的なルートをネットワーク上に対して手動で構成する代わりに、IBM iシステム上のあるジョブがルートをブロードキャストしてくれるということです。このジョブのことをルーター・デーモンといい、RouteDという名前が付いています。
現在VIPAを通知しているシステム上では、RouteDを構成して実行しなければなりません。緑色画面からRouteDの構成を変更するには、WRKRTDCFG コマンドを使用します。Navigatorを使用してRouteDの構成を変更するには[ネットワーク]-[サーバー]-[TCP/IP]を選択し、RouteDを右クリックして[プロパティ]を選択します。GUIを使用した構成設定の詳細(およびその他の有用な情報)については、IBMのレッドブック「IBM i5/OS IPネットワーク: ダイナミック」を参照ください。
いずれの方法でもRouteD構成ファイルを編集することができますので、これを使ってVIPAをネットワーク上の他のデバイスに通知する文を追加します。今回の例では、実運用サーバー上の物理アドレスが10.1.3.10と10.1.3.11で、VIPAは192.168.1.10ですから、次のような文を構成ファイル中に記述します。
RIP_INTERFACE 10.1.3.10 31 SUPPLY RIP2 FORWARD.COND 192.168.1.10 32 NOFORWARD 0.0.0.0 MASK 0.0.0.0 BLOCK 0.0.0.0 MASK 0.0.0.0
この文は、アドレス範囲10.1.3.10、マスク255.255.255.254 (31ビットですから10.1.3.10と10.1.3.11の2つのアドレスになります)に対して、VIPA 192.168.1.10でマスクが255.255.255.255 (32ビット)がその物理インタフェースに対して通知される、ということを意味しています。.CONDは、物理インタフェースがアクティブの場合のみに通知が行われることを意味しています。NOFORWARD文とBLOCK文は基本的には、他のネットワークがこのジョブによって受信あるいは通知されるのを防ぐためのものです。
RouteDジョブを実行する前に、ネットワークがRouteDを処理できるように設定してあるか確認してください。すべてのルーターでRIPv2の設定がされているとは限りませんから、ネットワーク上でこのプロトコルを使用しているデバイスが存在する可能性がありますので、ネットワーク管理チームとよく相談してRouteDを正しく実装してください。TCP/IPが開始された時にルートを通知して開始されるように、RouteDが設定されていることを確認してください。これはNavigatorで行うかあるいはChange RouteD Attributes (CHGRTDA)コマンドで行ってください。TCP/IPが開始された時にRouteDが開始されるように設定するか、あるいは手動で開始することもできますが、他のデバイスがVIPAに到達する前に開始されていなければなりません。
RouteDの詳細については、IBMのドキュメントSystem i - ネットワーキング RouteD - バージョン 6 リリース 1やIBMの技術ドキュメント仮想IPを使用したIBM System i サーバーの耐障害性の構成を参照ください。
ディザスター・リカバリー・システム上でもRouteDを開始できますが、物理インタフェースとVIPAがダウン状態にあることを確認してください。もし物理インタフェースとVIPAが稼働状態にあって、実運用システム上でも稼働状態にあると、両側のルーター・デーモン・ジョブが物理アドレスに対してルートを通知してしまいます。これでは見苦しい以外の何物でもありません。
設定が適切に行われていれば、そのシステムに耐障害性を持たせたことになり(どちらか一方の物理インタフェースがダウンした場合、RouteDはアクティブな方を通知しますから、VIPAが自動的にもう一方の物理インタフェースを使用します)、さらに一方のシステムからもう一方のシステムに一瞬で切り替えることができるようになったことになります。
ニュージャージー側のシステムがダウンした場合(または計画停止でインタフェースをダウンさせた場合でも)、VIPAが実運用サーバー側でダウンしてディザスター・リカバリー・システム側で立ち上がれば、そのVIPAをターゲットとしていたユーザーはほぼシームレスにカリフォルニア側のシステムに接続されます。「ほとんど」と言ったのは、ルートが通知されるまでに通常は数秒(あるいはネットワークによっては数分)の遅延があるからです。それでも、ユーザーにとってはスムーズな移行に見えます。この設定と複製技術を組み合わせれば、自分たちが別のシステム上にいるということをユーザーは気づかないかもしれません。少なくとも、実運用システムのデスクトップ上であるアイコンを使い、ディザスター・リカバリー・システムのデスクトップ上でもう一つアイコンをユーザーが使っている等という日はもう来ないでしょう。
VIPAを通知する上記の二つの方法は、システム内の物理アダプタ間および別々のシステム間での耐障害性を提供する強力な機能を示しています。もちろん常に良い方法を使用してシングル・ポイント障害を回避してください。たとえば、一つのシステム上で耐障害性用にVIPAを持ったNICが複数あるという問題を解決する場合、すべてのNICを同じスイッチに差し込んで構成の柔軟性を損なうようなことはしないでください。資源を分散させてください。可能であれば各NICを別々のラック内に設置する、別電源とする、別スイッチに設置する、等の措置を取ってください。見過ごしによりシステムにアクセスできないというのであれば、耐障害性の設計はユーザーにとって全く意味のないものになってしまいます。
ロード・バランス
耐障害性の他にも、VIPAを設定することである程度のロード・バランスを図ることができます。いやむしろ、VIPAは全体のロード・バランス・スキーマの重要な部分となりえます。受信ロード・バランスについては、VIPAはルート・ディレクティブの機能を持つルーターと協調することができます。ルート・ディレクティブは、受信パケットをラウンド・ロビン方式でVIPAに関連付けられた物理インタフェースに割り当てます。たとえば、VIPAが192.168.1.10で物理インタフェースが10.1.3.10と10.1．3.11である本稿の例でいえば、図―6に示されているようなディレクティブを確立することもできます。VIPAはルート・ディレクティブを使用したロード・バランスの方法の一部ですが、実際にはルーターの一機能なのです。ルート・ディレクティブは厳格にラウンド・ロビン方式を守るということを覚えておいてください。この方法では受信負荷がバランスされていることを前提としており、その負荷を利用可能なインタフェースに分散させているにすぎません。
送信ロード・バランスはIBM iシステム上で構成されますが、もう少し複雑になります。VIPAはその一部ですが、VIPAを使用しなくてもいくつかの物理インタフェースで同じロード・バランスを実現することもできます。
VIPAを使用せず複数の物理インタフェースを使用しているのと同様で、デフォルトではリモートのシステムは、ソース・アドレスをVIPAのアドレスではなく物理インタフェースのアドレスとみなします。この動作を回避するには、VIPAに関連付けられた物理インタフェースのローカル・インタフェースのパラメータでそのVIPAを指定してください。別の方法としては、ポート・アドレス変換(PAT: Port Address Translation)デバイス(別名「Hide NAT」または「逆NAT」または「NAT過負荷」とも呼ばれる)を使用することもできます。PATデバイスはユーザーとターゲット・デバイスとの間にあり、NATとは対照的に(NATの場合一つのIPアドレスを別のIPアドレスに置き換えます)、一つのIPアドレスを複数システムに対応したリモート・サイトに対して提示します。PATデバイスはポート置換という方法を使用してどのパケットがどこに送信されたのかをトラッキングします。この場合、ユーザー側のサブネットからの送信パケットはすべて同じソースIPアドレスを持っているように見えます。
これは決して風変わりな設定ではありません。ホーム・ネットワークをお持ちであればお使いになっているかも知れません。ご利用のISPがあるアドレスをあなたに割り当てていて、ルーターに接続されているデバイスが複数ある場合があるでしょう。ですからご家庭のPCがすべてibm.comにヒットしても、ソースのアドレスは同じです。「魔法」の部分はルーターがポートを置換するところで、ibm.comが一つのポートに対して応答した時に地下室にあるPCにルーティングするのに対し、別のポートに応答するときは、パケットはお子様の寝室にあるラップトップにパケットをルーティングするということです(お子様はibm.comのサイトで何を見ているのでしょう)。
ターゲット・デバイス側がどのようにしてソース・アドレスを見るのかを確立しましたから、複数の物理インタフェースを介してパケットをルーティングする構成をいくつか設定しなければなりません。この方法はスコーラー・ルートと呼ばれています(IBMのテックノート「IBM iSeries上でのスコーラー・ルート」を参照してください)。最初のステップは、各物理インタフェースに対してシステムが自動的に作成している直接ルートを無効にすることです。そうしないとこの直接ルートが他のものに上書きしてしまうからです。直接ルートを無効にするには直感に反して以下の二つのルートを作成します。
ADDTCPRTE RTEDEST('10.1.3.0') SUBNETMASK('255.255.255.0') NEXTHOP('10.1.3.10') BINDIFC('10.1.3.10') DUPRTEPTY(6)
ADDTCPRTE RTEDEST('10.1.3.0') SUBNETMASK('255.255.255.0') NEXTHOP('10.1.3.11) BINDIFC('10.1.3.11) DUPRTEPTY(6)
ルートの優先度(DUPRTEPTY)が6と重複しているのが「魔法の数字」です。6以下ですとスコーラー・ルートがオフになるという意味になります。上記のルートが追加されれば、この物理インタフェースを使用してシステムから外へ出ていくトラフィックはこのインタフェース間でバランスが取られます。同じVIPAに関連付けられているインタフェースが他にもあるけれども、先行するインタフェースが利用不可能な場合のみに使用したいというような場合は、DUPRTEPTYの値をもっと大きくしたルートを追加すれば良いのです。
複数のインタフェースへのルーティング
インタフェースが一つしかないシステムではルーティングは簡単です。送信も受信もすべてが同じ方法で行われます。しかしインタフェースが追加されていき、しかもネットワークに対する単一の物理接続を持たないVIPAのようなインタフェースが追加されると、ルーティングはずっと複雑になります。
二つの重複したネットワークに接続されている一つのシステムを、VIPAを使って移行することを考えてみましょう。この場合、二つの会社が統合されたという想定です。両方とも10.0.0.0というアドレスを使用しており、アドレス空間が重複していることもわかっています。両ネットワーク上のクライアントはある特定のIBM iサーバーに到達できる必要があり、その望むところは、ネットワークが徐々に一つに統合されていくに際して必要最小限の再構成に済ませたいということです。
そのような設定の詳細を図―7に示します。この図は考え方を説明するために意図的に簡略化したものである点に注意してください。二つのネットワーク(「古い」ネットワークが「新しい」ネットワークに統合される)は10.3.1.0というアドレス空間を使用します。実際は、各ネットワーク上に同じアドレス(10.3.1.131)のデバイスが存在することになります。Power Systemsのサーバーには四つの物理インタフェースがあります。そのうち二つは「新しい」ネットワーク側の10.4.1.0ネットワーク上にあり、残りの二つは古いネットワーク(172.16.1.0)とインタフェースするように作成されたネットワーク上にあります。VIPAはRIPv2を使用して確立されていますので、すべてのネットワーク上のすべてのデバイスは、Power Systemsのサーバーを192.168.1.10として認識します。
「古い」ネットワーク上の10.3.1.131から192.168.1.10に向けてパケットが来ると、そのパケットはNATによって172.24.2.0というアドレスに変換されます(この場合は172.24.2.123ですが、NATは通常ダイナミックに構成されていますので、クライアント・デバイスが接続されるたびにアドレスが変更されることがあります)。逆に「新しい」ネットワーク上の10.3.1.131のデバイスは、Power Systemsサーバーからは単に10.3.1.131に見えます。
ここで重要なのは、リクエストが入ってきたときのインタフェースと同じインタフェースから応答が返ると仮定しないことです。たとえば図―8に示す画面(CFGTCP option 2)が、今回の例のPower Systemsサーバー上のデフォルトのルートを示していると仮定します。この場合、10.3.1.131にある古いネットワークのデバイスがVIPA 192.168.1.0をターゲットとし、システムがルーターに対する応答を、最初のデフォルトのルートである10.4.1.1に送信します。「古い」ネットワーク上のデバイスへの接続はタイムアウトになります。これが「非対称ルーティング」の問題点です(この領域についてはチェースの同僚、デビッド・ミシェル氏に教えてもらいました。感謝いたします)。この問題を解決するには、(NavigatorまたはCFGTCPコマンドを使用して)適切なルーターに対するルートを作成する必要があります。ルートの例を図―9に示します。
優先インタフェースは(ここではデフォルトの*NONEのままにしておきますが)、指定したいと思っているインタフェースのどれかでしょう。ルートが物理インタフェースに関連付けられていてしかも利用可能な優先インタフェースがない場合は、アクティブなインタフェースのうち最初のインタフェースを関連付けます。この動作は、与えられたアドレスに戻ってくるということがすべてのインタフェースで有効になっていないと、問題を引き起こすことがあります。たとえば、リモート側がNATアドレスを介してこちらのシステムをターゲットとしていて、そのNATアドレスが単一の物理インタフェースをターゲットとしている場合、そうしたクライアントからのトラフィックがそのインタフェースだけを通って来るようにしておかなければなりません。
ルーティングは重要です。そしてネットワークが複雑になればなるほどルーティングも複雑になる、と言っておけば十分でしょう。送信したトラフィックが「うさぎの穴」に入ってしまって二度と応答がないという状況にはなりたくないでしょう。
ルートを慎重に構成してネットワーク担当者と緊密に連携してください。どんなルートが存在していてそのステータスがどうなっているのか把握しておいてください。このためのツールにはNETSTAT option 2 (現在のルートの全情報を表示) (IPv4用)やCFGTCP option 2などがあり、構成されている静的ルートの状況を確認できます。少なくとも冗長なルートだけは監視してください。これらは混乱を増大させるだけです。IBM i 6.1ではTCP/IPのルートにはテキスト記述フィールドがあることを覚えておいてください。このフィールドを使用してください。他の人が(あるいは自分のためにも)なぜこのルートが存在するのかを知りたい時にきっと役立つと思います。
一般的に言って、ルートが関連付けられる方法によっては、すべてのルートについて優先インタフェースを指定した方が良いでしょう。スコーラー・ルートを使用している場合は送信パケットが利用できるインタフェースをすべて使いますので、この推奨事項に従うことが特に重要です。
この関連付けの動作はNavigatorで見るのが一番です。インタフェースを右クリックして([システム]-[ネットワーク]-[TCP/IP設定]-[IPv4]-[インタフェース])、[関連ルート]を選択します(図―10Aおよび図―10Bを参照してください)。ルーターへのデフォルトのルートは、こうしたインタフェースのうちの一つに対してだけ定義されているということに注意してください。実際には、このインタフェースが出現する最初のインタフェースなのです。おかしなIPLがあってネットワークが急に今までと違った動きを見せ始めたら、今までとは違ったインタフェースを使用していることが考えられます。
ですから、送信トラフィック用に二番目のインタフェースが選択されたら、システムはそれをどこにルーティングすれば良いのかわからないのです(もちろん静的ルートあるいは直接ルートがなければの話です)。最良の方法は、ルートが有効なすべての各インタフェースに対してルートを作成することです。この方法は構成の手間が若干多くなりますが、将来、頭が痛くなるようなことが少なくなるという可能性を示しています。
VIPAゾーンに入る
ロード・バランスであれ、耐障害性であれ、IPテイクオーバーであれ、VIPAが適切な解法であれば是非試してみてください。ただネットワークの変更についてはいつもそうですが、周到な計画を立て、テストしてください。ちょっとだけ手間をかければ、境界を思いのままに広げられる驚異の地、VIPAゾーンにあなたも足を踏み入れることができます。
