可扩展性 – Scaling Puppet – 什么时候对WEBrick来说太过分了

发布时间：2020-12-16 18:22:18 所属栏目：安全来源：网络整理

导读：我在 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

我在 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个托管节点中的数字10来自哪里？

我有20多个节点,我可能很快就会超过30个.我应该改为乘客吗？

解决方法

当您开始遇到WEBrick(或之前的一段时间)时,您应该更改为Passenger.如果发生这种情况,将取决于您的工作量.

WEBrick最大的问题是它是单线程和阻塞的;一旦它开始处理请求,它就无法处理任何其他请求,直到完成第一个请求.因此,对您有所影响的是Puppet花费多少时间处理请求.

每次客户端询问其目录时,都是请求.通过puppet：/// URL检索的每个单独文件也是一个请求.如果您轻松使用Puppet,每个目录生成时间不会太长,您将不会在任何给定的Puppet运行上分发许多文件,并且每个客户端将不会花费超过四到六秒的服务器时间每隔一小时.如果每个客户端每小时需要4秒的服务器时间,则10个客户端有5％的机会发生冲突0 – 至少有一个客户端必须等待而另一个客户端的请求被处理.对于20或30个客户,这些机会分别为19％和39％.只要每个请求都很短,你就可以忍受一些争用,但是碰撞的几率会很快增加,所以如果你有超过50个主机(75％的碰撞几率)你真的应该通过使用乘客,除非你正在进行积极的表现测量,表明你做得很好.

但是,如果你正在努力工作你的Puppet大师 – 花费更长时间来生成目录,提供大量文件,提供大型文件或其他任何东西 – 你需要尽快切换到Passenger.事情进展顺利,我继承了一组约三十台拥有WEBrick Puppet master的主机,但是当我开始部署新系统时,由新部署(包括几个千兆字节文件1)引起的所有Puppet流量都阻止了其他主机得到他们的更新,所以当我被迫切换到乘客.

简而言之,如果你没有对Puppet做任何过于激烈的事情,你可能会对30个节点没问题,但那时你需要至少监控你的Puppet master的性能,最好是你的客户的更新状态.,所以当你开始超越WEBrick的功能时,你就会知道.

0这是标准的birthday paradox计算;如果n是客户端数量,s是每个客户每小时使用的服务器时间的平均秒数,那么在一小时内至少发生一次冲突的可能性由1-(s / 3600)给出！/(( S / 3600)^ N *((S / 3600)-n)！).

1在任何情况下,Puppet都不是分发这种大小的文件的好方法.我最终切换到将它们放在所有主机都可以访问的NFS共享上.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!