Redundância de dados dos Arquivos do Azure

Os Arquivos do Azure sempre armazenam várias cópias de seus dados para que sejam protegidos contra eventos planejados e não planejados, incluindo falhas transitórias de hardware, quedas de rede ou de energia e desastres naturais. A redundância garante que sua conta de armazenamento atenda às metas de disponibilidade e durabilidade, mesmo em caso de falhas.

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

• Como seus dados são replicados na região primária.
• Se seus dados são replicados para uma segunda região geograficamente distante da região primária, para proteção contra desastres regionais (redundância geográfica).

Os compartilhamentos de arquivos clássicos do Azure criados com o provedor de recursos Microsoft.Storage são gerenciados por meio de um recurso comum do Azure chamado conta de armazenamento. A conta de armazenamento representa um pool compartilhado de armazenamento que pode ser usado para implantar compartilhamentos de arquivos. Para obter mais informações sobre contas de armazenamento, consulte Visão geral da conta de armazenamento.

Ao criar uma conta de armazenamento, você escolhe uma configuração de redundância para a conta de armazenamento compartilhada para todos os serviços de armazenamento expostos por essa conta. Portanto, todos os compartilhamentos de arquivos implantados na mesma conta de armazenamento têm a mesma configuração de redundância. Talvez você queira isolar compartilhamentos de arquivos em contas de armazenamento separadas se elas tiverem requisitos de redundância diferentes.

Aplica-se a

Modelo de gestão	Modelo de faturação	Nível de média	Redundância	SMB	NFS
Microsoft.Armazenamento	Provisionado v2	SSD (de qualidade superior)	Localização (LRS)
Microsoft.Armazenamento	Provisionado v2	SSD (de qualidade superior)	Zona (ZRS)
Microsoft.Armazenamento	Provisionado v2	HDD (padrão)	Localização (LRS)
Microsoft.Armazenamento	Provisionado v2	HDD (padrão)	Zona (ZRS)
Microsoft.Armazenamento	Provisionado v2	HDD (padrão)	Geo (GRS)
Microsoft.Armazenamento	Provisionado v2	HDD (padrão)	GeoZona (GZRS)
Microsoft.Armazenamento	Provisionado v1	SSD (de qualidade superior)	Localização (LRS)
Microsoft.Armazenamento	Provisionado v1	SSD (de qualidade superior)	Zona (ZRS)
Microsoft.Armazenamento	Pagamento conforme o consumo	HDD (padrão)	Localização (LRS)
Microsoft.Armazenamento	Pagamento conforme o consumo	HDD (padrão)	Zona (ZRS)
Microsoft.Armazenamento	Pagamento conforme o consumo	HDD (padrão)	Geo (GRS)
Microsoft.Armazenamento	Pagamento conforme o consumo	HDD (padrão)	GeoZona (GZRS)

Redundância na região primária

Os dados em uma conta de armazenamento do Azure são sempre replicados três vezes na região primária. O Azure Files oferece duas opções de como seus dados são replicados na região primária:

• O LRS (armazenamento com redundância local) replica os dados em suas contas de armazenamento para uma ou mais zonas de disponibilidade localizadas na região principal de sua escolha. O LRS é a opção de replicação menos dispendiosa, mas não é recomendado para aplicações que exigem alta disponibilidade ou durabilidade.
• O ZRS (armazenamento com redundância de zona) copia seus dados de forma síncrona em três zonas de disponibilidade do Azure na região primária. Para aplicativos que exigem alta disponibilidade, recomendamos o uso de armazenamento com redundância de zona geográfica (GZRS), que usa o ZRS na região primária e também replica geograficamente seus dados para uma região secundária.

Armazenamento localmente redundante

O LRS (armazenamento com redundância local) replica os dados em suas contas de armazenamento para uma ou mais zonas de disponibilidade do Azure localizadas na região primária de sua escolha. Embora não haja nenhuma opção para escolher sua zona de disponibilidade preferida, o Azure pode mover ou expandir contas LRS entre zonas para melhorar o balanceamento de carga. O LRS proporciona pelo menos 99,9999999999% (11 nines) de durabilidade dos objetos durante um ano determinado. Visite o artigo O que são zonas de disponibilidade do Azure para saber mais sobre a fiabilidade da zona de disponibilidade.

