ICTSC, イベント, コラム, 運用管理

こんにちは、whywaitaです。
「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト にて運営委員を務めさせて頂きました。

「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト(以下、トラコン)では全部で13問の問題が出題され、その全てが学生の手によって作問されました!
今回はトラコン初の試みとして、問題文の公開、及び、作問者自身による問題解説を行いたいと思います!

問題文(出題したそのまま)を公開します!

Redmineの意図しない挙動の調査について (Survey of behavior not intended for Redmine)

問題文(Problem statement)

最近入社した社員が、Redmineでエラーを起こしたらしい。
A junior engineer caused the error on Redmine.

「若手で1番優秀な僕がエラーを出すことはありえないですよ!バグなんて絶対作りません!」
“There is no possible way that there is something wrong with my configuration. I absolutley do not create bugs!”

Redmineに発生した挙動を判断し、新入社員が再び操作しても壊れないようにしてください。
Determine the error occurred on Redmine.

症状(Symptom)

  • 新人社員がRedmineを操作した所、意図していない挙動が発生している。(After the junior engineer changed the configuration for Redmine/Server, it started to malfunction.)
  • 新人社員が操作した後は誰も操作を行っていない。(No one has touched the server after the junior engineer.)

チェックポイント(Checkpoint)

新入社員が再び同じ操作しても壊れないようにしてください。
Even if the junior employee carries out the same steps he has done before, Redmine should not show any error.

問題解説

この問題を解くのに必要なのが、「ログを読む力」と「ミドルウェアへの理解」でした。
トラコンは初期からネットワーク系の問題が非常に多い傾向にあり、多くのミドルウェアに対する問題が問われる事が少なかったため、本問題ではそれに反してRuby on Railsで開発されているRedmineをベースとした問題を取り扱いました。

解法

最初に運営側が想定していた解法についてお伝えしたいと思います。
※一部ログなどが出ますが、記事作成用に問題を再現した環境を作成しており、問題環境そのままでないことをご了承ください。

ログのバックアップを取る

これは通常のオペレーションではあまり取り扱われないことではないかと思うのですが、今回はどのタイミングで新入社員が不正な挙動を行ったかのヒントが少ないです。
通常であれば時間ベースで追いかける事も出来ると想うのですが、コンテストである性質上問題文中に「新人社員が操作した後は誰も操作を行っていない。」という文面を盛り込みました。この文面から、各種ミドルウェアのログのバックアップ(障害が起きているであろう箇所)を取ると問題が解きやすかったかもしれません。

エラーログを探す

ここで「ログを読む力」が生きてきます。
ApacheやNginxなどのwebサーバのアクセスログが、1アクセス=1行に対して、Redmine(というよりRails)はそれ以上のログを生み出します。
このような時に、「どのようなログであるか」「どのように抽出すれば上手くエラー箇所だけを抜き出すことができるのか」を即座に判断する必要があるのです。
ここで、「すぐにお手製のワンライナーを書けるのか?」という疑問が出てきます。これは、普段からシェルで色々な文章を扱っている人で無ければ難しいかもしれません。

ということで、抽出したログが以下になります。
自分の場合はHTTPステータスコードでエラーが吐いている事から、grepコマンドの検索を使って検索しました。

原因を見つける

このログを見つければ原因自体は分かりそうです。
Redmineが利用しているデータベース(今回はMySQLでした)に問題がありそうですね。
ついでに”U+1F60A”という見慣れない単語が見えます。これは何なのでしょう?

検索してみると分かりますが、これは「絵文字」です。皆さんもslackやHipChatなどで利用しているかもしれませんね。
通常のUTF-8で設定されているMySQLデータベースに絵文字を入れようとして、エラーを出力しているようです。
ここを解決出来れば、何とかなりそうですね!

対処する

原因が判明したのであれば、それを解決するだけですね。
MySQLの設定ファイルはmy.cnfです。今回の環境であれば/etc/mysql/my.cnfにあるので、ここを編集します。
[mysqld]セクションに以下の文字列を追加すると良いでしょう。

設定ファイルを書き換えたら、MySQLの再起動を行います。これでMySQLがutf8mb4に変更されました!

対処する(その2)

回答を見ていると、上記の対応をして回答としているチームが散見しました。
原因を発見出来ていて素晴らしいのですが、ここで問題文のチェックポイントを見返してみましょう。
「新入社員が再び同じ操作しても壊れないようにしてください。」とありますね。
実はこのままでは「再び同じ操作をした時」同じエラーが出ないとも限りません。それは何故か?既存のデータベースがUTF-8のままだからです

