Hi everyone. Welcome to the eighth chapter in our Tencent Cloud SysOps Associate course, Deploying High Availability Services. At the end of this chapter you'll be able to explain the basic concepts and deployment process of CLB. Describe CLB listener configurations, backend servers, monitoring, alarms, and algorithms. Explain the basic process and concepts of CDN, and describe CDN domain management, origin server configurations, access control, cache expiration, and origin-pull configurations. In this chapter we'll cover two sections: CLB configuration practices and CDN configuration practices. This video will cover the first section , CLB configuration practices. The subsequent video will cover the remaining section. Let's get started with Section 1, CLB configuration practices. In this video we'll cover CLB, configuring listeners, operating backend servers, load algorithm selection and weight configurations, and CLB monitoring and alarms. Let's start with CLB. In this subsection, we'll cover an overview of CLB, the CLB configuration process, creating CLB instances, and configuring domain names. There are two types of Cloud Load Balancer, CLB: CLB and classic CLB. The CLB supports the TCP, UDP, HTTP, and HTTPS protocols, provides domain name and URL-based balancing capabilities, and supports flexible forwarding. In contrast, the classic CLB has a simpler configuration and does not support HTTP and HTTPS. CLB has several use cases. First, it distributes traffic to backend services to eliminate single points of failure. The client can access CVM clusters through CLB to connect to backend databases. Second, CLB is also used in auto scaling scenarios where it is associated with scaling groups to distribute the traffic dynamically to the healthy instances according to the distribution rules. Third, CLB can implement load balancing through DNS by interconnecting with regional CLBs. In this example, there's a CLB in Beijing and in Shanghai, and DNS intercepts traffic and sends it to the CLB in the region that is closest to the user. There are three types of limitations to CLB: general limitations that apply to both CLB and classic CLB, CLB specific limitations, and classic CLB specific limitations. Some examples of general limitations are the maximum number of instances with either public or private IPs that an account can create in a single region is 100. The maximum number of listeners a CLB instance can add is 50 and the optional ports of the listener in a CLB instance must be an integer within 1-65,535. There are also several limitations that apply specifically to CLB. First, the maximum number of configurable domain names and URL forwarding rules of HTTP and HTTPS listeners in one instance is 50. Second, the maximum number of servers to which the forwarding rules of one instance can bind is 100. Third, a front end port can correspond to a maximum of multiple backend ports in one instance. Finally, there are a couple of limitations that apply specifically to classic CLB. First, the maximum number of servers to which the listener of one instance can bind is 100. Second, the maximum number of backend ports, a frontend port can correspond to in one instance is one. Now let's take a look at the CLB configuration process which consists of five steps. The first step is required and consists of enabling the CLB. The second step is also required and involves configuring listeners and binding them to servers. The third step is optional and consists of managing the backend servers. The fourth step is also optional but highly recommended and involves configuring CLB instance monitoring and alarms. The last step involving access control management is optional as well. When creating CLB instances, take the time to look over the key attributes of a CLB instance so you can correctly configure them. A CLB instance's key attributes include the region, the instance type, the network type, the project, the instance name, and purchase quantity. Now let's move on to configuring listeners. In this subsection, we'll cover an overview of listeners, creating listeners, configuring forward groups, binding CVMs, configuring certificates, and configuring redirection. The load balancing service is mainly provided by the listener. The listener will monitor all requests sent to the CLB instance and distribute them to the backend CVM according to the configured policies. The listener supports several protocols such as HTTP, HTTPS, TCP, UDP, and TCP SSL. HTTP is a protocol at the application layer that is suitable for applications that need to identify data content such as web applications and mobile games while HTTPS is a protocol at the application layer that is suitable for applications that require encrypted transmission. TCP is a protocol at the transport layer that is suitable for scenarios that require high reliability and data accuracy and are not sensitive to speed such as file transfer, email transmission, and remote login. UDP is another protocol at the transport layer that is suitable for scenarios that require low latency but not high reliability, such as video chatting and real-time financial push notifications. Finally, TCP SSL is a protocol at the transport layer that is suitable for scenarios that require very high security and use the TCP protocol. It supports TCP-based custom protocols. Because HTTPS is a security protocol, HTTPS listeners feature a security mechanism in which load balancing uses certificates to decrypt the request from the client and then sends the request to the backend. The listener configuration process consists of five steps. First, you need to create a listener. Second, you need to configure forwarding rules. Third, you need to bind the listener to a CVM. Fourth, you need to configure certificates if you're using the HTTPS protocol. Fifth, you can configure redirection which is optional. You can create either an HTTP or HTTPS listener or a TCP or UDP listener on the Tencent Cloud Console. Now let's move on to configuring forwarding groups. The CLB layer-4 forwarding process consists of three steps. First, bind the server to the listener. Second, the forwarding port and weight can be configured independently in the listener. Third, configure the session and perform a health check in the listener. In the CLB layer-4 forwarding process, a load balancing instance forwards traffic to backend servers through a load balancing listener. The load balancing listener and the backend servers must share the same port number such as 80 to interconnect. The CLB layer-7 forwarding process supports multi-domain forwarding and consists of three steps. First, bind the server to the forwarding group. Second, configure the forwarding port and weight independently in the group. Third, configure the session and perform a health check in the group. In the CLB layer-7 forwarding process, a load balancing instance listener forwards the traffic to backend servers first through a load balancing listener and then through forwarding rules and groups. Similar to the CLB layer-4 forwarding process, the load balancing listener and the backend servers must share the same port number such as 80 to interconnect. The forwarding group configuration process consists of four steps. First, you need to initiate a request. Second, you need to forward the request to the corresponding domain. Third, you need to match the forwarding group rule. Fourth, you need to forward the request to the corresponding CVM. Now let's take a look at the layer-7 forwarding matching rules. In layer-7 forwarding, precise matching is prioritized and followed by rule-based fuzzy matching. As the diagram illustrates, a domain name can forward traffic to backend servers through forwarding groups via specific URL paths. Each backend server has one or more ports associated with it and each forwarding group must be assigned the same port to communicate with that particular server. To configure forwarding groups, you can configure the domain name and URL for the listener on the CLB console. After, you can select the configured CVM by clicking "Bind". Once you create the HTTPS listener, you will need to provide at least one server certificate such as SSL to implement one-way authentication. HTTPS will always require an SSL to encrypt transport. To configure certificates, you will first generate the private key locally, then generate the certificate signing request using the private key, and then acquire the certificate signing request file and visit the website to apply for the certificate. There are two methods of configuring redirection : auto redirection and manual redirection. In auto redirection, when a PC, mobile browser, or other HTTP request sends a request to access a web service, CLB will redirect all HTTP 80 requests to HTTP 443. For example, if a user were to visit an unsecured HTTP website, the website will automatically redirect the user to its HTTPS version. In manual redirection, if the web service needs to go offline temporarily and no redirection is made, the old address in the user's search engine database will only lead users to a 404 and 503 error page, affecting the user experience. To finish configuring forwarding groups, you can configure the HTTPS listener and enable redirection on the console. Now let's move on to operating backend servers. In this subsection, we'll cover managing backend servers and configuring security groups. In what scenarios would you need to manage backend servers? When CLB routes requests to a normally running backend server. If the demand for the instance increases, you would need to add more instances to the CLB to meet the increased demand. You can add more instances to the CLB by going on the CLB console, clicking the ID name of the target instance, listener management and bind. Security groups need to be configured because CLB's CVM instances can be accessed via a security group which acts as a firewall. For public networks CLB's, the CLB's VIP should be allowed in the CVM security group so that the CLB can use the VIP to check the health of the CVM. For private CLB's, if the CLB is in the VPC network, the CLB's VIP should be allowed in the CVM security group for health checks. The CLB in the basic network does not need to be configured in the same way because the health check IP is allowed by default. For classic private CLB's, if the instance was created before December 5th, 2016 and is in the VPC network, the CLB's VIP should be allowed in the CVM security group for health checks. In other types of traditional intranets, the CLB does not need to be configured in the same way because the health check IP is available by default. You can configure security groups by going on the CVM console, clicking on the Security Groups tab on the left sidebar and the ID name of the target security group. Note that because security groups are stateful, you usually only need to add inbound rules and not outbound rules. Now let's move on to load algorithm selection and weight configuration. In this subsection we'll cover an introduction to load balancing algorithms and load balancing algorithm configuration examples. There are three main types of load balancing algorithms: weighted round robin scheduling, weighted least connection scheduling, and source hashing scheduling. Weighted round robin scheduling is relatively simple and suitable for stateless connections such as HTTP. While weighted least connection scheduling allocates weights according to it's capabilities and is suitable for long connections. Finally, source hashing scheduling assigns CVMs according to the hash table and are suitable for TCP protocols without cookies. In what scenario should each load balancing algorithm be used? Well, when there are three CVMs with the same performance and the same weight of 10 and another one needs to be added, the weighted least connection algorithm should be used to immediately increase the load for the fourth server. When users are using Cloud services for the first time and the website load is low, servers with the same configurations should be purchased and their weights should be set to 10 using the weighted round robin algorithm which is suitable for situations where the website load is low. When five servers are used to host a simple static website and the computing power ratio is 9:3:3:3:1, the weight ratio of servers should be set to 9:3:3:3:1 using the weighted round robin algorithm. When 10 servers are used to handle a large number of web requests but one server restarts often due to excessive loads, the weight should be set according to the performance of the server and a small weight should be set for the overloaded server. When three servers are used to handle several long connection requests and their computing power ratio is 3:1:1, the weighted least connection algorithm should be used to reduce the weight of busy servers. Finally, when the client wants all subsequent requests to be assigned to the same server, the source hashing scheduling should be used to distribute traffic. Now let's move on to monitoring and alarms. In this subsection, we'll cover an overview of monitoring and alarms, acquiring monitoring data, and configuring alarms. Monitoring and alarms can be accessed through Cloud monitor. Cloud monitor collects and displays data for the CLB in the backend. It also collects the operating data of instances every five minutes and supports a data granularity of one-minute with the data being conserved for 30 days by default. Finally, Cloud monitor integrates the monitoring data of all products and can obtain instance data from different locations as needed. Cloud monitor monitors certain metrics over a period of time and sends alerts at each interval based on a given threshold. An alarm involves several components such as an alarm receiving group, a trigger condition, an alarm object, and a receding method. You can acquire monitoring data by going on the CLB console and clicking the ID name of the instance and monitoring. Finally, let's take a look at configuring alarms. To configure an alarm policy for a public network CLB listener, retrieve the inbound package quantity data every minute. If the inbound package quantity exceeds 100 per second for two consecutive times, the alarm will be triggered. There are five steps to configuring an alarm. First, create an alarm. Second, configure the basic options. Third, configure the alarm objects. Fourth, configure the trigger conditions. Fifth, configure the alarm channels. First, create a new alarm policy and configure its basic options such as policy name, remarks, policy type, and project. Second, configure the alarm objects for the newly created alarm policy. Third, configure the alarm trigger conditions. Fourth, configure the alarm channels. When configuring the alarm channels, you can list specific recipients, divide them into groups based on affiliation, and specify a receiving channel such as e-mail or SMS.