O LRS é a opção de redundância de menor custo e oferece a menor durabilidade em comparação com outras opções. O LRS protege seus dados contra falhas de rack e drive do servidor. No entanto, se ocorrer um desastre, como incêndio ou inundação, no data center, todas as réplicas de uma conta de armazenamento usando o LRS poderão ser perdidas ou irrecuperáveis. Para reduzir esse risco, recomendamos o uso de ZRS,GRS ou GZRS.

Uma solicitação de gravação para uma conta de armazenamento que está usando o LRS acontece de forma síncrona. A operação de gravação retorna com êxito somente depois que os dados são gravados em todas as três réplicas.

O diagrama a seguir mostra como seus dados são replicados em um único data center com LRS:

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

• Se o seu aplicativo armazena dados que podem ser facilmente reconstruídos se ocorrer perda de dados.
• Se seu aplicativo estiver restrito à replicação de dados somente dentro de um país ou região devido a requisitos de governança de dados. Em alguns casos, as regiões emparelhadas nas quais os dados são replicados geograficamente podem estar em outro país ou região. Para obter mais informações, consulte Pares de região do Azure e regiões não pareadas.

O LRS é suportado em todas as regiões do Azure para partilhas de ficheiros HDD. Para obter uma lista de regiões que suportam LRS para partilhas de ficheiros SSD, consulte Suporte LRS para partilhas de ficheiros SSD.

Armazenamento com redundância entre zonas

O armazenamento com redundância de zona (ZRS) replica os dados em suas contas de armazenamento para três ou mais zonas de disponibilidade do Azure localizadas na região primária de sua escolha. 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,9999999999% (12 9s) durante um determinado ano. Visite o artigo O que são zonas de disponibilidade do Azure para saber mais sobre a fiabilidade da zona de disponibilidade.

Com o ZRS, seus dados ainda estão acessíveis para operações de leitura e gravação, mesmo que uma zona fique indisponível. Se uma zona ficar indisponível, o Azure realizará atualizações de rede, como reapontamento de DNS. Essas atualizações podem afetar seu aplicativo se você acessar os dados antes que as atualizações sejam concluídas. Ao projetar aplicativos para ZRS, siga as práticas para tratamento de falhas transitórias, incluindo a implementação de políticas de repetição com recuo exponencial.

Uma solicitação de gravação para uma conta de armazenamento que está usando o ZRS acontece de forma síncrona. A operação de gravação retorna com êxito somente depois que os dados são gravados em todas as réplicas nas três zonas de disponibilidade.

Uma vantagem de usar o ZRS para cargas de trabalho do Azure Files é que, se uma zona ficar indisponível, nenhuma remontagem de compartilhamentos de arquivos do Azure dos clientes conectados será necessária. Recomendamos o uso do ZRS na região principal para cenários que exigem alta disponibilidade. Também recomendamos o ZRS para restringir a replicação de dados a um determinado país ou região para atender aos requisitos de governança de dados.

Nota

O Azure File Sync é redundante por zona em todas as regiões que dão suporte a zonas de disponibilidade, exceto o Governo dos EUA da Virgínia. Na maioria dos casos, recomendamos que os usuários do Azure File Sync configurem contas de armazenamento para usar ZRS ou GZRS.

O diagrama a seguir mostra como seus dados são replicados nas zonas de disponibilidade na região primária com o ZRS:

O ZRS oferece excelente desempenho, baixa latência e resiliência para seus dados se eles ficarem temporariamente indisponíveis. No entanto, o ZRS por si só pode não proteger seus dados contra um desastre regional em que várias zonas são afetadas permanentemente. Para proteção contra desastres regionais, recomendamos o uso do GZRS.

Suporte ZRS por região

