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

こんにちわ。ツチノコブログ2回目のibuchoです。

このブログのエントリーでも幾つか書かれているのでご存知かもしれませんが、先日の8月29日、30日に開催されたDMM.com Labo ツチノコ杯 第4回ICTトラブルシューティングコンテスト(略してトラコン4)の模様をドキュメンタリータッチでご紹介します。(若干の潤色はありますが、ほぼ事実に基づいております。)

2015年8月29日(土曜日)

08:00 : 朝8時、トラコン4本選会場である工学院大学5Fに設置されたNOCルームに運営学生全員が集合した。2週間前から毎晩夜遅くまでコンテストの準備に追われていた運営の学生達だが、昨夜だけは18:00に作業を終え、今日に向けて十分な休息を取り万全の体調で参加選手を迎える事にしていた。始めに運営リーダの森から本日の予定、担当、シフトの確認、残作業、問題の準備等が伝えられ、各自それぞれの役割に従って会場やサーバ、プログラム、採点表の確認など、おのおのあらかじめ割り当てられている作業へと散っていった。

DSC07399 DSC07397

09:00 : 会場である5Fフロアはさながら嵐の前の静けさであり、案内看板、受付の準備も完了し、あとは出場選手を迎え入れるだけである。

DSC07406 DSC07410

運営学生はリラックスしている風を装っているが、心なしか表情に緊張の色が見え隠れしている。

DSC07544 DSC07538

09:30 : 受付開始と同時に参加者がぞくぞくと入場してくる。各参加者は受付で学校名、チーム名を申告し、運営学生に案内されコンテスト会場へと進む。そして各チーム毎のテーブル上におかれたゼッケンを手に取りコンテストに望む準備をする。チームの仲間と会話し作戦を確認する者、テーブル上に設置されている機器をチェックする者、ブラウザを開き何かを調べ始めるもの、ネットワーク技術の教科書を開き復習をする者など、さまざまである。そしてコンテスト開始10分前には全チームが集合し、ザワザワしながらコンテストの開始を待っていた。

DSC07424 DSC07448

10:00 : 会場正面の演題に運営チームリーダーの森が立ち、コンテストの開始を高らかに宣言した。

DSC07453 DSC07454

コンテストのルール、注意事項などが告知され、続いていよいよ初日午前の問題が出題される。出題は各チームにあらかじめ提供されているredmine上にチケットという形で出題されるため、会場内で問題がアナウンスされるということは無い。各チームは一斉に端末でredmineを開き、チケットとして発行された問題を確認しはじめる。初日午前の問題は以下の3問であった。

Q1. Webサーバを構築してくださいな。

Q2. スイッチ間を冗長化してほしい。

Q3. VPNの構築の件について。

問題文の内容は漠然としている。たとえばQ1の問題文は以下のようになっている。

新入社員「それなんですか?」
上司「これは俺が昔遊んでたサーバさ。CentOSが大好きでね。ちょうどいい、勉強用に使いなさい。まずはWebサーバを構築してみようか」
新入社員「やったーーー!がんばります!」

報告事項 :実際に行ったWebサーバの構築手順

これのどこがトラブルシューティングなのか?と誰もが思うだろう。過去にトラコンに参加したチームにとっては見慣れた問題形式だが、初出場のチームにとっては問題の意図が全くわからず、何を要求されているのか、何と答えると正解なのか混乱したはずだ。通常学校で出されるテスト、資格試験などの問題には必ず回答があり、問題文からどのような知識、解法手順を要求しているかが予測できる場合が多い。学生は問題を読み、授業や講義で学んだ知識を元に問題が要求している回答を探すといった対応をする。つまりクイズやパズルを解く事と同等なのだ。

DSC07471 DSC07467

しかし、実際の現場において、回答のある問題などあるはずがない。トラコンで出題される問題は正に現実に起こっているトラブルや上司や顧客から依頼、指示された作業を実施する様をモデルとしている。この問題形式は運営の学生が独自に発案し作成したものであるが、参加選手にとっては答の無い問題という実際の現場で直面する状況を経験する非常に良い機会であろう。

11:59 : 午前の問題の回答制限時間が近づく。その時、コンテストの成り行きをNOCで見守りながら各チームの回答の採点を行っている学生達がざわついた。15チーム中、1チームだけ3問全部満点の回答を叩き出したチームがいる。

日本工学院八王子専門校チーム「WCDI」である。

WCDI-1 WCDI-2

通常初日午前というのはコンテストの勝手がわからず、問題に取り組むというよりは機器や回答方法などの環境を把握するだけで精一杯であり中々正解を出す事は難しい。実際、他のチームはノーポイントか、せいぜい正解が1問だけだったが、チームWCDIは全問完璧な回答を出して初日午前をダントツトップで駆け抜け、このままポール・トゥ・ウイン、先行逃げ切りをぶちかます勢い。ロレンソか。

