Zones in GDC air-gapped

This document explains the deployment hierarchy for Google Distributed Cloud (GDC) air-gapped, which includes universes, regions, and zones. To provide high availability for your air-gapped resources and infrastructure, you must understand the locations that host your environment and the strategic boundaries that enforce available configurations for your applications.

This document is for the following audience groups:

  • Operators within the infrastructure operator group, who are responsible for deploying and managing GDC air-gapped zones and global infrastructure.
  • Network administrators and IT administrators within the platform administrator group, who are responsible for configuring multi-zone services.
  • Application developers within the application operator group, who are responsible for developing and managing applications in a GDC universe.

For more information, see Audiences for GDC air-gapped documentation.

Deployment hierarchy overview

A GDC air-gapped deployment follows a hierarchical structure consisting of universes, regions, and zones.

A universe is a high-level grouping of interconnected zones that share both network connectivity and a control plane. Even though zones can be geographically distant, a regional boundary is established when distinct zones are physically close enough to have low-latency communication.

A zone is the building block of your GDC air-gapped deployment. Each zone is a self-contained air-gapped implementation that doesn't require connectivity to Google Cloud at any time, which means that it manages its own infrastructure, services, APIs, and tooling through a local control plane.

For example, the following illustrates a GDC air-gapped multi-zone universe:

A universe consists of zones that are grouped across regions.

This diagram has two regions, each existing within a single universe. Region 1 is highlighted to show three zones that each operate various zonal services, such as virtual machines (VM) and container applications. There are also global services that span all zones and regions in the universe, such as Identity and Access Management (IAM) and load balancing.

For example, you could have a GDC universe that spans across far-reaching geographic regions. Consider Region 1 existing in Virginia, USA with three zones:

  • Zone A, such as us-virginia1-a
  • Zone B, such as us-virginia1-b
  • Zone C, such as us-virginia1-c

Likewise, you could have Region 2 reside in the Netherlands and include zones in Amsterdam:

  • Zone A, such as eu-ams1-a
  • Zone B, such as eu-ams1-b
  • Zone C, such as eu-ams1-c

Zones within a region must be geographically close to each other, but regions can span great distances. For example, a zone might have a fiber distance maximum limit of 50 km to another zone within the same region, but the region can span 100s of km from another region. Contact your infrastructure operator group for more information on your specific latency requirements.

Understanding a zone

A zone contains four layers that can operate in isolation without requiring connectivity to Google Cloud or the public internet:

  • Hardware: The foundational equipment fully integrated into the racks of your data center. This layer provides the compute, storage, network, and GPU capacity for your system and integrated workloads.
  • Infrastructure: The underlying hardware management system. This layer provides interfaces that enable the software to run without needing hardware specific configurations.
  • Service Platform: The framework for building services on GDC. This layer provides consistency among managed services and marketplace services.
  • Managed and Marketplace services: Customer-facing cloud services running on GDC. This provides a consistent implementation of the data plane for workloads and services.

These components give you the flexibility to adjust your zonal configuration to meet your unique availability and resilience requirements. Understanding this structure gives the foundation for understanding the common air-gapped zone configurations.

Deployment configurations

The following sections describe common deployment configurations you can use for GDC air-gapped.

Single zone configuration

A single zone configuration lets you deploy a universe where one zone acts as the sole region. This configuration is possible because each zone operates independently. You'll typically use this setup for initial deployments or for workloads that don't require high availability or robust disaster recovery.

The main limitation for a single zone universe is that it creates a single point of failure, making your system vulnerable to outages. A single point of failure happens when you deploy resources exclusively to a single zone. Zonal resources are impacted as a group when an outage or service disruption occurs in that specific zone.

Multi-zone configuration

A multi-zone configuration lets you strategically distribute your applications and services across several zones. This setup improves your system's resilience and fault tolerance by providing geographically distributed resources.

This configuration also provides high availability, which lets your application or service remain continuously accessible and operational even if a zone experiences an outage. You achieve high availability through redundancy by deploying and managing resources across multiple zones within a universe. GDC offers a subset of services that provide global capabilities so the resource is managed across multiple zones in a universe by default without manual replication. Global resources span multiple zones by default, which makes them available even during a zonal outage.

A key benefit to a multi-zone configuration is that each zone can function as a distinct disaster domain. A disaster domain is a group of resources susceptible to simultaneous failure due to their shared physical location or dependency. By strategically positioning zones far enough apart, your system becomes more resilient against widespread failures.

Zonal asymmetry allows for organization and hardware configurations to be different across zones in a GDC universe. Zonal asymmetry is a Preview feature starting in version 1.14.4.

Key capabilities of a multi-zone configuration

Multi-zone configurations let you establish resilient architecture because each zone can function as distinct disaster domains. Distributing resources across these independent disaster domains lets you enhance your air-gapped systems with the key capabilities outlined in the following sections.

High availability

You can create highly available applications to provide durable services that are able to withstand outages. High availability strategies, such as load balancing and data replication, transform fragile zonal applications into resilient and reliable global services. For more information, see High availability for your apps.

Data protection

You can use a multi-zone configuration to keep your data secure and accessible even in the event of an outage using data protection strategies that let you set up data replication to create geographically separated backups. For more information, see Data protection with multi-zone storage.

Network traffic management

Building a durable network is essential to creating a highly available GDC system. You can configure networking strategies across multiple zones to plan for failover procedures during a potential zonal outage. Balancing your network traffic across zones can also positively impact application performance. For more information, see Network traffic management for multiple zones.

Permissions control

You can implement cross-zone roles to apply access control strategies on a global scale, which removes zone-specific permissions management that can be tedious and difficult to manage. Likewise, you can seamlessly manage authentication across zones for your human users and services with global access accounts. For more information, see Permissions control for a multi-zone universe.

Limitations

GDC air-gapped universes have the following limitations:

  • A universe can have a maximum of six zones.
  • A universe can have one or two operation centers.
  • A universe with two zones cannot provide an automated recovery strategy, regardless of region configuration, and must be recovered manually. Universes with three or more zones can trigger recovery steps automatically.
  • GDC provides regions only as a grouping concept, and does not provide regional services. Regions in a GDC universe are provided to closely align with public Google Cloud architecture, and for future development and planning.

What's next