CONBU

去年のYAPC::Asia Tokyo2014 に引き続きまして 、明日より三日間 YAPC::Asia Tokyo 2015 が開催されます。なんと東京ビッグサイトでの開催です!
 YAPC::Asia Tokyo 2015 の会場で無線LANを提供する CONBU さんのホットステージの模様を一部お伝えします。ブロードバンドタワーさんのご好意により、会議室をお借りできました。

DMM.com ラボ は YAPC::Asia Tokyo 2015 へ協賛しています。
DMM.com ラボはカンファレンスネットワークを構築するチーム CONBU さんを応援しています。

でも今年は都合でDMMかき氷はありません。ごめんなさい!

小ネタ, 雑談

おはようございます。ライトノベル好きの新人ツチノコです。

DMM関連で2件お知らせがあります。

DMM.com Labo 開発者ブログが始まりました。
大手町にいるツチノコブログともどもご愛読のほどお願いいたします。m(_ _)m

DMMひきこもりが終わりました。
体験レポートはこちらです。ダイエット中の新人ツチノコとしては体脂肪率が気になります・・・(><)

なお、無料ではありませんが半額キャンペーンを実施していますので、暑い日にはぜひご利用ください。m(_ _)m

wifi, ネットワーク, 運用管理

調査しに行く

前回の記事: つながらない無線LAN!?(1/3)導入編

無線LANが繋がらなくなっている状態のオフィスに赴き、調査します。

事前のヒアリングでは 「快適に繋がるときと調子が悪いときがあり、混み合う時間帯で特に繋がりにくい」 とのことでしたので、電波が届きにくい箇所があるというより混雑しているのではないかと予想しました。

席数に対してアクセスポイントが少なすぎると思われる地点もあり、収容能力を超えている可能性も考えました。このようなケースでは、利用者が多い時間帯を狙って電波の状況を測定する必要があります。

ツール

Metageek WiSpy

電波を可視化する、周波数帯のなかで電波がどんな強度、密度、タイミングで存在するかを見るツールです(スペクトラム アナライザ)。同じ帯域(2.4GHz, 5GHz)に出ている電波なら無線LANに限らず、電子レンジや Bluetooth, ZigBee, 気象レーダーなどの電波も表示できます。特に 2.4GHz帯(ISMバンド)では、無線LANから存在が見えない種類の電波利用がとてもたくさんあり、互いに衝突するものも多いため、存在を可視化することは大切です。

なんでも受信できますが、その内容をデコードすることはできないため、何の電波か見分けるには慣れが必要かもしれません(最終的にわからないことも多い)。

また、広い周波数帯をスピーディに把握でき、干渉源の把握以外にも役立ちます。inSSIDerのような無線LANのビーコンをスペクトラムに重ねて表示できます。

FlukeNetworks AirMagnet WiFi Analyzer

非常に多機能な無線LANアナライザです。無線LANを完全にデコードでき、具体的な問題の特定に役立ちます。WiSpy が電波の存在を見るツールだとすれば、こちらは電波の中身を解釈できるツールです。

無線LANのトラブルシューティングでは、電波の存在だけを見ればわかる低レイヤな問題と、実際に無線LANの中を見てみないとわからない問題があります。AirMagnet は中身を解析し、膨大な情報を非常に見やすい形に整理して表示してくれます。無線LAN以外の電波を見ることはできません。スペクトラムアナライザよりレイヤが高いツールといえます。

inSSIDer, WiFi Analyzer, WiFi Explorer

もっとも身近な無線LAN調査ツールかと思います。AirMagnet, WiSpy は専用のハードウェアを必要とし、必ずしも導入しやすい価格でないかもしれないのに対し、inSSIDer, WiFi Analyzer, WiFi Explorer は PC やスマホの WiFi デバイスを利用した、無料ないし安価なツールです。

これらのツールで可能なのは、無線LANアクセスポイントの存在の検知とその電波強度を調べることだけです。高密度無線LAN環境で起こりがちな、電波が強いのに速度が遅かったり不安定である状態や、実際にアクセスポイントがどれくらい利用されているかなどを調べたいときにはあまり役立ちません。でも、とても軽くて手軽なので、前述のツールと併用することはよくあります。

他に無料で実現可能な手法として、モニタモードで動作できる無線LANデバイスを Wireshark などで見る方法もあります。その気になれば AirMagnet の一部機能のように無線LANの中身を調べることができますが、深い知識と根気が必要な方法かと思います…。 (トラブルシューティングではちょっとやりたくないですが) 取得したい情報があらかじめ決まっているのであれば、たとえば Python のモジュール Scapy には Dot11 Layer が用意されていますので、ツールを作成して解析することも可能です。


測定結果をいくつかご紹介します。

地点A

high_utilization_slow_datarate_s
遅いデータレートと高すぎるチャネル使用率

