Redundância do Armazenamento do Azure

O Azure Storage armazena sempre várias cópias dos seus dados para que esteja protegido contra eventos planeados e não planeados, incluindo falhas de hardware transitórios, falhas de rede ou de energia e desastres naturais maciços. A redundância garante que a sua conta de armazenamento cumpre os seus objetivos de disponibilidade e durabilidade mesmo face a falhas.

Ao decidir qual a opção de despedimento melhor para o seu cenário, considere as trocas entre custos mais baixos e maior disponibilidade. Os fatores que ajudam a determinar qual a opção de redundância que deve escolher incluem:

  • Como os seus dados são replicados na região primária.
  • Se os seus dados são replicados para uma segunda região que está geograficamente distante da região primária, para proteger contra desastres regionais (geo-replicação).
  • Se a sua aplicação requer acesso lido aos dados replicados na região secundária se a região primária ficar indisponível por qualquer motivo (geo-replicação com acesso lido).

Nota

As funcionalidades e disponibilidade regional descritas neste artigo também estão disponíveis para contas que têm um espaço hierárquico de nome (armazenamento Azure Blob).

Os serviços que compõem o Azure Storage são geridos através de um recurso comum Azure chamado uma conta de armazenamento. A conta de armazenamento representa um conjunto partilhado de armazenamento que pode ser usado para implantar recursos de armazenamento, tais como recipientes blob (Blob Storage), ações de ficheiros (Ficheiros do Azure), mesas (Armazenamento de Mesa) ou filas (Armazenamento de Fila). Para obter mais informações sobre as contas de Armazenamento Azure, consulte a visão geral da conta de Armazenamento.

A definição de despedimento de uma conta de armazenamento é partilhada para todos os serviços de armazenamento expostos por essa conta. Todos os recursos de armazenamento implantados na mesma conta de armazenamento têm a mesma definição de redundância. Pode querer isolar diferentes tipos de recursos em contas de armazenamento separadas se tiverem diferentes requisitos de despedimento.

Redundância na região primária

Os dados numa conta de Armazenamento Azure são sempre replicados três vezes na região primária. O Armazenamento do Microsoft Azure oferece duas opções para a forma como os dados são replicados na região primária:

  • O armazenamento localmente redundante (LRS) copia os seus dados de forma sincronizada três vezes num único local físico na região primária. O LRS é a opção de replicação menos dispendiosa, mas não é recomendado para aplicações que requerem elevada disponibilidade ou durabilidade.
  • O armazenamento redundante de zona (ZRS) copia os seus dados de forma sincronizada em três zonas de disponibilidade de Azure na região primária. Para aplicações que requerem elevada disponibilidade, a Microsoft recomenda a utilização de ZRS na região primária e também a replicação para uma região secundária.

Nota

A Microsoft recomenda a utilização de ZRS na região primária para Azure Data Lake Storage Gen2 cargas de trabalho.

Armazenamento localmente redundante

O armazenamento localmente redundante (LRS) replica a sua conta de armazenamento três vezes dentro de um único centro de dados na região primária. O LRS proporciona pelo menos 99.999999999999999999 % (11 noves) de durabilidade de objetos durante um determinado ano.

O LRS é a opção de despedimento mais barata e oferece a menor durabilidade em comparação com outras opções. O LRS protege os seus dados contra as falhas de suporte do servidor e da unidade. No entanto, se ocorrer uma catástrofe como incêndio ou inundação dentro do centro de dados, todas as réplicas de uma conta de armazenamento utilizando LRS podem ser perdidas ou irrecuperáveis. Para mitigar este risco, a Microsoft recomenda a utilização de armazenamento redundante de zona (ZRS), armazenamento geo-redundante (GRS) ou armazenamento de geo-zonas redundantes (GZRS).

Um pedido de escrita para uma conta de armazenamento que está a usar LRS acontece sincronizadamente. A operação de escrita só regressa com sucesso depois de os dados terem sido escritos nas três réplicas.

O diagrama a seguir mostra como os seus dados são replicados num único centro de dados com LRS:

Diagrama mostrando como os dados são replicados num único centro de dados com LRS

