2017-09-25: RubyKaigi 2017 で Wi-Fi を吹いてきた #rubykaigi

2010 年から参加している RubyKaigi にとうとう 2017 ではスタッフとして参加してきた。今回は広島国際会議場で Wi-Fi を吹くという仕事をしてました。 https://rubykaigi.org/2017/

まず始めに、1 〜 2 日目の不安定さについて非常に申し訳なかった。だいたいわたしが悪いので悔しさしかない。ただ、3 日目は快調だったようでなによりでした。

本稿ではその裏側についてログを兼ねて書き残しておこうと思っています。

資料や設定集など

GitHub repo

Itamae レシピやネットワーク機器設定を置いておきますね。

https://github.com/sorah/rubykaigi2017-nw

今回から利用するドメイン名などを変数にくくりだしたりして他での使い回しがしやすくなっている…はず。

Grafana Public Snapshot

全体的なメトリクスと、部屋ごとのメトリクスを各日ごとに。

(ミスっていて Overview に関して snapshot では 2.4GHz+5GHz 合計の association 数が 2 倍になってます)

NOC スタッフ

メインで設計・構築・運用を担当していたのはわたし sorah ですが、当日の物理的作業やヘルプで下記の方々にスタッフをお願いしました。

今回コミュニケーションやチームビルドに関する時間がなくて公募とかじゃなくて単純にわたしの良く知る友人内で募集してお願いした感じです。

ネットワークに関係するスキルの個人差がチーム内で激しいという感じになったけれど、結果としてコミュニケーションコストがかなり低くて、雑に仕事も振れて、適宜うまいことやってくれたので大変助かりました。ただまあ、今回の L3 以上のデザインと会場についてもうちょっと把握してる人が 1 人しっかり欲しかった…。動くのが遅かったので、反省点。

総評

assoc day1
assoc day2
assoc day3

traffic day1
traffic day2
traffic day3

最大接続端末数は 786 台でした。最大トラフィックは下り 177 Mbps、上り 108 Mbps となりました。たぶん回線自体は同時に 220-250 Mbps くらい出てたのではないか。

NATセッション数は 36500 前後だった気がするけれど、SNMP で取得できてない関係正確な値はなし。

Wi-Fi 運用に必要なこと

これは今年の始めに Cookpad TechConf 2017 提供 Wi-Fi の裏側 - クックパッド開発者ブログ でわたしが書いた通りです。

  • 人間 (設計/構築・敷設/撤収・運用)
  • 会場の理解 (配線、養生や配置に纏わるポリシ等)
  • 良質な回線
  • 機材 (業務用ルータ、スイッチ、Wi-Fi AP)
  • サーバ (DHCP、DNS)
  • 消耗品 (UTP ケーブル、養生テープ、電源タップ…)

L3 以上に関しては、Wi-Fi AP の配置や運用といった部分を除けば基本的に「やるだけ」です。やるだけのはずなのに完全にトラブル起こしていて何言ってんだって感じだけど、だいたいそんな感じです。難しい事はとくに無いんだよなー。物理作業や各種調達が一番たいへん。

キャパシティ見積り

今回は最大の参加者 900、最大端末数 1400-1600 で見積りました。部屋ごとの最大端末数は例年の傾向を伺いながら決めていった感じですが、詳細は割愛。

なお、外側グローバル IPv4 アドレスに関しては 1 つじゃ不安があったので IP8 で手配してました。結果として足りてはいたけど。

設計

L1 (配線やスイッチ配置等)

L1 設計はざっくり以下。裏側の詳細な場所やパッチパネル・ローゼット番号はボカしてます。

L1 設計

下見の時に配線の設計を考えはじめましたが、今回の会場である広島国際会議場は、屋内に CAT6 やシングルモード光ファイバの配線が存在していて、パッチパネルの配線差し替えをありがたい事に OK してもらった。なので、基本的に屋内配線はそのまま線だけ借用して、パッチパネルのある場所にスイッチを置いて配線を入れ替えるという作業で完結しました。そのせいで今回は L2 スイッチの台数が結構かさんでました。

