Azure Site Recovery agora suporta VMs Linux com discos NVMe — e isso muda o jogo para DR em produção
TL;DR: Este artigo analisa o anúncio da Microsoft sobre o suporte do Azure Site Recovery para VMs Linux com discos NVMe (séries Da/Ea/Fa v6 e Ebsv5/Ebdsv5). A conclusão principal é que, embora a novidade desbloqueie cenários de disaster recovery para workloads de alta latência e throughput, o suporte ainda está em preview e limitado a cenários Azure-to-Azure, exigindo planejamento adicional de validação e testes de failover antes de usar em produção crítica.
Nos últimos anos, a adoção de VMs Linux com controladores NVMe no Azure cresceu significativamente, especialmente entre empresas que rodam bancos de dados de alta performance, sistemas de arquivos distribuídos e aplicações de big data. Até agora, porém, quem optava por essas configurações enfrentava uma lacuna crítica: o Azure Site Recovery (ASR) não oferecia suporte para replicação e disaster recovery (DR) dessas máquinas. Isso obrigava times de infraestrutura a manter estratégias de backup paralelas ou aceitar riscos maiores de downtime em cenários de falha regional.
A Microsoft anunciou em preview o suporte do ASR para VMs Linux Azure Generation 2 equipadas com discos NVMe, incluindo as séries Da/Ea/Fa v6 e Ebsv5/Ebdsv5. A funcionalidade cobre exclusivamente o cenário Azure-to-Azure — ou seja, replicação entre regiões dentro do próprio ecossistema Azure. Para empresas brasileiras que utilizam essas famílias de VMs em workloads críticas, como sistemas de ERP, data lakes ou clusters de Kubernetes com storage local NVMe, isso representa um passo importante rumo a uma estratégia de continuidade de negócios mais robusta.
Por que isso importa para o mercado brasileiro?
No Brasil, a adoção de Azure tem crescido fortemente em setores como financeiro, varejo e logística, onde a latência de storage impacta diretamente a experiência do usuário e o custo operacional. VMs com NVMe oferecem throughput de I/O muito superior a discos premium tradicionais, mas sem suporte a DR nativo, o time de engenharia precisava recorrer a soluções como replicação via scripts customizados, ferramentas de terceiros ou snapshots manuais — todos caros, frágeis e difíceis de auditar.
Com o anúncio, o ASR passa a cobrir um gap importante. No entanto, é crucial que o leitor entenda as limitações: a funcionalidade está em preview, sem SLA de disponibilidade ou suporte oficial. Além disso, a replicação só funciona entre regiões Azure (Azure-to-Azure), o que significa que não é possível usar o ASR para migrar ou proteger VMs NVMe que estejam em ambientes on-premises ou em outros provedores. Portanto, o anúncio é mais um avanço incremental do que uma revolução — mas um avanço que pode eliminar dores reais para quem já está comprometido com Azure.
Como o suporte a NVMe impacta a arquitetura de DR?
Para times de infraestrutura, o principal ganho é a simplificação do design de disaster recovery. Antes, ao provisionar uma VM Linux com NVMe, era necessário planejar um caminho alternativo de DR, muitas vezes usando storage externo (como Azure NetApp Files ou soluções de backup independentes). Agora, o ASR permite replicar essas VMs diretamente, com failover planejado e não planejado, mantendo a consistência dos dados.
Entretanto, há pontos de atenção:
- Validação de failover: Como a funcionalidade está em preview, recomenda-se realizar testes de failover completos em ambiente de homologação antes de qualquer ativação em produção.
- Limitação de SKUs: Nem todas as VMs Generation 2 com NVMe são suportadas. Consulte a lista oficial de SKUs elegíveis.
- Consistência de dados: O ASR oferece replicação consistente com crash e consistência com aplicação (via VSS para Windows, mas para Linux é necessário validar se a aplicação suporta o modelo de consistência adotado).
Quais cenários práticos são desbloqueados?
- Bancos de dados relacionais (MySQL, PostgreSQL) rodando em VMs Da v6 com NVMe: agora é possível replicar para uma região secundária sem depender de replicação nativa do banco.
- Clusters de processamento de dados (Spark, Presto) em VMs Ebsv5: o DR pode ser configurado com failover automático em caso de falha regional.
- Ambientes de desenvolvimento e staging que precisam de replicação para testes de performance em regiões alternativas.
Qual o próximo passo para o time de engenharia?
Recomenda-se que as equipes de cloud e infraestrutura:
- Identifiquem as VMs Linux NVMe atuais (ou planejadas) e verifiquem a compatibilidade com as SKUs listadas na documentação do preview.
- Criem um plano de teste de failover controlado, sem expor tráfego de produção.
- Avaliem se o ASR atende aos RPO e RTO exigidos pelo negócio, considerando a latência de replicação entre as regiões utilizadas.
- Caso o preview atenda aos requisitos, preparem a transição para o GA quando disponível, mas sem pressa — a confiabilidade do DR é mais importante que a velocidade de adoção de previews.
Para empresas brasileiras que já operam ou planejam workloads intensivas em I/O no Azure, essa atualização reduz a complexidade operacional e aproxima o ASR de se tornar uma peça central na estratégia de resiliência. Por enquanto, a mensagem é clara: é possível, mas teste antes de confiar.
Perguntas Frequentes
-
O suporte para NVMe no Azure Site Recovery já está disponível para todos os cenários?
- Não. Atualmente está em preview e limitado ao cenário Azure-to-Azure (replicação entre regiões). Não cobre migração on-premises para Azure nem recuperação para regiões diferentes das suportadas pelas séries Da/Ea/Fa v6 e Ebsv5/Ebdsv5.
-
Quais famílias de VMs Linux são elegíveis para essa funcionalidade?
- As séries Da/Ea/Fa v6 (com NVMe habilitado) e as séries Ebsv5/Ebdsv5. A funcionalidade se aplica exclusivamente a VMs Generation 2 com controladores NVMe. Consulte a documentação oficial da Microsoft para a lista completa de SKUs compatíveis.
-
Essa funcionalidade substitui outras estratégias de backup para VMs NVMe?
- Não substitui completamente. O Azure Site Recovery foca em replicação contínua e failover para disaster recovery. Para backup pontual e restauração de arquivos individuais, você ainda precisa de soluções como Azure Backup ou ferramentas de terceiros. DR e backup são complementares.
-
Quais são os principais riscos de usar essa funcionalidade em preview?
- Como qualquer preview, não há SLA de disponibilidade ou suporte garantido. É essencial realizar testes de failover completos em ambiente de homologação, validar a consistência dos dados replicados e planejar rollback manual em caso de falha. Não é recomendado para workloads críticas sem cobertura contratual.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
