3

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

4

2 回答 2

10

更新

Chef 11 于今年早些时候发布。与该版本一起发布的还有一些新闻稿/案例研究，供 Opscode 合作进行可扩展性测试的公司使用。值得注意的是，Facebook 和 Cycle Computing 使用单个 Chef 服务器管理 10,000 多个节点集群。Chef Server 的规格适中，但未公开。更多信息可在此处获得：

需要注意的是，这适用于 Open Source Chef Server 和 Enterprise Chef。Opscode 的托管企业厨师服务本质上是一个巨大的企业厨师实例，因为它运行基本“相同”的代码库。

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

Chef Wiki 上的这个页面有很多很好的链接和信息：

需要考虑的几点：

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

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

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

  4. Chef 10.x 或 0.10.x 版本使用基于 Ruby 的 API 服务，并将 CouchDB 作为后端数据存储。在 Hosted Chef 的规模上，Opscode 发现了可扩展性问题，这在Seth Falcon 在 ChefConf 2012 的演讲中有所描述。虽然该演讲主要是关于客户数据的真棒实时迁移，但有几点关于 CouchDB 的可伸缩性。此外，Chef 11 将迁移到基于 Erlang 的 API 服务，并将 SQL（MySQL或PostgreSQL）作为后端数据存储。

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

于 2012-10-17T05:05:03.360 回答
1

@jtimberman 总结得很好，您确实可以通过将 Chef 服务拆分到多个单独的节点并投入更多资源来将事情扩展到某个点。

通过数据点，我看到大约 700 个客户端由单个（开源）Chef 10.x 服务器管理，solr 和 couchdb 在不同的节点上。

于 2012-10-17T10:55:19.443 回答