Welcome to session two, Server Load Balancer Components. In this session, we'll look at the following components of SLB. A server load balancer instance which includes instance network types and instance specifications. Creating one or more listeners. Backend servers to forward traffic to. And backend server health checks.

The first component then is the server load balancer instance. A server load balancer or SLB instance is a virtual machine in which the SLB service runs. You must first select a region to create an SLB instance in, recommended best practice is to choose a region that supports the multi-zone zone type. This provisions two copies of the SLB. One in the primary selected zone, and one in the secondary selected zone, which becomes the backup zone for fail over functionality.

You must then select the instance network type and instance specification. There are two instance network types available. They are internet SLB instances and intranet SLB instances. An internet SLB instance distributes client requests from the internet to backend servers according to configured forwarding rules on listeners. When you create an internet SLB instance, it's allocated an public IP address. You can resolve a domain name to the public IP address and provide public services.

Internet SLB instances can only be used inside Alibaba Cloud and can only forward requests from clients that can access the intranet of the SLB instance. When you create an intranet SLB instance, it's allocated a private IP address. Like the network types, there are two types of instance specifications available, shared-performance instances and guaranteed-performance instances, shared-performance instances share other Alibaba SLB resources in the same region, which means their performance cannot be guaranteed.

Guaranteed-performance instances are set according to their selected performance specification. Six different levels of performance are currently available and are based around three key performance indicators, max connections, which is the maximum number of connections allowed before new connection requests are dropped. Connections per second, which is the rate at which new connections are established per second before new connection requests are dropped. And queries per second, which is the number of HTTP or HTTPS requests that can be processed per second before new connection requests are dropped. The queries per second metric is available only for Layer-7 SLB listeners. This will be explained in the session on SLB architecture.

The server load balancer service can incur charges depending on which solution is selected. The following diagram depicts which of these services incur charges. You can see from the diagram that the internal SLB using the shared performance instance is the only free offering. All other offerings incur a usage charge. At present, pay as you go is the only method that supports the payment, so there's no upfront costs or longterm commitments.

Public-facing SLB instances are charged based on the charge type that is selected. And there are two charge types available, by traffic and by bandwidth. It's worth noting that internal-facing SLB instances are charged by traffic only. After you've created the server load balancer instance, the next component to configure is the listener.

For SLB to work, a minimum of one listener is a mandatory requirement. The listener checks connection requests, and then distributes the request to backend servers after carrying out a health check on the server to make sure that it's running and healthy. A listener comprises of two main components, selecting a listener protocol and port number and selecting a scheduling algorithm. Optionally in advanced settings, the following can also be enabled.

Session persistence, access control, and peak bandwidth settings. For the port forwarding rules, a separate listener protocol is required for each port, and the rules can be either TCP, UDP, HTTP, or HTTPS. For the scheduling algorithm, there are four types of algorithm to choose from. The default selection is a weighted round round. Backend servers can have a weight or number set against them, the default is 100.

A backend server with a higher weight than another backend server would receive more requests. For example, if we have two backend servers named EC1 and EC2, and EC1 has a weight of 100 and EC2 has a weight of 50, then twice as many requests would be forwarded to EC1 than EC2. The next one, weighted least connection is the same as weighted round robin where a server with a higher weight receives more requests. But when the weight values of two backend servers are the same, the backend server with the least number of connections will be used to forward traffic to.

Round Robin is where requests are evenly and sequentially distributed to all backend servers. It's worth noting that if the default setting of weighted round robin is selected and all backend servers have the same weight, then it's the same as selecting round robin. And the last one, consistent hash, which is only available for TCP and UDP rules, is where requests from the same source IP address are scheduled to the same backend server. Before you use the SLB service, you must add one or more ECS instances as backend servers to an SLB instance, to process distributed client requests.

SLB virtualizes the added group of ECS instances in the same region into an application pool, you can manage backend servers through either the default server group, a primary server group, or VServer groups. The default server group contains ECS instances that are not associated with a VServer group or a primary/secondary server group. By default requests are forwarded to ECS instances in the default server group.

A primary/secondary server group only contains two ECS instances. One acts as the primary or active server and the other acts as a secondary or standby server. No health check is performed on the secondary server. And when the primary server is declared as unhealthy, the system forwards traffic to the secondary server. When the primary server is declared as healthy again, and it restores service, the traffic is forwarded to the primary server once again.

Note that only TCP and UDP listeners support configuring primary/secondary server groups. VServer groups are used if you want to distribute different requests to different backend servers or configured domain name based or URL based forwarding rules. A single ECS instance can be a member of multiple VServer groups.

Before passing any requests to backend servers, SLB checks the service availability of the backend server ECS instances by performing health checks. Health checks improve the overall availability of your front-end service and avoid sending requests for a service to a backend server that's not online. The health check function is enabled by default when you create a listener, but can be turned off if required. Although this is not recommended.

With the health check function enabled, SLB stops distributing requests to any instance that is discovered as unhealthy and restarts forwarding requests to the instance only when it's declared healthy again. Before creating an SLB instance, it's important to know that SLB does not support cross-region deployment. Therefore ECS instances that are being used as backend servers must be in the same region as the deployed SLB instance.

SLB also does not limit which operating system is used on the ECS instances in the pool of backend servers. As long as the applications deployed in the ECS instances is the same and the data is consistent.

So to recap on what we've just covered, you need to select a region to deploy a server load balancer to. Choose whether it is to be public or private. Select the instance specification, either shared or guaranteed. Create a listener, selecting the protocol and port required. You can select between TCP, UDP, HTTP, and HTTPS. Accept the default algorithm or change it. You can select between weighted round robin, which is the default, weighted least connection, round Robin and consistent hash. Then allocate the listener to a group of backend servers. You can choose between default group, a primary/secondary group or a VServer group. And lastly, set the parameters for the health check or accept the defaults. Once these steps have been followed, you will have a running server load balancer.

That concludes this session on server load balancer components. In the next session, I'll be covering using SLB for fault tolerance. I look forward to speaking to you in the next session.