Elementos básicos da recuperação de desastres

Este artigo é a segunda parte de uma série que discute a recuperação de desastres (DR) no Google Cloud. Esta parte fala sobre os serviços e produtos que podem ser usados como elementos básicos para seu plano de DR, tanto os do Google Cloud quanto os que funcionam em várias plataformas.

A série contém estas partes:

Introdução

O Google Cloud tem uma ampla variedade de produtos que podem ser usados como parte da arquitetura de recuperação de desastres (DR). Esta seção aborda os recursos relacionados a DR dos produtos mais comumente usados como elementos básicos do Google Cloud DR.

Muitos desses serviços têm recursos de alta disponibilidade (HA, na sigla em inglês). A HA não se sobrepõe totalmente ao DR, mas muitos dos objetivos da HA também se aplicam a um plano de DR. Por exemplo, aproveitando os recursos de alta disponibilidade, é possível projetar arquiteturas que otimizem o tempo de atividade e que possam atenuar os efeitos de falhas em pequena escala, como a falha de uma VM. Para saber mais sobre a relação entre DR e HA, consulte o Guia de planejamento de recuperação de desastres.

As seções a seguir descrevem esses elementos básicos da DR do Google Cloud e como eles ajudam você a implementar suas metas de DR.

Computação e armazenamento

Compute Engine
  • Recursos de computação escalonáveis
  • Tipos de máquina predefinidos e personalizados
  • Tempos de inicialização rápidos
  • Snapshots
  • Modelos de instância
  • Grupos de instâncias gerenciadas
  • Instâncias reservadas
  • Discos permanentes
  • Migração em tempo real
Cloud Storage
  • Armazenamento de objetos com alta durabilidade
  • Armazenamento com redundância geográfica
  • Classes de armazenamento
  • Gerenciamento do ciclo de vida de objetos
  • Transferência de dados de outras origens
  • Criptografia em repouso por padrão
GKE
  • Ambiente gerenciado para implantação e escalonamento de aplicativos em contêiner
  • Reparo automático de nós
  • Sondagens de ativação e prontidão
  • Volumes permanentes
  • Clusters de várias zonas e regionais
  • Ferramenta de linha de comando para gerenciar clusters entre regiões

Compute Engine

O Compute Engine fornece instâncias de máquina virtual (VM) e é o principal elemento do Google Cloud. Além de configurar, iniciar e monitorar instâncias do Compute Engine, você normalmente usa uma variedade de recursos relacionados para implementar um plano de DR.

Em cenários de DR, é possível impedir a exclusão acidental de VMs definindo a sinalização de proteção de exclusão. Isso é particularmente útil ao hospedar serviços com estado, como bancos de dados. Para conseguir baixos valores de RTO e RPO, siga as práticas recomendadas para projetar sistemas robustos.

Você pode configurar uma instância com o aplicativo pré-instalado e, em seguida, salvar essa configuração como uma imagem personalizada. Essa imagem pode refletir o RTO que você quer alcançar.

Modelos de instância

Use modelos de instância do Compute Engine para salvar os detalhes de configuração da VM e, em seguida, criar instâncias com base nos modelos atuais. É possível usar o modelo para iniciar quantas instâncias forem necessárias, configuradas exatamente da maneira desejada, quando você precisar manter seu ambiente de destino de recuperação de desastres. Os modelos de instância são replicados globalmente para que você possa recriar facilmente a instância em qualquer lugar no Google Cloud com a mesma configuração.

Para criar modelos de instância, use uma imagem personalizada ou com base em instâncias de VM atuais.

Fornecemos mais detalhes sobre o uso de imagens do Compute Engine na seção como balancear a configuração da imagem e a velocidade de implantação, mais adiante neste documento.

Grupos de instâncias gerenciadas

Os grupos de instâncias gerenciadas trabalham com o Cloud Load Balancing (discutido posteriormente neste documento) para distribuir o tráfego para grupos de instâncias configuradas de forma idêntica, que são copiadas entre as zonas. Os grupos de instâncias gerenciadas permitem o uso de recursos como escalonamento automático e recuperação automática, em que o grupo de instâncias gerenciadas pode excluir e recriar instâncias automaticamente.

Instâncias reservadas

O Compute Engine permite a reserva de instâncias de VM em uma zona específica, usando tipos de máquina personalizados ou predefinidos, com ou sem GPUs ou SSDs locais. Isso é útil em cenários de DR frios, em que os recursos de recuperação podem ser reservados e permanecer disponíveis para uso em um failover sem precisar configurá-los e implantá-los completamente.

