问题标签 [high-availability]

你能帮我理解Linux HA吗？

• Pacemaker、Heartbeat、Corosync 似乎是整个 HA 堆栈的一部分，但它们如何组合在一起呢？
• wackamole 与 Pacemaker/Heartbeat/Corosync 有何不同？我看到有人认为 wackamole 比 Heartbeat 更好，因为它是基于对等的。那有效吗？
• wackamole 的最后一次发布是 2.5 年前。它是否仍在维护或活跃？
• 对于 Web/应用程序/数据库服务器的 HA 设置，您有什么建议？

我有一个 linux 进程，但有时我会进行一些核心转储。

简单的问题：是否有任何方法/方法/程序/任何能够重新启动被杀死的进程的方法？

谢谢。

云计算的强大功能给我留下了深刻的印象，因为它可以根据负载来扩大和缩小设施的规模。

我怎样才能改变我的范式并学会以这种方式编写我的应用程序？写一次然后忘记（无论未来的负载如何）将是最好的解决方案。

我该如何练习我在该领域的技能？当我可以通过一些智能算法将另一个虚拟机添加到私有云（通过命令行？）以预测一段时间的负载时，设置虚拟化环境？

理想情况下，我想在不购买实际云计算服务的情况下仅在我的硬件上进行练习。

我唯一想在这里练习的是应用程序/Web 角色和/或消息队列系统在当前工作人员在队列中有太多工作时扩展。因此，让我们从问题的目标中排除数据库扩展作为太大的话题。

在构建以高可用性为目标的 ASP.NET MVC 应用程序时，如果没有可用的状态服务器，将会话状态保留在 SQL Server 上是否是一种好习惯？

我在云环境中有一个节点，现在用作 nginx 和它后面的 mongrels。

这是 nginx 配置的样子：

我想实现以下目标：

1. 添加另一个节点
2. nginx 必须自动知道这个新节点而不停止他，更改配置（手动添加新节点的杂种）并重新启动它。

我怎样才能让我的负载均衡器（nginx）以这种方式工作，以便它可以自我感知云中的节点？

我正在为我们基于 EC2 的集群编写一个监控服务，它的任务将是 [通过 HTTP/S 连接到我们的事件服务器每个 X(ms)，验证它们是否还活着，休息]。

我需要一个能够自行执行 Connect 测试并报告成功或失败的工具包。我曾尝试使用Apache HTTPClient来做到这一点，但我在没有发生的故障上得到了太多误报。我还查看了 JMeter，它起初看起来很有希望，但在下载了一个 15mb 的文件和大约 25 个 3rd 方 jar 之后开始感觉像是一个巨大的矫枉过正。

要求很简单：检查测试节点是否在定义的时间范围内对 HTTP GET 请求做出正确回复。

你能推荐一个允许这项服务的图书馆吗？将误报率保持在最低限度是至关重要的，因为嗯......这意味着我们的处理会停止，直到检查到一个损坏的节点......（确实是不可以:)

谢谢你，马克西姆。

假设我有一个应用程序，即使在优化之后也能保证压倒一台服务器。有没有一种技术可以让 Web 应用程序在保持其状态的同时拆分到多个服务器上？

以多人在线游戏为例。通常在 World of Warcraft 中有多个服务器，每个服务器都有自己的游戏状态。我正在寻找的是允许这个游戏状态在多个服务器之间共享的东西。

编辑：平台并不重要，因为这是针对 Web 应用程序的，因此后端并不重要。但是，Rails 和 Java 是可能的。

另外，魔兽只是一个例子，我只是对这样的技术感兴趣；大型游戏将是一个很好的应用程序。

有哪些工具可以实现 Java Web 应用程序的高可用性。

我正在尝试建立分布式文件系统中文件可用性的数学模型。我在 MathOverflow 上发布了这个问题，但这也可能被归类为 CS 问题，所以我也在这里试一试。

系统是这样工作的：一个节点在 r*b 个远程节点上存储一个文件（使用纠删码编码），其中 r 是复制因子，b 是一个整数常量。纠删码文件的特性是，如果至少有 b 个远程节点可用并返回文件的一部分，则可以恢复文件。

最简单的方法是假设所有远程节点彼此独立并且具有相同的可用性 p。有了这些假设，文件的可用性遵循二项分布，即

不幸的是，这两个假设可能会引入不可忽略的错误，如本文所示：http ://deim.urv.cat/~lluis.pamies/uploads/Main/icpp09-paper.pdf 。

克服所有节点具有相同可用性的假设的一种方法是计算可用/不可用节点的每个可能组合的概率，并取所有这些结果的总和（这是他们在上面的论文中建议的那种，只是比我刚才描述的更正式）。您可以将此方法视为深度为 r*b 的二叉树，每个叶子都是可用/不可用节点的一种可能组合。文件的可用性与您在 >=b 个可用节点的情况下到达休假的概率相同。这种方法更正确，但计算成本为. 此外，它不处理节点独立性的假设。

你们有什么好的近似值的想法，它比二项式分布近似引入更少的误差，但计算成本比 更好？

您可以假设每个节点的可用性数据是一组由 组成的元组(measurement-date, node measuring, node being measured, succes/failure-bit)。例如，您可以使用此数据计算节点之间的可用性与可用性差异的相关性。

Redis 看起来确实是一个很棒的产品，具有内置的复制功能和惊人的速度。经过测试，感觉绝对是2010年memcached的替代品。

但是，由于在正常使用 memcached 时，会使用一致的散列来在池中的服务器之间均匀分布数据。如果池中的其中一台服务器出现故障并停止访问，它将被透明地处理，只有丢失的密钥将被重新创建并均匀分布在池中剩余的可用服务器上。

另一方面，Redis 还内置了分片，但还有另一个非常有趣的功能，称为自动复制。多亏了这一点，数据的可用性可以大大提高，同时利用从服务器来使用以防万一发生大事。

但是，我还没有找到任何好的解决方案来处理将 Redis 服务器的状态更改为从属服务器以自动成为新的主服务器或通过任何其他方式自动处理 Redis 的故障转移。

怎么可能做到这一点？什么是合适的方法？