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

11/17〜19に行われた Internet Week 2015 にて「失敗から学ぶWi-Fi構築」というテーマで講演させていただきました。Wi-Fi で陥りがちなアンチパターンと、それがなぜ失敗してしまうのか、どうしたら改善できるのかというテーマのプログラムでした。

無線LANに限らず、トラブルシューティングでは「なんか変だぞ?」という直感が、理屈よりも先に働くことがあるかと思います。これは経験や、どういう仕組みで動いているかを知ることによって、なんとなく変だなという直感として意識に上がってくるようになるのではないかと思っています。

電波は見えないし聞こえないけど、それがどういったものかをなんとなく知ることで、無線独特の特性、電波の飛び方や干渉の起こり方をなんとなくでも想像できるようになればと思い、このプログラムでお話しました。資料はのちほど Internet Week 2015 のページに掲載される予定です。

オフィス街と郊外を測定しながら走ってみた動画

プログラムの最後に紹介しました車載動画です。都内繁華街で電波が非常に混み合っているエリアから、電波がクリーンなお台場まで、簡易測定器を積んだ車で移動しながら撮影してみました。

測定器には metageek Wi-Spy を利用しました。この測定器は つながらない無線LAN!?(2/3) 調査編 で紹介したものです。

waterfall_wifi
この画面(Chanalyzer4)は、左右が周波数 (無線LANのチャネル表示)です。上下に分かれていますが、上は現在の電波強度、下はその履歴です(記録したものがだんだん下に動いていくのでウォーターフォールグラフなどとも呼びます)。

このケースでは 1, 6, 11 ch でいわゆる Wi-Fi が利用されているように見えます。それぞれのチャネルの真ん中が凹んでいますが、これが IEEE802.11a/g の特徴です。

Wi-Fi で利用されている変調方式 OFDM は、ひとつの通信を複数のサブキャリアと呼ばれる電波に分割して伝送します。802.11g (20MHz幅) であれば52本のサブキャリアに分割し、ひとつの通信となっています。この真ん中の部分は実装上の都合で通信に利用するのが難しいため、使われていません。このため、中心に凹みが観察されます。

秋葉原から出発し、お台場の暁埠頭まで移動しました。これは2.4GHz帯を観測しています。

  • 無線LANではないと思われる電波がかなり多い(意外)
  • 無線LANだけを拾うアプリ(inSSIDer, WiFi Analyzer等のアプリ)だけでは状況を正しく判断できそうにない
  • 繁華街ではほんの少し移動しただけで状況が大きく変わり、この辺はこういう状況である、等といったことは言いにくい

waterfall2

移動した約50分間のウォーターフォールを一枚に圧縮してみました。繁華街を離れ、海に近づくに従って電波の密度が下がっていき、バンド全体がクリーンになっていくのがわかると思います。

とはいえ、海の倉庫街(特に税関のある辺り)から広域にわたって何だかわからない電波が出ていたりもしましたので、やはり実際に測定してみないとわからない、かつ、この瞬間ではこういう電波状況だったが今後どうなるかもわかりません。突然トラブったりすることもあり得ます。

今度、電波がクリーンそうな熊野に行ってきたいと思います(フレッツが来ていない限界集落)。測定したら面白そうな場所があったらぜひ教えてください! 

iDC, ネットワーク

こんにちわ。また大分があいてしまったぜという感じの酔っ払い系ツチノコです。

 

今回は JANOG US Regional Meeting というところでお話をしてきました。JANOG は JApan Network Operators’ Group っていうくらいで基本的に日本でやってるんですが、今回は NTT America さんのオフィスをお借りして、San Jose です。人数も会議室でやってたくらいでいつもの JANOG と違って目線が同じでプレゼンの最中にも質問が飛び交って議論がいつも以上に盛り上がる感じ。こういうのもいいですねー。

私がしゃべった資料はこちら。

 

コンテンツ屋として考える現在のデータセンタインフラ、ネットワークとこれからはこんな感じにしたいなー、っていうお話でした。Chaos Monkey 動かしても大丈夫なアプリ+インフラってやりたいとおもってもなかなか越えなくちゃいけないハードルは高いんですけどね。でもやりたい。

 

私の発表以外の当日のプログラムと資料はこちらから辿れます。

https://www.janog.gr.jp/meeting/regional-us-1/

 

尚、当日の動画は youtube で公開されています。動画は2015年11月末迄の公開だそうなので、まだ見てない方々はお早めに。最初の住本さんの海底ケーブル話は特にオススメ。資料無しストリーミング有りですし。

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トラブルシューティングコンテスト(以下、トラコン)では様々な機材や技術を用いた上での運営を行いました。

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

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台のホストを一斉に管理することは中々無いので、今回は貴重な経験を積む事が出来ました!

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

PAGE TOP