Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Antes de criar recursos, considere como você planeja distribuir os recursos
de forma geográfica para atender aos requisitos exclusivos da sua empresa. Administradores e
os arquitetos da sua organização geralmente tomam decisões sobre geografia e tomam
as decisões disponíveis para as pessoas que implantam os recursos. Por exemplo, sua
empresa pode ter um processo de infraestrutura como código (IaC)
que atribui automaticamente as regiões à medida que você implanta recursos.
Este documento apresenta uma visão geral de como a geografia afeta suas cargas de trabalho.
Distribuir recursos para garantir a disponibilidade
Você pode distribuir geograficamente os recursos para atender aos seus requisitos exclusivos,
nos seguintes exemplos:
Latência: verifique se você tem recursos em zonas próximas aos usuários.
Disponibilidade: crie recursos redundantes em várias regiões no caso de uma
falha na região.
Regiões e zonas
Ao criar recursos, é possível selecionar as seguintes categorias geográficas:
Regiões são áreas geográficas independentes que contêm zonas. Por exemplo,
asia-east1 (Taiwan).
As zonas são áreas isoladas umas das outras dentro de uma região. Por
exemplo, a zona a na região asia-east1 (Taiwan) se chama asia-east1-a.
Considere uma zona como um único domínio de falha dentro de uma região. Para implantar aplicativos tolerantes a falhas com alta disponibilidade e ajudar a proteger contra falhas inesperadas, implante seus aplicativos em várias zonas em uma região.
Cada recurso tem a própria dinâmica de localização. Por exemplo, consulte os seguintes
detalhes sobre o Compute Engine e o Cloud Storage:
Selecionar regiões geográficas com base nas interações de recursos
Ao criar seu plano de distribuição de recursos, considere a comunicação de recursos
entre zonas e regiões. As capacidades de interação de recursos são determinadas
pelos seguintes tipos de recursos:
Recursos globais podem ser acessados por qualquer outro recurso, entre regiões e zonas. Exemplos incluem imagens de disco, snapshots de disco e redes.
Recursos regionais são implantados de maneira redundante em várias zonas em uma
região. Recursos regionais só podem ser acessados por recursos localizados na mesma região. Exemplos incluem aplicativos do App Engine e grupos de instâncias regionais gerenciadas.
Os serviços multirregionais são distribuídos de modo redundante dentro e entre
várias regiões. Esses serviços otimizam a disponibilidade, o desempenho e a eficiência do recurso. Para uma lista de serviços que têm um ou mais serviços multirregionais
locais, consulte Produtos disponíveis por local.
Recursos zonais só podem ser acessados por recursos localizados na mesma zona. Um exemplo de recurso zonal é uma instância de máquina virtual (VM) do Compute Engine.
Por exemplo, considere os seguintes recursos:
Global: uma rede que pode ser acessada por todos os recursos.
Em cada região: endereços IP que fornecem acesso externo a recursos apenas
dentro de uma única região.
Em cada zona: discos que podem se conectar a VMs que estão na mesma zona.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-12-22 UTC."],[[["\u003cp\u003eGeographic distribution of resources is crucial for meeting unique company requirements, ensuring low latency, and maintaining high availability.\u003c/p\u003e\n"],["\u003cp\u003eResources are categorized into regions and zones, where regions are independent geographic areas containing multiple zones, which are isolated areas within a region.\u003c/p\u003e\n"],["\u003cp\u003eResource interactions are influenced by whether they are global, regional, multiregional, or zonal, each having distinct access capabilities based on their location.\u003c/p\u003e\n"],["\u003cp\u003eFault-tolerant applications should be deployed across multiple zones within a region to protect against unexpected failures and enhance high availability.\u003c/p\u003e\n"],["\u003cp\u003eConsiderations regarding how resources communicate across regions and zones are important while determining the resource distribution strategy.\u003c/p\u003e\n"]]],[],null,["# Consider geographic distribution\n\nBefore you create resources, consider how you plan to distribute resources\ngeographically to meet your company's unique requirements. Administrators and\narchitects in your organization usually make decisions about geography, and make\ntheir decisions available to people who deploy resources. For example, your\ncompany might have an [Infrastructure as Code (IaC)](/docs/terraform/iac-overview)\nprocess that automatically assigns geographies as you deploy resources.\n\nThis document provides an overview on how geography impacts your workloads.\n\nDistribute resources to help ensure availability\n------------------------------------------------\n\nYou can geographically distribute resources to meet your unique requirements, as\nin the following examples:\n\n- Latency: Ensure you have resources in zones near your users.\n- Availability: Create redundant resources in multiple regions in case of a region failure.\n\nRegions and zones\n-----------------\n\nWhen you create resources, you might select the following geographic categories:\n\n- *Regions* are independent geographic areas that contain zones. For example,\n `asia-east1` (Taiwan).\n\n- *Zones* are areas that are isolated from each other within a region. For\n example, zone `a` in the `asia-east1` (Taiwan) region is named `asia-east1-a`.\n\nConsider a zone as a single failure domain within a region. To deploy\nfault-tolerant applications with high availability and help protect against\nunexpected failures, you might deploy your applications across multiple zones in\na region. For more information, see\n[Geography and regions](/docs/geography-and-regions).\n\nEach resource has its own location dynamics. For example, see the following\ndetails about Compute Engine and Cloud Storage:\n\n- [Compute Engine regions and zones](/compute/docs/regions-zones)\n- [Cloud Storage bucket locations](/storage/docs/bucket-locations)\n\n### Select geographies based on resource interactions\n\nAs you create your resource distribution plan, consider resource communication\nacross zones and regions. Resource interaction capabilities are determined by\nthe following resource types:\n\n- *Global resources* can be accessed by any other resource, across regions and\n zones. Examples include disk images, disk snapshots, and networks.\n\n- *Regional resources* are redundantly deployed across multiple\n zones within a region. Regional resources can be accessed only by resources that\n are located in the same region. Examples include App Engine\n applications and [regional managed instance groups](/compute/docs/instance-groups#types_of_managed_instance_groups).\n\n- *Multiregional* services are redundantly distributed within and across\n regions. These services optimize availability, performance, and resource\n efficiency. For a list of services that have one or more multiregional\n locations, see [Products available by location](/about/locations#multi-region).\n\n- *Zonal resources* can be accessed only by resources that are located in the\n same zone. An example of a zonal resource is a Compute Engine virtual\n machine (VM) instance.\n\nFor example, consider the following resources:\n\n- Globally: a network that can be accessed by all resources.\n- In each region: IP addresses that provide external access to resources only within a single region.\n- In each zone: disks that can connect to VMs that are in the same zone."]]
