AWS（亚马逊网络服务）网关负载均衡器为第三方虚拟设备提供负载均衡优势。同时，该服务旨在以最小的管理开销使这些第三方虚拟设备具有高可用性和可扩展性。本文讨论什么是负载平衡、更流行的负载平衡算法、AWS 负载平衡的用例、负载平衡中的问题以及Parallels® RAS如何增强负载平衡。
负载均衡器的定义
高流量网站、Web 应用程序和运行在它们背后的数据库在高峰时段会收到数百万个传入请求和查询。当图像、音频和视频等大文件在这种时候在用户和服务器之间传递时，降低服务器及其响应时间的风险就变得真实了。为了防止这种情况发生，增加了更多的服务器来容纳传入的请求。
更好地服务传入流量的另一个选择是为您的网络添加负载平衡功能。负载均衡器可以以硬件或软件的形式出现，并充当用户和服务器之间的中介，跟踪服务器负载，以便他们知道哪个服务器可以更好地处理传入流量。
当传入请求进入时，负载均衡器知道将其发送到哪个服务器。当服务器不可用时，负载平衡器会知道并相应地绕过该服务器。当服务器再次启动时，负载均衡器将再次将请求路由到它。它还将知道何时将新服务器添加到您的网络中，从而允许它在时间到来时将请求路由到该服务器。
流行的负载均衡算法
负载平衡器根据优化网络流量的算法决定将传入请求发送到何处。虽然您为网络选择的算法取决于您的要求，但您的 IT 团队必须在设置负载平衡器时选择要使用的算法。比较流行的负载均衡算法包括：
- 循环：在此设置下，负载均衡器根据网络中服务器的顺序做出决策。因此，服务器 1 是第一个处理请求的，然后是服务器 2 并继续处理。由于它不考虑服务器负载，因此该算法可能导致某些服务器因请求而过载。这种情况的一种变体是加权循环，它根据服务器的能力为服务器分配权重。
- 最少连接：使用此设置，传入请求将发送到活动连接数量最少的服务器。因此，它有助于避免服务器过载的潜在问题。
- 最小带宽：此设置测量传输到服务器和从服务器传输的流量，具有最少带宽消耗的服务器最终获得请求。这类似于最少数据包方法，它基于服务器通过网络传输的数据包数量来做出负载平衡器的转发决策。
- 最短响应时间：在此设置下，负载均衡器向服务器发送监视请求以确定它们可以多快地处理请求，然后再将实际请求转发到可以更快处理请求的服务器。
- 散列：使用此设置，负载平衡器依赖来自传入网络数据包的散列数据，包括源和目标的 Internet 协议 (IP) 地址。设置起来可能很复杂，比本节讨论的其他算法更难。
- 自定义负载：此设置涉及根据 SNMP（简单网络管理协议）提供的数据查询服务器负载，包括内存使用情况、CPU 使用情况和响应时间，负载均衡器依靠数据做出路由决策。
AWS Gateway 负载均衡器的使用案例
与任何其他负载均衡器一样，AWS Gateway 负载均衡器用于组织您的网络流量，以便更好、更快地为您的用户提供服务。其次是它可以让您的虚拟设备按需扩展。因此，如果您的组织当前使用或计划使用虚拟设备，则该服务主要面向您。虚拟设备的一些示例包括那些增强网络安全的设备，包括防火墙和入侵检测系统。
AWS Gateway 负载均衡器负责将流量路由到网络中的相应虚拟设备，而不是直接将流量路由到虚拟设备。使用网关负载均衡器，流量被路由到健康的虚拟设备，并从失败的虚拟设备中重新路由。因此，它可以帮助降低管理成本，因为您可以通过网关集中流量。它还可以确保您的策略在您的设备中得到一致执行。
通过 AWS Marketplace，您的组织还可以访问可以轻松添加到您的网络的第三方虚拟设备和解决方案。但是，这些都是有代价的，因此您仍然必须为这些费用分配预算。
由于任何第三方虚拟设备或解决方案都可以按原样连接到 AWS Gateway 负载均衡器，而无需更改任何其他端点，因此它们是网络分析的理想选择，让您能够及早发现潜在的网络问题并构建您的网络更有弹性。此外，AWS Gateway 负载均衡器还可以与网络编排工具一起使用。这些工具包括 AWS CloudFormation，它可以简化您 IT 基础设施中 AWS 资源的部署和管理。
负载均衡器的问题
尽管负载均衡器有其优势，但它们也不能免除可能使您的网络和 IT 团队工作复杂化的问题。负载平衡器可以使您的网络比现在更复杂。如果您的负载均衡器出现故障，它也会使您的整个网络瘫痪。必须实施负载平衡基础架构的故障转移机制以防止这种情况发生。
实现这一点的一种方法是通过冗余路由器，在发生故障时可以将流量从一个负载均衡器切换到另一个。有了这样的机制，当主负载均衡器发生故障时，备用负载均衡器将接管其功能，直到主负载均衡器重新上线。上述故障转移要求意味着负载平衡器可能会导致您的网络的运营成本更高。
负载均衡器配置错误也会带来网络问题。例如，负载均衡器可能会错误地检测健康服务器中的故障并不必要地将流量重新路由到其他服务器。这可能是由于多种因素造成的，包括过于频繁的运行状况检查以及在运行状况检查期间预期服务器响应的超时时间太短。调整运行状况检查的频率并延长超时时间有助于解决此问题。
