/

こんにちは!ICTSC8 問題リーダーの中西です。

大変遅くなりましたが、ICTSC8で出題された全問題の問題解説を公開します!
解けた問題は別解法の確認を、解けなかった問題は次回から解けるようになるために、是非勉強にお役立てください!

 


始まりの国

始まりの国には、様々な種族が住んでいる。エイトもこの国の出身である。
立地からか、外国との交流が盛んで旅人も多い。

永遠の国

エルフは魔法を使って生活を便利にすることが上手な種族である。
エルフの国はたくさんの村から構成され、村を指導する長は村人の尊敬を集めている。

謎の国 ICTSC

この国は未だに多くのことが謎に包まれている。
外国との交流は少なく、内情を知るものはほとんどいない。
一説では、政府が強大な力を持ち、魔法陣を使った交信を厳しく制限しているという。

荒廃の国

かつては栄えた国だったが、長く続いた内乱のせいで今は見る影もない。
治安は悪く、盗賊が人々を悩ませているという。

伝統の国

この国はドワーフを中心に構成されている。
ドワーフは何よりも繋がりを大切にしている種族である。
しかし自分の種族以外の人を冷たい目で見ることがある。

研究の国

この国では研究が盛んであり、教育にも力を入れている。
国の各地に学校があり、見習い魔導師たちが机を並べて勉強している。

ホビットの国

この国には、サーバが得意なホビットがたくさん住んでいる。 ホビットは商売が上手く、この国最大の会社であるホビットカンパニーは他国にもその名を轟かせる。

妖精の国

妖精の国がどこにあるのかは知られていない。しかし、たまに迷い込む者がいるという。妖精は様々なものに姿を変えて、出会ったものを惑わすと伝えられている。

 /

おはようございます、作問者のやつはしです。

今回は、リソース削減・ネットワーク基盤に依存しないために全て一つのVM上で完結させました。

残念ながら、この問題に辿りついたチームは1つで、解答数は0でした。

日の目を見ることはなかった問題ですが、SDNに関する問題は、今までなかったので参考問題として公開します。

 

問題文

無事に課題が終わったパトリシアは、学校を案内してくれることになった。

パトリシア「課題を手伝ってくれてありがとう♪。じゃあ学校を案内するね」

食堂や教室、体育館などを案内してもらった。

パトリシア「ここが最後よ–ここは私が志望してる研究室で、魔法陣の仮想化を研究しているの」

パトリシア「教授は、OpenFlowを使って特殊なNATを作成しているの……でも、昨日Dockerコンテナに移行してから動いていないそうなの」

エイト「ふむ、ここで教授に恩を売っておきたいところね」

パトリシア「そうなの、でも、私一人じゃできなくて……何度も悪いんだけど、手伝ってくれないかな?」

アクセスできるサーバー

  • サーバ名 : openflow
  • アドレス : openflow.3.mgi
  • ユーザ : admin
  • パスワード : hello_openflow

注意事項

  • VyOS1・VyOS2・VyOS3・VyOS4のIPアドレス・サブネット・VLANに変更を加えてはいけない。(Config自体は変えてもよい)
  • コンテナの停止・再起動は許可する。

達成すべき事項

  • VyOS4で ping 172.16.100.150 を実行し、VyOS3より返答を受け取れる。
  • OpenFlow を使って、 192.168.1.2->172.16.100.150 の SNAT と 172.16.100.150->192.168.1.2 の DNAT を実現する。

その他

OVSがインストールされたUbuntu上に、以下の5つのコンテナが存在する。
– VyOS1(192.168.1.1/24 & 172.16.100.100/24)
– VyOS2(172.16.100.200/24 & 10.30.100.1/24)
– VyOS3(192.168.1.2/24)
– VyOS4(10.30.100.2/24)
– OpenFlowController(Docker Default Network)

以下に簡単なトポロジーを示す。
VyOS3(192.168.1.2)-(192.168.1.1)VyOS(172.16.100.100)-(172.16.100.200)VyOS2(10.30.100.1)-VyOS4(10.30.100.2)

