実はPuppetはそれほどスケーラビリティに優れていません。管理する設定の量や、ファイルサーバの転送量などによっても異なりますが、1CPU/2GBメモリのPuppetサーバ1台で、50台から100台のPuppetクライアントを管理するのが限界と言われています。
最終回となる今回は、そんなPuppetのスケーラビリティを向上するためのテクニックについて解説します。
単一構成でのスケーラビリティ向上
Puppetではウェブサーバとして、Rubyに標準で含まれているWEBrickが利用されていますが、これをMongrelに変更することによってパフォーマンスの向上が見込めます。WEBrickの代わりにMongrelを利用する場合は、以下のようにpuppetmasterdのコマンドオプションでservertypeにmongrelを指定するだけです(Mongrelのインストールは別途必要です)。
ただし、Mongrelの場合はSSLの処理ができないため、前段にSSLが処理できるリバースプロキシを配置する必要があります。今回はリバースプロキシとして、Apache + mod_ssl + mod_proxyを利用する場合の設定例をご紹介します。
Mongrelを利用して、前段にApacheを配置した場合の構成例は以下の図のようになります。
この構成で動作させるための設定について解説します。
puppetmasterdの設定
puppetmasterdは特別な設定の必要はありませんが、起動時にservertypeオプションでmongrelを指定するのと、デフォルトのポートである8140はApacheが利用するため、masterportオプションで8140以外のポートを指定する必要があります。
また、デフォルトのWEBrickで起動した場合には、/etc/puppet/ssl/certsに自分自身の証明書が作成されますが、Mongrelで起動した場合には作成されません。したがって、puppetca --generateを実行して、証明書を作成する必要があります。
ここで作成した証明書は、後ほどApacheで利用します。
Apacheの設定
Apacheではまずmod_sslの設定が必要です。最低限必要な設定は、以下の通りです。
また、Apache宛てのリクエストをpuppetmasterdへプロキシするために、mod_proxyの設定を行います。
以上で、Mongrelを利用するための設定は完了です。Apacheを起動して、通常通りにPuppetクライアントを実行して、アクセスできることを確認します。
また、Ruby on Rails + Mongrelでは、Mongrelプロセスを複数起動してパフォーマンスを向上させる、ということが通常行われているようです。同様のことをPuppetでも行うためには、まずは以下のようにpuppetmasterdを複数起動します。
Aapache側ではmod_proxyではなくmod_proxy_balancerを利用して、以下のような設定を行います。
これでApache宛のリクエストが、複数あるpuppetmasterdプロセスのいずれかに振り分けられます。
複数台構成でのスケーラビリティの向上
複数台構成でのスケーラビリティの向上は、基本的には単一構成の場合の最後に解説した、mod_proxy_balancerを利用したやり方と全く同じです。振り分け先が同一ホスト上のpuppetmasterdではなく、リモートホスト上のpuppetmasterdに変わるだけです。ただし、servertypeにmongrelを指定した場合、puppetmasterdは127.0.0.1でみバインドしますので、リモートからアクセスできるように、bindaddressオプションでバインドアドレスを明示的に指定する必要があります。
ただし、「基本的には単一構成の場合と同じ」と書きましたが、SSL証明書の扱いに以下のような問題があります。
- Puppetクライアントが直接リクエストするのはApacheである。
- しかし、初回リクエスト時に実際に署名するのは、Apacheからリクエストをプロキシされる、複数あるPuppetサーバのいずれかである。
- Puppetサーバは初回起動時にCA証明書を各々自動的に作成する。
- したがって、Puppetクライアント毎に証明書のIssuerがバラバラになってしまい、動作に問題が発生する。
これを解決するための方法はいくつか考えられますが、一番簡単な方法は、Puppetサーバ追加時、puppetmasterdを起動する前に、Apacheが動いているホスト上にある、/etc/puppet/ssl/ca以下をすべて新規Puppetサーバにコピーすることです。こうすることで、Apache上にあるCAファイルと同一のものがすべてのPuppetサーバで利用されるため、どのPuppetサーバで署名をしても、Issuerが同一になります。
ただし、この方法には以下のような問題もあります。
- 同じIssuerで、同じシリアル番号なのに、Subjectが異なる証明書ができてしまう。
- 証明書のRevocationが面倒。
こういった問題はありますが、検証してみた限りではPuppetの動作には特に問題はないようです。
Apache以外にも、PoundやNginxを利用する方法についての解説が、Puppet Wikiにありますので、文末の参考URLを参照してみてください。
最後に
Puppetの連載は今回で最後ですが、いかがでしたでしょうか。Puppetを実運用で利用するための基本的な情報はほぼ網羅できたのではないかと思います。今後は、まだまだ英語でも情報が少ない、効率的な運用ノウハウを追求し、またみなさまと情報共有していきたいと思います。
- 参考URL