Docs : Scaling Puppetで以下を見つけました。
デフォルトの Web サーバーを使用していますか?
Puppet の Web サービス接続を有効にするために使用されるデフォルトの Web サーバーである WEBrick は、基本的にリファレンス実装であり、約 10 個の管理対象ノードを超えると信頼性が低下します。多くのノードを提供するあらゆる種類の本番環境では、Passenger や Mongrel などのより効率的な Web サーバー実装に切り替える必要があります。
「10 の管理対象ノード」の 10 という数字はどこから来たのですか?
20 を少し超えるノードがあり、まもなく 30 を少し超える可能性があります。Passenger に変更する必要がありますか?
WEBrick で問題が発生し始めたら (または少し前に)、Passenger に変更する必要があります。それがいつ起こるかは、ワークロードによって異なります。
WEBrick の最大の問題は、それがシングルスレッドであり、ブロッキングであることです。リクエストの処理を開始すると、最初のリクエストが完了するまで他のリクエストを処理できません。したがって、違いを生むのは、Puppet がリクエストの処理に費やす時間です。
クライアントがカタログを要求するたびに、それが要求になります。URLを介して取得された個々のファイルpuppet:///もリクエストです。Puppet を軽く使用している場合、各カタログの生成に時間がかかりすぎず、特定の Puppet の実行で多くのファイルを配布せず、各クライアントで 4 ～ 6 秒以上のサーバー時間がかかることはありません。毎時。各クライアントが 1 時間あたり 4 秒のサーバー時間を使用する場合、10 個のクライアントで 5% の確率で衝突が発生します 0-- 少なくとも 1 つのクライアントが、別の要求が処理されている間、待機する必要があります。クライアント数が 20 または 30 の場合、その可能性はそれぞれ 19% と 39% です。各リクエストが短い限り、ある程度の競合に耐えることができるかもしれませんが、衝突の確率は急速に上昇するため、たとえば 50 を超えるホスト (75% の衝突確率) を持っている場合は、本当にそうすべきです。あなたが大丈夫であることを示す積極的なパフォーマンス測定を行っていない限り、Passengerを使用してください。
ただし、Puppet マスターをよりハードに使用している場合 (カタログの生成に時間がかかっている、大量のファイルを提供している、大きなファイルを提供しているなど)、すぐに Passenger に切り替える必要があります。WEBrick Puppet マスターを使用して約 30 台のホストを継承しましたが、新しいシステムのデプロイを開始したとき、新しいデプロイによって発生したすべての Puppet トラフィック (数ギガバイトのファイル1を含む) が他のホストを妨げていました。そのため、私は Passenger に切り替えることを余儀なくされました。
要するに、Puppet であまり激しいことをしていなければ、おそらく 30 ノードで問題ありませんが、その時点で、少なくとも Puppet マスターのパフォーマンスと、できればクライアントの更新ステータスも監視する必要があります。であるため、いつ WEBrick の機能を超えて実行を開始したかがわかります。
0これは標準的な誕生日のパラドックス計算です。nがクライアント数で、sが各クライアントが 1 時間に使用するサーバー時間の平均秒数である場合、1 時間に少なくとも 1 回衝突が発生する確率は で与えられます。1-(s/3600)!/((s/3600)^n*((s/3600)-n)!)
1いずれにせよ、Puppet は、このサイズのファイルを配布するための適切な手段ではありません。最終的に、すべてのホストがアクセスできる NFS 共有にそれらを配置することに切り替えました。
20 ～ 30 ノードの場合、問題はありません。passengerいくつかの追加機能を提供することに注意してください。ノードの処理が速くなる可能性がありますが、ノードが 30 個しかない場合にどの程度の改善が得られるかはわかりません。
passenger100 を超えるノードを使用している場合は、に変更する必要があります。puppet-master からサービスを要求しているノードの数が約 200 に達したとき、問題が発生し始めました。私の場合、デフォルトの Web サーバーでは、ノードの約 5% (ランダム) が 1 時間ごとの実行中にカタログを受信できませんでした。