解説

この問題は、OpenvSwitch上でOpenFlowを動かしたもの。

まず、この問題の初期状態は、このようになっている。

OVSの設定を

sudo ovs-vsctl show

で確認すると、VyOS3-VyOS1,VyOS2-VyOS4では、

sudo ovs-vsctl set-fail-mode br0 standalone
sudo ovs-vsctl set-fail-mode br2 standalone

で設定してあり、L2スイッチとして動作している。
次にVyOS1-VyOS2では、

sudo ovs-vsctl set-fail-mode br1 secure

で、OpenFlowのエントリーによって処理されている。
そこで、

sudo ovs-ofctl dump-flows br1 --protocols=OpenFlow13

でエントリーを確認できる。
エントリーでは、図に書いてあるようなIP変換のみ処理されている。
ここでarpによるmacアドレスの解決ができないことに注目する。
なのでVyOS1とVyOS2でお互いにstaticでmacアドレスをお互いに登録する。
しかし、VyOSのconfigにインターフェースの設定を書いた場合、OVSにインターフェースの主導権をとられているため、反映されない。
VyOS1とVyOS2には以下のコマンドでvbashに入る

docker exec -it vyos1 /bin/vbash
docker exec -it vyos2 /bin/vbash

そして、linuxの処理として

arp -s 172.16.100.100 "VyOS2のmacアドレス" dev eth1
arp -s 172.16.100.200 "VyOS1のmacアドレス" dev eth1

staticでmacアドレスと登録する。
これでL2を解決できた。
次に、VyOS3からVyOS4にICMPパケットを飛ばすには、
VyOS1で

docker exec -it vyos1 /bin/vbash
su - vyos
configure
set protocols static route 10.30.100.0/24 next-hop 172.16.100.200
commit
save

のように設定する。
この設定で、ルーティングができるようになったのでICMPパケットが飛ぶ。

これでSDNの一端であるOpenFlowを用いた問題は解決である。
SDNでは、arpやDHCPなどL2の処理をプログラムしなければならない煩わしさがあるが、この問題のようにトポロジーを工夫することで、こういったNATやファイアーウォールなどのフィルターを、簡単に書き導入することが可能である。
ICTSC7では、運営でNAVT(Network Address Vlan Translation[作問者命名])と呼ばれるVLAN+IPaddressを全く別のIPに割り当てることでそれぞれのチームのセグメントIPを同じにし、運営からは、任意のIPアドレスで全チームにアクセスできるようにした。

 

 /

伝統の国 第3のトラブルの問題解説を以下に示します。

問題文 

NAT-PTの問題を解決した後、再びドワーフが話しかけてきた。

ドワーフ「2つもトラブルを解決してくれるとは驚いた。俺とあんたたちはもう家族も同然だよな? だから最後にあと1つだけいいか?」

エイト「え~まだあるの?」

ドワーフ「実は新しく喫茶店の支店作っていてなぁ~。そことIPsecで魔法陣をつなぎたいんだが、うまくつながらないんだ。なんとかしてくれよ~俺たち家族だろう?」

エイト「もう~調子がいいんだから。何度もごめんね。これだけ手伝ってあげてくれない?」

トポロジー図

採点基準

  1. IKEPhase1の成功が確認することができる。
  2. IKEPhase2の成功が確認することができる。
  3. 参加者手元PC及びルータからpingコマンドが通ることを確認することができる

解説

今回、1841と1941双方のルータには、通常のIPsec(NAPT前のアドレスによる記述)が設定されていました。
そのため、真ん中のルータにより、NAPT変換されることによって正しく通信が行えない状況でした。
今回はTEDによる解決方法による解答方法を記述します。(別解は後述)
1841に設定されたIPsecの記述を全て消した後
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 30 periodic
crypto ipsec transform-set T-IPSEC esp-3des esp-md5-hmac

これによりTEDによるIKEPhase1が成功します。
次に
crypto map M-IPSEC 1 ipsec-isakmp
set peer 192.168.140.2
set transform-set T-IPSEC
match address 101

