负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。
有两类可伸缩数据服务:纯粹和粘滞。纯粹服务 就是它的任何实例都可以对客户机的请求作出响应的服务。粘滞服务是客户机发送请求到相同实例的那种服务。那些请求不被重定向到其他实例。
纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下,客户机请求按缺省方式被均衡地分配到群集内的 服务器实例之上。例如,在一个三节点群集中,让我们来假设每个节点的加权为 1。每个节点将代表该服务对所有客户机请求 的 1/3 进行服务。加权可以在任何时候由管理员通过 scrgadm(1M) 命令接口进行修改。
粘滞服务有两种风格,普通粘滞和通配粘滞。粘滞服务允许多个 TCP 连接 上并行的应用程序级会话来共享“状态内”内存(应用程序会话状态)。
普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。相对于正在监听单个端口的服务器实例,可以该客户机 说成是“粘滞的”。假定实例保持打开状态并可访问,并且在服务处于联机状态时负载平衡策略不 更改,将保证该客户机的所有服务请求都传给相同的服务器实例。
例如,客户机的 Web 浏览器连接到使用三种不同 TCP 连接,连接到端口为 80 的共享 IP 址,但连接在服务时正在它们之间 交换已缓存的会话信息。
粘滞策略的普遍化延伸到在相同实例场景后面交换会话信息的多个可伸缩服务。当这些服务在相同实例场景后面交换 会话信息时,相对于在不同端口上监听的相同节点上的多个服务器实例来说,可以说客户机是“粘滞的”。
例如在一个电子商务站点上,顾客使用端口 80 上的普通 HTTP 购买了许多商品并放入到购物车中,但是要切换到 端口 443 上的 SSL,以发送安全数据,使用信用卡付款。
通配粘滞服务使用动态分配的端口号,但仍期望客户机请求去往相同的节点。相对于相同的 IP 地址来说,客户机就是端口 上的“粘滞通配”。
被动模式 FTP 是这一策略的一个好例子。客户机连接到端口 21 上的 FTP 服务器,并接着被服务器通知须连接回到动态 端口范围中的收听器端口服务器。此 IP 地址的所有请求都被转发到服务器通过控制信息通知客户的相同节点上。
请注意,对于每个粘滞策略,加权的负载平衡策略都缺省生效的,从而使客户的最初请求被定向到由负载平衡程序指定的 实例。在客户机已经为正运行着实例的节点建立一种亲密关系 之后,只要该节点可访问并且负载平衡策略未更改,以后的请求就会定向到此实例。
关于特定的负载平衡策略的补充详细信息在下面进行讨论。
加权的. 根据指定的加权值在各种节点间分配负载。此策略是 使用 Load_balancing_weights 属性的 LB_WEIGHTED 值设 置的。如果一个节点的加权未明显地设置,则会使用此节点的缺省加权值 1。
注意这一策略不是循环共享的。循环共享策略总是会使来自客户机的每个请求到达不同的节点:第一个请求到达 节点 1,第二个请求到达节点 2,以此类推。这种加权策略保证了来自客户机的一定比例的流量直接到达特定的节点。此策略不对个别 请求寻址。
粘滞的. 在此策略中,端口的设置在配置应用程序资源时就已经知道了。此策 略是使用 Load_balancing_policy 资源属性的 LB_STICKY 值设置的。
粘滞通配符. 此策略是普通“粘滞”策略的超集。对于由 IP 地址识别的可伸缩服务,端口由服务器来 分配(并且事先不知道)。端口可能会变化。此策略是使用 Load_balancing_policy 资源属性 的 LB_STICKY_WILD 值设置的。