ネットワークは今や重要な社会インフラであり，信頼性・安定性の高いものでなければなりません。そのネットワークの基幹を支えるルーターやLANスイッチにも当然のごとく信頼性・安定性を高めるための様々な工夫が必要になります。今回から3回に分けて，そういった高信頼化への取り組みについて紹介していきます。
今回取り上げるのは，障害に強いネットワークを実現するための第一歩ともいえる装置の信頼性を向上させる対策についてです。具体的には，装置内モジュールの2重化について紹介します。
装置内のモジュールを2重化する
ルーターやLANスイッチは，(1)パケット転送を担うハードウエアである「フォワーディング・エンジン」，(2)それをコントロールするソフトウエアを搭載する「コントロール・エンジン」，(3）電源――などで構成されています。ネットワークの基幹部分に使うルーターやレイヤー3スイッチでは，これらを2重化できるようになっています。
装置内のモジュールを2重化することには，大きく二つの目的があります。一つは，万が一装置内モジュールが故障しても，ルーターやスイッチとしての処理を継続できるようにすることです。ハードウエアが故障して一つのモジュールが動作を停止しても，待機系のモジュールに切り替わることで処理を継続し，通信が止まることを防ぎます。
装置内のモジュールを2重化するもう一つの目的は，通信を止めずに装置のソフトウエアをアップデートできるようにすることです。2重化しているモジュールを使って，運用系のモジュールで通信を維持しながら待機系のモジュールのソフトをアップデートします。その後，2重化部分を切り替えて運用系だったモジュールのソフトも同様にアップデートします。こうすることで，装置を止めることなく装置全体のアップデートが完了するわけです。
言葉で書くと簡単そうに見えますが，実際にはさまざまな工夫によりこうした2重化を実現しています。今回は，アラクサラネットワークスのレイヤー3スイッチ「AX6700S」を具体例として，2重化のしくみを見ていきましょう。
まず，AX6700Sの装置構成を示します（図1）。
 |
| 図1●レイヤー3スイッチ「AX6700S」の2重化構成 コントロール・エンジン，フォワーディング・エンジンといったモジュールを2重化できる。 [画像のクリックで拡大表示] |
AX6700Sでは，ソフトウエアを搭載する「コントロール・エンジン」とパケット転送を処理する「フォワーディング・エンジン」の各モジュールを2重化できる構造になっています。正確にいうと，フォワーディング・エンジンは，最大3枚まで搭載可能です。
コントロール・エンジンは，実際にプロトコルを処理したり装置を操作する側が「運用系」として動作し，もう一方は運用系の障害時に備える「待機系」になります。
一方，フォワーディング・エンジンの2重化は，双方が「運用系」としてパケット転送の処理負荷を分散する構造になっています。片側に障害が発生した場合には，パケット転送をもう片側に集約して通信を継続します。
装置内の情報を同期し，切り替えても通信を維持する
2重化したモジュール間は，それぞれが持つ情報を同期させ，常に同じ情報を持つ必要があります。コントロール・エンジンでは，運用系のソフトウエアがそれ自身の持つ情報（コンフィグレーションやプロトコル情報，ハードウエア制御情報など）を常に待機系のソフトウエアと同期させています。フォワーディング・エンジンでは，ハードウエアでパケット転送を行うためのフォワーディング・テーブルに登録してある情報をすべて同じ状態にしています（図2）。
 |
| 図2●装置内の情報の同期 コントロール・エンジン，フォワーディング・エンジンを2重化し，各モジュールが持つ情報を同期させる。 [画像のクリックで拡大表示] |
2重化した装置で障害が発生すると，モジュールを切り替えて動作を継続します。コントロール・エンジン，フォワーディング・エンジンの順に，障害が発生した場合の動作例を簡単に見ていきましょう（図3）。
 |
| 図3●障害時の待機系での動作 コントロール・エンジン、フォワーディング・エンジンそれぞれで障害が発生した場合にも動作を継続する。 [画像のクリックで拡大表示] |
コントロール・エンジンの「運用系」に障害が発生すると，「待機系」が新たに運用系に切り替わります。この時，新・運用系のソフトウエアは，障害発生前の装置状態やプロトコル情報が元・運用系と同期しているので，ハードウエアの制御やプロトコル処理を引き継ぐことで通信に影響を与えずに動作を継続します。
フォワーディング・エンジンに障害が発生した場合はどうなるでしょうか。このとき，障害が発生したモジュールで処理していたパケット転送を正常なモジュール引き継げるように，ここでも全モジュールのフォワーディング・テーブルには同じ情報が登録されていて，通信に影響を与えずに動作を継続します。
このように，2重化したモジュール間で情報を同期しておくことではじめて，切り替え後に通信を継続できるわけです。
もし情報が同期されていなかったらどうなるでしょうか。例えば，コントロール・エンジン間でARPの情報（ARPテーブル）が同期されていなかった場合，運用系に障害が発生して予備系が新・運用系として稼働しますが，切り替え後の新・運用系は装置が学習していたARP情報を一切持っていない状態なので，ARPテーブルをすべて再学習する必要が生じます。この場合には，フォワーディング・テーブルの全ARPエントリに対して再登録が行われるような事態に陥り，結果として一時的に通信が途絶えてしまいます。このような事を避けるために，情報を同期する必要があるのです。
ソフトウエアの処理性能を落とさずに2重化する
コントロール・エンジンで稼働するソフトウエアは，どんな処理を行っている瞬間であっても突然の切り替えに対応できるように，運用系と待機系で様々な情報をやりとりして情報を同期させ，切り替えに備えています。
ただし，単純に「情報を同期すればよい」というわけではありません。情報を同期する際には，以下の三つのポイントを考慮する必要があります。それは，(1)情報を同期するスピード，(2)通常処理への性能の影響，(3)同期の信頼性――です。
ルーターやスイッチでは，スペックを向上させたり機能を拡張させたりすることによって，コントロール・エンジンの保持する情報量が増えています。それに伴い，コントロール・エンジン間で同期しなければならない情報量も増加しました。大量のソフトウエア情報を同期するにあたり，情報を同期させるときの信頼性は当然ですが，通常の処理の性能が大きく劣化し，装置の能力を落とすようでは意味がありません。つまり，情報を同期するスピードと通常処理の性能を両立させることが課題となります。
そこでAX6700Sでは情報を同期させるときに二つの方法――(1)装置内イーサネットでの通信による同期と，(2)同期専用メモリーによる同期――を採用しています（図4）。
 |
| 図4●コントロール・エンジンのソフトウエア情報を同期する二つの方法 ソフトウエアの情報を同期するために，二つの方法を使用する。 [画像のクリックで拡大表示] |
この二つの方法は，「大量データを同期させる際のスピード」と，「到達確認のスピード」を考慮して使い分けています。
(1)の装置内イーサネットを使う方法は，大量のデータを同期する場合に向いています。イーサネットを介したソフトウエア間の通信は信頼性確保のためにTCPを使い，到達確認や再送制御はTCPに任せて連続してデータを送り込めるからです。その一方で，この方法は待機系に届くまでに時間がかかり，同期の即時性（待機系に確かに情報が届いたことが直ちに確認できること）は求められません。
(2)の同期専用メモリーを使用する方法は，同期の到達確認を素早く行う必要がある場合に向いています。この方法を使うと，運用系のソフトウエアによってメモリーへの情報の書き込みが完了した時点で，待機系ソフトウエアからは確実に読み込み可能な状態になるからです。つまり，メモリーへの書き込み性能が到達確認スピードと等しくなり，同期の即時性が確保できます。
ただし同期専用メモリーは高価なので，この方法を採用すると装置コストに跳ね返ってきます。コストを考えると，メモリーの使用量はなるべく少なくしたいところです。そこで，同期できるデータの量を制限することになります。
|
|