interface Gi0/0
crypto map M-IPSEC

以上の記述でIKEPhase2が成功します。
そして、対向からのpingですが、帰りのパケットに対するルート情報が記述されていないため
ip route 192.168.130.0 255.255.255.0
を追記します。
別解としては、NAPT変換されていることが根本的な問題ですから、IPsecのアドレスをNAPT後のアドレスにすれば解決することができます。

まとめ

いかがでしたか?
この問題は基準点以上の正答チームは7チーム(前問のtypo)中1チームでした。
真ん中のルータを触れなくした理由は単純に真ん中のNAPTルータの設定を消すことを阻止するためでした。
debugコマンド、手元環境の論理図を書くこと等を用いると解答しやすかったのではないかと思います。

 /
作成者
麻生情報ビジネス専門学校 何 力平
概要
pingはIPネットワークにおいて、ノードの到達性を確認するための基本的なツールの一つである。pingはICMPの”echo request”パケットを対象ノードに投げ、対象ノードから”echo reply”が返ってくることで到達性を確認する。
Address Resolution Protocol (略称:ARP)は、イーサネット環境で、IPアドレスから対応するMACアドレスを動的に得るためのプロトコル。代理ARP:他のネットワークにARP要求があった場合にルーターがホストに代わって回答する仕組みである。Proxy ARPなどと呼ばれており、NAT環境化において使用される例が多い。
スタティックルーティングとは、ルータなどが、管理者が予め設定した固定的な経路表(ルーティングテーブル)に基づいて経路選択を行なうこと。スタティックルーティングは経路情報の交換がない分通信量を節約でき、外部から不正な経路情報を送信される危険性もない。
本問題では経路を選択する方法を聞きます。
問題文
選手達はROUTER2とROUTER3を管理しています。
10.0.0.1がら20.0.0.1にPING(echo request)すると、パケットはROUTER2を経由し、20.0.0.1に到着します。
逆に、20.0.0.1から返信(echo reply)すると、ROUTER3を経由し、10.0.0.1に到着します。
ROUTER0とROUTER1の設定を参照しながら、ROUTER2とROUTER3を設定してください。
ルーティングテーブルを変更しないでください。
rikihei-topo
解決方法
R2
 interface GigabitEthernet0/1
no ip proxy-arp
R3
interface GigabitEthernet0/0
no ip proxy-arp
講評
key words in 892J:
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0
mac-address-table aging-time 16
本問は見た目がルーティングテーブルを変更せずに特定の通信経路を選び、とても難しい問題です。実はL2、L3の技術とOSI7層の動きを組み合わせ考えると、簡単な問題です。
問題の考え方法は通信経路を選ぶ機器がルーターだけではなく、892jのスイチ機能を気づき、ルーターの適当のポートに「no ip proxy-arp」を使います。
ネットワーク技術者としていつも新しい技術を勉強することは大事だけど、学んだ知識、特に基本知識の活用が大切だと思います。そして、勉強するときにコマンドを暗記ではなく、「なぜ」、「どのように使う」、「他の似ている技術との差」を理解することが必要です。
残念ですが、今回、満点の解答を行ったのはありませんでした。次回は似る問題を出るかもしれませんが、選手たちの答えを期待しています。
 /

こんにちは。電気通信大学 学部1年の田中 京介こと kyontan です。

「cloudpack杯 第5回ICTトラブルシューティングコンテスト」では、FreeBSD を用いた問題を出題しました。
改めてその魅力を知っていただくと共に、出題した問題について、問題の概要や解説などをしていこうと思います。

概要

今回出題した問題は、FreeBSD と、その機能である Jail という仮想環境を用いた仮想ネットワークの構築を行うものでした。

出題意図として、皆さんが日頃から使っているであろう Linux とは異なった環境で新鮮な気持ちになって取り組んで頂けたらという気持ちがありました。また、最近 LXC, Docker を始めとしたコンテナ技術も流行っていますのでその先駆けとなった Jail の復権を……