Para entender quais regiões oferecem suporte ao ZRS para compartilhamentos de arquivos padrão, consulte a lista de regiões do Azure e consulte a coluna de suporte da zona de disponibilidade. O ZRS é suportado em contas de armazenamento v2 de uso geral padrão para todos os três níveis padrão: otimizado para transações, quente e frio.

ZRS é suportado para compartilhamentos de arquivos SSD através do FileStorage tipo de conta de armazenamento. Para obter uma lista de regiões que suportam ZRS para contas de compartilhamento de arquivos SSD, consulte Suporte ZRS para compartilhamentos de arquivos SSD.

Redundância numa região secundária

Para aplicativos que exigem alta durabilidade para compartilhamentos de arquivos SMB, você pode escolher o armazenamento com redundância geográfica para copiar os dados em 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 sua conta de armazenamento for copiada para uma região secundária, seus dados serão duráveis mesmo no caso de uma interrupção regional completa ou um desastre em que a região primária não seja recuperável.

Importante

Os Ficheiros do Azure apenas suportam redundância geográfica (GRS ou GZRS) para partilhas de ficheiros HDD. As partilhas de ficheiros SSD têm de utilizar LRS ou ZRS.

Ao criar uma conta de armazenamento, você seleciona a região principal 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 regiões suportadas pelo Azure, consulte a lista de regiões do Azure.

Os Arquivos do Azure oferecem duas opções para copiar seus dados para uma região secundária. Atualmente, as opções de armazenamento com redundância geográfica só estão disponíveis para compartilhamentos de arquivos SMB padrão.

• O armazenamento com redundância geográfica (GRS) copia seus dados de forma síncrona três vezes em uma ou mais zonas de disponibilidade do Azure na região primária usando o 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, seus dados são copiados de forma síncrona três vezes usando o LRS.
• O armazenamento com redundância de zona geográfica (GZRS) copia seus dados de forma síncrona em três zonas de disponibilidade do Azure na região primária usando o 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, seus dados são copiados de forma síncrona três vezes usando o LRS.

A principal diferença entre GRS e GZRS é 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 usando o LRS. O LRS na região secundária protege seus dados contra falhas de hardware.

Armazenamento georredundante

