服务器负载均衡方案

服务器负载均衡方案内容摘要：

这 12 种局域负载均衡算法包括： 1．静态负载均衡算法 轮询（ Round Robin）：顺序循环将请求一次顺序循环地连接每 个服务器。 当其中某个服务器发生第二到第 7 层的故障， BIGIP 就把其从顺序循环队列中拿出，不参加下一次的轮询，直到其恢复正常。 比率（ Ratio）：给每个服务器分配一个加权值为比例，根椐这个比例，把用户的请求分配到每个服务器。 当其中某个服务器发生第二到第 7 层的故障， BIGIP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 优先权（ Priority）：给所有服务器分组，给每个组定义优先权， BIGIP 用户的请求，分配给优先级最高的服务器组（在同一组内，采用轮询或比率算法，分配用户的 请求）；当最高优先级中所有服务器出现故障， BIGIP 才将请求送给次优先级的服务器组。 这种方式，实际为用户提供一种热备份的方式。 2．动态负载均衡算法 最少的连接方式（ Least Connection）：传递新的连接给那些进行最少连接处理的服务器。 当其中某个服务器发生第二到第 7 层的故障， BIGIP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 最快模式（ Fastest）：传递连接给那些响应最快的服务器。 当其中某个服务器发生第二到第 7 层的故障， BIGIP 就把其从服务器队列中拿出， 不参加下一次的用户请求的分配，直到其恢复正常。 观察模式（ Observed）：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。 当其中某个服务器发生第二到第 7 层的故障， BIGIP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。 预测模式（ Predictive）： BIGIP 利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。 (被 BIGIP 进行检测 ) 动态性能分配（ Dynamic RatioAPM):BIGIP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。 动态服务器补充（ Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。 服务质量 (QoS)：按不同的优先级对数据流进行分配。 服务类型 (ToS)：按不同的服务类型（在 Type of Field 中标识）对数据流进行分配。 规则模式：针对不同的数据流设置导向规则，用户可自行编辑流量分配规则， BIGIP利用这些规则对通过的数据流实施导向控制。 本地服务器 /防火墙健康 检查机制 BIGIP 除了能够进行不同 OSI 层面的健康检查之外，还具有扩展内容验证 (ECV)和扩展应用查证 (EAV)两种健康检查方法。 基本的健康检查方法有以下几种： 在 Layer 2 健康检查涉及到用来对给定的 IP 地址寻找 MAC 地址的地址分辨协议 (ARP) 请求。 因为 BIGIP 设置了真实服务器的 IP 地址，它会发送针对每一个真实服务器的 IP 地址的 ARP 请求以找到相应的 MAC 地址，服务器会响应这个 ARP 请求，除非它已经停机。 在 Layer 3 健康检查涉及到对真实服务器发送 ”ping” 命令。 “ping” 是常用的程序来确认一个 IP 地址是否在网络中存在，或者用来确认主机是否正常工作。 在 Layer 4， BIGIP 会试图联接到一个特定应用在运行的 TCP 或 UDP 端口。 举例来说，如果 VIP 是被绑定在端口 80 做 Web 应用的话， BIGIP 试图建立一个联接到真实服务器的 80 端口。 BIGIP 发送一个 TCP SYN 请求包到每个真实服务器的 80 端口，并检查回应的 TCP SYN ACK 数据包是否收到，如果哪一个没有收到， BIGIP 就确认那台服务器不能正常提供服务， BIGIP 单独针对服务器的每个应用端口做健康检查并单独 做关于其服务器的诊断结果是非常重要的。 这样一来真实服务器的 80 服务可能停机，但是端口 21 可能正常工作， BIGIP 可以继续利用这个服务器的 21 端口提供 FTP 服务，同时确认这个服务器的 Web应用已经停机，这样一来就提供了一个高效率的负载均衡解决方案，细分健康检查的做法有效地提高了服务器的处理能力。 扩展内容查证 (ECV： Extended Content Verification)： ECV 是一种非常复杂的服务检查，主要用于确认应用程序能否对请求返回对应的数据。 如果一个应用对该服务检查做出响应并返回对应的数据， 则 BIGIP 控制器将该服务器标识为工作良好。 如果服务器不能返回相应的数据，则将该服务器标识为宕机。 宕机一旦修复， BIGIP 就会自动查证应用已能对客户请求做出正确响应并恢复向该服务器传送。 该功能使 BIGIP可以将保护延伸到后端应用如 Web 内容及数据库。 BIGIP的 ECV功能允许您向 Web 服务器、防火墙、缓存服务器、代理服务器和其它透明设备发送查询，然后检查返回的响应。 这将有助于确认您为客户提供的内容正是其所需要的。 用户可以定义发送和接收的字串，发送字串是指发送到一个服务器的请求命令，例如： “GET /” 字串发送到一个 HTTP 服务器。 服务器回应得字串必须与接收到的字串相匹配，例如 “”。 ECV 可以工作在正常和透明节点模式。 扩展应用查证 (EAV: Extended Application Verification)： EAV 是另一种服务检查，用于确认运行在某个服务器上的应用能否对客户请求做出响应。 为完成这种检查， BIGIP 控制器使用一个被称作外部服务检查者的客户程序，该程序为BIGIP 提供完全客户化的服务检查功能，但它位于 BIGIP 控制器的外部。 例如，该外部服务检查者可以查证一个 从后台数据库中取出数据的应用能否正常工作。 EAV 是BIGIP 提供的非常独特的功能，它提供管理者将 BIGIP 客户化后访问各种各样应用的能力，该功能使 BIGIP 在提供标准的可用性查证之外能获得服务器、应用及内容可用性等最重要的反馈。 该功能对于提高系统可靠性至关重要，它用于从客户的角度测试您的站点。 例如，您可以模拟客户完成交易所需的所有步骤－连接到前置服务器或中间件服务器、从目录中选择项目以及验证交易使用的信用卡。 一旦 BIGIP 掌握了该“可用性”信息，即可利用负载平衡使资源达到最高的可用性。 BIGIP 已 经为测试多种服务的健康情况和状态，预定义了扩展应用验证 (EAV)，如： FTP、 NNTP、 SMTP、 POP3 和 MSSQL等，用户还可依据实际应用，自行编辑 EAV 脚本。 F5 产品健康检查的频度和间隔是可以根据用户的要求而设置。 通过 F5 灵活自定义方式的 ECV 健康检查方式，用户可以检查常见的应用如 HTTP、SMTP、 POP3 等。 而通过 EAV 健康检查方式，更可自行编写脚本，实现更加复杂的健康检查方式，全面的检测后台服务器的运行状态，保证系统运行的高效，可靠。 会话保持技术 当使用 BIGIP 对服务器进行负载均 衡时，就需要会话保持。 如果某位用户连接到了一台服务器上，那么我们肯定希望该用户在将来再次连接时将仍可连接到该台服务器上。 当该服务器存有用户相关数据，并且这些数据并不与其它服务器动态共享时，持续性就显得十分有必要了。 例如，假设一位用户在某网站采购了一“购物车”的商品，然后还未结帐就离开了该网站。 如果在其重新登录网站后， BIGIP 应用交换机 将客户请求路由至不同的服务器，那么新的服务器对该用户的数据和其所购买的商品将一无所知。 当然，如果所有服务器都在同一个后台数据库服务器中存储用户信息及其选购商品的话，那么一切 就不成问题了。 但是如果网站不是这样设计的，那么具体的购物车数据就只能存储在特定的服务器上。 这样， BIGIP 应用交换机 就必需选择用户曾连接上的那台服务器，以无缝地处理用户请求。 BIGIP 提供以下几种会话保持方法： Simple Persistence， SSL Session ID Persistence，SIP Persistence， Cookie Persistence， iMode Persistence，目的地址归类。 Simple Persistence：根据源地址做会话保持，即相同源地址的访问请求 定位在同一台服务器上面。 SSL Session ID Persistence：根据 SSL 会话 ID 做会话保持。 SIP Persistence： SIP 协议会话保持技术。 HTTP Cookie Persistence： BIGIP 支持四种 Cookie 会话保持技术，即：改写模式，插入模式，被动的 cookie， Cookie 散列。 1．在 Cookie 改 写模式下，服务器将插入一个 cookie， 然后 BIGIP 应用交换机 将对其进行重写，访问流程如下： 首次命中， HTTP 请求（不带有 cookie）进入 BIGIP 应用交 换机 ， BIGIP 应用交换机 任选一台服务器，将请求发送至该服务器，来自该服务器的 HTTP 回复此时包括一个空白的 cookie， BIGIP 应用交换机 重写 cookie，并在粘贴一个特殊的 cookie 后将 HTTP回复发送回去。 再次命中 ， HTTP 请求（带有与上面同样的 cookie）进入 BIGIP 应用交换机 ， BIGIP应用交换机 借助 cookie 信息确定合适的服务器， HTTP 请求（带有与上面同样的 cookie）进入服务器， HTTP 回复（带有空白 cookie）返回 BIGIP 应用交换机 ，后者将向客户机提供更新后的 cookie。 如图 所示： 图 Cookie 会话保持改写模式 2． 在 Cookie 插入 模式下， BIGIP 插入一个 cookie， 服务器无需作出任何修改 ， 访问流程如下 ： 首次命中， HTTP 请求（不带 cookie）进入 BIGIP 应用交换机 ， BIGIP 应用交换机任选一台服务器，将请求发送至该服 务器， HTTP 回复（不带 cookie）被发回 BIGIP 应用交换机 BIGIP 应用交换机 插入 cookie，将 HTTP 回复返回到客户机。