几年前，我在一个客户的网络中完成了一个迁移项目，任务是更改平台，该平台在服务器之间分配负载。 随着数据中心行业的新发展，客户服务计划已经发展了近十年，因此，从好的意义上讲，“挑剔的”客户期望的解决方案不仅能够满足网络设备，负载平衡器和服务器的容错要求。 ，但也具有可伸缩性，灵活性，移动性和简单性等属性。 在本文中，我将尝试从简单到复杂，一贯地阐述使用负载均衡器的主要示例，而无需参考制造商，负载均衡器的功能以及与数据传输网络配对的方法。
负载平衡器现在越来越多地称为应用程序交付控制器（ADC）。 但是，如果应用程序在服务器上运行，为什么要将它们交付到某个地方？ 出于容错或扩展的原因，该应用程序可以在多个服务器上运行，在这种情况下，您需要一种反向代理服务器，该服务器对使用者隐藏内部复杂性，选择所需的服务器，向其发送请求，并确保服务器返回正确的服务器，从协议的角度来看，是结果，否则，它将选择另一个服务器并在那里发送请求。 要实现这些功能，ADC必须了解其使用的应用程序层协议的语义；这允许您配置特定于应用程序的规则，以进行流量传递，结果分析以及检查服务器状态。 例如，对HTTP语义的理解使HTTP请求时的配置成为可能
GET /docs/index.html HTTP/1.1 Host: www.company.com Accept-Language: en-us Accept-Encoding: gzip, deflate
发送到一组服务器，随后压缩结果，缓存和请求
POST /api/object-put HTTP/1.1 HOST: b2b.company.com X-Auth: 76GDjgtgdfsugs893Hhdjfpsj Content-Type: application/json
根据完全不同的规则进行处理。
了解协议的语义可以使您在应用程序协议的对象级别组织会话，例如，如果协议的应用程序级别允许的话，可以使用HTTP标头，RDP Cookie或多路复用请求，用许多用户请求填充一个传输会话。
有时仅通过服务HTTP流量就无法合理地想象ADC的应用范围，实际上，大多数制造商所支持的协议列表更加广泛。 即使在不了解应用程序层协议的语义的情况下工作，ADC也可用于解决各种任务，例如，我参与了构建一个自给自足的SMTP服务器虚拟场，在垃圾邮件攻击期间，使用了沿着消息队列长度的反馈控制来增加实例数量使用资源密集型算法提供令人满意的时间来检查消息。 在激活期间，服务器向ADC注册并接收了其新TCP会话的一部分。 在SMTP的情况下，由于网络和传输级别的连接具有很高的熵，因此这种操作方案是合理的；对于ADC垃圾邮件攻击期间的均匀负载分配，仅需要TCP支持。 当可以将服务器视为域中的等效服务器并且它们的性能特征彼此之间相差不大时，可以使用类似的方案从数据库服务器，高负载的DNS，DHCP，AAA或远程访问服务器群集构建服务器场。 我不会再深入探讨协议功能的主题，这方面的内容太宽泛，无法在引言中说明，如果有什么有趣的地方-写，也许这是写一些应用程序更深入介绍的文章的机会，现在让我们开始讨论。
ADC通常会关闭传输层，因此，使用者与服务器之间的端到端TCP会话变得复合，使用者与ADC建立会话，而ADC与其中一台服务器建立会话。
图1网络配置和寻址设置应提供这种流量提升，以便TCP会话的两个部分通过ADC。 使第一部分的流量进入ADC的最简单选择是为一个ADC接口地址分配一个服务地址，而第二部分则有以下选择：
- ADC作为服务器网络的默认网关；
- 在其接口地址之一中广播到ADC使用者地址。
实际上，对第一个应用方案的更为现实的看法看起来像这样，这是我们开始的基础：
图2在将经典应用程序分解为微服务的情况下，第二组服务器可以是数据库，后端应用程序，网络存储或另一组服务的前端。 这组服务器可以是位于另一个数据中心的具有自己的策略的单独路由域，也可以出于安全原因而完全隔离。 服务器很少位于一个网段中；更经常地将它们按明确的访问策略放置在网段中，并具有明确规定的访问策略，该图将其显示为防火墙。
研究表明，现代的多层应用程序会产生更多的西向流量，并且您不太可能希望所有内部代码/段间流量都通过ADC。 图2中的交换机不一定是物理的-可以使用虚拟实体来实现路由域，这些虚拟实体称为虚拟路由器，vrf，vr，vpn实例或针对不同制造商的虚拟路由表。
顺便说一下，存在一种与网络配对的变体，不需要从用户到ADC以及从ADC到服务器的流量对称，在会话较长的情况下，这是一个需求，在这种情况下，大量流量沿一个方向传输，例如流式传输或广播视频内容。 在这种情况下，ADC仅看到从客户端到服务器的流，该流将传递到ADC接口地址，并经过简单的处理，包括将MAC地址替换为其中一台服务器的接口MAC，然后将请求发送到服务器，将服务地址分配给其中一个逻辑接口。 从服务器到使用者的反向流量会根据服务器路由表绕过ADC。 为所有前端支持单个广播域可能非常困难，此外，在这种情况下，ADC分析响应和支持会话性的能力非常有限，实际上这只是一个切换，因此，尽管有些狭窄，但不进一步考虑此选项。可以使用任务。
图3因此，我们有一个基础数据中心，如图2所示，让我们考虑一下哪些问题可以推动基础数据中心发展，我看到了两个要分析的主题：
- 假设交换子系统是完全保留的，那么我们不要考虑如何或为什么，该主题过于广泛。 应用程序可在多台服务器上运行，并使用ADC进行备份，但是如何保留ADC本身？
- 如果分析表明下一个季节性峰值负载可能超出ADC的能力，那么您当然会考虑可伸缩性。
这些任务的相似之处在于，在解决这些问题的过程中，ADC实例的数量肯定会增加。 同时，可以根据“活动/备用”和“活动/活动”方案来组织容错，并且只能根据“活动/活动”方案进行缩放。 让我们尝试单独解决它们，看看不同解决方案具有哪些属性。
许多制造商的ADC都可以视为网络基础架构，RIP，OSPF，BGP的组成部分-所有这些都已经存在，这意味着您可以构建简单的Active / Backup备份方案。 主动ADC将服务前缀传递到上游路由器，并从上游路由器接收默认路由以填写其表，并传输到数据中心并到达相应的虚拟路由表。 备用ADC会执行相同的操作，但是使用所选路由协议的语义会产生不太吸引人的公告。 通过这种方法，服务器可以看到使用者的真实IP地址，因为没有理由使用地址转换。 如果有多个上游路由器，此方案也可以正常工作，但是为了避免主动ADC丢失默认值并与路由器建立连接的情况，同时仍从备用ADC接收默认值并继续将其通告给数据中心，请尝试避免两者之间的距离使用ADC和静态路由。
图4如果服务器不必使用实际的使用者IP地址运行，或者应用程序层协议允许您将其嵌入到标头（例如HTTP）中，则该方案将变为Active / Active，并且性能几乎取决于ADC数量。 如果有多个上游路由器，则必须确保输入的流量或多或少地均匀到达。 如果在ECMP路由域中开始向这些路由器的传输，如果困难或路由域不由您提供服务，则可以轻松解决此任务-您可以在ADX和路由器之间使用全网状连接，以便直接向它们开始ECMP传输。
图5在本部分的开始，我写到了容错和缩放是两个很大的区别。 这些问题的解决方案具有不同级别的资源利用率，如果您正在设计“活动/备用”方案，则需要忍受一半的资源将处于空闲状态这一事实。 如果发生这种情况，您需要采取下一个量化步骤，请准备在将来将所需资源再增加两倍。
当您使用两个以上的设备进行操作时，主动/主动的优势开始显现出来。 假设您需要确保8个任意单元的性能（每秒8千个连接，或800万个同时会话），并提供单个设备故障情况，在活动/活动版本中，仅需要三个容量为4的ADC实例（对于活动/备用情况- 2乘8。如果将这些数字转换为空闲的资源，则可得到三分之一到一半。 可以使用相同的计算原理来估计部分故障期间断开连接的比例。 随着Active / Active实例数量的增加，数学变得更加令人愉悦，并且系统有机会逐步提高生产率，而不是逐步提高Active / Standby。
提及“活动/活动”或“活动/备用”工作方案的另一种方法是正确的。 但是，花很多时间来解决这个问题并不是很正确，因为我试图写一些方法，而不是制造商的功能。 选择此解决方案时，您需要清楚地了解以下内容：
- 群集体系结构有时对此功能施加限制，在某些项目中这是基础，在某些将来可能变得很重要，这里的一切都非常依赖于制造商，每个解决方案都需要单独制定。
- 群集通常是一个故障域；软件中将存在错误。
- 该群集易于组装，但是很难拆卸。 技术的移动性较小-您无法控制系统的各个部分。
- 您陷入了制造商的顽强拥护。
但是，有一些积极的事情：
- 该集群易于安装且易于操作。
- 有时您可以期望接近最佳的资源利用率。
因此，图5中的数据中心继续增长，您可能要解决的任务是增加服务器数量。 并非总是可以在现有的数据中心中执行此操作，因此，假设出现了一个带有其他服务器的新的宽敞位置。
图6一个新站点可能不会很远，那么您可以通过更新路由域来成功解决该问题。 一个更普遍的情况（不排除站点在另一个城市或另一个国家/地区的外观）将带来数据中心问题：
- 利用站点之间的渠道；
- ADC发送到附近和远距离服务器的请求处理时间的差异。
维护站点之间的广泛渠道可能是一项非常昂贵的工作，选择一个位置将不再是一项琐碎的任务-响应时间短或负载大的站点过载。 考虑这一点将促使您构建地理位置分散的数据中心配置。 一方面，此配置对用户很友好，因为它使您可以在离自己较近的位置接收服务，另一方面，它可以显着降低站点之间的信道带宽要求。
对于服务器不必访问真实IP地址或应用层协议允许其在标头中传输的情况，地理上分布的数据中心的设备与我所说的基础数据中心没有太大区别。 任何站点的ADC都可以将处理请求发送到本地服务器，或者将它们发送到附近的服务器，通过广播消费者的地址来实现此目的。 应该注意监视进入的流量，以使站点内的ADC数量足以保持站点接收到的流量比例。 消费者地址转换使您可以根据传入流量矩阵的更改，或在迁移/启动期间，增加/减少ADC的数量，甚至在站点之间移动实例。 尽管它很简单，但是该方案非常灵活，具有令人愉悦的操作特性，并且可以轻松复制到两个以上的站点。
图7如果您使用允许转发请求的协议（例如HTTP重定向），则此功能可以用作控制站点之间通道负载的附加杠杆，在服务器上进行日常维护的机制或在不同站点上构建Active / Backup服务器场的方法网站。 在所需的时间点，ADC可以自动或在某些触发事件后从本地服务器中删除流量，并将使用者转移到相邻站点。 值得密切关注该算法的开发，以便ADC的协调工作排除相互转发请求或共振的可能性。
当服务器需要使用方的真实IP地址并且应用程序层协议不具有传输其他报头的能力时，或者ADC在不了解应用程序层协议的语义的情况下工作时，就会引起特别的关注。 在这种情况下，仅通过在ADC默认值中声明一条路由就不可能在TCP会话段之间提供一致的连接。 如果这样做，第一个站点的服务器将开始使用本地ADC作为第二个站点的会话的默认网关，在这种情况下将不会建立TCP会话，因为第一个站点的ADC只会看到该会话的一个肩膀。
图8有一个小技巧仍然可以让您在不同站点上结合Active / Active服务器场来运行Active / Active ADC（我不考虑在两个站点上使用Active / Backup的情况，仔细阅读上述内容将使您无需进一步讨论即可解决此问题）。 诀窍是在第二个站点的ADC上使用的不是服务器接口地址，而是在逻辑ADC地址上使用，该地址对应于第一个站点的服务器场。 同时，服务器接收的流量就像来自本地ADC的流量一样，并使用本地默认网关。 为了在ADC上保持这种工作模式，您需要激活接口的存储功能，第一个用于建立TCP会话的数据包来自该接口。 不同的制造商使用不同的功能调用此功能，但本质是相同的-记住会话状态表中的接口，并将其用于响应流量，而无需注意路由表。 该方案具有完整的功能，可让您在所有可用服务器之间灵活地分配负载。 对于两个或多个站点，一个ADC的故障不会整体上影响服务的可用性，但是完全排除了ADC发生故障的站点服务器上处理流量的可能性，在预测部分故障期间的行为和负载时应记住这一点。
图9当我开始着手向新ADC平台的迁移项目时，我们客户的服务几乎以相同的方式运行。 在经过验证且对客户友好的方案的框架内，简单地在新平台上重新创建旧平台设备的行为并不难，这是他们对我们的期望。
但是再看一下图9，您看到在那里可以进行优化吗？
使用ADC链的主要缺点是，它消耗了两个ADC的资源来处理部分会话。 对于此客户端，选择是绝对有意识的，这是由于应用程序的特定性以及需要能够非常快速地（从20到50秒）重新分配不同站点的服务器之间的负载所致。 在不同的时间段，双重处理平均占用ADC资源的15％到30％，这足以考虑优化。 与客户的工程师讨论了这一点之后，我们建议使用在Linux IP堆栈上使用PBR的服务器上的源路由，用接口绑定替换对ADC会话表的支持。 作为关键，我们考虑了以下选项：
- 每个ADC的公共接口上的服务器上的其他IP地址；
- 每个ADC在单独的802.1q上的服务器上的接口IP地址；
- 服务器上每个ADC的单独覆盖隧道网络。
第一个和第二个选项将以某种方式影响整个网络。 在第一个选项的副作用中，对于交换机上ADC，ARP表数量的增加和第二个选项的数量倍数的增加，我们似乎无法接受，这将需要增加站点之间或虚拟路由表的各个实例之间的端到端广播域的数量。 第三种选择的本地性质对我们来说似乎非常有吸引力，因此我们开始工作，这产生了一个简单的控制器，该控制器可以自动化服务器和ADC上的隧道配置以及Linux服务器IP堆栈上的PBR配置。
图10如我所写，迁移已完成，客户端获得了他想要的东西-一个新的平台，简单性，灵活性，可伸缩性，并且由于切换到覆盖层，简化了网络设备的配置，从而为这些服务提供了服务-而不是虚拟表和大型广播域的多个副本， - IP .
与ADC制造商合作的同事，本段重点更多地放在您身上。您的某些产品不错，但是请尝试注意与服务器上的应用程序进行更紧密的集成，设置的自动化以及整个开发和操作过程的编排。在我看来，这是经典的控制器与代理的交互形式，它对ADC进行了更改，用户向注册的代理发起了控制器的诉求，这是我们对客户所做的，但是是开箱即用的。另外，一些客户可能会发现从与服务器交互的PULL模型切换为PUSH模型很方便。服务器上的应用程序功能非常广泛，因此有时在代理本身上组织对服务的认真应用程序特定验证比较容易。如果检查给出肯定的结果，则代理将以类似于BGP成本社区的形式传输信息，以供加权计算算法使用。通常，组织的不同部门执行服务器和ADC维护；切换到PUSH交互模型可能会很有趣，因为此模型消除了人与人界面上部门之间协调的需要。服务器参与的服务可以类似于高级BGP Flow-Spec的形式直接从代理转移到ADC。还有更多要写的东西。我为什么要选择所有这些……在自由选择的情况下，我们做出更方便，更合适的决定，或者选择扩大机会窗口以最大程度降低风险的选择。互联网行业的大型公司发明了完全创新的产品来解决他们的问题，明天将要指出的是，较小的公司和具有软件开发经验的公司越来越多地使用允许自己进行深度定制的技术和产品。许多负载均衡器制造商指出，对其产品的需求有所减少。换句话说，运行在它们上面的服务器和应用程序，交换机和路由器已经发生了质的变化，并进入了SDN时代。平衡器已接近极限在门未打开的情况下执行此步骤，否则可能会失去竞争优势并转移到外围设备。