标签: high-availability

我希望通过使用分布式数据系统创建一个高可用性、可扩展的网络解决方案。此处的节点描述了可以控制数据的一个副本的网络。这些节点可能包含不止一台机器，但拥有一份数据副本。

节点将包含可能处于已用状态或未用状态的数据记录。客户端可以请求将记录从未花费状态转换为花费状态（请求花费）。如果他们可以多次成功执行此操作，则存在安全风险。

单个节点，如果它与所有其他节点有连接，则可以告诉节点已经请求支出，并且可以确保没有其他节点想要访问数据并且支出尚未发生。节点可以将数据的状态更改为已花费，而其他节点不会这样做，因为它们知道其中一个节点正在更新它并处理花费。所有节点都会更改数据，因此记录处于已花费状态。

如果一个节点无法访问另一个节点，它可以假设另一个节点已关闭，并将继续与其他节点一起运行，直到另一个节点恢复正常运行。在这种情况下，节点会将所有更新发送到恢复的节点。如果这个失败的节点正在执行当时未完成的支出操作，那么它可以完成它。这将导致某些操作的轻微停机。这将是在一个节点告诉其他节点它将花费，然后在它完成花费过程之前失败的情况下。在这种情况下，其他节点被阻止更新它，因此故障节点需要在完成之前重新联机。

问题是，支出的处理只能发生一次。如果网络被分区，知道这一点的攻击者可以请求在一个分区和另一个分区上花费。网络的每个分区都会假设另一个分区已关闭，因此将独立运行。这可能会导致多次处理支出。

如果在分区期间未向网络两侧发出请求，则这不会成为问题。当重新建立连接时，网络将最终变得一致。如果攻击成功，节点会在重新建立连接时了解攻击，因为网络的两侧会宣布相同的更改。

所以这是可检测的攻击，但实际上可能吗？

攻击者需要故意尝试这样做。该软件并非旨在同时发出多个支出请求。攻击是有时间成本的。如果攻击者失败，他们需要时间才能重新创建未使用的记录。创建未使用的记录需要钱。并且需要在一次攻击中使用更多的钱才能获得更高的收益。之所以有时间成本，是因为要收回钱再试一次需要时间。他们可以承受许多较小的攻击，然后对他们的好处会更少，造成的损害也会更少。

当然，分区自然非常罕见，如果攻击者在任何时候尝试攻击，攻击者必须非常幸运地获胜？

如果连接自然丢失，节点可以停止所有操作并尝试重新连接。使用低超时连接到节点意味着它不会导致任何停机时间（也许只是很少增加延迟）。如果重新连接失败，则它将继续尝试，然后重新启动操作（假设节点已关闭）。类似的东西可以防止偶尔的连接错误吗？

那么攻击者是否能够检测/导致网络中的分区？发生分区的可能性有多大以及持续多长时间？如果可能，可以通过哪些方式解决问题？

谢谢你。

我需要在多个“真实服务器”之间对 UDP 流量进行负载平衡，并以真正的循环方式进行。我已经开始使用 keepalived，但意外地发现，LVS 将 UDP 流量视为“连接”（无论 UDP 是什么......）。实际上，这意味着来自特定客户端的所有流量始终都流向同一个“真实服务器”（这是一个大问题，因为某些客户端可能会产生如此大的流量，以至于单个后端将不堪重负） .

显然，这是预期的行为，但是最近的 LVS 版本有一个“--ops”标志，这使 LVS 绕过其上述行为，以便独立处理每个 UDP 数据报（这就是我想要的！）。但是（总是有一个但是……）这个功能没有从 keepalived.conf 中暴露出来。

有什么解决方案可以让我

• 在 UDP 的后端之间进行循环分配
• 检测“死”后端并将它们从循环中删除（当它们“活着”时将它们添加回来也很有用）

显然应该是基于 Linux 的。任何形式的 DNS 轮询在这里都不起作用，因为客户端不知道 DNS。

PS我将尝试脉冲/食人鱼，但从阅读我收集的文档来看，它也没有公开“--ops”标志。我还将尝试mon（通过直接调用 ipvsadm使mon检查后端并添加/删除真实服务器）。

我正在考虑更改通过 https api 提供服务的“高可用性”网站的选项。

目前的设置是：

• 两个独立的 VM，来自不同的云提供商（AWS 和 RackSpace）
• 一个 DNS 负载平衡器：这也是 HA 的用武之地，该服务监视两个 VM，如果其中一个 VM 不可用，它将所有 DNS 查询定向到另一个

如果负载平衡不是必需的，我们是否可以通过简单地将 DNS 服务器放在两台机器上，在 DNS 查询时只用自己的地址回复，而无需负载平衡器。在这种情况下，如果一个 VM 关闭，它将同时删除服务和指向该服务的 DNS 服务器，因此不会将客户端定向到关闭的服务器，是否正确？

为清楚起见编辑：

我们对我们目前拥有的不完美的“HA”感到满意，这个问题特别是关于我正在考虑的变化是否会让事情变得更糟。

我似乎无法在 vSphere 5 文档中心找到这些问题的答案，因此如果您了解这些问题的任何方面，请分享。