O armazenamento com redundância geográfica (GRS) copia seus dados de forma síncrona três vezes em uma ou mais zonas de disponibilidade do Azure na região primária usando o LRS. Em seguida, ele copia seus dados de forma assíncrona para um único local físico em uma região secundária que está a centenas de quilômetros de distância da região primária. O GRS oferece uma durabilidade de pelo menos 99,999999999999% (16 9's) ao longo de um determinado ano.

Uma operação de escrita é primeiro validada no local principal e replicada usando LRS. A atualização é replicada de forma assíncrona para a região secundária. Quando os dados são gravados no local secundário, eles também são replicados dentro desse local usando o LRS.

O diagrama a seguir mostra como seus dados são replicados com o GRS:

Armazenamento geozonal redundante

O armazenamento com redundância de zona geográfica (GZRS) combina a alta disponibilidade fornecida pela redundância em zonas de disponibilidade com a proteção contra interrupções regionais fornecidas pela replicação geográfica. Os dados em uma 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. Recomendamos o uso do GZRS para aplicativos que exigem consistência, durabilidade e disponibilidade máximas, excelente desempenho e resiliência para recuperação de desastres.

Com uma conta de armazenamento GZRS, você pode continuar a ler e gravar dados se uma zona de disponibilidade ficar indisponível ou for irrecuperável. Além disso, seus dados também são duráveis no caso de uma interrupção regional completa ou um desastre no qual a região principal não é recuperável. GZRS é projetado para fornecer pelo menos 99,99999999999999% (16 9's) de durabilidade durante um determinado ano.

O diagrama a seguir mostra como seus dados são replicados com GZRS:

Para determinar se uma região dá suporte a GZRS, consulte Regiões do Azure que oferecem suporte a GZRS. Para dar suporte ao GZRS, uma região deve oferecer suporte a zonas de disponibilidade e ter uma região emparelhada.

Frequência de snapshot e de sincronização

Para garantir que os compartilhamentos de arquivos redundantes Geo e GeoZone estejam em um estado consistente quando ocorre um failover, um instantâneo do sistema é criado na região primária a cada 15 minutos e replicado para a região secundária. Quando ocorre um failover na região secundária, o estado da partilha é determinado com base no instantâneo do sistema mais recente na região secundária. Devido ao atraso devido à localização geográfica ou outros problemas, o instantâneo do sistema mais recente na região secundária pode ter mais de 15 minutos de atraso.

A propriedade Last Sync Time (LST) na conta de armazenamento indica a última vez que os dados da região primária foram gravados com êxito na região secundária. Para os Arquivos do Azure, o Último Tempo de Sincronização é baseado no instantâneo do sistema mais recente na região secundária. Você pode usar o PowerShell ou a CLI do Azure para verificar a Última Hora de Sincronização de uma conta de armazenamento.

É importante entender o seguinte sobre a propriedade Last Sync Time:

• A propriedade Última Hora de Sincronização na conta de armazenamento é baseada no serviço (Ficheiros, Blobs, Tabelas, Filas) na conta de armazenamento que está mais atrasada.
• A Última Hora de Sincronização não será atualizada se nenhuma alteração tiver sido feita na conta de armazenamento.
• O cálculo do Tempo da Última Sincronização pode atingir o tempo limite se o número de compartilhamentos de arquivos exceder 100 por conta de armazenamento. Recomenda-se menos de 100 compartilhamentos de arquivos por conta de armazenamento.

Considerações sobre failover

Com GRS ou GZRS, os compartilhamentos de arquivos não estarão acessíveis na região secundária, a menos que ocorra um failover. Se a região primária ficar indisponível, você poderá optar por fazer failover para a região secundária. O processo de failover atualiza a entrada DNS fornecida pelos Arquivos do Azure para que o ponto de extremidade secundário se torne o novo ponto de extremidade primário para sua conta de armazenamento. Durante o processo de failover, seus dados ficam inacessíveis. Após a conclusão do failover, poderás ler e gravar dados na nova região primária. Após a conclusão do failover, a região secundária se torna a região primária e você pode ler e gravar dados novamente. Para obter mais informações, consulte Recuperação de desastres e failover do Azure Files.

Importante

Os Azure Files não oferecem suporte ao armazenamento com redundância geográfica com acesso em leitura (RA-GRS) ou ao armazenamento com redundância de zona geográfica com acesso em leitura (RA-GZRS). Se uma conta de armazenamento estiver configurada para usar RA-GRS ou RA-GZRS, os compartilhamentos de arquivos serão configurados e cobrados como GRS ou GZRS.

Os seguintes itens podem afetar sua capacidade de failover para a região secundária:

• O failover da conta de armazenamento será bloqueado se não existir um instantâneo do sistema na região secundária.
• O failover da conta de armazenamento será bloqueado se a conta de armazenamento contiver mais de 100.000 compartilhamentos de arquivos. Para fazer failover da conta de armazenamento, abra uma solicitação de suporte.
• Os identificadores e concessões de arquivos não são retidos no failover, e os clientes devem desmontar e remontar os compartilhamentos de arquivos.
• A cota de compartilhamento de arquivos pode ser alterada após o failover. A cota de compartilhamento de arquivos na região secundária será baseada na cota que foi configurada quando o instantâneo do sistema foi tirado na região primária.
• As operações de cópia em andamento são anuladas quando ocorre um failover. Quando o failover para a região secundária for concluído, tente novamente a operação de cópia.

Para realizar um failover de uma conta de armazenamento, consulte iniciar um failover de conta.

Advertência

Ao usar os Arquivos do Azure com armazenamento com redundância geográfica, as consultas de diretório podem ter latência maior após o failover. Isso pode ocorrer durante a sincronização entre o armazenamento primário e secundário, especialmente para diretórios com muitos arquivos ou compartilhamentos com vários snapshots. Se você tiver vários arquivos no diretório de cache, poderá observar alguma degradação de desempenho até que a sincronização seja concluída. Em alguns casos, o impacto no desempenho pode persistir mesmo após a sincronização.

Redundância geográfica para compartilhamentos de arquivos SSD

Como mencionado anteriormente, as opções de redundância geográfica (GRS e GZRS) não são suportadas para compartilhamentos de arquivos SSD. No entanto, você pode alcançar a redundância geográfica de outras maneiras.

Para cenários de Sincronização de Arquivos do Azure, você pode sincronizar entre seu compartilhamento de arquivos do Azure (seu ponto de extremidade na nuvem), um servidor de arquivos do Windows local e um compartilhamento de arquivos montado em execução em uma máquina virtual em outra região do Azure (seu ponto de extremidade do servidor para fins de recuperação de desastres). Você deve desabilitar a hierarquização na nuvem para garantir que todos os dados estejam presentes localmente e provisionar armazenamento suficiente na VM do Azure para armazenar todo o conjunto de dados. Para garantir que as alterações sejam replicadas rapidamente para a região secundária, os arquivos só devem ser acessados e modificados no ponto de extremidade do servidor, em vez de no Azure.

Você também pode criar seu próprio script para copiar dados para uma conta de armazenamento em uma região secundária usando ferramentas como AzCopy (use a versão 10.4 ou posterior para preservar ACLs e carimbos de data/hora).

Resumo das opções de redundância

As tabelas nas seções a seguir resumem as opções de redundância disponíveis para os Arquivos do Azure.

Parâmetros de durabilidade e disponibilidade

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

Parâmetro	LRS	ZRS	GRS	GZRS
Percentagem de durabilidade ao longo de um ano determinado	pelo menos 99,999999999% (11 9's)	pelo menos 99,9999999999% (12 9's)	pelo menos 99,999999999999% (16 9's)	pelo menos 99,999999999999% (16 9's)
Disponibilidade para pedidos de leitura	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)
Disponibilidade para requisições de escrita	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)	Pelo menos 99,9% (99% para o nível Cool)
Número de cópias dos dados mantidos em nós separados	Três cópias em uma ou mais zonas de disponibilidade dentro de uma região	Três cópias em zonas de disponibilidade separadas dentro de uma única região	Seis exemplares no total, sendo três na região primária e três na secundária	Seis cópias no total, 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, consulte o SLA para contas de armazenamento.

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

