gRPC is a high-performance, open-source software framework developed by Google based on the HTTP 2.0 transport layer protocol. The framework provides methods for configuring and managing network devices in multiple programming languages. This document describes how to configure gRPC health check for the HTTPS listener of a CLB instance to forward client gRPC requests to real servers that use the gRPC protocol.
Use Cases
When a client sends HTTPS requests to access real servers that use the gRPC protocol, you can configure gRPC health check for the HTTPS listener of the CLB instance to implement the access.
Prerequisites
You have created a VPC. For more information, see Creating VPC.
You have created a CVM instance (used as a real server) in the VPC, and deployed a gRPC service on the instance. For more information, see Creating Instances via Images.
This feature is supported only by CLB but not classic CLB.
This feature is not supported by CLB for IPv6 and CLB for IPv6 with layer-7 mixed binding enabled.
This feature is only supported by VPC but not classic networks.
Real servers do not support SCF. (Support for the gRPC protocol within the SCF target is required.)
Directions
Step 1. Configure a listener
1. Log in to the CLB console and click Instance management in the left sidebar.
2. Select your region in the top-left corner of the Instance management page and click Configure listener in the Operation column of your CLB instance.
3. Under HTTP/HTTPS listener, click Create and configure the HTTPS listener in the pop-up window.
3.1 Create a listener
Parameter
Description
Example
Name
Listener name.
test-https-443
Listening protocol and port
Listening protocol: HTTPS is used in this example.
Listening port: The port used to receive requests and forward them to a real server. Port range: 1-65535.
The listening port must be unique in the same CLB instance.
HTTPS:443
Enable persistent connection
Once this feature is enabled, persistent connections will be used between a CLB instance and real servers, and the CLB instance will no longer pass through the source IP address that can be obtained from XFF. To ensure normal forwarding, enable the "Allow Traffic by Default" feature in the CLB security group or allow 100.127.0.0/16 in the CVM security group.
Note:
Once this feature is enabled, the number of the connections between a CLB instance and real servers will fluctuate in the range of [QPS,QPS*60], subject to the connection reuse rate. If there is a limit on the maximum number of connections, we recommend you be cautious when enabling this feature. This feature is currently in beta test. To try it out, submit a ticket.
The IP range 100.64.0.0/10 is already allowed as the health check source IP. You don't need to allow IPs within this range again.
Disabled
Enable SNI
If SNI is enabled, multiple domain names of a listener can be configured with different certificates; if it is disabled, multiple domain names of a listener can be configured with one certificate only.
Disabled
SSL parsing
One-way authentication and mutual authentication are supported. CLB takes over the overheads of SSL encryption and decryption to guarantee the access security.
If all domain names of a listener are not matched, the system distributes requests to the default domain name, making default access controllable.
Each listener can be configured with one default domain name only.
Enabled
HTTP 2.0
After HTTP 2.0 is enabled, CLB instances can receive HTTP 2.0 requests. CLB instances access real servers over HTTP 1.1 no matter what HTTP version the client uses to access CLB instances.
Enabled
QUIC
After QUIC is enabled, a client can establish a QUIC connection with a CLB instance. If the QUIC connection fails due to negotiation between the client and the CLB instance, HTTPS or HTTP/2 will be used. However, the CLB instance and the real server still use the HTTP 1.x protocol. For more information, see Using QUIC Protocol on CLB.
For HTTPS listeners, CLB supports three scheduling algorithms: weighted round robin (WRR), weighted least connections (WLC), and IP Hash.
WRR: Requests are distributed to real servers in sequence based on their weights. This algorithm performs scheduling based on the number of new connections. Servers with higher weights are more likely to be scheduled and servers with the same weight process the same number of connections.
WLC: Loads of servers are estimated based on the number of active connections to the servers. This algorithm performs scheduling based on server loads and weights. For servers with the same weight, those have less loads are more likely to be scheduled.
IP Hash: This algorithm uses a request source IP address as the Hash key to locate the corresponding server in the static hash table. If a server is available and not overloaded, requests will be distributed to it; otherwise, a null value will be returned.
WRR
Backend Protocol
Backend protocol is used between a CLB instance and a real server:
If HTTP is selected as the backend protocol, the HTTP service must be deployed on the real server.
If HTTPS is selected as the backend protocol, the HTTPS service must be deployed on the real server. In this case, encryption and decryption of the HTTPS service will consume more resources on the real server.
If gRPC is selected as the backend protocol, the gRPC service must be deployed on the real server. You can select gRPC as the backend forwarding protocol only when HTTP2.0 is enabled and QUIC is disabled.
After session persistence is enabled, a CLB listener will distribute access requests from the same client to the same real server.
TCP session persistence is implemented based on client IP address. The access requests from the same IP address are forwarded to the same real server.
Session persistence can be enabled for WRR scheduling but not WLC scheduling.
Enabled
Hold Time
Session persistence is terminated if there are no new requests in the connection within the specified duration.
Value range: 30-3600 seconds
30 seconds
Step 2. Bind a real server
1. On the Listener management page, select the created listener HTTPS:443. Click + on the left to expand the domain names and URL paths, select the desired URL path, and view the real servers bound to the path on the right of the listener.
2. Click Bind, select the target real server, and configure the server port and weight in the pop-up window.
Note:
If you set Default port first and then select real servers, the port of every real server is the default port.
Step 3. Configure a security group (optional)
You can configure a CLB security group to isolate public network traffic. For more information, see Configuring a CLB Security Group.
Step 4. Modify or delete a listener (optional)
If you need to modify or delete a created listener, click the listener on the Listener management page and click
Yes
No
Was this page helpful?