Discos permanentes e snapshots

Os discos permanentes são dispositivos de armazenamento de rede duráveis que podem ser acessados por suas instâncias. Eles são independentes das instâncias, portanto, você pode separar e mover discos permanentes para manter os dados mesmo depois de excluir suas instâncias.

É possível fazer backups incrementais ou instantâneos das VMs do Compute Engine que você pode copiar nas regiões e usar para recriar discos permanentes no caso de um desastre. Além disso, é possível criar snapshots de discos permanentes para se proteger contra perda de dados devido a erros dos usuários. Os instantâneos são incrementais e levam apenas alguns minutos para serem criados, mesmo se os discos dos instantâneos estiverem anexados a instâncias em execução.

Os discos permanentes têm redundância incorporada para proteger os dados contra falhas de equipamentos e garantir a disponibilidade de dados por meio de eventos de manutenção de data center. Os discos permanentes são zonais ou regionais. Os discos permanentes regionais replicam gravações em duas zonas em uma região. No caso de uma interrupção zonal, uma instância de VM de backup pode forçar a anexação de um disco permanente regional na zona secundária. Para saber mais, consulte Opções de alta disponibilidade usando discos permanentes regionais.

Migração em tempo real

A Migração em tempo real mantém suas instâncias de VM em execução mesmo quando ocorre um evento do sistema host, como uma atualização de software ou hardware. O Compute Engine migra em tempo real suas instâncias em execução para outro host na mesma zona em vez de exigir que as VMs sejam reinicializadas. Isso permite que o Google realize manutenção integral para manter a infraestrutura protegida e confiável sem interromper nenhuma de suas VMs.

Ferramenta de importação de disco virtual

A ferramenta de importação de disco virtual permite importar formatos de arquivo, incluindo VMDK, VHD e RAW, para criar novas máquinas virtuais do Compute Engine. Com essa ferramenta, é possível criar máquinas virtuais do Compute Engine com a mesma configuração das máquinas virtuais locais. Essa é uma boa abordagem quando não é possível configurar imagens do Compute Engine a partir dos binários de origem do software que já estão instalados em suas imagens.

Cloud Storage

O Cloud Storage é um armazenamento de objetos ideal para armazenar arquivos de backup. Ele fornece diferentes classes de armazenamento, adequadas para casos de uso específicos, conforme descrito no diagrama a seguir.

Diagrama mostrando o armazenamento padrão para acesso de alta frequência, Nearline e Coldline para acesso de baixa frequência e Archive para acesso de menor frequência

Em cenários de DR, Nearline, Coldline e Archive Storage são de especial interesse. Essas classes de armazenamento reduzem o custo em comparação com o armazenamento padrão. No entanto, existem outros custos associados à recuperação de dados ou metadados armazenados nessas classes, assim como durações de armazenamento mínimas pelas quais é possível receber cobranças. O Nearline é projetado para cenários de backup em que o acesso é feito no máximo uma vez por mês, o que é ideal para permitir testes regulares de estresse de DR e manter os custos baixos.

Nearline, Coldline e Archive são otimizados para acesso pouco frequente, e o modelo de preços é projetado tendo isso em mente. Portanto, você é cobrado por períodos mínimos de armazenamento e há custos extras para recuperar dados ou metadados nessas classes antes da duração mínima de armazenamento da classe.

O Storage Transfer Service permite importar dados do Amazon S3 ou fontes baseadas em HTTP para o Cloud Storage. Em cenários de DR, é possível usar o Serviço de transferência do Cloud Storage para:

  • Fazer backup de dados de outros provedores de armazenamento para um bucket do Cloud Storage.
  • Mova os dados de um bucket multirregional para um bucket em uma região só para reduzir os custos de armazenamento de backups.

Filestore

As instâncias do Filestore são servidores de arquivos NFS totalmente gerenciados para uso com aplicativos executados em instâncias do Compute Engine ou clusters do GKE.

As instâncias do Cloud Filestore são divididas por zonas e não podem ser replicadas entre elas. Uma instância do Cloud Filestore não estará disponível se a zona em que ela está estiver inativa. Recomendamos fazer backup periódico dos dados sincronizando o volume do Filestore com uma instância do Filestore em outra região usando o comando gsutil rsync. Isso exige que um job seja programado para ser executado em instâncias do Compute Engine ou em clusters do GKE.

