Azure Virtual Desktop Hybrid voor On-Premises VDI

Introductie

Azure Virtual Desktop Hybrid biedt organisaties een alternatieve route tussen traditionele on-premises VDI en volledig Azure-gehoste desktops. Dit artikel legt uit hoe de architectuur werkt, hoe Azure Arc lokale sessiehosts verbindt met AVD, welke wijzigingen er zijn voor bestaande VDI-infrastructuur en welke beperkingen blijven bestaan. Het onderzoekt ook wanneer Hybrid AVD zinvol is en wat IT-teams moeten evalueren voordat ze het adopteren.

Wat is Azure Virtual Desktop Hybrid?

Azure Virtual Desktop Hybrid is een implementatiemodel waarbij de Azure Virtual Desktop-service nog steeds wordt gehost en beheerd door Microsoft in Azure, maar de Windows-sessiehosts die de desktops en apps leveren, zijn on-premises.

Microsoft gebruikt Azure Arc om connectiviteit tussen omgevingen tot stand te brengen. Alle ondersteunde on-premises computers zullen Azure Arc-geactiveerde servers zijn. Vervolgens installeert de Azure Virtual Desktop Arc-extensie de vereiste AVD-componenten en registreert deze computer als een sessiehost in een AVD-hostpool.

Alles is min of meer hetzelfde voor de eindgebruiker alsof ze AVD gebruiken die gehost wordt in Azure. Gebruikers krijgen toegang tot de toegewezen desktops of apps via Windows App. Het verschil is echter dat de Windows-werklast geleverd zal worden vanuit de infrastructuur van de klant en niet vanuit Azure-computing.

Dus er is een scheiding van infrastructuur waar:

Component	Waar het draait	Wie Beheert Het
AVD-service en brokering	Azure	Microsoft
Hostpools, applicatiegroepen en toewijzingen	Azure	Klant configureert ze
Windows-sessiehosts	On-premises	Klant
Hypervisor of fysieke infrastructuur	On-premises	Klant
Sessie-host OS en applicaties	On-premises	Klant
Lokale netwerken en opslag	On-premises	Klant
Azure Arc-integratie	Azure + on-premises	Gedeelde afhankelijkheid

De belangrijkste conclusie hier is dat "hybride" een beschrijving is van de verdeling van verschillende elementen in de VDI-architectuur. Azure Virtual Desktop is op zichzelf nooit een volledig on-premises oplossing geworden.

Hoe werkt Azure Virtual Desktop Hybrid?

De architectuur begint met de machines die desktops of applicaties leveren. Organisaties bieden ondersteunde Windows virtuele machines of ondersteunde headless fysieke apparaten op hun eigen infrastructuur.

De Azure Connected Machine-agent registreert elke sessiehost bij Azure Arc. Een Azure Virtual Desktop Arc-extensie kan vervolgens de vereiste AVD-componenten installeren en de machine registreren bij een AVD-hostpool.

Azure Arc biedt of beheert de onderliggende virtuele machine niet. De sessiehost maakt deel uit van de lokale infrastructuur van de organisatie, wat betekent dat het IT-team van de organisatie verantwoordelijk is voor de levenscyclus, capaciteit en onderliggende virtualisatieplatform van de sessiehost.

Wanneer een gebruiker verbinding maakt, biedt Azure Virtual Desktop de servicezijde mogelijkheden om bronnen te ontdekken, toegang te authenticeren en de sessie te bemiddelen. De daadwerkelijke Windows-werklast draait op de lokale sessiehost.

Deze architectuur scheidt de AVD-service van de sessiehosts, waardoor Hybrid AVD zich van beide onderscheidt. traditionele on-premises VDI en standaard Azure-gehoste AVD: Microsoft beheert de cloudservice, maar de klant blijft de compute-infrastructuur beheren.

Hoe verandert hybride AVD een bestaande on-premises VDI-omgeving?

Voor bestaande VDI-omgevingen is de uitdaging niet alleen of de huidige servers in het datacenter kunnen worden behouden, maar ook welke lagen van de bestaande architectuur zijn behouden, welke AVD zijn vervangen en welke operationele verantwoordelijkheden door de organisatie zijn behouden.

Bestaande computers kunnen on-premises blijven

In tegenstelling tot een volledige Azure AVD-migratie, waarbij de sessie-hostcomputers naar Azure verhuizen, zijn er geen wijzigingen nodig aan de bestaande sessiehosts in het datacenter.

