ラベル ネットワークプログラマビリティ勉強会 の投稿を表示しています。 すべての投稿を表示
ラベル ネットワークプログラマビリティ勉強会 の投稿を表示しています。 すべての投稿を表示

2016年3月2日水曜日

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

開催概要

他のまとめ

感想

今回はOVS関連の話を聞けた。 いろんなレイヤーの「ネットワークプログラミング」が聞けてよかった。

OVN (Open Virtual Network) について

  • 進藤資訓（@motonorishindo）さん
  • OVS2.5.0がリリースされた
    • OVNも含まれる(Experimental)
  • オープンな仮想ネットワークの実装
    • L2、L3、Security Group、ACL、トンネル、物理スイッチ連携
  • 目指すところ
    • 商用で使えるようなクオリティを目指す
    • OpenStackとのよりよい連携
  • OVNの構成
    • northd
      • northからsouthに変換する
      • Restful APIではなくDBでのアクセス
      • northband DB
        • 望まれる状態を保持する
          • 物理的なものには入らない
      • southband DB
        • ランタイムで変わる内容
    • controller
      • HVごとに動く分散のコントローラ
  • OpenStackとの連携
    • これまで
      • 複雑
        • iptablesとかをOVN Nativeで
  • チュートリアル
  • OVNで使えるカプセル化
    • 要件
      • メタデータのサポート
      • マルチパスとの親和性
      • ハードウェアアクセラレーション
    • サポートされているのは Geneve、STT、VXLAN
  • OVNとNSX
    • 競合するものではない
      • OVNは"SDNコントローラ"を目指していない
        • FocusはOpenStack
      • NSXはよりリッチな
  • 質疑
  • OVNはいまはOpenStackのpluginの一部
  • まだ開発中
    • floating IPとかもまだ
  • OVNとOpenStackは結構絡んでいる
  • ロジカルフローの例
    • 物理的な語彙はでてこない
    • どの物理ポートとかはない
  • OVNで簡単なことやったら結構フローになっていたトラブルシュートは？
    • 難しい
      • 非常にシンドイ
      • OpenFlowのテーブルを直接書くのはアセンブラを直接読み書きしているのと同じ
      • 抽象化が必要。

ELKではじめるホームネットワーク監視

  • urkr さん
    • ネットワークプリセールスエンジニア
  • ELK
    • Elasticsearch/Logstash/Kibana
      • OSS
        • 勢いがある
  • UTMを入手
    • GUIからではログが見えない
    • Syslogサーバ、兼、NetFlowコレクタを
  • Logstash -> Elasticsearch
  • Kibana -> Elasticsearch
  • Kibana Dashboardを作って満足プロセスが必要
  • Flexible NetFlowの受け取り方： 仕組みが用意されている
    • TLV形式で定義されている
  • vagrant boxとかdockerでできるものがあったらいいかな
  • UTMとかについて気軽にできるとよいかな

機械学習によるリモートネットワークの異常検知

  • @Clorets8lack さん
  • 海外のネットワーク管理
    • 距離と時差
      • 損失と遅延
    • インド 600ms
      • さすが天竺
    • なかなか現地にいけない
    • USのをインドに展開というのは難しい
    • 人件費が安い
    • スイッチが買えないところもある
    • 静電気が異常にでる国がある
    • 現地ベンダに任せきりになってしまう
      • 信頼関係の構築が必要
      • 高度なトラブルシュート
    • Sonarmanでパケットキャプチャしたファイルから障害検知
      • いろいろな地域のネットワークでは、しきい値の設定が難しい
      • 「普段の状態」を定義する
        • 明らかに逸脱した状態を異常とする
      • エラーカウンタ70項目と時間密度から標準偏差を求めて70以上は異常と判断
    • 事例が溜まったら
    • 過去の同一時刻とか、曜日、月末、月初とか
    • いっぱつレッドの例も定義
    • Cで実装していたけど、IPv6まわりが大変
    • Wiresharkのフィルタを使う
      • 経験を活かしている
    • HWを海外に送るのは大変→VMにした
    • 見つかったモノ
      • BYODのAndroidのdhcpdの不具合
      • TCP/UDP比率でウィルス
      • けっこうよい精度で問題に到達できている
    • 感想
      • 可視化して仕事が増える
        • 自分と他人も
    • 情シス考
      • いろいろな情シス部門がいる
      • バリバリパケット読む人はいない
      • 可視化ツールいれたけど、見ていない
      • ターゲット間違ってね？
      • 問題発見ツールとして提案活動
        • ソリューション営業
  • 実働の人がやれているというのはいい
  • データセンター、サイバーエージェントとかはほしがっている
  • 機械学習での故障検知はいろいろでている

