F5 实现负载均衡

所有信息为笔者搜集学习总结，若有错误不当之处，烦请指出

F5？好奇怪的名字

  • 这就得从两方面说起了
    • F5是什么
    • 为啥叫F5

F5是什么？

  • F5是通过硬件实现了负责均衡的设备，相对的为通过Nginx软件层面实现负责均衡
  • 何为负责均衡？
    • 通俗来讲，就是将客户端的流量通过 F5（负责均衡器） 负载到各个服务器，实现各个服务器之间的压力、负载相对一致、可控，以增加吞吐量、降低服务器的压力。避免“一核有难，七核围观”。
    • 比如，有 5 台应用服务器，这时候来了50个http请求，就需要合理转发这50个请求，例如 5 10 15 10 10 的分发方式，避免大部分都转发到一台服务器上，导致一台服务器负载居高不下，其他服务器在摸鱼

为啥叫F5

  • 因为 用的最多的 硬件负载均衡设备就是 F5 家的

    img

  • F5成立于1996年，同年有一部电影叫 《龙卷风》（Twister）。F5就取自龙卷风风力的最高等级-F5。

F5咋干活的？

干活之前先看看概念

基础术语：

  • 在开始之前，让我们先复习一下负载均衡的基本术语。如果每个人使用的都是同一套词汇，这个环节将会容易得多；但遗憾的是，每一家负载均衡设备（进一步来讲，即 ADC）的供应商似乎都在使用不同的术语。好在只要稍加解释，我们就可以快刀斩乱麻，消除乱象。

节点、主机、成员和服务器

  • 大多数负载均衡 ADC 所涉及的概念不外乎节点、主机、成员或服务器，有些 ADC 会四者均沾，含义却各不相同。总的来说，所有这些术语想要表达的就是两个基本概念。其一，通常被称为节点或服务器，指的是将从 ADC 接收流量的物理或虚拟服务器的概念。它相当于物理服务器 IP 地址的同义词，在没有负载均衡器的情况下即指服务器名称（例如，www.example.com）所要解析到的 IP 地址。在下文中，我们将以主机来指代这个概念。

  • 第二个概念是用“成员”（然而有时也被一些厂商称为节点）一词来表示。成员通常比主机的定义更明确一些，因为它包括将要接收流量的实际应用的 TCP 端口。例如，一台名为 www.example.com 的主机，其解析地址可能为 172.16.1.10，该地址就代表主机，而该主机还可能有一个应用（Web 服务器）在 TCP 端口 80 上运行，因此成员地址便是 172.16.1.10:80。简单来说，成员包括应用端口的定义以及物理/虚拟服务器的 IP 地址。在下文中，我们称之为服务。

  • 为什么会如此复杂？因为区分服务器和在其上运行的应用服务，可以让负载均衡器单独与应用进行交互，而不是在数据中心或云端与底层硬件或管理程序进行交互。一台主机 (172.16.1.10) 可能有一个以上的服务可用（HTTP、FTP、DNS 等）。通过唯一地定义每个应用（例如 172.16.1.10:80、172.16.1.10:21 和 172.16.1.10:53），ADC 可以基于服务而不是主机，应用独特的负载均衡和健康监控（我们将在后面讨论这个概念）。

  • 总之，大多数基于负载均衡的技术都会用一个术语代表主机或物理服务器，然后用另一个术语代表可在该主机或物理服务器上使用的服务。在本例中，我们所用的就是主机和服务。

池、集群或农场

  • 负载均衡允许企业在多个后端目的地之间分配入站应用流量，包括在公有或私有云中的部署。因此也就有必要给出后端目的地集合的概念。集群（也被称为池或农场）在这里指代的是在任何数量的主机上可用的类似服务的集合。例如，所有提供公司网页的服务都会被收集到一个名为“公司网页”的集群中，而所有提供电子商务服务的服务都会被收集到一个名为“电子商务”的集群中。

虚拟服务器

  • 虚拟服务器是实际服务器（物理、虚拟或容器）的代理，与虚拟 IP 地址结合，即为呈现给外界的应用端点。
  • 可以理解成，上边的一个集群，被虚拟成一个服务器提供给外界，在外界看来，只有一台服务器提供服务

