chef-infra - 我可以使用 Chef 服务器的一个实例管理多少个节点？

Question

我正在配置一个 Chef 服务器，并期望通过该服务器管理超过 500 个节点 - 可能接近 1000 个。我可以期望在 EC2 上的超大型实例上有效地工作吗？我应该考虑在单独的服务器上运行rabbitmq、solr等吗？是否可以在分布式设置中运行 Chef 服务器本身？

Answer 1

更新

《Chef 11》于今年早些时候发布。与该版本一起发布的还有一些与 Opscode 合作进行可扩展性测试的公司的新闻稿/案例研究。值得注意的是，Facebook 和 CycleComputing 使用单个 Chef 服务器管理了 10,000 多个节点集群。 Chef 服务器的规范并不高，但尚未公开。更多信息请参见此处:

• Chef 11 announcement
• Facebook announcement
• Phil Dibowitz, Facebook, spotlight
• Phil's talk at ChefConf
• Cycle Computing case study

值得注意的是，这适用于开源 Chef 服务器和企业 Chef。 Opscode 的托管 Enterprise Chef 服务本质上是一个巨大的 Enterprise Chef 实例，因为它运行基本上“相同”的代码库。

(不完全一样，因为 Opscode 具有运行可公开访问的 SaaS 平台(允许多个客户付费和使用)所需的自定义功能和附加服务。)

Chef Wiki 上的此页面有很多很好的链接和信息:

• http://wiki.opscode.com/display/chef/Scalability+and+High+Availability

需要考虑的一些要点:

1. 重要的指标不是节点数量，而是随着您预期的时间收敛的节点数量。例如，每天运行一次 Chef 的 500 个节点比每 10 分钟运行一次 Chef 的 50 个节点在服务器上的负载要少。当然，每 10 分钟(甚至 30 分钟，常见的间隔时间)运行一次 Chef 的 500 个节点对系统来说是很大的负载。

2. Chef Server 被设计为分布式系统，因此组件可以在单独的节点上运行。正是如此Opscode Hosted Chef和 Opscode Private Chef工作 - 各种服务在单独的系统上运行以分配负载。如果您期望有很多节点经常运行 Chef，那么您绝对应该在单独的系统上运行这些服务。 Chef Configuration Settings wiki 页面描述了服务的配置选项。

3. 高可用性和可扩展性不是一回事，需要不同的方法。它们之间的差异完全超出了 Chef 的范围。不过，“Scalability and High Availability ”页面应该会有所帮助。

4. Chef 10.x 或 0.10.x 版本使用基于 Ruby 的 API 服务，并使用 CouchDB 作为后端数据存储。在 Hosted Chef 的规模上，Opscode 发现了可扩展性问题，如 Seth Falcon's talk at ChefConf 2012 中所述。 。虽然该演讲主要是关于客户数据的出色实时迁移，但还有几个关于 CouchDB 的可扩展性的要点。另外，Chef 11 will be migrated to an Erlang-based API service和 SQL(MySQL 或 PostgreSQL)作为后端数据存储。

5. 更新 开源 Chef Server 的 Chef 11 版本需要对 Erlang 中的服务器 API 服务进行完全重写，如前所述。本答案顶部的信息通过案例研究和讲座，让您更深入地了解这一切的含义。