2015年7月4日土曜日

ネットワークプログラマビリティ勉強会 #5

開催概要

OpenStack CongressとDatalog

  • @motonori_shindo さん
  • 今回のタイトルの背景
    • 前々々回の宣言的言語に触発された。
  • OpenStack Congressとは
    • Policy as a Service をになうプロジェクト
    • Congress = 議会 というところから、Policy を制定するところ というイメージ。
    • Standaloneでも動作するが、OpenStackと一緒に動作するのが、もっとも効果的。
    • https://github.com/openstack/congress
  • Policyとは？
    • 何かしらによって課される制約に対して、どうあるべきかを規定するもの
      • 法律
      • ビジネスルール
      • セキュリティ要件
      • など
  • 汎用的なPolicy Language
    • Datalog
    • 一階述語論理に基づいた宣言的論プログラミング言語
      • DSL
    • 1970年代からある
    • Prologに似ている
      • 会場でPrologを5行以上書いたことある人
        • 多少いた
      • PrologとDatalogの違い
        • 停止することが保証されている
        • Function symbolがない
        • 節の順序は無関係
        • リストの概念がない
        • カット(!)やfail(強制させる)オペレータがない
    • 書式
      • ヘッド :- ボディ
      • <atom> :- <literal 1>, <literal 2>, <literal 3>, .. <literal N>
      • literal 1, 2, .. Nがなりたてばatomがなりたつ
    • Safty Properties
    • Datalog(Prolog)書き方
      • ファクト
      • ルール
      • そして問い合わせ
    • 用途
      • Monitoring
        • ポリシーを照らしあわして、もしミスマッチがあればレポートする
      • Enforcement
        • 違反があったら回避するアクションをとる
      • Audiing
        • PolicyやPolicy違反の履歴管理
    • 制約
      • いまは再帰のルールはできない
    • サポートしているCongress 用ドライバ
      • OpenStackファミリ
      • :
      • vCenter

QA

  • 性能は？
    • ちょっと前まではすごく遅かった。最近大幅向上している。何百台。
  • だれがかくのか？
    • クラウド管理者がかく。ユーザーがかくものではない
  • メリットは？
    • 意図した状態を保つのは難しい。システムでなんとかしたい
  • なぜVMWareが力をいれている
    • VMWareが最初スタートしたからかな。

感想

OpenStackでないシステムであれば、ZabbixとかNagiosが監視、アクションをやっている。 ここではSNMPだったり、サーバにエージェント入れたりして、いろいろやっている。 OpenStackで統一的なポリシー管理の仕組みを作ると統一できるってことかな。 OpenStackを目指して、vendorが仕組みを統一できるといろいろメリットはありそうな気がした。 (NETCONFとかも一緒か)

クラウドを活用したシステム構築における、ネットワークのInfrastructure as Code

  • @qb0C80aE さん
  • 今日の話
    • SDN
    • オーケストレーション
    • その他
  • Infrastructure as a Code
    • 管理されたコードが正
  • Infrastructure as a Codeおさらい
    • Chef, Puppet, Ansible とか
    • 最近の概念
      • Immutable
      • Blue-Green Deployment
        • Immutable、Blue-Greenなら冪等性いらないよね→シンプルになる
  • AWS、OpenStackとかIaaS
    • APIで制御できる
    • この場合のコード化は
      • 利用側からみたもの
      • IaaSが隠蔽している
      • OpenStack Neutron API
        • Extentionで拡張できる
        • プログラムを書いて、丸投げして、
      • オーケストレータ
        • コードを宣言的 or 一部手続き的に記述し、書いたとおりにリソースを積み上げて実現
        • CloudFormation
          • JSONでかくとできる
      • テストも自動化でできる
        • ServerspecとかInfratasterとか
      • オーケストレーションの発展
        • 使いたいクラウドをうまく組み合わせてシステムを構築できる
        • Terraform
          • provisionerで定義
            • 使えるモノが変わってくる
        • resourceで定義
  • ネットワークの構成要素
    • ネットワークの構成要素とは。
      • Node?Link?Patch?…
      • 人によって全然違う。
  • CloudFormationみたいなモノ
    • OdenOS
      • トポロジのコントロールが主体
  • コード記述の標準フォーマット
    • ないのかな？
    • 作りたいなということで動き始めた
    • 上から下まで設定できたらいいな

QA

  • ネットワークを管理する目線で言語、記載方式とかの概念をがんばって、いまのやつでできるのか？
    • オーケストレーションとかでけっこうできる。ありものはありものでかけるっていうのができるといいな と。
  • ネットワークの設定とかは共通的になってきたのかな。ネットワークがなぜ宣言的になったほうがよい？
    • 手続きだと辛い。インフラ(ネットワーク含む)が宣言的にできるといいな。でもなかなか難しい。

感想

ネットワーク機器のマネジメントについては、既存の機器を考えるとなかなか難しいな。 基本的な部分だけでも(どこまでが基本的な部分か というのが人によって違うのだろうけど。)、 統一的に設定できるようになるとうれしいかもしれない。 そういう意味では、TerraformとかServerspec(Specinfra)のようにprovidorというか、実装は 泥臭いことをしているけど、ユーザーはJSONを書けばそれなりにできるとかがあるといいのかもしれない。 (過去機種もCLIとかでいろいろやれば、なんとかなるだろうし。(基本的なところは！))

