Disponibilidade e durabilidade dos dados

Nesta página, discutimos conceitos relacionados à disponibilidade e à durabilidade de dados no Cloud Storage. Isso inclui o modo do Cloud Storage de armazenar dados de forma redundante, o comportamento de replicação padrão para birregiões e multirregiões, o recurso de replicação turbo para birregiões e o recurso de replicação entre buckets.

Principais conceitos

  • O Cloud Storage foi projetado para oferecer durabilidade anual de 99,999999999% (11 noves).

    • Para isso, o Cloud Storage usa codificação de limpeza e armazena partes de dados de forma redundante em vários dispositivos localizados em várias zonas de disponibilidade.

    • O Cloud Storage armazena objetos de forma redundante, que são gravados nele em pelo menos duas zonas de disponibilidade diferentes antes de considerar a gravação bem-sucedida.

    • Os checksums são armazenados e revalidados regularmente para verificar de forma proativa a integridade de todos os dados em repouso, além de detectar a corrupção dos dados em trânsito. Se necessário, as correções são feitas automaticamente usando dados redundantes.

  • A disponibilidade mensal dos dados armazenados no Cloud Storage depende da classe de armazenamento dos dados e do tipo de local do bucket. Para mais informações, consulte as classes de armazenamento disponíveis.

  • Os objetos armazenados em um bucket birregional ou multirregional são armazenados de maneira redundante em pelo menos dois locais geográficos diferentes.

    • Para birregiões, você seleciona as regiões específicas em que seus objetos são armazenados.

    • Para multirregiões, os data centers específicos usados para armazenar os dados são determinados pelo Cloud Storage conforme necessário, mas estão localizados dentro do limite geográfico da multirregião e estão separados por pelo menos 160 quilômetros. Isso oferece redundância entre regiões por um custo de armazenamento menor do que as birregiões.

    • No caso improvável de uma falha temporária em toda a região, como aquela causada por um desastre natural, os buckets birregionais e multirregionais permanecerão disponíveis, sem a necessidade de alterar os caminhos de armazenamento.

  • Objetos armazenados em buckets birregionais e multirregionais geralmente são replicados em locais geográficos usando a replicação padrão.

    • Se um dos locais em que um objeto é armazenado ficar indisponível após seu upload, mas antes de o objeto ser replicado no segundo local, a consistência forte do Cloud Storage garantirá que as versões desatualizadas do objeto não serão disponibilizadas e que as substituições subsequentes não serão revertidas quando a região ficar disponível novamente.

    • Objetos armazenados em birregiões podem usar opcionalmente a replicação turbo para conseguir uma replicação mais rápida e previsível entre as regiões.

  • Para conseguir redundância entre um par de regiões não disponível como birregião, crie um bucket diferente em cada região e use as Transferências orientadas por eventos do Serviço de transferência do Cloud Storage ou a replicação entre buckets para manter os buckets em sincronia.

Redundância entre regiões

Embora os modelos de armazenamento tradicionais geralmente dependam de uma abordagem ativa-passiva com localizações geográficas "primárias" e "secundárias", o Cloud Storage oferece uma arquitetura ativa-ativa com base em um único bucket com redundância entre regiões. Isso simplifica o processo de recuperação de desastres eliminando a necessidade de os usuários replicarem dados de um bucket para outro ou realizarem failover manualmente no bucket secundário em caso de inatividade da região primária.

O Cloud Storage sempre compreende o estado atual de um bucket e disponibiliza objetos de uma região disponível de forma transparente, conforme necessário. Como resultado, os buckets birregionais e multirregionais são projetados para ter um objetivo do tempo de recuperação (RTO) de zero, e as falhas regionais temporárias normalmente são invisíveis para os usuários. No caso de falha temporária regional, os buckets birregionais e multirregionais continuam disponibilizando automaticamente todos os dados replicados entre as regiões.

No entanto, a redundância nas regiões ocorre de forma assíncrona, e todos os dados que não terminam de replicar entre regiões antes que uma região fique indisponível ficam inacessíveis até que a região desativada fique on-line novamente. Os dados podem ser perdidos no caso muito improvável de destruição física da região.

A replicação padrão no Cloud Storage foi projetada para oferecer redundância entre regiões para 99,9% dos objetos recém-gravados no escopo de 1 hora e 100% dos objetos recém-gravados no escopo de 12 horas. Os objetos recém-gravados incluem uploads, regravações, cópias e composições.

Replicação turbo

A replicação turbo fornece redundância mais rápida entre regiões para dados nos seus buckets birregionais, o que reduz o risco de exposição à perda de dados e ajuda a oferecer suporte a serviços sem interrupções após uma falha temporária regional. Quando ativada, a replicação turbo é projetada para replicar 100% dos objetos recém-gravados nas duas regiões que constituem a birregião dentro do objetivo do ponto de recuperação de 15 minutos, independentemente do tamanho do objeto.

