池组是一个服务器池列表,并包含从列表中选择服务器池的逻辑。只要虚拟服务可以引用服务器池(直接或通过规则、DataScript 或服务端口池选择器),虚拟服务就可以改为引用池组。

注:

池选择通常称为池切换。

池组是一种强大的结构,可用于实现以下功能:

  • 优先级池/服务器

  • 备份池

  • A/B 池

  • 蓝/绿部署

  • Canary 升级

注:

IPv6 不支持该功能。

什么是池组?

池组是一个成员(服务器)列表,并包含从列表中选择成员的逻辑。PoolGroup 对象表示为三元组 { Priority, Pool, Ratio } 列表,每个元组描述一个成员。例如,定义下面所述的池组需要一个具有 9 个三元组的 PoolGroup 对象。



池组的工作方式

让我们使用图 1 描述使用上面图表的典型场景。

在负责虚拟服务的服务引擎需要确定将特定客户端请求传送到的服务器时,可以使用以下步骤。

  • 步骤 1:确定组中的最佳池。这是由池优先级控制的。这个由 9 个成员组成的组定义了三个优先级(high_pri、med_pri 和 low_pri),而 pool1、pool2 和 pool3 是首选(最佳)的池,因为为它们分配了最高优先级。NSX Advanced Load Balancer 将尽量选择其中的一个池。

  • 步骤 2:确定最高优先级的池之一。该选择是由分配给三个池成员的权重控制的,即 weight_1、weight_2 和 weight_3。这些权重表示的比率控制传送到每个池成员的流量百分比。

  • 步骤 3:确定一个具有所选池的服务器。可以为 9 个成员中的每一个成员配置不同的负载均衡算法。与所选池关联的算法控制选择它的哪个服务器。

持久性的影响

上面我们介绍了该算法,因为它最初和以后将应用于客户端请求,但没有介绍持久性的影响。不过,如果为每个池配置了持久性(如果可能),持久性将对来自给定客户端的第 2 到第 n 个请求产生颠覆性的影响。

要在池中启用持久性,请导航到应用程序 > > 编辑池 > 设置,然后从提供的持久性下拉菜单中选择一个持久性。

池还是池组?

可以在虚拟服务上将池和池组互换使用。如果您预计将来需要解决它的任何用例问题,请使用池组。您将会从它的灵活性中受益,而不会中断现有的流量。在池组成员资格发生变化时,不会造成流量中断。即使从池组中移除了现有池成员,到该池成员中的服务器的连接也不会中断。同样,可以动态扩展池组。

如果预计不会使用池组的功能,请使用池。完成工作的简单池比池组更高效。它避免配置额外的完整 uuid 对象,从而消耗更少的 SE 和控制器内存。

注:

符合作为池组成员条件的池列表将排除与其他虚拟服务关联的池。

配置

考虑一个包含两个池的池组,以下是配置该功能的步骤:

创建池

导航到应用程序 > > 创建池,以创建将附加到池组的各个池。已在此处创建 pool-1、pool-2 和 cart2 池。



有关配置池设置的更多信息,请参见服务器池

创建池组

  1. 导航到应用程序 > 池组 > 创建池组



  2. 池组成员部分中,将以前创建的池添加为成员池或创建新的成员池。请注意,此处为每个池分配了优先级。



  3. 单击 + 添加池组成员

    1. 下拉菜单中选择/创建一个池。

    2. 输入 1 到 1000 之间的比率

    3. 选择一个具有较高优先级的池。

    4. 从下拉菜单中选择一种部署状态。部署状态选项包括:

      1. 评估失败

      2. 正在评估

      3. 正在服务

      4. 服务中断

  4. 池服务器部分中,指定池组的可选设置:

    1. 启用 HTTP2 - 选择该选项,以便为从虚拟服务到该池组上配置的所有池中的所有后端服务器的流量启用 HTTP/2。

      最小服务器数 - 将流量分配到的最小服务器数。您可以输入 1 到 65535 之间的范围。

  5. 池组故障设置部分中,指定在池组发生故障时执行的操作。可以将以下三个选项作为故障操作:

    1. 关闭连接 - 如果池中的所有服务器都关闭,虚拟服务的默认行为是发出 TCP 重置或丢弃 UDP 数据包以关闭新的客户端连接尝试。不会终止现有的连接,即使它们的服务器标记为关闭。假设服务器可能很慢,但仍然能够继续处理现有的客户端连接。

    2. HTTP 本地响应 - 返回简单的网页。指定状态代码 200 或 503。如果尚未将自定义 HTML 文件上载到 NSX Advanced Load Balancer,它将返回包含错误代码的基本页面。

      1. 状态代码 - 从下拉菜单中选择 200503

    3. HTTP 重定向 - 返回重定向 HTTP 响应代码,包括指定的 URL。

      1. 状态代码 - 从下拉菜单中选择 301、302 或 307。

      2. HTTP/HTTPS - 默认情况下,NSX Advanced Load Balancer 将通过 HTTPS 进行重定向,除非单击了 HTTP。

      3. URL - 输入 domain.com/path/file?query=bbb 格式的 URL。

        注:

        默认情况下,将选择关闭连接

  6. 选择/创建一个池组部署策略。在满足池组部署策略中定义的部署目标时,自动缩放管理器自动将新池升级为生产池。

  7. 基于角色的访问控制 (RBAC) 部分中,单击添加

    1. 输入密钥和相应的

      要了解配置标签的更多信息,请参见“每个应用程序的基于角色的精细访问控制”。