Organisaties kunnen profiteren van ondersteunde Windows virtuele machines op hun voorkeurs hypervisor in hun lokale datacenters. Dit kan nuttig zijn in gevallen waarin er aanzienlijke bestaande virtualisatie-infrastructuur is, of toepassingen sterk afhankelijk zijn van bestaande lokale systemen.

De aanwezigheid van bestaande hardware impliceert echter niet dat de VDI-omgeving onveranderd is. Sessiehosts moeten in overeenstemming worden gebracht met Microsoft-specificaties en geregistreerd als Azure Arc-enabled voordat ze kunnen worden gebruikt met Azure Virtual Hybrid Desktop.

De VDI-besturinglaag verhuist naar Azure

De meest significante architectonische verschillen verschijnen boven de sessiehosts.

In plaats van de volledige desktopleveringsstack intern te beheren, maakt de organisatie gebruik van het Azure Virtual Desktop-platform. Microsoft stelt kerncomponenten van de service beschikbaar voor het ontdekken van middelen, bemiddeling en gatewayverbinding.

Organisaties blijven verantwoordelijk voor het configureren van hostpools, applicatiegroepen, werkruimtes en gebruikersrechten, maar deze middelen maken nu deel uit van de AVD-architectuur. Eerdere on-premises brokers, gateways en beheerscomponenten hoeven mogelijk niet langer dezelfde functies uit te voeren.

Lokale Infrastructuurbeheer Blijft

Het verschuiven van de servicelaag naar Azure maakt de ondersteunende infrastructuur niet Microsoft-beheerd.

IT-teams behouden de verantwoordelijkheid voor het provisioneren, patchen en onderhouden van lokale hardware, besturingssystemen, applicaties, netwerken, opslag en het onderliggende virtualisatieplatform. Microsoft documenteert expliciet dat Azure Virtual Desktop Hybrid geen on-premises sessiehost-VM's provisioneert of hun stroomstatus beheert.

Hybrid AVD moet worden begrepen als een herverdeling van VDI-verantwoordelijkheden in plaats van een overdracht van de gehele oplossingsstack aan Microsoft.

In welk geval het zinvol is om AVD-sessiehosts on-premises te houden?

Als Azure al de AVD-service biedt, lijkt het misschien de gemakkelijkste weg om die sessiehost in Azure te plaatsen. Hybride komt in beeld wanneer er een technische, kosten- of operationele rechtvaardiging is om workloads in het datacenter te houden.

Legacy-applicaties en lokale afhankelijkheden

De toepassingen die worden gevirtualiseerd zijn vaak Windows-apps die sterk afhankelijk zijn van lokale databases, bestandsdeling, authenticatiediensten, randapparatuur of andere backendsystemen.

Je wint er niet veel mee om de sessiehost in Azure te plaatsen, maar de app-afhankelijkheden on-premises te laten, aangezien je gewoon netwerkvertraging aan de mix toevoegt. Dicht bij de back-end blijven voorkomt dat je de applicatiearchitectuur moet aanpassen alleen om te veranderen waar eindgebruikers verbinding mee maken.

Dit geldt vooral voor legacy line-of-business applicaties die zijn ontworpen om te werken in een lokaal netwerk.

Gegevenslocatie en infrastructuurvereisten

Sommige bedrijven hebben bepaalde werklasten of gegevens nodig om op infrastructuur onder hun controle te verblijven om redenen van regelgeving, contracten of operationele redenen.

Hybrid AVD stelt desktop- en app-verwerking in staat om lokaal te blijven terwijl Azure wordt gebruikt voor de desktopleveringsdienst. IT-teams moeten deze architectonische optie echter zorgvuldig analyseren in het licht van hun compliance-eisen, aangezien het hybride model nog steeds afhankelijk is van Microsoft Azure.

Bestaande datacenterinvestering

Organisaties met beschikbare reservecapaciteit in servers, opslag en virtualisatiebronnen hebben mogelijk weinig directe prikkel om dat te veranderen.

Hybride AVD zou dergelijke bedrijven in staat kunnen stellen om nieuwe capaciteit in golven te verwerven, terwijl bestaande rekenbronnen de werklasten blijven verwerken en het controlevlak eromheen wordt getransformeerd. De architectuur leent zich ook voor iteratieve modernisering, aangezien verschillende werklasten in verschillende tempo's kunnen worden gemigreerd.

