主页 / server / 问题 / 433697
Accepted
Kyle Brandt
Asked: 2012-10-02 07:40:46 +0800 CST

Puppet 的多站点高可用性选项

  • 772

我维护着两个数据中心，随着我们越来越多的重要基础设施开始通过 puppet 进行控制，如果我们的主站点出现故障，那么 puppet master 在第二个站点的工作就很重要了。

更好的办法是进行某种主动/主动设置，这样第二个站点的服务器就不会通过 WAN 进行轮询。

是否有任何标准的多站点人偶高可用性方法？

puppet

2 个回答

  1. Best Answer

    Puppet 实际上非常适合多主机环境，但需要注意。主要的？ Puppet 的很多部分都喜欢集中化。 证书颁发机构、库存和仪表板/报告服务、文件存储和存储的配置——所有这些都在（或只是需要）一个只有一个地方供他们交谈的设置中处于最佳状态。

    但是，如果您可以接受在失去主站点时优雅地失去一些功能，那么让许多这些移动部件在多主环境中工作是非常可行的。

    让我们从获取节点向主节点报告的基本功能开始：

    模块和清单

    这部分很简单。对它们进行版本控制。如果它是一个分布式版本控制系统，那么只需集中和同步，并根据故障转移站点中的需要更改您的推/拉流程。如果它是 Subversion，那么您可能希望svnsync将回购到您的故障转移站点。

    证书颁发机构

    这里的一种选择是简单地在主节点之间同步证书颁发机构文件，以便所有节点共享相同的根证书并能够签署证书。这一直让我觉得“做错了”；

    • 一个主人真的应该看到自己的证书在客户端身份验证中显示为来自另一个主人的传入连接有效吗？
    • 这会可靠地用于库存服务、仪表板等吗？
    • 您如何在以后添加其他有效的 DNS 替代名称？

    老实说，我不能说我已经对此选项进行了彻底的测试，因为它看起来很糟糕。然而，根据此处的说明，Puppet Labs 似乎并不鼓励这种选择。

    所以，剩下的就是拥有一个中央 CA 主机。当 CA 关闭时，所有信任关系仍然有效，因为所有客户端和其他主服务器都缓存了 CA 证书和 CRL（尽管它们不会按应有的频率刷新 CRL），但您将无法签署新证书，直到您可以备份主站点或从故障转移站点的备份中恢复 CA 主机。

    您将选择一个 master 作为 CA，并让所有其他 master 禁用它：

    [main]
    ca_server = puppet-ca.example.com