A tabela a seguir indica se seus dados são duráveis e estão disponíveis em um determinado cenário, dependendo do tipo de redundância em vigor para sua conta de armazenamento. Os Arquivos do Azure não suportam o acesso de leitura à região secundária caso a região primária fique indisponível, a menos que ocorra um failover.

Cenário de interrupção	LRS	ZRS	GRS	GZRS
Um nó num centro de dados torna-se indisponível	Sim	Sim	Sim	Sim
Um data center inteiro (zonal ou não zonal) fica indisponível	Não	Sim	Sim1	Sim
Uma interrupção em toda a região ocorre na região primária	Não	Não	Sim1	Sim1

¹ O failover de conta é necessário para restaurar a disponibilidade de gravação se a região primária ficar indisponível.

Para obter informações sobre preços para cada opção de redundância, consulte Preços do Azure Files.

Capacidade de suporte da região com base em diferentes modelos de faturamento

Você pode verificar a capacidade de suporte da região para vários modelos de faturamento usando os comandos a seguir.

Portais

Para exibir a capacidade de suporte da região com base em diferentes modelos de cobrança, use o Azure PowerShell ou a CLI do Azure.

PowerShell

# Login to Azure account
Connect-AzAccount

# Track down the subscription ID in GUID format
$subscriptionID = "your-subscription-id-number"

# Get Token
$token = Get-AzAccessToken

# Invoke SRP list SKU API, and get the returned SKU list
$result = Invoke-RestMethod -Method Get -Uri "https://management.azure.com/subscriptions/$($subscriptionID)/providers/Microsoft.Storage/skus?api-version=2024-01-01" -Headers @{"Authorization" = "Bearer $($token.Token)"}