下見のときに測距に必要な機材を持っていくの完全に忘れてて、そこに関しては仕方ないので余裕を持たせて(持たせすぎた)図面を元に距離を想定してやった感じ。

AP 配置

まず台数は以下。

  • Wi-Fi AP:
    • Phoenix: 13 台
    • Phoenix 裏側: 1 台
    • Dahlia: 8 台
    • Cosmos: 5 台
    • Himawari (スポンサーブース): 3 台
    • Ran (充電・ワークショップ): 2 台
    • ロビー: 5 台

フェニックスホール図面

Phoenix 、メインホールだけ人数 900 いるし、密度高いし配置難易度高くてドキドキって感じだったけど 13 台で思ったより上手くいった! という感想。途中 2F 席開放の話が出てきて、2F には AP の設置が無かったのでもしかしたら 2F だけ不安定だったかもしれないけど…。そこに関しては 忘れてた 用意と余裕がなかったので、そこも考慮してあげられたら良かったな…って感じ。それに、2Fが1Fのを掴んでるとデータレート的に全員不幸になる話もあるので。

ほかの部屋は雑にこんなもんでしょって決めてまあ問題なかったなという見解。ちなみに Ran に関してはもともと 60 席程度でしたが途中で席が増えたみたいな話もなってちょっと警戒してたのだけれど、なんとかなってよかったです。

ちなみに、ロビーについてはデータレート緩めに許容、ホール内はちょっと厳しく、という感じでした。

UTP ケーブル

ホール内は全部 5m 以上だったので単線で、各ホールの床色に合わせて発注した。届いたケーブルは全部スパイラル状になっていたので、東京から広島へ送る前にテプラでラベルを貼りつつ全部 8 の字に巻き直すという作業をしました。60m 巻き直しほんとうに辛かった。


L2 以上

RubyKaigi は 2016 以降地方開催になっており、今回も広島ということで、この時点でクラウドで NAT する選択肢が消失する。関東近郊ならまだ考えられたけど、さすがに広島から東京はレイテンシが大きすぎる。

なので今回は普通に会場側 NAT 、ISP は IIJ FiberAccess/F でフレッツ NGN の PPPoE v4 + v6 でやりました。
会場側がここでも融通を効かせてくれて、必要に応じて追加で契約するケースの対応経験があるとの事で、新規にフレッツ光を調達した。工事立ち会いもお願いできて良かった。
ただ、NTT へはこちらから新規に連絡を取る必要があり、まず状況が分からないので問合せを投げて、よくわからない法人窓口へ回された。かなりコミュニケーションコストが高かった (電話連絡→混み合ってるアナウンスで10分くらい待つ→担当者名言う→busy なので折り返します→コールバック30分待つ みたいな感じ)。担当営業とか紹介してくれたらもうちょっと良かったのだけれど…。

L2 セグメントに関しては今回もユーザー向けは 1 セグメントで全部やってます。AP 収容、サーバ収容、スイッチ・ルータのマネジメント用、あと管理ユーザー用とユーザー用、って感じでした。

L3, NAT

Cisco IOS の設定でだいたい下記。

ip nat translation timeout 600
ip nat translation tcp-timeout 600
ip nat translation udp-timeout 600
ip nat translation finrst-timeout 15
ip nat translation syn-timeout 30
ip nat translation dns-timeout 15
ip nat translation routemap-entry-timeout 15
ip nat translation icmp-timeout 10
ip nat translation max-entries 195000
ip nat translation max-entries all-host 200
ip nat translation arp-ping-timeout 10
ip nat pool napt-pool ... ... netmask 255.255.255.248
ip nat inside source list acl-napt pool napt-pool overload

L7 (DHCP, DNS, WLC ...)

その他会場に必ずしもなくて良いサーバはさくらのクラウドにいつも通り設置しました。DNS だけは会場にも置いたけど。詳細は Itamae レシピ参照のこと。

  • DNS キャッシュ: Unbound
  • DHCP サーバ: ISC Kea
  • WLC: Cisco Virtual Wireless LAN Controller
  • Syslog: fluentd
  • 監視: Zabbix, Grafana

