2013 年 8 月 16 日，谷歌遭遇了史无前例的全球性宕机。大约五分钟内，该公司提供的所有服务（包括Google 搜索、Google Drive、YouTube 和 Gmail）都下线，全球范围内无法访问。
结果如何？当时，分析公司计算出该事件导致全球互联网流量下降了 40%。
那么，我们能从中学到什么呢？这次事件表明，虽然正常运行时间对所有网站都至关重要，但有些中断的代价比其他中断更大。
这就是为什么虽然您的个人博客可能托管在单个服务器上，但流行的、关键任务的网站和应用程序需要更复杂的设置，称为高可用性系统。
今天，我们将深入了解高可用性集群是什么，并向您展示它在虚拟服务器（VPS）环境中的工作原理。
什么是高可用性系统？
在典型的托管设置中，您有一个物理或虚拟服务器，用于托管一个或多个网站。所有文件和数据库都存储在一台机器上，该机器负责处理来自互联网的所有请求。如果它发生故障，您的整个网站都会瘫痪。换句话说，存在单点故障。
对于一些企业来说，这种设置的风险太高了。
例如，想象一下，一家大型电子商务商店，客户来自世界各地，每秒都会有数百个订单。即使是几分钟的停机时间也会导致数十万美元的收入损失和难以修复的声誉损害。如果您运行的是处理网上银行、流量控制等任务的关键应用程序，停机的后果可能会更加严重。
此类项目需要更可靠的托管基础架构，不依赖于单个服务器。此时，我们可能应该澄清“更可靠”的含义。
假设您的网站在 24 小时前正式启动，在此期间，由于主机需要重启服务器，网站离线了 5 分钟。一整天有 1,440 分钟，5 分钟占 0.35%。因此，您的应用程序正常运行时间为 99.65%。
对于大型赚钱网站或关键任务应用程序来说，这个数字是不可接受的。这些项目的目标是实现“五个 9”或 99.999% 的正常运行时间。在 24 小时内，它们可以接受的停机时间不会超过0.0144 分钟（或 864 毫秒）。实现这一目标的唯一方法是使用高可用性托管基础设施。
高可用性 (HA) 系统由集群中连接的多台服务器（或节点）组成，配置为托管同一网站或应用程序。有许多不同的设置，但在所有情况下，如果其中一个节点离线，其他节点可以接管并确保您的网站可供全世界访问。
这就是 HA 集群消除单点故障的方式。听起来很简单，但您如何实际设计和构建高可用性基础设施？
有三个主要概念需要您密切关注。让我们更详细地讨论一下它们。
冗余
从更广泛的计算角度来看，在系统中建立冗余意味着设置多个执行相同操作的组件。在我们的例子中，组件是组成我们集群的服务器（或节点）。它们的工作是处理请求、传递文件以及从站点的数据库读取/写入数据。
如果一台服务器离线，其他服务器仍可保持您的网站可访问。只要至少一个集群节点仍在工作，用户就能够访问它。
监控
监控是高可用性集群运行的重要组成部分。通常内置于 Web 服务器或负载平衡器中的系统必须随时可用，以跟踪每个集群节点的运行状况。根据此信息，可以将请求重新路由到特定节点，以确保即使在流量大的情况下也能不间断地正常运行并实现出色的性能。
故障转移
故障转移是指从发生故障的服务器切换到正常运行的服务器的操作。如果您的故障转移机制足够好，用户将不会知道您正在有效地将他们重定向到另一个节点。
上述概念应是每个高可用性集群的基础。总体而言，此设置有许多不同的方法，您选择的方法很大程度上取决于您正在构建的 HA 系统的类型。
高可用性架构的类型
没有两个高可用性系统是相同的。提供商使用各种不同的服务器和虚拟实例，他们构建的每个集群都是根据客户的特定要求量身定制的。解决方案往往非常灵活。
高可用性系统在设计上易于 水平扩展。如果您的网站需求超出了您当前的设置容量，您可以轻松地向集群添加更多服务器，以获得更强大的功能和冗余度。
鉴于所有这些，按规模对 HA 系统进行分类有点毫无意义。但是，当涉及到其操作的其他方面时，我们可以看到几种不同的方法。
主动-备用与主动-主动基础设施
首先，让我们检查一下 HA 集群如何处理请求并利用可用的服务器。
主动/备用高可用性设置
在此设置中，单个主服务器处理所有传入请求。集群中的其他节点处于待机状态 – 它们已打开但不处理任何流量。监控系统密切关注主服务器的运行状况，如果发现问题 – 它会立即将流量重定向到第二个节点，该节点开始处理传入请求。
如果第二台服务器出现问题，流量将转到第三台服务器，依此类推。主节点修复后，将重新上线并继续处理传入请求。
主动/主动高可用性设置
在主动-主动集群中，没有一台服务器处理所有流量。相反，负载平衡器位于互联网和应用程序服务器之间，其工作是将传入的请求重定向到集群中的不同节点。其目的是通过在多台机器之间分散负载来更有效地利用服务器资源。如果集群中的某个节点出现问题，发往该节点的请求将自动发送到其他服务器。
优点缺点
双活基础设施可提高您网站的可用性和性能。一方面，这提供了所有 HA 集群所必需的冗余，另一方面，您的网站可以持续访问大量硬件资源，这意味着您可以期待更快的加载速度。
就复杂性而言，主动备用基础设施更为简单。操作中涉及的组件较少，配置所有组件以使其协同工作的工作量也较少。
更简单的设置降低了价格，但尽管主动-备用架构在绝对意义上可能更便宜，但您仍然需要为大多数时间未使用的资源付费。从这个角度来看，使用主动-主动集群更有可能物有所值。
单站点与多站点基础设施
使用虚拟机构建高可用性集群非常有意义。它们运行起来更便宜，在硬件配置方面也更加灵活。但是，它们仍然需要部署在物理服务器上，而物理服务器又位于数据中心。您有两种选择。
单站点集群
通过单站点设置，您的所有节点都位于同一数据中心。虚拟实例可以部署在不同的物理机器上以实现更好的冗余，但数据来自同一位置。
多站点集群
您可以从多个数据中心运行高可用性集群。您可以将节点部署到任何您想要的地方。其中一个可能位于欧洲，另一个可能位于美国，第三个可能位于远东。唯一的限制因素是您的主机提供的位置。
优点缺点
如果您的在线项目吸引了全球观众，那么多站点架构的好处显而易见。在主动-主动设置中，您可以配置集群来分析单个请求并从最靠近访问者的位置为其提供服务（就像内容交付网络一样）。
多站点集群的缺点是增加了复杂性。维护集群也更具挑战性，并且由于传入的请求将被重新路由到不同国家的节点 –额外的网络流量可能会抵消性能优势。
但是，除了CDN 类型的行为和更快的加载速度之外，还有一种情况，多站点高可用性架构提供了宝贵的优势。如果您的节点部署在一个位置，并且该位置发生灾难性故障或自然灾害 – 您的整个集群将随之瘫痪。
值得一提的是，数据中心运营商为确保这种情况永远不会发生而付出了很多努力。他们运行最先进的设施，并遵循涵盖各种情况的数十种安全协议。然而，灾难有时确实会发生，后果相当可怕。
应该非常清楚的是，即使是最小的高可用性集群也是一个复杂的系统，其运行有多个至关重要的组件。让我们更仔细地检查一下它们。
负载平衡和高可用性
您可以将负载均衡器视为一个调度器，它接收来自互联网的请求并将其重新路由到集群中的不同节点。当然，这是一个非常简单的概述。
还记得每个高可用性系统都必须应用的关键概念——冗余、监控和故障转移吗？您可以利用连接到集群的多个应用程序服务器来确保冗余。对于监控和故障转移，您可以使用负载均衡器。
通过它，您的高可用性基础设施可以了解每台服务器的运行情况，并可以相应地重定向流量。
我们将在稍后了解它是如何实现这一点的，但首先，让我们看看不同类型的负载均衡器。
负载均衡器的类型
负载均衡器主要有两种类型：
硬件负载均衡器
硬件负载均衡器是连接到高可用性集群的物理设备。它可能位于与您的应用服务器相同的数据中心，但也可能位于不同的位置。硬件负载均衡器具有专门的操作系统和工具，可帮助系统管理员配置将请求重新路由到各个节点的机制。
软件负载均衡器
过去，软件负载均衡器只是从物理负载均衡器中取出的软件，并经过调整以在标准化环境中工作。如今，情况已经不同了。
软件负载平衡器可以在本地、数据中心或公共云中托管的单独物理或虚拟服务器上运行。通常，它是安装在您的托管帐户上的默认软件堆栈的组件，甚至可以集成到 Web 服务器中。
优点缺点
传统上，硬件负载平衡器被认为是更高级的选择，因为整个硬件设备的设计都只有一个目的。然而，近年来，软件负载平衡解决方案取得了长足的发展，由于功能范围广泛，它们现在被认为是大多数项目的更好选择。由于它们通常集成到软件堆栈中，因此软件解决方案通常更便宜，也更易于部署、维护和扩展。
负载平衡算法
当请求到来时，负载均衡器必须决定由哪个集群节点来处理该请求。至关重要的是，必须重新路由流量，以将总体负载保持在合理水平，同时保持出色的性能。
为了确保所有这些，系统管理员实施了负载平衡算法——负载平衡器在将传入请求分配给集群节点时遵循的规则。
有几种众所周知的负载平衡算法，可分为两类：
静态负载平衡算法
静态负载平衡算法由固定的规则组成，无论每个服务器的当前状态、流量等如何，这些规则都会适用。
这里有一些例子：
- 循环——按顺序分配请求（即第一个请求发送到服务器 1，第二个请求发送到服务器 2，第三个请求发送到服务器 3，等等）。
- 加权循环——循环算法的这种变体允许管理员将更多的流量重新路由到可以同时处理更多请求的集群节点。
- IP 哈希– 负载均衡器使用源 IP 地址计算唯一密钥并确定哪个服务器应接收此特定请求。这是确保特定 IP 范围的流量到达确切服务器的绝佳解决方案。
动态负载平衡算法
动态负载平衡算法会添加适用于高可用性集群当前状态的规则。如果您的负载平衡器使用此类算法，它会考虑一个或多个因素，然后再决定哪台服务器最适合处理每个传入请求。
以下是动态负载平衡算法的几个示例：
- 最少连接– 传入请求将自动发送到具有最少打开连接的服务器。
- 加权最小连接– 某些连接对服务器的负载大于其他连接。通过修改最小连接算法，管理员不仅可以考虑请求数量，还可以考虑请求类型。
- 基于资源——集群中的每台服务器都安装了一个代理，用于监控可用内存量和处理能力。该代理不断与负载均衡器通信，因此平衡器知道哪些服务器很忙，哪些服务器可以处理更多请求。
通常，管理员会实施两种或多种静态和动态算法的组合，以保证出色的性能和一致的速度，同时将服务器负载维持在可管理的水平。
负载平衡和安全
高可用性系统中的每个组件都必须在配置时考虑安全性，负载均衡器也不例外。多年来，管理员尝试使用负载均衡器执行许多与安全相关的任务。有些做法在推出时是有意义的，但现在已被认为过时。
例如，过去，负载平衡器通常用于所谓的SSL 终止（或 SSL 卸载）。从根本上讲，管理员使用平衡器作为解密设备，在将 SSL加密的请求传递给应用服务器之前对其进行解密。这意味着集群节点上的负载更少，响应时间更快。
然而，SSL 终止现在被认为是有风险的，因为它实际上意味着负载平衡器和应用程序服务器之间的数据流不受保护。对于信息需要在数据中心之间传输的多站点集群来说，风险尤其严重。
使用负载均衡器解密数据不是一个好主意。但是，使用它来保护您的项目免受DDoS 攻击是一个好主意。
现代负载平衡解决方案可以自动检测垃圾流量并将其卸载到亚马逊或谷歌等云提供商。云是当今吸收 DDoS 活动的最有效方式，因此如果您配置负载平衡器以利用它 – 您很有可能毫发无损地遭受严重的网络攻击。
负载平衡中的冗余
到目前为止，我们一直以单数形式提及负载均衡器。然而，只有一个负载均衡器的集群并不是真正的高可用性解决方案。
如果没有负载平衡解决方案，整个集群就会崩溃，因此，如果它由单个设备或软件应用程序组成，那么就会出现单点故障——这正是您要解决的问题。
这就是为什么精心设计的高可用性设置有多个负载平衡器以 Active-Active 或 Active-Standby 配置工作。在多站点设置中，它们必然位于不同的位置以获得额外的冗余。这可以保证即使您使用的其中一个数据中心发生故障，也有一个负载平衡器可以保持集群在线。
虚拟 IP 及其故障转移功能
到目前为止，我们已经探讨了高可用性集群采用的原理，将请求引导到可用节点并在发生硬件故障时保持您的网站运行。
现在是时候看看该机制的实际作用了。
实际上，您的服务器集群是一个与您家中的计算机网络没有太大区别的计算机网络。在其中，您的计算机、手机、智能电视和其他 IoT 设备都连接到路由器，路由器充当来往于万维网的流量网关。在您的高可用性集群中，您拥有的是节点而不是设备，以及负载均衡器而不是路由器。
任何计算机网络中的单个机器，无论大小，都必须易于识别。例如，在您的 HA 集群中，负载平衡器必须能够识别单个节点、检查负载并将流量重定向到最合适的目的地。
IP 地址是处理任何类型的计算机网络时最常用的标识符。在 HA 集群中，各个节点被分配虚拟 IP 地址 (VIPA)。IP 是虚拟的，因为它们不绑定到物理网络接口。
负载平衡器拥有集群中所有 VIPA 及其对应的MAC 地址的最新列表。它知道每个请求在任何给定时间的去向。如果需要重新分配 VIPA，则必须更新列表。
负载平衡器与集群中的所有虚拟 IP 交换信息。如果 VIPA 停止响应，则表明其中一台服务器明显存在问题，发送到该服务器的流量会立即转移到健康节点。这就是最重要的故障转移过程。
但是，请记住，信息流必须是双向的。当节点处理请求并发回所需信息时，它必须经过负载均衡器才能发送给用户。与节点一样，负载均衡器也有自己的 IP。但是，其地址称为“浮动”。
浮动 IP 与虚拟 IP 类似，因为它不连接到硬件网络接口 – 对外界完全不可见。但是，与虚拟 IP 不同，它可以更轻松地重新分配给其他设备。因此，如果主负载均衡器离线，浮动 IP 会自动转移到备份，并且应用程序服务器的响应不会中断。
高可用性和数据复制
冗余与先进的监控系统和可靠的故障转移开关相结合，可以切实消除用户在尝试访问您的网站时出现空白屏幕或错误消息的风险。但是，您还没有完全脱离困境。
在传统设置中，您通常会在单个服务器上托管一组文件和一个数据库。使用高可用性基础架构，您必须确保文件和数据库在所有集群节点上都可用。这本身就是一项复杂的任务，现代网站往往提供的交互水平使这项任务变得更加棘手。
如今，只需单击一下按钮，就可以生成新的数据条目，并需要将其存储起来以备将来使用。在繁忙的网站上，这种情况每秒发生数百或数千次，而在高可用性环境中，挑战在于确保数百万人同时看到这些更改。
过去，有两种方法可以做到这一点。
- 共享磁盘架构 –要构建共享磁盘基础架构，您需要设置外部存储设备并配置集群节点以与其配合使用。用户生成的所有数据（无论他们连接到哪台服务器）都保存在同一磁盘上，可供其他计算机使用。
- 无共享架构——在无共享架构中，节点将信息写入其内部磁盘，自动数据复制机制确保该信息被复制到网络中的所有服务器上。
同时反映所有更改至关重要。该过程称为同步数据复制（与定期进行更新的异步相反），并且是保证高可用性且零数据丢失的唯一方法。
两种设置各有利弊。例如，共享磁盘架构将最关键的任务之一卸载到外部设备，从而减轻了应用服务器的负载。但是，它也增加了网络的复杂性，使其更加昂贵。
使用应用程序服务器的内部磁盘听起来像是一个简单的解决方案，但实现同步数据复制机制绝非易事，而且确保这种设置的冗余度也很棘手。
值得庆幸的是，云技术的进步使得科技公司能够创新并创造出远远优于传统方法的解决方案。
- 分布式存储——分布式存储架构涉及将数据存储在多个物理或虚拟机上。除了应用程序服务器之外，您还有一个仅负责数据存储的节点集群。
分布式存储解决方案将数据分解为块，并将不同部分存储在不同的存储节点上。高可用性集群中的每个应用服务器都可以直接访问信息，并可以随时找到所需的任何内容。
与传统解决方案相比，分布式存储设置有几个主要优点：
- 冗余–分布式解决方案可以在不同节点上存储相同数据的多个副本。即使集群中的一台服务器离线，数据也可以轻松恢复。
- 成本——近年来，云资源的价格大幅下降，而且由于分布式存储可以让您充分利用它们的潜力——您可以放心地说，这是最具成本效益的解决方案。
- 性能 ——分布式存储设置可以比传统解决方案更快地传递数据，尤其是使用部署在多个地理区域的云基础设施。
- 可扩展性——根据您的需求扩展分布式基础设施既简单又便宜。
得益于这些优势，萤光云等全球云托管服务拥有强大的分布式存储基础设施。
结论
高可用性集群可能是一个复杂的系统。您有多个物理或虚拟机协同工作来为您的网站提供服务，以及多个实用程序，即使在高负载下也能确保一致的网络性能和可靠性。
多集群解决方案对于高流量业务而言非常经济高效，并且可以产生一些真正显著的效果。您只需确保您的设置是按照项目要求构建和配置的即可。
常问问题
问： 什么是高可用性？
答：高可用性系统的目的是使用具有内置冗余和故障转移机制的基础设施尽可能减少停机时间。该设置涉及多个服务器协同处理访问者请求。如果其中一个节点发生故障，其他节点将接管并保持网站在线。每个高可用性系统的目标都是实现99.999% 的正常运行时间。
问： 具有高可用性集群系统的VPS服务商有哪些？
答：萤光云、lightnode、阿里云、腾讯云这些顶尖VPS服务商都配有这个系统。
问： 要实现高可用性，需要哪三件事？
答： 冗余可确保您拥有备用资源，以防您的某个主服务器离线。监控系统对于在硬件故障影响您网站的性能之前检测出这些故障至关重要。可靠的故障转移交换机应将请求从故障服务器重新路由到备用节点。
问： 高可用性系统和备份有什么区别？
答：高可用性系统提供基础架构，以确保您的网站即使在硬件故障的情况下也能保持在线。相比之下，备份用于在网站瘫痪后恢复网站。即使您的项目在高可用性网络上运行，您仍必须确保拥有文件和数据库的有效备份，以防万一。
