6th - Junos on KVM/Linux/x86

先日、Juniper の QFX5100 スイッチの OS の中身が Linux で、Junos をその上の VM で動かしている、という話が出ていた。これに Arista のような Openness を感じる人が多いかも知れないが、多分ちょっと違うんだろうな、と僕は思っている。 （この記事は別に Juniper のアプローチを批判するものではない点にご注意下さい。VM で動作させるアプローチ自体は悪くないし、多様なアプローチ自体は歓迎すべきことでプロレスのように単純比較して優劣を判じてもしょうがない。強いて言えば僕は自分の「好み」を説明しているだけだ。）
僕は個人的に Arsita の EOS （制御用 OS）をお薦めしている。理由は EOS の中身がとても普通の x86 Linux で、制御プログラムそのものが高級言語 (Python) で書かれており、Linux レベルででも、Python レベルででも、とても自由に手を入れられるからだ。僕はこれを Hackability が高いと評している。
EOS で僕が好きなのはベンダーが提供する機能、というかシステム自体のとても広範囲に直接手が入ることと、その（特に入り口部分の）技術ハードルが異様に低いことだ。EOS のほとんどは Python で記述されており、EOS にはソースコードがそのまま含まれている。bash も vi も動くので、login して Python のコードを直すだけで、すぐ反映されて動き始める。おかしくなったら電源ぶち切りして再起動すれば元に戻る。（もちろん保存することもできる）
Junos は以前から「プログラムで制御できる」事が知られており、Arista が出た当初によくその点で引き合いに出された。Juniper でもできるでしょう？どう違うの？と。 逆に僕は Junos のことを知らなかったのでざっと調べてみたところ、JUNOScript である程度自動化処理が出来る、とはいえ、これは OS やシステムにその記述言語を使って、直接自由に手を入れられるわけではなかった。その後、Juniper は SDK を出し、こちらは Junos そのものにかなり食い込めるものだった。しかし SDK の内容について調べたところ、その技術ハードルは相当なものだった。（技術以外のハードルについてもいろいろ聞いた）
（これはもちろん JUNOScript が安全性重視な設計として必然的に導入した制約で、その真逆をいく EOS はユーザが手を入れた途端，何が起きても不思議で無い、という状況だ。繰り返すが僕は好みの話をしているに過ぎない。）
今回、QFX5100 の「中身が x86 Linux で、Junos をその上の VM で動かす」という話を、僕は一瞬 「x86 CPU の、手が入れられる Linux ベースの OS をもつスイッチが出てきた」のかと思いかけた。しかしどうやらそうではなく Junos はやはり Junos のままということのようだ。VMの中はやはり閉ざされた Junos であるはずで、VM の外の比較的手が入りやすいと想像される Linux システムから手が届くものではないんだろうなと思える。
SDN というのはソフトウェアで制御できる、ということで、そのために多くのプログラマにとって見通しが良い Linux で制御 OS を組むことは良い事だと思うのだけれど、ほんとに制御したい OS は VM のカプセルの中、となるとちょっとうーん、と思ってしまう。 つまり本当に重要なことは、制御用 OS の安全性確保と、デベロッパーに提供する自由度の「良い」バランスポイントはどこか、ということなんだろうなと。SDN が普及していく過程で、このあたりに一定の答が出てくるものと思う。推移を見守りたい。
なお僕が Junos のことを調べたのは 2013年の夏が最後なので、ひょっとして最近のものはもう少し何かハードル低めの入り口があるのかも知れない。あったらごめんなさい。

References