第5回ICTトラブルシューティングコンテストにOpenStackを導入してみた

こんにちは、電気通信大学 学部3年の森 優輝です。
2016年2月27,28日に開催されました第5回ICTトラブルシューティングコンテスト(以後トラコン)にて運営委員を務め、主に運営サーバーの構築を担当しました。
ありがたいことにツチノコの仲間に入れてもらいました。ありがとうございます。

今回のトラコンはDMM.com Labのみなさまも大人枠で参戦いただきました(第5回ICTトラブルシューティングコンテスト結果)。
ありがとうございました。

大会の模様はトラコン公式ページにてフォトレポートとして掲載しています。是非そちらもご覧ください。
cloudpack杯 ICTSC5 レポートまとめ

出題した問題の解説はトラコン運営委員によるtech-blogにて近日公開予定です。

OpenStack導入の動機

一番の動機は「チャレンジ!」です。

少し具体的に書きます。

前回の第4回トラコンでは使用したハイパーバイザーにVMware vSphereの評価版を使用していました。
そこから脱却したいという思いがあり、今回はオープンソースなハイパーバイザーであるKVMを採用しようと考えました。

また前回大会の準備では問題VMのテンプレートから全チーム分展開するのにAnsibleを用いる予定でしたが、想像以上にうまくいかず、断念。
そこで今回はあえてプライベートクラウドを構築し、クラウドの利点の1つであるサーバー増減のしやすさを利用できないかと考えました。

そして今年の4月に新バージョン「Mitaka」がリリースされる、話題のOpenStackを使ってみようと考えました、

そういった経緯から、プライベートクラウド基盤としてOpenStack、ハイパーバイザーとしてKVMを採用することにしました。

構成

今回はシンプルな構成を目指しました。

サーバーは2台構成で、片方は管理&コンピュート兼用ノード。もう片方はコンピュートノード。
作成されるVMはそのまま問題用VLANネットワークに所属するようにするため、OpenStackで標準的に使用される仮想ルーターは今回はなし。ネットワークノードも不要。
OpenStackのコンポーネントはインスタンス起動に最低限必要なもののみ。

簡単な構成図は私が懇親会でLTした資料に掲載しています。
ICTSC5 meets…

OpenStackのインストール方法

2台だけの構成ですので、OpenStackのインストールガイドをシェルスクリプトに起こしたものを使用しました。
スクリプトはGitHubにアップしてあります。2,3台構成でサクッと構築する用途に、ご興味あればぜひご活用ください。

VMの提供と問題作成

今回の大会ではサーバーOSとして基本的にはUbuntuを使用し、一部問題でFreeBSDを使用しました。
なんとなくこれらのクラウドイメージファイルを落としてきてOpenStackに登録すればいいや。と軽い気持ちでいましたが、
標準ではCloud-initの力によってSSHは公開鍵認証のみしか受け付けず、ホスト名もインスタンス作成時につけた名前がそのままついたり。

問題ごとにホスト名の変更をAnsibleを用いて行うと聞いていたため、ここではCloud-initはOSイメージから削除し、
必要最低限のパッケージインストール&設定を済ましたものを問題作成者に配布しました。

問題作成者はそのベースイメージからVMを必要な数だけ作成し、問題サーバーを構築してもらいました。
作成完了後はスナップショットをとってもらい、後日全チーム分展開する形をとりました。

サーバー展開方法

今回の大会ではおよそ250-300台のVMを用意しました。
VMの展開は、Ansibleのos_serverモジュールを主に使用しました。Playbookは近日中に公開予定です。

1つ展開に際して工夫した点があります。
問題出題の都合上、問題用サーバーにはチーム別にIPアドレスを固定で割り振る必要があります(例えば10.X.14.2のような。Xはチーム番号)。

任意のサーバーに対して特定のIPアドレスを固定する方法の1つに、DHCPサーバーにてMACアドレスとIPアドレスを紐付ける方法があります。前回大会ではシェルスクリプトを使ってガムシャラにコンフィグ部分を自動生成し、DHCPサーバーの設定ファイルにぺたっと・・・。

今回はOpenStackのポート機能を使用しました。基本的にはこちらもDHCPを利用しますが、感覚的にはあらかじめIPアドレスを割り振ったNICをVMにくっつける、というイメージです(ちょっと詳しい話はこのあたりとかこのあたりを参照)。
この機能をAnsibleから利用するために、os_networkではなくquantum_networkを使用しました。

ハマったところ

