Introdução
Azure Virtual Desktop Hybrid oferece às organizações um caminho alternativo entre VDI tradicional local e desktops totalmente hospedados no Azure. Este artigo explica como a arquitetura funciona, como o Azure Arc conecta hosts de sessão locais ao AVD, quais mudanças ocorrem na infraestrutura VDI existente e quais limitações permanecem. Também examina quando o AVD Híbrido faz sentido e o que as equipes de TI devem avaliar antes de adotá-lo.
O que é o Azure Virtual Desktop Híbrido?
Azure Virtual Desktop Hybrid é um modelo de implantação onde o serviço Azure Virtual Desktop ainda é hospedado e gerenciado pela Microsoft no Azure, mas os hosts de sessão do Windows que entregam as áreas de trabalho e aplicativos estão localmente.
A Microsoft usa o Azure Arc para estabelecer conectividade entre ambientes. Todos os computadores locais suportados serão servidores habilitados para Azure Arc. Em seguida, a extensão Azure Virtual Desktop Arc instala os componentes necessários do AVD e registra este computador como um host de sessão em um pool de hosts AVD.
Tudo é mais ou menos o mesmo para o usuário final, como se estivesse usando AVD hospedado no Azure. Os usuários acessam as áreas de trabalho ou aplicativos atribuídos via Windows App. No entanto, a diferença é que a carga de trabalho do Windows será entregue pela infraestrutura do cliente e não pela computação do Azure.
Então, há uma separação de infraestrutura onde:
| Componente | Onde Ele Funciona | Quem Gerencia Isso |
|---|---|---|
| Serviço AVD e intermediação | Azure | Microsoft |
| Pools de host, grupos de aplicativos e atribuições | Azure | O cliente os configura |
| Hosts de sessão do Windows | Localmente | Cliente |
| Hipervisor ou infraestrutura física | Localmente | Cliente |
| Sistema operacional e aplicativos do host de sessão | Localmente | Cliente |
| Rede e armazenamento local | Localmente | Cliente |
| Integração do Azure Arc | Azure + local | Dependência compartilhada |
A principal conclusão aqui é que "híbrido" é uma descrição da distribuição de elementos distintos na arquitetura VDI. O Azure Virtual Desktop, por si só, nunca se tornou uma solução totalmente local.
Como funciona o Azure Virtual Desktop Híbrido?
A arquitetura começa com as máquinas que entregam desktops ou aplicativos. As organizações fornecem máquinas virtuais Windows suportadas ou dispositivos físicos headless suportados em sua própria infraestrutura.
O agente Azure Connected Machine registra cada host de sessão com o Azure Arc. Uma extensão Azure Virtual Desktop Arc pode então instalar os componentes AVD necessários e registrar a máquina em um pool de hosts AVD.
Azure Arc não fornece nem gerencia a máquina virtual subjacente. O host da sessão faz parte da infraestrutura local da organização, o que significa que a equipe de TI da organização é responsável pelo ciclo de vida do host da sessão, capacidade e plataforma de virtualização subjacente.
Quando um usuário se conecta, o Azure Virtual Desktop fornece as capacidades do lado do serviço para descobrir recursos, autenticar o acesso e mediar a sessão. A carga de trabalho real do Windows é executada no host de sessão local.
Essa arquitetura separa o serviço AVD dos hosts de sessão, diferenciando o AVD Híbrido de ambos. VDI tradicional local e AVD hospedado no Azure padrão: a Microsoft gerencia o serviço em nuvem, mas o cliente continua a operar a infraestrutura de computação.
Como o AVD Híbrido muda um ambiente VDI existente no local?
Para ambientes VDI existentes, o desafio não é apenas se os servidores atuais podem ser mantidos no datacenter, mas quais camadas da arquitetura existente foram retidas, qual AVD foi substituído e quais responsabilidades operacionais foram mantidas pela organização.
A Computação Existente Pode Permanecer Localmente
Ao contrário de uma migração completa do Azure AVD, onde a computação do host de sessão é transferida para o Azure, isso não requer alterações nos hosts de sessão existentes no datacenter.
As organizações podem aproveitar máquinas virtuais Windows suportadas em seu hipervisor preferido em seus datacenters locais. Isso pode ser útil em casos onde há uma infraestrutura de virtualização existente substancial, ou aplicações dependem fortemente de sistemas locais existentes.
A presença de hardware existente não implica que o ambiente VDI permaneça inalterado, no entanto. Os hosts de sessão devem estar em conformidade com Especificações da Microsoft e inscritos como habilitados para Azure Arc antes de poderem ser usados com Azure Virtual Hybrid Desktop.
O Plano de Controle VDI Muda para o Azure
As diferenças arquitetônicas mais significativas aparecem acima dos hosts de sessão.
Em vez de operar toda a pilha de entrega de desktop internamente, a organização utiliza a plataforma Azure Virtual Desktop. A Microsoft expõe componentes principais do serviço para descoberta de recursos, intermediação e conectividade de gateway.
As organizações mantêm a responsabilidade pela configuração de pools de hosts, grupos de aplicativos, áreas de trabalho e direitos dos usuários, mas esses recursos agora fazem parte da arquitetura AVD. Corretores, gateways e componentes de gerenciamento locais anteriores podem não precisar mais desempenhar as mesmas funções.
Gestão de Infraestrutura Local Permanece
Mover a camada de serviço para o Azure não torna a infraestrutura de suporte gerenciada pela Microsoft.
As equipes de TI mantêm a responsabilidade pela provisão, atualização e manutenção de hardware local, sistemas operacionais, aplicativos, redes, armazenamento e a plataforma de virtualização subjacente. A Microsoft documenta explicitamente que o Azure Virtual Desktop Hybrid não provisiona VMs de host de sessão locais nem gerencia seu estado de energia.
Hybrid AVD deve ser entendido como uma redistribuição das responsabilidades de VDI em vez de uma transferência de toda a pilha de soluções para a Microsoft.
Em quais casos faz sentido manter os hosts de sessão AVD no local?
Se o Azure já fornece o serviço AVD, optar por colocar esse host de sessão no Azure pode parecer o caminho mais fácil. O híbrido entra em cena quando há uma justificativa técnica, de custo ou operacional para manter as cargas de trabalho no datacenter.
Aplicativos Legados e Dependências Locais
As aplicações que estão sendo virtualizadas são frequentemente aplicativos do Windows que dependem fortemente de bancos de dados locais, compartilhamentos de arquivos, serviços de autenticação, periféricos ou outros sistemas de backend.
Você não ganha muito ao colocar o host da sessão no Azure, mas deixar as dependências do aplicativo no local, já que você apenas adicionará latência de rede à mistura. Permanecer próximo ao back-end evita ter que desmontar a arquitetura do aplicativo apenas para mudar de onde os usuários finais se conectam.
Isso é especialmente verdadeiro para aplicações legadas de linha de negócios que foram projetados para funcionar em um ambiente de rede local.
Localização de Dados e Requisitos de Infraestrutura
Algumas empresas precisam que certas cargas de trabalho ou dados residam em infraestrutura sob seu controle por razões regulatórias, contratuais ou operacionais.
Hybrid AVD permite que o processamento de desktop e aplicativos permaneça local enquanto utiliza o Azure para o serviço de entrega de desktop. As equipes de TI devem, no entanto, analisar cuidadosamente essa opção arquitetônica em relação aos seus requisitos de conformidade, uma vez que o modelo híbrido ainda depende do Microsoft Azure.
Investimento em Datacenter Existente
Organizações com capacidade de sobra disponível em servidores, armazenamento e recursos de virtualização podem ter pouco incentivo imediato para mudar isso.
Hybrid AVD poderia permitir que essas empresas adquirissem nova capacidade em ondas, onde os recursos computacionais existentes continuam lidando com as cargas de trabalho enquanto o plano de controle é transformado ao seu redor. A arquitetura também se presta à modernização iterativa, uma vez que diferentes cargas de trabalho podem ser migradas em ritmos diferentes.
Cargas de trabalho sensíveis à latência do backend
Para algumas aplicações, a proximidade do host da sessão com os recursos que consome é mais importante do que a proximidade do host da sessão com o usuário final.
Aplicativos que fazem chamadas frequentes a bancos de dados locais, sistemas de armazenamento ou outra infraestrutura podem não ter um desempenho tão bom se essas dependências estiverem distribuídas por uma WAN. Ao manter a sessão do Windows local, a proximidade com esses recursos pode ser mantida.
Quando o AVD Híbrido Pode Não Ser a Opção Certa
O valor de manter os hosts de sessão no local é reduzido se o objetivo da organização é eliminar a infraestrutura do datacenter em vez de mantê-la. Em tal cenário, o uso do AVD hospedado no Azure pode se adequar melhor ao modelo operacional desejado.
As equipes de TI também devem considerar se realmente precisam do modelo de serviço Azure Virtual Desktop. Se o requisito principal for o publicação segura de aplicativos ou desktops Windows centralizados ao mesmo tempo em que mantém o controle direto da infraestrutura, um plano de controle VDI dependente do Azure pode introduzir complexidade arquitetônica desnecessária.
A AVD Híbrida Elimina VPNs e Gateways RD?
Azure Virtual Desktop elimina muitas das complexidades da conectividade externa, permitindo que as organizações evitem expor hosts de sessão individuais à internet ou implantar um Gateway de Área de Trabalho Remota (RD Gateway) padrão para AVD.
AVD usa a infraestrutura de serviços da Microsoft para se conectar através do serviço da Microsoft. O transporte padrão utiliza conexão reversa baseada em TCP, enquanto o RDP Shortpath pode negociar um transporte baseado em UDP se a rede e a configuração o suportarem.
Para organizações que atualmente possuem um ambiente VDI que utiliza uma conexão de Protocolo de Área de Trabalho Remota (RDP) de entrada, bem como outros métodos, como acesso VPN ou Gateways RD gerenciados localmente para acesso remoto isso poderia mudar significativamente a arquitetura do acesso externo.
Os requisitos de conectividade de rede não são eliminados. Os hosts de sessão locais ainda precisam se conectar aos serviços apropriados do Azure, enquanto os aplicativos precisam de acesso confiável às dependências locais. Considerações de conectividade, como DNS, identidade, configuração de firewall, roteamento e resiliência, são, portanto, ainda elementos de design importantes.
Quais são as limitações do Azure Virtual Desktop Híbrido?
Hybrid AVD oferece flexibilidade de implantação, mas existem algumas diferenças importantes em relação ao AVD hospedado no Azure que podem impactar a arquitetura e as operações.
A Microsoft atualmente define vários capacidades de gerenciamento de host de sessão como não suportado para AVD Híbrido:
- Gerenciamento de energia
- Escalonamento automático do Azure Virtual Desktop
- Iniciar VM na Conexão
- Configuração do Host da Sessão
As empresas seriam responsáveis por fornecer essas capacidades por meio de seu hipervisor, scripts, automação ou outras ferramentas.
Além disso, o suporte ao sistema operacional é diferente, pois não há suporte para Azure Virtual Desktop Hybrid com Windows 10 Enterprise multi-session e Windows 11 Enterprise multi-session. Esta é uma diferença significativa, pois os sistemas operacionais de cliente Windows em multi-session são um recurso chave do AVD hospedado no Azure.
Os requisitos de licenciamento também devem ser revisados cuidadosamente, considerando o sistema operacional e o caso de uso pretendidos. Deve-se confirmar se os requisitos para o licenciamento híbrido do Azure Virtual Desktop da Microsoft se aplicam além das licenças existentes de VDI, Serviços de Área de Trabalho Remota ou Microsoft 365.
Finalmente, ter hosts de sessão locais não torna a implantação do AVD independente da nuvem, uma vez que o serviço gerenciado Azure Virtual Desktop da Microsoft continua sendo uma parte integral da arquitetura.
Azure-Hosted AVD vs AVD Híbrido vs VDI Tradicional Local
Versão final da frase (reescrita, usando palavras diferentes, com algumas frases alteradas em estrutura ou comprimento):
| VDI Tradicional On-Premises | Azure Virtual Desktop Híbrido | AVD hospedado no Azure | |
|---|---|---|---|
| Hosts de sessão | Localmente | Localmente | Azure |
| serviço VDI/plano de controle | Normalmente a infraestrutura do cliente/fornecedor | Microsoft AVD no Azure | Microsoft AVD no Azure |
| Hypervisor local necessário | Normalmente sim | Sim para hosts baseados em VM | Não |
| Gerenciamento de computação local | Cliente | Cliente | Não aplicável a computação local |
| Recursos nativos do ciclo de vida da VM AVD | Não | Limitado | Suporte mais amplo |
| Proximidade com aplicativos locais | Alto | Alto | Depende do design da rede |
| dependência do Azure | Dependente do produto | Sim | Sim |
| Consumo de computação do Azure | Não | Não para hosts de sessão local | Sim |
Assim, o AVD híbrido possui uma arquitetura de meio termo, onde as cargas de trabalho são entregues a partir da nuvem (gerenciada pela Microsoft), mas o processamento local é gerenciado pelo cliente.
Tal escolha arquitetônica só é justificável se houver um benefício em manter as cargas de trabalho locais.
Como as equipes de TI devem avaliar uma mudança para AVD híbrido?
Uma avaliação híbrida de AVD deve começar não com o Azure, mas com cargas de trabalho e dependências.
Identifique quais aplicativos e desktops devem ser mantidos nas instalações e documente suas dependências em bancos de dados, serviços de arquivos, sistemas de identidade, periféricos, armazenamento e outras infraestruturas. Isso torna possível estabelecer se a manutenção de hosts de sessão nas instalações tem algum mérito arquitetônico.
O estado atual da pilha VDI deve ser mapeado para o modelo AVD. Quais corretores, gateways e serviços de gerenciamento serão substituídos pelo Azure Virtual Desktop? Quais responsabilidades operacionais permanecerão?
A gestão do ciclo de vida do host de sessão é uma consideração chave. Se a plataforma VDI existente inclui provisionamento automático, início/parada ou escalonamento de VMs, avalie se essas capacidades estão disponíveis no Hybrid AVD em vez de presumir que o plano de controle do Azure as substituirá.
Identidade, rede, licenciamento, resiliência e responsabilidades operacionais devem ser avaliados como um grupo. O objetivo não é apenas determinar se as máquinas existentes podem ser registradas no Azure Virtual Desktop, mas se separar a infraestrutura VDI entre o Azure e o datacenter produzirá um ambiente mais simples e sustentável.
Procurando uma maneira mais simples de entregar aplicativos e desktops do Windows?
Hybrid AVD pode fazer sentido quando uma organização deseja especificamente o Azure Virtual Desktop enquanto mantém os hosts de sessão localmente. Mas nem toda organização precisa dividir sua arquitetura de entrega de desktop entre um serviço gerenciado pelo Azure e computação gerenciada localmente.
Onde o requisito é principalmente publicar aplicativos Windows ou desktops completos de forma segura a partir da infraestrutura Windows existente, TSplus Acesso Remoto fornece uma alternativa mais direta. As organizações podem entregar aplicativos e desktops por meio de acesso compatível com RDP ou baseado em navegador HTML5, mantendo o controle sobre onde a infraestrutura de suporte é executada.
Conclusão
Azure Virtual Desktop Hybrid fornece um meio-termo entre VDI tradicional local e AVD hospedado no Azure. Ele move serviços-chave de entrega de desktop para o Azure, permitindo que os hosts de sessão do Windows e suas cargas de trabalho permaneçam dentro da infraestrutura existente.
O fator decisivo é se manter essas cargas de trabalho localmente oferece um benefício técnico ou operacional claro. As equipes de TI devem avaliar as dependências de aplicativos, gerenciamento de infraestrutura, redes, licenciamento e dependência do Azure juntas antes de decidir se o AVD Híbrido realmente simplifica seu ambiente VDI.
TSplus Acesso Remoto Teste Gratuito
Alternativa definitiva ao Citrix/RDS para acesso a desktop/aplicativos. Seguro, econômico, local/nuvem