この構成に関しては Cookpad TechConf とほぼ同様なので、詳細は http://techlife.cookpad.com/entry/2017/01/26/120222 を参照ください。

また、今回は DHCP で AP 自体の IP アドレスも配るようにしました。 40 台規模だとそうしないと AP の初期化→設定投入が無限にコストかかっちゃうので。安定してたし Static IP にする理由はもうないんじゃないかなー。管理の都合 DHCP サーバ側で MAC アドレスから IP 固定はしてた。

機材

今回のネットワークスポンサーは http://rubykaigi.org/2017/sponsors#network にある通り、DMM.com Labo Co.,Ltd. さまおよび Cookpad Inc. さまに機材提供を頂きました。ご協力ありがとうございました。

(わたし (sorah) は Cookpad Inc. 所属ですが、実は機材・機材置き場の提供のみでわたしは業務時間で構築していたわけではないのです。本業の稼動かなり止めることになるし…。) UPDATE: Wi-Fi 準備が勤務扱いになった。設計構築運用に関してはクックパッド提供の Wi-Fi ということになりました。

運用していた AP は 38 台 (2 台予備)、間に設置したスイッチが 5 台、会場内のエッジスイッチが 8 台、という結構な規模での運用をしていました。

  • ルータ: CISCO2921/K9 * 1
  • L2 スイッチ (1G): WS-C2960S-24TS-L * 2
  • L2 スイッチ (1G): EX2200-24T-4G * 3
  • L2 スイッチ (1G): EX2200-48T-4G * 1
  • L2 スイッチ (1G PoE+): WS-C2960S-24PS-L * 3
  • L2 スイッチ (100M PoE+): WS-C3750-24PS-S * 5
  • PoE インジェクタ: EIB-UG01-PF * 5
  • Wi-Fi AP: AIR-CAP3502I-Q-K9 * 20
  • Wi-Fi AP: AIR-CAP3602I-Q-K9 * 4
  • Wi-Fi AP: AIR-LAP1142N-P-K9 * 16

UTP ケーブルは 99 本、総長 1534m でした。会場に敷設する線は単線、会場裏側のスイッチ・パッチパネル間などで使う線はより線で長さをきっちり指定して業者に発注しました。なお、会場内で利用した単線は消耗品扱いで、会場内で撤収のち廃棄処分をした。

機材運搬

運営母体が法人だと ヤマト JITBOX チャーター便 がつかえるので、これで依頼。ある程度まとまった荷物をまとめて運べる事と、着時間をピッタリ指定できるのが嬉しいところ。難点は集荷は時間指定遵守のお願いができない所だったけど、今回は 18:00-20:00 の枠で集荷依頼をして伝票に「19:30希望」と書いておいたら 19:30 に来てくれた。

敷設

今回は前日と当日朝に敷設の作業をしていた。前日 14:00 から 1 部屋だけ借りていたのでそこで荷物受取・整理をして、全館貸切となる夕方から本格的に敷設作業をするという流れ。前日は真っ先にフェニックスホールを終わらせておいて、あとは当日、フェニックスホール以外で積み残した作業をやる感じとしていた。つもりでした。

裏手のパッチパネル等の配線はわたしが一手に引き受けつつ、会場内配線はまるっとネットワーク班の他スタッフに依頼。

実態としては後述のトラブルに書いてあるが帯域が出ない・外に NAT されないといった問題を踏みまくって敷設作業に入るのが遅れた。ルータだけの問題だったからパッチパネル作業人員を他に確保していればまだ作業遅れ取り戻せたんじゃないかなという反省…。

そんな遅れもあって前日はパッチパネルの配線だけで終わってしまいました (パッチパネルの状態が予想よりも各種資料で全て食い違っている等といった混乱もあり)。フェニックスは AP の配置まで終わっていた。

なので、1 日目は朝から改めてホール内配線作業を。実はフェニックスの配線終了は 9:30 だったのでした (Door open ギリギリすぎる)。そんな状況だったので 1 日目は午前中一杯いろんなホールの敷設作業をしていました。なんとかいろいろ間に合ってよかった…。とはいえ下記のようなトラブルがあり完全に全部上がったのは午後となった。

