Disponibilidade e durabilidade dos dados

Esta página explica os conceitos de disponibilidade e durabilidade no Cloud Storage:

  • Disponibilidade: capacidade de acessar dados imediatamente após a solicitação.

  • Durabilidade: proteção de longo prazo para garantir que os dados permaneçam intactos e não corrompidos.

As seções a seguir abordam como o Cloud Storage armazena dados de forma redundante, o comportamento de replicação padrão para birregiões e multirregiões e recursos avançados, como replicação turbo e replicação entre buckets.

Principais conceitos

  • 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.

  • O Cloud Storage foi projetado para ter uma durabilidade anual de pelo menos 99,999999999% (11 noves), independentemente da classe de armazenamento e do tipo de local.

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

    • As gravações no Cloud Storage só são confirmadas como bem-sucedidas depois que os dados são armazenados de forma redundante.

    • 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.

Como o tipo de local de um bucket afeta a disponibilidade e a durabilidade

  • Os bucketsregionais armazenam dados de forma redundante em pelo menos duas zonas de disponibilidade na região selecionada. Eles são projetados para tolerar a perda de qualquer zona de disponibilidade na região.

    • As gravações de objetos em um bucket só são confirmadas como bem-sucedidas depois que os dados são armazenados de forma redundante em pelo menos duas zonas de disponibilidade diferentes.

    • No caso improvável de uma interrupção na zona de disponibilidade, como uma causada por um desastre natural, os buckets regionais permanecem disponíveis, sem a necessidade de mudar os caminhos de armazenamento.

  • Os buckets birregionais e multirregionais armazenam dados de forma 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.

    • As gravações de objetos em um bucket só são confirmadas como bem-sucedidas depois que os dados são armazenados de forma redundante em uma região inicial, em pelo menos duas zonas de disponibilidade diferentes (o mesmo que gravações em um bucket regional). Os dados são replicados de forma assíncrona usando a replicação padrão para fornecer a redundância esperada entre regiões.

      • Se uma das regiões em que um objeto é armazenado ficar indisponível após o upload, mas antes de o objeto ser replicado para georredundância, 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.

      • Como uma oferta premium, você pode ativar a replicação turbo em buckets birregionais para conseguir tempos de replicação mais rápidos e previsíveis entre regiões para dados recém-gravados.

    • No caso improvável de uma interrupção do serviço 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.

    • Para conseguir redundância entre um par de regiões não disponível como birregião, crie um bucket diferente para 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.

  • Os dados redundantes localmente, como dados em um bucket zonal, oferecem 99,999999999% (11 noves) de durabilidade anual contra falhas de hardware, como falhas de host, rack ou unidade. No entanto, como os dados não são redundantes em todas as zonas de disponibilidade, eles podem ficar indisponíveis ou perdidos permanentemente em caso de falha na zona de disponibilidade. Como resultado, o armazenamento redundante local é mais adequado para dados que podem ser substituídos ou reconstruídos.

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", as birregiões e multirregiões do Cloud Storage oferecem 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.

O Cloud Storage também oferece um recurso de replicação entre buckets que pode ser usado para replicar dados entre buckets independentes para atender a outras necessidades de replicação de dados que não são atendidas por locais birregionais ou multirregionais.

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), 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 detalhado para projetar a recuperação de desastres para aplicativos em 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 independentes, cada um com suas configurações, como local de armazenamento, criptografia, acesso e classe de armazenamento. É especialmente 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 sua carga de trabalho de produção.
  • Compartilhar dados: replique dados em um bucket de propriedade de um fornecedor ou parceiro.
  • Agregar dados: combine dados de diferentes buckets em um único bucket para executar cargas de trabalho de análise.
  • Gerenciar custos, segurança e conformidade: mantenha seus dados em diferentes proprietários, 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 Pub/Sub para receber alertas sobre mudanças nos buckets de origem e destino. É possível ativar a replicação entre buckets em novos buckets criados e em buckets atuais.

Para buckets em que a taxa de mudança de objetos é inferior a 3.000 por segundo e os objetos têm menos de um GiB, a replicação entre buckets geralmente leva de minutos a dezenas de minutos, mas nenhum limite superior específico é aceito. Além disso, os buckets que têm taxas de mudança mais altas ou objetos maiores podem ter atrasos de replicação maiores.

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

Limitações

  • Nomes personalizados não são aceitos para jobs de replicação entre buckets. As solicitações de criação que contêm um valor para o campo name retornam um erro.

  • A replicação entre buckets não é aceita para buckets de namespace hierárquicos ou buckets zonais.

  • 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.

  • Como a replicação entre buckets pode ser usada para replicar dados entre buckets localizados em qualquer Google Cloud lugar, o desempenho da replicação entre buckets varia de acordo com os locais selecionados. Consequentemente, a replicação entre buckets não oferece um objetivo do ponto de recuperação (RPO).

  • Os objetos que já estão no bucket quando um job de replicação é criado não são replicados automaticamente. Somente objetos novos e atualizados são replicados. Para replicar objetos atuais, crie um job de transferência do Serviço de transferência do Cloud Storage único do bucket atual para o novo. Consulte Criar transferências para instruções.

Monitoramento de desempenho

O Cloud Storage monitora os objetos não replicados mais antigos em buckets birregionais e multirregionais usando a replicação padrão ou a replicação turbo. Se um objeto não for replicado por mais tempo do que o tempo do objetivo do ponto de recuperação (RPO), 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 Google Cloud console, o gráfico Porcentagem de minutos fora do RPO permite monitorar a porcentagem de minutos ruins durante os últimos 30 dias para o bucket ao usar a replicação padrão ou a replicação turbo em buckets birregionais ou multirregionais. 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 da meta rastreia as replicações de objetos que não ocorreram dentro do 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