遅いデータレート(1Mbps)でチャネルの約74%が使用済になっています。スループットが1Mbpsも出ていません。この状態では遅いながらもかろうじて通信はできていますが、これ以上のトラフィックを流そうとすると、無線LANは切れてしまうと思われます。

このときは、複数のポータブル WiFi ルータが存在したようです。実際にデータがたくさん流れておらず、多くがビーコンとプローブ レスポンスでした。ビーコンとは、アクセスポイントが SSID などを含めた基本的機能を送信し続ける制御トラフィックで、端末はこれを受信するとアクセスポイントの一覧に SSID が表示されます。
データをたくさん流していなくとも、アクセスポイントが大量に存在することによって制御トラフィックでチャネルが使い切られてしまい、ろくに通信ができないという本末転倒の状況にあります。

5GHz_HighUtilization
高すぎるチャネル使用率, W53, W56利用なし

こちらは5GHz帯です。40ch, 48ch のチャネル使用率が高いことがうかがえます。また、52ch以上のチャネルが利用されていません。アクセスポイントは5台以上見えているので、DFSか、と思ったのですが、52ch以上がまったく利用されていないのは不思議です。

※DFS: 52ch以上(W53バンド以上)の無線LANでは、同じ周波数帯を共用する気象レーダ等を検出し、検出された場合はそのチャネルでの電波の送信を停止することが義務づけられています。アクセスポイントは、そのチャネルの利用をやめ、他のチャネルをランダムに選択します。レーダの検出により、利用可能なチャネルが減ることになります。レーダの検出は、窓際や見晴らしのよい場所に設置されたアクセスポイントで起こりやすく、建物の奥まったところでは比較的起こりません。

地点B

2.4G_overlap_s
ノイズが多い2.4GHz帯

有線LANで接続されたPCが多いエリアです。アクセスポイントへの接続端末数は多いのですが、それほどトラフィックは多くありません。しかし、上下フロアおよび外からの電波、野良アクセスポイントによって利用チャネルがオーバーラップしてしまい、干渉しあっています。

問題

  • チャネル利用率が高すぎる
  • 遅いデータレートでチャネルが埋まっている可能性が高い
  • アクセスポイントに対して端末数が多く、収容能力を超えている箇所がある
  • 電波が弱いエリアはほとんどない

測定により、以上のような状況が把握できました。何ができるのか考えてみたいと思います。

無線LANの電波を伝える空間は共有されているため、理想的な状態にできるとは限りません。外や上下フロアなどの自社の管理下にない装置から飛んでくる電波、持ち込まれるポータブル WiFi ルータやテザリングなど。免許不要の無線は、国が電波の交通整理をしないから混信を許容せよ、ということでもあります。できることからやっていこうと思います。

続く

linux, 負荷分散装置, 運用管理

社内では少ないZabbix派のshinonomeです。お久しぶりでございます。

Zabbix派なんですが、実は今までローレベルディスカバリ(以下LLD)を自分で書いたことがなかったので、書いてみることにしました。

LLDとは
Zabbix 2.0から追加された機能で、マシンの構成により変更されることが多いものに対してアイテムやグラフ、トリガーを自動的に構成してくれる機能です。
デフォルトでFilesystemやNIC、SNMPに対して有効化できます。v2.4からはCPUにも対応しました。

そして、今回書いた対象が

LVS – Linux Virtual Server

です。

ツチノコでは一部サーバにLVSを利用してロードバランシングを行っているところがあります。
そのサーバの状況を監視するべく、LLDでやってみようという魂胆です。
LLDにしたのは、LVS配下にあるサーバが頻繁に変更されるためです。

カスタムLLDは、zabbix_agentdに対してUserParameterを設定することで作成します。
たいていはわかりやすいように XXXXXXXX.discovery というキー名を利用するようです。

Zabbixの値取得の基本は、Zabbix ServerがZabbix Agentに対しキー名を叩いた時に、Zabbix AgentはUserParameterのスクリプトを実行、
スクリプトが返した値を、そのキーの値としてZabbix Serverへ返す様になっています。
カスタムLLDを作成するときは、その返り値をテンプレートに渡すJSONとすることで実現できます。
https://www.zabbix.com/documentation/2.2/jp/manual/discovery/low_level_discovery#カスタムlldルールの作成

今回はipvsadm.discoveryをキーとし、VIP、TCP/UDP、Real IPのマクロ化を行いました。
そして、https://www.zabbix.com/forum/showthread.php?t=12086 こちらのPythonスクリプトを叩ける形のテンプレートを用意しました。

LVSをバックエンドとして使っているLdirectordやKeepalivedでも使えますので、ぜひご利用ください。
また、プルリク等もお待ちしております!

コードはこちら:https://github.com/shinonome/zabbix_ipvsadm

PAGE TOP