あ、AP を設置する譜面台に関しては会場から借りる事ができました。荷物減って便利だった。

当日の運用

運用に関しては後述のトラブルシュートがメインで全然できてませんでした。でも各種メトリクスや Grafana のダッシュボードを見ている限り WLC の操作が必要そうなほど AP ごとの Associations が偏るというのは観測できてなく、あまり何もやらなくても良かったかなって感じ。Client Load Balancing 今回はトラブルなかったかな…? 観測できてないだけかもしれない。

後手にまわってしまって手遅れ気味ではあったけど、1、2、3 日目で Door open 前や close 後に若干パワーレベルを全体的に調整するなどは適宜やってました。チャンネルについてはほぼ何も弄れてない。2.4 GHz の間引きも同様に後手にまわってぼちぼちやってた感じ。

撤収

最終日の 15:50 からラン (充電コーナー) を締めさせてもらって機材の整理と梱包場所とさせてもらった。参加者の皆様、ご協力ありがとうございました。

作業の流れは、そもそも単線の UTP ケーブルに関しては捨てるという事が前提だったので、まずは集荷に載せる荷物 (= 機材) を真っ先に回収して捨てるという事に。残っている単線についてはネットワーク班外のスタッフにも協力してもらってどんどん回収。

でもって、16:30 のコスモス・ダリアのセッション終了と同時に、Wi-Fi AP とスイッチから順次回収していた。ヒマワリも早めに Wi-Fi だけ撤収させてもらいました。

17:40 からの Closing で一旦作業を止めてホール内に居るようにして、Closing 後は再び裏側などからパッチパネルの現状復帰をしつつ機材を回収していた。

人手があった事もあり 19:00 には完全撤収完了で、そのまま 19:30 頃に集荷に載せて撤収作業完了となりました。素早かった!

トラブル

基本的に全部わたしのミスなので申し訳ない限り。

前日設営時になんかインターネットに出れない

これよくわからん。NAT 周りな気がするんだけど… ルータ reload したら直った。

前日設営時、帯域がない

そもそも ↑ はこれが原因だった気もする。だいたい 4-5% パケロス、TCP 1 本 10Mbps 程度しかでない。これは話にならない…と絶望感。当日台風だったしみんなインターネットしてたか何か起きてたかだと思うんだけど… NTT 障害情報は無かった模様。NTT の対応基本的に平日日中なのでトラブルは即座に「死」という感じなのでつらい。

一応切り分けは一通りやった: PPPoEv4 網内速度測定, PPPoE を MacBook で直接終端+測定, ISP 変更等々。
(NGN IPoE v6 での網内速度測定は西日本 v6 オプションがデフォルトでオフなので出来ずだったけど、PPPoE v4 網内測定は問題がなかった…。)

なのでよくわからないし前日はもう諦めて裏側のパッチパネル配線とスイッチ設置まで済ませて、このようなツイートをして寝ました。翌朝 4 時に目覚めて真っ先に clear pppoe all したら全部いい感じになって、なんやねんという想いに尽きる…。

1 日目、一部の AP に繋がらない

FlexConnect の VLAN support 設定が抜けてる AP がたくさんいた。AP 収容 L2 セグメント (/24) にユーザーがぶらさがっていた。ちゃんと確認しましょう。Web UI しんどいけど 1 ページずつ AP の情報見て順次直してました。Grafana の Overview ダッシュボードで 1 日目に DHCP AP pool が枯渇してるのは、そういうことですね。さらに、そこからインターネットには抜けられないようにしていたはずだし。

これ最初気付いてなくて、「なんかAPのDHCP poolが半分埋まったアラートきてるけど後で見よ…」という感じだったけど、クックパッド社内から + スタッフ内でもスポンサーブース全部ダメみたいな話を聞いて調べてすいませんでした、となった。

1 日目 DNS が引けない

設定ミスってて会場内 DNS から IPv4 で外に出れなくなってました。IPv6 な権威サーバあるところは問題なかった。もうねー、アホかと、しっかりやれ。
で、それに加え後述のパケロスで SERVFAIL しまくりという状態。そして IPv6 CEF 問題の関係で IPv6 はもっとパケロスひどかった。

