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 os 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 gerido 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 utiliza 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 AVD necessários e registra este computador como um host de sessão em um pool de hosts AVD.
Tudo é mais ou menos o mesmo para o utilizador final como se estivesse a usar AVD hospedado no Azure. Os utilizadores acedem aos desktops ou aplicações atribuídos através da Aplicação Windows. No entanto, a diferença é que a carga de trabalho do Windows será entregue a partir da infraestrutura do cliente e não a partir da computação do Azure.
Então há uma separação de infraestrutura onde:
| Componente | Onde Funciona | Quem Gerencia Isso |
|---|---|---|
| Serviço AVD e intermediação | Azure | Microsoft |
| Pools de hosts, grupos de aplicações e atribuições | Azure | O cliente os configura |
| Hosts de sessão do Windows | No local | Cliente |
| Hipervisor ou infraestrutura física | No local | Cliente |
| Sistema operativo e aplicações do host de sessão | No local | Cliente |
| Rede local e armazenamento | No local | Cliente |
| Integração do Azure Arc | Azure + no 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 aplicações. 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 regista cada anfitrião de sessão com o Azure Arc. Uma extensão Azure Virtual Desktop Arc pode então instalar os componentes AVD necessários e registar a máquina com um pool de anfitriões AVD.
Azure Arc não fornece nem gere a máquina virtual subjacente. O anfitrião da sessão faz parte da infraestrutura local da organização, o que significa que a equipa de TI da organização é responsável pelo ciclo de vida do anfitrião da sessão, capacidade e plataforma de virtualização subjacente.
Quando um utilizador 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 anfitrião da sessão local.
Esta 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 gere 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 em 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 mantidas, qual AVD foi substituída e quais responsabilidades operacionais foram mantidas pela organização.
Os Computadores Existentes Podem Permanecer Nas Instalações
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 no seu hipervisor preferido nos seus datacenters locais. Isso pode ser útil em casos onde existe uma infraestrutura de virtualização substancial já existente, 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 ser colocados em conformidade com Especificações da Microsoft e inscritos como habilitados para Azure Arc antes de poderem ser utilizados com o 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 consome 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 aplicações, áreas de trabalho e direitos dos utilizadores, mas esses recursos agora fazem parte da arquitetura AVD. Corretores, gateways e componentes de gestão locais anteriores podem não precisar mais de desempenhar as mesmas funções.
A Gestão da Infraestrutura Local Permanece
Mover a camada de serviço para o Azure não torna a infraestrutura de suporte gerida pela Microsoft.
As equipas de TI mantêm a responsabilidade pela provisão, atualização e manutenção de hardware local, sistemas operativos, aplicações, 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 gere o 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 que caso 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.
Aplicações Legadas e Dependências Locais
As aplicações que estão a ser virtualizadas são frequentemente aplicações Windows que dependem fortemente de bases de dados locais, partilhas de ficheiros, serviços de autenticação, periféricos ou outros sistemas de backend.
Não ganha muito ao colocar o host da sessão no Azure, mas deixar as dependências do aplicativo no local, uma vez que apenas adicionará latência de rede à mistura. Manter-se próximo ao back-end evita ter que desmontar a arquitetura do aplicativo apenas para mudar de onde os usuários finais se conectam.
Isto é especialmente verdade para aplicações legadas de linha de negócios que foram projetados para funcionar em um ambiente de rede local.
Requisitos de Localização de Dados e 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 esta 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 reserva disponível em servidores, armazenamento e recursos de virtualização podem ter pouco incentivo imediato para mudar isso.
A AVD híbrida 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 aos recursos que consome é mais importante do que a proximidade do host da sessão ao utilizador final.
Aplicações que fazem chamadas frequentes a bases 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 a 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 nas instalações é reduzido se o objetivo da organização for eliminar a infraestrutura do datacenter em vez de mantê-la. Numa situação assim, o uso do AVD hospedado no Azure pode se adequar melhor ao modelo operacional desejado.
As equipas 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 aplicações ou desktops Windows centralizados ao mesmo tempo que mantém o controle direto da infraestrutura, um plano de controle VDI dependente do Azure pode introduzir complexidade arquitetônica desnecessária.
O AVD Híbrido 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 implementar um Gateway de Área de Trabalho Remota (RD Gateway) padrão para AVD.
AVD utiliza 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 geridos localmente para acesso remoto isto 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 gestão de hosts de sessão como não suportado para AVD Híbrido:
- Gestão 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 multi-session são um recurso chave do AVD hospedado no Azure.
Os requisitos de licenciamento também devem ser revistos cuidadosamente, considerando o sistema operativo e o caso de uso pretendidos. Deve ser confirmado 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 implementação do AVD independente da nuvem, uma vez que o serviço Azure Virtual Desktop gerido pela Microsoft continua a ser uma parte integral da arquitetura.
Azure-Hosted AVD vs AVD Híbrido vs VDI Tradicional On-Premises
Versão final da frase (reescrita, utilizando palavras diferentes, com algumas frases alteradas na estrutura ou comprimento):
| VDI Tradicional On-Premises | Azure Virtual Desktop Híbrido | AVD hospedado no Azure | |
|---|---|---|---|
| Hosts de sessão | No local | No local | Azure |
| serviço VDI/plano de controle | Normalmente a infraestrutura do cliente/fornecedor | Microsoft AVD no Azure | Microsoft AVD no Azure |
| Hipervisor local necessário | Normalmente sim | Sim para hosts baseados em VM | Não |
| Gestão 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 aplicações locais | Alto | Alto | Depende do design da rede |
| dependência do Azure | Dependente do produto | Sim | Sim |
| Consumo de computação Azure | Não | Não para hosts de sessão local | Sim |
Assim, a AVD híbrida tem uma arquitetura de meio-termo, onde as cargas de trabalho são entregues a partir da nuvem (gerida pela Microsoft), mas o processamento local é gerido pelo cliente.
Tal escolha arquitetónica só é justificável se houver um benefício em manter as cargas de trabalho locais.
Como as equipas de TI devem avaliar uma mudança para AVD híbrido?
Uma avaliação AVD híbrida deve começar não com o Azure, mas com cargas de trabalho e dependências.
Identifique quais aplicações 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 gestão 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 incluir provisionamento automático, início/paragem ou escalonamento de VMs, avalie se essas capacidades estão disponíveis no Hybrid AVD em vez de presumir que o plano de controlo 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 a separação da infraestrutura VDI entre o Azure e o datacenter produzirá um ambiente mais simples e sustentável.
Procurando uma maneira mais simples de entregar aplicações e desktops Windows?
O AVD híbrido pode fazer sentido quando uma organização deseja especificamente o Azure Virtual Desktop, mantendo os hosts de sessão nas instalações. Mas nem toda organização precisa dividir sua arquitetura de entrega de desktop entre um serviço gerido pelo Azure e computação gerida localmente.
Onde o requisito é principalmente publicar aplicações 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 aplicações e desktops através 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 proporciona um benefício técnico ou operacional claro. As equipes de TI devem avaliar as dependências de aplicativos, a gestão de infraestrutura, a rede, a licenciamento e a dependência do Azure em conjunto antes de decidir se o Hybrid AVD realmente simplifica o seu ambiente VDI.
TSplus Acesso Remoto Teste Gratuito
Alternativa definitiva ao Citrix/RDS para acesso a desktop/aplicações. Seguro, rentável, local/nuvem