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年11月6日金曜日

NetOpsCoding #1 参加メモ

開催概要

  • 日時： 2015/10/30 (金) 19:00 to 21:00 (実際には22:00ごろまででした)
  • ビッグローブ株式会社(品川シーサイドパークタワー 3F)
  • ハッシュタグ: #netopscoding

他の方のまとめなど

まとめ・感想

Network 運用のためのCodingの話でした。

似ている勉強会にネットワークプログラマビリティ勉強会(#npstudy)というのがありますが、非常に分野が近いというかOverrapしています。 #npsutdy がネットワークの仕組みとかがメイン(かなぁ)である一方で、 このNetOpsCodingは運用からの視点で見ています。

この勉強会のよいところとしては、運用の視点から具体的な困りごとをベースに議論ができるところかな と思いました。 いろいろな困りごとから出発して、共通的な仕組みができるとうれしいです。

今回の発表では、Microsoftさんの取り組みがありましたが、圧巻でした(資料は2015/11/06現在 見つけられていません)。 最終的にはここまでいくといいと思いますが、規模が大きくない現場ではなかなかここまで作り込むのは大変だと思います。 NetOpsCodingを通して共通的なフレームワークが作れると管理規模が小さい環境でも効率的に管理できてうれしいです。 現状でもCLI, SNMP, NETCONF, Rest APIといろいろなやりかたがあるので、そこを吸収する必要性を再認識しました。

また、今回はLTで5分だけNetwork Test Automationという発表をさせてもらいました。(#npstudyの発表の再構成ですが。) NetOpsCodingを始めるところの敷居が下げられるといいなぁ と思っています。

Introduction of NetOpsCoding

ネットワーク運用者が自動化して、楽して、ミスを減らして、楽しいことに時間を使うために、 どうしたらよいのか？ベストプラクティスを共有したい という趣旨でした。 ネットワーク運用者、ソフトウェア開発者、Network機器メーカーいろいろな立場から、 自動化を進めていきたい という話でした。

ネットワークAPI作成30分Coding

Rubyはじめて半年くらいという井上さんがvSRX(のルータ機能)を NetConfで設定するという話でした。

通信系のデモとしては珍しく(?)、pingではなく、descriptionを設定する ということでした。

Qiitaの記事 をベースに進んでいきました。

今回の例では、最終的にはCLI over NETCONFというような感じだったので、 まずは、これができると、いまの運用との一貫性を築くことができるので、よいと思いました。 (結局、これがないと、いろいろなところで実装しなくなるのでつらいですね。)

Microsoftにおけるネットワーク自動化とそれを支えるソフトウェア群について

  • 発表者: Microsoft 北島さん
  • 発表資料:
    • 見つけられていません。

いくつかのソフトウェア群についての紹介がありました。非常に刺激的で有用なものが多いです。 一方で、これを規模の小さいうちの環境では工数かけられないなぁ とか、そう思うところもありました。 けっこう、一般化できるかもしれないので、仕組みをNetOpsCodingで作っていったら、 みんなで幸せになれるのかもなと 思いました。

ソフトウェア群はこんな感じでした。

  • SES(Standard Enforcement Script)
    • Perlスクリプト
    • 機器のConfigがテンプレートと一致していなければNGとする
    • Model Driven ではなく、Adaptive
  • Pre/Post-change Validation
    • 事前の状態と事後の状態を比較する
    • 事後の状態がテンプレートとマッチしていなくても、事前も同じだったら、今回のオペレーションによるものではない
    • 差分がでたところだけ確認して、問題なければ、そのままにする
  • MPLS Autobandwidth Automation
    • MPLSのBandwidthの制御をするための話
  • Monitoring Intelligence
    • 複数のグラフを時間軸で相関を見る。
    • FibrecutでCPU負荷が上がったり、QoSのプライオリティごとの通信が変化したり、しなかったり
    • CLI, SNMP, Syslogをアグリゲートしている
    • Ping meshでsrc/dstのメッシュをしておくと、どのあたりに問題があるかわかりやすい

YANG modelの話など

NETCONFのデータモデルを記述できるYANGというモデリング言語の話でした。 NETCONF自体はYANGでのモデリングと切り離して考えられる。 しかし、統一したオペレーション(設定と監視)を考えると、YANGでモデリングされている必要があるということでした。(たぶん)

いろいろな機器が統一した記述で(ある程度)設定できるとうれしいです。

ネットワーク運用自動化お悩み相談室

会場の参加者がどのようなところに興味があるかを聞き出す、面白い内容でした。 NetOpsの自動化のイメージが全然違うので、それぞれのイメージを共有したい という意図です。 会場では、まずは設定とチェックのところの自動化をやりたい という感じだったような気がしていますが、記憶が曖昧です。。

ライトニングトーク

Model driven automation!

  • 発表者:
    • CISCO 河野 美也さん

YANGモデルとかの話だったと思います。自分のLTの準備とかしていて、 あまり聞けませんでした。

Network Test Automation

Networkの自動化の第一歩として、基本の動作確認の仕組みの共有です。 Config系の自動化は、ミスすると通信できなくなりますが、 基本動作確認を自動化しても、基本的には通信できなくなることはありません。 なので、そこから最初に手をつけるのがよいのかな という話です。

テストツールとしては次のようなものを紹介しました。(自家製ツールの紹介が多いです。) 使ってみて、Issue、Pull Requestもらえるとうれしいです。

Test Tool対象備考
ServerspecServers(static)
InfratasterServers(dynamic)
Infrataster-plugin-dns (Rspec-dns)DNS servers
Infrataster-plugin-firewallFirewallsTraget serverにtcpdump, netcat が必要
LbspecLoad Balancers(L4-L7)Target serverにngrep, netcat が必要
Rspec-ssltlsSSL/TLS

機能的なテスト以外(性能系のテストなど)は、ここではできていないので、 性能などを計測したい という場合は、別途そのようなツールが必要です。

テスト駆動型ネットワーク

ItamaeとServerspecを使ってテスト駆動でCumulus Linuxの設定を作っていく事例でした。 本番環境以外に開発環境がある場合は、このやり方でやりたいです。

インフラ屋の友:Tera Term

Skypeでの参加ということで、驚きました。 内容はTeraTerm のスクリプトを使った自動化でした。 expectやこの手のツールも、使うのと、使わないのとで大きな差があるので、 ここのあたりも共有できるとよいのでしょうか。 (私はTeraTerm使っていないですが。)

投稿者 時刻: 1 件のコメント:
ラベル: , ,

2015年8月26日水曜日

YAPC::ASIA 2015 参加メモ

参加したところ

  • 日時: 2015/08/21(金) 10:00 - 18:00(懇親会)
  • 日時: 2015/08/22(土) 10:00 - 18:00
  • 会場: 国際展示場 会議棟
  • ホームページ: http://yapcasia.org/2015/
  • hash tag: #yapcasia

初めてのYAPC::ASIAでした

懇親会は大盛況でした。

ネットワークエンジニアでRubyがメインの私にとって、今回、初めてのYAPC::ASIAでした。

金曜日と土曜日の両日参加し、懇親会にも参加できました。

多くのOSSの開発者と話ができたこと(アイコンと顔が一致した)が一番よかったです。

YAPC::ASIAを快適に過ごしている裏で、YAPC::ASIAの開催側でいろいろなかたが努力しているのを感じました。 ありがとうございました。

「blogを書くまでがYAPC」ということで、2つの発表について振り返ろうと思います。 (YAPC::ASIAのあとに家族旅行があり、blog更新が遅くなりました。)

それは僕たちのドメイン・DNS運用

某面白法人でのDNSレコード(受託のWebサイトのレコードなど)の管理方法についての話でした。

  • AWSのRoute53での運用をするようになった
  • その運用のツールとして、Roadworkerというツールを使っている
  • Circle CIを使ってCIを回している
  • 実際にDNSレコードが反映されているかはテストしていない

このような話だったので、@jiggyakkumaさんと、次のようなやりとりで、 テストツール(infrataster-plugin-dns, rspec-dns)を紹介したのですが。。。

Roadworkerにテストコマンドあるじゃん！！ という落ちでした。

Roadworkerはとても良さそうなので、 AWSのRoute53以外のDNSレコードの運用にも応用したい熱が上昇中です。

3分でサービスのOSを入れ替える技術

タイトルでは想像できないくらいいろんな取り組みをしていて、とても参考になる話でした。

まず、課題設定として、「Do scale-out with extremely rapid automation!!!1」という ところからのスタートです。 この課題に向けて、どのようなアプローチをとるのか。

アプローチとしては、以下のようなアプローチのようです。

  • アプローチ
    • Infrastructure as a Code化
      • VMの作成手順書からPuppetへの置き換え
      • puppetマニフェストの修正
    • VMのサービスへの投入の自動化
      • ノードのImmutable化
      • 現実の手順をコードにする
    • クラウド指向のアーキテクチャの導入
      • 監視などで登録を手動でやらないといけないものからの脱却
      • fluentdなどでのログの収集自動化
    • コマンド化
      • コマンドをthorなどを使って簡単に！
    • VM起動時間の短縮
      • Packerを使って、起動のためのphaseを段階を分けて実行するように
        • Minimal image(phase1)
        • Role specified(phase2)
    • Infra CI
      • Severspecなどを使って、壊れていないことを確認できるようにする
    • OSの切り替え
      • Secientific LinuxからCent OS7 へ
    • Blue Green デプロイ
      • Nginx などでの切り替え(ELBはここでは使わない)
    • (将来)ここまで来たらDockerとかも考えられる

コード化して、CI回しながら、リファクタリング という、 ソフトウェア開発的なアプローチでの置き換えにより、 短期間での実現したという素晴らしい内容でした。

「すばらしい」のだが、一方で、「自分でもできるのではないか？」 と 思うことができて、成功体験の共有は素晴らしい と思いました。

投稿者 時刻: 1 件のコメント:
ラベル:

2015年8月9日日曜日

Trema Day #7 Presented by APC に参加してきた

開催概要

他のかたのまとめ

感想

トレンドなのか、たまたまなのか、今回は無線関係のOpenFlowの話が多かった。 TremaがPure Rubyになったということで、いい加減、Trema入門します。 エーピーコミュニケーションズさんのすばらしい会場で、 懇親会まで準備いただいてありがとうございました！

OpenFlowで覚えるネットワーク

まとめると

ネットワークをあまり理解していない人に向けて、どのようにしたら 理解してもらえるか。どうやったらネットワークを理解している人を増やせるか という課題に対して、 Yellowケーブルなどのころからのネットワークの変化を OpenFlowを使って追体験することで、理解を深められるのではないか という 試み。

メモ

  • テクニカルな話ではない
− ネットワーク = コミュニケーションをする道具
  • 複数の人 で達成する
    • 情報のやりとりをやる
  • 必ず2点の「端点」がある
  • ゴール： 自分の頭の中にあるものが相手の頭の中になっている
    • 音声、紙
      • 日本語 とかいうルールがある
        • プロトコル
  • ネットワークのかたち
    • どんな情報を伝えるか
    • どこのだれに情報を伝えるか
    • 何を使って情報を伝えるか
    • メディア
  • mininet使うと簡単に試せる
  • 糸電話からLearning Switchへ
  • 同時に話すとCollisionが発生する
    • 共有メディアは人が増えるとしゃべれなくなる
  • 近代ネットワークの道
    • ブリッジ → スイッチ
    • スイッチになるとコリジョンが発生しなくなる
− スイッチにするには
  • KnownなARPテーブル
  • UnknownなARPテーブル → Learning Switch
  • よその部屋の人との会話
    • IPの話→Simple Router
  • L1とはL2というのを下から上に理解するといいのではと思っている
  • コリジョンドメイン、全二重と半二重、物理メディアの話は端よっている
  • OpenFlowを使おうとおもうと、面倒見る人がいない
    • ソフト屋

ニューTrema5つのポイント

まとめる

新しいTremaになった。 見た目は変わっていないが、中身はだいぶかわった。 OpenFlow1.3.4に対応し、Pure Rubyにして、 コントローラ連携がしやすくなって、テストフレームワークと ドキュメントが充実した。

メモ

  • OpenFlow1.3.4に対応
    • –openflow13 と足すとしゃべれるようになった
    • pioで対応
    • trema/pio を見るとわかる
  • Pure Ruby化
    • インストールが簡単
    • openvswitchを入れて、bundle install でできる
    • デバッグしやすい
    • pryとかでパケットインのところでそのときのスコープの変数とかが見える
    • pryだとmethodの補完もできる
    • show-sourceとかでmethodなので。
  • コントローラ連携
    • 既存のコントローラを組み合わせて高機能なコントローラを作ることができる
    • delegatorというのを使う
    • クラスの継承を使って機能を拡張するのも簡単
  • テストフレームワーク
    • テスト
      • INPUT とOUTPUTを定義するとできる
    • Cucumberでできる
    • Given When Thenでかける
  • ドキュメント
    • Cucumberの記述からドキュメントを生成するようにした
    ｰ その結果充実した
  • 協力のお願い
    1. バグ報告
    2. パッチのPR
    3. 新しいアプリ
    4. Trema本レビュー

OVS拡張の話(とPioの話)

まとめると

TremaのPacketParserであるPioに OVSで使われている Nicira拡張をいれたいという話。 Nicira拡張はOVSに限定されているが、 いろいろと使いやすいものがある。

メモ

  • PioはRubyのパケットパーサ実装
    • パケットのパースをするツール
    • パケットを作れるツール
    • PioがだんだんCoreの部分に近づいている
    • Pioの性能がTremaの性能に影響を与える
  • OVSのNicira拡張にいろいろと使えるものがある
  • OpenFlowのきついところ
    • 「Controllerに転送を書くんでしょ？」
    • 「そうだよ？」
    • 辛そう
  • 宣言的にやりたい
  • OpenFlow的にはpacket_inさせるな！というのが一般的だが。。
  • 簡単にかけます

QA

  • Q: Pioにいれるきがあるか？
  • A: 熟読してから決める(by @yasuhito さん)
  • Q: 使える実装はどれくらい？
  • A: OVSなら使える
  • C: 他のハードのスイッチはけっこうはまりそう？。
  • C: Nicira拡張なのでOVSなら使える

いろいろなデバイスでOpenVNetを動かしてみようとした

まとめると

OpenVNet(OVS, Trema, MySQL など)を 次世代携帯型データセンター(Android 2.x)で 動かそうと頑張ったが、そこまでいかなかった。。 という 死闘の記録。

メモ

  • Edge Overlayのおさらい
    • Hostに仮想Switchがのるタイプのネットワーク
    • OpenStack Newtronとの親和性
  • 次世代携帯型データセンター
    • rbenvでrubyのコンパイルが1日で終わる。
    • Tremaのコンパイルも1時間
    • rootをとる必要がある
    • けっこう辛い
  • デモ
    • OVS, Tremaはなんとか動いたが。。
    • 無理矢理アラインメント変更したから。。

Dive into wireless openflow!

まとめると

無線LANとOpenFlowについての考えは珍しくはないが、 無線LANベンダによって、ロックインがあるため、いろいろ難しい面もある。 Raspberry Piを使った実装のデモを使って、効果の説明があった。

メモ

  • 無線とOpenFlowの組み合わせは珍しくはない
  • 無線はいろいろわからない(見えない)
  • 今回作ったやつはラズベリーパイで動いている
  • 効果
    • 状態を監視できる
    • APの電波でどちらを優先するか などの制御ができる
    • デバイスごとの癖がわかる
  • 実装
    • Linux netdev = openflow portとした

QA

  • Q: 無線LANの標準はあるのか？
  • A: 標準にしてもいいがONFとしてどうなっているかはわからない
  • C: 個人的には標準化したほうがよいかという気持ちはある

「Lagopusで遊ぶ(仮)」 あらため「Lagopusで試すFirewall」

  • @hibitomo さん
  • スライドはNot Yet

まとめると

FirewallのACLをLagopusで実装してみる試み。 ポートのRangeを実装するところはLagopusなら力業で実現できる(はず)。 ちょうどLagopusが新しくなって動いていないが、すぐに直るはず。

メモ

  • ACLのポートレンジのところは、最大26万ルールにおさまる！！
  • Lagopus →100万ルール いける(はず)
  • priorityを気をつける必要がある

QA

  • Q: テストツールは？
  • A: RyuのテストツールでJSONをいれればできるので、これでいける？

(仮題)Dockerコンテナのネットワーク周りについて

まとめると

DockerではネットワークまわりがいまHot。 docker 1.8 experimentalではいろいろ遊べる。 RunCを使えば、dockerが入らないようなシステムでも コンテナを簡単に作れる。

メモ

  • Trema関係ない
  • いまDocker Networkに力入れている
  • コンテナの周りのツール いろいろある
  • きょうの話
    • libnetwork
      • コンテナのネットワーク
    • RunC
  • libnetworkの話
    • 言葉の定義
      • SandBox → コンテナのこと
      • Endpoint → vethとかのこと
    • libnetwork driverがdocker0作成したりする
    • libnetwork driver
      • bridge デフォルト
      • overlay VXLANでトンネルをはる
    • overlay driver
      • docker 1.8-experimentalから利用可能
    • swarmはいまはネットワーク周りまだ管理していない
    • consulでやっている
    • docker create network overlay のようにやる
    • docker service publish h1.test ってやる
    • service とIPアドレスが対応している
    • /etc/hostsに書かれている
    • network driver だとarpがこない
      • broadcastとかはdocker側で管理している
    • 今後はlibnetworkを中心に発展していきそう
  • RunCの話
    • ホワイトボックススイッチ
    • Cumulus Linuxなど
      • Debian 7ベース
    • dockerを入れるにはいろいろ問題があって。。
    • そこでRunC
    • Open Container Projectに準拠させた
    • dockerのような常駐デーモンがいない
    • docker export でtarにして、それをrootfsにして、そこでruncを走らせるとコンテナが動く

QA

  • Q: vxlanはdocker間だけ？
  • A: 現状はdocker間だけでしかvxlanは通信できない
  • Q: どうしてスイッチ上でコンテナを動かしたい？
  • A: スイッチ上でアプリが動けばいろいろやりたい。アプリの配置を簡単にしたい
  • Q: dockerのネットワーク切り替えはできる？
  • A: 一応できるけど、ホスト名では解決できない

LT

ぜんぜんかけていないので、あとで追記します。きっと。。

LT SDNに夢見た無線AP～

LT 無線LANコントローラーからSDNへの移行可能性と拡張性の模索

  • @SRCHACK さん

LT Lagopus 0.2

投稿者 時刻: 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 件のコメント:
ラベル: , , , ,

2014年9月29日月曜日

vagrant-proxyconf(1.4.0) supports docker (en)

Hello, proxy fans in the world,

Finally,vagrant-proxyconfdocker has been released!(version 1.4.0).So, you can run docker easily behind a corporate proxy.

docker

You can use vagrant-proxy docker support for docker hosts on ubuntu, RHEL(6,7), CoreOS, boot2docker and so on.

It is easy to use. Install vagrant-proxyconf, then add your proxy configuration to Vagrantfile. If you already use vagrant-proxyconf, you don't need extra configuration for vagrant-proxy docker support.

vagrant-proxyconf installation

Install vagrant-proxyconf

$ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

If you can't install vagrant plugin because of proxy server. Try the followings.

$ http_proxy=http://myproxy:3128/ vagrant plugin install vagrant-proxyconf
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.4.0)'!
$

Vagrantfile

Add configuration.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  if Vagrant.has_plugin?("vagrant-proxyconf")
    config.proxy.http     = "http://myproxy:3128/"
    config.proxy.no_proxy = "localhost,127.0.0.1,.example.com"
  end
  # ... other stuff
end

Running docker

After vagrant up, try to run docker.

vagrant@vagrant-ubuntu-trusty-64:~$ sudo docker.io pull -t 14.04 ubuntu 
Pulling repository ubuntu
ad892dd21d60: Download complete 
vagrant@vagrant-ubuntu-trusty-64:~$

If you set http_proxy, it will affect for https communication for docker. You can use private repositories in your intranet, because you can set no_proxy.
docker/registry/registry.go
docker/registry/auth.go
The Go Programming Language Source file src/pkg/net/http/transport.go

Happy proxy life!!

Docker logo and marks usage

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