ネットワークプログラマビリティ勉強会 #npstudy #15 参加メモ

memo

ネットワークプログラマビリティ勉強会に参加してきたのでいつものメモです。

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

趣旨

  • NWの課題、システムエンジニアリングだけではなくソフトウェアエンジニアリングで解決する時代に
  • NWエンジニアもソフトウェアやOSSの知識が必要
  • みんなで知見やノウハウを共有しましょう

募集

  • スピーカーがいると次回早く開催できます
  • LTは公募割と早く埋まるので、確定してないネタでも声をかけてもらえると
  • スタッフも募集してます。
  • 会場も探してます

Lagopus Router, hibitomo さん

余談: MSのすごいところ

Lagopus

  • NTTの研究所で開発している。OSSプロジェクト。
  • 2013年から。SDN/NFVというキーワードで。DPDKで10Gワイヤレート、ソフトウェアで汎用サーバの上で。
    • コスト効果、time-to-market の短縮
  • 最初は総務省のプロジェクト。今はNTTと大学とか。
  • 2017/8月にLagopus software router (alpha), 今頃には beta が出てるはずだったんだけど社内手続きを勘違いしていてちょっとずれる…

Lagopus switch

  • OpenFlow1.3 + Tunnel Extension

OpenFlow?

  • パケットをマッチしていろいろいじる
  • 弱点: ステートを持てない (ステートはコントローラでしか持てない)
    • よく考えないとフローが爆発しがち
  • ユースケース例
    • SDN-IX (Interop), DDoS対策とか。
  • ユースケース要望きくとOFだとつらい
    • VRRPとか。自発的にパケットを出す・ステートを持つ

Lagopus switch → Lagopus routerへ

  • NWエンジニアが使いやすいものを作ろう
  • 方針
    • コントローラ--スイッチ間が埋まりがち → 経路交換とかの機能は「箱」のほうへ。コントローラ側は提供したいサービスアプリのみに注力しよう。
    • lagopus で実証実験 → 良ければベンダとかで

中身の話

  • Lagopus project 側の思いからは、モジュールを作ってみてほしい → router architecture について。
  • 中身はマイクロサービスみたいな感じ
    • モジュール間が gRPC とかで切れてる
    • Zebra2.0 で使っている config manager を利用。(config datastore)
      • demo
    • config datastore → agent (routing, vrrp, ike, mat) → dataplane
      • DP間I/Fは gRPC, NetLink の agent がある

Dataplane module

  • Fast path → DPDK, Slow path → Golang で記述
    • Go/DP(Clang)間はRING, (2016 の dpdk user space (ダブリン) の資料を参照)
    • alpha → beta で中身が変わる。2018年度頭リリースの時にモジュールの書き方とかのドキュメントを追加して公開予定。

Config datastore

  • Openconfigd
    • YANGを突っ込むとCLI/APIを生成してくれる
    • YANGのconfig sub tree に対して、agent が subscribe すると push してくれる。
    • CLI も他とか commit とかつかえる
      • validation して subscribe しているモジュールがみんなOKならcommitになる
    • openconfigd でオレオレCLIを書こう (IW2017 BoF 浅間さん)

Openconfigd Demo

  • YANG の leaf を足すだけで CLI ができる
  • "birdwatcher" (公開予定)
    • config に条件をしたいことがある。依存関係の解決
    • OpenStack Congress (ポリシーエンジン) みたいなの
      • 「このルータでL2の設定は許さない」
    • config datastore とだけやりとりして validation する
    • commit → validation error → birdwatcher で validation log を確認できる
    • 依存関係を定義すると CLI の依存関係を解決する仕組みが書ける
      • 本体201行! ルールは変数定義だけ。
      • Golang, openconfigd すごい!