openvswitchのステートフルなアレとかL3なアレをOpenFlow越しにアレコレする

  • @shun159 さん
  • OVS新しそうな機能
    • arp
    • コントラック
    • NATもできるように
      • kernelにパッチを当てる必要
      • 未リリースのOVSを使う必要がある
    • OVSのこの機能はOFのベンダー機能
      • Nicira Extensionの一部
        • OVS

ブラウザからルータを操作してみた

  • @kooshin さん
  • GUI
    • いろいろ開発大変
      • 結局、詳細はCUIで見る方がよい
  • GUIとCUIのいいとこ取り
    • ブラウザ上でGUIで概略を見て、詳細はCUI(tty)で見る
  • Rubyとgotty
投稿者 時刻: 0 件のコメント:
ラベル:

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 件のコメント:
ラベル:

2015年4月26日日曜日

ネットワークプログラマビリティ勉強会 #4 @GMO Yours

ネットワークプログラマビリティ勉強会 #4 @GMO Yours

開催概要

他のかたのまとめ

いろいろまとめられているので、全体的なのは他のかたのメモを参照してください。

感想

今回は、LTの発表をしたせいで、あまり他の人の発表をこころの余裕をもって聞くことができませんでしたが、 自分としては発表することで自分が知りたい内容がしれたのでよかったと思います。
一番大きい収穫は、この勉強会にどのような人が来ているか？ということがわかったことです。 「ネットワークエンジニア」というのは、範囲が非常に広いので、発表者がどのような人をターゲットに話をしたら いいのかが難しいと思っていたからです。
今回の超おおざっぱな私の集計によると、次のようになっています。(重複含む。全体人数は100人くらい)
TypeRelated toHow many people at this study?
SDNOpenFlow, OpenStack20 people
InternetBGP10 people
IntranetWAN, Inter DC15 people
DC internalFirewall, Load balancer,L2/L3 switch30 people
Platform ServiceDNS, mail, proxy20 people
ServerLinux, Windows,20 people
ApplicationWeb Service, Mail Service10 people
全体として、SDNとかをいま使っている人は20%くらいで、80%の人はSDNとかに興味はあるけど、 いまの活動としてはあまり使っていないということでした。 DNS, mailとかの基盤サービスをやっている人も結構いて、「ネットワークエンジニア」が広いということがわかりました。 (自分の中の仮説どおりです。)
よかったことと、改善できたらいいな ということをまとめるとこんな感じです。

よかったこと

  • #npstudy というハッシュタグがついたことで、いろいろ情報がまとまったこと
  • どんな人が参加しているかがわかったこと
  • 具体的なプログラミングのことになると、けっこう、一歩引いてしまうということがわかったこと
  • 会場設備がよくて、Wifiやドリンクも提供していただいたこと(GMOさんありがとうございます)

改善できたらいいな ということ

  • 終了がギリギリになってしまって、懇親があまりできなかったこと
    • LTでは質問を受け付けず、会場での懇親の場(30分でも)で聞いてくださいのほうがよかったかもですね

発表

自分の気持ち的に、全体の発表はあまり見れなかったので、自分の発表のところだけ。。

ネットワークのテスト自動化(Network Test Automation) @otahi


ネットワークテストの自動化して、インシデント対応などでの「ダブルチェック」の再発防止を減らしていきたい。 そういう感じで話をしました。
自前のテスト自動化ツールなどの紹介をしたので、「なんだ」と思ったかたもいたと思いますが、 OSSなので、自分で書き換えれば、もっとよくなりますよ！ ということで。。
今回紹介したツールは、以下のとおりです。(上の2つ以外は自作ツールです。)
TypeTest targetRemarks
ServerspecServers(static)
InfratasterServers(dynamic)
Infrataster-plugin-dnsDNS servers
Infrataster-plugin-firewallFirewallsTraget server needs: tcpdump, netcat
LbspecLoad Balancers(L4-L7)Target server needs: ngrep, netcat
RSpec-ssltlsSSL/TLS

今回紹介しなかったですが、RSpec-proxypac というproxy.pacをテストするツールもあります。

将来的にはOpenFlowを使って、TDDできるとおもしろいかなと思っています。
Trema に興味をもって、Rubyを始めたので、そろそろTremaに恩返しをしたいとは思っています。

スライドは適当な「英語」で書いていますが、私のボキャブラリの範囲なので、 難しいことはないと思います(英語的に意味がわからないことはあるかもしれませんが)。
なぜ、英語で書いたかというと、せっかく書くのだから 「スライドだけ」でも他の人にも見てもらえたらな と思ったからです。 OSSのツールを広めるのであれば、英語圏(全世界)の人が見てくれたほうがいいですよね。
このスライドに対して、2015/4/23に発表して、2015/4/26 07:22現在で、USからのアクセスもそれなりにありますので、 英語で書いておいて、効果はあったかな と(とはいえ、このblog記事を英語ではかけなかった。。)。
  • Top countries
NameViews
Japan464
United States68
Canada5
France4
Philippines2


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