2〜3日目もまあだいぶ無理があったぽくてちゃんと調べてないが ISP 上流しらべて設定しなおしてマシになったという感じ。何も考えずにフルリゾルバにして static NAT していたけど、ダメだったかー…。NAT まわりな気がするけど原因調べきれてないです。あと会場からのフルリゾルブ、 IIJ 網内の Akamai cache を見に行ってなかったみたいだね。ちゃんとやろうな以上の話はないですね…。

さくらのクラウド側のを一時的に DHCP で配ってたりしたんだけど、そっちは問題なかったみたい。NAT っぽい。
とはいえ、会場が地方だと DNS のレイテンシがつらくて会場内にキャッシュ置くのが不可避だよねー。安定してるのを安定したままそのまま使うというのが安定するのは確かでも。

1〜2日目とにかくパケロスする (ルータで)

これがかなりの品質低下を招いていた。今回 DHCP サーバがルータの先にいる以上、ルータでパケットを落とされると DHCP offer などが取得できず、 DHCP request が爆増してさらに負担が上がる… っていう二次災害も発生していた。そして当然ながら DHCP で IP 取得できずみんな何もできないという状況が続いていた。

DHCP に関してはしんどかったし、最大接続台数も見えてきたので途中から Lease time を大幅に伸ばして若干安定したと思います。

具体的には上流は問題なくて今度はルータでつまっていた。具体的には CPU 処理に回っているパケットが多すぎるようで下記な感じ。普通は全部 ASIC 処理のはず…。

rt-01: CPU load

PPPoE 上で IPv6 CEF が効かない!

CEF とは Cisco Express Forwarding の事です。これが効かないと CPU でパケットの転送先を決めることになって負荷が高い。デフォルトでオンの機能です。

なんか IPv6 Input が食ってるな…とまず発見したのがこれ。show interface switching みても全部 Fast 0 でヤベーこれは無理だ、となった。

もう全くわからないので IPv6 アクセスを無くすのは非常に悲しいけど、各種 Lifetime を 0 にした RA を高速に配布して IPv6 トラフィックを削って、ある程度なくなった時点で IPv6 を落としました。悲しい…。

機種は違うけどこれと同じ症状な気がしている: IPv6 PPPoE使用時にCEFが動作しない - Cisco Support Community

根本原因 (一部) 特定

結論から言うと Cisco IOS の CBAC (Linux でいう conntrack)、ip inspect を入れてたんだけどこれがめっちゃ割込み増やすようで、これ外したらマシになった。それでも日中 (快適に使えるが) 割込み 90% 前後を記録してて、結局それは謎のまま。雑に外したせいで VPN 不通になっちゃったみたいでそこは申し訳ない。 (IKE の UDP パケット通さなくなってた)

なんで入れてたんだと言われてたらそうですね、よくない手癖っぽい気がした。NAT してるなら別に permit tcp any any establishedpermit udp any any で足りたんじゃないかとは思いますね。でも NAT しない IPv6 ではこれ欲しいんだよなー。IPv6 で入れてた関係でそのまま IPv4 でも入れた、とかだった気がする。

C2921 そこそこ強いルータだから問題ないとは思っていたけど、これか〜って感じ。割込みの原因を特定するのが箱物ルータだと本当にブラックボックスすぎて辛い。

そういう意味でも、出来ればクラウド上設備で全部処理して会場ルータは VPN とトンネルしかやらないって状況にしたい所。当日に接続先変更したりいろいろあわただしい感じになっちゃって大変。

