Gateway Load Balancer
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Billable Items
- Operation Guide
- GWLB Listener
- Health Check
- Practical Tutorial
- Ops Guide
- API Documentation
- Making API Requests
- Target Group APIs
- GWLB APIs
- Other APIs
Implementing HA Across Multiple AZs
Last updated: 2024-12-16 17:22:19
GWLB guarantees high availability (HA) from multiple dimensions such as system architecture and product configuration. Based on the business scenarios and requirements, you can select one from a variety of HA solutions for cross-region disaster recovery or intra-region cross-AZ disaster recovery.
GWLB Cluster HA
GWLB instances adopt cluster deployment to eliminate single points of failure of servers and enhance system redundancy, thereby ensuring the service stability. All GWLB instances have the cluster HA.
Tencent Cloud's gateway load balancing is implemented based on its own GWLB gateway, which features high reliability, strong scalability, high performance, and strong anti-attack capability. A single cluster can handle Tbps-level traffic and support millions of QPS, easily responding to various traffic distribution scenarios.
Single GWLB Instance HA
GWLB provides load balancing services with the SLA of 99.99%. GWLB deploys clusters in multiple AZs and the same GWLB instance is deployed across multiple AZs simultaneously. When a client accesses this GWLB instance, the traffic is automatically directed to the AZ cluster with the lowest latency and then forwarded to the real servers.
If a GWLB cluster in a specific AZ becomes unavailable, GWLB can automatically switch to another AZ and restore services within a very short time (about 30 seconds). If only the GWLB cluster fails, it does not affect the access traffic. If the entire AZ fails (including the real server), the GWLB instance will detect exceptions of the real server through health checks and will not forward traffic to the real server in the failed AZ.
Real Server HA
GWLB determines the availability of real servers through health checks to avoid real server exceptions from affecting frontend businesses, thereby improving the overall availability of businesses.
After the health check feature is enabled, health checks will be performed regardless of the real server weight (including 0). You can view the "health status" of real servers on the Target Group Instances tab of the target group details page, or check the number of unhealthy RSs on the Monitoring tab of the target group details page. For details of the health check mechanism, see Health Check Overview.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No