Laboratório de Troubleshooting: Configure Azure Storage redundancy
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento relata que a aplicação está retornando erros intermitentes ao tentar ler blobs de uma conta de armazenamento. O administrador investiga e coleta as seguintes informações:
- A conta de armazenamento está configurada com RA-GRS
- A aplicação usa o endpoint secundário para todas as leituras, conforme configurado pela equipe de desenvolvimento há três semanas
- A região primária está operacional e sem incidentes registrados no Azure Service Health
- A conta de armazenamento foi criada há seis meses
- O administrador verifica o portal e identifica que um failover foi concluído na noite anterior por outro membro da equipe de operações
A saída do comando executado pelo administrador é:
az storage account show \
--name minhaconta \
--resource-group producao-rg \
--query "[sku.name, primaryEndpoints.blob, secondaryEndpoints]" \
--output json
[
"Standard_GRS",
"https://minhaconta.blob.core.windows.net/",
null
]
Qual é a causa raiz dos erros de leitura na aplicação?
A) A conta foi rebaixada de RA-GRS para GRS durante o failover, eliminando o endpoint secundário de leitura.
B) A região primária está com latência elevada, causando falhas intermitentes no endpoint secundário.
C) O failover concluído promoveu o secundário a primário, e o novo estado não possui ainda uma região secundária configurada, tornando o endpoint secundário inexistente.
D) O SKU Standard_GRS não suporta leituras no endpoint secundário, sendo necessário RA-GRS explícito.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que uma conta de armazenamento crítica em produção, atualmente configurada com LRS, está localizada em uma região do Azure que sofreu dois incidentes de datacenter nos últimos doze meses. A liderança decidiu que a conta deve ser migrada para GZRS para aumentar a resiliência.
O administrador responsável tem as seguintes informações:
- A conta armazena aproximadamente 40 TB de dados de logs históricos acessados raramente
- A migração para ZRS ou GZRS pode ser feita via conversão direta no portal para contas LRS em regiões que suportam zonas de disponibilidade
- A região atual suporta zonas de disponibilidade
- A janela de manutenção disponível é de 4 horas na próxima madrugada
- Não há aplicações gravando na conta durante a janela de manutenção
- O time de segurança solicitou um relatório de auditoria da conta antes de qualquer alteração, mas ainda não entregou o modelo do relatório
Qual é a ação correta a tomar durante a janela de manutenção?
A) Iniciar a conversão direta de LRS para GZRS pelo portal, pois todos os requisitos técnicos estão atendidos e a janela está disponível.
B) Aguardar o relatório de auditoria do time de segurança antes de executar qualquer alteração, pois a mudança não pode ocorrer sem esse documento.
C) Criar uma nova conta com GZRS, copiar os dados com AzCopy e atualizar as conexões das aplicações durante a janela.
D) Converter a conta para ZRS primeiro e, em uma janela futura, escalar para GZRS para reduzir o risco de cada etapa.
Cenário 3 — Causa Raiz
Um administrador recebe um chamado relatando que uma conta de armazenamento não está replicando dados para a região secundária. A conta foi criada há dois dias com as seguintes configurações, conforme o ARM template usado:
{
"kind": "StorageV2",
"sku": {
"name": "Standard_ZRS"
},
"properties": {
"accessTier": "Hot",
"supportsHttpsTrafficOnly": true,
"minimumTlsVersion": "TLS1_2"
}
}
O administrador verifica no portal que a conta está operacional, os blobs estão sendo gravados com sucesso e o TLS 1.2 está ativo. Ele também confirma que a assinatura tem cota disponível para contas geo-redundantes e que não há políticas de bloqueio no resource group.
O time de arquitetura informa que esperava replicação geográfica automática porque a conta foi criada em uma região com par geográfico definido pelo Azure.
Qual é a causa raiz da ausência de replicação geográfica?
A) A política de TLS mínimo impede a replicação geográfica entre regiões com versões TLS distintas.
B) A conta foi implantada com SKU Standard_ZRS, que replica entre zonas de disponibilidade dentro da mesma região e não realiza replicação geográfica.
C) A replicação geográfica não é automática em contas novas e deve ser habilitada manualmente após 24 horas da criação.
D) O access tier Hot bloqueia replicação geográfica; seria necessário usar Cool para habilitar GRS ou GZRS.
Cenário 4 — Impacto Colateral
Um administrador identifica que uma conta de armazenamento configurada com GRS está com o failover disponível no portal após um incidente na região primária. Após confirmar com a liderança, ele executa o failover manualmente. O processo é concluído com sucesso e a aplicação volta a funcionar normalmente na nova região primária.
Três dias depois, o time de conformidade reporta que os relatórios de auditoria de acesso a blobs, que eram exportados automaticamente para um container na mesma conta, estão incompletos e com lacunas no período imediatamente posterior ao failover.
O administrador confirma que:
- A aplicação principal está gravando normalmente
- As configurações de diagnóstico da conta apontam para o mesmo container de destino
- O container de destino existe e está acessível
- Nenhuma alteração foi feita nas configurações de diagnóstico
Qual consequência colateral do failover explica as lacunas nos relatórios?
A) O failover interrompe permanentemente os logs de diagnóstico, exigindo recriação da conta de armazenamento.
B) Durante o período de failover e sincronização, gravações de diagnóstico que ocorreram na região primária original podem não ter sido replicadas para a secundária antes da promoção, gerando lacunas nos dados de auditoria.
C) O container de destino dos logs foi excluído automaticamente durante o failover para evitar dados corrompidos.
D) As configurações de diagnóstico foram redefinidas para os valores padrão após o failover, desativando a exportação dos logs.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista decisiva está na saída do comando: o campo secondaryEndpoints retorna null. Isso confirma que não existe mais um endpoint secundário na conta. O motivo é que o failover promoveu a região secundária a primária. Após a conclusão do failover, a conta opera com uma única região até que o Azure provisione uma nova secundária de forma assíncrona, o que pode levar horas ou dias dependendo da quantidade de dados.
A informação irrelevante no enunciado é o fato de a conta ter sido criada há seis meses. Esse dado não tem relação com o comportamento pós-failover e foi incluído para induzir o leitor a buscar causas relacionadas ao tempo de vida da conta.
A alternativa A é o distrator mais perigoso. Embora o SKU exibido seja Standard_GRS após o failover (e não Standard_RAGRS), isso não representa um rebaixamento funcional pelo failover em si; é o estado transitório esperado. A causa real não é a mudança de SKU, mas a ausência do endpoint secundário. Agir com base na alternativa A levaria o administrador a tentar reconfigurar o SKU como solução, o que não resolveria o problema imediato.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é explícita: o time de segurança solicitou um relatório de auditoria antes de qualquer alteração e ainda não entregou o modelo. Executar a conversão sem esse documento viola um controle de processo estabelecido pela própria organização. A janela técnica está disponível, os requisitos de infraestrutura estão atendidos, mas o processo de governança não foi cumprido.
A alternativa A ignora a restrição de governança e aplica corretamente apenas os critérios técnicos. Em um exame ou em produção, ignorar restrições de processo explícitas é um erro mesmo quando a ação técnica está correta.
A alternativa C descreve uma abordagem válida para migrações que não suportam conversão direta, mas é desnecessariamente complexa para este cenário, onde a conversão direta de LRS para GZRS é suportada. Além disso, também ignora a restrição de auditoria.
A alternativa D aplica uma lógica de escalonamento por etapas que não tem base técnica obrigatória neste contexto; a conversão direta de LRS para GZRS é suportada em regiões com zonas de disponibilidade, tornando essa divisão desnecessária e arriscada por prolongar o período de exposição.
Gabarito — Cenário 3
Resposta: B
O ARM template é a evidência direta: o SKU configurado é Standard_ZRS. O ZRS replica os dados entre zonas de disponibilidade dentro de uma única região. Ele não realiza nenhuma forma de replicação geográfica, independentemente de a região ter um par geográfico definido pelo Azure.
A informação irrelevante é a confirmação de que a assinatura tem cota para contas geo-redundantes e que não há bloqueios no resource group. Esses dados foram incluídos para induzir o leitor a buscar causas administrativas ou de permissão, quando a causa é simplesmente o SKU escolhido.
A alternativa A é tecnicamente infundada: a configuração de TLS mínimo não afeta a replicação geográfica. A alternativa C descreve um comportamento que não existe na plataforma. A alternativa D também é falsa; o access tier não tem relação com o suporte à replicação geográfica. O erro de raciocínio que os distratores representam é buscar causas em configurações visíveis e técnicas quando a causa está no SKU, que é o parâmetro central e mais óbvio do template.
Gabarito — Cenário 4
Resposta: B
O GRS replica de forma assíncrona. Isso significa que, no momento do failover, pode haver um delta de dados entre a região primária e a secundária que ainda não foi sincronizado. Gravações recentes, incluindo registros de diagnóstico gerados imediatamente antes e durante o processo de failover, podem não ter sido replicadas a tempo. O resultado observável são lacunas nos logs de auditoria correspondentes exatamente ao período do incidente e do failover.
A pista no enunciado é a combinação de dois fatores: as lacunas ocorrem no período imediatamente posterior ao failover e todas as configurações estão corretas após o evento. Isso elimina causas de configuração e aponta diretamente para a perda de dados não sincronizados inerente à replicação assíncrona do GRS.
A alternativa D é o distrator mais perigoso. O administrador poderia perder tempo inspecionando e reconfigurando diagnósticos que já estão corretos, atrasando a identificação da causa real e gerando relatórios de conformidade incorretos sobre o que causou a lacuna. A consequência real de agir com base nela seria documentar um incidente de configuração que não ocorreu.
Árvore de Troubleshooting: Configure Azure Storage redundancy
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado. Responda cada pergunta de diagnóstico com base no que você consegue verificar diretamente, seja via portal, CLI ou saída de comando. Ao chegar a um nó de causa identificada, leia a ação correspondente antes de executar qualquer mudança. Se o caminho percorrido não corresponder ao sintoma real, retorne ao último nó de decisão e siga o ramo alternativo. A árvore cobre os principais padrões de falha relacionados à redundância de armazenamento no Azure e pode ser percorrida em menos de dois minutos com o ambiente à frente.