続きを読む

作成者
麻生情報ビジネス専門学校 何 力平
概要
 RFC 3986では 予約文字(Reserved Character)と非予約文字(Unreserved Character)が定められています。
予約文字:区切り文字などの特定目的で用いるために予約されている文字であり、その目的以外ではURLに使用できません。
ファイル名には次の文字は使えません
: / ?  * < > | \
URLには次の文字は使えません(予約文字)
: / ? * # [ ] @ ! $ & ‘ ( ) + , ; =
パーセントエンコーディング(英: percent-encoding)とは URLにおいて使用できない文字を使う際に行われるエンコード(一種のエスケープ)の名称である。RFC3986のSection 2.1で定義されている。
一般にURLエンコードとも称される。
本問題ではURLにおいて使用できない文字を使い、ダウンロードできないようになっている。
問題文
あなたはABC社のCEです。
お客様から「会社新製品のマニュアルをダウンロードできない」というようなクレームが出ました。
  URL  http://192.168.1.1/product/question#20160227.txt
原因を分析し、その原因を説明する簡単な文章を提出してください。
ダウンロードしたマニュアルも併せて提出してください。
お客様の作業環境:
     Windows7/10+Firefox/Chrome/Iexplorer10/Iexplorer11
解決方法
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。
http://192.168.1.1/product/question%2320160227.txt
講評
本問はネットワーク問題かサーバー問題か分類しにくいだけど、現実でよく出るトラブルです。
RFC 3986では予約文字と非予約文字が定められています。予約文字-区切り文字など特定目的で用いるために予約されている文字で その目的以外ではURLに使用できません。
それでWeb ブラウザが#や!や@などの予約文字があるURLを解読するときに認識ミスを起こしました。
解決方法は#をパーセントエンコーディングを使い、%23に替えることです。パーセントエンコーディングとは URLにおいて使用できない文字を使う際に行われるエンコードの名称です。一般にURLエンコードとも称されます。このような知識は教科書にも載っていないから、選手たちの知識の広さと深さが要求されます。
 /

初めまして、大阪工業大学2回生の吉川尚希です。
問題案と問題文を池田悠人さんが担当し、その他の想定解と採点基準等を私が担当して二人で作成しました。

問題文

「株式会社ぽよぽよ」では老朽化に老朽化を重ねた社内システムを問題視する声が以前から挙がっていました。
この問題に解決するため、ITに少し詳しいだけで社内システムの運用・保守を担当する情報システム部門の長に任命されたあなたは、上司にシステムの刷新を請願し続けてようやく申請が通り、システムの刷新を行っていました。
2015年にシステムの刷新が完了。しかし2016年2月27日現在、あなたは朝出勤するとなぜか外部へのインターネットが繋がらないことに気づきました。
周りの上司、社員に聞きましたが曖昧な返答しかせず、あなたに対して怒ってばかりです。
上司「N+1の冗長化構成で構築しているのに、繋がらないのはおかしい!」
「午前中になんとかするのだ」
あなたは朝調査したところ2つの回線は異なるISPと契約しており、メイン回線のISPが致命的なシステムダウンを起こし、問い合わせたところ復旧に1時間かかるとのことです。
情報システム部門の長たるあなたは、上司の指示に応えて回線をすみやかに復旧し、二度と発生しないように冗長化の設定を再設定しなければなりません。
上司に報告書と変更を行ったルーターの設定(running-config)を提出してください。

トラブルの原因

今回の問題ではデフォルトゲートウェイを冗長化するHot Standby Routing Protcol(以下HSRP)を用いて冗長化の設定をしていました。
しかし、今回の初期設定だと10.100+x.3.0/24のネットワークしか監視していないため、他のネットワークで障害が発生してもHSRPが機能せず、デフォルトゲートウェイが切り替わらなかったため外部へのそつうが途絶えている状況となっていました。
原因トポロジー図

解決方法の一例

