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 vantagens 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 que tenham 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 seus 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 seus dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Para aplicações que necessitam de 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 no rack do servidor e na 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 num país ou região devido a 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, pode 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 com a consistência sobre a 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,9999999999999% (12 9 s) 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 repointing 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 transitório de falhas, incluindo a implementação de políticas de repetição com um back-off 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. Se uma zona de disponibilidade estiver temporariamente indisponível, a operação será devolvida com êxito após os dados terem sido escritos em todas as zonas disponíveis.
A Microsoft recomenda a utilização do 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 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 qualquer 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 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 de armazenamento com redundância entre zonas geográficas (GZRS), que utiliza ZRS na região primária e também georreplica os seus dados para uma região secundária.
A camada de 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á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
Para obter uma lista de regiões que suportam armazenamento com redundância entre zonas (ZRS) para contas padrão, veja Regiões do Azure que suportam armazenamento com redundância entre zonas (ZRS) para contas de armazenamento padrão.
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.
Para obter uma lista de regiões que suportam armazenamento com redundância entre zonas (ZRS) para contas de blobs de blocos premium, veja Regiões do Azure que suportam armazenamento com redundância entre zonas (ZRS) para contas de blobs de blocos premium.
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.
Para obter uma lista de regiões que suportam armazenamento com redundância entre zonas (ZRS) para contas de partilha de ficheiros premium, veja Ficheiros do Azure armazenamento com redundância entre zonas para partilhas de ficheiros premium.
Managed disks
O ZRS é suportado para discos geridos com as seguintes limitações.
Para obter uma lista de regiões que suportam armazenamento com redundância entre zonas (ZRS) para discos geridos, veja disponibilidade regional.
Redundância numa região secundária
Para aplicações que exijam 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 seus 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
Para obter uma lista de regiões que suportam armazenamento com redundância entre zonas geográficas (GZRS), veja Regiões do Azure que suportam armazenamento com redundância entre zonas geográficas (GZRS).
Ler o acesso 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 são diretamente acessíveis a 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 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 seus dados estão inacessíveis. Após a conclusão da 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 uma ativação pós-falha de conta.
Se as aplicações precisarem de elevada disponibilidade, pode configurar a sua conta de armazenamento para acesso de leitura à região secundária. Quando ativa 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 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.
Nota
Ficheiros do Azure não suporta armazenamento georredundante com acesso de leitura (RA-GRS) nem 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 conceber as suas aplicações para mudar de forma totalmente integrada para ler 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 esta será lida 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 ao secundário está ativado, 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 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ários e secundários.
Planear a perda de dados
Uma vez que os dados são replicados de forma assíncrona da região primária para a região 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.
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 dos objetos ao longo de um determinado ano | pelo menos 99,9999999999% (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 camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para a camada de acesso esporádico) | 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 a camada de acesso esporádico) para GZRS Pelo menos 99,99% (99,9% para a camada de acesso esporádico) para RA-GZRS |
| Disponibilidade para pedidos de escrita | Pelo menos 99,9% (99% para camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para a camada de acesso esporádico) | Pelo menos 99,9% (99% para camadas de acesso Esporádico ou Arquivo) | Pelo menos 99,9% (99% para a camada de acesso esporádico) |
| 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 seus dados são duráveis e estão disponíveis num determinado cenário, consoante o tipo de redundância que está 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.
| Serviço | 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 | ✅1,2 | ✅1 | ✅1 | ||
| Discos geridos do Azure | ✅ | ✅3 | ||||
| Azure Elastic SAN | ✅ | ✅ |
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
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:
| 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 |
Importante
Contas de armazenamento clássicas
A ativação pós-falha da conta gerida pelo cliente só é suportada para contas de armazenamento implementadas com o modelo de implementação do Azure Resource Manager (ARM). O modelo de implementação do Azure Service Manager (ASM), também conhecido como clássico, não é suportado. Para tornar as contas de armazenamento clássicas elegíveis para a ativação pós-falha da conta gerida pelo cliente, primeiro têm de ser migradas para o modelo arm. A sua conta de armazenamento tem de estar acessível para efetuar a atualização, pelo que a região primária não pode estar num estado de falha.
Em caso de desastre que afete a região primária, a Microsoft irá gerir a ativação pós-falha para contas de armazenamento clássicas. Para obter mais informações, veja Ativação pós-falha gerida pela Microsoft.
Azure Data Lake Storage Gen2 (Armazenamento do Azure Data Lake Gen2)
A ativação pós-falha da conta gerida pelo cliente para contas com um espaço de nomes hierárquico (Azure Data Lake Storage Gen2) está atualmente em PRÉ-VISUALIZAÇÃO e só é suportada nas seguintes regiões:
- (Ásia-Pacífico) Índia Central
- (Europa) Norte da Suíça
- (Europa) Oeste da Suíça
- (América do Norte) Canadá Central
Para optar ativamente por participar na pré-visualização, veja Configurar funcionalidades de pré-visualização na subscrição do Azure e especifique AllowHNSAccountFailover como o nome da funcionalidade.
Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.
Para obter mais informações sobre a recuperação após desastre e a ativação pós-falha gerida pelo cliente, veja Recuperação após desastre e ativação pós-falha da conta de armazenamento.
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 com 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