13:00 : 昼休みが終了し、各チームが再び所定のテーブルに着座した所で初日午後の問題が出題された。

Q4. ときどきサーバにつながりません!

Q5. 残りのスイッチの設定は任せた!

Q6. Redmineの意図しない挙動の調査について

Q7. 新しい営業所

これまた問題タイトルからは内容が全くわからないが、サーバの脆弱性が攻撃されていたり、あらかじめコンフィグレーションされている設定が間違っていたりといったトラップが仕込まれており、参加選手はサーバ、機器類のログや設定を調査しながら原因を突き止め、トラップを修正もしくは回避しつつ依頼された内容を解決していかなければならない。

午前問題をトップでクリアしたチームWCDIはまたもや4問中2問で満点を叩きだした。しかし、ここで急速にWCDIに迫るチームが出現する。

関西大学大学院チーム「コバゼミ」だ。

コバゼミ1 コバゼミ2

チームコバゼミは前回(トラコン3)から参戦して初出場で優勝を勝ち取った、いわばディフェンディングチャンピオンチームである。前回は学部4年生の関西大学としての出場だったが、チームメンバ中の数名が大学院へ進学し、今大会ではゼミの新たなメンバーを加え大学院チームとして参戦した。チームコバゼミはチームWCDIと同じく4問中2問で満点を叩き出した。しかもWCDIがノーポイントだった問題でも得点を獲得し、いきなりWCDIに肉薄してきたのだ。

17:00 : 初日午後のコンテストが終了。結果的にトップはチームWCDIが死守し、ついでチームコバゼミが5ポイント差で2位に着けていた。問題の得点は5ポイントと10ポイントの2種類が用意されているため、1問の差で同点になるか、もしくは順位が逆転する可能性もある。初日の結果により2日目には俄然これら上位2チームによるデットヒートが展開されるだろうと、運営の誰もが予測しつつ、初日夜に予定されている懇親会へとなだれ込んだ。(出張握り寿司付き)

DSC07683 DSC07714

しかし、初日を終了した時点でトップ2チームのWCDIとコバゼミの背後から静かに忍び寄るチームがあった事を関係者、そして運営さえ誰も気づいていなかったのである。

(後編へ続く)

DSC07774 DSC_8296

イベント, コラム, 勉強会, 雑談

NTTPCコミュニケーションズさんの社内勉強会にDMMかき氷を送ったらLightning Talkの機会をいただきました。

NTTPCコミュニケーションズは日本の最古参のISPの1つで「高品質」なサービスを提供しているイメージがあります。
高品質を維持するには時間とコストがかかるので、なので逆にあえて品質を下げる(コントロールする)ことで、スピードを上げるのもどうでしょう?、という意図で資料作りを始めました。
資料作成に時間をかけると品質が上がってしまうので作成時間は1時間ほど。
そのため、言いたいことを言えてない感じの資料になってしまってますが、これが低品質というものです。
お目汚しになってしまいますが、記念に公開しておきます。

肝心の勉強会は、その場での手作りの食事が出たり、遠方からのゲスト発表があったり、様々なネタの飛びかう、とても雰囲気の良い勉強会でした。
お招きいただきありがとうございました。

iDC, イベント, インフォメーション, インフラ全般, ネットワーク, 製品

7月にJuniper様主催のイベントである「Juniper Cloud Builder Conference 2015」に登壇させていただいた内容を、をASCII.jpに取りあげてもらいました。

成長し続けるDMM.comのネットワーク、その変遷を担当が語る
http://ascii.jp/elem/000/001/047/1047295/
読んでいただけると、DMMの事業スピードに対応するため、Juniperのファブリック技術を用いて頑張って整理拡張をしてきた様子がわかるかと。
Juniper様主催のイベントなので、Juniper機材にフォーカスした内容になっていますが、もちろん他社の機材も使っていますよ。
機会があれば今後もいろいろと発表させていただければと思っています。

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

こんにちは!
学生ツチノコのsaiです!

今回はICTトラブルシューティングコンテスト(以下、トラコン)の一日目で出題されたネットワークの問題、スイッチ間の冗長化についてお話しようと思います。

※問題作成者ではなく大会参加者の記事となります。確実な正答ではございませんので、ご了承くださいませ。

問題のシナリオと条件

<大まかなシナリオ>
人員が増加するのでスイッチをもう一台追加することとなった。
現状、既存のスイッチと新たに導入したスイッチ間をUTPケーブル一本で接続している。
そのためか、追加されたスイッチに接続している端末のネットワークが遅くなったりと不安定である。

<条件>
1.スイッチ間の経路冗長化と通信帯域の拡張をする際、ネゴシエーションはしない設定で行う。
2.ポートはFastEthernet0/1と0/2を使用し、トランクポートとすること。

 

問題を解くに当たっての知識

・STP (スパニングツリープロトコル)

@network Cisco・アライド実機で学ぶ様  http://atnetwork.info/ccna3/stp1.html

・アクセスポートとトランクポート

