前回は，2重化したモジュール間で情報を同期させる二つの手法――装置内イーサネットと同期専用メモリー――を紹介しました。今回はこの二つの方法の使い方について具体的に説明していきましょう。
装置内イーサネットで大量のデータを同期
ネットワークの構成にもよりますが，コントロール・エンジンを2重化する際には，100Mバイトを超えるような大量の情報を同期する必要が出てくるケースもあります。例えば，大規模ネットワークのコンフィグレーション情報や，ARPテーブルなどプロトコルに関連する情報です。AX6700Sでは，こうした大量の情報をコントロール・エンジン間で同期させるために装置内イーサネットを使っています。運用系のソフトウエアは情報の変更を常に待機系に送付・反映し，待機系はその情報を記憶して系の切り替えに備えます。
大量のデータをやりとりするのに装置内イーサネットは適しています（図5）。しかしその一方で，装置内イーサネッでは，再送制御や到達確認をTCPに任せているため，2重化したコントロール・エンジン間で瞬時にデータを同期させる「同期の即時性」はありません。ある瞬間を見ると，運用系のコントロール・エンジンは情報の同期処理を終えているのに，待機系ではまだ受信が完了していないという状態が生じます。
この瞬間，運用系に障害が発生すると，本来同期すべき情報が失われることになります。同期の遅れはごく短い時間なので，待機系が受信できなかった情報はごく少量ですが，ソフトウエアはこの少量の失った情報をリカバリする必要があります。リカバリの方法は機能によって異なりますが，失った分について再送処理を行うなど，プロトコルの規定が許す範囲の時間をかけてリカバリを行います。
 |
| 図5●装置内イーサネットを使用した情報同期 装置内イーサネットを介した同期はTCPを使って高速に実行する。ただし，同期の即時性は期待できない。 [画像のクリックで拡大表示] |
同期専用メモリーで到達確認をしながら同期
装置内イーサネットを使って情報を同期させる手法では，同期にかかる時間の遅れによって情報が失われると，プロトコルの再送処理などでリカバリします。しかし，一部の通信処理では，情報をリカバリするのが難しいケースが出てきます。
例えば，ハードウエアの制御に関する情報で，インタフェース・カードの各ポートのリンク・アップ/リンク・ダウンの状態や，フォワーディング・テーブルの更新に関する情報，転送エンジンやインタフェース・カードそのものがどのような状態で動作しているかの情報などです。
ハードウエアの状態について一部の情報が失われた状態のまま切り替えを実行してしまうと，新たに運用系になった側（旧待機系）は，ハードウエアの現状を調べ直さなければならなくなります。どこの情報が失われているかもわからないので，ハードウエア状態のすべての情報について確認をとることになります。新・運用系ではこの再確認が完了するまで，ハードウエアの設定を変更できなくなり，コントロール・エンジンが本来行わなければならない処理が遅れてしまいます。
こうした事態を避けるには，同期の遅れによるリカバリという処理そのものが要らない，つまり「同期の即時性」が確保できる方法が必要となります。そこで，同期の即時性を確保するために登場した手法が，同期専用メモリーを使う方法です（図6）。
 |
| 図6●同期専用メモリーを使用した情報同機 フォワーディング・エンジンに配置した同期用メモリーに書き込むことで同期を行う。 [画像のクリックで拡大表示] |
運用系と待機系，両方のコントロール・エンジンは，同期専用のメモリーに直接アクセスできるようになっています。さらに，コントロール・エンジンがダウンしても情報が失われないように，他のモジュールに搭載します。AX6700Sでは，フォワーディング・エンジンのモジュールに搭載しています。
同期専用のメモリーは，コントロール・エンジンから直接読み書きできるので，運用系のコントロール・エンジンが情報を書き込んだ時点で，待機系から参照できるようになります。さらに，すべてのフォワーディング・エンジンに同期専用メモリーを搭載し，同じ情報を多重に書き込みます。こうすることで，一つのフォワーディング・エンジンがダウンしても読み書きできるようになります。
この同期専用メモリーの読み書きは，装置内イーサネット経由で情報をやりとりするのと比べると非常に高速です。そのため，同期専用メモリーを使うことで，通常の処理を滞らせることなく同期の即時性を確保できるようになります。
ただし，同期専用メモリーを使う方法にはデメリットもあります。あまり大量のメモリーを搭載すると装置コストが跳ね上がってしまうのです。このため，搭載するメモリーの容量をなるべく抑え，同期専用メモリーで同期させる情報を限定するように2重化部分を設計します。
同期の方式は用途に応じて
以上のように，モジュールの2重化を実現するのに欠かせない情報の同期は，二つの手法によって実現されます。同期する情報量や機能の特性，装置コストなどのバランスにより，二つの手法のうちどちらを使用するかを決定します。
ハードウエアの制御に直接関わるような情報は，同期の即時性を確保する必要があるものが多いのですが，コンフィグレーション情報やプロトコルに関連する情報に比べると，情報量は少ないという傾向があります。逆に，コンフィグレーション情報やプロトコルに関連する情報は，情報量が圧倒的に多くなります。そこで，ハードウエア制御に関連する情報の同期には「同期専用メモリー」を使い，コンフィグレーション情報やプロトコルに関連する大量の情報の同期には「装置内イーサネット」を使います。
ただし，両者を使い分けるケースもあります。機能に応じて適切な方法を採用するのです。その具体的な例として，ARPに関する処理を見てみましょう（図7）。
 |
