StackStorm

 インフラ本部の大山裕泰です。今回は Brocade が買収したことで話題になった、イベントドリブンな Workflow エンジン StackStorm が一体どういう仕組みで動作しているか、ちょっと深堀した内容をお届けします。

 StackStorm 自体については、先日行われた StackStorm 勉強会で 発表された方の資料 で詳しく解説されており、使い方についても こちらこちら のページで詳しく解説されています。
 「StackStorm を使ってみたけど、裏側で何がどうなっているかイマイチよくわからん」といったユーザ向けに、StackStorm の論理構造を解説し、StackStorm の理解の手助けが出来ればと思います。

StackStorm について

 StackStorm のドキュメント を冒頭から読んでいくと、いきなり次のような図が情報します。

 一見とても複雑そうです。ターゲットに紐付く依存関係を解決してコマンドを実行する “古典的なワークフローエンジン” とは違います。
 初めて触るユーザや、とりあえず QuickStart だけやってみたユーザにとっては、なんでこんな複雑な機構なんだろうかと戸惑われたかもしれません。
 本エントリではこうしたユーザ向けに、StackStorm の概要についての理解と、上記の内部アーキテクチャの詳細についての理解の中間的な論理構成の理解を手助けする内容を提供していきます。

StackStorm の論理構造

 以下は、StackStorm がイベントを処理する仕組みについて表した図になります。

 Sensor は外部で発生したイベントを監視するモノで、外部のイベントを検知した際には予め登録された Trigger にイベントの発生を通知 (以降では “Trigger を引く” と表現) します。
 Trigger は Sensor から通知された外部イベントを Action が扱い易い形に正規化します。何も設定されていない状態では、Sensor が Trigger を引いても何も発生しません。Trigger が引かれた際にどういった処理 (Action/Workflow) を実行するかを規定したものが Rule になります。
 Rule には二つの役割があります。一つは上述した Trigger と Action/Workflow を紐づける役割で、もう一つが Trigger パラメータと Action パラメータを変換する役割です。
 StackStorm では Trigger と Action はそれぞれ独立しており、Rule によって任意の Trigger と Action を組み合わせることができます。その際、Trigger から渡されるどのパラメータを抽出し、どういったパラメータを Action に渡すかの設定を Rule に記述します。

 以下の具体的なケースに置き換えて考えてみます。

 ここでは Sensor, Trigger, Action にそれぞれ以下を使用し、GitHub の特定のリポジトリで Issue を作成(更新)した際に RabbitMQ にメッセージを送る仕組みになります。
 尚、StackStorm では Sensor, Trigger, Action を機能毎にまとめたソフトウェアコンポーネントのことを pack と呼びます。そして、上記の github は rabbitmq のようなサードパーティの pack は (本エントリ執筆時点では) StackStorm/st2contrib リポジトリで管理する運用になっています。

 Sensor ‘github.GithubRepositorySensor’ は 30 秒毎に GitHub のリポジトリの更新状況を確認し、前回の確認から更新が発生した場合には Trigger ‘github.repository_event’ を引きます。
 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。この Rule の内部で Trigger パラメータ (Issue に対する操作(opened/closed)、及びタイトルと本文) を Action パラメータ (exchange, routing-key, message) を次のように変換しています。

動かしてみる

 確認する GitHub のリポジトリは、GitHub pack の設定ファイル ‘/opt/stackstorm/packs/github/config.yaml’ で指定します。以下に設定ファイルの全文を示します。

 ここでは、この Trigger が引かれた際に Action ‘rabbitmq.publish_message’ を実行する Rule ‘example.github_event_invocation’ を記述しました。以下が設定したルールの全文になります。

 ’trigger’ / ‘action’ のパラメータで、それぞれ図の Trigger / Action を指定します。’action’ の ‘parameters’ で当該アクションに渡すパラメータを指定します。ここで Trigger から渡されるパラメータと Action パラメータの変換処理を行っています。
 ’criteria’ パラメータは、Trigger に通知されたイベントのうち Action で処理するモノを選択する際に利用します。今回の例では Trigger はリポジトリに対する Issue の更新/コメント、Fork、Watch、Push などのイベント発生時に Sensor によって引かれますが、Issue の更新イベントだけ Action を呼ぶようにしたい場合にこのように設定します。

 それでは実際に GitHub リポジトリ に Issue を作成し動作を確認します。RabbitMQ に通知された メッセージを受け取るスクリプト を実行し、リポジトリに以下のような Issue を作成します。

 こうすることで Sensor が検知したイベントを Trigger に通知し、Rule に沿って RabbitMQ にメッセージが送られます。そして、先ほど実行したスクリプトで送られたメッセージを取得できることが確認できます。

JANOG, イベント, インフォメーション, ツチノコNOC

こちらの記事で募集をかけさせていただいたツチノコNOC(仮)のメンバーが決まりました!
ご応募いただいた皆さまありがとうございました٩( ‘ω’ )وツチノコNOCは、来年1月のJANOG39ミーティングの会場ネットワークを構築するために、社内・社外・学生を含めて27名のメンバーで構成されたチームです。

キックオフミーティングを開催しました

先週末、キックオフミーティングが開催されました!
テレビ会議を使用して金沢や仙台からも会議に参加していただきました。

20161006_210722img_9285img_9290

ミーティングでは、JANOG39ミーティングの会場ネットワークをどんなものにしたいかを共有しました。
”すぐ動いて、すぐ壊せるやつを作りたい!” から ”OpenStackでやりたい”
など、たくさんのやりたいこと案が出てきました。

チーム分けをしました

