2016年12月22日

2度目の投稿となりますCloud&SDN研究所の加藤です。

12月06日から08日の4日間、沖縄オープンラボラトリ主催のオープンテクノロジーのイベントである「Okinawa Open Days 2016」が開催されました。今回、4日目の「ホワイトボックススイッチユーザ会」にてホワイトボックススイッチユーザ事例として一枠頂き、登壇をさせて頂きました。折角の会社ブログですので、当日話しました内容+αをblogにも投稿いたします。

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

昨今、主流のネットワーク機器はベンダ謹製ソフトウェア (OSやルーティングソフトウェア) が専用の構成となったハードウェアに載って提供されますが、ホワイトボックススイッチはQuantaAcctonなどのODM (Original Design Manifacture) ベンダによって提供される汎用シリコンを使い、汎用的に設計されたスイッチになります。ホワイトボックススイッチは汎用構成であるが故、ハードウェアの上に乗るOSやルーティングなどのソフトウェアについても(だいたい)同じように動き、ソフトウェアの取捨選択、さらにはハードウェアの取捨選択が期待できる筐体になります。

Cumulus Linuxとは?

Cumulus LinuxはCumulus Networksが出した、ホワイトボックススイッチの為のDebian GNU/Linux派生の商用Linuxになります。Cumulus Linuxがインストールされたスイッチは完全にLinuxサーバとして管理が可能となり、SSH越しにLinuxコマンドを叩いて操作をしていきます。ネットワーク機器の設定変更ですとLinuxで使うipコマンドであったり、brctlであったりを利用可能で、サーバ感覚でスイッチの設定が行えます。運用でどのスイッチにも必ず設定を行うSNMPであったりSyslogについても、/etc/snmp/snmpd.confや /etc/rsyslog.d/* を編集したりで、サーバ管理者には馴染みの設定方法かと思います。その他、限られたハードウェア資源にはなるもののアプリケーションを追加して、何かのサーバとして動かしたり等々もできるようになる柔軟なネットワークOSになります。

スイッチ設定の概要

Bridge設定の基本

Cumulus Linuxのスイッチング周りの設定は基本/etc/network/interfaces周りで操作を行います。スイッチの各ポートはswp[n]という名前でネットワークインターフェイスが登録され、”ip link show”をしますと48ポートのポートがある場合はswp1からswp48がずらっと並びます。認識されたそれぞれを /etc/network/interfaces へ Debian流儀の書き方で

auto  br-VLAN100
iface br-VLAN100
  bridge-ports swp1.100 swp2.100
  bridge-stp on
auto  br-VLAN200
iface br-VLAN200
  bridge-ports swp1.200 swp2.200
  bridge-stp on

として書くことが基本の設定 (Traditionalモード) となります。しかし、従来のLinuxサーバ的にスイッチ管理を行う場合、管理するvlanが増えるたび都度まとめたBridgeを分けたりする必要があったりで管理が煩雑となる為、解決として複数vlanを使用する場合は Cumulus Linux独自の拡張のモード (vlan-awareモード) を使うことが推奨されています。

auto  bridge
iface bridge
  bridge-vlan-aware yes
  bridge-ports glob swp1-48
  bridge-vids 100 200
  bridge-pvid 1
  bridge-stp on

これにより多数ポート多数vlanを一つのBridgeに纏めることができ、簡素化できます。ただ、一見vlan-awareモードが万能に見えますがスイッチ筐体に対してvlan-awareは一つのBridgeしかサポートされていないのと、Traditionalモードについては vlan変換箱 (vlan100 -> vlan200 ※) として動作させる際には使いますので、用途に応じて各モードを使い分ける必要があります。

※ TraditionalモードによるVLAN変換設定

$ echo "Reference https://docs.cumulusnetworks.com/display/DOCS/VLAN+Tagging"
$ echo net.bridge.bridge-allow-multiple-vlans = 1 | sudo tee /etc/sysctl.d/multiple_vlans.conf
$ sudo sysctl -p /etc/sysctl.d/multiple_vlans.conf
$ sudo brctl addif br_mix swp10.100 swp11.200

スイッチ設定の所感

私自身は職歴的にはやっとここ数年でJUNOSやIOS等々一通り触ることができるようになりましたが、これらを触った後にCumulus Linuxを触ると一つの違和感が出てきました。「Bridge設定の向き」です。通常のスイッチはCLIから各ポートの設定は、”各ポートに対してブリッジの設定”を行いますが、Linux的なBridgeの場合”Bridge設定からポートに紐付ける設定”で使うポートを割り当てます。JUNOSやIOSでも一括操作はできるため操作の煩雑さは減らせるもののポート毎の設定が基本となり、後からのコンフィグから見直しをする場合Bridge側から割り当てる方がすっきりして分かりやすいのかな、という私の所感でした。ただ、この設定方法の違いは恐らくはポートをきめ細かく事故が無いように設定を作り続けるネットワーク系OSと自由にBridgeを作って割り当てては壊すサーバ系OSの文化からきた設定方法の違いからなのだろうなと想像します。

スイッチ設定の自動化と群体管理

Cumulus Linuxは一般的なLinuxサーバであり、sshdが管理用に動いています。加えて標準でPythonも動くため、構成管理と自動化にはスイッチもサーバと同じ扱いでAnsibleを使って自動化ができます。当研究所の構築事例ではAnsibleにて初期構築 (管理ユーザ追加、デフォルトユーザ削除、ライセンス適用、SNMP/Syslog設定、監視ツール設定、初期Bridge設定) を冪等性ある形で一斉に行います。構成管理としてはChef/Puppet/Ansible…etcなどサーバ運用で長く蓄積されたノウハウを利用しない手はなく、これによりCumulusLinuxがを一括で管理ができるほか運用設計次第でほかのサービス用サーバと同じ方法でデプロイから管理まで進めることができます。またCloud&SDN研究所はAnsibleを意識的に構成管理・デプロイ用としてのみに使用し、スイッチに対する細かいオペレーションについては Consul を使ってスイッチもLinuxノードの一つとして群体管理を行うようにしました。Consulによりコントローラからの死活監視と異常時のSlackへの発報や、トラブルシューティング時のコマンド各スイッチへ発行することができます。全スイッチがCumulusLinux想定ではありますが、例えばどこかでL2のループをしたり端末がマルウェア感染した場合、該当のMACアドレスを各スイッチのfdbから浚って所在を特定するのがスイッチ側からの対応方法になりますが、”consul exec ‘bridge fdb show |grep [MAC-ADDRESS]'”とコマンドを発行しますと、consul管理下のLinuxスイッチがそれぞれfdbを攫って、該当のMACアドレスがどのスイッチのどのポートにいるかを見ることができます。ここで気づいたのは、「あったら便利だな」と思って設定をしていたら自然と従来のスイッチにできないことを自分達で盛り込んで運用をしていたことです。

ホワイトボックススイッチの所感

今回のホワイトボックススイッチについての投稿は、手元にあったCumulus Linuxを元に話を構成したため、どうしてもCumulus Linux寄りの内容になってしまいましたが、決まった箱と決まったソフトウェアから外れたホワイトボックススイッチは今までにないスイッチの管理方法を試すことが出来たり、ネットワーク製品の土台になり得る筐体であると実感しております。今回のホワイトボックススイッチユーザ会ではCumulus Linux以外のOSを載せた正しくホワイトボックスらしいBig Switch Networks様のSwitch Lightを用いたBig Cloud FablicやBig Monitoring Fabric、ip-infusion様のキャリア向け対応が可能なOcNOSなど多数のOSが出来る事の発表もありました。いずれも対応状況に差異は多少のあるもののメジャーどころの箱はいずれもサポートされ、ホワイトボックススイッチは筐体が同じであっても、出来る事が載せるソフトウェア製品や運用者によって大きく変わってきます。ホワイトボックス自体は汎用シリコンを用いたりODMベンダからの直接購入からのコスト削減がメリットとして挙げられますが、数台購入して使ってみてから言えることは大量購入によるコストメリットは確かに期待ができるものの、それ以上に今までにないことを新しく組み込むができることや、製品土台としてハードウェアのみもしくはOS込みで選定して、自分達で新しい機能やサービスを作ることができる筐体である事が一番大きいメリットなのかもしれません。今回のユーザ会が国内でのホワイトボックススイッチ導入の際の何かの役に立ちましたら幸いです。

12月08日ホワイトボックスユーザー会 発表資料

※高画質版はOkinawa Open Days 2016プログラムよりダウンロード可能です。

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。