起搏器生态系统（Corosync等）在EC2的背景下是否有意义？ 直到某一点，Corosync需要IP组播（EC2上不可用），但我认为它已经播出。 还有，Pacemaker et。 人。 集群在EC2上pipe理自己的正确工具，例如监视对方的失败，从而触发提供新的实例来replace失败的实例？ 我猜这个问题的一部分是，我花了不less时间把这里的所有玩家（心跳，Corosync，OpenAIS等等）都弄清楚了，而且我还在试图弄清楚这些东西实际上是什么（除了模糊的术语，例如，Pacemaker是一个“集群资源pipe理器”，Corosync提供“可靠的消息和会员基础设施”）。 因此，如果我的问题本身有点笨拙或不完全有道理，我们表示歉意。 任何见解将不胜感激。 谢谢。
每个数据中心都有一对CentOS Linux服务器。 他们在每个数据中心都有故障切换，由心跳和DRBDpipe理（我知道这些都是过时的工具，但是它们是稳定的，所以不需要改变它们）。 它们也具有数据中心交换的能力，使东部数据中心处于活动状态，而西部变为被动状态。 但这是一个手动工程过程，没关系。 西数据中心目前是主动数据中心，东数据中心是被动的。 serverA.west <-> serverB.west <———–> serverA.east <-> serverB.east ACTIVE DATA CENTER PASSIVE DATA CENTER 服务器可以运行mysqld和一个Java应用程序。 此服务器上的Java应用程序只应在活动数据中心（即serverA.west）的主要主机上运行。 如果Java应用程序的另一个实例在辅助主机（serverB.west）上启动，或者在被动数据中心的任一主机上启动，则存在裂脑问题的风险。 今天serverA.east重新启动，导致心跳翻转到serverB.east。 心跳然后忠实地启动了serverB.east上的Java应用程序，我们不希望发生这种情况。 Heartbeat也在serverB.east上启动了mysqld，这是正确的，因为MySQL复制应该继续下去，连续复制来自西部数据中心的变化，以便东部DC在需要时可以接pipe。 /etc/ha.d/haresources将mysqld和Java应用程序的/etc/init.d脚本命名为要启动的资源。 我们希望允许心跳来pipe理被动数据中心中的A / B对。 它应该在故障转移时启动mysqld，但不启动Java应用程序。 但是，如果东数据中心是活动的，那么在心跳自动故障转移期间，心跳应该启动Java应用程序。 什么是实施这个好方法？ 我所希望的是，当我们将活动数据中心从西方切换到东方时，需要采取一个步骤进行configuration。 理想情况下，它应该是防错的，也就是说，应该确保只有一个数据中心被configuration为活动数据中心。
我之前做过这样的设置，没有任何问题。 现在我不能做“crmconfiguration”，因为在当前的包中没有可用的crm命令。 我错过了什么吗？ 也许它被其他方式/命令取代？ [root@node1 src]# find / -name crm*|grep bin /usr/sbin/crm_mon /usr/sbin/crmadmin /usr/sbin/crm_error /usr/sbin/crm_shadow /usr/sbin/crm_ticket /usr/sbin/crm_failcount /usr/sbin/crm_resource /usr/sbin/crm_master /usr/sbin/crm_diff /usr/sbin/crm_attribute /usr/sbin/crm_node /usr/sbin/crm_simulate /usr/sbin/crm_standby /usr/sbin/crm_verify /usr/sbin/crm_report
我的服务器繁忙接口上有很好的大型服务器级网卡。 不久我就要build立一个集群，将有一个专门的热拍。 我真的需要使用昂贵的服务器级网卡吗？ 或者将一个低端桌面网卡足够？
我有一个两节点群集心跳和DRBDpipe理一个MySQL资源。 如果我暂停主服务器，重新启动服务器或断开networking连接，则故障切换会很好。 但是，如果主服务器遇到内核恐慌（通过运行echo c > /proc/sysrq-trigger模拟），则辅助服务器不会echo c > /proc/sysrq-trigger资源。 这是次要的心跳日志看起来像： Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead. Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device] Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION […]
我们利用心跳进行高可用性。 我想添加一个额外的IP地址到心跳群集，但是我不想在这个过程中完全重启群集。 是否有一个信号可以发送给心跳，会提示它重新parsing“haresources”文件并对其执行操作？ 心跳-r似乎没有办法。
我正在寻找像使用Heartbeat / Squid / Varnish / etc等来平衡内部apache实例之间的传入stream量。 这必须是软件，而不是硬件，因为我所有的东西都运行在VPS上。 我在这个领域没有太多的经验，所以如果我滥用术语，选错了软件包，我会感到抱歉。 我已经绘制了一些东西来说明我所追求的。 绿色的一面是初始设置的样子，蓝色的一面是增加更多的Apache实例后，由于stream量增加可能看起来像什么。 这可能不是如何工作，但理想情况下，我会将平衡器的IP添加到域的DNS。 然后平衡器会看到每个apache实例上有多less个连接（通过内部IP或永久IP的某个configuration列表），并平均分配连接。 在蓝色有第二个平衡器，因为我相信在某些时候平衡器也需要帮助。 也许我正在讨论这个错误，但是我正在寻找关于“平衡器”应该是什么的帮助以及如何设置它们的最佳实践。 任何帮助将是伟大的。
在pipe理自己的群集（即不使用/支付Amazon Autoscale，Rightscale，Scalr等）的人员中，您如何pipe理EC2上的实例并处理（例如）故障转移？ 我想知道是否大多数人最终只是写了自己的EC2 API的脚本，正如我怀疑的那样。 这当然是我们的方法：掀起我们自己的基于Python的基于Boto的监控/重新启动后台程序，在异地运行，监听来自我们实例的UDP保持活动。 失败时，我们快照卷，注册图像，启动新实例，删除旧卷等等。 每当我们经常在对脚本进行黑客攻击的时候，我认为必须有一些开源的工具来处理这些问题，并且没有Scalr的限制，但是我总是从Google两手空空。 （像Scalr这样的软件在受支持的软件集/版本/configuration方面相当有限，并且具有专门和IMO笨重的操作这些设置的方法。） 另外，Linux-HA / Pacemaker生态系统（Heartbeat，ldirectord等）听起来并不适合EC2 。 （但后来我发现这一点 – 虽然我不确定这是否是一个高质量的解决scheme）。
我想构build一个高可用性的服务器集群。 现在我想知道关于keepalive和heartbeat的细节，两者有什么区别，以及如何select一个。
刚刚完成我的研究，build立一个Web服务器群集，我还没有决定哪个消息层与Pacemaker一起使用。 我使用的服务器都是Fedora，所以这两个层都可以通过YUM获得，两者都有很好的文档logging，据说可以和Pacemaker一起使用。 我无法find的是哪一个更好的意见。 有没有人有这两种经验，也有偏好哪一个更好？ 有一个更大的社区支持基地吗？ 另一个更稳定吗？ 或者这是一个武断的决定？