Azure Virtual Desktop-servicearchitectuur en -tolerantie

Azure Virtual Desktop is ontworpen om organisaties en gebruikers een flexibele, betrouwbare en veilige service te bieden. De architectuur van Azure Virtual Desktop bestaat uit veel onderdelen waaruit de service bestaat die gebruikers verbindt met hun bureaubladen en apps. De meeste onderdelen worden beheerd door Microsoft, maar sommige worden beheerd door de klant of door een partner.

Microsoft biedt de VDI-onderdelen (Virtual Desktop Infrastructure) voor kernfunctionaliteit als een service. Deze onderdelen omvatten:

• Webservice: de gebruikersgerichte website en het eindpunt en retourneert de verbindingsgegevens naar het apparaat van de gebruiker.
• Broker-service: organiseert binnenkomende verbindingen.
• Gatewayservice: een websocket-service die rdp-connectiviteit (Remote Desktop Protocol) biedt vanaf het apparaat van een gebruiker vanaf de locatie waar ze verbinding maken met de sessiehosts die hun bureaubladen en apps leveren.
• Resourcemap: biedt informatie om de webservice te instrueren welke van de meerdere geografische databases als host fungeert voor de verbindingsgegevens die voor elke gebruiker zijn vereist.
• Geografische database: bevat de verbindingsbestanden (.rdp) en pictogrammen voor elke resource die een gebruiker heeft ingericht.

Daarnaast maakt Azure Virtual Desktop gebruik van andere wereldwijde Azure-services, zoals Azure Traffic Manager en Azure Front Door om gebruikers naar hun dichtstbijzijnde Azure Virtual Desktop-toegangspunten te leiden.

U bent verantwoordelijk voor het maken en beheren van sessiehosts, met inbegrip van aanpassingen en toepassingen van installatiekopieën van het besturingssysteem, connectiviteit van virtuele netwerken, de tolerantie en de back-up en het herstel van deze sessiehosts. U kunt ook gebruikersidentiteiten opgeven en beheren en de toegang tot de service beheren. U kunt andere Azure-services gebruiken om te voldoen aan uw vereisten, zoals:

• Azure-beschikbaarheidszones voor het distribueren van uw sessiehosts over fysiek afzonderlijke datacenterlocaties binnen een Azure-regio, elk met onafhankelijke voeding, koeling en netwerken.
• Azure Backup om een back-up van uw sessiehosts te maken en te herstellen.
• Azure Site Recovery om uw sessiehosts te repliceren naar een andere Azure-regio.
• Azure Advisor om u te helpen uw Azure-resources te optimaliseren.

In dit diagram op hoog niveau ziet u de onderdelen en verantwoordelijkheden:

Gebruikersverbindingen

Wanneer een gebruiker toegang wil krijgen tot de bureaubladen en apps in Azure Virtual Desktop, zijn er meerdere onderdelen betrokken om die verbinding tot stand te laten komen. Er zijn twee afzonderlijke reeksen:

1. Feeddetectie. De feed is de lijst met bureaubladen en apps die beschikbaar zijn voor de gebruiker.
2. Een verbinding via het Extern bureaublad-protocol met een sessiehost.

Feeddetectie

Tijdens de feeddetectie worden de bureaubladen en apps die beschikbaar zijn voor de gebruiker ingevuld in de app op hun lokale apparaat. De feed bevat alle informatie die nodig is om verbinding te maken.

Het feeddetectieproces is als volgt:

1. De gebruiker bevindt zich mogelijk overal ter wereld. Azure Traffic Manager stuurt het apparaat van de gebruiker naar het dichtstbijzijnde exemplaar van de Azure Virtual Desktop-webservice op basis van de geografische verkeersrouteringsmethode, die gebruikmaakt van het bron-IP-adres van het apparaat van de gebruiker.

2. De webservice maakt verbinding met de Azure Virtual Desktop-brokerservice in dezelfde Azure-regio om de RDP-bestanden en toepassingspictogrammen voor de feed van de gebruiker op te halen. De brokerservice maakt verbinding met de geografische database en resourcemap van Azure Virtual Desktop in dezelfde regio om de informatie op te halen.

3. De brokerservice retourneert de RDP-bestanden en toepassingspictogrammen naar de webservice, die de informatie retourneert naar het apparaat van de gebruiker.

   Hier volgt een diagram op hoog niveau waarin het feeddetectieproces in één Azure-regio wordt weergegeven:

   

   De geografische database bevat alleen de informatie die is vereist voor bureaubladen en apps uit hostgroepen in dezelfde Azure-regio's die worden gedekt door de geografie. Als de gebruiker is toegewezen aan desktops of apps uit een hostgroep die wordt gedekt door een andere geografie, vertelt de resourcemap de webservice om verbinding te maken met de brokerservice en geografische database in de juiste Azure-regio.

   Hier volgt een diagram op hoog niveau met het feeddetectieproces voor een hostgroep in een Azure-regio die wordt gedekt door een andere geografie:

   

RDP-verbinding

Wanneer een gebruiker vanuit de feed verbinding maakt met een bureaublad of app, wordt de RDP-verbinding als volgt tot stand gebracht:

1. Alle externe sessies beginnen met een verbinding met Azure Front Door, die het algemene toegangspunt voor Azure Virtual Desktop biedt. Azure Front Door bepaalt de Azure Virtual Desktop-gatewayservice met de laagste latentie voor het apparaat van de gebruiker en stuurt de verbinding ernaartoe

