1.
Cumulus Linuxを
導入したワケ
株式会社マイクロアド
元井 正明

2.
導入したワケ
検証でCumulus Linuxを実際に触ってみて、
”面白そう…”と思ったから

3.
アジェンダ
● 導入までの流れ
● 当時抱えていた課題について
● 課題に対する検討
● Cumulus Linuxを導入検討
● 構成について
● 導入してみてよかったこと
● 現在まで運用してみての感想
● 今後の計画

4.
導入までの流れ
● 2015年3月10日、某社よりCumulus Networks社を紹介
→最初は”ウチで使うのはどうなのかなぁ…”という感想だった
● 3月18日、Bootcampに参加
→Cumulus Linuxについて詳しく知る機会に
● 4月頃から検証機を借りて実際の操作感や設定方法などを検証（約2
週間）
→スイッチでLinuxコマンドを打つというのは新鮮だった
ここで使えるタイミングがあれば使ってみたい気持ちが湧いてくる

5.
導入までの流れ
● 既存NWの課題や導入方法の検討などを整理してみると
IP CLOS構成にしたい欲求が。
→Cumulus Linux使えるのでは？
● ビジネス的に新しいHadoopクラスタを構築することになり
専用ラックの拡張案件が舞い込んでくる
→これはCumulus Linux使うしかない
● 2015年10月頃に導入決定、2016年1月から運用開始

6.
当時抱えていた課題

7.
課題：独自Fabric機能によるベンダーロック

8.
課題：大きなL2空間

9.
課題：大きなL2空間なのでL2ループの不安

10.
課題：大きなL2空間なのでBUMトラフィック
一部の古いスイッチでは、BUMトラフィックでサーバ接続ポートのトラフィックが溢れてしまうことも
BUM :Broadcast, unknown Unicast, Multicast

11.
当時の課題（まとめ）
● スイッチのベンダーロック（某社のL2Fabric機能に依存）
● 約2000台のサーバが同じL2に接続
● L2でのループ事故（過去に何度か発生）
● BUM(Broadcast, unknown Unicast, Multicast)のトラフィックが無視でき
ない状況

12.
課題：そもそも…
ネットワーク専任エンジニアがいない
サーバエンジニアが片手間でスイッチを設定
課題があってもなかなか手を付けられない
なのでみんなの頭の片隅に…

13.
課題に対する検討

14.
課題に対する検討（１）
一番大きな問題はL2での障害
→当時流行り（?）であったIP CLOS構
成を真面目に検討してみる

15.
課題に対する検討（２）
約2000台のサーバが同じL2に接続
→IP CLOS構成ならL2を最小限に
できそう
L2でのループ事故（過去に何度か発生）
→L2を最小限にできそうなので、
ループ発生時も影響を極小化できそう

16.
課題に対する検討（３）
BUM(Broadcast, unknown Unicast, Multicast)のト
ラフィックが無視できない状況
→BUMはL2を越えないので、こちらも
極小化できそう

17.
課題に対する検討（４）
スイッチのベンダーロック
（某社のL2Fabric機能に依存）
→IP CLOSならOSが対応しているス
イッチであれば選択肢が複数ある

18.
課題に対する検討（５）
そもそもネットワーク専任のエンジニアがいな
い
→Linuxがベースなので、サーバエンジ
ニアもとっかかりやすい（？）

19.
課題に対する検討（まとめ）
ひとまず課題になっていることは
解決できそう

20.
課題に対する検討（不安）
とは言え不安も…
● BGPの設定簡単にできるだろうか
● Linuxベースとはいえ、管理を簡単にできるだ
ろうか
● どうやって移行していこうか

21.
Cumulus Linuxの
導入検討

22.
Cumulus Linuxの導入検討（１）
IP CLOS構成でL2問題の解決になるかも
ひとまずHadoop環境用に小規模NW設計

23.
Cumulus Linuxの導入検討（２）
構成管理ツールで楽に運用できるそう
Ansible真面目に触ってみる

24.
Cumulus Linuxの導入検討（３）
BGP Unnumberedによる
Spine - Leaf間のBGP設定が簡単そう

25.
導入したワケ
なによりCumulus Linuxを実際に触ってみて、
”面白そう…”と思ったのが大きい

26.
構成について

27.
シンプルなSpine - LeafのCLOS構成を検討

28.
既存環境との接続方法
様々な方法を検討したが、最終的には以下のような接続方法に

29.
導入してみて良かったこと

30.
導入してみて良かったこと（１）
BGP Unnumberedの設定は簡単！
router bgp 65001
bgp router-id 10.1.1.1
neighbor FABRIC peer-group
neighbor FABRIC remote-as external
neighbor FABRIC capability extended-nexthop
neighbor swp49 interface peer-group FABRIC
neighbor swp50 interface peer-group FABRIC
BGPの設定

31.
導入してみて良かったこと（２）
Ansibleで設定を管理しているので…
● コンフィグのバックアップが不要
● テンプレートで設定内容を簡略化
● 故障時のスイッチ交換が容易

32.
導入してみて良かったこと（３）
ZTP＋AnsibleでOSインストールから設定まで
を簡略化
● ZTPでスイッチの基本設定
● Ansibleで機器個別の設定
● 1時間もあれば完了

33.
導入してみて良かったこと（４）
HW保守費の削減
● HWの保守レベルを最低限に
翌営業日対応やセンドバックなど
● 予備機を持って運用していたほうがコスト的
に安い

34.
現在まで運用してみて
● Hadoop環境以外にも適応して10数台程度まで拡張
拡張もZTP+Ansibleで簡単
● シンプルなIP CLOS構成なので4年経過しても大きなトラブル
なし
HW故障も1台のみ
● シンプルが故に設置・セットアップ後はあまり手をつけてない
運用。。
OSのバージョンアップはちゃんとしようと思った
→基本的にZTP+Ansibleなのでバージョンアップも楽

35.
現在まで運用してみて
● よくよく調べて見るとHadoopの処理中にパケロスが出る
ようになってきた。スイッチのASICが何であるか気にな
るようになった。。

36.
今後の計画

37.
今後の計画
データセンター移設計画
進行中

38.
今後の計画
こんな構成で進めています

39.
今後の計画
新DCでのNW構成
● DC内はIP CLOS構成
● サーバでBGPを運用、All L3化を計画中
● パケロスが気になったのでMellanox, Broadcomの
機器検証して両者問題ないことを確認

40.
今後の計画
機器は…
● DC内はホワイトボックススイッチ
● OSはCumulus Linux
● その他、FW・LBやRouterなどは
アプライアンス製品を使用
● 現在GNS3でVXを動かして検証中