みなさんこんにちは。
普段は CloudStack ではないナニカを触っていることが多い私ですが、CloudStack のことも、ずっと気になっていました。
なにせ、これだけ商用実績があるわけですから。
また、年度末に向けて絶賛デスマ^H^H^H活動中のオープンクラウド実証実験(OCDET)の活動の一環で、最近「基盤統合検証(オーケストレーション)WG」というのが発足しました。
端的に言うと、CloudStackなクラウドとOpenStackなクラウドをつないで運用できないか？という試みです。
私はこれにかかわっている事情もあり、いよいよ CloudStack に挑戦してみることにしました。
実は、初めて CloudStack をインストールしてみたときに驚いたことがあります。
私も遠巻きに眺めながら CloudStack が Java で開発されていることは知っていたのですが、CloudStack の Management Server(MS) が Tomcat のServlet Container の上で動いていることは知りませんでした。
どんな実装を使うにしても、運用する以上は、システム全体からSPOFになりうるコンポーネントを除去することは、誰でも考えると思います。
Management Server が Tomcat だということを知った時、「ああ、仕事でクラウドをやり始める前にかかわっていた、Web３層系システムのノウハウがそのまま使えるのだな」と思ったのを覚えています。
…と、いうわけで前置きがだいぶ長くなりましたが、CloudStack初心者の(でもTomcatを使ったwebシステム位はやったことがある) 一般人が手持ちの知識だけで頑張ってみるとどうなるか？
題して、
「一般人の、一般人による、一般人のため CloudStack」
です。 :)
今回は、Apache-Tomcat コネクタとして mod_jk を使って図１の赤い点線の中身を試してみます。
mod_jk と mod_proxy_ajp を比較すると宗教戦争になってしまうかもしれません(笑)し、nginxとかいろいろあるわけですが、私が mod_jk 選択した理由は単純に仕事で使ったことがあるからです。
冷静に見てみると、mod_proxy_ajp はなんといっても apache 本体に含まれていて安心な一方、
リカバリ処理の丁寧さでは mod_jk に一日の長があるようです。（と、私の周りの人間は言っていました...)
1. 準備
ベースOSとしては、Ubuntu 12.04 LTS(amd64)を使い、VMware Player で２台用意しました。
RedHat系のdistributionと比較すると、今回関連する範囲では Apache まわりで若干環境設定の癖に違いがあるとおもいます。
既に長くなってきているので、CloudStacker(?)の皆さんが良くご存じの部分ははしょって書きます。
- OS(Ubuntu 12.04 LTS(amd64))を入れます
- cloudstack 4.0 の apt line を設定します
- 私は /etc/apt/source.list の末尾に以下の２行を足しました。
- deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
- deb-src http://cloudstack.apt-get.eu/ubuntu precise 4.0
- Management Server をインストールし、単体で初期設定します。
- sudo apt-get install cloud-client
- 通常の初期設定！設定！設定！
- DBはもちろん片側に寄せておきます。
- とりあえずWeb UIからログインできるところまでたどりついてください。
以下、私の場合のIPはそれぞれ Management Server #1 が 192.168.174.137、Management Server #2 が 192.168.174.129 です。
先にApacheからつなぎに行く先の Tomcat (=Management Server)の設定をしておきます。
- Apache-Tomcat 連携用の設定
- Management Server #2 の /etc/cloud/management/server.xml に、以下のサンプルのような箇所があります。Management Server #2のほうは、jvmRoute プロパティのデフォルト値 jvm1 から jvm2 に書き換えておきます。この jvmRoute は、後で設定する mod_jk から見た、Tomcat の識別名になります。
<Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1"> - Tomcat Cluster の設定
- Management Server の片系ダウン時にログインセッションを引き継ぐために、セッションレプリケーションの設定を行います。これには、LBから apache/mod_jk のどちらにくるのかわからないため、セッション情報を知らない mod_jk にリクエストが渡されてしまうことがあるのに対応する意味もあります。
…が、これは別途説明します。
3. mod_jk のインストールと設定
- mod_jk (とapache2)をインストールします
- sudo apt-get libapache2-mod-jk
- apache2 本体もインストールされます
- また、以下の例ではノード数の節約のため、Management Server に Apache を同居させていますので注意してください。
- mod_jk の有効化
- sudo a2enmod mod_jk
- mod_jkの環境設定
- /etc/apache2/mods-enabled/jk.conf
- 最低限、以下の２行を追加します。
- JkMount /client/* wlb
- JkMountCopy All
- また、トラブルシューティング用に状態表示用URLの jk-status を有効にしておくと良いでしょう。
- 以下のサンプルのように、Location /jk-status に 適当にアクセス許可を追加しておきます。
- /etc/libapache2-mod-jk/workers.properties
- Management Server #1 と #2 用の定義を行います。マニュアルはここ
http://tomcat.apache.org/connectors-doc/reference/workers.html
から参照できます。 - 私はこんな感じで設定しました。(コメント/空行を除く)
以下に出てくる、jvm1 と jvm2 はTomcat の server.xml の jvmRouteで指定した値とあわせ、振り分け先の Tomcat の分は全部書いておきます。(重要) - Apacheの再起動
- 設定が終わったら Apache を再起動します。
- sudo /etc/init.d/apache2 restart
<Location /jk-status>
JkMount jk-status Order deny,allow Deny from all Allow from all ★ここ
</Location>
workers.tomcat_home=/usr/share/cloud/management ★/var/lib/tomcat6から変更(CATALINA_HOME) workers.java_home=/usr/lib/jvm/default-java ps=/ worker.list=wlb,jk-status worker.jvm1.port=20400 ★通常は 8009 だが、MSの servers.xml にあわせる。 worker.jvm1.host=192.168.174.137 ★ MS #1のIP
worker.jvm1.type=ajp13 worker.jvm1.lbfactor=1 worker.jvm2.port=20400 ★通常は 8009 だが、MSの servers.xml にあわせる。 worker.jvm2.host=192.168.174.129 ★ MS #2のIP worker.jvm2.type=ajp13 worker.jvm2.lbfactor=1 worker.wlb.type=lb worker.wlb.balance_workers=jvm1,jvm2 ★MS 3台なら３台分書きます。 worker.wlb.sticky_session=1 ★スティッキーセッションの有効化 worker.wlb.sticky_session_force=0 worker.jk-status.type=status worker.jk-status.read_only=TRUE ★FALSEにすると worker のON/OFF等の制御も Web UIからできます。
4. mod_jk の管理画面にアクセスしてみる
- 例えば、Apache #１(今回は同居させているので Management Server #1)の http://192.168.174.137/jk-status にアクセスすると、以下のような画面が表示されます。
- ここで、URLにポート指定がなく、Management Server (Tomcat)が待っている tcp 8080 ではなく、Apache/mod_jk が待っている tcp 80 にアクセスしていることに注意してください。
- 画面の中段に、Management Server #1 と #2に対応する worker の jvm1 と jvm2 がそれぞれどんな状態なのか表示されています。ACT と State が、両方とも ACT OK になれば正解です。
- また、最下段に、tcp 80 (8080ではなく）の /client/ にアクセスされた場合の転送設定(JkMount) が表示されています。
- 今回は、Management Server の jsp に以下のような一時的な細工を施し、mod_jk 経由で round robin でアクセスされた場合、どちらのサーバが反応しているのかわかるようにしました。
- /usr/share/cloud/management/webapps/client/index.jsp の <body>部の先頭に、以下のホストの名前をベタ書きする。
<body>
<center><font size=20>
Management Server #1 （または #2）
</font></center>
つづく… - こうしておき、http://192.168.174.137/client/ にアクセスして何度もリロードすると、(ログインしてセッションが発生する前は)以下のように round robin で処理サーバ(Management Server)が切り替わることがわかります。
- また、いったんログインしてしまうと（同じ Apacheにアクセスし続ける限り）Sticky Session の効果で、正しく同じ Management Server (Tomcat)で処理を続けられることがわかります。
ここまでできたら、もう一台 Apache を同じ設定で作成し、Apache側は完成です。
もちろん、mod_jkのもっとチューニングや、static contents の Apache側への配置などは、それはそれで深遠なノウハウがありますし、SSLの終端をApache/mod_sslでやるのか？L7バランサでやるのか、はたまた箱モノでやるのか…など、議論のあるところではありますが、それは別の話。
さて、Apache-Tomcat コネクタの設定が終わった後は、
それではまた！
- Tomcat Clusterの設定
- これによって、Management Server 間でセッション情報を持ちまわれるようになり、どちらかが倒れた時もログインセッションを引き継げます。（はずです）
- フロントのバランサの設定
をするのですが、今日は時間切れということで、次回挑戦してみたいと思います。
＃近日更新予定！
なお、図２は今回説明した範囲を示しています。
いかがでしょうか？
web3層系の知識だけでも、けっこう頑張れるということが分かるかと思います。＃近日更新予定！
なお、図２は今回説明した範囲を示しています。
いかがでしょうか？
それではまた！
No comments:
Post a Comment