2. De gatewayservice maakt verbinding met de brokerservice in dezelfde Azure-regio. Met de gatewayservice kunnen sessiehosts zich in elke regio bevinden en nog steeds toegankelijk zijn voor gebruikers.

3. De brokerservice neemt het over en organiseert de verbinding tussen het apparaat van de gebruiker en de sessiehost. De brokerservice geeft de Azure Virtual Desktop-agent die wordt uitgevoerd op de sessiehost opdracht om verbinding te maken met dezelfde gatewayservice waarmee het apparaat van de gebruiker verbinding heeft gemaakt.

4. Op dit moment wordt een van de twee verbindingstypen gemaakt, afhankelijk van de configuratie en beschikbare netwerkprotocollen:

   1. Omgekeerde verbinding maken: nadat zowel de client als de sessiehost zijn verbonden met de gatewayservice, wordt het RDP-verkeer doorgegeven met behulp van Transmission Control Protocol (TCP) tussen de client en de sessiehost. Transport van omgekeerde verbinding is het standaardverbindingstype.

   2. RDP Shortpath: er wordt een rechtstreeks UDP-transport (User Datagram Protocol) gemaakt tussen het apparaat van de gebruiker en de sessiehost, waarbij de gatewayservice wordt overgeslagen.

Hier volgt een diagram op hoog niveau met het RDP-verbindingsproces:

Tip

Meer gedetailleerde technische informatie over netwerkconnectiviteit vindt u in Azure Virtual Desktop-netwerkconnectiviteit en RDP Shortpath voor Azure Virtual Desktop.

Servicetolerantie

Azure Virtual Desktop is ontworpen om bestand te zijn tegen fouten en gebruikers een betrouwbare service te bieden. De service is ontworpen om bestand te zijn tegen fouten van afzonderlijke onderdelen en om snel te kunnen herstellen van storingen.

De door Microsoft beheerde onderdelen van Azure Virtual Desktop bevinden zich momenteel in ongeveer 40 Azure-regio's om dichter bij gebruikers te staan en een flexibele service te bieden. Tolerantie is wereldwijd, geografisch en binnen een Azure-regio op de volgende manieren geïmplementeerd:

• Azure Traffic Manager stuurt verkeer om voor de webservice en Azure Front Door stuurt verkeer om voor de gatewayservice. Als er een storing is waardoor de webservice of gatewayservice niet beschikbaar is vanuit één Azure-regio, of als er een volledige regiostoring is, wordt het verkeer omgeleid naar het dichtstbijzijnde beschikbare exemplaar in de dichtstbijzijnde regio. Door het verkeer om te leiden, kunnen gebruikers nog steeds nieuwe verbindingen maken.

• De geografische database maakt gebruik van Azure SQL Database-failover- en gegevensreplicatiemogelijkheden binnen elke geografie. Als er een databasestoring is, wordt er een failover uitgevoerd naar de secundaire replica en wordt de normale bewerking hervat. Tijdens de failover is er een korte periode waarin nieuwe verbindingen mislukken totdat de failover is voltooid, maar deze failover heeft geen invloed op bestaande verbindingen.

• De resourcemap, brokerservice, webservice en gatewayservice zijn allemaal beschikbaar in elk van de Azure-regio's waar de door Microsoft beheerde onderdelen voor Azure Virtual Desktop zich bevinden. Elk onderdeel heeft meerdere exemplaren, zodat er geen single point of failure is. Binnen elke Azure-regio zijn er ten minste zes afzonderlijke exemplaren of clusters van elk onderdeel die onafhankelijk van elkaar werken om exemplaarfouten te weerstaan.

  Een regio heeft bijvoorbeeld voldoende exemplaren van de gatewayservice om aan de vraag te voldoen, maar ook met voldoende capaciteit om ook fouten van die exemplaren op te vangen. Als een exemplaar van de gatewayservice mislukt, worden ALLE OP TCP gebaseerde RDP-verbindingen die worden doorgegeven via dat specifieke exemplaar van de gatewayservice verwijderd. Wanneer de niet-verbonden gebruikers opnieuw verbinding maken, verwerken de resterende exemplaren aanvragen en maken ze elke gebruiker opnieuw verbinding met hun bestaande sessie. Alle andere sessies die worden verwerkt door andere exemplaren van de gatewayservice, worden niet beïnvloed.

Hier volgt een diagram op hoog niveau dat laat zien hoe de door Microsoft beheerde onderdelen met elkaar zijn verbonden:

De andere Azure-services waarop Azure Virtual Desktop afhankelijk is, zijn zelf ontworpen om flexibel en betrouwbaar te zijn. Zie Azure Traffic Manager en Azure Front Door voor meer informatie.

Wereldwijd bereik

Azure Virtual Desktop is een service waarmee organisaties zich kunnen aanpassen aan de eisen van hun werknemers, met name op afstand werken. Het biedt een veilige, betrouwbare en flexibele manier om desktops en toepassingen vrijwel overal te leveren. Azure Virtual Desktop is ontworpen om flexibel te zijn, met behulp van Azure-functies en -services waarmee u een maximaal beschikbare service voor uw workloads kunt garanderen.

Hier volgt een kaart waarin het wereldwijde bereik van Azure Virtual Desktop wordt gedemonstreerd:

Verwante onderwerpen

Zie Gegevenslocaties voor Azure Virtual Desktop voor meer informatie over de locaties waarop Azure Virtual Desktop gegevens voor serviceobjecten heeft opgeslagen.