NetOpsCoding Advent Calendar 2015 4日目のエントリーです．
ネットワーク運用のためのネットワークスイッチを製造している側の中のひとです。
今回は箱屋さんからみた個人的な悩みとかを書いてみたりします。
自動化が必要なケースと必要でないケースがある。
必要なケース
ルーティンワークが発生する。大量の箱を面倒みる必要がある。
これこそ、NetOpsの出番、運用が楽になる。開発が楽になる。
いらないケース
一度いれたら二度と設定しない系の箱
MGMT用の箱だったり、、エンプラの島ハブだったり、、
悩み
エントリー系のスイッチ/ルータのUIをどうするか。
過去の歴史があり、簡単に変えられない。そもそもコストをどこに乗っけるのか問題とか、、、5000円のスイッチにAPI乗っけて値段あげられるかというと、、、
仮に過去の歴史が長いOSにアドオンすると実装が完全にならないという悩みがあります。
ここは永遠の課題だったりします。
解決策
最初から自動化を考えたOSを作ってしまう。APIが神でCLIやGUIが従、間違いがおこらない。
ホワイトボックス上のOSよりかは優しく保守できる形にすると喜んでもらえるかなぁとか、、
いっそ箱からオフロードしてVirtual Functionになってしまう。物理の制約から離れるので自動化がかなりできる。
古い箱たちやマルチベンダ対応とか
例えば OpenDaylightなどのネットワークコントローラ経由で抽象化して REST-APIで叩いて先をCLIにしたりとか
一つの回答かなと。実際ODLベースで動かされているベンチャーさんとかもいるそうです。
ちょっと考える。
API提供するだけだと、路頭に迷うよね、、、
えーい作っちまえということで、手前味噌ながらメーカーでライブラリやサンプルを提供していたりします。
こんな感じ
https://github.com/BRCDcomm/
あ、会社がばれた。。
こちらの紹介とかでおそらくおなかいっぱいになってしまうと思うので、今日はここまでで(^^;
まとめ
・自動化を考えるならば新しめの思想のOSでやるといいかもしれない。
・Out of BOX(ネットワークコントローラ)で抽象化するのも答えかな
・探すとAPIだけじゃなくてサンプルコードもあるよ
とりとめもないですが、読んで頂いてありがとうございました。