ICTSC9のバックボーン解説
こんにちは、バックボーンなどインフラを担当した川原です。
参加者の皆さん、参加してくださり誠にありがとうございました。今回も30分のサーバの電源断、1日目のWi-Fiの不調など、皆さんにご不便をお掛けしてしまい申し訳ありませんでした。特にWi-Fiにつきましては、アンケートでも厳しい意見が多かったためバックボーン担当として重く受け止めています。ただ、Wi-Fiの調子は人数が増えてみないとわからないことも多いです。年々、改善を繰り返しながら取り組んでおりますので今後とも率直な意見をくださりながら参加して楽しんでいただければと思います。
また、機材提供・協力をはじめとした協賛企業の皆様、毎度のことながら我々学生の無茶な要望を受け入れてくださり誠にありがとうございます。今回も参加者へのインフラを提供する傍ら、運営学生も貴重な体験をすることができました。
さて、堅苦しい話はここまでとして今回も大規模なインフラを組んで皆さんに提供しました。LTなどでも話しましたが、改めてブログにまとめることで多くの人にネットワークやサーバに興味を持って欲しいと思っています。
今回のインフラは何人かで担当しているので、担当した各人がブログへ投稿することになっています。この記事では最初の記事として全体の総括をしていきたいと思います。
個別の解説は以下のとおりです．
バックボーンについて
我々ICTSC運営において、バックボーンとは全チームが問題を解くために使うインフラのことを言います。バックボーン担当は作問など大会開催に必要なタスクをこなす傍ら、興味のある人が思い思いのインフラを構築していくことになります。
バックボーンの目的は以下です。
- 参加者が問題を快適に解ける環境を提供する
- ICTSC運営が問題を提供しやすい環境を提供する
つまり、1に参加者、2に参加者、3くらいに問題作成者のことを考えて作るわけです。勘違いすると安定感に欠けた目的のわからないものになってしまうので、気をつけなくてはいけません。また、どんな問題でも出題できるように準備をしています。インフラ的に難しいからこの問題はボツで…ということは極力ないようにします。
問題作成は運営発足から行われるものなので、運営発足からHotstage(本番の大会会場で本番の機材を使いながら準備する期間)中のインフラもある程度安定させなければ、よい品質の問題を用意することができなくなってしまいます。そのあたりの差し引きをしながら本番環境を構築していくのもバックボーン構築の醍醐味です。
今回のバックボーンテーマについて
最近のICTSCのバックボーンはテーマを決めて構築を行っています。第7回は安定感、第8回は仮想化でした。
今回は… 冗長化!!
ということで構築されたバックボーンネットワークは以下のように、今回のテーマに則ってネットワーク機材をすべて冗長化しています。
各機材の冗長構成については各担当の者がそれぞれ本ブログに投稿することになっているので楽しみにしていてください。概要については当日の発表資料を以下に用意しました。
当日発生したトラブルについて
どれだけ準備しようがトラブルは起きてしまうものです。当日起きてしまったトラブルをまとめていきます。
1日目 11:30頃 サーバ電源断
1日目 11:30頃にサーバの全台が電源断するという障害が発生しました。昼食が早まったことで解答不可能になった時間は比較的少なくなりましたが、ご迷惑をお掛けしてしまい誠に申し訳ございませんでした。
原因
我々の不手際によって協賛の皆さんが半分のサーバを接続している電源系統でPCの充電をしてしまったことによる過負荷でおきたものであると考えられます。また、その後私が生きていたサーバのコンセントを抜くというミスオペを犯してしまいました。
改善策
改善策としては、サーバは冗長化が行えていなかったためサーバの電源をそのような危険性がある電源からではなくアクセスしにくい電源を選択するなどがあります。ネットワーク機器は最悪電源が落ちても2系統とっていましたし、再起動も比較的高速に行えます。何よりサーバの電源断はHDDなどが故障する可能性もあります。
ミスオペに関してはダブルチェックなどを行うなどがあります。ただ、復旧を一丸となって行えたのでとても良かったと思います。私を責めずに冷静に私の指示に従ってくれたみんなには感謝です。
1日目 懇親会
Wi-Fiの調子が悪いという話を多くの方から聞きました。懇親会後、原因の調査と修正を行いました。2日目の開始時にも軽くお伝えしましたが、ストレスを感じさせてしまい申し訳ありませんでした。
原因
2.4Ghz帯の電波が強すぎたことによって、多くのクライアントが2.4Ghz帯で接続し混線したものと考えられます。
改善策
2.4Ghz帯の電波を弱める、5Ghz帯でクライアントが接続できているか監視するなどの対策を行いました。我々の感知している範囲では2日目は快適に使用できていたと聞いています。
しかし、競技時間の半分を不快な環境で回答していたことについては反省会でも話題になりました。次回以降はWi-Fiの調子などを早めに聞く機会を設け、早めに対策が行えるように努力します。みなさんもストレスを感じた場合は気軽に問い合わせ下さい。バックボーン側に原因がある場合は早急に対応いたします。
また、Wi-Fiの調子は当日の人数が入らないとわからないことも多いです。次回以降の運営からも当日アナウンスがあるとは思いますが、Wi−Fiが不調の場合は有線接続の使用をご検討ください。
2日目 13時頃
一部グローバルIP(Googleなど)への接続ができなくなるという障害が発生しました。障害は3分ほど継続した後、収束しました。
原因
以上の障害発生時のメトリクスを見ても、障害発生時間帯にルート数が5000経路ほど減少していました。また、こちらの設定ミスか上流からのトラフィックを受信しているのに、こちらからトラフィックが流れていませんでした。障害発生から5分以内にメトリクスを把握し上流であるHomeNOC様に確認したところ、一部障害が発生していたとお聞きしました。
しかし、このようなことが発生してもよいように上流は冗長化していましたが、うまく動作しませんでした。冗長化が動作しなかった原因としては、IPv4のフルルートを受け取っていた影響でルートの収束まで時間がかかってしまったようです。準備期間中や開催後に接続断テストを行った際には収束まで約10分の時間を要しました。
原因究明にはメトリクスによる可視化が重要であることを実感できた障害でもありました。
改善策
なぜ、収束までにここまでの時間が発生するのかは我々も理解しきれていません。勉強してきます。
フルルートの運用をしてみないとわからないことは多く存在します。このような貴重な機会をくださったHomeNOC様に感謝しております。
おまけ: ベンチマーク
今回、テンションがおかしくなってしまった運営学生は10Gbps NICをヤフオクで9本程度落札してしまいました。それをNAVTサーバに搭載し、バックボーンに組み込んでいました。大会終了後、バックボーンネットワークがどれほどの帯域を出せるのかベンチマークを取りました。
実験環境
18:13ごろから18:23ごろまでOpenstackのVM 10台から、別のVM 10台までiperf3を実行しました。以下のような経路を通り、通信を行いました。
その後、18:28以降に同様の経路でOpenstackのVM 15台から、別のVM 15台までiperf3を実行していました。
結果
わかりにくいですが、18:13ごろから18:23ごろまで 5 Gbps 、 18:28以降は 8 Gbps の流量が出ていることが右下のTraffic of server と transmit traffics of servers のグラフからわかります。このグラフは、Openstackのホストサーバの受信と送信の流量を示しています。
タイトルが消えてしまっていますが右上のグラフがNAVT 2台の流量合計です。このグラフからも 8 Gbps まで出ていることがわかります。
真ん中の Traffics between Nexus5548 and QFX5100 のグラフはNexus5548とQFX5100の間の4本の流量をそれぞれ示しており、上半分が送信、下半分が受信になっています。このグラフだけ単位が Bytes per sec になっていることに注意してください。
考察
楽しかった！！
LACPのハッシュアルゴリズムの偏りによって、 1 Gbps * 2 を出せるサーバが確率的に 1 Gbps しか出てないことがあり、15台のVM同士の通信では 8 Gbps までしか実験を行うことができませんでした。右下の Traffic of server と transmit traffics of servers のグラフからOpenstackのVM同士の合計トラフィックが 8 Gbps しか出てないことがわかります。今回のバックボーンのキャパシティは 20 Gbps であったため、今回のベンチマークはバックボーンのベンチマークというよりサーバのベンチマークになってしまいました。特に左下の CPU idle のグラフでは各ホストのcpu0の idle が大幅に下回っており、サーバで 10 Gbps を処理をする際割り込みが多く発生することが大変であるという意味がわかりました。
Traffics between Nexus5548 and QFX5100 のグラフから Nexus5548 <==> QFX5100 間の通信のロードバランスは非常に美しく4つのインターフェイスに対して等コストバランシングができていることがわかりました。 Nexus5548 ==> QFX5100 と Nexus5548 <== QFX5100 両方向で等コストバランシングされていることから両方の機種がよい性能を持っていることがわかりました。
NAVTは 10 Gbps * 2 のNICを刺したサーバの2台構成で 8 Gbps は余裕であることがわかりました。 :clap:
まとめ
バックボーン担当は以上の通り様々な技術的挑戦をしながら参加者に快適に問題を解いてもらうことを目標にバックボーンを構築しています。興味を持った方は是非これから続く記事も読んでいただき、わからないところを自分で調べることで知識を深めていただければと思います。
また、機材提供をしていただける皆様！！面白い機材、お待ちしております！！
改めて、参加者・関係者の皆様ありがとうございました。次回も是非参加をよろしくお願いいたします！！