今回は、チームを4つに分けました。
チームの役割について説明をし、自身が携わりたいチームを選んでもらいました。
サーバもネットワークもやりたい!という人は、どちらにも所属していいルールです。

役割 仕事内容
ネットワーク
  • ネットワークの物理設計、論理設計を行なう
  • アドレス管理、VLAN管理を行なう
  • ネットワーク機材の設定を行なう
WiFi
  • 機器(無線AP, スイッチ)の配置場所を決める
  • 会場内の配線図を作成する
  • ケーブルを準備する
  • WLC、AP等のWiFI機器の設定を行なう
サーバ
  • サーバ(DHCP, DNS cache, 監視など) の設計と設定と行なう
サポート
  • 外部との調整を行なう
  • 内部スケジュール調整を行なう
  • ドキュメント管理責任者
  • ツチノコNOCのPR, SNS係, 撮影係

img_9289

どのチームも満遍なく人が振り分けられていい感じ♪
なかなか「サポート」に手が挙がらなかったのはご愛敬です。

暫定リーダを決めてチーム分けは完了し、この日は解散となりました。
続きはオンライン上でチームに分けれて意見を出し合いながら、どんな構成でいくかを決めていいきます。

さいごに

普段の業務はiOSアプリの開発、社内SEといったインフラ寄りではないメンバー、学生、インフラエンジニア
とバラエティ豊かなメンバーで構成されたツチノコNOCがどんな会場ネットワークを作ってくれるのか今から楽しみです!

今後もツチノコNOCについて情報を発信していければと思っております!
どうぞ、ご期待ください。

ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

タイトル:調子が悪いんでしょうか?

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

 *1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

  *2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!

ICTSC, イベント, 雑談

8月末に大阪で行なわれた、第6回ICT トラブルシューティングコンテストに今回もお邪魔してきました。

ICTSC – ICTトラブルシューティングコンテスト
http://icttoracon.net/

2日間の戦いの後は、運営側の採点が行なわれるのですが、その採点時間の間、参加者の学生達にイイ話をして場を繋がなければいけません。
学生も大変ですが、大人も意外と大変です。
前回のICTSC5のときは、大人っぽくお金の話をしたのですが、2回続けてお金の話はヤらしいよなあ、と思って数学の話をしてみましたよ。

発表前に、数学好きな人ー?、と聴衆の学生さんに聞いたところ、挙手は皆無。
お金の話のほうが聞きたかった人ー?、と聞いたら、挙手がちらほら。
ありゃあ、はずしちゃったかあ、と思ったけど、発表後に、数学を勉強してみたいと思った人ー?、にちらほらと手が挙がったので、まあ喋って良かったかのなあ。
でも最近の若者は気を使ってくれるんだよねえ。ありがとう。
前回のICTSC5のときに喋った資料もついでに吊っておきます。出すのを忘れてました。

イベント, インフォメーション

来年1月に開催されるJANOG39 ミーティングのホスト企業をDMM.comラボが務めさせていただきます!
少しずつですが、準備を進めていますよー!

さてさて、9月7日よりJANOG運営スタッフの募集が始まっていますが、本日はツチノコNOC(仮)と称した会場ネットワークを構築する部隊のメンバーを募集します!

JANOG39 ミーティングについて

名称 JANOG39ミーティング
日時 2017年1月18日(水)~20日(金)
※1月19日(木)の本会議終了後に、懇親会が開催されます。
会場 本会議:金沢市文化ホール (http://www.bunka-h.gr.jp/)
懇親会:ホテル金沢 (http://www.hotelkanazawa.co.jp/)
主催 日本ネットワーク・オペレーターズ・グループ
ホスト 株式会社DMM.comラボ (http://labo.dmm.com/)
参加費 本会議:無料
懇親会:有料 (金額未定)

来年1月18日から3日間に亘り、日本中のネットワークオペレータが一堂に集い、情報交換や議論を行うことを目的とした会です。

JANOG39の詳細や、スタッフ・プログラム募集については下記のページをご覧ください!
https://www.janog.gr.jp/meeting/janog39/

ツチノコNOC(仮)について

ツチノコNOC(仮)は、JANOG39本会議中に使用する会場ネットワークを構築するチームです。
JANOG39 ミーティングの運営スタッフとは異なりますのでご留意ください。

求める人材像と具体的な作業内容について

求める人材像

– イベントネットワーク構築に興味がある
– 大規模WiFi環境を作ってみたい
– イベント運営の裏側が見たい

具体的な作業内容(すべてを1人で行っていただくことはありません)

– 会場下見・ネットワーク回線の手配
– ネットワーク設計・当日作業手順所作成
– 監視(設計・設定・セキュリティ含む)
– 無線AP、無線コントローラ・L2/L3スイッチ設定
– ケーブルアサイン・タグ作り

構築経験は問いません!
学生の方、面白い事をしたいエンジニアの方など大歓迎です!
なお、応募多数の場合はバランスを考慮し選考させていただく場合がございます。

大まかなスケジュールについて

9月 メンバー募集→メンバー確定
10月 キックオフミーティング、チーム分け、アイディア出し、機材手配
11月 システム設計、機材準備
12月 東京にてホットステージ、システム仮組み、動作テスト
1月 金沢にて本番環境構築
2月 クローズミーティング

応募方法

応募は、以下のフォームよりお願いいたします。
締め切り:10月3日(月)10:00まで

https://goo.gl/forms/vbA5MeDEFI35ExBa2

 

最後に

ご質問、ご要望、疑問などございましたら、お気軽にご連絡ください!
冬の金沢で一緒に会場ネットワークを構築しましょう!皆さまからのご応募お待ちしております!!

PAGE TOP