我维护两个数据中心，而且随着更多的重要基础设施开始通过傀儡控制，如果我们的主站点发生故障，那么在第二站点的木偶大师工作就显得非常重要。
更好的办法是进行一种主动/主动设置，以便第二个站点上的服务器不在WAN上进行轮询。
有没有任何标准的多站点木偶高可用性方法？
木偶实际上适合多主环境，但有一些注意事项。 主要的？ 很多木偶的部分喜欢集中。 证书颁发机构，库存和仪表板/报表服务，文件包装和存储configuration – 所有这些都是他们最好的（或者只是要求）一个设置，只有一个地方让他们谈话。
但是，如果在丢失主站点的情况下某些function正常丢失，那么获得大量在多主站环境中运行的移动部件是非常可行的。
让我们从基本function开始，让一个节点向一个主站报告：
这部分很简单。 版本控制他们。 如果是分布式版本控制系统，那么只需集中和同步，并根据需要在故障转移站点中更改推送/拉出stream程。 如果它是Subversion，那么你可能会希望将repo同步到你的故障转移站点。
这里的一个select是简单地在主服务器之间同步证书颁发机构文件，这样所有的人都可以共享相同的根证书并且能够签名证书。 这一直让我感到“做错了”;
我不能诚实地说，我已经做了彻底的testing这个选项，因为它看起来很可怕。 然而，木偶实验室似乎并不想鼓励这个选项，根据这里的说明。
那么，剩下的就是拥有一个中央CA主人。 所有信任关系在CAclosures时仍然有效，因为所有客户端和其他主服务器都cachingCA证书和CRL（尽pipe它们不会像应该那样频繁刷新CRL），但是您将无法签署新的证书您将从主站点备份或从故障切换站点的备份还原CA主站点。
您将select一位主人充当CA，并让所有其他主人员将其禁用：
[main] ca_server = puppet-ca.example.com [master] ca = false
然后，你需要这个中央系统来获得所有与证书相关的stream量。 这有几个select，
SRVlogging支持将所有代理节点指向CA的正确位置 – _x-puppet-ca._tcp.example.com puppet.conf中设置ca_serverconfiguration选项 将来自代理的CA相关请求的所有stream量代理到正确的主服务器上。 例如，如果您通过Passenger在Apache中运行所有主人，则在非CA上configuration：
SSLProxyEngine On # Proxy on to the CA. ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1 # Caveat: /certificate_revocation_list requires authentication by default, # which will be lost when proxying. You'll want to alter your CA's auth.conf # to allow those requests from any device; the CRL isn't sensitive.
而且，这应该做到这一点。
在我们开始配套服务之前，请注意一下。
我认为这就是移到3.0的最有说服力的理由。 假设你想指向一个节点“任何醇”工作主“。
在2.7以下，你需要一个通用的DNS名称，比如puppet.example.com ，所有的主人都需要在他们的证书中使用这个名字。 这意味着在他们的configuration中设置dns_alt_names ，重新颁发他们configuration为主服务器之前拥有的证书，当您需要添加一个新的DNS名称到列表中时重新发布证书（例如，如果您想要多个DNS名称有代理人喜欢在他们的网站的主人）..丑陋。
使用3.0，您可以使用SRVlogging。 给你所有的客户，
[main] use_srv_records = true srv_domain = example.com
然后，主人不需要任何专门的证书 – 只需在_x-puppet._tcp.example.com添加一条新logging到您的SRV RR，然后您就可以开始设置，这是组中的现场_x-puppet._tcp.example.com 。 更好的是，您可以轻松地使主select逻辑更复杂; “任何职业大师，但更喜欢你的网站”，通过为不同的网站设置不同的SRVlogging集; 没有dns_alt_names需要。
这一个最好的集中，但如果你可以生活没有它，当你的主站点下来，那么没有问题。 只要configuration所有的主人与正确的地方把报告..
[master] reports = http reporturl = https://puppetdash.example.com/reports/upload
..你们全都定了。 无法上传报告对于configuration运行而言是非致命的; 如果仪表板服务器吐司，它就会丢失。
另一个好东西粘在仪表板是库存服务。 如文档中build议的那样，将facts_terminus设置为rest ，这实际上会在中央清单服务closures时中断运行configuration。 这里的诀窍是在非中央主数据库上使用inventory_serviceterminal，这可以实现优美的失败。
facts_terminus = inventory_service inventory_server = puppet-ca.example.com inventory_port = 8140
让您的中央库存服务器设置为通过ActiveRecord或PuppetDB存储清单数据，并且每当服务可用时，它应该保持最新。
所以 – 如果你可以下到一个漂亮的准系统configurationpipe理环境，你甚至不能使用CA来签署一个新节点的证书，直到它恢复，那么这可以工作得很好 – 虽然它会很好如果这些组件中的一些对分发更友好一些。
Ladadadada所描述的“无主傀儡”的方法是我最熟悉的（这基本上就是我们公司所做的）。 我更准确地说，它是“多个主同步的外部过程”，任何给定的服务器可以（理论上）在紧急情况下服务于我们的整个宇宙。
在我们的例子中，由于radmind的性质，我们只需将同步主机的成绩单和数据文件rsync同步到每个远程站点的radmind服务器，并且客户机使用短主机名radmind从服务器获取更新（通过resolv.conf的魔术来评估radmind.[sitename].mycompany.com – 永远是本地的radmind服务器，如果本地服务器停机，很容易覆盖并指向任何其他站点的服务器）。
这种rsync过程也可能适用于您的情况，但与基于版本控制的解决scheme相比，这可能是次优的。
对于傀儡或者厨师来说，基于版本控制的系统比简单的rsync更有意义，其中最重要的一点就是版本控制木偶脚本（而不是完整的操作系统映像，就像使用radmind一样）。
作为基于版本控制的pipe理的附加好处，您可以同时有多个人在存储库上工作（对于并行性来说是一个巨大的胜利），您可以免费获得修订历史logging，如果有人打破了Puppet环境，则可以轻松回滚（假设您“重新使用git你也有git blame ，它在锡上说了什么）。
创意分支和合并甚至可以让您在版本控制框架内处理主要的操作系统升级或其他转换 – 只要切换到新的分支，并且（希望）生产推动将正常工作。
如果我在这里实现这个function，我可能会利用git中的pre-commit和post-commit挂钩来确保提交的puppetconfiguration是合理的（客户端pre），并将它们推送到宇宙的其余部分（服务器端后 – 如果您的部署策略允许这样的行为可能也触发环境更新）。
关于在每个站点build立新的puppetmaster服务器，你可以简单地检查每个远程puppetmaster的puppet环境，并使用上面描述的resolv.conf / hostname hackery或者redirect到Michuelnik这样的本地系统的anycast服务IP后者是方便的，如果你想自动故障转移，如果一个网站的傀儡大师爆炸），以确保每个网站看到“正确的”puppetmaster，并不阻塞你的WAN链接试图获取更新。
Brain Tree Payments的人员显然将版本控制和rsync解决scheme与一些自定义的Capistrano任务结合在一起 – 他们的解决scheme似乎是半熟的，因为它仍然依赖于手动工作stream程元素，但是它可以被调整和自动化太多工作。
我偏执的强迫testing者对他们的noop健康检查步骤很喜欢 – 我的手动过程希望在其周围有一定程度的自动化。