Mesmo na replicação padrão, a maioria dos objetos termina a replicação em minutos.

Embora a redundância entre regiões e a replicação turbo ajudem a dar suporte a continuidade de negócios e esforços de recuperação de desastres (BCDR, na sigla em inglês), os administradores precisam planejar e implementar uma arquitetura BCDR completa que seja apropriada para a carga de trabalho deles.

Para mais informações, consulte o guia passo a passo para projetar a recuperação de desastres para aplicativos no Google Cloud.

Limitações

  • A replicação turbo está disponível apenas para buckets em regiões birregionais.

  • A replicação turbo não pode ser gerenciada pela API XML, incluindo a criação de um novo bucket com replicação turbo ativada.

  • Quando a replicação turbo está ativada em um bucket, ela pode levar até 10 segundos para começar a ser aplicada a objetos recém-gravados.

  • As gravações de objetos que começaram antes de ativar a replicação turbo em um bucket são replicadas entre as regiões com a taxa de replicação padrão.

    • A composição de objetos, que usa objetos de origem gravados com a replicação padrão nas últimas 12 horas, cria um objeto composto que também usa a replicação padrão.

Replicação entre buckets

Em alguns casos, talvez você queira manter uma cópia dos dados em um segundo bucket. A replicação entre buckets copia objetos novos e atualizados de forma assíncrona de um bucket de origem para um de destino.

A replicação entre buckets é diferente da replicação padrão e turbo porque os dados existem em dois buckets, cada um com suas configurações, como local de armazenamento, criptografia, acesso e classe de armazenamento. Como resultado, ele oferece recuperação e disponibilidade de dados, mas também é adequado para:

  • Soberania de dados: mantenha dados em regiões geograficamente distantes.
  • Manter versões de desenvolvimento e produção separadas: crie buckets e namespaces distintos para que o desenvolvimento não afete a carga de trabalho de produção.
  • Compartilhar dados: replicar dados para um bucket de um fornecedor ou parceiro.
  • Agregação de dados: combinar dados dos buckets diferentes em um único bucket para executar cargas de trabalho de análise.
  • Gerenciar custos, segurança e conformidade: manter os dados em diferentes propriedades, classes de armazenamento e períodos de retenção.

A replicação entre buckets usa o Serviço de transferência do Cloud Storage para replicar objetos e o Pub/Sub para receber alertas sobre mudanças nos buckets de origem e destino. A replicação entre buckets pode ser ativada em novos buckets criados e em buckets existentes. A maioria dos objetos pode ser replicada em minutos, enquanto objetos maiores que um GiB podem levar várias horas.

Para instruções sobre como usar a replicação entre buckets, consulte Usar a replicação entre buckets.

Limitações

  • As exclusões de objetos no bucket de origem não são replicadas no bucket de destino.

  • As configurações do ciclo de vida do objeto não são replicadas.

  • Quando os objetos são replicados, os metadados de carimbo de data/hora (por exemplo, timeCreated e timeUpdated) não são preservados. Consulte Transferências entre buckets do Cloud Storage para saber mais sobre a preservação de metadados.

Monitoramento de desempenho

O Cloud Storage monitora os objetos não replicados mais antigos. Se um objeto não for replicado por mais tempo do que o tempo de RPO (objetivo de ponto de recuperação), ele será considerado fora do RPO. Cada minuto em que um ou mais objetos estão fora do RPO é contado como um minuto "ruim".

Por exemplo, se um objeto tiver gerado 20 minutos ruins das 9h às 9h20 e outro objeto tiver gerado 10 minutos ruins das 9h15 às 9h25, haverá dois objetos para os que estão sem RPO. O número total de minutos ruins no mês é de 25 minutos, porque das 9h às 9h25 havia pelo menos um objeto que não tinha o RPO.

  • Para buckets que usam a replicação turbo, o RPO para objetos é de 15 minutos.

  • Para buckets que usam a replicação padrão, o RPO para objetos é de 12 horas.

    • Para buckets que usam replicação padrão, os objetos normalmente são replicados em uma hora ou menos.

  • A replicação entre buckets não fornece um RPO.

No console do Google Cloud, a porcentagem de minutos do gráfico de RPO permite monitorar a porcentagem de minutos ruins durante os últimos 30 dias para o bucket. Esse indicador de nível de serviço pode ser usado para monitorar a conformidade mensal de tempo de replicação do seu bucket. Da mesma forma, a porcentagem de objetos fora de destino rastreia replicações de objetos que não ocorreram no RPO. Esse indicador de nível de serviço pode ser usado para monitorar a conformidade do volume de replicação mensal do bucket. Para mais informações, consulte Monitoramento do Cloud Storage e SLA do Cloud Storage.

A seguir