ネットワークエンジニアとして様 http://www.infraexpert.com/study/vlanz2.html

・イーサチャネル

@network Cisco・アライド実機で学ぶ様  http://atnetwork.info/ccnp5/fec07.html

この問題は以上の知識と、ネットワークにおける基礎的な知識があれば解ける問題でした。

CCNAレベルを理解していれば、調べずともこの問題を解けるのではないでしょうか!

トラコンは前回か前々回まで参加する学校等の関係もありネットワーク問題の割合が多く、その難易度も高いものでした。(参加してませんが、VPNとかVPNとかVPNとか)

しかし色んな学校が参加するにあたって、問題もネットワークによるのではなくバランスの取れたものにしたようです。

 

今回の設定について

設定だけで言うと

1.スイッチA、スイッチBのFa0/2をケーブルで接続
2.ターミナルFa0/1とFa0/2にswitch mode trunkchannel-group 1 mode onを両方のスイッチに入力し適用
3.show etherchannel summayを使用し、イーサチャネルの状態を確認
4.pingを相互でvlan1に飛ばしイーサチャネルの疎通を確認
5.copyコマンドを使用し、スタートアップコンフィグに設定を反映

経路の冗長化、帯域拡張、トランクポートの設定は以上で問題ないと思われます。

 

設定の解説

では、順に解説していきます!(4,5は割愛)

1.スイッチA、スイッチBのFa0/2をケーブルで接続

これによってスイッチA―B間は二本のケーブルで繋がれた状態になっています。
しかし、ブロードキャストストームを防ぐため、STPによって一つのポートがブロッキングポートとなるので (RSTPの場合はオルタネートポートと名称が変わります)
二本繋いだけど、ループになっちゃうから一本だけ日頃使わないようにしといた という状態になります。

「なんだよ、それじゃ意味ないじゃん!!」

・・・と、待った待った。実はそんなことないんですね!
STPはループを回避するにプラスして冗長化もしてくれています。

そもそも 冗長化 とは…

まず例としてスイッチとパソコンの間にケーブルが一本あり、それを介してネットサーフィンをしているとします。
もしも、このケーブルが断線してしまったらどうなるでしょう・・・
当たり前ですが、パソコンはインターネットに接続できなくなりネットサーフィンも出来なくなってしまいます!ohᔪ( ᐪᐤᐪ )ᔭNo!

スイッチのケーブルをもう一本増やしてみましょう。
そうすると、ネットサーフィン中に片方のケーブルが断線したとしても、もう片方のケーブルがアクティブ状態となり接続が保たれるようになります!
これが冗長化!片方動かなくなってももう片方が動く!それが冗長化!
つまり冗長化を使用すると、可用性が向上するわけです!
STP以外にもRSTP、ルーターではVRRP、HSRP等、冗長化するためのプロトコルは色々あります。
設定によってはロードバランシング(負荷分散)も実現できる為、ネットワークを常時止めないという点においてとても重視される項目になります。

 

つまりは、日頃一本ケーブルを使わないだけで、片方が断線なりした場合はもう片方が肩代わりするわけです。便利ですね!
ということで、とりあえずの冗長化はケーブルの接続だけでOKです。

 

2.ターミナルでFa0/1とFa0/2にswitch mode trunkchannel-group 1 mode onを両方のスイッチに入力し適用

前者のコマンドを使用することにより、任意のポートをトランクポートに設定することが可能になります。
これによって複数のVLANの通信をトランクポートを通じ橋渡しができます!

後者のコマンドはイーサチャネルというものの設定をしています。
これは「複数の物理ポート」「一つの論理ポート」に束ねる技術です!
束ねたインタフェースをポートチャネルといい、ポートチャネルで接続する事で通信帯域を増やす事ができます!
STPでは片方のケーブルは日頃使わない状態になっていましたが、この設定を施すとケーブル二本の通信帯域を有効的に使用できるというわけです!
因みに、mode onの部分はネゴシエーションしない場合の設定となっておりますが、両方のポートでmode onの設定を入れておく必要があります。

 

この問題の設定自体は以上で終了です。

ですが、実際に反映されているか、自分の思ったように行われているかの確認のために以下を行っています。

3.show etherchannel summayを使用し、イーサチャネルの状態を確認

このコマンドを使用するとポートチャネルとそれに属しているインタフェースが見れるようになっています。

 

 

(´-`).。oO(showコマンド、ほんと便利だ)

 

まとめ

この問題では、「ネットワークが遅くなったりと不安定である」というのがトラブルの症状となっていました。

問題文の中に「冗長化と通信帯域の拡張」と対処すべき項目が記述してあったので、チームによってはスムーズに終わったのではないでしょうか。

また、今回とりあげられている冗長化はネットワークやサービスを止めないために重要であると思います。

必要となる場面は多岐にわたるので、解けなかった!知らなかった!という方は勉強してみてもいいかもですね!

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!

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

PAGE TOP