Roadmap

  • 2月か3月に出す予定だったが…来年度に。
  • beta release (L3/L2, match&action)
  • 2Qあたりに ipsec
  • future work
    • nat, ipv6, mpls, bgp flowspec, acl, xflow
    • 来年度中… 少なくとも NATは。ipv6もいれないとshownetにはいらないので…
  • みなさん CLI つくりましょう

QA

  • lagopus arch, agent は golang の別のプロセスで動いている?
    • routing agent は linux kernel
    • vrrp agent とかは dataplane module とは別プロセス
  • スレッドのつかいかた、switch は dpdk pipeline model, router は?
    • 基本的には pipeline model にちかいけど、スケジューラがいて仕事を割り振る感じ。

ここ3年におけるサイバーエージェントのネットワークを取り巻く環境の変化 ～API/SDN/kubernetes～, 山本さん

CyberAgent

  • ゲーム・メディア事業
  • アドテク本部
    • インターネット広告
  • アドテクスタジオ
    • いろんな広告をまとめて開発していく(掲載媒体より・広告出したい人向け、広告競売、などのシステムがある
    • 遅延の少ないネットワークが求められる

アドテクスタジオのインフラ?

  • 広告プロダクト…25-30ある。200名くらいのエンジニア(ほとんどアプリ。インフラは10人くらい。)
  • インフラはプロダクトで選択できる。GCP < AWS < Private cloud (インスタンス数)
    • GCP増えてきてる

プライベートクラウド

  • 本番用 OpenStack (ふたつあって新旧移行中)
  • コンテナ基盤
  • CI (Circle CI)
    • Circle CI 2.0 で苦労しています
  • 物理マシンはMAAS (Ironic)
  • 個人開発用クラウド (OpenStack Mille + Midonet)
  • 分析基盤: tableau, Hadoop (OpenStack)

ここ3年

  • 2014/3
    • 1U物理サーバを並べる + KVM でVMを数台。
    • サーバ担当がラックつくってNW担当がスイッチ設定してOS入れてVM作って…とかを申請ベースに手作業
    • ヒューマンエラー, 作業分断
  • 2014/8
    • OpenStackでセルフサービス
    • 当時の neutron L3 がアレだったのでL2構成
      • L3終端とLBが物理で取り残される → 申請作業が残る (より問題が顕著に)
    • インフラ用 API gateway を作成して API を公開 → ルータ・スイッチ・LB, neutron の設定をapi経由で
      • 学習コスト/標準化 → 機器固有の違いを覚えなくてもよい, JOB組み込みがしやすい・申請ベースの問題を解消
    • chatbot も導入。chatでインフラ操作。NWのグラフとってくるのとか面倒な操作も。
  • 2015/2
    • 個人開発環境をMidonetで。当時OSS化されたばかりくらい。
    • VTEP → サーバになる。NW は L3 reachability だけあればよい。
    • トラブルシュートが変わってくる…範囲をどこに絞るか。物理NW? Linux NW? zookeeper で管理しているところ? midonet bug だと scala
    • NWとサーバの守備範囲の変化…垣根がなくなってくる
  • 2016/11
    • コンテナ使いたい → GKE → k8s-aaS ("AKE")
    • private cloud, パフォーマンスとか見てもコストメリットがあったので。
    • k8s 構築がつらい問題→k8sクラスタを簡単にデプロイ。動的な永続ボリュームの提供。
      • OpenStack上で必要なリソースを展開...HEATの話とかもトラブルシュートする上では必要
    • type:LoadBalancerの壁…OpenStackでは neutron LBaaS, Octavia : でも アドテクのOpenStackはL2構成…
      • k8s cloud provider の openstack pkg を回収 → LB用IP払い出してAXCをたたくように変更
    • 物理の世界だけでは生きていけない
    • chatbot も進化: ヘルスチェックやアラート応答

まとめ

  • NWエンジニアの領域は変わってきている
  • openstack, sdn, k8s による変化にどれくらいNWEが食い込んでいけるか
  • 申請処理などの単純作業から解放されれば他のことがやれる
  • 情報交換を

Azure のネットワークはブラックボックスじゃない！, 山本さん

Azure

  • サービス8年。IaaS/PaaS, AKS
  • Enterprise Cloud : 固い会社とよくやっている
  • 世界中にDCがあるよ
  • 5月～欧州で個人情報保護系の法律(GDPR)にも対応
  • Openなクラウドです!

NWがブラックボックス?

  • Azure NW, 世界中のDCにいろんな回線引いてる。backbone NW つよいよ
  • IaaSのNWイメージ
    • 仮想マシンごとに NW Sec Gr (NSG)(per NIC) + vNETでも Sec Gr
    • PaaSとvNetでつなぐこともできるようになったよ
  • NWの可視化 : Network Watcher
    • 有料だけどゴミのような値段!
  • demo
    • VM→NIC→IP,NSG
    • Network watcher → トポロジ → NW図を表示 (defaultでやれる + download topology すると visio で編集可能なファイルが落とせる)
    • Network watcher → IPフロー確認(ping), packet captuer
    • PowerBIにNWログ食わせる(Windows)。テンプレートがある。とってきた情報のままレポートが書ける
    • Security center: NWの推奨値とかが出てくる。ポリシあてたりとかいろいろ。
    • Just in Time VM preview: 普段は全部閉じたFWポリシ。要求タイミングで特定プロトコルを指定時間・指定範囲で空けることができる。(まだGUIでの入力)

分離されたネットワークでの複合機/プリンターの共有, @otahi さん

オフィスでのネットワークの課題とその対策。

  • 総務省が自治体に、ネットワークの分離を求めている。住基ネット/LGWAN/インターネットをわけてそれぞれで情報が簡単にやり取りできないように。
    • 複数のネットワークから複合機とかプリンタを安全に利用したい
  • NWごとにプリンタ置けばいいんだけど場所の問題もあるしそうもいかない

複数のNWからプリンタ使いたい

  • USBプリントサーバ
    • 2系統までなら簡単
  • インタフェースボックスタイプ (今回の話はこれ)
    • 3系統までの有線LANに対応
    • scan-to-folder 可能
    • 個人認証/私書箱プリント対応
    • Tag VLAN対応(10VLANまで) (プリンタはtag対応しない)

しくみ

  • いままでのNWはそのまま
  • 他のNWは NAPT...プリンタが source になるときのルーティングとかNW間制御とかでSDN的に

USBプリントサーバだと快癒ところに手が届かないところに対応

pyATSをつかったテストの自動化, 緒勝さん

pyATS?

  • python based framework
  • pytest + netomico
  • もうちょっとすると testfms 込み見たいなフレームワークに
  • まだ OSS としてソースコードが公開されていない
    • 公開されるかどうかはまだわからない。
  • 発表はいちユーザとして。
  • pyATS + Genie
    • 現在は netomico 的モジュール(genie), 今後は REST, parser lib 都下も出てくる予定。

テストケースをクラスで書いて、メソッドでステップを刻んでいく

  • ベーシックなテストケースを書いて、子classでoverrideしてバリエーション

いいとこ

  • cisco で結構長くつかわれてる。
    • ATS: 前身は tcl → python で
    • testbed file: 機器のアクセス情報、トポロジ、初期条件などを書ける
    • genie framework: 機器抽象化ライブラリ
    • unicon package...ssh/telnet による機器アクセスサポート
    • roadmap
      • Parsergen, YANG.connector, REST.connector, Genie.Telemetry

Testbed file

NSOで自動化した処理の試験を自動化する - pyATS →(REST)→ NSO → config → test - CLIでやったけど XML でやったほうがらくだったかな

関連情報

次回

  • 2か月後くらい?
  • ネタがある人は声をかけてください

2016-2017年のサービス障害を振り返る

memo

最近全然ブログとか書けてないなーと思いつつ 2018 年を迎えてしまいました。本年もよろしくお願いいたします。

以前、DC/クラウド/通信事業者サービスの障害事例よせあつめ という記事を書いたところ意外と反響があったので、続きを書こうかなと年末考えていたのですが、結局 2017 年中は書けませんでしたね。いろいろあったんですよ。個人的な話なんで別にどうでもいいんですけど。そんなわけで年明けに書きます。

この記事は 2016 年アタマの GMO の障害とか github のサービス障害をきっかけに書いたものでした。その後、世の中的にはどんなサービス障害が起きているのかをざっとおさらいしてみたいと思います。いまシステムやサービスを作っていく中で、こういう原因で死ぬのか…というのを見ていくことは、ひいては「そこまで予見できなかった」あるいは「そこからは回復させられなかった」ってことを考えることなんですよね。落ちた = ダメじゃん、という話でおわるのはなくて、ここまでやられて初めて落ちるんか…とか、こういう可能性まで見込んで何か考えないとイカンのか…とか、こういう状況でもうまく逃げ切るための方法って何なのか…とか、発展的な話を考えるための材料だと思っていただければ。

挙げる事例については私がウォッチして見つけているものなので当然偏りがあります。その点はご承知おきください。他にもこういう事例があるよってのがあったら是非教えていただきたく。

参考資料

ニュースソース

ツイッターとかでも拾っていますがこの辺を見ることが多いですね。いろいろ時事ネタや速報だしてくれています。ありがたや。

参考記事

2016年の事例

2017年の事例

おわりに

個人的な所感としてはこんな感じです。

  • 相変わらず DC 設備系のトラブルはおきる : 停電・ケーブル切断などファシリティ・設備レベルの話はやっぱりゼロにはならない。
  • パブリッククラウド・クラウド上のサービス(XaaS)ではソフトウェアで自動化されることによって障害が増幅される : 自動化してレバレッジをかける……一度に大量のサーバを操作したり処理を実行できる。ただ、これは誤った手順・オペミスのリスクを拡大する方向にも働く。実行するツールの選択ミス・パラメタ設定ミスなどをどう防ぐか → オペレーションの妥当性・正当性をどう保証するか、というのは課題になるだろう。それと大規模にやらかしたときにどうやって復旧するか、という話。両面での対策検討が必要になると思われる。
    • 複数のサイト(リージョン)やサービスをまたがるような障害にどう対処するか?
  • ネットワークエンジニア的には、この 1-2 年は BGP 操作による大規模障害が目立つのが気になるところ。とはいえこれ、upstream でやられちゃうと、エッジにいる側からはなかなか対処ができないんだよな。せめて問題検知や切り分け・状態の把握を早期にやれるようにするくらいか?

ネットワークの自動化、何つかう？ 〜自動化ツール紹介〜 #APC勉強会 #30(2回目) 参加メモ

memo

ネットワークの自動化、何つかう？〜自動化ツール紹介〜　APC勉強会＃30(2回目) - connpass に参加してきたのでいつものメモ。1回目のときはぼんやりしていたらあっという間に満席になってしまったので2回目で滑り込みです。

資料は1回目の時に公開されているのでそちらを参照してください。

ネットワークの自動化、何つかう？〜自動化ツール紹介〜

はじめに
  • NW機器もAPIに対応して、自動化フレンドリーなものが増えてきた
  • そういう機械でなくても自動化できるツールやライブラリを紹介
    • netmiko
    • napalm
    • ansible
    • salt
全体像
  • 業務フロー : 作業, 実際に config 流し込むところの自動化
  • ツール依存イメージ
    • 構成管理ツール : ansible, salt
    • python ライブラリ : napalm, netmiko
  • 機能概要
    • netmiko, napalm : ライブラリ。抽象化の仕方が違う。
      • netmiko...直接コマンドを指定, napalm...ひとつのメソッドで複数のベンダのコマンドに相当
    • ansible, salt : ツール。抽象化の仕方が違う。
      • saltはnapalmの中で使っているのでベンダをお意識しなくても使えるようになっている
      • ansibleはモジュールによるけど、コマンドを直接呼ぶタイプのモジュールが多い
netmiko

netmiko

  • シンプルで薄い抽象化ライブラリ。
  • login, モード移行, commit などを共通メソッドとして抽象化。
    • "conf term" とかは抽象化されてる
    • 表示・設定コマンドはコマンドを直接指定する
  • netmiko 対応機種
    • けっこうある

コード例

  • 状態表示
    • enable メソッドで抽象化されてる
    • send_command で直接コマンドを送る
      • コマンド実行結果がそのままとれる (特に parse とかしない)
  • 設定変更
    • 設定コマンドも直接指定
    • send_config_set でコマンド文字列(リスト)を渡して実行

まとめ

  • シンプルで薄い
  • teraterm マクロよりは楽かな
    • waitとかプロンプトとか気にしなくていいので設定に注力
    • 対応機種は限られるので注意
napalm

napalm

  • 多機能で厚い抽象化ライブラリ
    • 一部だけど表示コマンド・設定コマンドまで抽象化
  • 対応機種
    • netmikoよりはすくない
  • 対応メソッド
    • サイトにある…使いたい嬉々とやりたい操作の対応をチェックすべし。

コード例

  • 状態表示
    • get_interfaces メソッド→IOSの場合は"show interface" : 抽象化されてる
    • コマンド実行結果も parse されて構造化されたデータとして取得
    • 違うOSでも共通のデータ構造で取得できる
  • 設定変更
    • load_template メソッド。テンプレートを呼び出して、パラメータを渡して、設定実行。

まとめ

  • 多機能で厚い
    • 一部設定と表示に関しても抽象化…対応していないものについては直接コマンド指定して実行することもできる。
Ansible

ansible

  • シンプルな構成管理ツール
  • 抽象化というアプローチは特にとっていない。
    • ベンダごとにモジュールがあるのでそれを使い分ける
    • netconf 対応などは今後注目
  • 特徴
    • agentless
    • yaml で構成定義 (playbook)...なってほしい状態を定義する
      • プログラムを書くわけではない
  • 対応機種
    • v2.3, napalm よりちょっと多い

playbook例(cisco ios module)

  • 状態表示
    • コマンドを直接指定して実行
    • 特に parse されるわけじゃない
  • 設定変更
    • コマンドを直接指定して実行
    • "changed=1", 既に設定が入っていれば "changed=0"

まとめ

  • シンプル
    • インストールも pip で一発。必要なファイルも最低二つ。
salt

salt

  • 多機能な構成管理ツール
    • 中で napalm を使っている……抽象化するアプローチ
    • ベンダごとのモジュールも出てきているけど主要なのは napalm を使う方法
  • 概要
    • master/agent 型
    • yaml で構成定義
    • 高機能 : イベントドリブン, スケジューラ, WebAPI
    • v2016.11.0 で napalm 統合 (NW機器対応)

Saltの主な用語

  • Master : 指示を出す
  • Minion : いわゆる Agent, master の指示を受ける
    • Master-Minion 間は MQ
    • NW機器対応をどうするか…Proxy Minion
    • Master → Proxy Minion → NW機器 (ssh等)
  • Grains : ホスト名、シリアル番号、バージョン番号などの基本的な情報を保存
  • Pillars : 任意のデータを保存できる

対応機種

  • 基本的には napalm と同じ

設定がちょっとややこしい

  • デバイスID → IPや認証情報は別ファイルで管理(proxy minion)

状態表示例

  • Grains から情報を引っ張ってくる
    • 内部で napalm キックして情報をとってくる
    • 構造化された情報がとれる

設定変更例

  • 定義ファイル実行
    • "changed=1"

デモ

  • 定義ファイルが更新されたら自動的に設定投入 : イベントドリブン
    • daemon で動いているのでファイル監視とかができる

まとめ

  • 多機能な構成管理ツール
各ツールの比較
  • ライブラリか、構成管理ツールか
  • 抽象化のアプローチ
  • メリット・デメリット
    • netmiko: 対応機種が多い。その分抽象化レベルは低い。
    • napalm: マルチベンダ環境の情報取得に強い…parseしてくれる。一方、設定系のメソッドがまだ少ない。足りないところは直接コマンド入力
    • ansible: シンプル! アプローチが違うので機種ごとにモジュールを使い分け。情報量が多い。開発が盛ん。
    • Salt: 高機能…イベントドリブンとかWebAPIとか。内部では napalm を使っているので、マルチベンダ情報取得に強いという特徴を。日本語情報は少ない。調べるときは公式ドキュメント頼み。

ツールつかいどころ選択

  • 管理したい危機に対応しているかどうか
  • コードを書くかどうか
    • コードにすると運用城南があるのであれば構成管理ツール系へ
  • シンプル or 高機能
    • 高機能 → 学習コストが高い
  • どの程度抽象化したいか
    • ターゲットが一つ二つであればそんなに抽象化気にしないのでは
  • 管理対象機器の種類・ベンダ数
    • 種類が多いほど、抽象化レベルが低いとベンダごとのコマンド使い分け・パターンが増える。
  • 既存で導入している構成管理ツールがあるならあわせる

まとめ

  • 特徴を把握して適材適所で
これから
  • 自動化を進めるにあたって: ツール・人・仕様
    • 人: 自動化するための設計・実装スキル、文化
    • ツール: 今回の話はここ
    • 仕様: api拡充、標準化
QA
  • dry-run/diff 表示
    • ansible, salt は dry-run できる。netmiko, napalm は自前で dry-run 動作を実装しないといけない。
  • ツールによる設定変更・管理のメリット
    • 設定要件→定義ファイルのexportなど、中間加工のしやすさ。デメリットとしてはyaml知らないといけないというのはある
  • excelからデータとれる?
    • 標準ではなさそう。やろうとおもえばやれる
  • commit の自動化って大丈夫?
    • 変なことすると途中で止まるとかはある。検証・dry-runしてチェックしたうえで実行とか、そのあとのテストなどでリスクヘッジしていく。アプリ開発の自動化とはこういった点で性質が異なる。
  • 表示コマンドの抽象化は必要か?
    • ケースバイケースではあるが、あると便利だと思う。自前で parse するのは大変。
  • 既存の自動化スクリプト+構成管理ツールでサーバとNWの一括管理というのがメリットがあるのでは
    • サーバ側を含めて、というのはメリットがあるだろう
  • 機器が対応していない場合のアプローチ?
    • paramiko (netmiko内部のssh module) ベースで自作, ansible module 自作、あたりか。
  • Ansible導入どうやってる?
    • 最初のハードル。インベントリファイルどう作るかとか。別なスクリプトかませないといけないかもしれない。最初の対応はちょっと泥臭い対応が必要になりそう。
  • 失敗時ロールバック?
    • 実装すれば全部可能。モジュールについては試していないが、junosのケースでは失敗時commitしないようになっているのでは?

所感

懇親会でも他の方と話をしたんですが、この辺のツールで気になるところはある程度共通だなあと。

  • エラー処理・例外処理
  • dry-run など実行前のチェックの可否

何かしらのカタチでコマンドを投げる、というところだけだとやっぱり実際動かしていシステムで使うのはちょっとねー、という話になる。あと、エラー処理とか例外処理とか、運用している側からすると、やりたいことそのものではないというのもあるかな。エラー処理とか対応手順とかはあるんだけど、CLIベースの機材に対してそれを自動化するための仕掛けそのものを作るのってハードル(手間的な)が高いんだよね…。ツールにあるエラーハンドリングの仕掛けの上でやりたいこと(やりたいエラー処理)に集中できるようにならないかな、と言う話とかね。