[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# High availability for your apps\n\nThis strategy guide provides technical guidance and best practices for designing\nand deploying highly available (HA) workloads to a\nGoogle Distributed Cloud (GDC) air-gapped universe configured with multiple zones, or\n[*multi-zone*](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview). The guide\noutlines key architectural patterns, service configurations, and operational\nconsiderations necessary to minimize downtime and provide business continuity for\napplications running on GDC.\n\nHigh availability strategies are intended for technical professionals involved\nin designing, deploying, and managing applications on\nGDC, which include the following:\n\n- **Cloud architects within the platform administrator group**: Designing\n resilient infrastructure and application architectures on\n GDC.\n\n- **DevOps engineers and site reliability engineers (SREs) within the application operator group**:\n Implementing deployment strategies, automation, monitoring, and incident\n response for HA workloads.\n\n- **Application developers within the application operator group**: Building\n applications that are fault-tolerant and integrate seamlessly with HA\n infrastructure patterns.\n\nFor more information, see\n[Audiences for GDC air-gapped documentation](/distributed-cloud/hosted/docs/latest/gdch/resources/audiences).\n\nImportance of high availability\n-------------------------------\n\nIn modern distributed systems, planning for high availability is critical. Downtime,\nwhether planned or unplanned, can lead to significant business disruption,\nrevenue loss, damage to reputation, and poor user experience. For workloads\nrunning at the edge or in private data centers using\nGDC, availability often correlates directly with core\noperational success, especially for latency-sensitive or mission-critical\napplications. Designing for HA from the outset is essential to build resilient\nand reliable services.\n\nHyperscale capabilities, delivered locally\n------------------------------------------\n\nGDC extends Google Cloud infrastructure and services to\nthe edge and your data centers. GDC provides a fully\nmanaged hardware and software solution, letting you run\nGoogle Kubernetes Engine (GKE) on GDC clusters and other\nGoogle Cloud services closer to where your data is generated and consumed.\n\nThis guide focuses specifically on GDC universes\nconfigured in a multi-zone topology. With multi-zone, a single\nGDC\n[universe](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview#deployment-hierarchy-overview) comprises\nmultiple, physically isolated\n[zones](/distributed-cloud/hosted/docs/latest/gdch/resources/multi-zone/mz-overview#understading-a-zone) within the same\nlocation, such as a data center campus or metropolitan area. These zones have\nindependent power, cooling, and networking, providing protection against\nlocalized physical infrastructure failures. The low-latency, high-bandwidth\nnetwork connectivity between zones within a GDC universe\nenables synchronous replication and rapid failover, forming the foundation for\nbuilding highly available applications.\n\nScalability and load balancing\n------------------------------\n\nBeyond basic component redundancy, managing traffic effectively and enabling\nseamless scaling are crucial for maintaining high availability, especially with\nvarying load conditions. GDC provides several mechanisms\nfor load balancing and sophisticated traffic management.\n\n### External load balancer for north-south traffic\n\nTo expose your applications to users or systems outside a GKE on GDC\ncluster (north-south traffic), you use GDC's managed\nexternal load balancing capabilities. The external load\nbalancer (ELB) service provides these capabilities and integrates seamlessly with Kubernetes.\n\nThe key characteristics of the ELB service that provides HA and scalability are\nthe following:\n\n- **Managed service**: ELB is managed by GDC, designed\n for high availability and resilience.\n\n- **External access**: Provisions stable external IP addresses from\n GDC-managed pools, providing a consistent entry point\n for external clients.\n\n- **Load balancer integration with Kubernetes** : Automatically provisions and\n configures the load balancer when you create a Kubernetes `Service` of `type:\n LoadBalancer` without specific internal annotations.\n\n- **Zone awareness**: Distributes incoming traffic across healthy application\n pods running in all available zones within the GDC\n universe. The ELB relies on pod readiness probes to determine backend health.\n\n- **Scalability**: Handles distribution of external traffic as your application\n scales horizontally across nodes and zones.\n\nUsing an external load balancer is the standard and recommended way to achieve\nHA for external traffic ingress, so client requests are\nautomatically routed away from failing zones or instances.\n\nFor more information, see\n[Configure external load balancers](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/elb-service).\n\n### Internal load balancer for east-west traffic\n\nFor communication between services running within the same GKE on GDC cluster (east-west traffic), GDC provides an internal load balancer (ILB). This is crucial for decoupling internal services and providing internal communication paths that are also highly available and scalable.\n\nThe key characteristics of the ILB service that provides HA and scalability are\nthe following:\n\n- **Internal access**: Provisions a stable internal IP address accessible only\n from within the GDC network, such as cluster nodes or\n other internal services.\n\n- **Load balancer integration with Kubernetes** : Typically provisioned by\n creating a Kubernetes `Service` of `type: LoadBalancer` with a specific\n annotation to indicate it must be internal. For example,\n `networking.gke.io/load-balancer-type: \"Internal\"`.\n\n- **Zone awareness**: Distributes traffic across healthy backend pods, which are\n identified with readiness probes, located in all available zones. This\n distribution prevents internal communication failures if one zone experiences\n issues.\n\n- **Service discovery and decoupling**: Provides a stable internal IP address\n and DNS name with kube-dns and CoreDNS integration. Services can discover and\n communicate with each other, removing the need for clients to know individual\n pod IP addresses.\n\n- **Scalability**: Facilitates scaling of internal backend services by\n distributing traffic across all available healthy replicas.\n\nUsing an ILB for internal service-to-service communication makes internal\ntraffic flow resilient to zone failures and provides effective scaling,\ncomplementing the HA provided by the external ELB and underlying compute\ndistribution. This is often used for tiered applications where frontends must\ncommunicate with backend APIs or databases within the Kubernetes cluster.\n\nFor more information, see\n[Configure internal load balancers](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/ilb-service).\n\nHA app deployment across zones with asynchronous storage\n--------------------------------------------------------\n\nGDC lets you run infrastructure and applications closer\nto your data sources or end users. Achieving HA in your\nGDC universe is crucial for critical workloads. You can\ndeploy HA applications across multiple zones within your\nGDC universe, implementing asynchronous storage\nreplication for data persistence and disaster recovery.\n\nZones represent distinct failure domains within a single universe.\nBy distributing application components and replicating data across zones, you\ncan significantly improve resilience against localized hardware failures or\nmaintenance events.\n\nWhat's next\n-----------\n\n- To deploy a service as a collection of virtual machines (VMs) distributed\n across zones using asynchronous replicated block storage, see\n [Deploy an HA VM app](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-vm-app).\n\n- To deploy a service as a containerized application on Kubernetes across zones\n using asynchronously replicated persistent volumes, see\n [Deploy an HA container app](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/ha-apps/deploy-ha-container-app)."]]