| 図7●ARPに関する情報の同期 ARPテーブルの情報は装置内イーサネット経由で同期させ，フォワーディング・テーブルの更新に関する情報は同期専用メモリーを使って同期させる。 [画像のクリックで拡大表示] |
LANスイッチ内部のARPの処理は，（1）ARPプロトコルにより端末などのARP情報を学習し，（2）パケット転送を行うためにフォワーディング・テーブルに学習したARPのエントリを登録し，（3）ハードウエアでパケット転送を行う――という流れになります。この処理の中で，その都度情報が追加されたり書き換えられたりするのは，コントロール・エンジンのARP機能が持つ「ARPテーブル」と，フォワーディング・エンジンの「フォワーディング・テーブル」になります。つまり，モジュールを2重化させるには，この二つの情報について同期を取っておく必要があるわけです。
（1）のARP学習は短時間に大量のARPテーブル登録を行う場合があります。そうした場合は，2重化したモジュール間で大量の情報を同期する必要があります。そのため，ここでは装置内イーサネットを経由した同期方法を採用します。仮に，ARPテーブルの同期が完了する前に2重化の切り替えが発生したとしても，ごく小数のエントリについて再度ARP学習を行うことで，短時間にリカバリできます。
（2）のフォワーディング・テーブルへの登録では，フォワーディング・テーブルの状態を厳密に管理する必要があります。テーブルを中途半端に更新してしまうと，大容量のテーブルをすべて検査する必要が生じ，そのリカバリ処理が困難になるからです。そのため，テーブル更新の前後に，どのような更新を行うかという情報をまず同期させます。これによって，テーブル更新の途中で2重化の切り替えが発生しても，フォワーディング・テーブルを即座に修復できるようになります。テーブル更新の情報の同期は即時性が求められます。また，この情報はテーブル更新が完了すると不要な情報となるため，情報量としては少なくなります。そこで，この同期には同期用メモリーを使用する方法を採用しているわけです。
2重化の系の切り替えは高速に
ルーターやLANスイッチのソフトウエアは，ここまで見てきた方法で情報を同期しながら――つまり，2重化の切り替えに対する準備をしながら――動作しています。ここで系の切り替えに条件を付ければ，ソフトウエアの実装を容易にすることもできます。
例えば，運用系に故障が発生したとき，ソフトウエア処理の進行状態を確認して「連続して行わなければならない処理に区切りがつく“都合の良いタイミング”」で，運用系から待機系へ切り替えるようにすれば，ソフトウエアの実装は比較的容易になります。また，コンフィグレーション情報の情報を同期している最中で，図5の待機系TCP/IPのバッファに同期する情報が残っている場合，その情報を処理し終わってから切り替えを行うようにするとソフトウエアの実装が容易になります。
しかし，ソフトウエアの実装を優先してこうした条件を付けると，故障発生から通信復旧までを遅らせる要因になります。“都合の良いタイミング”というのは機能により様々で，場合によって秒単位の時間を待たなければならなくなる可能性もあります。例えば，音声データを転送している装置の2重化切り替えで秒単位の時間を要すると，エンドユーザー側では，音声が一時的に切れて聞こえてしまいます。これは問題です。
そのため，どんな瞬間でもすぐに切り替えを行えるようにソフトウエアを実装するのが基本です。系の切り替えはハードウエア・レベルで行います。こうすることで，2重化部分に障害が発生した場合，ミリ秒単位で待機系へ切り替えることができ，復旧にかかる時間を短くできるわけです。
|
|