Werkbelastingen Gevoelig voor Backend Latentie

Voor sommige toepassingen is de nabijheid van de sessiehost tot de middelen die het verbruikt belangrijker dan de nabijheid van de sessiehost tot de eindgebruiker.

Toepassingen die vaak oproepen doen naar lokale databases, opslagsystemen of andere infrastructuur presteren mogelijk niet zo goed als deze afhankelijkheden over een WAN zijn verspreid. Door de Windows-sessie lokaal te houden, kan de nabijheid tot deze bronnen worden behouden.

Wanneer hybride AVD mogelijk niet de juiste keuze is

De waarde van het behouden van sessiehosts on-premises wordt verminderd als het doel van de organisatie is om de datacenterinfrastructuur te elimineren in plaats van deze te onderhouden. In een dergelijk scenario kan het gebruik van Azure-gehoste AVD beter passen bij het gewenste operationele model.

IT-teams moeten ook overwegen of ze het Azure Virtual Desktop-service model überhaupt nodig hebben. Als de primaire vereiste de veilige publicatie van gecentraliseerde Windows-toepassingen of bureaubladen terwijl directe infrastructuurcontrole behouden blijft, kan een Azure-afhankelijke VDI-besturingslaag onnodige architectonische complexiteit introduceren.

Verwijdert Hybrid AVD VPN's en RD Gateways?

Azure Virtual Desktop elimineert veel van de complexiteit van externe connectiviteit door organisaties in staat te stellen individuele sessiehosts niet bloot te stellen aan het internet of een standaard Remote Desktop Gateway (RD Gateway) voor AVD te implementeren.

AVD maakt gebruik van de service-infrastructuur van Microsoft om verbinding te maken via de Microsoft-service. Het standaardtransport maakt gebruik van TCP-gebaseerde omgekeerde verbinding, terwijl RDP Shortpath een UDP-gebaseerd transport kan onderhandelen als het netwerk en de configuratie dit ondersteunen.

Voor organisaties die momenteel een VDI-omgeving hebben die een inkomende Remote Desktop Protocol (RDP) verbinding gebruikt, evenals andere methoden zoals VPN-toegang of lokaal beheerde RD Gateways voor Externe toegang dit zou de architectuur van de externe toegang aanzienlijk kunnen veranderen.

Netwerkconnectiviteitsvereisten worden niet geëlimineerd. On-premises sessiehosts moeten nog steeds verbinding maken met de juiste Azure-services, terwijl applicaties betrouwbare toegang tot lokale afhankelijkheden nodig hebben. Connectiviteitsoverwegingen zoals DNS, identiteit, firewallconfiguratie, routering en veerkracht zijn daarom nog steeds belangrijke ontwerpelementen.

Wat zijn de beperkingen van Azure Virtual Desktop Hybrid?

Hybrid AVD biedt implementatieflexibiliteit, maar er zijn enkele belangrijke verschillen met Azure-gehoste AVD die invloed kunnen hebben op architectuur en operaties.

Microsoft definieert momenteel verschillende sessiehostbeheer mogelijkheden als niet-ondersteund voor Hybrid AVD:

• Energiebeheer
• Azure Virtual Desktop Autoscale
• Start VM bij Verbinden
• Sessiehostconfiguratie

Ondernemingen zouden verantwoordelijk zijn voor het bieden van deze mogelijkheden via hun hypervisor, scripts, automatisering of andere tools.

Daarnaast is de ondersteuning voor het besturingssysteem anders, aangezien er geen ondersteuning is voor Azure Virtual Desktop Hybrid met Windows 10 Enterprise multi-sessie en Windows 11 Enterprise multi-sessie. Dit is een aanzienlijk verschil omdat multi-sessie Windows-clientbesturingssystemen een belangrijke functie zijn van Azure-gehoste AVD.

Licentievereisten moeten ook zorgvuldig worden beoordeeld, rekening houdend met het beoogde besturingssysteem en het gebruiksdoel. Het moet worden bevestigd of de vereisten voor de hybride licenties van Microsoft Azure Virtual Desktop van toepassing zijn naast de bestaande VDI-, Remote Desktop Services- of Microsoft 365-licenties.

Uiteindelijk maakt het hebben van lokale sessiehosts de AVD-implementatie niet cloudonafhankelijk, aangezien de door Microsoft beheerde Azure Virtual Desktop-service een integraal onderdeel van de architectuur blijft.