ここが残念ながら出来てなかったチームが多かったです。(勿論この処理を行ったチームをいらっしゃいました!)
既存のデータベースをしっかり変換して、ようやく完答となります。お疲れ様でした。

まとめ

通称「Redmine絵文字問題」、如何だったでしょうか?
Redmineが利用している言語であるRubyはマルチバイト文字にデフォルトで対応しているのですが、MySQLを初めとするバックエンド類はまだまだデフォルト対応とは言えない物が多いように思えます。
最近は海外でも”emoji”の愛称で呼ばれるようになった日本発祥の文化「絵文字」を取り扱う事も多くなるので、動向・扱い方はしっかり捉えていきましょう!

余談

「Redmine 絵文字」で検索すると、かなり上の方にこのブログ記事が出てきます。

Redmine構築後のDBの文字コードをutf8mb4に変換して絵文字に対応する – Dig that groovy!

このブログを読むと完答までの流れが書いてあるのですが、実はこのブログの筆者はトラコンの運営委員だったのです!
参加者の方の中にはこのブログを読んだのかな?と思われる回答もありましたが、本人は複雑な表情をしていました(笑)

ICTSC, イベント, インフォメーション, ネットワーク, 運用管理

こんにちは、whywaitaです。

「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト にて運営委員を務めさせて頂きました!

「DMM.com Labo ツチノコ杯」第4回ICTトラブルシューティングコンテスト(以下、トラコン)では様々な機材や技術を用いた上での運営を行いました。

今回はその中で、サーバ周りの技術をご紹介したいと思います!

ansible

今回は物理ホストサーバの上に、vmware社のvSphereを構築し、その上で仮想ホストを管理していました。問題用サーバ・運営用サーバ・DMZ用サーバ・その他様々な用途のサーバが立っており、最終的には350台弱のサーバが起動していました。このホスト群を上手く操作するのはとても大変です。問題を出す直前で何らかの仕様変更が発生したり、事前にやっておくべきであった操作を完全に忘れたまま放置していた事もありました。

この問題を対処するために我々が採用していたのが、ansibleです。

今回ansibleでは、以下のような作業を行いました。(あくまで一例です!)

  • チーム毎にログインパスワードの変更
  • ntpdやiptablesなどの必要なミドルウェアのインストール
  • 参照するリポジトリを日本のミラーサーバに変更
  • 参加者が作業するサーバに対して、運営の作業ログ削除
  • DHCPにて割り振られていたIPアドレスを利用して、そのままstaticなconfigの設置

特に、「問題用ホストを問題として出せるように調整する」作業に大きな効果を発揮しました。

問題によっては1チームに3台のホストを提供していることもあり、今回参加して下さったチーム数が15チームのため、全部で45台分その問題用のホストがあることになります。このホスト群に対して同じ動作をする必要があるのですが、その際にサッと書いたansibleのplaybookを書く事で、全台に対して同じ動作をすることが保証された状態で設定の変更を反映することができました。

ホストの大量展開

また、多くのホストを操作する事が出来ても、そもそも構成を管理するホストが無ければ意味がありません。通常であれば長い時間をかけて少しずつホストが徐々に増えていくのかも知れませんが、今回のトラコンではそのような事は出来ず、一度に数十台のホストを用意する必要がありました。

その解決策として、vsphere_guestというモジュールを用いて、大量展開を行いました。これを用いる事で、特定のテンプレートを基に複数台のホストを自動で用意する機構も作成しました。

この機構により、問題用のホストを作成した後にそのホストをテンプレート化、チーム数分展開を行うことで、各チームごとに差異が発生しないまま問題を出すことが出来ました!

事前準備期間のansible

当日は複数ホストに対する操作が多かったのですが、当日までの期間には構成管理ツールとしての使い方を行っていました。

GitHub上でのPullRequest(通称PR)ベースでの開発を行うことで、一定の品質を保ったplaybookの開発を行うことが出来ました。

PRの様子
また、GitHubへのPRをトリガーとして、jenkinsを用いた自動テストを行い、その結果をslackに通知していました。これにより、テストが失敗した時のみjenkinsを確認すれば良いので大変便利でした。近年はChatOpsと呼ばれるチャット基盤とオペレーションを繋げる試みが話題ですが、その便利さには本当に驚かされます。

