厨师/木偶与多个configuration服务器

傀儡，你会需要

1. 相同的清单。 这可以通过保持你的清单在版本控制中完成，并在每个服务器上检查出来，你应该这样做。
2. 存储configuration的单个数据库，如果您使用它。 这就像从sqlite的默认值切换到MySQL或PostgreSQL一样简单。 如果需要，您可以使用这些数据库的工具来复制数据库。
3. 来自相同证书颁发机构的所有傀儡长官的证书。 丹博德有我见过的最好的解释。 但是，它可能无法按照您的预期工作。 另外，我不确定这是如何与客户端证书（即/ var / lib / puppet / ssl / ca /​​ signed / * ）。 也许他们的validation总是由单个CA来处理（引入单点故障），或者也许pem文件在由CA签名后分发给每个puppetmaster。

Chef的devise从一开始就是为了所有的后端组件而运行的，因为这是Opscode平台的一个核心function – 一个高度可扩展的托pipeChef Server。

厨师服务器的各种核心组件：

• API服务器
• 数据存储（CouchDB）
• search引擎（SOLR）

因此，这些组件中的每一个都能够在不同的服务器上运行，Chef可以被configuration为为每个组件使用单独的服务器。 有关configuration信息，请参阅Chefconfiguration设置页面。 主要是，couchdb_url和solr_url设置可以指向运行这些组件的独立服务器（或多个服务器），或者指向它们前面的负载平衡器。

厨师服务器API也需要访问可以在共享文件系统中的食谱。

如果您担心单点故障，请创build一个木偶集群:)

1. 使用corosync/pacemaker （或老式心跳）创build群集，使其成为主动/被动，甚至主动/主动
2. 使用DRBD或其他方法获取两个（或更多）服务器的重要数据
3. 利润！

木偶客户端从由DNS标识的木偶服务器获得清单（除非你在客户端指定了一个服务器，但这不是很好），所以你有很多方法来保证你永远不会没有服务器，无论是主动/被动群集，其中如果主动失败，则被动获取IP地址，或者甚至在失败的情况下将DNS条目更改为新的服务器（第一个选项是最优雅的）。

那些日子里，群集的一个很好的资源就是来自clusterlabs的 Scratch集群。 该指南包含DRBDconfiguration示例，因此非常有帮助。