Redundância do Armazenamento do Azure
O Armazenamento do Azure armazena sempre várias cópias dos seus dados para que estejam protegidos contra eventos planeados e não planeados, incluindo falhas transitórias de hardware, falhas de rede ou energia e desastres naturais maciços. A redundância garante que a sua conta de armazenamento cumpre os respetivos objetivos de disponibilidade e durabilidade, mesmo perante falhas.
Ao decidir qual a melhor opção de redundância para o seu cenário, considere as desvantagens entre custos mais baixos e maior disponibilidade. Os fatores que ajudam a determinar 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 geograficamente distante da região primária, para proteger contra desastres regionais (georreplicação).
- Se a sua aplicação necessita de acesso de leitura aos dados replicados na região secundária se a região primária ficar indisponível por qualquer motivo (georreplicação com acesso de leitura).
Nota
As funcionalidades e a disponibilidade regional descritas neste artigo também estão disponíveis para contas com um espaço de nomes hierárquico (armazenamento de Blobs do Azure).
Os serviços que compõem o Armazenamento do Azure são geridos através de um recurso comum do Azure chamado conta de armazenamento. A conta de armazenamento representa um conjunto partilhado de armazenamento que pode ser utilizado para implementar recursos de armazenamento, como contentores de blobs (Armazenamento de Blobs), partilhas de ficheiros (Ficheiros do Azure), tabelas (Armazenamento de Tabelas) ou filas (Armazenamento de Filas). Para obter mais informações sobre contas de Armazenamento do Azure, veja Descrição geral da conta de armazenamento.
A definição de redundância de uma conta de armazenamento é partilhada para todos os serviços de armazenamento expostos por essa conta. Todos os recursos de armazenamento implementados na mesma conta de armazenamento têm a mesma definição de redundância. Poderá querer isolar diferentes tipos de recursos em contas de armazenamento separadas se tiverem requisitos de redundância diferentes.
Redundância na região primária
Os dados numa conta de Armazenamento do 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 dados de forma síncrona três vezes numa única localização física na região primária. O LRS é a opção de replicação menos dispendiosa, mas não é recomendada para aplicações que exijam elevada disponibilidade ou durabilidade.
- O armazenamento com redundância entre zonas (ZRS) copia os dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Para aplicações que requerem elevada disponibilidade, a Microsoft recomenda a utilização do 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 do 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 num único datacenter na região primária. O LRS fornece, pelo menos, 99,9999999999% (11 noves) durabilidade de objetos durante um determinado ano.
O LRS é a opção de redundância de custos mais baixos e oferece a menor durabilidade em comparação com outras opções. O LRS protege os seus dados contra falhas de rack de servidor e unidade. No entanto, se ocorrer um desastre, como incêndio ou inundação no datacenter, todas as réplicas de uma conta de armazenamento com LRS poderão ser perdidas ou irrecuperáveis. Para mitigar este risco, a Microsoft recomenda a utilização de armazenamento com redundância entre zonas (ZRS), armazenamento georredundante (GRS) ou armazenamento com redundância entre zonas geográficas (GZRS).
Um pedido de escrita para uma conta de armazenamento que esteja a utilizar o LRS ocorre de forma síncrona. A operação de escrita só é devolvida com êxito depois de os dados terem sido escritos nas três réplicas.
O diagrama seguinte mostra como os seus dados são replicados num único datacenter com LRS:
O LRS é uma boa opção para os seguintes cenários:
- Se a sua aplicação armazenar dados que podem ser facilmente reconstruídos se ocorrer perda de dados, pode optar pelo LRS.
- Se a sua aplicação estiver restrita à replicação de dados apenas dentro de um país ou região devido aos requisitos de governação de dados, pode optar pelo LRS. Em alguns casos, as regiões emparelhadas nas quais os dados são georreplicados podem estar noutro país ou região. Para obter mais informações sobre regiões emparelhadas, veja Regiões do Azure.
- Se o seu cenário estiver a utilizar discos não geridos do Azure, poderá optar pelo LRS. Embora seja possível criar uma conta de armazenamento para discos não geridos do Azure que utilizem GRS, não é recomendado devido a potenciais problemas de consistência na georreplicação assíncrona.
Armazenamento com redundância entre zonas
O armazenamento com redundância entre zonas (ZRS) replica a sua conta de armazenamento de forma síncrona em três zonas de disponibilidade do Azure na região primária. Cada zona de disponibilidade é uma localização física separada com energia, refrigeração e rede independentes, O ZRS oferece durabilidade para recursos de armazenamento de, pelo menos, 99,999999999999% (12 9) durante um determinado ano.
Com o ZRS, os seus dados continuam acessíveis para operações de leitura e escrita, mesmo que uma zona fique indisponível. Se uma zona ficar indisponível, o Azure realiza atualizações de rede, como a repontação de DNS. Estas atualizações podem afetar a sua aplicação se aceder aos dados antes de as atualizações serem concluídas. Ao conceber aplicações para ZRS, siga as práticas de processamento de falhas transitórias, incluindo a implementação de políticas de repetição com trás exponencial.
Um pedido de escrita para uma conta de armazenamento que esteja a utilizar o ZRS ocorre de forma síncrona. A operação de escrita só é devolvida com êxito depois de os dados terem sido escritos em todas as réplicas nas três zonas de disponibilidade.
A Microsoft recomenda a utilização do ZRS na região primária para cenários que exigem elevada disponibilidade. O ZRS também é recomendado para restringir a replicação de dados a um determinado país ou região para cumprir os requisitos de governação de dados.
A Microsoft recomenda a utilização do ZRS para cargas de trabalho Ficheiros do Azure. Se uma zona ficar indisponível, não é necessária a montagem de partilhas de ficheiros do Azure dos clientes ligados.
O diagrama seguinte mostra como os seus dados são replicados em zonas de disponibilidade na região primária com o ZRS:
O ZRS proporciona um excelente desempenho, baixa latência e resiliência para os seus dados se ficarem temporariamente indisponíveis. No entanto, o ZRS por si só pode não proteger os seus dados contra um desastre regional em que várias zonas são permanentemente afetadas. Para proteção contra desastres regionais, a Microsoft recomenda a utilização do armazenamento com redundância entre zonas geográficas (GZRS), que utiliza o ZRS na região primária e também replica georreplica os seus dados para uma região secundária.
A camada Arquivo do Armazenamento de Blobs não é atualmente suportada para contas ZRS, GZRS ou RA-GZRS. Os discos não geridos não suportam ZRS ou GZRS.
Para obter mais informações sobre as regiões que suportam o ZRS, veja Regiões do Azure com zonas de disponibilidade.
Contas de armazenamento Standard
O ZRS é suportado para todos os serviços de Armazenamento do Azure através de contas de armazenamento v2 para fins gerais padrão, incluindo:
- Armazenamento de Blobs do Azure (blobs de blocos frequentes e esporádicos e blobs de acréscimo, blobs de páginas que não são de disco)
- Ficheiros do Azure (todos os escalões padrão: otimizado para transações, frequente e esporádico)
- Armazenamento de Tabelas do Azure
- Armazenamento de Filas do Azure
O ZRS para contas de armazenamento v2 para fins gerais padrão está disponível para um subconjunto de regiões do Azure:
- (África) Norte da África do Sul
- (Ásia-Pacífico) Leste da Austrália
- (Ásia-Pacífico) Índia Central
- (Ásia-Pacífico) Ásia Oriental
- Leste do Japão (Ásia-Pacífico)
- (Ásia-Pacífico) Coreia do Sul Central
- (Ásia-Pacífico) Sudeste Asiático
- (Europa) França Central
- (Europa) Alemanha Centro-Oeste
- (Europa) Europa do Norte
- (Europa) Leste da Noruega
- (Europa) Suécia Central
- (Europa) Norte da Suíça
- (Europa) Sul do Reino Unido
- (Europa) Europa Ocidental
- (Médio Oriente) Catar Central
- (Médio Oriente) Norte dos Emirados Árabes Unidos
- (América do Norte) Canadá Central
- (América do Norte) E.U.A. Central
- (América do Norte) E.U.A. Leste
- (América do Norte) E.U.A. Leste 2
- (América do Norte) E.U.A. Centro-Sul
- (América do Norte) US Gov Virginia
- (América do Norte) E.U.A. Oeste 2
- (América do Norte) E.U.A. Oeste 3
- (América do Sul) Sul do Brasil
Contas de blob de blocos Premium
O ZRS é suportado para contas de blobs de blocos premium. Para obter mais informações sobre blobs de blocos premium, veja Contas de armazenamento de blobs de blocos Premium.
Os blobs de blocos Premium estão disponíveis num subconjunto de regiões do Azure:
- (Ásia-Pacífico) Leste da Austrália
- (Ásia-Pacífico) Ásia Oriental
- Leste do Japão (Ásia-Pacífico)
- (Ásia-Pacífico) Sudeste Asiático
- (Europa) França Central
- (Europa) Europa do Norte
- (Europa) Europa Ocidental
- (Europa) Sul do Reino Unido
- (América do Norte) E.U.A. Leste
- (América do Norte) E.U.A. Leste 2
- (América do Norte) E.U.A. Oeste 2
- (América do Norte) E.U.A. Centro-Sul
- (América do Sul) Sul do Brasil
Contas de partilha de ficheiros Premium
O ZRS é suportado para partilhas de ficheiros premium (Ficheiros do Azure) através do FileStorage tipo de conta de armazenamento.
O ZRS para partilhas de ficheiros premium está disponível para um subconjunto de regiões do Azure:
- (Ásia-Pacífico) Leste da Austrália
- Leste do Japão (Ásia-Pacífico)
- (Ásia-Pacífico) Sudeste Asiático
- (Ásia-Pacífico) Coreia Central
- (Europa) França Central
- (Europa) Europa do Norte
- (Europa) Europa Ocidental
- (Europa) Sul do Reino Unido
- (Médio Oriente) Qatar Central
- (América do Norte) E.U.A. Leste
- (América do Norte) E.U.A. Leste 2
- (América do Norte) E.U.A. Oeste 2
- (América do Norte) E.U.A. Centro-Sul
- (América do Sul) Sul do Brasil
Redundância numa região secundária
Para aplicações que requerem elevada durabilidade, pode optar por copiar adicionalmente os dados na sua conta de armazenamento para uma região secundária que esteja a centenas de quilómetros de distância da região primária. Se a sua conta de armazenamento for copiada para uma região secundária, os seus dados serão duráveis mesmo em caso de uma falha regional completa ou de um desastre em que a região primária não seja recuperável.
Quando cria uma conta de armazenamento, seleciona a região primária da 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 suportadas pelo Azure, veja Regiões do Azure.
O Armazenamento do Azure 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. Na região secundária, os seus dados são copiados de forma síncrona três vezes com LRS.
- O armazenamento com redundância entre zonas geográficas (GZRS) copia os dados de forma síncrona em três zonas de disponibilidade do Azure na região primária através do ZRS. Em seguida, copia os dados de forma assíncrona para uma única localização física na região secundária. Na região secundária, os seus dados são copiados de forma síncrona três vezes com LRS.
Nota
A principal diferença entre GRS e GZRS é a forma como os dados são replicados na região primária. Na região secundária, os dados são sempre replicados de forma síncrona três vezes com 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 acesso de leitura ou escrita, a menos que exista uma ativação pós-falha para a região primária. Para acesso de leitura à região secundária, configure a sua conta de armazenamento para utilizar o armazenamento georredundante com acesso de leitura (RA-GRS) ou o armazenamento georredundante com acesso de leitura (RA-GZRS). Para obter mais informações, veja Acesso de leitura aos dados na região secundária.
Se a região primária ficar indisponível, pode optar por efetuar a ativação pós-falha para a região secundária. Após a conclusão da ativação pós-falha, a região secundária torna-se a região primária e pode ler e escrever dados novamente. Para obter mais informações sobre a recuperação após desastre e para saber como efetuar a ativação pós-falha para a região secundária, veja Ativação pós-falha da conta de armazenamento e recuperação após desastre.
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 na perda de dados se não for possível recuperar a região primária. O intervalo entre as escritas mais recentes na região primária e a última escrita na região secundária é conhecido como o objetivo do ponto de recuperação (RPO). O RPO indica o ponto anterior no tempo para o qual os dados podem ser recuperados. Normalmente, a plataforma de Armazenamento do Azure tem um RPO inferior a 15 minutos, embora atualmente não exista nenhum SLA sobre quanto tempo demora a 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 de forma assíncrona para uma única localização física numa região secundária a centenas de quilómetros de distância da região primária. O GRS oferece durabilidade para recursos de armazenamento de, pelo menos, 99,9999999999999999% (16 9) durante um determinado ano.
Uma operação de escrita é consolidada pela primeira vez na localização primária e replicada com LRS. Em seguida, a atualização é replicada de forma assíncrona para a região secundária. Quando os dados são escritos na localização secundária, também são replicados nessa localização com LRS.
O diagrama seguinte mostra como os seus dados são replicados com GRS ou RA-GRS:
Armazenamento georredundante com redundância entre zonas
O armazenamento com redundância entre zonas geográficas (GZRS) combina a elevada disponibilidade fornecida pela redundância entre zonas de disponibilidade com proteção contra falhas regionais fornecidas pela georreplicação. Os dados numa conta de armazenamento GZRS são copiados em três zonas de disponibilidade do Azure na região primária e também são replicados para uma região geográfica secundária para proteção contra desastres regionais. A Microsoft recomenda a utilização do GZRS para aplicações que exijam a consistência, durabilidade e disponibilidade máximas, um excelente desempenho e resiliência para a recuperação após desastre.
Com uma conta de armazenamento GZRS, pode continuar a ler e escrever dados se uma zona de disponibilidade ficar indisponível ou não for detetável. Além disso, os seus dados também são duráveis em caso de indisponibilidade regional completa ou um desastre em que a região primária não é recuperável. O GZRS foi concebido para fornecer, pelo menos, 99,99999999999999999% (16 9's) durabilidade de objetos durante um determinado ano.
O diagrama seguinte mostra como os seus dados são replicados com GZRS ou RA-GZRS:
Apenas as contas de armazenamento v2 para fins gerais padrão suportam GZRS. O GZRS é suportado por todos os serviços de Armazenamento do Azure, incluindo:
- Armazenamento de Blobs do Azure (blobs de blocos frequentes e esporádicos, blobs de página não disco)
- Ficheiros do Azure (todos os escalões padrão: otimizado para transações, frequente e esporádico)
- Armazenamento de Tabelas do Azure
- Armazenamento de Filas do Azure
O GZRS está disponível para um subconjunto de regiões do Azure:
- (África) Norte da África do Sul
- (Ásia-Pacífico) Leste da Austrália
- (Á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-Oeste
- (Europa) Europa do Norte
- (Europa) Leste da Noruega
- (Europa) Suécia Central
- (Europa) Norte da Suíça
- (Europa) Sul do Reino Unido
- (Europa) Europa Ocidental
- (América do Norte) Canadá Central
- (América do Norte) E.U.A. Central
- (América do Norte) E.U.A. Leste
- (América do Norte) E.U.A. Leste 2
- (América do Norte) E.U.A. Centro-Sul
- (América do Norte) E.U.A. Oeste 2
- (América do Norte) E.U.A. Oeste 3
- (América do Norte) US Gov Virginia
- (América do Sul) Sul do Brasil
Acesso de leitura aos dados na região secundária
O armazenamento georredundante (com GRS ou GZRS) replica os seus dados para outra localização física na região secundária para proteger contra falhas regionais. Com uma conta configurada para GRS ou GZRS, os dados na região secundária não estão diretamente acessíveis para utilizadores ou aplicações, a menos que ocorra uma ativação pós-falha. O processo de ativação pós-falha atualiza a entrada DNS fornecida pelo Armazenamento do Microsoft Azure para que o ponto final secundário se torne o novo ponto final primário da sua conta de armazenamento. Durante o processo de ativação pós-falha, os dados estão inacessíveis. Depois de concluída a ativação pós-falha, pode ler e escrever dados na nova região primária. Para obter mais informações sobre a ativação pós-falha e a recuperação após desastre, veja Como funciona a ativação pós-falha de uma conta.
Se as aplicações exigirem elevada disponibilidade, pode configurar a sua conta de armazenamento para acesso de leitura à região secundária. Quando ativa o acesso de leitura para a região secundária, os dados ficam sempre disponíveis para serem lidos a partir da secundária, incluindo numa situação em que a região primária fica indisponível. As configurações de armazenamento georredundante com acesso de leitura (RA-GRS) ou armazenamento georredundante com acesso de leitura (RA-GZRS) permitem o acesso de leitura à região secundária.
Atenção
Uma vez que os dados são replicados de forma assíncrona da região primária para a secundária, a região secundária está normalmente por trás da região primária em termos de operações de escrita. Se um desastre atingir a região primária, é provável que alguns dados se percam. Para obter mais informações sobre como planear potenciais perdas de dados, veja Antecipar a perda de dados.
Nota
Ficheiros do Azure não suporta armazenamento georredundante com acesso de leitura (RA-GRS) ou armazenamento georredundante com acesso de leitura (RA-GZRS).
Conceber as suas aplicações para acesso de leitura à secundária
Se a sua conta de armazenamento estiver configurada para acesso de leitura à região secundária, pode criar as suas aplicações para mudar de forma totalmente integrada para a leitura de dados 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 de leitura depois de ativar o RA-GRS ou o RA-GZRS, para que possa testar a sua aplicação com antecedência para se certificar de que lê corretamente a partir da secundária em caso de indisponibilidade. Para obter mais informações sobre como conceber as suas aplicações para tirar partido da redundância geográfica, veja Utilizar a redundância geográfica para conceber aplicações de elevada disponibilidade.
Quando o acesso de leitura à secundária está ativado, a aplicação pode ser lida a partir do ponto final secundário, bem como do ponto final primário. O ponto final secundário acrescenta o sufixo –secundário ao nome da conta. Por exemplo, se o ponto final principal do Armazenamento de blobs for myaccount.blob.core.windows.net, o ponto final secundário é myaccount-secondary.blob.core.windows.net. As chaves de acesso da conta para a sua conta de armazenamento são as mesmas para os pontos finais primário e secundário.
Consulte a propriedade Last Sync Time
Uma vez que os dados são replicados para a região secundária de forma assíncrona, a região secundária está frequentemente atrás da região primária. Se ocorrer uma falha na região primária, é provável que todas as escritas na primária ainda não tenham sido replicadas para a secundária.
Para determinar que operações de escrita foram replicadas para a região secundária, a aplicação pode verificar a propriedade Hora da Última Sincronização da conta de armazenamento. Todas as operações de escrita escritas na região primária antes da hora da última sincronização foram replicadas com êxito para a região secundária, o que significa que estão disponíveis para serem lidas a partir da região secundária. Todas as operações de escrita escritas na região primária após a hora da última sincronização podem ou não ter sido replicadas para a 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 Hora da Última Sincronização com Azure PowerShell, a CLI do Azure ou uma das bibliotecas de cliente do Armazenamento do Microsoft Azure. A propriedade Hora da Última Sincronização é um valor de data/hora GMT. Para obter mais informações, veja Verificar a propriedade Hora da Última Sincronização de uma conta de armazenamento.
Resumo das opções de redundância
As tabelas nas secções seguintes resumem as opções de redundância disponíveis para o Armazenamento do Azure.
Parâmetros de durabilidade e disponibilidade
A tabela seguinte descreve os parâmetros-chave para cada opção de redundância:
| Parâmetro | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GzRS |
|---|---|---|---|---|
| Percentagem de durabilidade de objetos ao longo de um determinado ano | pelo menos 99,99999999999% (11 9) | pelo menos 99,999999999999% (12 9) | pelo menos 99,999999999999999% (16 9) | pelo menos 99,999999999999999% (16 9) |
| Disponibilidade para pedidos de leitura | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para camadas de acesso Esporádico ou Arquivo) para GRS Pelo menos 99,99% (99,9% para camadas de acesso Esporádico ou Arquivo) para RA-GRS |
Pelo menos 99,9% (99% para camadas de acesso Esporádico ou Arquivo) para GZRS Pelo menos 99,99% (99,9% para camadas de acesso Esporádico ou Arquivo) para RA-GZRS |
| Disponibilidade para pedidos de escrita | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para as camadas de acesso Esporádico ou Arquivo) |
| Número de cópias de dados mantidos em nós separados | Três cópias numa única região | Três cópias em zonas de disponibilidade separadas numa única região | Total de seis cópias, incluindo três na região primária e três na região secundária | Total de seis cópias, incluindo três em zonas de disponibilidade separadas na região primária e três cópias localmente redundantes na região secundária |
Para obter mais informações, veja o SLA para Contas de Armazenamento.
Durabilidade e disponibilidade por cenário de indisponibilidade
A tabela seguinte indica se os dados são duráveis e estão disponíveis num determinado cenário, consoante o tipo de redundância em vigor para a sua conta de armazenamento:
| Cenário de indisponibilidade | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GzRS |
|---|---|---|---|---|
| Um nó num datacenter fica indisponível | Yes | Yes | Yes | Yes |
| Um datacenter inteiro (zonal ou não zonal) fica indisponível | No | Yes | Sim1 | Yes |
| Ocorre uma indisponibilidade em toda a região na região primária | No | No | Sim1 | Sim1 |
| O acesso de leitura à região secundária está disponível se a região primária ficar indisponível | No | No | Sim (com RA-GRS) | Sim (com RA-GZRS) |
1 A ativação pós-falha da conta é necessária para restaurar a disponibilidade de escrita se a região primária ficar indisponível. Para obter mais informações, veja Recuperação após desastre e ativação pós-falha da conta de armazenamento.
Serviços de Armazenamento do Azure suportados
A tabela seguinte mostra que opções de redundância são suportadas por cada serviço de Armazenamento do Azure.
| LRS | ZRS | GRS | RA-GRS | GZRS | RA-GZRS |
|---|---|---|---|---|---|
| Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage Ficheiros do Azure 1,2 Discos geridos do Azure Blobs de páginas |
Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage Ficheiros do Azure 1,2 Discos geridos do Azure3 |
Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage Ficheiros do Azure 1 |
Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage |
Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage Ficheiros do Azure 1 |
Armazenamento de blobs (incluindo Data Lake Storage) Armazenamento de filas Table Storage |
1 As partilhas de ficheiros Standard são suportadas no LRS e no ZRS. As partilhas de ficheiros padrão são suportadas em GRS e GZRS, desde que sejam inferiores ou iguais a 5 TiB de tamanho.
2 As partilhas de ficheiros Premium são suportadas no LRS e no ZRS.
3 Os discos geridos ZRS têm determinadas limitações. Veja a secção Limitações do artigo Limitações das opções de redundância para discos geridos para obter detalhes.
Tipos de conta de armazenamento suportados
A tabela seguinte mostra que opções de redundância são suportadas para cada tipo de conta de armazenamento. Para obter informações sobre tipos de conta de armazenamento, veja Descrição geral da conta de armazenamento.
| Tipos de conta de armazenamento | LRS | ZRS | GRS/RA-GRS | GZRS/RA-GzRS |
|---|---|---|---|---|
| Recomendado | Standard para fins gerais v2 (StorageV2)1Blobs de blocos Premium ( BlockBlobStorage)1Partilhas de ficheiros Premium ( FileStorage)Blobs de página premium ( StorageV2) |
Standard para fins gerais v2 (StorageV2)1Blobs de blocos Premium ( BlockBlobStorage)1Partilhas de ficheiros Premium ( FileStorage) |
Standard para fins gerais v2 (StorageV2)1 |
Standard para fins gerais v2 (StorageV2)1 |
| Legado | Standard para fins gerais v1 (Storage)Blob legado ( BlobStorage) |
N/D | Standard para fins gerais v1 (Storage)Blob legado ( BlobStorage) |
N/D |
1 As contas deste tipo com um espaço de nomes hierárquico ativado também suportam a opção de redundância especificada.
Todos os dados de todas as contas de armazenamento são copiados do principal para o secundário de acordo com a opção de redundância da conta de armazenamento. São copiados objetos, incluindo blobs de blocos, blobs de acréscimo, blobs de páginas, filas, tabelas e ficheiros.
Os dados em todas as camadas, incluindo a camada Arquivo, são sempre copiados da primária para a secundária durante a georreplicação. A camada Arquivo do Armazenamento de Blobs é atualmente suportada para contas LRS, GRS e RA-GRS, mas não para contas ZRS, GZRS ou RA-GZRS. Para obter mais informações sobre as camadas de blobs, veja Camadas de acesso Frequente, Esporádico e Arquivo para dados de blobs.
Os discos não geridos não suportam ZRS ou GZRS.
Para obter informações sobre preços para cada opção de redundância, veja Preços do Armazenamento do Azure.
Nota
Atualmente, o Armazenamento de Discos Premium do Azure suporta apenas armazenamento localmente redundante (LRS). As contas de armazenamento de blobs de blocos suportam armazenamento localmente redundante (LRS) e armazenamento com redundância entre zonas (ZRS) em determinadas regiões.
Suporte para ativação pós-falha da conta gerida pelo cliente
Todas as ofertas georredundantes suportam a ativação pós-falha gerida pela Microsoft em caso de desastre na região primária. Além disso, alguns tipos de conta suportam a ativação pós-falha da conta gerida pelo cliente, conforme mostrado na tabela seguinte. Os tipos de conta suportados têm de utilizar implementações do Azure Resource Manager. Para obter mais informações sobre a recuperação após desastre e a ativação pós-falha gerida pelo cliente, veja Ativação pós-falha da conta de armazenamento e recuperação após desastre.
| Tipo de ativação pós-falha | GRS/RA-GRS | GZRS/RA-GzRS |
|---|---|---|
| Ativação pós-falha gerida pelo cliente | Contas de fins gerais v2 Contas de Fins gerais v1 Contas de Armazenamento de Blobs Legados | Contas de armazenamento para fins gerais v2 |
| Ativação pós-falha gerida pela Microsoft | Todos os tipos de conta | Contas de armazenamento para fins gerais v2 |
Nota
A ativação pós-falha da conta gerida pelo cliente ainda não é suportada em contas com um espaço de nomes hierárquico (Azure Data Lake Storage Gen2). Para saber mais, veja Funcionalidades do armazenamento de blobs disponíveis no Azure Data Lake Storage Gen2.
Em caso de desastre que afete a região primária, a Microsoft irá gerir a ativação pós-falha para contas com um espaço de nomes hierárquico. Para obter mais informações, veja Ativação pós-falha gerida pela Microsoft.
Integridade dos dados
O Armazenamento do Azure verifica regularmente a integridade dos dados armazenados através de verificações de redundância cíclicas (CRCs). Se forem detetados danos em dados, estes são reparados através de dados redundantes. O Armazenamento do Azure também calcula somas de verificação em todo o tráfego de rede para detetar danos em pacotes de dados ao armazenar ou obter dados.
Ver também
- Alterar a opção de redundância de uma conta de armazenamento
- Georreplicação (GRS/GZRS/RA-GRS/RA-GZRS)
- Preços