Create a Listener

On the main menu of ZStack Cloud, choose Resource Center > Network Service > Basic Network Service > Load Balancing. On the load balancer management page, click the target load balancer. On the details page of the load balancer, click the Listener tab. On the tab, click Create Listener. The Create Listener page appears.

On the displayed page, set the following parameters:
  • Name: Enter a name for the listener.
  • Description: Optional. Enter a description for the listener.
  • Protocol: Select a listening protocol. Valid values: TCP, HTTP, HTTPS, and UDP.
    • If you select TCP, HTTP, or UDP, you can select a port that ranges from 1 to 65535.
    • If you select HTTPS:
      • You can select a port that ranges from 1 to 65535.
      • You need to associate the listener with a certificate. You can upload a certificate or certificate chain. For more information, see Create a Certificate.
      • Certificate: Associate a certificate with the listener.
  • Load Balancer Algorithm: Set a routing rule for data packets. Default: Round Robin.
    The following lists the supported load balancing algorithms:
    • Round Robin:

      The Round Robin algorithm evenly distributes external requests to each VM instance in sequence that is specified by the load balancing rule regardless of the established connections or system loads of a VM instance.

    • Min Connections:

      The Min Connections algorithm dynamically distributes external requests to VM instances that have established least connections. If VM instances in the cluster have similar system performance, you can use this algorithm to achieve even distribution of workloads.

    • Source IP Hash:

      The Source IP Hash algorithm uses a source IP address as a hash key and maps the hash key to a VM instance based on the mapping in the static hash table. If the VM instance is available and is not overloaded, requests are sent to the instance. Otherwise, no VM instance is returned to handle the requests.

    • Weighted Round Robin:

      The Weighted Round Robin algorithm is generated by combining the Round Robin algorithm with the Weighted algorithm. It assigns a weight to each VM instance and distributes more requests to VM instances with a higher weight. Requests are more likely to be distributed to VM instances with a higher weight.

  • Load Balancer Port: Specify a port for load balancing. Valid values: 1 to 65535.
  • Backend Server Port: Specify a backend server port. Valid values: 1 to 65535.

    For example, if you specify port 80 as the load balancing port and port 5000 as the backend server port, requests sent to port 80 of the load balancer (LB) virtual IP address are distributed to the port 8000 of backend servers.

  • Backend Server Group: Optional. Select a backend server group.
    Note:
    • A backend server group is a group of backend servers that share the same configurations. You can associate one or more listeners with a backend server group. The listeners distribute traffic based on the weight that you assign to each backend server.
    • You can associate a listener with one or more backend server groups that are attached to the same LB.
    • If a backend server is added to multiple backend server groups, you cannot associate the same listener with these backend server groups.
    • After you associate a listener with a backend server group, you can view the health status of the backend server group on the details page of the listener. A backend server group may be in Healthy or Unhealthy status.
  • Advanced: Configure advanced settings for the listener.
    • Health Check Protocol: Set the health check protocol. Valid values: TCP, HTTP, and UDP. You can select a protocol different from the listening protocol.
      • If you select TCP, HTTP, or HTTPS as the listening protocol, you can select TCP or HTTP as the health check protocol.
      • If you select UDP as the listening protocol, you can select UDP as the health check protocol.
      • If you select HTTP as health check protocol, you can configure normal status code, health check URI, and HTTP health check method:
        • Normal Status Code: The HTTP status code returned when the health check passes. You can select one or more status codes. Valid values: http_2xx, http_3xx, http_4xx, and http_5xx.
        • Health Check URI: The URI of the page on which health checks are performed, for example, /healthcheck.html.

          A health check on static pages is recommended. When you set a health check URI, make sure that:

          • The URI must be 2 to 80 characters long.
          • The URI can contain only letters, digits, hyphens (-), forward slashes (/), periods (.), percentage signs (%), question marks (?), number signs (#), ampersands (&),or a combination of these characters.
          • The URI must start with a forward slash (/) but it cannot contain only forward slashes.
        • HTTP Health Check Method: The method used to perform HTTP health checks on server applications. Valid values: HEAD and GET. Default: HEAD. The health check requests simulate the access requests of a browser.
    • Idle Connection Timeout: The amount of time that the load balancer terminates the connection between the server and the client when no data is transmitted. Default value: 60 seconds.
    • Healthy Threshold: The maximum number of consecutive successful health checks required for a unhealthy backend server to be considered healthy. Default value: 2.
    • Health Check Port: The health check port. Default: default. This value indicates that the health check port is the same as the specified backend server port. You can also specify another port.
    • Unhealthy Threshold: The maximum number of consecutive failed health checks required for a healthy backend server to be considered unhealthy. Default value: 2.
    • Health Check Interval: The time interval between each health checks of an individual backend server. Default value: 5 seconds.
    • Maximum Concurrent Requests: The maximum number of concurrent connection requests of the listener. Valid values: 1 to 2000000. Default: 2000000.
      Note: The memory usage of a running load balancer is associated with the maximum concurrent requests. Excessively high memory usage may cause the out of memory (OOM) error. Set the parameter based on the actual memory size. For example, if you set the maximum concurrent requests of a listener to 2,000,000, the memory usage of the load balancer listener is around 200 MB.
    • Processes: The number of HAProxy processes. Default: 1.

      Using multiple processes can improve the listener performance and increase listening concurrency. However, multiple processes might occupy more memory and affect the listening accuracy.

    • HTTP Mode: The HTTP connection mode of the load balancer. This option is available only when the listening protocol is HTTP.
      • http-server-close: The server-facing connection is closed after the end of the response is received, and the client-facing connection remains open.
      • http-keep-alive: All requests and responses are processed, and connections remain open but idle between responses and new requests.
      • http-tunnel: Only the first request and response are processed and a tunnel is established between the client and the server, so that they can talk without further analysis of HTTP protocol. This mode is not recommended.
      • httpclose: The same as tunnel mode, but with a Connection: close header field appended in both the client and server directions. This mode is not recommended.
      • forceclose: Both the client and the server connections are actively closed by the load balancer after the end of a response.
    Figure 1. Create a Listener