最后部署起来是啥样的？

  • 负载均衡 ADC 向外界展示的是虚拟服务器，每个虚拟服务器都指向一个驻留在一个或多个物理主机上的服务集群。如下图

    应用交付包括四个基本概念：虚拟服务器、集群、服务和主机。

应用交付包括四个基本概念：虚拟服务器、集群、服务和主机。

工作原理

  • 客户端发起服务请求到VIP（虚IP）

  • BIGIP（这才是上边图里设备的真正名称，是一系列硬件产品）接收到请求，将数据包中的目的IP地址改为选中的后台服务器的IP地址，然后将数据包转发到指定的后台服务器（注意：客户端的源IP不受影响）

  • 后台服务器接收到请求后，处理，再将应答包按照路由发回到BIGIP

  • BIGIP收到应答包后，将其中的源地址改写回VIP的地址，以匹配虚拟服务器的IP和端口，发回给客户端

  • 客户端接收返回包，认为他来自虚拟服务器，并继续处理

  • 由此完成了一个标准的服务器负载均衡的流程

    一个基本的负载均衡事务。

  • 这个非常简单的例子相对容易理解一些，但有几个关键要素需要注意。

    • 首先，客户端所知道的是，它要向虚拟服务器发送数据包，然后虚拟服务器会做出响应，这一点很简单；
    • 第二，执行 NAT。此时 ADC 会将客户端（或虚拟服务器）发送的目标 IP 替换为所选主机的目标 IP，以实现对请求的负载均衡。
    • 第三，便是这个过程中完成“双向”NAT 的环节。从主机返回的数据包的源 IP 将是主机的 IP，如果不改变这个地址，只是简单地将数据包转发给客户端，那么客户端会认为接收的数据包并非来自请求对象，因此便会直接将其丢弃。
    • 但是，负载均衡器会记住该连接并重写数据包，这样源 IP 便是虚拟服务器的 IP，从而解决了该问题。

负载均衡过程中可能需要考虑的问题

  • ADC咋看应该将请求转发给哪个主机？
  • 如果选定的主机不工作了咋办？
  • 某些会话依赖于上次会话的内容，连接如何维护？
  • 某些会话过程中，会跳转其他服务，让不让跳？

第三、第四个问题其实都是在 负载均衡建立后， 后续流量处理过程中的问题

我们先讨论第二个问题

如果选定的主机不工作了咋办？

  • 简单来说，他就不响应客户端的请求呗，导致连接超时，请求失败
    • 这种状况当然不可取，因为无法保证高可用性
    • 所以ADC都包括一定级别的健康监控，以确定主机是否真的可用，然后再尝试向其发送连接
  • 健康监控
    • 监控监控有多个级别，每个界别的监控监控的粒度和重点都在不断提升
      • 基本的监控器只是简单的对主机本身进行ping。如果ping无响应，就可以推断主机上的任何服务都有可能宕机
      • 但是只是ping通，也无法保证主机上的服务一定可用。于是，大多数设备都可以进行某种形式的“服务ping”，从简单的TCP 连接一直到通过脚本或智能交互与应用进行交互。这些更高级别的健康监控器不仅可以为实际服务（相对于主机而言）的可用性提供更多的可靠性，而且还可以让负载平衡器区分单个主机上的多个服务。负载均衡器可以判断出，虽然一个服务可能不可用，但同一主机上的其他服务可能工作正常，因此仍应该将其视为用户流量的有效目的地。

ADC咋看应该将请求转发给哪个主机？

  • 每台虚拟服务器都有一个特定的专用服务集群（列出提供该服务的主机），构成可用性列表。此外，健康监控会修改该列表，使其成为提供指定服务的“当前可用”主机的列表。ADC 正是从这个修改后的列表中选择将接收新连接的主机。
  • 主机的精准选择取决于与该特定集群相关联的负载均衡算法。其中一些算法包括最小连接数、动态比率和简单轮询
  • 轮询时，负载均衡器只需从列表顶部开始向下，将每个新连接分配给下一个主机；当到达列表底部时，只需从顶部重新开始即可。虽然该过程简单，可预测性也很好，但有时它会推定所有连接在后端主机上的负载和持续时间都是相似的，而事实却并非总是如此（例如，每个http请求，对于后端操作的负载不尽相同）
  • 更先进的算法会使用诸如当前连接数、主机利用率，甚至是主机现有流量的真实响应时间，以便从可用的集群服务中挑选出最合适的主机

