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

オープンソースカンファレンス 2016 Tokyo/Fall

http://www.ospn.jp/osc2016-fall/

【開催概要】

日程 11月5日(土) 10:00~18:00(展示:11:00~17:30)
11月6日(日) 10:00~17:30(展示:10:00~16:00)
会場 明星大学 日野キャンパス 28号館 2F(OSC受付)
(多摩モノレール 「中央大学・明星大学駅」から大学まで直結。会場まで徒歩6分)
内容 オープンソースに関する最新情報の提供
・展示 – オープンソースコミュニティ、企業・団体による展示
・セミナー – オープンソースの最新情報を提供
主催 オープンソースカンファレンス実行委員会

【登壇情報】

登壇者 XaaS部
大山 裕泰
登壇日時 11月5日(土)13:00~13:45
登壇内容 マイクロサービスを支える MQ を考える
マイクロサービスアーキテクチャに見られるような、分散したシステムを有機的に結びつけ、一つの大きなサービスを提供するシステムにおいて MessageQueue (MQ) は非常に重要な役割を果たします。
MQ は単なる各システム間のメッセージの仲介役としてだけではなく、負荷平準、可用性の向上、スケーラビリティを担保するといった役割も同時に果たすことができます。
ただサービスの形態が異なるように、システムも様々な形態が存在し、システムの形態によってMQ に求められる要件も異なります。例えば、冒頭で述べたような認証や決済、コンテンツサービスなど様々なシステムと連携したアプリケーションや、様々なサービスから送られるログを集計し分析する基盤、または大量のサーバのメトリクスを集計するパフォーマンス監視基盤など、様々な形態の仕組みにおいて、それぞれ MQ に共められる要件は異なり、それらの要件を満たす様々な MQ の実装が存在します。
本セッションでは、こうした MQ の実装の一つとして開発した NewtMQ について、これが一体どういうものかについての紹介と、どういったユースケースで効果を発揮するかについて議論してみたいと思います。

 

 

Scality Japan SDS Day 2016 Tokyo

https://omniattend.com/seminar/scality-jp/sds-day-2016

 

【開催概要】

日程 11月22日10:30-17:30(受付開始 10:00)
会場 コングレスクエア日本橋
内容 国内・海外の事例公演多数。
SDSとオブジェクトストレージの今とこれからが1日で分かる。
主催 スキャリティ・ジャパン株式会社

【登壇情報】

登壇者 配信インフラ構築運用部
渡辺宣彦
登壇日時 11月22日(火)10:30-12:10
登壇内容 国内ユーザー企業様による成功事例講演②
弊社の動画配信で導入した事例を紹介します。

Internet Week 2016

https://internetweek.jp/

【開催概要】

日程 2016年11月29日(火)から12月2日(金)の4日間
会場 ヒューリックホール&ヒューリックカンファレンス
内容 インターネットの発展を推進する
インターネットに関する議論の場・交流の場を提供する
セミナー開催によるインターネット基盤技術の普及を図る
主催 一般社団法人日本ネットワークインフォメーションセンター(JPNIC)

【登壇情報】

登壇者 XaaS部
高嶋隆一
登壇日時 12月1日(木)11:10 ~ 12:00
登壇内容 ネットワーク機器の本当のスペックを見抜く
ユーザー企業における機器検証とは、

サービスに必要な機器を選定する過程で実施されるケース
それらに先立って情報収集する段階で実施されるケース
等が考えられます。

本セッションではどんなプロセスの中でどんな機器検証が必要になってくるのか、 ユースケースをまじえてお話しできればと思います。

登壇日時 12月1日(木)13:15 ~ 18:45
登壇内容 DNS DAY
コンテンツプロバイダから見た権威DNSサーバ

・想定されるユースケース
・ユースケース毎に用いられる実装
・ユースケース毎の注意点

について共有し、議論できればと思います。

登壇者 ツチノコ企画室
熊谷 暁
登壇日時 12月1日(木)13:15~15:45
登壇内容 Wi-Fi”再”入門 見えない電波を知識で見抜く~社会的課題も交えて~
Wi-Fiの基礎技術と電波の知識
Wi-Fiの応用ノウハウと最新技術トピック
Wi-Fiを取り巻く課題

最後に

オープンソースカンファレンス 2016 Tokyo/FallとInternet Week 2016はイベントに協賛しているのでブースを出します!
ぜひ、ブースにも遊びに来てくださいね。

また、phpcon 2016では、会場ネットワークを構築するメンバーに弊社エンジニアも参加しております!
イベントに参加される皆さまは、ぜひ!会場WiFi使用してくださいね(^o^)

 

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