オープンソースなシステム自動管理ツール Puppet

第18回Puppetのスケーラビリティ向上テクニック

実はPuppetはそれほどスケーラビリティに優れていません。管理する設定の量や、ファイルサーバの転送量などによっても異なりますが、1CPU/2GBメモリのPuppetサーバ1台で、50台から100台のPuppetクライアントを管理するのが限界と言われています。

最終回となる今回は、そんなPuppetのスケーラビリティを向上するためのテクニックについて解説します。

単一構成でのスケーラビリティ向上

Puppetではウェブサーバとして、Rubyに標準で含まれているWEBrickが利用されていますが、これをMongrelに変更することによってパフォーマンスの向上が見込めます。WEBrickの代わりにMongrelを利用する場合は、以下のようにpuppetmasterdのコマンドオプションでservertypeにmongrelを指定するだけです(Mongrelのインストールは別途必要です⁠⁠。

# puppetmasterd --servertype mongrel

ただし、Mongrelの場合はSSLの処理ができないため、前段にSSLが処理できるリバースプロキシを配置する必要があります。今回はリバースプロキシとして、Apache + mod_ssl + mod_proxyを利用する場合の設定例をご紹介します。

Mongrelを利用して、前段にApacheを配置した場合の構成例は以下の図のようになります。

Apache+Mongrelの単一構成例
Apache+Mongrelの単一構成例

この構成で動作させるための設定について解説します。

puppetmasterdの設定

puppetmasterdは特別な設定の必要はありませんが、起動時にservertypeオプションでmongrelを指定するのと、デフォルトのポートである8140はApacheが利用するため、masterportオプションで8140以外のポートを指定する必要があります。

# puppetmasterd --servertype mongrel --masterport 18140

また、デフォルトのWEBrickで起動した場合には、/etc/puppet/ssl/certsに自分自身の証明書が作成されますが、Mongrelで起動した場合には作成されません。したがって、puppetca --generateを実行して、証明書を作成する必要があります。

# puppetca --generate puppet.example.com

ここで作成した証明書は、後ほどApacheで利用します。

Apacheの設定

Apacheではまずmod_sslの設定が必要です。最低限必要な設定は、以下の通りです。

LoadModule ssl_module modules/mod_ssl.so
Listen 8140

SSLEngine on

SSLCertificateFile    /etc/puppet/ssl/certs/puppet.example.com.pem
SSLCertificateKeyFile /etc/puppet/ssl/private_keys/puppet.example.com.pem
SSLCACertificateFile  /etc/puppet/ssl/ca/ca_crt.pem

SSLVerifyClient optional

SSLOptions +StdEnvVars

RequestHeader set X-Client-DN     %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

また、Apache宛てのリクエストをpuppetmasterdへプロキシするために、mod_proxyの設定を行います。

ProxyPass        / http://127.0.0.1:18140/
ProxyPassReverse / http://127.0.0.1:18140/

以上で、Mongrelを利用するための設定は完了です。Apacheを起動して、通常通りにPuppetクライアントを実行して、アクセスできることを確認します。

# puppetd --server puppet.example.com --verbose --test

また、Ruby on Rails + Mongrelでは、Mongrelプロセスを複数起動してパフォーマンスを向上させる、ということが通常行われているようです。同様のことをPuppetでも行うためには、まずは以下のようにpuppetmasterdを複数起動します。

# puppetmasterd --servertype mongrel --masterport 18140 --pid /var/puppet/run/puppetmasterd.18140.pid
# puppetmasterd --servertype mongrel --masterport 18141 --pid /var/puppet/run/puppetmasterd.18141.pid
# puppetmasterd --servertype mongrel --masterport 18142 --pid /var/puppet/run/puppetmasterd.18142.pid

Aapache側ではmod_proxyではなくmod_proxy_balancerを利用して、以下のような設定を行います。

SetHandler balancer-manager

ProxyPass        / balancer://puppetmaster/
ProxyPassReverse / balancer://puppetmaster/

<Proxy balancer://puppetmaster>
  BalancerMember http://127.0.0.1:18140
  BalancerMember http://127.0.0.1:18141
  BalancerMember http://127.0.0.1:18142
</Proxy>

これでApache宛のリクエストが、複数あるpuppetmasterdプロセスのいずれかに振り分けられます。

複数台構成でのスケーラビリティの向上

複数台構成でのスケーラビリティの向上は、基本的には単一構成の場合の最後に解説した、mod_proxy_balancerを利用したやり方と全く同じです。振り分け先が同一ホスト上のpuppetmasterdではなく、リモートホスト上のpuppetmasterdに変わるだけです。ただし、servertypeにmongrelを指定した場合、puppetmasterdは127.0.0.1でみバインドしますので、リモートからアクセスできるように、bindaddressオプションでバインドアドレスを明示的に指定する必要があります。

# puppetmasterd --servertype mongrel --bindaddress 0.0.0.0
Apache+Mongrelの複数台構成例
Apache+Mongrelの複数台構成例

ただし、⁠基本的には単一構成の場合と同じ」と書きましたが、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以外にも、PoundNginxを利用する方法についての解説が、Puppet Wikiにありますので、文末の参考URLを参照してみてください。

最後に

Puppetの連載は今回で最後ですが、いかがでしたでしょうか。Puppetを実運用で利用するための基本的な情報はほぼ網羅できたのではないかと思います。今後は、まだまだ英語でも情報が少ない、効率的な運用ノウハウを追求し、またみなさまと情報共有していきたいと思います。

参考URL

おすすめ記事

記事・ニュース一覧