tencent cloud

Gateway Load Balancer

Release Notes and Announcements
Release Notes
Product Introduction
Overview
Use Cases
Strengths
Technical Principles
Product Feature Comparison
Use Limits
Purchase Guide
Billing Overview
Billable Items
Purchase Methods
Payment Overdue
Quick Start
Operation Guide
GWLB Instance
GWLB Listener
Target Group
Health Check
Monitoring and Alarms
Practical Tutorial
Easily Implementing Adaptation of a Third-Party Virtual Device with GWLB
Implementing HA Across Multiple AZs
Ops Guide
Stress Testing FAQ
API Documentation
History
Introduction
API Category
Making API Requests
Target Group APIs
GWLB APIs
Other APIs
Data Types
Error Codes
FAQs
Billing
GWLB Configuration
Troubleshooting Health Check Issues
Service Level Agreement
GWLB Policy
Privacy Policy
Data Processing and Security Agreement
Contact Us
Glossary

Implementing HA Across Multiple AZs

PDF
Modo Foco
Tamanho da Fonte
Última atualização: 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.

Ajuda e Suporte

Esta página foi útil?

comentários