Geografia e regiões

Google Cloud Os produtos são fornecidos a partir de domínios de falhas regionais específicos e são totalmente suportados por Contratos de Nível de Serviço para garantir que está a criar a arquitetura da sua aplicação na estrutura do Google Cloud.

Os serviços de infraestruturaGoogle Cloud estão disponíveis em localizações na América do Norte, América do Sul, Europa, Ásia, Médio Oriente e Austrália. Estas localizações estão divididas em regiões e zonas. Pode escolher onde localizar as suas aplicações para cumprir os requisitos de latência, disponibilidade e durabilidade.

Experimente

Se for um novo utilizador do Google Cloud, crie uma conta para avaliar o desempenho dos nossos produtos em cenários reais. Os novos clientes também recebem 300 USD em créditos gratuitos para executar, testar e implementar cargas de trabalho.

Comece gratuitamente

Regiões e zonas

As regiões são áreas geográficas independentes compostas por zonas. As zonas e as regiões são abstrações lógicas dos recursos físicos subjacentes. Uma região consiste em três ou mais zonas alojadas em três ou mais centros de dados físicos. As regiões de Estocolmo, México, Osaka e Montreal têm três zonas alojadas num ou dois centros de dados físicos. Estas regiões estão em processo de expansão para, pelo menos, três centros de dados físicos. Quando criar a arquitetura das suas soluções no Google Cloud, considere as orientações em Localizações na nuvem, Google Cloud SLAs da plataforma> e a Google Cloud documentação do produto adequada.

Estes centros de dados podem ser propriedade da Google e estar listados na Google Cloud página de localizações, ou podem ser alugados a fornecedores de centros de dados externos. Para ver a lista completa das localizações dos centros de dados para Google Cloud, consulte o nosso certificado ISO/IEC 27001. Independentemente de o centro de dados ser propriedade da Google ou estar arrendado, a Google seleciona centros de dados e concebe a sua infraestrutura para oferecer um nível uniforme de desempenho, segurança e fiabilidade. Google Cloud

Uma zona é uma área de implementação para Google Cloud recursos numa região. As zonas devem ser consideradas como um único domínio de falhas de uma região. Para implementar aplicações com tolerância a falhas e alta disponibilidade, e ajudar a proteger contra falhas inesperadas, implemente as suas aplicações em várias zonas numa região.

Para se proteger contra a perda de uma região inteira devido a um desastre natural, tenha um plano de recuperação de desastres e saiba como ativar a sua aplicação no caso improvável de perder a sua região principal. Consulte as considerações sobre a implementação de aplicações para mais informações.

Para mais informações sobre os recursos específicos disponíveis em cada opção de localização, consulte as nossas localizações na nuvem.

Google CloudOs serviços e os recursos do Google Cloud podem ser zonais, regionais ou geridos pela Google em várias regiões. Para mais informações sobre o que estas opções significam para os seus dados, consulte a secção Gestão geográfica de dados.

Google Cloud pretende oferecer um mínimo de três zonas de disponibilidade (zonas física e logicamente distintas) em todas as regiões de uso geral.

Documentos de localização relacionados

Recursos zonais

Os recursos zonais operam numa única zona. As falhas de energia zonais podem afetar alguns ou todos os recursos nessa zona. Um exemplo de um recurso zonal é uma instância de máquina virtual (VM) do Compute Engine que reside numa zona específica.

Recursos regionais

Os recursos regionais são recursos implementados de forma redundante em várias zonas de uma região, por exemplo, aplicações do App Engine ou grupos de instâncias geridos regionais. Deste modo, têm maior disponibilidade do que os recursos zonais.

Recursos multirregionais

Vários Google Cloud serviços são geridos pela Google para serem redundantes e distribuídos dentro e entre regiões. Estes serviços otimizam a disponibilidade, o desempenho e a eficiência dos recursos. Como resultado, estes serviços requerem um compromisso entre a latência ou o modelo de consistência. As soluções de compromisso necessárias para a obtenção deste equilíbrio são documentadas em função de cada produto.

Os seguintes serviços têm uma ou mais localizações multirregionais além de quaisquer localizações regionais:

  • Artifact Registry
  • Bigtable
  • Proteção de dados confidenciais
  • Cloud Healthcare API
  • Cloud KMS
  • Container Registry
  • Spanner
  • Cloud Storage
  • Database Migration Service
  • Armazenamento de dados
  • Firestore

Estes serviços multirregionais foram concebidos para poderem funcionar após a perda de uma única região.

Para mais informações, consulte o artigo Produtos disponíveis por localização e a documentação de cada produto.

Serviços globais