将池组附加到虚拟服务

  1. 创建一个虚拟服务(在高级模式下),并配置其池设置以包括一个池组,如下所示:



  2. 导航到应用程序 > 创建虚拟服务 > 高级设置 > 新建虚拟服务

    1. 步骤 1:设置选项卡下面,选择池组单选按钮以将以前创建的池组附加到虚拟服务。

    2. 将附加池组,并且虚拟服务处于活动状态,如下所示:



  3. 要查看虚拟服务和池组的总体设置,请导航到应用程序 > 仪表板,然后从查看 VS 列表下拉菜单中选择 VS 树

注:

池组不支持缓存。

用例

优先级池/服务器

考虑一个池具有不同类型的服务器的情况 - 非常强大的新服务器、较慢的旧服务器以及非常慢的旧服务器。在图中,假设蓝色池由功能强大的新服务器组成,绿色池具有较慢的旧服务器,而粉色池具有最旧的服务器。还会注意到,为它们分配了从 high_pri 到 low_pri 的优先级。这种分配方式导致 NSX Advanced Load Balancer 尽量(可能总是)选择 3 个蓝色池中的较新服务器。只有在找不到任何最高优先级池中的服务器时,NSX Advanced Load Balancer 才会向较慢的成员发送一些流量(按优先级排序)。

以下一种或多种情况将触发这种替代选择(选择优先级较低的池):

  1. 找不到正在运行的服务器。

  2. 与 1 类似,给定优先级的服务器不接受额外的连接。所有候选的服务器已饱和。

  3. 给定优先级的池均未运行为其配置的最小数量的服务器。

操作说明

  • 建议将优先级间隔开以留出空隙。这样,以后就可以更轻松地添加中间优先级。

  • 对于纯优先级用例,池组的比率是可选的。

  • 如果将池的比率设置为 0,将导致不会向该池发送任何流量。

  • 对于每个池,将执行正常的负载均衡。在 NSX Advanced Load Balancer 为新会话选择池后,将使用为该池配置的负载均衡方法选择服务器。

优先级池的示例配置

如果仅启用了三个池,每个池具有不同的优先级,则不会使用“比率”列中的值选择池。除非出现上述三种情况中的任何情况,否则,将始终选择 cart2。



备份池

在“池组”一节中介绍了现有的备份池实施。将备份池指定为池关闭/失败操作的现有选项已弃用。相反,请配置一个具有两个或更多池的池组,每个池具有不同的优先级。只要在最高优先级的池中具有可用的服务器,就会选择该池(与前面提到的三种情况保持一致)。

操作说明

  • 具有较高优先级值的池被视为更好的池,只要具有最高优先级的池已启动并满足最小服务器数要求,就会将流量发送到该池。

  • 建议将优先级间隔开以留出空隙。这样,以后就可以更轻松地添加中间优先级。

  • 对于组的每个池成员,将执行正常的负载均衡。在 NSX Advanced Load Balancer 为新会话选择池后,将使用为该池配置的负载均衡方法选择服务器。

  • 添加或移除备份池不影响池组中的其他池上的现有会话。

备份池的示例配置

  1. 创建一个池组“backup”,它具有两个成员池 - 优先级为 10 的 primary-pool 和优先级为 3 的 backup-pool。



对象详细信息:

{
     url: "https://10.10.25.20/api/poolgroup/poolgroup-f51f8a6b-6567-409d-9556-835b962c8092",
     uuid: "poolgroup-f51f8a6b-6567-409d-9556-835b962c8092",
     name: "backup",
     tenant_ref: "https://10.10.25.20/api/tenant/admin",
     cloud_ref: "https://10.10.25.20/api/cloud/cloud-3957c1e2-7168-4214-bbc4-dd7c1652d04b",
     _last_modified: "1478327684238067",
     min_servers: 0,
     members:
    [
        {
            ratio: 1,
            pool_ref: "https://10.10.25.20/api/pool/pool-4fc19448-90a2-4d58-bb8f-d54bdf4c3b0a",
            priority_label: "10"
        },
        {
            ratio: 1,
            pool_ref: "https://10.10.25.20/api/pool/pool-b77ba6e9-45a3-4e2b-96e7-6f43aafb4226",
            priority_label: "3"
        }
    ],
    fail_action:
    {
        type: "FAIL_ACTION_CLOSE_CONN"
    }
}