Em cenários de DR, os aplicativos podem retomar o acesso aos volumes do Filestore rapidamente alternando para o Filestore em regiões de failover sem precisar aguardar a conclusão de qualquer processo de restauração. O valor de RTO dessa solução de DR depende em grande parte da frequência do job programado.

GKE

O GKE é um ambiente gerenciado e pronto para produção para implantar aplicativos em contêineres. Ele permite orquestrar sistemas de alta disponibilidade e inclui os seguintes recursos:

  • Reparo automático de nós: se as verificações de integridade mostrarem falha consecutiva de um nó por um tempo de aproximadamente 10 minutos, o GKE iniciará um processo de reparação.
  • Sondagem de ativação: especifique uma sondagem de ativação, que informa periodicamente ao GKE que o pod está em execução. Se o pod falhar, a sondagem pode ser reiniciada.
  • Volumes permanentes: os bancos de dados precisam ser capazes de persistir após o fim da vida do contêiner. Usando a abstração de volumes permanentes (link em inglês), que mapeia para um disco permanente do Compute Engine, é possível manter a disponibilidade de armazenamento independentemente dos contêineres individuais.
  • Clusters regionais e de várias zonas: é possível distribuir recursos do Kubernetes entre várias zonas dentro de uma região.
  • Kubemci: essa ferramenta permite configurar um balanceador de carga global para balancear a carga de tráfego entre vários clusters do GKE em diferentes regiões.

Rede e transferência de dados

Cloud Load Balancing
  • Verificações de integridade
  • IP Anycast único
  • Entre regiões
  • Integração com o Cloud CDN
  • Integração com escalonamento automático
Traffic Director
  • ILB L7 global gerenciado pelo Google
  • Plano de controle para proxies de serviço aberto compatíveis com xDSv2
  • Compatível com VMs e contêineres
  • Descarga da verificação de integridade
  • Escalonamento automático rápido
  • Políticas avançadas de roteamento de solicitações e controle de tráfego
Cloud DNS
  • Gerenciamento de DNS programático
  • Controle de acesso
  • Anycast para exibição em zonas
Cloud Interconnect
  • Cloud VPN (VPN IPsec)
  • Peering direto

Cloud Load Balancing

O Cloud Load Balancing fornece alta disponibilidade para o Compute Engine por meio da distribuição das solicitações de usuários entre um conjunto de instâncias. Configure o Cloud Load Balancing com verificações de integridade, que determinam se as instâncias estão disponíveis. Assim, o tráfego não é encaminhado para instâncias com falha.

O Cloud Load Balancing fornece um único endereço IP acessível globalmente para as instâncias do Compute Engine. Seu aplicativo pode ter instâncias em execução em regiões diferentes (por exemplo, na Europa e nos EUA), e seus usuários finais são direcionados para o conjunto de instâncias mais próximo. Além de fornecer balanceamento de carga para serviços que estão expostos à Internet, é possível configurar o balanceamento de carga interno (link em inglês) para seus serviços por trás de um endereço IP de balanceamento de carga particular. Esse endereço IP é acessível apenas para instâncias de VM internas da sua nuvem privada virtual (VPC).

Traffic Director

Com o Traffic Director, é possível implantar um plano de controle de tráfego totalmente gerenciado para sua malha de serviço. O Traffic Director gerencia a configuração de proxies de serviço em execução no Compute Engine e no GKE. Implante um serviço em várias regiões para ativar a alta disponibilidade. O Traffic Director descarregará as verificações de integridade do serviço e iniciará uma configuração de failover de proxies de serviço, redirecionando o tráfego para instâncias íntegras.

O Traffic Director também é compatível com conceitos avançados de controle de tráfego, quebra de circuitos e injeção de falha. Com a quebra de circuitos, é possível impor limites em solicitações a um determinado serviço. Depois disso, as solicitações são impedidas de chegar ao serviço, protegendo-o contra maior degradação. Com a injeção de falhas, o Traffic Director pode apresentar atrasos ou cancelar uma fração de solicitações a um serviço, permitindo que você teste facilmente a capacidade do serviço de sobreviver a atrasos ou solicitações canceladas.

Cloud DNS

O Cloud DNS oferece uma maneira programática de gerenciar suas entradas de DNS como parte de um processo de recuperação automatizado. O Cloud DNS usa nossa rede global de servidores de nomes Anycast para disponibilizar zonas de DNS de locais redundantes do mundo todo, oferecendo alta disponibilidade e baixa latência aos usuários.

