scalability - Scaling Puppet - 什么时候对 WEBrick 来说太多了？

Question

我在 Docs: Scaling Puppet 找到了以下内容:

Are you using the default webserver?

WEBrick, the default web server used to enable Puppet’s web services connectivity, is essentially a reference implementation, and becomes unreliable beyond about ten managed nodes. In any sort of production environment serving many nodes, you should switch to a more efficient web server implementation such as Passenger or Mongrel.

“十个受管节点”中的数字 10 来自哪里？
我有 20 个多一点的节点，我可能很快就会有 30 个多一点。我应该更改为 Passenger 还是不？

Answer 1

当您开始遇到 WEBrick 问题时(或稍早一些)，您应该更改为Passenger。当这种情况发生时，您将取决于您的工作量。

WEBrick 最大的问题是它是单线程和阻塞的；一旦它开始处理一个请求，它就不能处理任何其他请求，直到它完成第一个请求。因此，对您产生影响的是 Puppet 花多少时间处理请求。

每次客户要求其目录时，这就是一个请求。通过 puppet:/// URL 检索的每个单独文件也是一个请求。如果您轻率地使用 Puppet，那么生成每个目录不会花费太长时间，您不会在任何给定的 Puppet 运行中分发许多文件，并且每个客户端不会花费超过四到六秒的服务器时间每隔一小时。如果每个客户端每小时占用 4 秒的服务器时间，则 10 个客户端有 5% 的机会发生冲突 - 至少有一个客户端在处理另一个请求时必须等待。对于 20 或 30 个客户，这些机会分别为 19% 和 39%。只要每个请求都很短，您就可以忍受一些争用，但冲突的几率会迅速增加，因此如果您有超过 50 个主机(75% 的冲突几率)，您真的应该通过使用Passenger，除非您正在进行积极的性能测量，表明您做得很好。

但是，如果您更努力地工作 Puppet master——需要更长的时间来生成目录、提供大量文件、提供大文件或其他任何东西——你需要尽快切换到乘客。我继承了一组大约 30 台带有 WEBrick Puppet master 的主机，一切正常，但是当我开始部署新系统时，新部署引起的所有 Puppet 流量(包括几个千兆字节的文件1)都在阻止其他主机得到他们的更新，所以那是我被迫切换到乘客的时候。

简而言之，如果您不使用 Puppet 做任何过于激烈的事情，那么您可能会接受 30 个节点，但此时您至少需要监控 Puppet master 的性能，最好也监控客户端的更新状态，所以当您开始运行超出 WEBrick 的功能时，您就会知道。

0 这是标准的 birthday paradox 计算；如果 n 是客户端的数量，s 是每个客户端每小时使用的服务器时间的平均秒数，那么在一小时内至少发生一次碰撞的机会由 1-(s/3600)!/((s/3600)^n*((s/3600)-n)!) 给出。

1 Puppet 在任何情况下都不是分发这种大小文件的好途径。我最终转而将它们放在所有主机都可以访问的 NFS 共享上。