Amazon Elastic Load Balancing Load Balancing High Availability Architecture: Equipping Your Server with a Top-Level "Traffic Police"
In the Internet world, there are two things that make architects and bosses unable to sleep most:
First, the sudden increase in traffic washed out the server, and second, the sudden "downtime" of a certain server led to the paralysis of the whole station.
If you compare your back-end server cluster to a bank's teller, when there is only one or two customers, everyone is at peace. However, when double eleven, black five or breaking news comes, thousands of customers will pour in instantly. A teller alone will not only form a long line (website Caton), but the teller will even collapse directly due to overwork (server downtime).
How to break? You need a smart and capable "lobby manager" to maintain order and evenly distribute customers to each free window. In the Amazon Web Services (AWS) ecosystem, this role is
ELB(Elastic Load Balancing, Elastic Load Balancing)
.
Today, instead of obscure PPT terminology, we use a purely practical perspective to deeply disassemble how to use ELB to build an indestructible "highly available load balancing architecture".
1. Core Selection: Which of the three ELB family members should you choose?
AWS's ELB is not a single product, but derives three main directions for different business scenarios. Selecting the wrong model is like using a sports car to pull goods or a truck to race, which is a waste of money and ineffective.
1. ALB (Application Load Balancer) -Application Load Balancer
Positioning: Focus on HTTP/HTTPS traffic (that is, the application layer of the seven-layer network protocol).
The unique skill: advanced routing function. It can understand the content of the request. For example, users visit. It also supports distributing traffic based on host, headers, and even query strings.
Application scenarios: most web applications, microservice architectures, and containerized applications (ECS/EKS).
NLB (Network Load Balancer) -Network Load Balancer
Positioning: Focus on TCP/UDP/TLS traffic (the transport layer in the network layer 4 protocol).
The ultimate performance with ultra-low latency. NLB is capable of handling millions of burst requests per second. What's more, it supports static IP addresses. Each available area can be bound with a fixed elastic IP, which is just needed for enterprise-level docking that needs to be whitelisted.
Applicable scenarios: game servers, high-frequency financial trading systems, and Internet of Things (IoT) data receivers.
3. GLB (Gateway Load Balancer)
-- Gateway Load Balancer
Location: Specifically used to manage third-party virtual security devices (such as firewalls, intrusion detection systems).
Applicable scenarios: large factories are used to do security audits and cleaning of station-wide traffic. Usually small and medium-sized businesses rarely use it directly.
2. High Availability Architecture Design: How Does ELB Achieve Fault Self-Healing?
Many novices will have a question: "I gave all the traffic to ELB, what if ELB hangs up on its own? Isn't it a single point of Failure (Single Point of Failure)?"
AWS has taken this into consideration. ELB in the name.
Elastic (elastic)
It contains two meanings:
elasticity of capacity
and
The resilience of the architecture
.
1. Cross-zone (Multi-AZ) high availability
When designing the ELB architecture, the core principle is
Never put your eggs in one basket.
.
Each AWS Geographic Region (Region) contains multiple independent Availability Zones (Availability AZ). Each AZ has independent power, network and cooling systems.
When you create an ELB, you are forced to select at least two Availability Zones. In fact, ELB will automatically deploy a load balancing "node" in each of your selected Availability Zones ".
When a user initiates a request, DNS will poll and distribute traffic to these different Availability Zone nodes.
If zone a is completely paralyzed by heavy rain and power failure, the DNS resolution at the top of ELB will automatically cut off the traffic and pour it into the nodes in zone B. The whole process is completely imperceptible to the user.
2. Health Check (Health Check): Accurate elimination of "black sheep"
Another big killer of the ELB's ability to remain highly available is
Health check
.
You must configure a rule for ELB, such:
Every 10 seconds, send an HTTP request to the/health path of the backend server. If you return 200 OK for 3 consecutive times, the server is alive. If there is no response for 2 consecutive times, it is determined that the server is "sick.
Once a server is judged to be unhealthy, ELB will immediately
Block
and no longer send any new traffic to it until it gets back to normal. This successfully avoided the tragedy of "1/3 of the users reporting errors due to a server crash.
3. Practical Exercise: Hand-in-Hand Building a Highly Available Web Architecture for ALB Multi-AZ
Next, let's take the most classic ALB as an example and go through the standard configuration process of the production environment.
Step 1: Prepare the backend Target Group"
Before configuring the load balancer, we need to tell it "who to send traffic". in AW
In S, this back-end collection is called the target group.
Open the EC2 console, find Target Groups in the left navigation bar, and click Create target group.
Select the target type, usually Instances (instance), and enter a name.
Protocol and port: Select HTTP:80 (or the port on which your application runs).
Health checks: The check path is usually written to your service status interface, such as/or/status.html. Expand the advanced settings (Advanced the health check settings) and set Health Threshold to 3, Unhealthy Threshold to 2, Timeout to 5 seconds, and Interval to 10 seconds.
Click Next, check the web server instances you started in different Availability Zones (such as AZ-A and AZ-B), and click Create target group.
Step 2: Create the Application Load Balancer
In the left-side navigation pane, click the Load Balancers, click the Create load balancer, and select the Application load Balancer.
Scheme: Select the Internet-facing (Internet-oriented). Select Internal if you are loading intranet microservices.
Network mapping (Network Map): Select your VPC. Key step: Select at least two AZ (for example, us-east-1a and us-east-1b) and select the public subnet corresponding to each AZ.💡Architecture Pit Avoidance Guide: ALB itself must reside in the public network subnet so that it can obtain the public network IP to receive Internet traffic. But! Your back-end web server (EC2) can and is strongly recommended to be placed in a private subnet (Private Subnet). In this way, no one from the outside world can directly attack your server through IP, all the security protection is carried by the front-end ALB, and the architecture security is instantly full.
Step 3: Configure Security Groups (Security Groups) and Listeners
Security groups: To associate a security group with ALB, the TCP 80(HTTP) and TCP 443(HTTPS) ports must be opened.
Listeners and routing (Listener and Routing): By default, there is an HTTP:80 listener. In the Forward to (Forward to) drop-down menu, select the "target group" we created in the first step ". As
If there is an SSL certificate, click Add listener, add an HTTPS:443, and configure your domain name certificate.
Click on the bottom
Create load balancer
. After about 2 minutes, the ALB status changes
Active
, you will get a long DNS name (for example:
my-alb-123456789.us-east-1.elb.amazonaws.com
).
4. advanced advanced: combined with Auto Scaling (elastic expansion) to achieve the ultimate high availability
If you only have ELB, the website will still be stuck when the traffic really exceeds the total tolerance limit of the back-end server. ELB is just a lobby manager, it can't make more tellers out of thin air.
To achieve true "elastic freedom", you need to put
ELB
and
Auto Scaling
Bound together.
[User Request] -> [ELB] -> [Auto Scaling Group]
When the double eleven is approaching, the traffic will surge:
CloudWatch monitoring found that the average CPU of the back-end server soared to 80%.
Auto Scaling received the signal and immediately automatically packaged and created 5 brand new EC2 servers.
The most wonderful place is here: after the new server is started, Auto Scaling will automatically report to ELB's target group: "reporting manager, I am the new teller, ready!"
The ELB was notified and immediately began offloading subsequent traffic to the five new servers, without manually changing any line of configuration or restarting any device.
At 2: 00 a.m. when the traffic recedes and the CPU drops, Auto Scaling will automatically destroy the five machines to save money, and ELB will gracefully disconnect (Deregistration Delay) to ensure that the requests being processed are normally completed before moving them out of the cluster.
Conclusion
In a modern cloud-native architecture, Amazon ELB is definitely not a simple "traffic forwarder", it is the entire high-availability architecture.
Commander
.
It prevents physical-level disasters through node deployment across Availability Zones, isolates internal system faults through strict health checks, and enables unlimited business extension through perfect coordination with Auto Scaling. After understanding the operation logic and configuration details of ELB, you have the key to build a modern website with high concurrency and no downtime.