Azure-Hosted AVD vs Hybride AVD vs Traditionele On-Premises VDI

Eindversie van de zin (herschreven, met andere woorden, met enkele zinnen die in structuur of lengte zijn veranderd):

	Traditionele On-Premises VDI	Azure Virtual Desktop Hybrid	Azure-Hosted AVD
Sessiehosts	On-premises	On-premises	Azure
VDI-service/controlplane	Gewoonlijk klant/leverancier infrastructuur	Microsoft AVD in Azure	Microsoft AVD in Azure
Lokale hypervisor vereist	Typisch wel	Ja voor VM-gebaseerde hosts	Nee
Lokale computerbeheer	Klant	Klant	Niet van toepassing op lokale computer
Native AVD VM-lifecyclefuncties	Nee	Beperkt	Breder ondersteuning
Nabijheid van lokale applicaties	Hoog	Hoog	Hangt af van het netwerkontwerp
Azure-afhankelijkheid	Productafhankelijk	Ja	Ja
Azure compute consumptie	Nee	Niet voor lokale sessiehosts	Ja

Dus heeft hybride AVD een architectuur met een middenweg, waarbij de workloads vanuit de cloud (beheerd door Microsoft) worden geleverd, maar de lokale rekencapaciteit door de klant wordt beheerd.

Zo'n architectonische keuze is alleen te rechtvaardigen als er een voordeel is om de werklasten lokaal te houden.

Hoe moeten IT-teams een overstap naar hybride AVD evalueren?

Een hybride AVD-beoordeling zou niet met Azure moeten beginnen, maar met workloads en afhankelijkheden.

Identificeer welke applicaties en desktops op locatie moeten worden gehouden en documenteer hun afhankelijkheden van databases, bestandsdiensten, identiteitsystemen, randapparatuur, opslag en andere infrastructuur. Dit maakt het mogelijk vast te stellen of het onderhouden van sessiehosts op locatie enige architectonische waarde heeft.

De huidige staat van de VDI-stack moet worden gemapt naar het AVD-model. Welke brokers, gateways en beheerdiensten zullen worden vervangen door Azure Virtual Desktop? Welke operationele verantwoordelijkheden blijven bestaan?

Lifecyclebeheer van sessiehosts is een belangrijke overweging. Als het bestaande VDI-platform automatische provisioning, starten/stopen of schalen van VM's omvat, evalueer dan of die mogelijkheden beschikbaar zijn in Hybrid AVD in plaats van aan te nemen dat het Azure-besturingsvlak ze zal vervangen.

Identiteit, netwerken, licenties, veerkracht en operationele verantwoordelijkheden moeten als een groep worden geëvalueerd. Het doel is niet alleen om te bepalen of bestaande machines kunnen worden geregistreerd bij Azure Virtual Desktop, maar ook of het scheiden van VDI-infrastructuur tussen Azure en het datacenter een eenvoudigere en duurzamere omgeving zal opleveren.

Zoekt u een eenvoudigere manier om Windows-toepassingen en bureaubladen te leveren?

Hybride AVD kan zinvol zijn wanneer een organisatie specifiek Azure Virtual Desktop wil terwijl de sessiehosts on-premises blijven. Maar niet elke organisatie hoeft zijn desktopleveringsarchitectuur te splitsen tussen een door Azure beheerde service en lokaal beheerde rekenkracht.

Waar de vereiste voornamelijk is om Windows-toepassingen of volledige desktops veilig te publiceren vanuit bestaande Windows-infrastructuur, TSplus Remote Access biedt een directer alternatief. Organisaties kunnen applicaties en desktops leveren via RDP-compatibele of browsergebaseerde HTML5-toegang, terwijl ze de controle behouden over waar de ondersteunende infrastructuur draait.

Conclusie

Azure Virtual Desktop Hybrid biedt een middenweg tussen traditionele on-premises VDI en Azure-gehoste AVD. Het verplaatst belangrijke desktop-leveringsdiensten naar Azure, terwijl Windows-sessiehosts en hun workloads binnen de bestaande infrastructuur blijven.

De beslissende factor is of het behouden van die workloads lokaal een duidelijk technisch of operationeel voordeel biedt. IT-teams moeten applicatieafhankelijkheden, infrastructuurbeheer, netwerken, licenties en Azure-afhankelijkheid samen evalueren voordat ze beslissen of Hybrid AVD hun VDI-omgeving daadwerkelijk vereenvoudigt.