A/B 池

NSX Advanced Load Balancer 支持指定一组可视为等效池的池,并按定义的比率将流量发送到这些池。

例如,可以为虚拟服务配置一个具有两个池(A 和 B)的优先级组。此外,用户可以指定发送到 A 的流量比率为 4,发送到 B 的流量比率为 1。

A/B 池功能有时称为蓝/绿测试,它提供了一种简单方法,以将虚拟服务的流量从一组服务器逐渐过渡到另一组服务器。例如,要在虚拟服务的主池 (A) 中测试重大操作系统或应用程序升级,可以为主池添加运行升级的版本的第二个池 (B)。然后,根据配置,将一定比率 (0-100) 的客户端到服务器流量发送到 B 池而不是 A 池。

接着前面的示例,如果升级正常运行,NSX Advanced Load Balancer 用户可以增加发送到 B 池的流量比率。同样,如果升级失败或效果不佳,可以轻松再次降低发送到 B 池的比率以测试替代升级。

要在成功升级后完成过渡到新池的过程,可以调整比率以将所有流量发送到该池,从而使池 B 现在成为生产池。

要执行下一次升级,可以颠倒该过程。在升级池 A 后,可以降低发送到池 B 的流量比率以测试池 A。要完成升级,可以将发送到池 B 的流量比率降回到 0。

操作说明

  • 如果将池的比率设置为 0,将导致不会向该池发送任何流量。

  • 对于每个池,将执行正常的负载均衡。在 NSX Advanced Load Balancer 为新会话选择池后,将使用为该池配置的负载均衡方法选择服务器。

  • A/B 设置不会影响现有的会话。例如,如果将发送到 B 的比率设置为 1 并将发送到 A 的比率设置为 0,并不会导致池 A 上的现有会话移动到 B。同样,A/B 池设置不会影响持久性配置。

  • 如果某个具有非零比率的池关闭,新流量将平均分配给其余池。

  • 对于纯 A/B 用例,池组的优先级是可选的。

  • 可以将池组默认应用于虚拟服务,也可以将其附加到规则、DataScript 和服务端口池选择器。

A/B 池的示例配置

  1. 创建一个池组‘ab’,其中包含两个池(a-pool 和 b-pool)而未指定任何优先级:



    在该示例中,将 a-pool 和 b-pool 的比率分别设置为 10 和 1,以将 10% 的流量发送到 b-pool。

  2. 将该池组应用于要使用 A/B 功能的 VS:



对象详细信息:

{
    url: "https://

    
      /api/poolgroup/poolgroup-7517fbb0-6903-403e-844f-6f9e56a22633", uuid: "poolgroup-7517fbb0-6903-403e-844f-6f9e56a22633", name: "ab", tenant_ref: "https://
     
       /api/tenant/admin", cloud_ref: "https://
      
        /api/cloud/cloud-3957c1e2-7168-4214-bbc4-dd7c1652d04b", min_servers: 0, members: [ { ratio: 10, pool_ref: "https://
       
         /api/pool/pool-c27ef707-e736-4ab6-ab81-b6d844d74e12" }, { ratio: 1, pool_ref: "https://
        
          /api/pool/pool-23853ea8-aad8-4a7a-8e9b-99d5b749e75a" } ], }
        

其他用例

蓝/绿部署

这是一种发行方法,它运行两个完全相同的生产环境以减少停机和降低风险,在任何时间,仅一个环境(例如,蓝色)处于活动状态并处理所有生产流量。在准备发行新版本时,将在非活动环境(例如,绿色)中进行部署和最后阶段测试。在对绿色环境感到满意后,可以将所有入站请求发送到绿色环境而不是蓝色环境。绿色环境现在处于活动状态,蓝色环境处于空闲状态。这种方法消除了由于应用程序部署而导致的停机。此外,如果绿色环境中的新版本发生意外情况,将立即回滚到上一个版本;直接切换回蓝色环境。

Canary 升级

这种升级方法之所以这样命名,是因为它类似于矿工的金丝雀 (Canary),金丝雀将会在任何人可能受到影响之前检测到有毒气体。这种升级的思路是,在执行系统更新或更改时,先更新一组有代表性的服务器,在一段时间内对其进行监控/测试,然后才在其余服务器上进行滚动更改。