Se você optar por gerenciar entradas de DNS no local, poderá ativar as VMs no Google Cloud para resolver esses endereços por meio do encaminhamento de DNS do Cloud DNS.

Cloud Interconnect

O Cloud Interconnect fornece maneiras de mover informações de outras fontes para o Google Cloud. Falaremos sobre esse produto mais tarde em Como transferir dados de e para o Google Cloud.

Gerenciamento e monitoramento

Painel de status do Cloud
  • Status dos serviços do Google Cloud
Conjunto de operações do Google Cloud
  • Monitoramento do tempo de atividade
  • Alertas
  • Logging
  • Error Reporting
Deployment Manager
  • Processo de implantação repetível e consistente
  • Implantação paralela
  • Modelos
  • Infraestrutura como código

Cloud Status Dashboard

O Painel de status do Cloud mostra a disponibilidade atual dos serviços do Google Cloud. Veja o status na página e assine um feed RSS. Ele será atualizado sempre que houver notícias sobre um serviço.

Cloud Monitoring

O Cloud Monitoring coleta métricas, eventos e metadados do Google Cloud, da AWS, de sondagens de tempo de atividade hospedadas, de instrumentação de aplicativos e de vários outros componentes de aplicativos. Configure alertas para enviar notificações para ferramentas de terceiros, como o Slack ou o Pagerduty, e oferecer atualizações periódicas aos administradores. Outra maneira de usar o Cloud Monitoring para DR é configurar um coletor do Pub/Sub e usar o Cloud Functions para acionar um processo automatizado em resposta a um alerta do Cloud Monitoring.

Deployment Manager

O Deployment Manager permite definir o ambiente do Google Cloud em um conjunto de modelos. Depois, é possível usar os modelos para criar ambientes com um único comando repetidamente e de maneira consistente. Da mesma forma, é possível desativar o ambiente com um único comando. Isso torna o Deployment Manager ideal para definir um ambiente de DR, que pode ser criado com segurança na região que você quiser.

Elementos básicos de DR em várias plataformas

Ao executar cargas de trabalho em mais de uma plataforma, uma maneira de reduzir a sobrecarga operacional é selecionar ferramentas que funcionam com todas as plataformas que você está usando. Nesta seção, discutimos algumas ferramentas e serviços que são independentes de plataforma e, portanto, compatíveis com cenários de DR entre várias plataformas.

Ferramentas de modelos declarativos

As ferramentas de modelos declarativos facilitam a implantação de infraestrutura entre plataformas. Como observado anteriormente, para implantações somente do Google Cloud, é possível usar o Deployment Manager. Para implementações multiplataforma, o Terraform é uma das ferramentas de modelos declarativos mais conhecidas.

Ferramentas de gerenciamento de configurações

Para infraestruturas de DR grandes ou complexas, recomendamos ferramentas de gerenciamento de software independentes de plataforma, como Chef e Ansible. Essas ferramentas garantem que as configurações reproduzíveis possam ser aplicadas em qualquer lugar da carga de trabalho de computação. Para exemplos de uso desses tipos de ferramentas, consulte o tutorial do Ansible com Spinnaker e a Implantação do zero com o Chef no Google Cloud.

Armazenamento de objetos

Um padrão de DR comum é ter cópias em armazenamentos de objetos em diferentes provedores de nuvem. Uma ferramenta de várias plataformas para isso é o boto, que é uma biblioteca Python de código aberto que permite interagir com o Amazon S3 e o Cloud Storage.

Ferramentas do orquestrador

Os contêineres também podem ser considerados um elemento básico de DR. Eles constituem uma maneira de agrupar serviços e introduzir consistência entre as plataformas.

Se você trabalha com contêineres, normalmente usa um orquestrador. O Kubernetes serve para gerenciar contêineres dentro do Google Cloud (usando o GKE) e também oferece uma maneira de orquestrar cargas de trabalho baseadas em contêiner em várias plataformas. O Google Cloud, a AWS e o Microsoft Azure fornecem versões gerenciadas do Kubernetes.

Para distribuir o tráfego para clusters do Kubernetes em execução em diferentes plataformas de nuvem, você pode usar um serviço DNS que ofereça suporte a registros ponderados e incorpore a verificação de integridade.