jenkinsの結果がslackに通知されている様子1
jenkinsの結果がslackに通知されている様子2
これらの機構を使う事により、安定かつ暖かみの無いplaybookの制作を進めることが出来ました!

playbookのオープンソース化!

最後に、トラコンの過程で出来たplaybookがどのようなものになったのか、気になりませんか?

なんと…作成したplaybookが、先日オープンソースとしてGitHub上にて公開されています!

ictsc/ictsc-playbooks

構築期間中、とある社会人の方に競技後公開する話をした所、「太っ腹すぎない?」と心配されてしまいましたが問題ありません!再利用性があるように(急いでいて出来ていない部分もありますが)制作したつもりですので、ライセンスの下ご自由にご利用ください!

まとめ

学生の身分で約350台のホストを一斉に管理することは中々無いので、今回は貴重な経験を積む事が出来ました!

これからもトラコンは続きます!大量のホスト管理に興味の出た方は、是非運営参加もご検討下さい!

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

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

あらまし

x月x日、某社オフィスで
「社内無線LANが使い物にならず非常に困っている」
という相談を受けました。

特に繋がらない場所は会議室であり、iPadでFaceTimeを使ったテレビ会議をしようとすると、映像がブラックアウトしたり音声がブチブチ切れるという悲惨な状況だというのです。さらに会議室以外でも通常なら数分終了する構成管理ツールが、なんと70分も掛かるなどの事例が報告され、社員は無線LANに対して大きな不満を抱えているとのこと。つまり……

今すぐ解決してほしい!

ということです。今すぐに解決できるわかりませんが、まず調査してみて、対処できることからトライしてみようと思います。

無線LANが不安定になる原因

  1. 電波が弱い
  2. 混雑している

オフィス無線LANが不安定になる原因の多くは混雑です。同時に多数の端末が通信できているように見えますが、有限のチャネルを時間で分割して利用しています。

ひとつのチャネルを5台の端末で共有
ひとつのチャネルを5台の端末で共有

無線LANの特徴として、端末ごとに通信状況が異なることがあげられます。これは、伝送媒体の品質が保障できる有線と違い、電波の状況が悪くなっても接続を維持できるように、端末ごとにデータレート(bps)をつねに変化させています。電波状況は刻一刻と変化していますので、それに追随してデータレートも常に自動調整されています。

OS X では Option + 無線LANアイコンクリックで 現在のデータレートなどを確認できます。電波の状況があまり良好でないときは、クリックするたびに数字が変化しているのを見ることができるでしょう。

そのうち一台(オレンジ色)の端末が遠くに行ってしまい、電波状況が悪化したため、データレートが 2Mbps まで低下したとします。すべての端末に 100KB を転送すると

全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)
全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)

なんということでしょう! 遅いデータレートの端末が一台いるだけでかなりの時間を消費し、チャネルを共有している全端末のパフォーマンスが大幅に劣化してしまいました。

この遅いデータレートの存在があると、無線LANに収容できる端末数は大幅に低下します。無線LANでは制御も同一チャネルの半二重で行うため、チャネルの空き時間が少なくなると制御も困難になり、全体が一気に不安定になってしまいます。

この場合、ボトルネックになっているのは伝送媒体である空間そのものですので、同じチャネル×空間にアクセスポイントを増設しても改善されません。

高密度無線LAN環境において遅いデータレートは悪!

オフィスなどの高密度無線LAN環境では、遅いデータレートの端末が発生しないよう考慮します。遅いデータレートでの接続を禁止する設定ができるアクセスポイント製品もあります。

データレート制限機能の例
データレート制限機能の例

データレートが速いほど、より高品質な電波状況が要求されます。遅いデータレートでの接続を禁止してしまうと、電波状況が少しでも悪化すると切れてしまうことになります。端末が移動したり、何らかの原因で電波状況が悪くなったとしたら、より近くのアクセスポイントへローミングを早めに行わせます。

※ローミング 複数のアクセスポイントが同じSSIDで設置されている場合、端末は最も良い電波状況のアクセスポイントを自動的に選んで接続し、電波状況が変化すれば別のアクセスポイントへ接続先を変更する。

続く:: つながらない無線LAN!?(2/3) 調査編


初めまして、申し遅れましたが新人ツチノコのkumaです。よろしくおねがいいたします。

PAGE TOP