早くなったみたいです。@yuichi110だれが書くもの?クラウド管理者。一般ユーザが使うものではない。みたいなのを書くのが常套手段と思われる。VMwareが割と力を入れているのはなぜ?メリット。比較的スケールあるところ、自分が意図した状態にあるかを人が管理するのは無理だろう。数万インスタンスが全部意図したポリシにマッチするかどうかを人手でやるのは無理。中心になって始めたプロジェクト。VMwareなのか、というのは明確にはわからないけど、ポリシは重要になると考えているというのはある。いうのがあって、このプロジェクトを始めたというのがある。-SDN/一部仮想より・サーバよりオーケストレーションと自動化コードIaCもとはサーバミドル、アプリを含む構成管理の話だった管理されたコードが正。構築されるインフラはそのコード結果を反映したもの。基盤もバージョン管理できる。宣言型プログラミングツールがいろいろ出てきた。意味→インフラは常にコードを反映したものである。構築後に手動変更しない、みたいなところを意味している。コードを書いて丸ごと新しい環境作って、テストして問題なければ新しいものに切り替える。これがやれれば冪等性とかきにしないでいいんじゃないの、とか。流行してより身近になってきた。いうのはサーバの中身の話。広く応用できるようにユーザによるプログラミングサーバ以外のインフラリソースの制御もAPIでどうにかなるように。...APIでどうにかなるので、サーバだけでなく足回り含めて一連の作業をまとめてコードで実行できるようになった。NWのコード化?サーバエンジニアが必要な形のネットワークリソースの提供。ネットワークはつながるもの、という前提がある。APIの標準になるという話も。個別機能投入もできるように。裏にあるあれこれとplugin経由で連携している。オーケストレータいろんな定義がある。クラウド基盤そのもののことを指しているときもある。所定のコードでシステムのありさまを宣言的あるいは一部手続的に記述し、書いたとおりにリソースを積み上げてIaaSやクラウド基盤上に実現するもの。差分アップデートとかいい感じにやってくれたり。まとめていろいろやってくれる仮想NWの構築、セキュリティグループ(ACL)の設定、依存定義に応じた順序で既存、ボリューム設定、などなど。テンプレート例(CFN)構築した後、ツールで自動テストとかCIとかもできる。ネットワークつながる前提なのでその辺は省略サーバの状態、設定、動作などの確認ができる。組み合わせて、富豪的にテスト通ったら古いの全部捨てるとかみたいなのもできる。フォーマット互換があっても機能が足りないとかいろいろ困ったり。IaaSだけじゃなくてその上のpaasだけ使いたいとかも。TerraformSDNについて、コントロール層で設定をコード化できるよ、とか書いてある。ここまでのまとめサーバだけじゃなくてAPI使ってNWの自動構成ができるようにオーケストレータで宣言的に描いたリソースの組み合わせをもとにIaaS/クラウド基盤に反映できるようになってきた。ネットワークのコード化に関しての試みネットワークの構成要素そもそもなんでしょうね?使う人によってほしいもの、話題になる要素は違う。みたいなの外部DSLをコードにしたNW記述。NWつながるって前提。OdenOSなどプログラム自体をコードとしたNW記述。ほしいトポロジ組む感じ。トポロジコントロール主体。複数レイヤにまたがって管理可能ネットワークといっても実現する要素が違うこの辺のありさまを一様に記述できる記法があるんだろうか?提供者も利用者も統一的にNW記述できたら幸せなんじゃないか。リソースの種類は追加可能だけど記述は同じにとか。最近の取り組みそういうのを記述できるNWの記述方式の検討というのをお仕事的には初めてみました。産学連携とかでやってるので何か面白いものができたらいいなあ提供者目線でノードの設定とかもうちょっとどうにかならんのか手続き的設定とノード単位設定は相性が非常に悪い。definedなせかいがきたりするんかなテレコムノードの仮想化とかいう話も最近聞いたしサーバ内でのノード使い捨てとかもあるかもしれない。どんなネットワーク要素もコードで記述できるようにっていう考え方は無駄ではないんじゃないかなーQA構成要素、NWを管理する目線で今後言語とか方式とかDBとかの概念というのがこうなればいいんじゃないかとか、いろんなVMとかがあれこれあって全体の構成をシンプルに制御させるとか、そういうのが現実的にあり得るんだろうか?まったくできないってことはないと思う。オーケストレーションでそういうの動的に管理したりするのもある。言語でやるところもあるし、システムから一部ダイナミックにやったりというのもある。言語について言うと、こういう言語があればいいな、というのをはじめてる。こんなふうになったらいいね、ってIaaSから提供されるものはそのまま使うし、なければ自分で定義するとか、そういうのがやれるといいな。なんとなくNWのプログラミングって宣言的に、という話。NW施文じゃないという人がネットワークになぜ宣言的なものがいいかというのを考えたのか。インフラ事態が宣言的であった方がよいのではないか。手続きでは限界がある。いろんなものが宣言的にあった方がよいと思う。収束とかを記述できないんじゃないかとか。今のを置き換えるって発想はない泥臭い頑張りが評価されたりされなかったり。数値化・可視化というのがキーワード。運用の効果、定量化、どのくらいやっててどういう費用対効果があるのか。SDNで目指すものプログラミングは問題解決手段の一つ泥臭い現場運用に改善の余地がありそう。切り替えがうまくできないことがある。経営的には、予算出してもう大丈夫と思ってて、でもうまく動かなくて落ちたとかどう説明するんだって話。障害の原因究明がやりにくい抜線で試験。それと実際に落ちた状況は異なる。再起動で、というのが多い。リモートでやるってこともあるし。再起動しちゃうと原因究明はもうできない。なんとかならんのか、と。システムの冗長機能に依存しない構成を独自に実装してみましょう。(OpenFlow)落ちた状況を保全しつつサービスを復旧させる。監視と切り替えサービス監視、自動テストを書いて高度にする。ログインして画面はいって何が出るか、とか。DBの何かを見る、とか。切り替えを確実に・単純に。抜栓テストと同様の結果が得られるものにしましょう。スイッチの冗長に活用。OFSでトンネリングもやってるのでトンネル終端を複数機器で。flow?)現時点の状態を取得しやすい。同じことができる、というアナログな手段で再現できる。処理系依存なので一例として。downさせておいたリンクをupさせる。インタフェース初期化・状態変化を避ける。くみあわせポート上がるまでの時間も事前に見ておくつかいどころ冗長機能のない機会を無理やり冗長化HAクラスタが変わった時に切り替わらない時の「ダメ押し」としてつかうってのはどうか。死に掛けの時に落とすとか。スイッチ自体の信頼性懸念...何かあったら確実に切り替わる機能があるよ(実装しました)というのが効くかも。海外情シス(ヘルプデスク)「ログがないので問題ないと」とか「ログ内からこれ以上調べられねえと」とかログちゃんと出すの難しい。そもそも適切なログを出すという行為自体がかなり難しいログ機能にもバリエーション、品質がある。過度な期待をしてはいけない。パケットキャプチャで証拠を突きつけて短く会話する。海外、タイとか、まともに話が通じない。詳しそうなオーラを出して押し切る。そっちの機材がこういう出力出してるよね、そっちの問題だよね、というのをわからせる。運用上の問題ほしいパケットが肝心の時にとれない障害が起きているときは、比較対象になる正常系のパケットがほしい、とか。過ぎ去ってしまった過去のグラフ。機能の謎のピーク...大量のパケットを海外とやり取りしたりできない。パケットキャプチャの取り方を工夫しようか。DevelUpJapan副業で作ってみたけど問い合わせがない。売ってます!!現場運用、予兆みたいなのをとれるといいんじゃないの?キャプチャ大量にとったときにエラー予兆とかやる方法はないのか。海外の小さい拠点とかだとどういう配線なのかわからなかったりする。WAN側のキャプチャしたいとか。つけてキャプチャをとる。海外だとプロバイダが来てルータ交換して、元の配線に戻さないとか、そういうことが起きたりする。今本当に現状の結線どうなっているのかを追いかける、みたいなと気に使えたりする。その結線本当にただしいのか、とか、勝手に機材増やしてる、とか。まとめ現場の運用を泥臭く書くというので見えることもある運用を可視化しつつ、現状維持バイアスとうまく付き合う。情シス部門のNW内製は頑張りすぎると引継ぎできない。いう製品があります!QA引き継ぎどうしましょう?ドキュメントを書きましょう。JP1+Extremeでポートを自動的に落とすものをつくったりした。全ポートがシャットダウンして失敗した。コントローラのラインは別に作っておいた。意図的に結線を意識して、Aに5本あるなら5本落として切り替える、というのを切り替えないと。ふえていくと48ポート全部落とす手順になりかねないのでちょっと微妙だけど、そういうベタなやり方も。ポリシ統合でコントロールできる、みたいな概念が必要?複数システムあって、ポリシベースで、きれいに落とすというのを見通しよく書くというのは重要になるんじゃないか。企業ネットワーク管理、内製に伴う引継ぎとか内製とプログラマビリティのメリットの両立。企業ネットワークにおいてSDN,プログラマビリティって、パッケージがいいのか自生・内製がいいのか。すみわけ実際には情報システム部門の人は、こうやりたいっていうのには弱い。聞かざるを得ないというケースがある。海外の偉いマネージャからやれって言われるとやらざるを得ないこととか。SDNがどういくかによりけりだけど、まずニーズありき。複数の会社が事務所使ってて会議室どうにか、とか。使いやすい状態がどうか、というのをどうやってコーディングしていくか、というのは考えないといけない。ユーザがアクセスするところ...じゃなくて今回は機械としゃべるところの話。L3インタフェース設定、VLAN,IP設定、リンクあけて通信通すエッジ、アクセスに近い機器の話を想定。設定できるのはほとんどない、くらい。面倒だけどできないことはない。実装の容易さ+ユーザの使い勝手として一番いい?応答メッセージの解析は今まで通り。フォーマットの数だけ手間が増える?SNMPは情報取得用と割り切る。割り切ればいろいろとれるし、解析しやすいSET可能なMIBが増えれば使い勝手はかなり良くなるんじゃないか。NETCONFの使い勝手は対応モデルがどれくらい増えるか次第。backboneとかだとまた別かもしれないけど。エッジに近いところ、冪等なところからやる。順序・依存があるような密結合システムはサーバサイドでも自動化は難しいAPIが一番必要なのはローエンド〜ミドルエンドのL2/L3スイッチ特殊ハイエンドは自前でいろいろやるでしょう。only機器の取り扱い。SDKかえって言われるとちょっとつらいなあ。?southboundをベンダから提供されるといいんだけど。ローエンド機器、古い機械。SOAPオブジェクト設計がいまどきおわりに次回9月末、連休翌週とかを想定。参加メモ久しぶりに勉強会行ってきました。理解する(3)月別アーカイブはてなブログをはじめよう!stereocatさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。