Além disso, é necessário garantir que seja possível receber a imagem no ambiente de destino. Isso significa que você precisa acessar seu registro de imagem no caso de um desastre. Uma boa opção que também é independente de plataforma é o Container Registry.

Transferência de dados

A transferência de dados é um componente essencial para cenários de DR em várias plataformas. Você precisa projetar, implementar e testar seus cenários de DR em várias plataformas usando modelos realistas do que o cenário de transferência de dados de DR exige. Discutimos os cenários de transferência de dados na próxima seção.

Padrões para DR

Nesta seção, veremos alguns dos padrões mais comuns para arquiteturas de DR com base nos elementos essenciais discutidos anteriormente.

Como transferir dados para e do Google Cloud

Um aspecto importante do seu plano de DR é a rapidez com que os dados podem ser transferidos para e do Google Cloud. Isso é essencial se seu plano de DR é baseado na movimentação de dados do local para o Google Cloud ou de outro provedor de nuvem para o Google Cloud. Esta seção discute a rede e os serviços do Google Cloud que podem garantir uma boa capacidade.

Ao usar o Google Cloud como o local de recuperação para cargas de trabalho locais ou em outro ambiente em nuvem, considere os seguintes itens principais:

  • Como você se conecta ao Google Cloud?
  • Qual é a largura de banda entre você e o provedor de interconexão?
  • Qual é a largura de banda fornecida pelo provedor diretamente ao Google Cloud?
  • Quais outros dados serão transferidos por meio desse link?

Se você usa uma conexão pública de Internet para transferir dados, a capacidade da rede é imprevisível, porque você está limitado pela capacidade e o roteamento do ISP. O ISP pode oferecer um SLA limitado ou nenhum. Por outro lado, o custo dessas conexões é relativamente baixo.

O Cloud Interconnect oferece várias opções para se conectar ao Google e ao Google Cloud:

  • O Cloud VPN permite a criação de túneis VPN IPsec entre uma rede VPC do Google Cloud e uma rede de destino. O tráfego entre as duas redes é criptografado por um gateway de VPN e depois descriptografado por outro gateway desse tipo. A VPN de alta disponibilidade permite criar conexões VPN de alta disponibilidade com um SLA de 99,99%, além de uma configuração simplificada em comparação com a criação de VPNs redundantes.
  • O peering direto fornece saltos mínimos de rede para endereços IP públicos do Google. É possível usar o peering direto para trocar o tráfego da Internet entre sua rede e os pontos de presença perimetrais (PoPs, na sigla em inglês) do Google.
  • A Interconexão dedicada fornece uma conexão física direta entre a rede local e a rede do Google. Ele fornece um SLA com uma capacidade mais consistente para grandes transferências de dados. Os circuitos têm 10 Gbps ou 100 Gbps e são encerrados em uma das instalações de colocation do Google. Com uma largura de banda maior, é possível reduzir o tempo necessário para transferir dados do local para o Google Cloud. A tabela a seguir ilustra os ganhos de velocidade ao fazer upgrade de 10 Gbps para 100 Gbps. Gráfico mostrando o tempo de transferência de dados para 10 Gbps x 100 Gbps
  • A Interconexão por parceiro oferece recursos semelhantes aos da Interconexão dedicada, mas em velocidades de circuito inferiores a 10 Gbps. Consulte Provedores de serviços compatíveis.

O diagrama a seguir fornece orientações sobre qual método de transferência usar, dependendo da quantidade de dados que você precisa transferir para o Google Cloud.

Gráfico que mostra a quantidade de dados no eixo Y (de 0 a 100 TB) e as categorias de localização de dados no eixo X (por exemplo, "No Google Cloud", "No local com boa conectividade" etc.), com transferência diferente soluções em cada categoria

Use a calculadora de tempo de transferência para entender quanto tempo uma transferência pode levar, considerando o tamanho do conjunto de dados que você está movendo e a largura de banda disponível para a transferência. Para ver mais informações sobre transferência de dados como parte do seu planejamento de DR, consulte Como transferir grandes conjuntos de dados.

Como balancear a configuração da imagem e a velocidade de implantação