回線の復旧方法例
RT2のinterface gi0/1を一時的にshut downする等で機能していなかったHSRPを機能させる。
冗長化の再設定例
以下のコマンドをRT2に追加し、オブジェクトトラッキングを設定することで、ネットワークの監視方法を拡張することができます。この設定をすることで任意の宛先へのpingの到達性で宛先までのネットワークを監視することができるようになります。

  • ip sla 1
    icmp-echo (宛先IP address) source-interface gi0/0
    timeout 5000
    frequency 5000
    exit
  • ip sla schedule 1 life forever start-time  now
  • track 1 ip sla 1 reachability
  • int gi0/1
    standby 1 track 1 decrement 100
    exit

この他にもHSRPの設定を消去してVirtual Router Redundancy Protocol(VRRP)に切り替えて設定する解答方法もあります。

出題意図

情報関係では有事の際にもシステムやサービスを停止しないために、冗長性を持たせることが重要になっています。しかし、冗長化の機能を使用しても設定と状況次第では実際は冗長化されていないこともあるというのを知っていただくために出題しました。
以上から冗長化の再設定を重要視して採点させていただきました。

 /

みなさんこんにちは!大阪工業大学藪野好一です。
ICTSC5が終了してからもうすぐ1ヶ月ですね。とても時間の経過が早いと感じるこの頃です。

前回は、WEBアプリケーションを作ってみましたというタイトルでブログを書かせて頂きましたが、今回は大会1日目の午前に出題したWEBサーバーに繋がりませんという問題の解説をしたいと思います。

問題文

ある部署の追加に伴ってネットワークの改修を行った。しかし、改修後サーバーに繋がらなくなった。このトラブルの原因を特定し、正しく繋がるように設定を変更して欲しい。また、変更点と原因を詳しく説明して欲しい。

トラブルの原因

この問題は、WEBサーバーに繋がらないといっていますが、原因はサーバー側ではなく経路情報の交換が行われないというトラブルで、そのトラブルを解決してもらう問題でした。経路情報が正しく回っていない理由は2つあります。

1つ目は、MTUのサイズの不一致で、2つ目がアクセスリストの暗黙のdenyによるOSPFパケットの拒否でした。対向するインターフェイスのMTUサイズが一致しないと隣接関係を確立することが出来ないため、OSPFでの経路情報の交換が行えません。アクセスリストとは、通過するパケットの許可と拒否を設定することが出来るリストで、通過が許可されていないパケットは通過が暗黙的に拒否されます。今回最初に適用していたアクセスリストでは、OSPFの通過を許可する条件に一致しないため、OSPFパケットの通過が暗黙的に拒否されます。

この2つの理由によりOSPFによる経路交換が行われなくなりWEBサーバーに接続できない状態となっていました。

yabuno_issue

まとめると次のようになります。

  • MTU(Maximum Transmission Unit)
    • 一度の転送で送れるデータの最大量
    • 対向のインターフェイスのMTUのサイズが違うとOSPFの隣接関係が確立出来ない
  • ACL(Access Control List)
    • 通過するパケットの許可と拒否を設定することが出来るリスト
    • 通過が許可されていないパケットは通過が暗黙的に拒否される

解決方法

今回のトラブルでは、OSPFによる経路情報の交換が行われていないため、OSPFにより正しく経路情報の交換が行われるように設定の変更を行う必要があります。そのために、対向ルーターのMTUサイズを一致させ、アクセスリストをOSPFが通過できるように書き換えます。これにより、OSPFによる経路情報の交換が行えるようになります。

yabuno_answer

さらに、次の2点の修正も行うことによりトラブルの発生を抑制したり、トラブルシューティングを容易にすることが出来ます。

1つ目がMSSの調整です。MSSとは、TCPで受信可能なヘッダを除いたデータサイズです。MTUサイズがイーサネットの標準サイズである1500から変更されている場合はMSSサイズも設定することが推奨されています。今回最初に設定されていたMTUサイズは1360だったので、TCPヘッダ(20byte)とIPヘッダ(20byte)の合わせて40byteを引いた1320をMSSサイズとして設定します。