1. 已为高可用性 (HA) 配置的故障 VM 会发生什么情况？容错（FT）？它是否自动停止并释放其资源（但重新启动 (HA) 或辅助实例接管 (FT)）？
2. 调试发生故障的 VM 的典型方法有哪些？通过日志还是 VMware VM 监控 UI？用户会收到 VM 故障的通知吗？
3. 是否可以在重新启动或故障转移之前克隆虚拟机以稍后调试发生了什么？

谢谢！！

根据我对故障转移集群的理解，实际上只有一台机器在工作，这意味着其他机器闲置。那么为什么要使用故障转移群集而不是使用 Windows Server 2012 的负载平衡样式来获得更好的性能，所有机器都作为一台工作，但仍然保持高可用性。

在某些情况下，一种情况比另一种情况更有效吗？

我想练习在一台机器上使用多个 Docker 容器创建高可用的 Web 应用程序。

我在 Docker 容器中启动了多个 Web 服务器。比如说，三台服务器rest1和rest2。rest3

我将 Docker 与 HAProxy 平衡器结合使用，该平衡器绑定到服务器127.0.0.1:80并将查询路由到rest服务器。这使我可以确定，当一两台rest服务器发生故障时，我将能够进行查询127.0.0.1:80并收到正确的结果。

坏事是：当 HAProxy 关闭时，Web 应用程序也会关闭。

我想使用多个 HAProxy Docker 容器，每个容器中都带有 Keepalived 服务。问题是：我需要几个Docker容器来监听一个IP和一个PORT。例如，我将拥有haproxy1和，它将通过 Keepalivedhaproxy2绑定到。localhost

当我在 HAProxy 配置文件中设置 IP（不是当前 Docker 容器的 IP）时，它显示一个错误，HAProxy 无法侦听此 IP 和端口。

是否可以使用HAProxy和Keepalived配置多个Docker容器来监听一个IP和PORT？

HAProxy的配置：

defaults
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http-in
    mode http
    bind 172.17.0.10:80
    default_backend BACKEND

backend BACKEND
    option httpchk
    server rest1 …

首先感谢您对未来的帮助:)

• 我想知道是否可以将我的 HA 包裹在我的油漆上（请原谅我的图纸质量）。

• 我还想知道在 HA 和服务器出现故障的情况下，ipv4 故障转移块如何处理？

• 我的最后一个问题，在我的 ISCSI 上，如果硬盘驱动器崩溃，如果我理解正确，数据会丢失吗？所以我想知道您是否必须进行突袭或备份？不会失去太多空间^^

提前谢谢你，我为我的英语道歉。亲切地

我们有 2 个物理主机、4 个虚拟节点（HyperV 服务器 VM，每个主机上有 2 个）集群，它们运行一些嵌套的测试 VM（使用提到的 HyperV 服务器）。

简而言之，它是一个实验室环境，我们试图在其中复制 2 个机架（其中每个机架是物理主机）、4 个服务器站点感知故障转移集群。我们已将 iSCSI 卷挂载到作为 CSV 工作的所有节点，其中存储了 VM。我们创建了故障域，其中前 2 个节点位于站点 1 机架 1，左侧 2 个节点位于站点 2 机架 2，将首选站点配置为站点 1。将 VM 的 Get-ClusterGroup 更改为站点 1。

我们有一个我们出售的 Web 解决方案，它带有 1 个专用的 Azure VM，其中包含运行应用程序所需的一切：

• ASP.NET 网络应用程序
• 生产环境
• 质量保证环境
• 包含 PROD 和 QA 环境数据的 SQL 服务器

但是，特定客户要求在高可用性设置中运行其应用程序。他想要的是，当一台服务器出现故障时，另一台应该接管，反之亦然。

我对负载平衡/高可用性设置完全陌生，我知道 Azure 支持负载平衡，但我对如何使其工作感到困惑。使用上述设置创建 2 个服务器然后设置高可用性功能是否容易？我关心的是如何在两台服务器之间同步网站数据和 SQL Server 数据？尤其是后者。

或者如果我使用 Azure SQL 服务器而不是本地 SQL 服务器会更容易吗？或者可能引入额外的服务器而不是 2 个？

ceph有高可用吗，我这样配置2个节点

  cluster:

    id:     07df97db-f315-4c78-9d2a-ab85007a1856
    health: HEALTH_WARN
            Reduced data availability: 32 pgs inactive
            Degraded data redundancy: 374/590 objects degraded (63.390%), 18 pgs degraded, 32 pgs undersized

  services:
    mon: 2 daemons, quorum ceph1,ceph2
    mgr: ceph1(active), standbys: ceph2
    mds: mycephfs-1/1/1 up  {0=ceph1=up:active}, 1 up:standby
    osd: 2 osds: 1 up, 1 in

  data:
    pools:   6 pools, 96 pgs
    objects: 216  objects, 12 MiB
    usage:   75 MiB used, 945 MiB / 1020 MiB avail
    pgs:     33.333% pgs not active
             374/590 objects degraded (63.390%)
             64 active+clean …