Ao configurar uma imagem de máquina para implantar novas instâncias, pense no efeito que sua configuração terá na velocidade da implantação. Há um dilema entre a quantidade de pré-configuração da imagem, os custos de manutenção da imagem e a velocidade de implantação. Por exemplo, se uma imagem de máquina estiver minimamente configurada, as instâncias que a usam precisarão de mais tempo para serem iniciadas, porque precisam fazer o download e instalar dependências. Por outro lado, se a imagem de máquina estiver altamente configurada, as instâncias que a usam serão iniciadas mais rapidamente, mas você precisará atualizar a imagem com mais frequência. O tempo necessário para iniciar uma instância totalmente operacional tem uma correlação direta com seu RTO.

Diagrama mostrando 3 níveis de agrupamento (de não agrupado a totalmente agrupado) mapeados em relação ao tempo de inicialização da imagem (o mais agrupado é o mais rápido para inicializar)

Como manter a consistência da imagem de máquina em ambientes híbridos

Se você implementar uma solução híbrida (do local para nuvem ou de nuvem para nuvem), precisará encontrar uma maneira de manter a consistência da VM nos ambientes de produção.

Caso seja necessário usar uma imagem totalmente configurada, use um software como o Packer, que pode criar imagens de máquina idênticas para diversas plataformas. É possível usar os mesmos scripts com arquivos de configuração específicos da plataforma. No caso do Packer, é possível colocar o arquivo de configuração no controle de versão para acompanhar qual versão é implementada na produção. Para ver como criar um pipeline automatizado para a criação contínua de imagens com o Packer e outros utilitários de código aberto, consulte Criações automatizadas de imagem com Jenkins, Packer e Kubernetes.

Outra opção é usar ferramentas de gerenciamento de configuração, como Chef, Puppet, Ansible ou Saltstack, para configurar instâncias com maior granularidade, criando imagens de base, imagens minimamente configuradas ou imagens totalmente configuradas conforme necessário. Para uma discussão sobre como usar essas ferramentas de maneira eficaz, consulte o tutorial do Ansible com o Spinnaker e a Implantação do zero com o Chef no Google Cloud (link em inglês).

Também é possível converter e importar manualmente as imagens existentes, como Amazon AMIs, imagens de Virtualbox e imagens de disco RAW, para o Compute Engine.

Como implementar o armazenamento em níveis

O padrão de armazenamento em níveis é normalmente usado para backups em que o backup mais recente fica em um armazenamento mais rápido e, lentamente, você migra os backups mais antigos para um armazenamento mais barato e mais lento. Há duas maneiras de implementar o padrão usando o Cloud Storage, dependendo da origem dos dados: no Google Cloud ou no local. Em ambos os casos, você migra objetos entre buckets de diferentes classes de armazenamento, geralmente da classe de armazenamento padrão para a Nearline (custo mais baixo).

Diagrama mostrando dados migrando de um disco permanente para o armazenamento padrão e para o armazenamento Nearline

Se seus dados de origem forem gerados no local, a implementação será parecida com o diagrama a seguir:

Diagrama mostrando dados migrando do local por meio do Cloud Interconnect para o Cloud Storage

Como alternativa, é possível alterar a classe de armazenamento dos objetos em um bucket usando as regras de ciclo de vida do objeto para automatizar a mudança da classe de objeto.

Como manter o mesmo endereço IP para instâncias particulares

Um padrão comum é manter uma única instância de exibição de uma VM. Se a VM precisar ser substituída, a substituta precisará ser idêntica à VM original. Portanto, o endereço IP que os clientes usam para se conectar à nova instância deverá permanecer o mesmo.

A configuração mais simples é definir um grupo de instâncias gerenciadas que mantém exatamente uma instância. Esse grupo de instâncias gerenciadas é integrado a um balanceador de carga interno (particular) que garante que o mesmo endereço IP seja usado para fazer frente à instância, independentemente de ser a imagem original ou uma substituição.

Parceiros em tecnologia

O Google tem um ecossistema de parceiros robusto compatível com casos de uso de backup e DR com o Google Cloud. Especificamente, vemos clientes usando soluções de parceiros para:

  • Fazer backup de dados no local para o Google Cloud. Nesses casos, o Cloud Storage é integrado como um destino de armazenamento para a maioria das plataformas de backup locais. Use essa abordagem para substituir fitas e outros dispositivos de armazenamento.
  • Implementar um plano de DR que vá do local para o Google Cloud. Nossos parceiros podem ajudar a eliminar data centers secundários e usar o Google Cloud como o local de DR.
  • implementar DR e backup para cargas de trabalho baseadas em nuvem.

Para mais informações sobre soluções de parceiros, consulte a página Parceiros no site do Google Cloud.

A seguir