2つ目は、アクセスリストで暗黙的に通過が拒否されているicmp のunreachableパケットの通過を許可する設定への変更である。このicmp unreachableパケットの通過が拒否されると、宛先に届けられなかったという情報が正常に帰って来ないためトラブルの原因となります。そのため、icmpのunreachableも通過を許可するようにアクセスリストを書き換えることが望ましいと考えます。

出題意図

普段は当たり前のように経路交換を行っているルーティングプロトコルがうまく動作しない場合の例とそれによって起こるトラブルを知って欲しいという思いから問題を出題しました。

最後に

1問目のインターネットに繋がりません問題と一緒に出題したため、問題の難易度が高くなってしまったようで、正解率はとても低かったです。
もし、OSPFが回っていないというトラブルに遭遇した際にこの問題の事を思い出していただければ幸いです。

今回初めてトラブルシューティングコンテストに関わらせていただきましたが、多くの経験をさせて頂きました。この場をお借りしてお礼申し上げます。実行委員のみなさま、運営委員のみなさま、参加者のみなさま本当にありがとうございます。そしてお疲れさまでした。

 /
カテゴリー

どうもどうも、大阪工業大学 池田です。
ICTSC には初参加で初運営委員をしております。
なぜ参加したかと言うと、実はネットワーク関係を勉強したのは去年の8月くらいから勉強を初め、学校の方では主にCiscoルーター・スイッチを触りその関係で今回のコンテストに運営として志願しました。
ICTSCではL2,L3のネットワーク設計を担当しています。L1もちょっと触ってます。

実際の会場で(おそらく)お会いするとは思います、よろしくお願いします。

この記事ではネットワーク設計とは何をするのか!?ってな感じで、後から“””デキる”””方々からお叱りをおことばを受けることを覚悟しつつ、書いてきます。

Layer1とか2とか3とか…

