This document describes how to create a public network Classic CLB instance named clb-test and forward requests from clients to two real servers.
Prerequisites
1. CLB only forwards traffic but cannot process requests; therefore, you need to have a CVM instance that processes user requests.
In this example, two CVM instances are enough, but you can also configure more instances. CVM instances rs-1 and rs-2 have been created in the Guangzhou region in this example. For more information on how to create a CVM instance, please see Purchasing and Launching CVM Instances.
2. This document takes HTTP forwarding as an example. The corresponding web server (such as Apache, Nginx, or IIS) must be deployed on the CVM instance.
To verify the result, in this example, Apache is deployed on both rs-1 and rs-2. Apache returns "Hello Tomcat! This is rs-1!" on rs-1 and "Hello Tomcat! This is rs-2!" on rs-2. For more information on how to deploy components on a CVM instance, please see Deploying Java Web on Linux (CentOS) and Installing and Configuring PHP on Windows.
3. Access the public IP and path of your CVM instances. If the deployed page is displayed, the service has been successfully deployed.
Note:
For traditional accounts, public network bandwidth must be purchased for the CVM instances, as the bandwidth is billed by CVM rather than CLB. You can determine the account type as instructed in Billing Overview.
In this example, the values returned by the service deployed on two real servers are different. In actual scenarios, to ensure that all users have a uniform experience, generally the same service should be deployed on all real servers.
Purchasing Classic CLB Instance
1. Log in to Tencent Cloud's official website and go to the CLB purchase page.
2. In this example, select Guangzhou as the region, which is the same as that of the CVM instances. Select Classic as the instance type, Public Network as the network attribute, and Default-VPC (Default) as the network and enter "clb-test" as the instance name.
3. Click Buy Now and make the payment. For more information on CLB instances, please see Product Attribute Selection.
4. On the "CLB Instance List" page, select the corresponding region to view the instance just created.
Creating CLB Listener
A CLB listener forwards requests by specifying protocols and ports. This document takes configuration of forwarding HTTP client requests by CLB as an example.
1. In the "CLB Instance List", find the created clb-test and click its ID to enter its details page.
2. In the "Bind Real Server" module in "Listener Management", click Bind.
3. In the pop-up box, select CVM instances rs-1 and rs-2 in the same region as the CLB instance and keep the default weight "10" for them.
4. Click OK to complete binding.
5. Expand the listener Listener1. You can view the health check status of the backend CVM instance. The "Healthy" status indicates that the CVM instance can properly process requests forwarded by CLB.
Configuring Security Group
After creating a CLB instance, you can configure a CLB security group to isolate public network traffic. For more information, please see Configuring CLB Security Group.
After configuring a security group, you can choose to enable or disable "Allow Traffic by Default in Security Group" with different configurations as follows:
Method 1. Enable "Allow Traffic by Default in Security Group"
Note:
This feature is currently in beta test. To try it out, please submit a ticket for application. This feature is not supported for classic private network CLB.
1. Enter the CLB service address and port http://vip:80 in a browser to test the CLB service. If a message is displayed as shown below, the request has been forwarded to the CVM instance rs-1 by CLB, and the CVM instance has properly processed the request and returned the result.
2. The round robin algorithm of the listener is "weighted round robin", and the weights of the two CVM instances are both "10". If you refresh the webpage in the browser to send a new request, you can see that the request is forwarded to the CVM instance rs-2 by CLB.
Note:
If session persistence is disabled and a round-robin method is used for scheduling, requests will be assigned to different real servers in sequence.
If session persistence is enabled, or it is disabled but ip_hash scheduling is used, requests will always be assigned to the same real server.