负载均衡建立后，后续流量处理可能存在的问题

  • 主要有两个问题
    • 连接维护
    • 持久性
连接维护
  • 连接维护指：如果用户试图利用一个不会立即关闭的 TCP 长连接（端口 21：FTP、端口 23：Telnet 或其他），则负载均衡器必须确保通过该连接传输的多个数据包不会在经过负载均衡后被发送至其他可用的服务主机上
  • 它涉及两大关键能力：其一是持续跟踪开放连接及其所属的主机服务的能力；其二是负载均衡器必须能够持续监控该连接，以便在连接关闭时更新连接表。这对于大多数 ADC 来说称得上一个标准套餐。
持久性
  • 然而越来越常见的情况是，客户端会使用多个 TCP 短连接（例如，端口 80：HTTP）来完成单个任务。在某些情况下，比如标准的 Web 浏览，持久性或许可有可无，因为每个新请求都可以进入任意一个后端服务主机；但是在很多情况下（XML、电子商务等），来自同一用户的多个连接都要进入同一个后端服务主机会变得极其重要，而此时无需负载均衡。这个概念就叫做持久性，或者说服务器亲和力。
  • 根据协议和所需的结果，有多种方法可以解决这个问题。例如，在现代 HTTP 事务中，服务器可以指定一个“持续”连接，将多个短连接变成一个单一长连接，处理时与其他长连接一样。然而这种做法治标不治本，主要原因在于，随着 Web 和移动服务的使用量增加，让所有连接保持开放超过必要时间会使整个系统的资源紧张。这就是为什么如今为了可扩展性和可移植性，许多组织正在转向构建依赖 API 的无状态应用。这基本上意味着服务器将抹去所有会话信息，以减少资源负载，在这些情况下，状态会通过传递会话 ID 以及通过持久性的概念来维护。
  • 最基本的持久性形式之一是源地址亲和力，它包括简单地记录传入请求的源 IP 地址和经过负载均衡后接收请求的服务主机，以及将所有未来事务都转到同一个主机。实现这一目的方法有两种：使用 SSL 会话 ID 和 cookie。SSL 持久性使用 SSL 会话 ID 跟踪 SSL 会话，这意味着即使客户端的 IP 地址发生变化，负载均衡器也会根据会话 ID 识别出持久性会话。基于 cookie 的持久性提供了另一个选项，即在客户端的计算机上插入一个 cookie 来唯一识别会话，然后在请求中引用该 cookie，这样连接就会进入正确的服务器。
  • 今天，ADC 智能化允许企业打开数据包，并且几乎可以为数据包中的任何内容创建持久性表，使其能够通过用户名等独特信息来维持持久性。然而企业必须确保这种可识别的客户端信息存在于每一个发出的请求中，因为任何缺少该信息的数据包都无法保持持久性，并将再次经过负载均衡，这很有可能导致应用被破坏。

今天的ADC

  • 最初，负载均衡的重点是在整个网络中分配工作负载，并确保应用和服务的可用性。然而随着技术的发展，负载均衡器演变为应用交付平台，用于确保组织的关键应用高度可用且安全。虽然基本的负载均衡仍然是应用交付的基础，但现代 ADC 提供了更多强化功能。

  • 企业意识到，只是能够获得一个应用并不意味着它可用，而部署无法使用的应用对企业而言则意味着浪费时间和金钱。这就是现代 ADC 的用武之地，它允许企业将基于网络的服务（如 SSL/TLS 卸载、缓存、压缩、速率整形、入侵检测、应用防火墙，甚至远程访问）整合到一个单一的战略点中，该点可以在所有应用服务和所有主机上共享和重用，从而创建一个虚拟化的 Application Delivery Network。这使得网络、应用和运营团队能够更好地响应业务需求、缩短交付时间和提高可扩展性，同时完全不会牺牲安全需求。

  • 扩展阅读

参考引用