ホワイトボックススイッチとは

ネットワーク・インフラの世界にもソフトウェアを活用して開発や運用を効率化していこうという動きが盛んになってきました。その流れに乗るようにホワイトボックススイッチと呼ばれる新しいスイッチの形が注目を集めてきています。今回はホワイトボックススイッチについて解説していきます。

そもそもスイッチとは？

ホワイトボックススイッチの説明に入る前に、一般的なスイッチについて理解しておきましょう。基本的なスイッチの説明については次のページで解説していますので参考にしてください。

スイッチとは、「複数のデバイス間で通信を行うために、デバイス同士を接続するための装置」で、スイッチングハブや略してスイッチと呼ばれています。

上図でノードAからノードEへの通信の場合を考えてみます。

イーサネット通信はMACアドレスを使用して相手を特定して通信を行います。ノードAは宛先であるノードEのMACアドレスをイーサネットフレームの宛先MACアドレスフィールドにセットしてフレームを送信します。

フレームは電気信号に変換されて送出されスイッチに到達します。スイッチは、送られてきた電気信号をフレームに変換しフレームレベルで処理します。スイッチはMACアドレスを認識して処理しますので、該当するMACアドレスが接続されているポートのみに転送します。

この時、どのポートにどのMACアドレスを持っているノードが接続されているかをMACアドレステーブルというテーブルで管理していて、そのテーブルを参照して処理しています。

このようにスイッチは余計なポートにフレームを流さないため、ノードAとノードEが通信中であっても、その他のノード同士が通信を行うことが出来ます。

スイッチは入ってきた信号をフレームに変換し、そのフレームを解析して宛先MACアドレスを自身がもっているMACアドレステーブルと参照し、該当のポートに転送するという処理を専用のチップ（ASIC:Application Specific Integrated Chip）を用いてハードウエア処理しています。ソフトウエア処理と違いハードウエアで処理しているため非常に高速に処理を行うことができます。

スイッチの課題

ベンダー独自のハードウェア

スイッチは先程書いたように、フレーム転送を高速化するために専用のチップ（ASIC:Application Specific Integrated Chip）を用いてハードウエア処理しています。ASICなどのハードウェアや、ハードウェアを動かすためのOSは、ベンダー独自に開発していることが一般的です。

OSがベンダーごとに異なることで、異なるベンダーのスイッチ同士を接続する場合に問題が発生する場合があります。ベンダー独自の機能やベンダーごとに仕様が異なるなどが原因で、うまく接続できなかったり通信障害などのトラブルが発生した時に切り分けに時間がかかるといった課題もあります。

ベンダーごとに異なるコマンドプロンプト

ベンダーごとに設定方法やコマンドプロンプトが違うため、インフラエンジニアにとって負荷となってしまうという課題があります。

特にTera Termのマクロなどでコマンド投入を自動化する場合、ベンダーごとにコマンドが異なるため、ベンダーごとにコマンドを理解しつつマクロを作成する必要があるため、余計な工数がかかってしまいます。

最近は各ベンダー製品にもAPIが実装されてきていますが、APIの仕様が統一されていないため、やはりベンダーごとに仕様を確認しながら実装していく必要があります。

ホワイトボックススイッチとは？

これらの現状のスイッチの課題を解決すべく登場したのが、ホワイトボックススイッチです。今までのスイッチはハードウェアとOSは密接に連携しており、基本的にはベンダーがハードウェアとOSをセットで提供するという形態でした。

ホワイトボックススイッチは、ハードウェアとOSを分離することが可能で、一般的な汎用サーバーと同じように扱うことができるスイッチです。

Cisco製のスイッチであれば、OSもCiscoが提供しているIOSしか利用することができませんが、ホワイトボックススイッチの場合は、A社製のハードウェアにB社製のOSを搭載することができます。このようない利用者がハードウェアとOSを好きなように組み合わせて利用することができるというメリットがあります。

ホワイトボックススイッチのハードウェアを提供しているベンダーには、台湾ベンダーを中心に多くのベンダーが提供しています。

ホワイトボックススイッチのメリット

必要機能を独自に実装可能

ホワイトボックススイッチのOSは、Linuxベースで実装されているものが大半になります。そのため、一般的なLinuxのシェルが使えたりPythonを追加で導入するといったことも可能です。

このメリットを活かして、運用者が独自の機能を実装することが可能です。独自のAPIを実装して設定を完全自動化させるなど、サーバーのレイヤでは当たり前のように行われていた、自分でソフトウェアを実装してシステムを運用するということが、ネットワークのレイヤでも実現できるようになります。

従来のスイッチの場合、足りない機能があれば、ベンダーに機能実装を要求して開発してもらうしかありませんでした。開発に時間がかかったり、場合によっては実装を見送られることもあります。ホワイトボックススイッチの場合は、ホワイトボックススイッチ用のOSベンダーが開発を行いますが、ASICを制御するためのAPIやSDKが公開されているため、ユーザー自身が開発を行い機能実装することも可能です。

このように、インフラエンジニアもプログラミングのスキルが求められるようになり、インフラエンジニアとソフトウェアエンジニアの垣根がどんどん低くなってきています。

ベンダーロックインからの解放

ベンダーロックインとは、特定のベンダーの独自機能や独自技術にを採用することで、製品の入れ替え時にも同じベンダーの提供する製品を入れざるを得なくなり、他ベンダーへの乗り換えが困難になる状況のことです。

ホワイトボックススイッチは、ベンダーの独自機能があるわけではないため、他ベンダーのホワイトボックススイッチへの乗り換えを行う場合もハードルが低く、ユーザー主導でライフサイクルコントロールも可能です。

ホワイトボックススイッチのデメリット

では、ホワイトボックススイッチは既存ベンダーのスイッチよりも優れているのかというと、個人的には一概に良いとは言えないと思っています。

意外にコストメリットが少ない

商用でホワイトボックススイッチを利用する場合、ホワイトボックススイッチ用のOSも無償版では無くサポートが付いている有償版を利用することが一般的です。その有償版OSを利用する場合、既存ベンダー製のスイッチと価格があまり変わらない場合も出てきます。

また、ホワイトボックススイッチを運用するには、ソフトウェアスキルがあるエンジニアでなければ、メリットを活かした運用が難しいという課題もあります。また、保守体制にも課題があります。既存ベンダーの製品であれば、そのベンダーが一次対応しれくれますが、ホワイトボックススイッチで機能を独自実装しているような場合、一次切り分けは自分たちで実施しなければいけません。

特に展開するボリュームが小さい場合、コストメリットを生み出しにくいというデメリットがあります。