エンタープライズにおけるOpenflowユースケースを考える

  • @Clorets8lack さん

− 資料

  • 会場の情シス担当者は？
    • ほとんどいない。。
  • エンタープライズ運用担当者の特徴
    • 既存のネットワークを置き換えるという発想はない
      • もどせるとうれしい
    • 「可視化」がキーワード
      • 運用定量化と効果計測のため数値化を常に考えている
  • SDN
    • プログラミングは解決手段の一つ
  • ユースケース2つ
    • 冗長システムのコントロール
      • 問題点
        • 切り替えがうまくできないコトがある
          • ハングアップなど、ダウン検知が難しい障害がある
          • 情シス担当者には最悪
            • 2倍払って、なに？これ？ と経営からいわれる。
      • 解決方法
        • サービス監視を高度化する
          • 自動テストを書いて、それを流す(高度な死活監視)
        • 切り替え処理を単純/確実化
          • 抜線と一緒にする(ポートStateの制御)
        • なぜフロー制御でなく、ポートStateの制御なのか？
          • 現時点で状態が把握しやすい LEDとかで見やすい
          • 他の担当に動作を説明しやすい
          • アナログな手段で容易に再現可能(本当に線を抜くとか)
        • 具体的な切り替え手順
          • NICチーミングを使う
          • 優先I/Fをあらかじめダウンさせておく
        • 使いどころ
          • 冗長機能がない製品を無理矢理冗長構成をする
          • HAクラスタ製品のだめ押し
        • やってみた感想
          • 障害状態の保存という移管点では、ポートダウンが使いづらい
    • パケットキャプチャによるエビデンスベースの障害対応
      • 海外情シスあるある
        • 「エラーログが出ていないのでこちらに問題はありません」
        • 「ログがないのでこれ以上調べられません」
      • エラーログが正しく出されているとは限らない
      • それなら
        • パケットキャプチャで証拠を突きつけて「短く」会話する
        • 詳しそうなオーラを出して押し切る
      • 運用上の問題
        • 再現できない
      • 解決方法
        • 容量を大きめのリングバッファでパケットをキャプチャしておく
        • 問題が発生したらそのパケットを保存しておく
          • Sonarmanというものを作りました
        • OpenFlowでミラーポートを制御
        • ポートごとにVLAN TAGをつけるとあとでわかりやすい
          • 海外だと元の配線にしないで帰るとかあるので、これで助かる

QA

  • 引き継ぎの話をどうするの？
    • ドキュメント書きましょう。現場の人しかわからないことが多いので、現場で伝えられるように。
  • 昔のやつでいろいろやったら、すべてのポートがシャットダウンしたことがあった、気をつけていることは？
    • 全部が切れることはなかった
    • 5本入っています、全部、5本切り替える とか気にするところはある
  • 運用と自分でのプログラムするのの両立は？
    • 情シスは現場のやりたいというのい弱い。
    • ニーズありきで、どうやるか。同じ居室の会議室を2社でどのように利用するか など、そういうときに課題解決できるかな。
    • これからどう両立するかは考えないといけない

感想

前回に引き続き、非常におもしろい話だった。 情シスのひとはあまりこういう勉強会にはでてこないのかな。 情シスのひとで、運用のためにコード書いている人はあまりみないし。 (外部の業者さんが書いていたりするのだろう)

運用の自動化のためにプログラム書いたりすると、属人性があがってしまうところは、もどかしい。 情シスで「高度自動化チーム」とかを作って、そこのチームでは使用言語とか仕組みを統一する とかがいいのかもしれない。 (このチームもどのくらい効果があるか、とかを可視化しないといけないのか。。。)

自動でできるかな？

  • @_norin_ さん
    • データセンターの中のひと
  • きょうの話
    • 定型作業の自動化、その結果
    • 機械と話をするところ
  • シナリオ
    • L2-ホスト間のInterfaceを設定して、L3でping確認する
  • How
    • CLI
      • 最強。人間には優しいが、自動化はやりにくい。
    • SNMP
      • Link UP/Down
        • snmpset … IF-MIB::ifAdminStatus
      • Duplexなど他はほとんどreadonly
        • VLANはprivate MIBにある
      • 敗北。。
    • NETCONF
      • 古い機器にはない。
      • 新しいのも結構ばらばら
      • CLI over NETCONFみたいのがあるが、結局これで十分？
    • REST
      • 3750ではHTTPでコマンドをいれられる
      • マニュアルとかでは見つからなからない？
    • Web UI
      • LiveHTTPHeaderとかで見て、やればいける。
  • 今後の課題
    • メッセージボディの規格がまとまっていない
    • 古い機械をどうやってすくっていくか。

QA

  • 時間不足のためQAは懇親会パートで！

感想

新しいネットワーク機器だと、だいぶ、自動化やりやすくなっているのかなと思う。 EsxiとかもRubyのライブラリでけっこう簡単にいろいろできる。 利用シーンを限定すれば、L2スイッチとかでも自動化はまぁまぁいけるのかな。 なかなか汎用的なものは作れないので、ネットワーク技術者が利用シーンに応じて、 プログラミングして、自動化するのが現実的なのかもしれない。 ただ、このあたりは情シスの課題と同じかな。(属人的になるとその人がいなくなると終わる。。)

投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)