Google Cloud foi concebida para funcionar a nível global desde o início e realiza continuamente manutenção e atualizações 24 horas por dia, 7 dias por semana, 365 dias por ano sem causar inconvenientes. A nossa rede global oferece uma flexibilidade enorme para o equilíbrio de carga e reduz a latência do utilizador final através de interconexões próximas de si. O nosso plano de gestão da nuvem global simplifica a gestão de desenvolvimentos em várias regiões.

Serviços internos

A base e o suporte de muitos serviços Google Cloud voltados para o cliente são um conjunto de serviços internos comprovados, como o Spanner, o Colossus, o Borg e o Chubby.

Estes serviços internos têm um equilíbrio de carga global em várias regiões ou são dedicados a cada região em que estão disponíveis. Quando os serviços são equilibrados em várias regiões, implementamos atualizações progressivamente região a região, o que nos permite detetar e resolver problemas sem afetar a sua utilização do serviço. Nenhum destes serviços internos está limitado a um único centro de dados lógico ou a uma única região.

Os serviços internos globais podem ser executados ou replicados nas seguintes regiões da nuvem:

Americas

  • southamerica-west1
  • us-central1
  • us-east1
  • us-east4
  • us-west1
  • us-west4

Europa

  • europe-north1
  • europe-west1
  • europe-west4

Ásia

  • asia-east1
  • asia-southeast1

Dependências do serviço

Em geral, para os Google Cloud serviços, se uma única região falhar, apenas os clientes nessa região são afetados. Os clientes que têm produtos multirregionais não são afetados. Google Cloud tem uma arquitetura significativa em vigor com o objetivo de evitar falhas correlacionadas em várias regiões.

Todos os Google Cloud serviços dependem de ferramentas internas essenciais para fornecer serviços fundamentais, como redes (dentro e fora dos centros de dados), acesso a centros de dados e sistemas de autorização de identidade. Estas ferramentas são resilientes a interrupções regionais, com o objetivo de que uma região não seja afetada se outras regiões ficarem indisponíveis.

Google Cloud fornece orientações claras sobre como os clientes podem arquitetar as respetivas aplicações para o nível de resiliência desejado no nosso Website público, especialmente para produtos Google Cloud usados com frequência, como o Compute Engine, o BigQuery, o Pub/Sub e outros serviços.

As nossas principais dependências estão listadas abaixo, começando pelas dependências comuns a todos os serviços, com a ressalva de que os detalhes de implementação de nível inferior estão sujeitos a alterações.

Dependências comuns para todos os serviços

  • Plano de dados de identidade para autenticação e autorização
  • Serviços internos que fornecem registo, armazenamento de metadados e gestão de fluxo de trabalho
  • O acesso às Google Cloud APIs depende do DNS, dos equilibradores de carga distribuídos globalmente e dos pontos de presença (PoPs).
  • A configuração de recursos globais: por exemplo, as políticas de IAM, as regras de firewall globais, as configurações do balanceador de carga global e os tópicos do Pub/Sub são armazenados em bases de dados replicadas.
  • Quando os Google Cloud serviços fazem pedidos a pontos finais controlados pelo cliente, por exemplo, a obtenção de chaves do cliente do EKM na nuvem ou a entrega de mensagens do Pub/Sub, esses pedidos dependem da nossa infraestrutura de rede global para aceder a esses pontos finais controlados pelo cliente.

Serviços com dependências adicionais

  • Serviços do Compute Engine
    • Os planos de dados Google Cloud de VMs e discos persistentes dependem de serviços de nível inferior do Compute Engine e do Cloud Storage como o Borg e o Colossus.
  • Google Cloud e os serviços de armazenamento de infraestrutura, como o Spanner, o Bigtable e o Cloud Storage, dependem do seguinte:
    • Infraestrutura de encriptação e gestão de chaves para o cliente (Cloud KMS / Cloud EKM) e infraestrutura interna para chaves pertencentes à Google
    • Serviços internos para fornecer registo e auditoria do acesso aos dados
    • Serviços de replicação de dados internos, em que se espera que os dados estejam disponíveis em várias regiões
    • As cópias de segurança e a replicação configuradas explicitamente para outras regiões dependem da rede entre regiões
  • Serviços de mensagens
    • O Pub/Sub depende da nossa infraestrutura de rede global para aceder a pontos finais controlados pelo cliente
  • Serviços de networking
    • O equilíbrio de carga global, o DNS e a comutação por falha entre regiões dependem todos da infraestrutura de rede física.
    • A prevenção de ataques DDoS e semelhantes depende da infraestrutura do Compute Engine de nível inferior.
  • Serviços geridos e alojados, como o GKE e o Cloud SQL
    • Dependem do Compute Engine e do Container Registry ou do Artifact Registry para imagens de VMs.
  • Infraestrutura de nível inferior autónoma
    • O nosso plano de controlo interno ao nível do cluster, incluindo o Borg e as estruturas de rede
    • Armazenamento ao nível do cluster, como o Colossus
    • Infraestrutura de encriptação e gestão de chaves

