ZStack Logo

ZStack AIOS

创建监听器

完整平台用户手册，包含基础云平台能力与 AIOS 相关章节。

在ZStack Cloud主菜单，点击资源中心 > 网络服务 > 基础网络服务 > 负载均衡，进入负载均衡界面。点击某一负载均衡，进入其详情页。在监听器子页面，点击创建监听器，弹出创建监听器界面。

可参考以下示例输入相应内容：
  • 名称：设置监听器名称
  • 简介：可选项，可留空不填
  • 协议：选择监听器协议类型，包括：TCP、HTTP、HTTPS、UDP
    • 如选择TCP/HTTP/UDP：支持1-65535端口
    • 如选择HTTPS：
      • 支持1-65535端口。
      • 需绑定证书使用，支持上传证书和证书链。如何上传及管理证书可参考创建证书和管理证书章节。
      • 证书：必选项，创建监听器选择HTTPS时必须绑定证书。
  • 负载均衡端口：可从1-65535端口之间选择一个端口作为负载均衡器虚拟IP地址的端口
  • 后端服务器端口：可从1-65535端口之间选择一个端口作为后端服务器端口

    例如：负载均衡端口选择80，后端服务器端口选择5000，表示对负载均衡器对应虚拟IP地址80端口的访问会转发到后端服务器的5000端口。

  • 负载均衡算法：对网络包设定不同的路由规则，默认为轮询
    支持的负载均衡算法包括：
    • 轮询：

      按照顺序轮流分配访问请求至后端服务器。轮询是最简单的一个算法，无须关注后端服务器本身的连接数和系统负载等状态，主要应用于各个后端服务器性能差异不大的场景。

    • 最小连接：

      将新的连接请求分配到当前连接数最小的后端服务器，适用于请求占用后端服务器时间相差较大的场景，常用于长连接服务。

    • 源地址哈希：

      使用客户端请求的源 IP 地址与目标 IP 地址生成唯一的哈希密钥，将客户端请求分配给特定的后端服务器。源地址哈希适合后端服务器需处理客户端请求差异较大的场景。

    • 加权轮询：

      根据后端服务器权重转发访问请求。一般情况下，权重基于硬件配置进行设置，为静态值。权重值越高，被轮询的次数（概率）越高。加权轮询是轮询的一种特殊形式，主要应用于各个后端服务器性能差异较大的场景。

  • 会话保持：负载均衡上的一种机制，可识别客户端与后端服务器之间交互关联性，将客户端访问请求定向转发至特定的后端服务器，保证业务会话连续性
    平台支持基于TCP/UDP协议的四层会话保持机制和基于HTTP/HTTPS协议的七层会话保持机制：
    • 四层会话保持机制：负载均衡将同一个源IP地址的访问请求都转发至一台后端服务器上。
    • 七层会话保持机制：不同负载均衡算法下，七层会话保持机制不同。
      • 轮询算法或加权轮询算法使用基于Cookie的会话保持机制，负载均衡可通过Cookie将访问请求定向转发至之前记录的后端服务器。
      • 源地址哈希算法通过哈希函数计算客户端源IP地址，同一个源IP地址的访问请求都将转发至一台后端服务器上。
    说明：
    • 选择基于TCP/UDP协议的四层会话保持机制时：若选择源地址哈希算法，默认打开会话保持，且不可关闭；若选择其他负载均衡算法，默认关闭会话保持，且不可打开。
    • 选择基于HTTP/HTTPS协议的七层会话保持机制时： 若选择源地址哈希算法，默认打开会话保持，且不可关闭； 若选择最小连接算法，默认关闭会话保持，且不可打开。
    • 选择基于HTTP协议的七层会话保持机制时：若选择轮询或加权轮询算法，且选择重写Cookie的方式，HTTP模式不支持http-tunnel。
  • Cookie处理方式：若打开基于HTTP/HTTPS的七层会话保持，且选择轮询/加权轮询算法，需设置Cookie处理方式。支持植入Cookie和重写Cookie两种方式
    • 植入Cookie：负载均衡在后端服务器返回给客户端的响应报文中植入Cookie，下次客户端携带此Cookie访问时，负载均衡将访问请求定向转发至之前记录的后端服务器
      • 会话保持超时时间：设置客户端和后端服务器会话保持的超时时间，默认为 60 秒，可选范围为 30-3600 秒
    • 重写Cookie：用户在后端服务器返回给客户端的响应报文中自定义Cookie后，由负载均衡进行重写，下次客户端携带此Cookie访问时，负载均衡将访问请求定向转发至之前记录的后端服务器
      • Cookie名称：设置Cookie名称。长度为1-20个英文字符，可包括英文字母、数字、下划线（_）或连字符（-）
  • 后端服务器组：选择后端服务器组
    说明：
    • 后端服务器组为具有相同配置的后端服务器集合，方便加载到多个监听器。监听器根据权重分配来自用户的流量。
    • 一个监听器可绑定同一负载均衡下的多个后端服务器组。
    • 若不同的后端服务器组拥有同一个后端服务器，不支持将这些后端服务器组同时绑定同一个监听器。
    • 后端服务器组加载监听器后，可在监听器的详情页查看某个后端服务器的健康状态，包括：健康、不健康。
  • 高级设置：可对高级选项进行设置
    • HTTP重定向：监听器协议为HTTP时，支持开启HTTP重定向，将所有访问该监听器的流量自动转发到使用HTTPS协议的监听器处理
      说明：
      • 如已开启会话保持，将无法开启HTTP重定向。
      • 开启HTTP重定向前，需确保当前负载均衡中已有HTTPS监听器用于处理转发后的流量。
      • 开启HTTP重定向后，该监听器上的其他配置将全部无法生效，如健康检查、转发规则等，因为相关流量将转由目的HTTPS监听器处理。如仍需使用这些配置，请将它们添加到HTTPS监听器上。
    • 目的监听端口：指定HTTPS监听器端口，用于处理重定向后的流量
    • 重定向状态码：选择重定向状态码，支持以下五种状态码，默认值为302：
      • 301：永久重定向，告知用户所请求的资源已被永久移动到新位置。客户端会缓存该新位置，并在下次请求发生时直接访问新位置。
      • 302：临时重定向，告知用户所请求的资源暂时被移动到新位置。客户端不会缓存该新位置，下次请求发生时，仍将首先访问旧位置。
      • 303：查看其他位置，与302相似，但客户端必须使用GET方式获取新位置，该状态码常用于在POST请求后需跳转到GET请求的场景。
      • 307：临时重定向，与302相似，但客户端访问新位置的请求方式与访问旧位置的请求方式必须相同。
      • 308：永久重定向，与301相似，但客户端访问新位置的请求方式与访问旧位置的请求方式必须相同。
    • 健康检查协议：设置健康检查协议，支持：TCP/HTTP/UDP，可与监听协议使用不同的协议
      • 若监听协议为TCP/HTTP/HTTPS，健康检查协议支持TCP/HTTP。
      • 若监听协议为UDP，健康检查协议支持UDP。
      • 若使用HTTP健康检查协议，支持配置正常状态返回码、健康检查URI和HTTP健康检查方法：
        • 正常状态返回码：HTTP协议健康检查正常的HTTP状态码，支持多选。包括：http_2xx、http_3xx、http_4xx、http_5xx
        • 健康检查URI：用于健康检查页面文件的URI（例如：/healthcheck.html）

          建议对静态页面进行检查，设置规则如下：

          • 长度限制为2~80字符。
          • 只能使用字母、数字或规定符号 - / . % ? # & 的组合。
          • 必须以 / 开头，但不能全为 / 。
        • HTTP健康检查方法：通过发送HEAD/GET请求模拟浏览器的访问行为来检查服务器应用是否健康，默认为HEAD方式
    • 空闲连接超时：没有数据传输时，触发负载均衡器终止服务器和客户端连接的超时时间，默认为60秒
    • 健康检查阈值：若不健康的后端服务器连续检查成功次数超过阈值，则认定为健康，默认为2次
    • 健康检查端口：默认为default，表示健康检查端口与指定后端服务器端口一致，支持指定其它端口
    • 非健康检查阈值：若健康的后端服务器连续检查失败次数超过阈值，则认定为不健康，默认为2次
    • 健康检查间隔时间：对后端服务器进行检查的时间间隔，设置范围默认为5秒
    • 最大并发请求连接数：设置监听器最大并发请求连接数，设置范围1~2000000，默认为2000000条
    • 进程数量：HAProxy进程的数量，默认为1

      使用多个进程可提高监听器的性能与监听数据的并发量，但同时可能会占用更多内存，并在一定程度上影响监控数据的准确性。

    • 协议版本：支持选择 HTTP1.1 和 HTTP2.0，默认为 HTTP1.1
    • IP透传：默认关闭开关。开启后，支持通过Proxy Protocol协议携带客户端源地址到后端服务器
      说明： 后端服务器需启用Proxy Protocol，否则将导致和实例通信协商失败。
      • IP透传协议版本：默认为v1，IP透传协议版本支持v1和v2
    • HTTP模式：负载均衡器的HTTP连接模式，仅支持HTTP协议
      • http-server-close：收到响应结束信息后，关闭面向服务器的连接，并将面向客户端的连接保持打开状态。
      • http-keep-alive：处理所有请求和响应并将连接保持打开状态，但在响应和新请求之间闲置一段时间。
      • http-tunnel：仅处理第一个请求和响应，并在客户端和服务器之间建立隧道，以使它们能够进行通信，而无需进一步分析HTTP协议。该模式不推荐使用。
        说明： 该模式不支持基于轮询/加权轮询算法与重写Cookie机制组合的HTTP会话保持机制。
      • httpclose：与隧道模式相同，但在客户端和服务器方向添加Connection: close标头。该模式不推荐使用。
      • forceclose：在响应结束后，负载均衡器主动关闭客户端和服务器的连接。
    • 数据压缩：默认关闭开关。开启后，支持对特定文件类型进行压缩，通过数据压缩可缩小传输文件大小，提升文件传输效率，减少带宽消耗

      支持压缩的类型包括：text/xml、text/plain、text/css、application/javascript、application/x-javascript、application/rss+xml、application/atom+xml、和 application/xml

      • 数据压缩算法：默认为 gzip 算法，数据压缩支持gzip、deflate、raw-deflate三种算法
        • gzip：最广泛使用的 HTTP 内容编码方式之一，基于 DEFLATE 算法实现压缩。
        • deflate：实际应用于 gzip 和其他压缩格式的一种具体的压缩算法，是 LZ77（Lempel-Ziv）算法与哈夫曼编码的组合。
        • raw-deflate：仅使用 DEFLATE 算法压缩后的数据，而不包括任何额外的文件头或者尾部信息。
        说明： 选择deflate和raw-deflate算法时，需确保客户端和后端服务器均能够正确处理这些压缩格式，否则可能造成数据无法解压或显示异常的问题
    如图1所示：


    图1 创建监听器