LRS é uma boa escolha para os seguintes cenários:

  • Se a sua aplicação armazenar dados que podem ser facilmente reconstruídos se ocorrer perda de dados, poderá optar pelo LRS.
  • Se a sua aplicação se limitar a replicar dados apenas dentro de um país ou região devido aos requisitos de governação de dados, poderá optar pelo LRS. Em alguns casos, as regiões emparelhadas em que os dados são geo-replicados podem estar noutro país ou região. Para obter mais informações sobre as regiões emparelhadas, consulte as regiões de Azure.
  • Se o seu cenário estiver a utilizar discos não geridos do Azure, pode optar pelo LRS. Embora seja possível criar uma conta de armazenamento para discos não geridos Azure que usam GRS, não é recomendado devido a potenciais problemas com consistência sobre a geo-replicação assíncrona.

Armazenamento com redundância entre zonas

O armazenamento redundante de zona (ZRS) replica a sua conta de armazenamento sincronizadamente em três zonas de disponibilidade de Azure na região primária. Cada zona de disponibilidade é uma localização física separada com energia, refrigeração e rede independentes, A ZRS oferece uma durabilidade para recursos de armazenamento de pelo menos 99.999999999999999999999999999999999 (12 9's) durante um determinado ano.

Com o ZRS, os seus dados ainda estão acessíveis tanto para operações de leitura como para escrever, mesmo que uma zona fique indisponível. Se uma zona ficar indisponível, o Azure realiza atualizações de rede, como a repontagem de DNS. Estas atualizações podem afetar a sua aplicação se aceder a dados antes de as atualizações terem sido concluídas. Ao conceber aplicações para ZRS, siga as práticas de manuseamento transitório de falhas, incluindo a implementação de políticas de retripagem com recuo exponencial.

Um pedido de escrita para uma conta de armazenamento que está a usar o ZRS acontece sincronizadamente. A operação de escrita só regressa com sucesso depois de os dados forem escritos a todas as réplicas nas três zonas de disponibilidade.

A Microsoft recomenda a utilização de ZRS na região primária para cenários que exijam elevada disponibilidade. O ZRS também é recomendado para restringir a replicação de dados a um determinado país ou região para satisfazer os requisitos de governação de dados.

A Microsoft recomenda a utilização de ZRS para Ficheiros do Azure cargas de trabalho. Se uma zona ficar indisponível, não é necessária a remontagem das ações de ficheiros Azure dos clientes ligados.

O seguinte diagrama mostra como os seus dados são replicados em zonas de disponibilidade na região primária com ZRS:

Diagrama mostrando como os dados são replicados na região primária com ZRS

O ZRS proporciona um excelente desempenho, baixa latência e resiliência para os seus dados se ficar temporariamente indisponível. No entanto, o ZRS por si só pode não proteger os seus dados contra um desastre regional onde várias zonas são permanentemente afetadas. Para proteção contra desastres regionais, a Microsoft recomenda a utilização de armazenamento redundante em geo-zona (GZRS), que utiliza ZRS na região primária e também geo-replica os seus dados para uma região secundária.

O nível de arquivo para armazenamento blob não é atualmente suportado para contas ZRS, GZRS ou RA-GZRS. Os discos não geridos não suportam ZRS ou GZRS.

Para obter mais informações sobre quais as regiões que suportam zrs, consulte as regiões de Azure com zonas de disponibilidade.

Contas de armazenamento Standard

O ZRS é suportado para todos os serviços de Armazenamento Azure através de contas de armazenamento v2 de uso geral padrão, incluindo:

  • Armazenamento Azure Blob (bolhas de bloco quentes e frescos e bolhas de apêndice, bolhas de página não-disco)
  • Ficheiros do Azure (todos os níveis padrão: transação otimizada, quente e fresca)
  • Armazenamento de Tabelas do Azure
  • Armazenamento de Filas do Azure

ZRS para contas de armazenamento v2 de uso geral padrão está disponível para um subconjunto de regiões de Azure:

  • (África) África do Sul Norte
  • (Ásia-Pacífico) Austrália Leste
  • (Ásia-Pacífico) Índia Central
  • (Ásia-Pacífico) Ásia Oriental
  • Leste do Japão (Ásia-Pacífico)
  • (Ásia-Pacífico) Coreia Central
  • (Ásia-Pacífico) Sudeste Asiático
  • (Europa) França Central
  • (Europa) Alemanha Centro Ocidental
  • (Europa) Norte da Europa
  • (Europa) Leste da Noruega
  • (Europa) Suécia Central
  • (Europa) Suíça Norte
  • (Europa) Reino Unido Sul
  • (Europa) Europa Ocidental
  • (América do Norte) Canadá Central
  • (América do Norte) Central EUA
  • (América do Norte) Leste dos EUA
  • (América do Norte) Leste dos EUA 2
  • (América do Norte) Centro Sul dos EUA
  • (América do Norte) Eua Gov Virginia
  • (América do Norte) West US 2
  • (América do Norte) West US 3
  • (América do Sul) Brasil Sul

Contas blob de bloco premium

O ZRS é suportado para contas de blobs de bloco premium. Para obter mais informações sobre as bolhas de bloco premium, consulte as contas de armazenamento de bloco premium.

Bolhas de bloco premium estão disponíveis num subconjunto de regiões de Azure:

  • (Ásia-Pacífico) Austrália Leste
  • (Ásia-Pacífico) Ásia Oriental
  • Leste do Japão (Ásia-Pacífico)
  • (Ásia-Pacífico) Sudeste Asiático
  • (Europa) França Central
  • (Europa) Norte da Europa
  • (Europa) Europa Ocidental
  • (Europa) Reino Unido Sul
  • (América do Norte) Leste dos EUA
  • (América do Norte) Leste dos EUA 2
  • (América do Norte) West US 2
  • (América do Norte) Centro Sul dos EUA
  • (América do Sul) Brasil Sul

Contas de ações de ficheiro premium

O ZRS é suportado para ações de ficheiros premium (Ficheiros do Azure) através do FileStorage tipo de conta de armazenamento.

ZRS para ações de ficheiros premium está disponível para um subconjunto de regiões de Azure:

  • (Ásia-Pacífico) Austrália Leste
  • Leste do Japão (Ásia-Pacífico)
  • (Ásia-Pacífico) Sudeste Asiático
  • (Ásia-Pacífico) Coreia Central
  • (Europa) França Central
  • (Europa) Norte da Europa
  • (Europa) Europa Ocidental
  • (Europa) Reino Unido Sul
  • (Médio Oriente) Qatar Central
  • (América do Norte) Leste dos EUA
  • (América do Norte) Leste dos EUA 2
  • (América do Norte) West US 2
  • (América do Norte) Centro Sul dos EUA
  • (América do Sul) Brasil Sul

Redundância numa região secundária

Para aplicações que exijam alta durabilidade, pode optar por copiar adicionalmente os dados da sua conta de armazenamento para uma região secundária que fica a centenas de quilómetros da região primária. Se a sua conta de armazenamento for copiada para uma região secundária, então os seus dados são duráveis mesmo no caso de uma paragem regional completa ou de um desastre em que a região primária não é recuperável.

Ao criar uma conta de armazenamento, selecione a região primária para a conta. A região secundária emparelhada é determinada com base na região primária, e não pode ser alterada. Para obter mais informações sobre as regiões apoiadas pelo Azure, consulte as regiões de Azure.

O Azure Storage oferece duas opções para copiar os seus dados para uma região secundária:

  • O armazenamento georredundante (GRS) copia os dados de forma síncrona três vezes numa única localização física na região primária através do LRS. Em seguida, copia os dados de forma assíncrona para uma única localização física na região secundária. Dentro da região secundária, os seus dados são copiados sincronizadamente três vezes utilizando LRS.
  • O armazenamento de zonas geo-redundantes (GZRS) copia os seus dados sincronizadamente em três zonas de disponibilidade de Azure na região primária utilizando zRS. Em seguida, copia os dados de forma assíncrona para uma única localização física na região secundária. Dentro da região secundária, os seus dados são copiados sincronizadamente três vezes utilizando LRS.

Nota

A principal diferença entre GRS e GZRS é a forma como os dados são replicados na região primária. Dentro da região secundária, os dados são sempre replicados sincronizadamente três vezes utilizando LRS. O LRS na região secundária protege os seus dados contra falhas de hardware.

Com GRS ou GZRS, os dados na região secundária não estão disponíveis para ler ou escrever acesso, a menos que haja uma falha na região secundária. Para ler o acesso à região secundária, configuure a sua conta de armazenamento para utilizar o armazenamento geo-redundante de acesso à leitura (RA-GRS) ou o armazenamento de zonas de acesso de leitura redundantes (RA-GZRS). Para mais informações, consulte Ler o acesso aos dados na região secundária.

Se a região primária ficar indisponível, pode optar por falhar na região secundária. Após a conclusão do failover, a região secundária torna-se a região primária, e pode voltar a ler e escrever dados. Para obter mais informações sobre a recuperação de desastres e para aprender a falhar na região secundária, consulte a recuperação de desastres e a conta de armazenamento falhada.

Importante

Uma vez que os dados são replicados para a região secundária de forma assíncrona, uma falha que afeta a região primária pode resultar em perda de dados se a região primária não puder ser recuperada. O intervalo entre os mais recentes escreve para a região primária e a última escrita para a região secundária é conhecido como o objetivo do ponto de recuperação (RPO). O RPO indica o ponto no tempo para que os dados podem ser recuperados. A plataforma Azure Storage normalmente tem um RPO inferior a 15 minutos, embora não exista atualmente nenhum SLA sobre o tempo que leva para replicar dados para a região secundária.

Armazenamento georredundante

O armazenamento georredundante (GRS) copia os dados de forma síncrona três vezes numa única localização física na região primária através do LRS. Em seguida, copia os seus dados assíncronamente para um único local físico numa região secundária que fica a centenas de milhas da região primária. A GRS oferece uma durabilidade para recursos de armazenamento de pelo menos 99.99999999999999999999999999999999 (16 9's) durante um determinado ano.

Uma operação de escrita é inicialmente comprometida para a localização primária e replicada usando LRS. A atualização é então replicada assíncronamente para a região secundária. Quando os dados são escritos para a localização secundária, também é replicado dentro desse local usando LRS.

O diagrama a seguir mostra como os seus dados são replicados com GRS ou RA-GRS:

Diagrama que mostra como os dados são replicados com GRS ou RA-GRS

Armazenamento georredundante com redundância entre zonas

O armazenamento de zonas geo-redundantes (GZRS) combina a elevada disponibilidade proporcionada pela redundância através das zonas de disponibilidade com proteção contra interrupções regionais fornecidas por geo-replicação. Os dados de uma conta de armazenamento GZRS são copiados em três zonas de disponibilidade de Azure na região primária e também são replicados numa região geográfica secundária para proteção contra desastres regionais. A Microsoft recomenda a utilização de GZRS para aplicações que exijam a máxima consistência, durabilidade e disponibilidade, excelente desempenho e resiliência para a recuperação de desastres.

Com uma conta de armazenamento GZRS, pode continuar a ler e escrever dados se uma zona de disponibilidade ficar indisponível ou se não for recuperável. Além disso, os seus dados também são duráveis em caso de uma paralisação regional completa ou de um desastre em que a região primária não é recuperável. O GZRS foi concebido para proporcionar pelo menos 99.999999999999999999999999999999999999 (16 9's) de durabilidade de objetos durante um determinado ano.

O diagrama a seguir mostra como os seus dados são replicados com GZRS ou RA-GZRS:

Diagrama que mostra como os dados são replicados com GZRS ou RA-GZRS

Apenas as contas de armazenamento v2 de uso geral padrão suportam GZRS. O GZRS é suportado por todos os serviços de Armazenamento Azure, incluindo:

  • Armazenamento Azure Blob (bolhas de blocos quentes e frescos, bolhas de página não-disco)
  • Ficheiros do Azure (todos os níveis padrão: transação otimizada, quente e fresca)
  • Armazenamento de Tabelas do Azure
  • Armazenamento de Filas do Azure

O GZRS está disponível para um subconjunto de regiões de Azure:

  • (África) África do Sul Norte
  • (Ásia-Pacífico) Austrália Leste
  • (Ásia-Pacífico) Ásia Oriental
  • Leste do Japão (Ásia-Pacífico)
  • (Ásia-Pacífico) Coreia Central
  • (Ásia-Pacífico) Sudeste Asiático
  • (Ásia-Pacífico) Índia Central
  • (Europa) França Central
  • (Europa) Alemanha Centro Ocidental
  • (Europa) Norte da Europa
  • (Europa) Leste da Noruega
  • (Europa) Suécia Central
  • (Europa) Suíça Norte
  • (Europa) Reino Unido Sul
  • (Europa) Europa Ocidental
  • (América do Norte) Canadá Central
  • (América do Norte) Central EUA
  • (América do Norte) Leste dos EUA
  • (América do Norte) Leste dos EUA 2
  • (América do Norte) Centro Sul dos EUA
  • (América do Norte) West US 2
  • (América do Norte) West US 3
  • (América do Norte) Eua Gov Virginia
  • (América do Sul) Brasil Sul

Ler acesso aos dados na região secundária

O armazenamento geo-redundante (com GRS ou GZRS) replica os seus dados para outra localização física na região secundária para proteger contra interrupções regionais. Com uma conta configurada para GRS ou GZRS, os dados na região secundária não são acessíveis diretamente aos utilizadores ou aplicações, a menos que ocorra uma falha. O processo de failover atualiza a entrada de DNS fornecida pela Azure Storage para que o ponto final secundário se torne o novo ponto final primário para a sua conta de armazenamento. Durante o processo de failover, os seus dados são inacessíveis. Após a conclusão do failover, pode ler e escrever dados para a nova região primária. Para obter mais informações sobre o failover e a recuperação de desastres, consulte como funciona uma falha de conta.

Se as suas aplicações requerem alta disponibilidade, então pode configurar a sua conta de armazenamento para ler o acesso à região secundária. Quando permite o acesso de leitura à região secundária, os seus dados estão sempre disponíveis para serem lidos a partir do secundário, incluindo numa situação em que a região primária fica indisponível. As configurações de armazenamento geo-redundante de acesso à leitura (RA-GRS) ou de armazenamento redundante de zona de acesso à leitura (RA-GZRS) permitem o acesso à região secundária.

Atenção

Como os dados são replicados assíncronamente desde a primária até à região secundária, a região secundária está tipicamente por trás da região primária em termos de operações de escrita. Se um desastre atingisse a região primária, é provável que alguns dados se percam. Para obter mais informações sobre como planear a perda de dados potenciais, consulte Antecipar a perda de dados.

Nota

Ficheiros do Azure não suporta o armazenamento geo-redundante de acesso à leitura (RA-GRS) ou o armazenamento de geo-zonas redundantes de acesso à leitura (RA-GZRS).

Desista as suas aplicações para ler o acesso ao secundário

Se a sua conta de armazenamento estiver configurada para o acesso lido à região secundária, então pode projetar as suas aplicações para mudar sem problemas para os dados de leitura da região secundária se a região primária ficar indisponível por qualquer motivo.

A região secundária está disponível para acesso à leitura depois de ativar RA-GRS ou RA-GZRS, para que possa testar a sua aplicação com antecedência para se certificar de que a mesma será lida corretamente a partir do secundário em caso de interrupção. Para obter mais informações sobre como projetar as suas aplicações para tirar partido da geo-redundância, consulte Use geo-redundância para desenhar aplicações altamente disponíveis.

Quando se lê o acesso ao secundário, a sua aplicação pode ser lida a partir do ponto final secundário, bem como do ponto final primário. O ponto final secundário apêndice o sufixo ( secundário ao nome da conta. Por exemplo, se o seu principal ponto final para o armazenamento blob for myaccount.blob.core.windows.net, então o ponto final secundário é myaccount-secondary.blob.core.windows.net. As chaves de acesso à conta para a sua conta de armazenamento são as mesmas tanto para os pontos finais primários como secundários.

Consulte a propriedade Last Sync Time

Como os dados são replicados para a região secundária de forma assíncrona, a região secundária está muitas vezes por trás da região primária. Se um falhanço acontecer na região primária, é provável que todos os escritos para as primárias ainda não tenham sido replicados para o secundário.

Para determinar quais as operações de escrita que foram replicadas na região secundária, a sua aplicação pode verificar a propriedade Last Sync Time para a sua conta de armazenamento. Todas as operações de escrita escrita escritas para a região primária antes da última sincronização foram replicadas com sucesso para a região secundária, o que significa que estão disponíveis para serem lidas a partir do secundário. Quaisquer operações de escrita escrita escrita para a região primária após a última hora de sincronização podem ou não ter sido replicadas na região secundária, o que significa que podem não estar disponíveis para operações de leitura.

Pode consultar o valor da propriedade Last Sync Time utilizando Azure PowerShell, Azure CLI ou uma das bibliotecas do cliente do Azure Storage. A propriedade Last Sync Time é um valor de data/hora GMT. Para mais informações, consulte a propriedade Da Última Hora de Sincronização para obter uma conta de armazenamento.

Resumo das opções de despedimento

As tabelas nas secções seguintes resumem as opções de despedimento disponíveis para o Azure Storage.

Parâmetros de durabilidade e disponibilidade

A tabela a seguir descreve parâmetros-chave para cada opção de redundância:

Parâmetro LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Durabilidade por cento de objetos ao longo de um determinado ano pelo menos 99.999999999999999% (11 9's) pelo menos 99.9999999999999999999 % (12 9's) pelo menos 99.99999999999999999999999999999999 (16 9's) pelo menos 99.99999999999999999999999999999999 (16 9's)
Disponibilidade para pedidos de leitura Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) para GRS

Pelo menos 99,99% (99,9% para os níveis de acesso Cool ou Archive) para RA-GRS
Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) para GZRS

Pelo menos 99,99% (99,9% para os níveis de acesso Cool ou Archive) para RA-GZRS
Disponibilidade para pedidos de escrita Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive) Pelo menos 99,9% (99% para os níveis de acesso Cool ou Archive)
Número de cópias de dados mantidos em nós separados Três cópias dentro de uma única região Três cópias em zonas de disponibilidade separadas dentro de uma única região Seis exemplares no total, incluindo três na região primária e três na região secundária Seis exemplares no total, incluindo três em zonas de disponibilidade separadas na região primária e três exemplares redundantes locais na região secundária

Para mais informações, consulte o SLA para contas de armazenamento.

Durabilidade e disponibilidade por cenário de paralisação

A tabela a seguir indica se os seus dados são duráveis e disponíveis num determinado cenário, dependendo do tipo de redundância em vigor para a sua conta de armazenamento:

Cenário de paralisação LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Um nó dentro de um centro de dados torna-se indisponível Yes Yes Yes Yes
Um centro de dados inteiro (zonal ou não-zonal) torna-se indisponível No Yes Sim1 Yes
Uma paralisação em toda a região ocorre na região primária No No Sim1 Sim1
Leia o acesso à região secundária disponível se a região primária ficar indisponível No No Sim (com RA-GRS) Sim (com RA-GZRS)

1 A falha na conta é necessária para restaurar a disponibilidade de escrita se a região primária ficar indisponível. Para obter mais informações, consulte a recuperação de desastres e a falha da conta de armazenamento.

Serviços de armazenamento Azure apoiados

A tabela que se segue mostra quais as opções de redundância suportadas por cada serviço de Armazenamento Azure.

LRS ZRS GRS RA-GRS GZRS RA-GZRS
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage
Ficheiros do Azure 1,2
Discos geridos Azure
Blobs de páginas
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage
Ficheiros do Azure 1,2
Discos geridos Azure3
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage
Ficheiros do Azure 1
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage
Ficheiros do Azure 1
Armazenamento de bolhas (incluindo Data Lake Storage)
Armazenamento de filas
Table Storage

1 As ações de ficheiros standard são suportadas em LRS e ZRS. As ações de ficheiros standard são suportadas em GRS e GZRS desde que sejam inferiores ou iguais a 5 TiB de tamanho.
2 As ações de ficheiro premium são suportadas em LRS e ZRS.
3 Os discos geridos ZRS têm determinadas limitações. Consulte a secção limitações das opções de redundância para artigo de discos geridos para obter mais detalhes.

Tipos de conta de armazenamento suportados

O quadro seguinte mostra quais as opções de despedimento suportadas por cada tipo de conta de armazenamento. Para obter informações sobre tipos de conta de armazenamento, consulte a visão geral da conta de Armazenamento.

Tipos de conta de armazenamento LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Recomendado V2StorageV2 ()1

Bolhas de bloco premium (BlockBlobStorage)1

Ações de ficheiros premium (FileStorage)

Bolhas de página premium (StorageV2)
V2StorageV2 ()1

Bolhas de bloco premium (BlockBlobStorage)1

Ações de ficheiros premium (FileStorage)
V2StorageV2 ()1 V2StorageV2 ()1
Legado V1 de finalidade geral padrão (Storage)

Bolha legado (BlobStorage)
N/D V1 de finalidade geral padrão (Storage)

Bolha legado (BlobStorage)
N/D

1 As contas deste tipo com um espaço hierárquico habilitado também suportam a opção de redundância especificada.

Todos os dados relativos a todas as contas de armazenamento são copiados do primário para o secundário de acordo com a opção de despedimento para a conta de armazenamento. Objetos que incluem bolhas de blocos, bolhas de apêndice, bolhas de página, filas, tabelas e ficheiros são copiados.

Os dados em todos os níveis, incluindo o nível archive, são sempre copiados do primário para o secundário durante a geo-replicação. O nível de arquivo para o Armazenamento Blob é atualmente suportado para contas LRS, GRS e RA-GRS, mas não para contas ZRS, GZRS ou RA-GZRS. Para obter mais informações sobre os níveis de blob, consulte os níveis de acesso Hot, Cool e Archive para obter dados blob.

Os discos não geridos não suportam ZRS ou GZRS.

Para obter informações sobre preços para cada opção de despedimento, consulte os preços de armazenamento Azure.

Nota

A Azure Premium Disk Storage suporta atualmente apenas armazenamento localmente redundante (LRS). As contas de armazenamento de blob de bloco suportam armazenamento localmente redundante (LRS) e armazenamento redundante de zona (ZRS) em certas regiões.

Suporte para falha de conta gerida pelo cliente

Todas as ofertas geo-redundantes suportam o fracasso gerido pela Microsoft em caso de desastre na região primária. Além disso, alguns tipos de conta suportam o failover de conta gerido pelo cliente, como mostrado na tabela seguinte. Os tipos de conta suportados devem utilizar as implementações Resource Manager do Azure. Para obter mais informações sobre a recuperação de desastres e o failover gerido pelo cliente, consulte a recuperação de desastres e a falha da conta de armazenamento.

Tipo de failover GRS/RA-GRS GZRS/RA-GZRS
Falha gerida pelo cliente Contas v2
de uso geral v1 contas
Legacy Blob Storage
Contas de armazenamento para fins gerais v2
Falha gerida pela Microsoft Todos os tipos de conta Contas de armazenamento para fins gerais v2

Nota

O failover de conta gerido pelo cliente ainda não é suportado em contas que tenham um espaço hierárquico de nome (Azure Data Lake Storage Gen2). Para saber mais, consulte as funcionalidades de armazenamento Blob disponíveis em Azure Data Lake Storage Gen2.

Em caso de desastre que afete a região primária, a Microsoft gerirá o failover para contas com um espaço hierárquico. Para obter mais informações, consulte o failover gerido pela Microsoft.

Integridade dos dados

O Azure Storage verifica regularmente a integridade dos dados armazenados através de verificações cíclicas de redundância (CRCs). Se a corrupção de dados for detetada, é reparada com dados redundantes. O Azure Storage também calcula os dados de verificação em todo o tráfego de rede para detetar a corrupção de pacotes de dados ao armazenar ou recuperar dados.

Ver também