☰

节点镜像——或者是负载平衡或反向代理？

tag-icon • tag-icon networking
节点镜像——或者是负载平衡或反向代理？

如果您有解决方案，最好是开源的，当然（！），我很感兴趣，但我实际上想知道正确的术语。

我正在考虑的设备是一个地址转换器（如 NAT），它接受 URL 请求并从其缓存或可能的服务器机器之一中应答该请求。

如果有写入（POST 请求），该设备会将其发送到所有服务器。

因此所有服务器都可以处于相同状态，无需同步。如果一个节点发生故障，其余节点将处于相同状态，因此可以回复请求。

如下图所示：

Client -> read -> device -> Server A/B (load balancing) or from cache


                                     ->  Server A
Client -> write (POST url) -> device ->  Server B
                                     ->  Server N

所有服务器都被赋予相同的写入权限，因此服务器 A、B、……N 都处于完全相同的状态（如果它们正在运行）。

任何服务器或缓存都可以回复读取操作。

问题：

  • 这个设备叫什么名字？
  • 使用 Apache/Squid 设置是否容易？——如果容易，哪里有傻瓜指南？
  • 这使得设备本身成为 SPOF（单点故障），您如何设置它以便有两个独立的设备执行此操作，以便如果一个设备发生故障，另一个设备可以无缝接管？

答案1

商业的、专有的、有点昂贵的解决方案：CISCO 内容交换
CISCO 有一条名为内容服务交换机的产品线（其CSS 11500 系列）。根据您的问题，这很接近您要找的内容。他们使用的术语（您可以使用它们在 Google 上搜索类似产品）是“内容切换”或“应用程序切换”。

（我在现实生活中没有使用过此类设备，并且与思科没有任何关系）

高可用性设计原则：保持简单
我认为，您的图表中有一个薄弱环节，那就是向所有服务器写入 ( POST)。您依靠“设备”来同步服务器的所有实例（Apache、NSF 文件夹、数据库等）。这引入了新的 SPoF（设备本身，正如您已经注意到的），并增加了同步的复杂性。如果其中一个服务器（暂时）不可用，谁负责重新同步？服务器本身还是“设备”？

更好的模式是将故障转移/高可用性的责任放在基础设施本身内：

  • 硬件层面（RAID、冗余硬件、多条网络路径等），
  • 在操作系统级别（在 Linux 下：心跳：集群消息传递层，起搏器：集群资源管理器和胶水：集群管理工具）和
  • 在应用程序级别。例如，Apache 有几种选择，例如骆驼，所有数据库平台都带有集群选项和 NSF可以使用操作系统的 HA 功能进行设置）。

高可用故障转移 LAMP 服务器
我认为对于 MediaWiki 来说，一般的解决方案是构建一个高可用性故障转移 LAMP。如果你在 Google 上搜索这些术语，会弹出很多解决方案，如本文所述以及高可用性 LAMP 设置的示意图这里是 serverfault。

相关内容