# Filter the SKU list to get the required information, customization required here to get the best result.
$filteredResult = $result | `
    Select-Object -ExpandProperty value | `
    Where-Object {
        $_.resourceType -eq "storageAccounts" -and
        # Filter based on your needs. FileStorage kind includes pv2, and pv1 file share, where StorageV2 kind include PayGO file shares.
        $_.kind -in @("FileStorage", "StorageV2") -and
        # Filter based on your needs. "Standard_" for PayGO file share, "StandardV2_" for Pv2 file share, "Premium_" for pv1 file shares.
        # $_.name.StartsWith("StandardV2_") -and
        # Change region based on your need to see if we currently support the region (all small cases, no space in between).
        # $_.locations -eq "italynorth" -and
        $_.name -notin @("Standard_RAGRS", "Standard_RAGZRS")
    }

if ($filteredResult.Count -eq 0) {
    Write-Output "No results found."
} else {
    $filteredResult | `
        Select-Object `
            -Property `
                @{
                    Name = "sku";
                    Expression = { $_.name }
                }, `
                kind, `
                @{
                    Name = "mediaTier";
                    Expression = {
                        if ($_.tier -eq "Premium") {
                            "SSD"
                        } elseif ($_.tier -eq "Standard") {
                            "HDD"
                        } else {
                            "Unknown"
                        }
                    }
                }, `
                @{
                    Name = "billingModel";
                    Expression = {
                        if ($_.name.StartsWith("StandardV2_") -or
                            $_.name.StartsWith("PremiumV2_")
                        ) {
                            "ProvisionedV2"
                        } elseif ($_.name.StartsWith("Premium_")) {
                            "ProvisionedV1"
                        } else {
                            "PayAsYouGo"
                        }
                    }
                }, `
                @{
                    Name = "location";
                    Expression = { $_.locations | Select-Object -First 1 }
                } | ft sku, kind, mediaTier, billingModel, location
}

CLI do Azure

Este script usa jq, um processador JSON de linha de comando. Para baixá-lo, visite https://jqlang.org/download/

# Login to Azure account
Az login

# Track down the subscription ID in GUID format and set subscription ID
subscriptionID="your-subscription-id-number"

# Get Token
token=$(az account get-access-token --query accessToken --output tsv)

# Invoke SRP list SKU API, and get the returned SKU list
result=$(az rest --method get --uri "https://management.azure.com/subscriptions/$subscriptionID/providers/Microsoft.Storage/skus?api-version=2024-01-01" --headers "Authorization=Bearer $token")

# Filter the SKU list to get the required information, customization required here to get the best result.
filteredResult=$(echo $result | jq '.value[] | select(.resourceType == "storageAccounts" and (.kind == "FileStorage" or .kind == "StorageV2") and (.name | test("^(?!Standard_RAGRS|Standard_RAGZRS)")))' )

if [ -z "$filteredResult" ]; then
    echo "No results found."
else
    # Print the table header
    printf "%-30s %-15s %-10s %-20s %-15s\n" "SKU" "Kind" "MediaTier" "BillingModel" "Location"
    # Print the filtered results
    echo $filteredResult | jq -r '. | "\(.name)\t\(.kind)\t\(.tier | if . == "Premium" then "SSD" elif . == "Standard" then "HDD" else "Unknown" end)\t\(.name | if test("^StandardV2_|^PremiumV2_") then "ProvisionedV2" elif test("^Premium_") then "ProvisionedV1" else "PayAsYouGo" end)\t\(.locations)"' | while IFS=$'\t' read -r sku kind mediaTier billingModel location; do
        printf "%-30s %-15s %-10s %-20s %-15s\n" "$sku" "$kind" "$mediaTier" "$billingModel" "$location"
    done
fi

Consulte também

• Alterar a configuração de redundância para Arquivos do Azure
• Use redundância geográfica para projetar aplicações de alta disponibilidade