Manter e melhorar a disponibilidade e a resiliência

A engenharia de fiabilidade de sites (EFS) é a organização interna da Google dedicada a trabalhar na disponibilidade, latência, desempenho e capacidade. As indisponibilidades e as falhas de serviço estão correlacionadas com a implementação de novo código ou alterações ao ambiente. Ao usar as práticas recomendadas da indústria, a SRE equilibra a necessidade de lançar novo software e mantém o ambiente seguro, compreendendo que essas alterações necessárias podem causar tempo de inatividade.

Parcerias com clientes para criar serviços resilientes

Se tiver necessidades críticas para a missão e precisar de criar uma arquitetura para resiliência e recuperação de desastres, as nossas equipas de SRE/CRE e PSO podem trabalhar consigo para criar a arquitetura das suas aplicações de forma a abranger várias regiões e zonas, e podem ajudar ainda mais na conceção de sistemas de elevada disponibilidade (HA).

Se tiver requisitos de disponibilidade mais elevados em torno de datas específicas, como a Black Friday e a Cyber Monday, Google Cloud tem um programa para estabelecer uma parceria consigo para verificar e validar a sua aplicação específica em execução no Google Cloud e identificar dependências de serviços inesperadas entre a sua aplicação e os nossos serviços.

Pontos de presença (POPs)

A Google opera uma rede global de pontos de presença de intercâmbio, o que significa que o tráfego dos clientes pode viajar na rede Google até estar perto do respetivo destino, oferecendo aos utilizadores uma melhor experiência e maior segurança. Para mais informações, consulte o artigo Localizações na periferia da rede.

Gestão geográfica de dados

A localização dos dados para os serviços Google Cloud é regida pelos termos de utilização, incluindo os termos específicos do serviço. A Google compreende que cada cliente pode ter necessidades únicas de segurança e conformidade. A equipa de vendas do Google Cloud pode ajudar a trabalhar no sentido de cumprir os seus requisitos.

Quando usar recursos de armazenamento regionais ou zonais, recomendamos vivamente que replique os dados para outra região ou crie um instantâneo dos mesmos num recurso de armazenamento multirregional para fins de recuperação de desastres.

Considerações sobre a implementação de aplicações

Para criar serviços e aplicações de elevada disponibilidade que possam resistir à indisponibilidade de zonas

Use o seguinte:

Para criar aplicações capazes de recuperação de desastres que possam resistir à perda prolongada de regiões inteiras

Para os dados, use uma ou mais das seguintes estratégias:

  • Use serviços de armazenamento multirregionais geridos, como o Cloud Storage, o Datastore, o Firestore ou o Spanner.
  • Use recursos zonais ou regionais, mas crie instantâneos de dados para um recurso multirregional, como o Cloud Storage, o Datastore, o Firestore ou o Spanner.
  • Use recursos zonais ou regionais, mas faça a gestão da sua própria replicação de dados para uma ou mais outras regiões.

Para o cálculo, use a seguinte estratégia:

  • Use recursos zonais ou regionais, como o Compute Engine ou o App Engine, mas inicie manual ou automaticamente a sua aplicação noutra região (em caso de falha regional) consultando cópias dos seus dados principais se os dados ainda não estiverem num recurso multirregional gerido.

Para mais informações sobre dependências de serviços, contacte o departamento de vendas.

Soluções e tutoriais adicionais

As seguintes soluções e tutoriais oferecem orientações para garantir que a sua aplicação está altamente disponível e consegue resistir a interrupções:

Padrões para apps escaláveis e resilientes

Saiba como usar o Google Cloud para criar arquiteturas de aplicações escaláveis e resilientes usando padrões e práticas que se aplicam amplamente a qualquer aplicação Web.

Criar um balanceador de carga HTTPS

Configure instâncias do Compute Engine em diferentes regiões e use o balanceamento de carga HTTP para distribuir o tráfego pelas regiões de modo a aumentar a disponibilidade nas regiões e fornecer uma alternativa em caso de indisponibilidade do serviço.

Conceber sistemas robustos

Conceba a sua aplicação no serviço Compute Engine para ser robusta contra falhas, interrupções de rede e desastres inesperados.

Cópia de segurança e restauro do Cassandra com o Cloud Storage

Saiba como adicionar a recuperação de desastres básica à sua instalação do Cassandra fazendo uma cópia de segurança dos seus dados no Cloud Storage e restaurando-os a partir deste.

Guia de planeamento de recuperação de desastres

Princípios gerais para conceber e testar um plano de recuperação de desastres com o Google Cloud.