Disponibilidade e durabilidade dos dados

Nesta página, explicamos os conceitos de disponibilidade e durabilidade no Cloud Storage:

  • Disponibilidade: a capacidade de acessar dados imediatamente mediante solicitação.

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

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 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 oferecer durabilidade anual de pelo menos 99,999999999% (11 noves), independente 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 buckets regionais armazenam dados de modo redundante em pelo menos duas zonas de disponibilidade na região selecionada. Eles foram 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 em uma 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 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.

    • 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). Em seguida, 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 está armazenado ficar indisponível depois que o objeto for transferido por upload com sucesso, mas antes de ser replicado para georredundância, a consistência forte do Cloud Storage garante que versões desatualizadas do objeto não sejam disponibilizadas e que substituições subsequentes não sejam revertidas quando a região ficar disponível novamente.

      • Como uma oferta premium, você pode ativar opcionalmente 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 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.

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

  • Dados redundantes locais, como dados em um bucket zonal, oferecem durabilidade anual de 99,999999999% (11 noves) 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 ser perdidos permanentemente em caso de falha em uma zona de disponibilidade. Como resultado, o armazenamento localmente redundante é 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 regiões duplas e multirregionais 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 e atender a necessidades adicionais 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, 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 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. Ele é 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 a carga de trabalho de produção.
  • Compartilhamento de dados: replicar dados para um bucket de um fornecedor ou parceiro.
  • Agregação de dados: combine dados de diferentes buckets 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 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 1 GiB, a replicação entre buckets geralmente leva de alguns minutos a dezenas de minutos, mas não há um limite superior específico. Além disso, buckets com 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 compatíveis com 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 é compatível com buckets de namespace hierárquicos.

  • 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 local, o desempenho da replicação entre buckets varia de acordo com os locais selecionados. Por isso, a replicação entre buckets não oferece um objetivo de 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 única do Serviço de transferência do Cloud Storage do bucket atual para o novo. Consulte as instruções em Criar transferências.

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 turbo. 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 , o gráfico Porcentagem de minutos fora do RPO permite monitorar a porcentagem de minutos inválidos durante os últimos 30 dias para o bucket ao usar a replicação padrão ou 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 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