反省点

  • この規模 1 人構築なかなか大変
    • でもこの規模だと分担するのもなかなか大変じゃない…?
    • 構築は別に分担できなくてよくて、パッチパネルなどの配線に関して 2 人で下見行ってれば問題なく分担できたのではないか。そっちだよね。トラブルシュート人員が配線人員と兼ねてるのが良くなかった。
  • 人手はもっと早く掴まえておきましょう
    • 下見にネットワーク担当っぽいのが 2 人いるのが理想的。
  • ちゃんとトラフィックを一定時間流してテストする時間を取りましょう
    • ハイ
  • 実は L2 スイッチの機能セットの問題で端末間の通信阻止が設定できずでした。
    • どれくらいの人が気付いてたかさえ分からないけど。vWLC だと FlexConnect になる都合、全部のスイッチで防がないといけないんだけど、今回の L2 スイッチの機能セットや構成だとなかなか難しかった。
  • 前日中に設営が終えられないことによるチャンネルやパワーレベルの計測・調整が甘かった事
    • ちまちま会期中といっても、2日目後半になって調整できるようになった感じでした。Android だとアンテナピクトが max にならない閾値が iOS より低いので、しばらく Android ではどこでも電波弱いとかになってたんじゃなかろうか。なんでか Auto assign 切ってたけど、正直入れっぱなしでもよかったかなぁ…。
  • 養生テープ不足…雑すぎましたね見積りが。

ひー。まだまだ精進が必要。

Sustainability

特定のスタッフが SPOF になる状況が長年続くのは非常によくないと思います。今回わたしが主で担当したけど、正直わたし自身は問題なくても、これが何年も続く状況は不健全だと自分でも思っている。固定的でも、チームで動ければかなりマシ。

問題はどれくらい安定的に勝手が分かっている人手が確保できて、安定的に機材が確保できて、さらに構築面でどれだけ手が抜けるか (= 使い回せるか) という話になるなー、と個人的には思っている。

人手に関しては興味ある人が寄ってきてくれたら後は教えるだけなんだけど、わたし自身人に何かを教える事が苦手なのでこれが難しい。ある程度 L3 までの知識があって適宜聞いてくれたらなんとか…って感じ。
べつにやってる事自体は Wi-Fi 運用を除けば中規模くらいのオフィスで耐えるネットワーク作るくらいの話だし、特別な話は高密度な Wi-Fi 運用と、特殊かつ高速な敷設撤収のノウハウくらい。難しくないと思うんだけど、最近この辺に首突っ込んでくる人が少なくて寂しい…。

機材については次に難しい。今回わたしがスポンサーしてくれそうなところから機材を借りさせてもらったのだけど、探すコミュニケーションコストが高すぎる。とはいえ、毎年 1 度のカンファレンスの運営母体で必要な機材を買って年 1 で使うというのももったいない気がするんだよね。運用は別にしろ機材だけなんかまとめて購入・補完しておいていろんなカンファレンスで使い回すみたいなの、誰かやってほしい。(誰もやりたくないんじゃないかとは思う。)

構築で手を抜くのはそんなに大変じゃない。サーバの設定に関しては最近全部使い回してて (Cookpad TechConf の時、KMC 40 周年カンファレンスの時、そして今回の RubyKaigi) 、ルータやスイッチの設定もほぼ使い回せているし、台数あるロールで同じ設定を入れていったりとか、機種間差を吸収したりとか、AP 40 台全部初期化したりとかはしんどいけど。人手いればどうにかなるしなー。

来年わたしが Kaigi でネットワークやるかどうかは分からないけど、今回 Kaigi スタッフになってみたら楽しかったし、まあ何らかの形で関われたらいいなーと思います。ネットワークやるならもっと早期から絡んでいろいろ考えとけばもっと手は抜けるはず。今回も時間の関係で相当手を抜いたけどね。

まとめ

このように、自分としては満足のいくサービスを提供ができなかったという悔やみがあるけど、おおむね懇親会等では好評だったり、サイネージを最終日の Keynote のメインホールに集中している時間以降でも Wi-Fi 経由で 更新を反映させられる のは初なんだよ、とかとか言われたりでカンファレンス中の最低限の人権の提供というラインは満たせたかな? という認識です。そのような声を聞くのは嬉しかったですね。瞬間的に大きなネットワークを組むのも、カンファレンスの運用に携わるのもわたしとしては非常に楽しい経験ができたし。

というわけで、RubyKaigi 2017 のネットワークについてまとめました。

Published at 2017-09-25 10:27:02 +0900