・OpenStack管理外のIPアドレスの通信フィルター
VMに設定されるIPアドレスは、OpenStackによって割り当てられたもの以外は基本的に使用できません。VMに入って手動でIPアドレスを違うものに変更すると通信がiptablesによってフィルターされます。
コンテストの性質上、問題の中には悪意のあるサーバーから変な通信が飛んでくるものがあり、悪意サーバーが持つIPアドレスとは異なるアドレスを送信元としてパケットを送出することなどがたまにあります。
そこで、カーネルパラメーターを変更することで、変な通信をiptablesによってフィルタされないようにしました。具体的には

/etc/sysctl.confに以下を追記し、

net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-arptables=0

適用します。

# sysctl -p

こうすることで運営学生が作る変な通信を流すことが可能となりました。

・Ansibleからポートが作れない
AnsibleからVM展開Playbookを適用する際にIPアドレス固定のためのポートを作成するようにしていました。
しかし一般ユーザーからではポートが権限の問題で作成できず、管理者ユーザーが作成したポートが一般ユーザーから見えないというもの。
ここは権限ポリシーを変更することで対処しました。ネットワーク関係はNeutronというコンポーネントが管理しているので、そこのポリシーを変更しました。

# editor /etc/neutron/policy.json
"*_port"と名のついたキーの値をすべて "" に変更。

OpenStackを導入してよかったこと

1. 気軽にサーバー問題の検証ができた
VMの作成が簡単にでき、OSもあらかじめイメージを登録してあったために10~20秒ほどでVMが起動していたためストレスも少なかったと思います。VMware vSphereのWeb Clientは不安定なことなどが多く、取っつきづらい一面があったことから、特にこのように感じられたのかもしれません。

2. Linuxの知識でメンテナンスができた
上で構成図を載せましたが、OpenStackは比較的レガシーなミドルウェアを組み合わせて使ってることが多いため、メンテナンスがしやすかったと感じました。たとえばAnsibleでVMの展開を一気に行おうとしたとき
にMySQLが最大接続数に達していたことが判明しました。スピードを上げるためにMySQLのチューニングを行うことで改善を図った、ということがありました。

3. ディスクイメージのサイズが小さかった
問題の展開前にあった懸念事項に、ストレージは足りるか?というものがありました。いざ300VM弱の展開を終え、dfコマンドを叩いてみると大して容量を使っていないことが判明しました。
展開に使用したベースのイメージはおよそ1GB強あったのですが、1つ1つのインスタンスに割り当てられたディスクイメージの実サイズは数百MBほどで大変驚きました。
ディスクイメージにQCOW2というフォーマットを使用したのですが、QCOWは”QEMU Copy on Write”の略で、ベースイメージの差分だけを保存できる仕組みになっていたようです。(Dockerも似たような感じだったと記憶しています。)
そのおかげで展開時のIO負荷も少なく済んだと思います。

まとめ

この記事ではトラコンの運営サーバーにOpenStackを導入したお話を書きました。
一応は大きな障害もなく、基本的には問題なくサーバーの提供が出来ていたと思います。
私自身、今回のようなOpenStack環境(約300VMが立ったり、Linux BridgeでVMとVLANネットワークを直接つないだり)は初めてでしたが、なんとかなりました。
VMの展開もAnsibleを用いて無事にでき、また大きなトラブルもありませんでした。
今更ですが、OpenStackの内部で動いているWorkerを増やすなどのパフォーマンスチューニングもしてみればよかったなあとも思っています。

これは個人的な想いなのですが、なんとかして参加者にVMのコンソール画面を参加者に提供したいです。
サーバー側のネットワーク設定が悪く疎通がとれないような場合やPXEブートなどを想定した問題が出題可能となり、問題の幅がより広がるのではないかと思っています。

インターネットが当たり前になり、クラウドも当たり前になりつつある今、クラウド特有のトラブルを出題することを考えてもいい頃かもしれません。

今回はOpenStack+KVMを基盤に使用しましたが、次回のサーバー基盤はどういう構成になるでしょうか。サーバーだけでなく、どんなコンテストになるのでしょうか。まだ何も決まっていません。
トラコンの運営に興味を持った方、ぜひ第6回トラコン 大阪の陣にて一緒に運営やりましょう!

改めて、cloudpack杯 第5回ICTトラブルシューティングコンテストに協賛いただいた企業様をはじめ、参加されたみなさま、そして運営委員&実行委員には大変感謝しております。本当にありがとうございました。


PAGE TOP