OpenStackワークショップでインフラ初心者をボコボコにしてしまった話


年も明けてしまいましたが、年末に行った勉強会の主催者側としての記事を一つ。

母校で 定期的に開催しているOB勉強会で、 「OB、在校生向けにOpenStackに関する勉強会をやってほしい」というリクエストがあったので、 勉強会を開いたら思った以上に初級インフラ勉強会になってしまった話。


概要

IMG_1060 IMG_1072

IMG_1079

 

 

苦しみながらインフラの裏側を触ってもらう、経験してもらう事を目的として「OpenStackワークショップ」というものを開催しました。

 

勉強会全体の流れとしては

  1. 簡単にスライドでOpenStackとは?コンポーネントとは?とよくある解説をする
  2. まず、主催者である私が事前に自宅サーバとして構築して構築した ESXi及びSSHのゲートウェイサーバにアクセスしてもらい、動作確認及び、作業対象の仮想マシンのチェック。
  3. 大体5〜6人1組の3チームに分かれてESXi上に既に構築された仮想マシン(OSはUbuntu)に対してNW周りの設定をしたり、OpenStackに関するコンポーネントをインストールしてもらったりする。チーム毎にOpenStackに必要なコンポーネントをインストールする形。

といったものです。 事前に私が行った準備としては

  1. 勉強用スライドの作成
  2. ”イイ感じ”の勉強用、参考用のソースURLを収集しておく
  3. 実際に参加者が使う空仮想マシンの構築、ストレージやVLANなどのNW周りの準備
  4. 本当に問題ないよね?の確認を込めて実際に構築

これら4つを仕事の合間をみてポチポチやっていました。

 

行った結果

 

OpenStackを扱う事の難しさを知ってもらうのが勉強会のテーマでもあったので、俗に言うOpenStackインストールバトルをクリアしたチームはありませんでした。

というものの、いくつかリアルトラブルも発生したのですが、この3つが致命的だったと思います。

 

詰み1,ESXi6.5のHTML5クライアントの使い方に慣れておらず、躓いた

 

今回は私が用意したESXi6.5とネットワーク・インフラを組み合わせた環境で予め仮想マシン及びOSをインストールした状態で参加者に引き渡しました。

ネットワークの設定は除いた状態だった為、最初からSSH接続はできず、ESXi6.5のコンソール画面から ネットワークの設定(IPアドレスの割当など)をする必要があったのですが、コンソール周りでリアルトラブル続出。

単純にブラウザが対応していなかったり、キーボード入力が思うようにいかなかったり、そもそもコンソールに入れたはいいがバグってる等…。 私のようなインフラ人間野郎には当然の如く扱っていたツールのレクチャーをもう少し手厚くフォローする必要があるなと痛感しました。

スクリーンショット 2017-01-01 0.11.26

詰み2,単純にNW・サーバ周りの基礎的な知識を持つ参加者が少なかった

ここの詰みは主催者側の準備不足が強く現れた部分でした。

事前に提示したNW構成をみてパパッとIPアドレスの割当やデフォルトGWの設定を入れられる参加者が思ったよりも少なかったように感じました。

事前情報では「授業でも触っているし、OBの方も経験長いから余裕やろ!!」なんてのん気に構えてフォローする為の手順書の作成をサボってたら痛い目をみました。 それと、純粋にインフラに強い学生があまり見受けられませんでした。

上記をフォローすると、授業で触っているLinuxディストリビューションはCentOSなどのRedHat系OSに対し、今回私が提供したのはUbuntu。IPアドレスの設定やchrony(ntpd)周りの違いなど、勝手を理解していない方にはハードルが高いものだったかもしれません。

 

また、一部のOBの方も開発メインで、MWの構築から先はやるけどOSから下はインフラ部隊が整備して提供してくれる為、そもそも実務でインフラに触れることがあまりない、、といった様子でした。

これらについては、フォローするためのドキュメントをしっかり作り込んでおけばよかったかな?と思いつつ、運営チームの方から 「いや、これぐらい(IPアドレスの設定やESXiの操作周りなど)軽々とこなせないとこの先やっていけないよね」 というお言葉もあり、どこまで手を差し伸べるか、という点で非常に悩みましたし、苦労しました。

詰み3,今回提供した環境のストレージI/Oが遅くてインストール処理が非常に長引いた

上記2つのトラブルが落ち着いたワークショップ後半、一斉に参加者達がコンポーネントやサービスをインストールするあたりに差し掛かった所、このトラブルが発生しました。

検証時は特に問題なく感じられたストレージのパフォーマンスが非常に悪く、どのチームもインストール待ちで手持ち無沙汰状態になってしまったのです。

多少の時間ならまだしも、それが30分、1時間、2時間と続くのですから地獄。 結局この最後のトラブルが原因で、軌道に乗りだした各チームの作業もストップしてしまいました…。

実際出てた速度

ちなみに後々速度計測してみましたが

  • ESXi上の仮想マシン(vmdkファイルはNFS上) : 3~5MB/s (Read & Write)
  • 私の個人環境OpenStack上の仮想マシン(CinderボリュームはNFS上) : 30MB/s (Read & Write)

※1 NFSはVLANで別セグメントに切り分けており、各仮想化基盤から専用のNICで通信している。

※2 ESXi、OpenStack共に 対象NFSは同じ

誰もアクセスしていないときで10倍近く差が出ています。 これでESXi上の複数の仮想マシンから命令を送っていたとすると、また結果も悪くなっていたでしょう。

同じストレージに対してこれだけの差なので、NWの影響やストレージそのものというより、仮想化基盤が原因なのかな?とも思っています。(詳しい人教えてください…)

また、そもそも私が用意したNFS環境のNASストレージの速度が遅い?といった部分もあります。 この辺良い解決法ないかなぁ…


よかったところ、改善すべきところ

ワークショップという割には結構投げっぱなしの勉強会だった感じも否めません。 ただ参加者からは

  • 「ハードだったけどやりがいがあって楽しかった」
  • 「キリンさん本気の”死ぬがよい”を経験できた。」
  • 「開発の人間なので(OpenStackに関する部分までは到達できなかったが)インフラ部分を触れたのは新鮮で良かった」

といった声を頂いたので、上記のトラブルを上手く備えて対処できれば劇的に良くなるなと感じました。

次回、同じ様な催しをする際は事前情報や自分のスキル経験にとらわれず、様々な参加者層、レベルに対応出来るような準備ができたら……いいですね。


おまけ

今回のインフラ。 仕事柄、保守はしていますが構築は素人。見よう見真似で試行錯誤しました。

ちなみにESXi → Storage へのアクセスはNFS。 NFS上に全ての仮想マシンのvmdkファイルをぶち込んでたのがパフォーマンス遅延の原因なのかなー…。

インフラ部分の画像

以上


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です