光トランシーバーによって運ばれるデータの部分は、ファブリックチップに接続されたSerDesインターフェースによって行われる。これはデータプレーンです。

そして、トランシーバーのタイプや温度、受信している光の強さなどを把握するにはI2Cインターフェースで行われます。これがトランシーバーにおけるコントロールプレーンです。

イーサネットスイッチとトランシーバーの組み合わせを考えるときに単純な図は下記のようになります。

NOS(Network OS)
Fabric chip
光トランシーバー

 

ホワイトボックスの場合トランシーバーベンダーも顧客が使用しているNOSと使われているファブリックチップは気にしますが他の要素、そのスイッチが何処で作られたかは軽視する傾向があります。しかし、実際のシステムはこれ以外の要素。特にこの図では出てこないコントロールプレーンの部分が重要でありトラブルの要素でもあります。

NOS
env driver interface driver fabric driver
I2C driver fabric chip
I2C SerDes
FAN,温度センサー、LED トランシーバー

 

トランシーバーはファブリックチップに関係ないパスでNOSと情報のやり取りをしており、それはI2Cドライバーとインターフェースドライバーを経由して行われています。そして、重要なことはこのドライバー部分はスイッチのハードウェアを製造しているベンダーからバイナリーでのパッケージとして提供されていることが多くNOS側からみるとブラックボックスになっている場合がある事です。

実際に、EdgeCore AS7712と7726ではファブリックチップの違いもありますが、interfaceドライバーの挙動も異なり。同じNOSを使用していてもI2C driverのdebug機能を利用してやり取りされている情報をdumpすると全く異なる結果が得られます。

論理的インターフェースに対してNOSからAPI経由で同じ操作をしても、実際にトランシーバーに対して行われる操作は異なると言う事です。

この結果、ある障害が同じNOSで同じファブリックであっても違うベンダーのホワイトブックススイッチで症状が異なり、その違いの部分がバイナリーなのでソースコードで確認できないという問題が実際にありました。

対処法としてはI2Cでの情報をdumpして比較するか、I2Cの信号を外部に引き出す線を装備した特殊なトランシーバーを使用し信号線をロジックアナライザーなどで確認するしかありません。

ホワイトボックスを使用するにあたってI2Cに関する互換性に注意することは広く知られていますが、FANの回転数制御や筐体の温度センサー情報の所得に関連するものであるという認識が強く、トランシーバーにまで影響すると考えていない人も多いようです。

古くは、Intelの10G NICで同じようにバイナリーで提供されるドライバーによるlock-inが把握できず障害の解明に手間取った事がりました。ユーザーとしてはソフトウェア部分はパッケージされ全面的に入れ替えているのでNICベンダー固有の要素があるとは想定していませんでした。しかし、パッケージ含まれるNICのドライバーはNICベンダーによって提供されたもので、その詳細はドキュメント化されていません。

その結果、組合せ試験の結果はハードウェアが原因を思えるが実際にはソフトウェアによる処理の違いであることにたどり着くのに時間を要したのです。

ブラックボックス化したドライバーによる懸念は、ファブリックチップのドライバーにもあります。多くのチップベンダーはSDKと言う形でバイナリーでのドライバーをNOSベンダーに提供しています。この部分の違いは、NOSベンダーが作成するドキュメントには含まれない事が多く、ユーザーからは隠蔽されています。

 


コメント欄を読み込み中