まずはじめに情報処理技術者試験等で聞いたことのある、OSI参照モデルのお話です。
L1は物理層、L2はデータリンク層、L3はネットワーク層…と勉強した記憶があります(汗
また下位層で決めた内容を基に上位層に引き継いでいくってのもありますよね、ネットワーク設計においても同じ事が言えます。

L2設計

まず基となる下位層から、今回作ろうとするネットワークを考えます。

1,2,3と下からで、L1設計(物理配線)からじゃないの?

と思われる方が居ると思いますが(僕も思ってた)、先に物理配線、機材や光ファイバー、LANケーブルを決めてしまうと途中で変更できなくなるのと、実際の論理的な設計の時に仕様変更で必要な機材やケーブルが増えるかもしれません。
論理から物理に落とし込んでいきます。

なのでL2設計から始めます。僕のイメージでは、

  • 今回必要なネットワークは何があるのかを考える。
  • ルーターを超えない範囲のネットワークをたくさん、ふわふわしてるようなイメージを想像する。
  • またそのネットワークが何の役割をするのかも考える。

と言ったイメージでL2ネットワークを作成していきます。
IPアドレスやVLANIDを考える必要はありません。ただL3設計時に割り振りやすいような配置固めは考えます。
目指せふわふわネットワーク。

 
L2

L3設計

ここでルーターを超える通信について考えてみます、L2設計で作成したネットワークを繋げる作業です。
L3設計では、

  • IPアドレスやVLANIDの割り振り
  • ルーティング
  • フィルタリング

の作業を行います。
ルーティングはRIPやOSPFがよく知られていますよね。実際の企業ネットワークはもっと難しいこと(他の企業ネットワークとお金が絡む)をしているそうですがここでは割愛します。
フィルタリングについても拡張ACLでCiscoだとanyですべて切ったり、ipやtcpだけを使う(ipやtcpの層から上の層すべて)プロトコルを切ることもできます。L2ネットワーク同士の接続要件もフィルタリングの仕事です。
体外接続に置いてもグローバルIPアドレスで引っ張るか、1つのグローバルIPアドレスにNAPTする方法もあります。
バックボーンはどういう構成にするのか?考えることは大量にあります。

 

L3

L1設計

L3設計まで行くと最低限必要な機材スペックや光ファイバーの本数、LANケーブルが何本いるか、なんとなく分かっていくはずです。
あとは設置する場所の大きさを測り、長さも測ればなお良しです。お疲れさまです。

おわりに

如何だったでしょうか、ICTSCでは企業ネットワークのようなネットワークを想定しています。
しかし本物の企業ネットワークには当たり前ではあるのですが、ポリシーが定められており、ポリシーを基に考えていきます。
今回の大会でもポリシーがあったような気がしましたが…

我々運営もそろそろ修羅場を迎えそうな雰囲気があります。
参加者の皆様、当日お会いしましょう!

 /
カテゴリー

はじめまして。kyontan こと田中京介と申します。
ICTSC に携わるのは初めてで、今回が初参加かつ初運営委員です。
インフラには以前から興味があり、ICTSC5を通して様々なことを吸収していきたいと思っています。
どうかお手柔らかによろしくお願いします。

今回は インフラ の 監視周り構築担当 ということで、監視に関するふわっとした話をします。

そもそもなんで監視をする必要があるのか? という疑問がまず存在するのですが、僕は以下の様な理由で監視が必要だと考えています。

  • サービスを継続して提供するため (死活監視)
    多くのサービスが監視を導入する理由がこれだと思います。
    サービスに一定間隔で ping を飛ばしたり、 特定ポート (80, 443 など) へのリクエストを行ったりすることで、サービスがダウンしていないか確認するものです。
    実際に僕も自宅のサーバーでは Pingdom を使って死活監視を行っています。
  • サービスを提供するインフラを改善するため
    これは、サービスの継続提供の先にあるものです。
    例えば、提供しているサービスの一部に負荷が掛かりサービス全体が重くなっている、なんてことがあったとします。
    こういった時に、どのサーバーに負荷がかかっているのか? ということを知ることで、そこから改善の糸口をつかむことができるのではないかと考えています。

そこで今回は上記の目標を達成するため、以下のとおり監視ツールの選定を行いました。

  • Mackerel
    株式会社はてなが提供している監視サービス (SaaS) です。
    まだ新しいサービスですが、各所で使われているのをブログなんかで目にします。
    ホストに紐付いた通常のメトリック(監視項目)とは別に、サービスメトリックというホストに依存しないメトリックも設定できます。
    SaaS なので設定が最小限で済むことが大きいです。UI が格好いいというのも個人的には好きなところです。
  • Zabbix
    オープンソースの監視ツールとしては Nagios や MRTG, Munin と並んで有名なものです。
    豊富なテンプレートにより、監視対象を容易に設定できることや、多彩な設定ができることが強みです。
    こちらは直接サーバにインストールして使う形になります。WebUI もあるようです。

ICTSC5 では、これら2つを併用してみる形となりました。
Mackerel は SaaS であるため、外部へ疏通ができるサーバーしか監視することができません。また、内部のネットワークに負荷が掛かっていたり、外部への接続に問題があるというときには、当たり前ですが監視ができません。
こういった事情も踏まえ、外部に出せるところは Mackerel に頼りつつ、Zabbix で不足している部分を補うというユースケースを考えており、現在検証を進めているところです。

さて、ここまで書いておきながら、私は今までこういったツールをほとんど使ったことがありません。(お恥ずかしながら……)
まだまだ検証途中であり、サービスの中身に踏み込んだ内容が書けていないのはこういった事情があります。
またそのうち、検証も進んできたところで再度記事を書きたいなと思います。

ところで今回の大会、募集要項が去年と少しだけ変わっているのには気付かれたでしょうか?
私としては、そんなところにも目を向けて頂けたらと思っています。

そんな ICTSC 5 は皆さんの参加応募をお待ちしております。募集要項はこちらです!

cloudpack杯 第5回 ICTトラブルシューティングコンテスト 参加募集要項

以上で私の記事は終わりです。

最近のコメント