ネットワークプログラマビリティ勉強会 #5 参加メモ
ネットワークプログラマビリティ勉強会 #5 に参加してきました。
ネットワークプログラマビリティ勉強会 #5 – connpass
以下個人的メモです。
OpenStack CongressとDatalog VMware 進藤氏
OpenStack Congressとは?
OpenStack Congress で使われているポリシ言語Datalogの話。
OpenStack Congressは新しくて、1年目ぐらいのプロジェクト。
ポリシーとは?
何かしらによって課される制約条件に対してどのように振る舞うべきかを規定するもの
- 法律・条例
- ビジネスルール
- アプリ要求
- 地域的制約
- セキュリティ要件
これらを遵守させていく必要があるため、これらを記述するためのポリシーランゲージが必要。
CongressではDatalogを採用している。
Datalog
一階述語論理にもとづいた宣言的論プログラミング言語
文法的にはPrologに似ているが以下が違う
- Function Symbolがない
- 停止することが保証されている
- 節の順序は無関係
- リストの概念がない
- カットやFailオペレータがない
Congressでできること
- Monitoring
クラウドの現在の状態とポリシーを照らし合わせて、ミスマッチがあればレポートする - Enforcement
ポリシー違反を回避するためになにかアクションを取る
proactively / reactively / interactively - Auditing
ポリシーやポリシー違反の履歴管理
QA
- Congressのスケールは?
ちょっと前まではかなり遅くなったけど、最近は高速に動作するようになっている。 - Congressを書くのは誰?
クラウドを管理している人が使うもの - Congressを使うことのメリットは?
規模が大きいクラウドだと管理が大変
何千何万というインスタンスを人が管理するのは大変なので、システムで何とかするってのがメリット - VMwareが力入れる理由は?
vmwareが当初中心になって始まったメリットなので。
次のクラウドの主戦場になるという信念のもと始まった。
クラウドを活用したシステム構築における、ネットワークのInfrastructure as Code @qb0C80aE氏
Infrastructure as Code
サーバのミドルウェアやアプリを含む構成管理
管理されたコードが正、構築されたインフラはそのコードの実行結果を反映したもの
宣言型のプロビツールは何度やっても同じ状態になる。chefとかansibleとかpuppetとか。
- Immutable infrastructure
サーバを一度セットアップしたら二度と変更を加えないという運用スタイル - Blue Green deployment
バージョンアップ時に新規でサーバーを構築して、問題無ければ丸ごと交換して古いモノは破棄するという考え方。Dockerとか。
最近はAPI操作でサーバー以外もコントロールできるようになっている。
- ネットワーク構築して
- サーバー起動して
- サーバー整備して
- クラスタ監視して
と、全て自動化出来るようになった。
有名なネットワークAPIの標準化になるといわれているのが、OpenstackのNeutron API。
オーケストレータ
定義はさまざま。
使いたいクラウドをうまく組み合わせてシステムを構成出来るオーケストレータがでてきた。
→ TERRAFORM
まとめ
- サーバーだけでなくネットワークの自動構成は当たり前。
- オーケでいろんなリソースの組み合わせを反映できる。
- コードで複数環境のリソースを使えるようになった。
ネットワークのコード化による試み
ネットワークの構成要素は多種多様
- CloudFormation
NWはつながる前提 - OdenOSとか
OdenOS
O3プロジェクト
トポロジのコントロールが主体
複数レイヤに跨がって管理可能
提供者も利用者も統一的な書き方でネットワークが定義できたら幸せ!
ツールも作りやすくなるし。
ということで、このへんを業務で始めました。
エンタープライズにおけるOpenflowユースケースを考える Clorets8lack
EP担当者の目線
- 既存のNWを置き換える発想はない
現在動いている環境にアドオンするのが前提
何かあったら元に戻せると素晴らしい - 可視化がキーワード
上層への説明がしやすいことは重要
運用定量化と効果計測のための数値化が重要
冗長システムのコントロール
冗長システムの問題
- 切替がうまくできない
- 事前に行った切替試験が役に立たない
- 障害の原因究明がやりにく
これらをOpenFlowで解決
死活監視の高度化
ソフトウェアによる高度な死活監視
ネットワーク側の制御により障害状態を残しつつ復旧させる
- サービス監視を高度化
- 切替処理を単純化
- 結果的に止まらないシステムを作る
事例
- OpenFlowスイッチの冗長に活用
- 何故フロー制御でなく
パケットキャプチャによるエビデンスベースの障害対応
海外情シスあるある
- エラーログがでていないのでこちらに問題はありません
- ログが無いのでこれ以上調べられません
- ログをきちんと出力させるのは難しい
適切なログを出すという行為は本質的にエラーの先回りであり、想定していないエラーでは適切なメッセージにはならない
ログ出力には過度な期待はしない
どうするか?
- パケットキャプチャを突きつける
- 詳しそうなオーラを出して押し切る
運用上の問題
- 肝心なときに欲しいパケットが入手できない
- 目的のパケットを探すのに手間取る
パケットキャプチャの取り方を工夫する
作った
Sonarman
副業で作ったけど問い合わせ無し。。。買って下さい。
エラー検知と連携
ICMPを使って予兆検知
OpenFlowでミラーポート制御
OpenFlowスイッチにケーブルをぶっ込んで、キャプチャしたいものを抜き出す。
海外とかだとどういう配線なのかわからなかったり、WAN側回線をキャプチャしたいとかもある。
海外だとプロバイダが来てルータ交換して、元の配線に戻さないとか普通にある。
まとめ
- 泥臭く書くことで見えてくる
- 運用を可視化しつつ、現状維持バイアスと上手く付き合う
- 情シス部門の内製は懲りすぎると引き継ぎで死ぬ
QA
- 引き継ぎどうすんの?
ドキュメントをちゃんと書く - 昔、JP1とExtremeでポートを自動的に落とすものをつくったところ、全ポートがシャットダウンして大失敗したことあるけど、そんなことって無かった?
OpenFlow state をうまくつかうようにしている。
自動でできるかな? norin
定型作業の自動化がどこまで出来るかやってみた
ハイパーバイザとベアメタルをL2/L3スイッチに繋いで疎通出来るまでを自動化してみた
SNMPでやってみた
snmpsetコマンドを使用
Read-OnlyなMIBが多くて使えない。。
プライベートMIBで出来る機器もあるけど、プライベートMIBが無い機器もあったり。。
NetConfでやってみた
対応製品が少ない
REST
対応製品が少ないけど、イマドキな機器は対応している。
WebGUI
略
まとめ
- 自動化はしやすくなっているが、メッセージボディの規格がまとまってない
- CLI最強
- SNMPは情報取得用と割り切る
- NETCONFの使い勝手は対応モデルの数次第
- APIが必要なのはローエンド〜ミドルエンドの機器
ハイエンド機器は特殊なエンジニアが特殊ないじり方をする - CLIオンリーな機器の扱い
今まで通り、Telnet + expectで頑張る
終わりに
次回は9月末ぐらいを予定