ネットワークプログラマビリティ勉強会 #npstudy #5 参加メモ
ネットワークプログラマビリティ勉強会 #5 に参加してきたのでいつものメモです。例によって、機器ながらメモってるので不正確になってるところとかちゃんと記録取り切れていないところとかもありますがその辺はご容赦くだされ。
[追記 2015-07-06]
- Giving is Taking - Networking: ネットワークプログラマビリティ勉強会 #5
- ネットワークプログラマビリティ勉強会 #5 参加メモ | ネットワークエンジニアを目指して - ブログ
会の趣旨
- 初参加の人が減ってきた?
- 経緯
- SDNとかNFVとか。NWEにもソフトウェア開発とかOSSの素養が必要になってきたよね。でもそういう勉強会ってなかったよね。
- 1年前から始めて参加者増えつつ5回目になりました。
- いろんな業界の人から参加してもらうの歓迎。
- 単なるセミナにしないで、有志で話題の提供、意見交換を。
ネットワークプログラマビリティといって直接はまるイベントはないのでは。
- 幅広く、ちょっとでもかすればよいかな。
- 発表ネタ、最近は提供増えてきたけど、ネタは随時募集している。
- 懇親会の時にでも、今やってる取組、いつかやれるかも暗いのがあれば教えてください。
- 企画・運営のボランティア募集中
- いろんな人に入ってきてほしい
会場、前回はGMOさんで
- 同じ会場でやって変に色がつくと嫌だな。会場提供も募集。
しゃべってもらう人へのインセンティブ
- 過去発表者枠を用意してます。
スタッフ枠も同様。協力者募集中。
Twitter hashtag, #npstudy
- 運営者がタイムリーに必ずしも見れているわけではないですが。
- キャンセルは早めにお願いします。直前キャンセルドミノになる。
OpenStack Congress & Datalog, VMware 進藤さん
OpenStack Congress とそこで使われているポリシ言語 Datalog の話。
…をしようと思った理由
- 前々回、宣言的プログラミングの話に触発されて。
OpenStack Congressとは?
- 比較的新しめのサブプロジェクト
- policy as a service を担うプロジェクト。
- なぜ "Congress" ?
- ポリシーが作られるところは議会だよね。
- 一般的なポリシエンジン。どうしても OpenStack の一部でなければ、というわけでもない。なぜ OpenStack なのか? opstにはたくさんのコンポーネントがあって、いろんなしがらみ、ポリシーが必要。いろんな情報をポリシエンジンにデータソースを提供してくれる土壌がある。
ポリシーとは何か?
- 何かしらによって課される制約条件があり、それに対してどうふるまうべきか、を、規定するもの
- 制約…法律・条例・ビジネス上のルール、アプリケーション要求、地理的な制約、セキュリティ上の要求、…- ポリシーを順守させる。
- いろんな角度で定義されるポリシを汎用的に記述するための言語(ポリシ言語)が必要
- Datalog
Datalog
- たくさん亜種・派生がある
- 一階述語論理に基づいた宣言的プログラミング言語
- うまれたのは1970-1980ごろ?
- Prologっぽい文法
- Datalog は見かけ似ているけどいくつか違いがある。
- シンプルな記述しかできない。
- 停止することが保証されている。(Prolog program は書き方間違えると停止しない)
- 節の定義の順序に依存しない。どういう順序で定義してもよい。順序によって効率に違いがあるかもしれないけど、必ず停止する。
- リストの概念がない
- カット、フェイル、というオペレータはない。カット(!): 失敗するとバックトラックするのを切るオペレータ
Syntax
<atom> :- <literal 1>,... head :- body
Datalog のおやくそく
- 停止性(安全性:safety)の保証のためのルール
Datalog の例(1)
Datalog の例(2)
- グラフ、隣接関係の定義
- 再起を使った reachability の定義。
- こうであったと仮定して、という考え方。
これを使うとどんなことができるか?
- いろいろな制約条件をポリシとして記述することができるようになる。
- OpenStack というコンテキストでは
- 現在のクラウドの状態が、定義されたポリシとあっているかどうか、とか。
- ポリシ違反の発見→(action)policy enforceとか。
- 事前に何か違反が起こる雨に simulate することができる。アクションを取った後に状態が正しいものかどうか、というチェックもして、ダメなら修正するみたいなアクション定義もできる
- 自動でも手動でもやれるようになる。
- audit: ポリシは変化していくもの。その時にはどういうエラーがあったのか、という証跡取得
Congress における Datalog syntax
- いまの congress には制約がある。Datalog 再帰表現の実装ができない。(現時点では)
Congress における拡張
- pure Datalog からははみでるところ
- OpenStack : たくさんカラムのあるテーブルの操作, 簡易表記(無名変数よりもうおちょっとおしゃれな表記)
- サポートしているデータソース
- いろんなデータを引き出してポリシを記述できるようになっている
congress policy example
- monitoring
- enforcing
- "Execute" head, アクションをとれる。
Congress Demoしたかったけどdevstackうごかないので
- oslo 対応がうまくいってない
QA
- Prolog的な記述、性能。処理性能、スケーラビリティ
- ちょっと前まではかなり遅かった。最近大幅な性能向上。いまはかなり高速に動く
- だれが書くもの?
- クラウド管理者。一般ユーザが使うものではない。
- ポリシエンジン、classifier, class, action みたいなのを書くのが常套手段と思われる。これを使うことのメリットってどの辺? VMwareが割と力を入れているのはなぜ?
- メリット。比較的スケールあるところ、自分が意図した状態にあるかを人が管理するのは無理だろう。数万インスタンスが全部意図したポリシにマッチするかどうかを人手でやるのは無理。システムでvalidationしたり自動的に修正できるようにactionまわせるようにしましょう、というのが狙いどころ
- Congress は最初 VMware が中心になって始めたプロジェクト。なぜVMwareなのか、というのは明確にはわからないけど、ポリシは重要になると考えているというのはある。Martin Casado が中心になって始めたんだけど、次のクラウドの中心は policy だろう、というのがあって、このプロジェクトを始めたというのがある。
クラウドを活用したシステム構築における、ネットワークのInfrastructure as Code, @qb0C80aE
IaaS/クラウド基盤を使ったシステムの構築が一般的になったんだけど、そこで IaC ってどうなるってはなし。-SDN/一部仮想より・サーバより
- オーケストレーションと自動化
- コード
IaC
- もとはサーバミドル、アプリを含む構成管理の話だった
- 管理されたコードが正。構築されるインフラはそのコード結果を反映したもの。基盤もバージョン管理できる。
- 宣言型プログラミングツールがいろいろ出てきた。chef, puppet, ansible, 冪等性
- Immutable infrastructure, 意味→インフラは常にコードを反映したものである。ということ。構築後に手動変更しない、みたいなところを意味している。
- Blue-Green deployment, まずコードを書いて丸ごと新しい環境作って、テストして問題なければ新しいものに切り替える。これがやれれば冪等性とかきにしないでいいんじゃないの、とか。
- docker container が流行してより身近になってきた。
というのはサーバの中身の話。
もっと広く応用できるように
- ユーザによるプログラミング
- サーバ以外のインフラリソースの制御もAPIでどうにかなるように。
- AWS, OpenStack , ...
- APIでどうにかなるので、サーバだけでなく足回り含めて一連の作業をまとめてコードで実行できるようになった。
NWのコード化?
- サーバエンジニアが必要な形のネットワークリソースの提供。ネットワークはつながるもの、という前提がある。
- クラウド基盤は利用者にネットワークリソースを払い出すために、いろいろなものを連携してネットワークを払いだしている
- API?
neutronをつかったネットワークのコード化例 (python)
- 実際には neutron の裏にあるあれこれとplugin経由で連携している。
オーケストレータ
- いろんな定義がある。クラウド基盤そのもののことを指しているときもある。
- まとめていろいろやってくれる
- 仮想NWの構築、セキュリティグループ(ACL)の設定、依存定義に応じた順序で既存、ボリューム設定、などなど。
- テンプレート例(CFN)
構築した後、ツールで自動テストとかCIとかもできる。
- ネットワークつながる前提なのでその辺は省略
- サーバの状態、設定、動作などの確認ができる。
- blue/green deployment と組み合わせて、富豪的にテスト通ったら古いの全部捨てるとかみたいなのもできる。
- cloudformation, OpenStack heat
- ほかの環境で使うには? フォーマット互換があっても機能が足りないとかいろいろ困ったり。
オーケストレーションの発展
- 使いたいクラウドをうまく組み合わせてシステム構成できるオーケストレータ
- TerraForm, いろいろ混ぜて使えたりする。IaaSだけじゃなくてその上のpaasだけ使いたいとかも。
Terraform
- SDNについて、コントロール層で設定をコード化できるよ、とか書いてある。
- どの基盤の(provisioner)、何のリソース(resource)を、どういうパラメータで?
- 宣言的にテンプレ書いて、dry-run(plan) → apply できたりする。
ここまでのまとめ
ネットワークのコード化に関しての試み
ネットワークの構成要素
- そもそもなんでしょうね?
- 使う人によってほしいもの、話題になる要素は違う。
ネットワークのコードレイヤ
- CloudFormation みたいなの
- 外部DSLをコードにしたNW記述。NWつながるって前提。
- OdenOSなど
ネットワークといっても実現する要素が違う
この辺のありさまを一様に記述できる記法があるんだろうか?
- 提供者も利用者も統一的にNW記述できたら幸せなんじゃないか。
- リソースの種類は追加可能だけど記述は同じにとか。
最近の取り組み
- そういうのを記述できるNWの記述方式の検討というのをお仕事的には初めてみました。
- 産学連携とかでやってるので何か面白いものができたらいいなあ
提供者目線で
- ノードの設定とかもうちょっとどうにかならんのか
- 手続き的設定とノード単位設定は相性が非常に悪い。順序依存、ロールバックで死亡
- OpenDaylight, MD-SALとかひろがったり ENTCONF/YANG とかもうちょっと整備されて
- 宣言的ネットワークコードとか
やれるようにならないかなー
おわりに。
- 物理・仮想、利用者・提供者、そう遠くない将来で汎用サーバとかそう機能だけで完全software definedなせかいがきたりするんかな
- テレコムノードの仮想化とかいう話も最近聞いたし
- サーバ内でのノード使い捨てとかもあるかもしれない。
- どんなネットワーク要素もコードで記述できるようにっていう考え方は無駄ではないんじゃないかなー
QA
- 構成要素、NWを管理する目線で今後言語とか方式とかDBとかの概念というのがこうなればいいんじゃないかとか、いろんなVMとかがあれこれあって全体の構成をシンプルに制御させるとか、そういうのが現実的にあり得るんだろうか?
- まったくできないってことはないと思う。オーケストレーションでそういうの動的に管理したりするのもある。言語でやるところもあるし、システムから一部ダイナミックにやったりというのもある。
- 言語について言うと、こういう言語があればいいな、というのをはじめてる。こんなふうになったらいいね、ってIaaSから提供されるものはそのまま使うし、なければ自分で定義するとか、そういうのがやれるといいな。
- なんとなくNWのプログラミングって宣言的に、という話。NW施文じゃないという人がネットワークになぜ宣言的なものがいいかというのを考えたのか。
- インフラ事態が宣言的であった方がよいのではないか。手続きでは限界がある。いろんなものが宣言的にあった方がよいと思う。収束とかを記述できないんじゃないかとか。
エンタープライズにおける OpenFlow ユースケースを考える, Clorets8lack
資料: エンタープライズにおけるOpen flowユースケースを考える
企業情報システム担当者の目線
- 今のを置き換えるって発想はない
- 泥臭い頑張りが評価されたりされなかったり。数値化・可視化というのがキーワード。運用の効果、定量化、どのくらいやっててどういう費用対効果があるのか。
SDNで目指すもの
- プログラミングは問題解決手段の一つ
- 泥臭い現場運用に改善の余地がありそう。
- 細かすぎてだれも解決してくれない問題をどうにかするってのをやってみたい
- 冗長システムの子tんろーる
- パケットキャプチャによるエビデンスベースの障害対応
冗長システムのコントロール
- 現実の冗長システム: 切り替えがうまくできないことがある。
- 経営的には、予算出してもう大丈夫と思ってて、でもうまく動かなくて落ちたとかどう説明するんだって話。
- 障害の原因究明がやりにくい
- 抜線で試験。ただそれと実際に落ちた状況は異なる。
- サービス復旧優先: 再起動で、というのが多い。リモートでやるってこともあるし。再起動しちゃうと原因究明はもうできない。そういう状況を OpenFlow でなんとかならんのか、と。
システムの冗長機能に依存しない構成を独自に実装してみましょう。
- ちゃんと機能診断をする
- ネットワークを切り替える (OpenFlow)
- 落ちた状況を保全しつつサービスを復旧させる。
監視と切り替え
- サービス監視、自動テストを書いて高度にする。ログインして画面はいって何が出るか、とか。DBの何かを見る、とか。
- 切り替えを確実に・単純に。抜栓テストと同様の結果が得られるものにしましょう。
- 事例、 OpenFlow スイッチの冗長に活用。OFSでトンネリングもやってるのでトンネル終端を複数機器で。ARP の書き換え処理なども。
- Why port-state? (why not network flow?)
- 現時点の状態を取得しやすい。ポートup/down, link LED, ほかの担当者への動作説明。
- 抜線・結線で同じことができる、というアナログな手段で再現できる。
具体的な切り替え手順
- 処理系依存なので一例として。
- あらかじめ downさせておいたリンクをupさせる。インタフェース初期化・状態変化を避ける。
- esxcli, shell, php をくみあわせ
- ポート上がるまでの時間も事前に見ておく
つかいどころ
- 冗長機能のない機会を無理やり冗長化
- HAクラスタが変わった時に切り替わらない時の「ダメ押し」としてつかうってのはどうか。
- 死に掛けの時に落とすとか。
- HAクラスタとか、製品依存が大きいのでものによるかも
やってみた感想
- インタフェース初期化伴うのでポートダウンがつかいにくい
- フェイルオーバー条件を自分で書けるというのはいい
- OpenFlow スイッチ自体の信頼性懸念…何かあったら確実に切り替わる機能があるよ(実装しました)というのが効くかも。
パケットキャプチャによるエビデンスベースの障害対応
- 海外情シス(ヘルプデスク)
- 「ログがないので問題ないと」とか「ログ内からこれ以上調べられねえと」とか
- ログちゃんと出すの難しい。
そもそも
- 適切なログを出すという行為自体がかなり難しい
- ログ機能にもバリエーション、品質がある。
- 過度な期待をしてはいけない。
とりあえず現場どうしようか。
- パケットキャプチャで証拠を突きつけて短く会話する。海外、タイとか、まともに話が通じない。なるべく短く。詳しそうなオーラを出して押し切る。
- そっちの機材がこういう出力出してるよね、そっちの問題だよね、というのをわからせる。
運用上の問題
- ほしいパケットが肝心の時にとれない
- 障害が起きているときは、比較対象になる正常系のパケットがほしい、とか。
- 過ぎ去ってしまった過去のグラフ。機能の謎のピーク…
- 大量のパケットを海外とやり取りしたりできない。
パケットキャプチャの取り方を工夫しようか。
- 常設監視カメラ: 容量大き目のリングバッファで常にキャプチャとる
つくりました
- Sonarman
- 副業で作ってみたけど問い合わせがない。売ってます!!
現場運用、予兆みたいなのをとれるといいんじゃないの?
- キャプチャ大量にとったときにエラー予兆とかやる方法はないのか。
- icmp をつかったチェック
OpenFlow ?
- ミラーポート制御
- 海外の小さい拠点とかだとどういう配線なのかわからなかったりする。WAN側のキャプチャしたいとか。 OpenFlow の推知にあらゆる線を突っ込んで、全部のワイヤに対してvlan tag つけてキャプチャをとる。
- 海外だとプロバイダが来てルータ交換して、元の配線に戻さないとか、そういうことが起きたりする。今本当に現状の結線どうなっているのかを追いかける、みたいなと気に使えたりする。その結線本当にただしいのか、とか、勝手に機材増やしてる、とか。
まとめ
- 現場の運用を泥臭く書くというので見えることもある
- 運用を可視化しつつ、現状維持バイアスとうまく付き合う。
- 情シス部門のNW内製は頑張りすぎると引継ぎできない。
- 今後考えていく。
おねがい
- SDNの便利な使い方があったら教えてください
- sonarman という製品があります!
QA
- 引き継ぎどうしましょう?
- ドキュメントを書きましょう。
- JP1+Extremeでポートを自動的に落とすものをつくったりした。全ポートがシャットダウンして失敗した。今回そういう話ってなかった?
- OpenFlow state をつかって。コントローラのラインは別に作っておいた。意図的に結線を意識して、Aに5本あるなら5本落として切り替える、というのを切り替えないと。ふえていくと48ポート全部落とす手順になりかねないのでちょっと微妙だけど、そういうベタなやり方も。
- ポリシ統合でコントロールできる、みたいな概念が必要?
- 複数システムあって、ポリシベースで、きれいに落とすというのを見通しよく書くというのは重要になるんじゃないか。
- 企業ネットワーク管理、内製に伴う引継ぎとか内製とプログラマビリティのメリットの両立。企業ネットワークにおいてSDN,プログラマビリティって、パッケージがいいのか自生・内製がいいのか。すみわけ
- 実際には情報システム部門の人は、こうやりたいっていうのには弱い。聞かざるを得ないというケースがある。海外の偉いマネージャからやれって言われるとやらざるを得ないこととか。SDNがどういくかによりけりだけど、まずニーズありき。複数の会社が事務所使ってて会議室どうにか、とか。使いやすい状態がどうか、というのをどうやってコーディングしていくか、というのは考えないといけない。
自動でできるかな?, _norin_
- 定型作業の自動化って、今現在どこまでやれるの?
- IaaSとかを作る側
- OpenDaylight, ユーザがアクセスするところ…じゃなくて今回は機械としゃべるところの話。
hypervisor/bare-metal -- L2 ToR -- L3
- インタフェース設定、VLAN,IP設定、リンクあけて通信通す
- エッジ、アクセスに近い機器の話を想定。サーバ接続・回線開通で日々設定するもの
どうやって設定?
SNMPでinterface設定
- snmp set
- MIB, read-only がすごくおおい。設定できるのはほとんどない、くらい。
- C37/C29, private MIB であればやれた。面倒だけどできないことはない。
NETCONF
- A社はSDK買わないと data schema ない?
REST
WebUI
まとめと所感
- 自動化はしやすくなってる
- NETCONF, REST, web
- メッセージボディの規格がまとまってない
- CLI最強
- Command over hogehoge が実装の容易さ+ユーザの使い勝手として一番いい?
- 応答メッセージの解析は今まで通り。
- フォーマットの数だけ手間が増える?
- SNMPは情報取得用と割り切る。
- 割り切ればいろいろとれるし、解析しやすい
- SET可能なMIBが増えれば使い勝手はかなり良くなるんじゃないか。
- NETCONFの使い勝手は対応モデルがどれくらい増えるか次第。
- もう少し対応数が増えないと使い勝手はよくならないんじゃないかなあ
- command埋め込みが一番簡単かなあ
- 自動化したい作業は限られる
- APIが一番必要なのはローエンド〜ミドルエンドのL2/L3スイッチ
- 特殊ハイエンドは自前でいろいろやるでしょう。
- CLI only機器の取り扱い。
おまけ
おわりに
次回9月末、連休翌週とかを想定。