[master]
    ca = false

    然后，您会希望该中央系统获得所有与证书相关的流量。有几种选择；

    1. 使用 3.0 中的新SRV记录支持将所有代理节点指向 CA 的正确位置 -_x-puppet-ca._tcp.example.com
    2. 在所有代理中设置ca_server配置选项puppet.conf

    3. 将所有来自代理的 CA 相关请求的流量代理到正确的主服务器。例如，如果您通过 Passenger 在 Apache 中运行所有主节点，则在非 CA 上进行配置：

      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.

    而且，应该这样做。

    在我们继续进行辅助服务之前，请注意；

    主证书的 DNS 名称

    我认为这就是迁移到 3.0 的最有说服力的理由。假设您想将一个节点指向“任何 ol' working master”。

    在 2.7 下，您需要一个通用的 DNS 名称，例如puppet.example.com，并且所有高手的证书中都需要这个。这意味着dns_alt_names在他们的配置中进行设置，重新颁发他们在被配置为主服务器之前拥有的证书，当您需要将新的 DNS 名称添加到列表中时再次重新颁发证书（就像您想要多个 DNS 名称一样）让代理商更喜欢他们网站上的主人）..丑陋。

    使用 3.0，您可以使用SRV记录。给你所有的客户这个；

    [main]
    use_srv_records = true
    srv_domain = example.com

    然后，大师不需要特殊证书 - 只需将新记录添加到您的SRVRR_x-puppet._tcp.example.com就可以了，它是组中的现场大师。更好的是，您可以轻松地使主选择逻辑更加复杂；通过为不同站点设置不同的SRV记录集，“任何 ol' working master，但更喜欢您站点中的那个”；不需要dns_alt_names。

    报告/仪表板

    这一个最集中，但如果您在主站点关闭时可以没有它，那就没问题。只需将您所有的主人配置为放置报告的正确位置。

    [master]
    reports = http
    reporturl = https://puppetdash.example.com/reports/upload

    ..你都准备好了。上传报告失败对于配置运行来说不是致命的；如果仪表板服务器吐司，它就会丢失。

    事实清单

    粘在仪表板上的另一件好事是库存服务。按照文档中的建议facts_terminus设置rest为，这实际上会在中央库存服务关闭时中断配置运行。这里的技巧是inventory_service在非中央主机上使用终端，这允许优雅的失败。

    facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140

    将您的中央库存服务器设置为通过 ActiveRecord 或 PuppetDB 存储库存数据，并且只要服务可用，它就应该保持最新。

    所以 - 如果你可以接受一个漂亮的准系统配置管理环境，在这个环境中你甚至不能使用 CA 来签署一个新节点的证书，直到它被恢复，那么这可以工作得很好 - 虽然它真的很好如果其中一些组件对分发更友好一些。

    • 15

  2. Ladadadada 描述的“无主傀儡”方法是我最熟悉的方法（这基本上是我们在公司使用 radmind 所做的）。我猜更准确地说，它是“由外部进程同步的多个主机”，其中任何给定的服务器都可以（理论上）在紧急情况下为我们的整个宇宙提供服务。

    在我们的例子中，由于 radmind 的性质，我们只是rsync将副本和数据文件从经过批准的主服务器发送到每个远程站点的 radmind 服务器，并且客户端从具有短主机名的服务器中提取他们的更新radmind（通过resolv.conf这个评估的魔力radmind.[sitename].mycompany.com- 总是本地的radmind 服务器。如果本地服务器出现故障，很容易覆盖并指向任何其他站点的服务器）。

    这种 rsync 过程也可能适用于您的情况，但与基于版本控制的解决方案相比，它可能不是最佳选择。

    对于 puppet 或 chef，基于版本控制的系统比简单的 rsync 更有意义，原因有几个——最重要的是你是版本控制的 puppet 脚本（而不是像 radmind 那样的整个操作系统映像）。
    作为基于版本控制的管理的附加好处，您可以同时让多个人在存储库上工作（并行性的巨大胜利），您基本上免费获得修订历史记录，如果有人破坏了 Puppet 环境，您可以轻松回滚（假设您'重新使用git你也有git blame它在罐子上说的）。
    创造性的分支和合并甚至可以让你在版本控制框架内处理主要的操作系统升级或其他转换——一旦你做对了，只需切换到新分支，（希望）生产推送就能正常工作。

    如果我在这里实现这个，我可能会利用 git 中的预提交和提交后挂钩来确保提交的人偶配置是健全的（客户端预），如果他们将它们推送到宇宙的其余部分是（服务器端发布——如果您的部署策略允许此类行为，也可能触发环境更新）。

    在每个站点启动新的 puppetmaster 服务器方面，您可以简单地检查每个远程 puppetmaster 的 puppet 环境，并使用我上面描述的 resolv.conf/hostname hackery 或重定向到本地系统的任播服务 IP，如 Michuelnik 建议的（如果您希望在某个站点的 puppetmaster 崩溃时自动进行故障转移，后者会很方便）以确保每个站点都能看到“正确的”puppetmaster，并且不会阻塞您试图获取更新的 WAN 链接。

    Brain Tree Payments 的人们显然已经将版本控制和 rsync 解决方案与一些自定义 Capistrano 任务结合在一起——他们的解决方案似乎是半生不熟的，因为它仍然依赖于手动工作流元素，但它可以在没有太多的工作。
    我这个偏执狂的强迫性测试人员喜欢他们的noop完整性检查步骤——我这个讨厌手动过程的人希望围绕它进行某种程度的自动化……

    • 8

相关问题