Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cumulus Linuxを導入したワケ

86 views

Published on

Cumulus Linuxを導入したワケ

第2回Cumulusユーザー会(2019/11/20) - connpass
https://cumulus-interest.connpass.com/event/152392/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cumulus Linuxを導入したワケ

  1. 1. Cumulus Linuxを 導入したワケ 株式会社マイクロアド       元井 正明
  2. 2. 導入したワケ 検証でCumulus Linuxを実際に触ってみて、 ”面白そう…”と思ったから
  3. 3. アジェンダ ● 導入までの流れ ● 当時抱えていた課題について ● 課題に対する検討 ● Cumulus Linuxを導入検討 ● 構成について ● 導入してみてよかったこと ● 現在まで運用してみての感想 ● 今後の計画
  4. 4. 導入までの流れ ● 2015年3月10日、某社よりCumulus Networks社を紹介 →最初は”ウチで使うのはどうなのかなぁ…”という感想だった ● 3月18日、Bootcampに参加 →Cumulus Linuxについて詳しく知る機会に ● 4月頃から検証機を借りて実際の操作感や設定方法などを検証(約2 週間) →スイッチでLinuxコマンドを打つというのは新鮮だった ここで使えるタイミングがあれば使ってみたい気持ちが湧いてくる
  5. 5. 導入までの流れ ● 既存NWの課題や導入方法の検討などを整理してみると IP CLOS構成にしたい欲求が。 →Cumulus Linux使えるのでは? ● ビジネス的に新しいHadoopクラスタを構築することになり 専用ラックの拡張案件が舞い込んでくる →これはCumulus Linux使うしかない ● 2015年10月頃に導入決定、2016年1月から運用開始
  6. 6. 当時抱えていた課題
  7. 7. 課題:独自Fabric機能によるベンダーロック
  8. 8. 課題:大きなL2空間
  9. 9. 課題:大きなL2空間なのでL2ループの不安
  10. 10. 課題:大きなL2空間なのでBUMトラフィック 一部の古いスイッチでは、BUMトラフィックでサーバ接続ポートのトラフィックが溢れてしまうことも BUM :Broadcast, unknown Unicast, Multicast
  11. 11. 当時の課題(まとめ) ● スイッチのベンダーロック(某社のL2Fabric機能に依存) ● 約2000台のサーバが同じL2に接続 ● L2でのループ事故(過去に何度か発生) ● BUM(Broadcast, unknown Unicast, Multicast)のトラフィックが無視でき ない状況
  12. 12. 課題:そもそも… ネットワーク専任エンジニアがいない サーバエンジニアが片手間でスイッチを設定 課題があってもなかなか手を付けられない なのでみんなの頭の片隅に…
  13. 13. 課題に対する検討
  14. 14. 課題に対する検討(1) 一番大きな問題はL2での障害 →当時流行り(?)であったIP CLOS構 成を真面目に検討してみる
  15. 15. 課題に対する検討(2) 約2000台のサーバが同じL2に接続 →IP CLOS構成ならL2を最小限に できそう L2でのループ事故(過去に何度か発生) →L2を最小限にできそうなので、 ループ発生時も影響を極小化できそう
  16. 16. 課題に対する検討(3) BUM(Broadcast, unknown Unicast, Multicast)のト ラフィックが無視できない状況 →BUMはL2を越えないので、こちらも 極小化できそう
  17. 17. 課題に対する検討(4) スイッチのベンダーロック (某社のL2Fabric機能に依存) →IP CLOSならOSが対応しているス イッチであれば選択肢が複数ある
  18. 18. 課題に対する検討(5) そもそもネットワーク専任のエンジニアがいな い →Linuxがベースなので、サーバエンジ ニアもとっかかりやすい(?)
  19. 19. 課題に対する検討(まとめ) ひとまず課題になっていることは 解決できそう
  20. 20. 課題に対する検討(不安) とは言え不安も… ● BGPの設定簡単にできるだろうか ● Linuxベースとはいえ、管理を簡単にできるだ ろうか ● どうやって移行していこうか
  21. 21. Cumulus Linuxの 導入検討
  22. 22. Cumulus Linuxの導入検討(1) IP CLOS構成でL2問題の解決になるかも ひとまずHadoop環境用に小規模NW設計
  23. 23. Cumulus Linuxの導入検討(2) 構成管理ツールで楽に運用できるそう Ansible真面目に触ってみる
  24. 24. Cumulus Linuxの導入検討(3) BGP Unnumberedによる Spine - Leaf間のBGP設定が簡単そう
  25. 25. 導入したワケ なによりCumulus Linuxを実際に触ってみて、 ”面白そう…”と思ったのが大きい
  26. 26. 構成について
  27. 27. シンプルなSpine - LeafのCLOS構成を検討
  28. 28. 既存環境との接続方法 様々な方法を検討したが、最終的には以下のような接続方法に
  29. 29. 導入してみて良かったこと
  30. 30. 導入してみて良かったこと(1) 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. 31. 導入してみて良かったこと(2) Ansibleで設定を管理しているので… ● コンフィグのバックアップが不要 ● テンプレートで設定内容を簡略化 ● 故障時のスイッチ交換が容易
  32. 32. 導入してみて良かったこと(3) ZTP+AnsibleでOSインストールから設定まで を簡略化 ● ZTPでスイッチの基本設定 ● Ansibleで機器個別の設定 ● 1時間もあれば完了
  33. 33. 導入してみて良かったこと(4) HW保守費の削減 ● HWの保守レベルを最低限に 翌営業日対応やセンドバックなど ● 予備機を持って運用していたほうがコスト的 に安い
  34. 34. 現在まで運用してみて ● Hadoop環境以外にも適応して10数台程度まで拡張 拡張もZTP+Ansibleで簡単 ● シンプルなIP CLOS構成なので4年経過しても大きなトラブル なし HW故障も1台のみ ● シンプルが故に設置・セットアップ後はあまり手をつけてない 運用。。 OSのバージョンアップはちゃんとしようと思った →基本的にZTP+Ansibleなのでバージョンアップも楽
  35. 35. 現在まで運用してみて ● よくよく調べて見るとHadoopの処理中にパケロスが出る ようになってきた。スイッチのASICが何であるか気にな るようになった。。
  36. 36. 今後の計画
  37. 37. 今後の計画 データセンター移設計画 進行中
  38. 38. 今後の計画 こんな構成で進めています
  39. 39. 今後の計画 新DCでのNW構成 ● DC内はIP CLOS構成 ● サーバでBGPを運用、All L3化を計画中 ● パケロスが気になったのでMellanox, Broadcomの 機器検証して両者問題ないことを確認
  40. 40. 今後の計画 機器は… ● DC内はホワイトボックススイッチ ● OSはCumulus Linux ● その他、FW・LBやRouterなどは アプライアンス製品を使用 ● 現在GNS3でVXを動かして検証中

×