はじめに
こんにちは！KADOKAWA Connected、ネットワークチームの 立松(Matsu) です。データセンターとキャンパスのネットワークサービスのデザイン、デリバリ、O&Mの業務を担当しています。会社ブログへの投稿は初めてなので、読みづらいところもあるかもしれませんが、お付き合いのほどよろしくお願いします。
ところざわサクラタウン
さて、皆さんは、KADOKAWAが世界に誇るポップカルチャーの発信拠点、ところざわサクラタウンをご存知でしょうか。
ところざわサクラタウンは、ミュージアム、イベントホール、ホテル、レストラン、書店、オフィス、神社、書籍製造・物流工場などを有する文化複合施設です。
複合商業施設に求められる無線ネットワーク
ところざわサクラタウンの無線ネットワークには、下記の要件が求められました。
- オフィスや工場における高密度かつ多様なネットワークへの無線アクセス
- e-sportsイベント実施への低遅延
- 24時間稼働施設としての高品質・安定性能
これらを満たすためKADOKAWA Connectedでは、ところざわサクラタウンを都内のデータセンター(プライベートクラウド含む)とダークファイバーを用いた自前の専用線で直結し、訪問客の皆様や従業員を対象とした、無線LANアクセスによる低遅延・高品質・多機能なネットワーク環境を提供しています。
協業アプライアンス機器ベンダー様のPRサイトでも紹介されておりますので、ご興味のある方はぜひアクセスしてみてください。
この記事でお話しすること
この記事では、ところざわサクラタウン開業後における無線LANデプロイの際に我々が経験した、「ヒヤッ」となったお話をします。我々と同じ様なネットワークサービスを提供する業務をされている方への情報共有や、技術コミュニティの活性化につながれば良いな、と考えています。集中管理型の無線LANのアーキテクチャにある程度親しんでいる方向けの内容になっておりますので、どうかご承知おきください。
ところざわサクラタウンの無線ネットワーク
ところざわサクラタウンの無線ネットワークの概略図は以下のようになります。都内データセンターのプライベートクラウド上に無線LANの制御コアであるMM(モビリティマスター)を設置し、ところざわサクラタウンキャンパスにおいて無線LANのAPを収容するMC(モビリティコントローラ)をMD(マネージドデバイス)として管理するMM-MD構成を採用しています。
なお、概略図では省いて記載していますが、MDはクラスター構成を組んでおり、その他の設備も完全に冗長化しています。
※MM:モビリティマスターは、現在はMC:モビリティコンダクターに名前が変わりました。MC:モビリティコントローラと略称が被ってしまうので、本記事では便宜的に古い名称を使用しています、ご承知おきください。 用語変更のご案内：Terminology Change | 日本語フォーラム
もう少し詳しく描いた図としては下記のようになります。MMは冗長化されたプライベートクラウド上に設置してあります。MC(つまりMDのこと。ややこしいな・・・)からAP(無線アクセスポイント)までの足回りも、冗長構成を取っています。
MDとAPはそれぞれトンネルを張り、ユーザトラフィックはカプセル化されてトンネルの上を通りますので、MDからAPまではトンネルのみが流通する単一のL2空間構成として設計しています。
また、コアSWとフロアSWはベンダ独自技術を用いたスタック構成を採用していますが、可能な限り標準化された技術で実装する方針を取っています。
さてさて、ここまで冗長構成を組み上げたとて、決して慢心してはならないのがインフラオペレーションの常です。どのような「ヒヤっと」が出てくるのでしょうか？
ヒヤっとした話その１：クラスタ構成のMCが交互に死亡する話
ある日、クラスタ構成のMD2号機が突如としてMMと疎通不可能になり、当該機にジョインしているAPが全て外れてしまう(=APから電波が吹けなくなる)事象が発生しました。
現地(サクラタウンオフィス)の担当者と協力し、MD2号機のリブートを実施したところ当該機のMMとの疎通は復旧しましたが、今度はMD1号機が同様の事象に陥ります。以降は、同じことの繰り返しです。
ベンダーサポートとも連携し、切り分けを続行しますがなかなか解消しません。とある担当者が、「数日前に追加したlogの設定かも・・・？」と特定のlog取得設定を削除したところ、事象は復旧に至りました。
実は、MCの出力するSyslog情報が少ないため、とある担当者がMC(MD)に全てのシステム サブカテゴリーのログを出力する設定を追加していたのです。
logging security process aaa level debugging
logging security process authmgr level debugging
logging security process authmgr subcat aaa level debugging
logging arm subcat all level debugging
logging security subcat all level debugging
+logging system subcat all level debugging
logging wireless subcat all level debugging
後日ベンダーサポートに事象発生時にrsyslogdのCPU使用率を確認してもらったところ、負荷が高い状況となっていることが確認できました。筆者は昔、某社のナントカ7206VXR(NPE-300)という機器でteminal monitorを有効にしログを大量に吐き出したらサービストラフィックに影響を与えてしまった経験があるのですが、なるほど無線LANコントローラもCPU処理でトラフィックをやりとりしていることを忘れてはいけないな、と思い出した事案でした。まさかSyslogの設定で主信号の通信に影響が出るとは思いもよりませんでしたが、特にdebuggingというレベル指定には敏感になっていた方が良いですね。
教訓：商用機器でSyslog情報を多く変更するときは、その機器のアーキテクチャをしっかりと把握すること！
ヒヤっとした話その２：無線アクセスポイントを追加したかっただけなのに！
施設のオープンから半年ほど経過し、WiFiの電波のエリアを広げたい！という要望が来るようになりました。そこで、複数のAPを追加する工事を実施することとなりました。WiFiの電波を広げたいエリアは沢山あり、検討の結果、20台ほどのAPを複数の階で、10台ほどのスイッチへ結線する事となりました。
工事の流れとしては、APの物理設置を実施する工事業者さんの選定、物理配線の設計、工事業者さんとの契約、APの設置や配線に向けた各所調整と段階を踏んで実施していきます。また、APの設置の際に確認しておいたAPのMACアドレスを、事前に無線LANコントローラの親玉でもあるMMに登録し、APがネットワーク的につながれば電波を吹ける設定にしておきます。
工事業者さんから、APを結線しましたよ〜と連絡が来たら、いよいよAPが接続されているスイッチの設定を実施していきます。
スイッチの設定作業は、過去に施設の建設時にも大量に実施をしています。同じ作業をした際に、何か課題があったような心の引っ掛かりがあり、念のために人の少ない深夜帯、自宅からリモートワークで実施をすることにしました。
個人的には、大量の機械にポンポンと設定を入れていくこのフェーズが、一番楽しいところです。業務効率化とミスの防止のため、テンプレートエンジンを用いて自動でConfigを作成し、さらに自動で投入するカラクリを採用しています。個人的に「ネットワークシェル芸」と言っているのですが、シェルスクリプトにより、追加AP一覧のリストからテンプレートエンジン(m4マクロ)でConfigを自動生成し、機器のベンダに適したexpectのwrapper(rancidのhlogin)経由で装置への流し込みを行います。
なお、APには2本UTPケーブルが刺さるポートがあり、サーバのようにそれぞれがActive/Standbyの設定になっています。サーバでいうbondingのmodeでいうと、「active-backup」でしょうか(APに直接コンソールを接続してみると組み込みLinuxが動いているようなので、そのものかもしれません)。仮にスイッチが一台死んだとしても、無線LANサービスが継続して提供できるような設計にしています。
これでネットワーク的にAPはMD(MC)と疎通性ができたのですが、スイッチ側から見ると、中々APが論理的に上がってきません。通常、APがMDからプロファイルをフェッチしその設定が適用されると、スイッチ側でAPのホスト名がLLDP経由で把握することができるのですが、そこに中々至りません。
過去の実施手順を漁っていると、「MMに事前にAPを登録しても、時間が経つとexpireするから再度活性化作業が必要」というノウハウを見つけ、MMにログインしたところ、何か嫌な気配を感じました。コンソールが若干、重たいのです。
するとslack上に「APのジョイン数に変更があった」メッセージが監視システムから飛んできました。少し時間がかかって、APが上がってきたのかな？と楽観的に構えていると、slackのメッセージに気づいた輪番担当の同僚から、「APのジョイン数が大量に減っているけど、何か作業しましたか？」という恐怖の問いかけが来て、嫌な汗が出てきました。お楽しみタイムは終了し、恐怖のトラシューの時間です。
慌ててスイッチを確認すると、新設AP向けのポートでループを検知して、自律閉塞されているじゃありませんか。そういえば、施設建設時のAP初期構築の際に、毎回ではないけれど偶にループがあったな、ベンダに問い合わせしても有効な回答がなく、それでループ検出やBUMのリミットをガッチガチに厳しく設定し直したのだった。心の引っ掛かりはそれか〜と妙に納得しつつ、慌てて設定投入をしたスイッチに対し、老番側のインタフェースを一斉に閉めるスクリプトを書いて復旧させました。
なぜ、デフォルトでAPはアップリンクがActive/Standbyであるはずなのにループが発生してしまうのか、ベンダサポートに問い合わせをしていますが、未だにメカニズムが判明していません。
ベンダーのユーザのコミュニティである、「AirHeads Community」を確認すると同様のケースが確認できました。APがMDにジョインするまでL2ループが起こるという状況的にも同じ経験をしているユーザがいて、「ポートを2つ使いたいときは、どういう設計するのが定石なのかなぁ？」と問いかけがされていました。僕もコメントしておきましたが、1年ほど前のポストで反応がないので、新たにスレッドを立てて議論してもいいかもしれないですね。
redditでも似たような悩みを抱えている人が居る様です。AP向けにLAGを組む、そもそも一本だけにする、Active/Standbyになるから無問題、色々な意見がありますが、あなたはどれが良いと思いますか？ちなみにLAGを組んだとしても、APとMD間はトンネルを張ることになるので、(hashingによって)トラフィックはどちらかのリンクに寄る事になると思います。
教訓：過去に発生した課題は管理表に記載し、解決までトラッキングをしっかりすること。サービス影響がないはずの作業であっても(さらに深夜のリモートワークでも)、誰かと一緒に実施できると良い。コミュニティの情報にも目を通しておくと吉。
ヒヤっとした話その３：給電不良！？
これはヒヤッとパート2のその後のお話しです。やれやれ、ループも収まり電波も吹いた。現場で電波サーベイをしてもらって検収し終了という段階で、「一部のエリアで電波状況がAPの設置前と変わらないです」という申告が電波サーベイ担当者から来ました。
電波サーベイの結果を見ると、今回新設したAPの付近のマップが灰色のままです。つまり、電波が吹けていません。なんだろう、と無線コントローラの親玉であるMM側を確認すると、確かに当該のAPのステータスは「Up」となり上がっていますが、「r」というフラグが付いている状態ではないですか。
このフラグの意味するところは何か。凡例を見ると「Power Restricted」、つまりという「電力制限」がかかっている状況を示すフラグになっています(OS8.6の場合)。APの電力状況に問題があり、電波が吹けない状況になっているようなのです。
電波を吹いていないAPの現在の状況としては、前述のループの問題もあり、老版側スイッチのポートは安全のためshutdownしたままです。しかし、少なくとも片方のラインから電源が共有できていれば、APが動作する電力としては過不足がなく、電波は吹けるはずなのです。
過不足・・・？と考えたところで、またまた:thinking-face:になりました。
サクラタウンで使用しているスイッチは、ポートをshutdownしていてもPoE給電を明示的に停止しない限り、給電をし続ける挙動をします。AP(PD)はスイッチ(PSE)に対してLLDPを用いた電力のネゴシエーションを行うため、今回のように電力を受け取っているがLLDPが疎通できない場合においては、自律的に「Power Restricted」として電力制限に陥ることで電波を吹かなくなるのです。
stw05nt-fsw01# show power-over-ethernet brief
Status and Configuration Information
Member 1 Power
Available: 1440 W Used: 114 W Remaining: 1326 WPoE Pwr Pwr Pre-std Alloc Alloc PSE Pwr PD Pwr PoE Port PLC PLC
Port Enab Priority Detect Cfg Actual Rsrvd Draw Status Cls Type
------ ---- -------- ------- ----- ------ ------- ------- ------------ --- ----
1/1 Yes low off usage lldp 4.3 W 4.2 W Delivering 5 3
2/1 Yes low off usage usage 6.3 W 6.0 W Delivering^ 5 3^ - Power demoted ports
Refer to command's help option for field definitions
確かにスイッチ側を確認してみると、「Alloc Actual」が「usage」になっており、LLDPではなく実測になっている事、「^」マークが付きうまく給電が出来ていない事が確認できます。
もしも片方のリンクをshutdownするのであれば、PoEも同じく停止してやらないと正常に動作しなくなることがわかりました。この後、shutdownしているポートのPoEも停止することにより無事電波を吹き始め、電波サーベイをする同僚にごめんアイスを奢る！と謝って、もう一度テクテクテクテクしてもらうことで、正確な電波状況を再測定することができました。
教訓：設定変更をしたら、MM側も確認して変なフラグが立っていないか確認すること。IEEE802.3atの動作を理解し、論理的に考えるようにする。可能であれば電波の息吹を感じる。
おわりに
いかがでしたでしょうか？楽しんでいただけたでしょうか。ここまで書いて思ったのですが、インフラ担当者の読者の皆さんには、ヒヤッとする話というよりも、ゾッとする話が多かったかもしれません。DX化が進み、ITインフラの重要性が増すほどに「ゾゾゾッ」と寒気が強くなっていくと思います。
こういったヒヤリハットを「公式の」ブログに書くことは、あまり一般的ではないかもしれませんが、機械にはバグがあるものです。そういった点については、生々しくユーザコミュニティで積極的に情報共有をし、うまく付き合っていければいいのではないかと思っていますので、今後もどんどん書いていきたいと思っています。
また、「お前ヒヤリハットを会社のブログに書いて反省しろ！」と上司に言われたわけでもありません。ヒヤリハットが多いということは、それだけ仕事をこなしているということだと考えています。もちろんお客様に影響を及ぼさないことは大前提ですが、ヒヤリハットを隠すのではなく文書化し、広く共有することで技術コミュニティに貢献できるのではないかと感じています。
最後に少しポエティックになってしまいましたが、ここまで読んで頂いてありがとうございました。それではまた！
- はじめに
- ところざわサクラタウンの無線ネットワーク
- ヒヤっとした話その１：クラスタ構成のMCが交互に死亡する話
- ヒヤっとした話その２：無線アクセスポイントを追加したかっただけなのに！
- ヒヤっとした話その３：給電不良！？
- おわりに
