Azure Virtual Desktop-servicearchitectuur en -tolerantie

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

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 de RDP-connectiviteit (Remote Desktop Protocol) biedt vanaf het apparaat van een gebruiker waar ze verbinding maken met de sessiehosts die hun bureaubladen en apps leveren.
• Resourcemap: biedt informatie voor het instrueren van de webservice die van de meerdere geografische databases als host fungeert voor de verbindingsgegevens die vereist zijn voor elke gebruiker.
• Geografische database: bevat de verbindingsbestanden (.rdp) en pictogrammen voor elke resource die een gebruiker heeft ingericht.

Daarnaast maakt Azure Virtual Desktop gebruik van andere globale 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, inclusief aanpassingen van installatiekopieën van besturingssystemen en toepassingen, connectiviteit van virtuele netwerken, de tolerantie en het maken en herstellen van deze sessiehosts. U geeft en beheert ook gebruikersidentiteiten en beheert de toegang tot de service. U kunt andere Azure-services gebruiken om te voldoen aan uw vereisten, zoals:

• Azure-beschikbaarheidszones om uw sessiehosts te distribueren over fysiek afzonderlijke datacenterlocaties binnen een Azure-regio, elk met onafhankelijke voeding, koeling en netwerken.
• Azure Backup om een back-up te maken van uw sessiehosts en deze 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 zijn of haar bureaubladen en apps in Azure Virtual Desktop, zijn er meerdere onderdelen betrokken bij het maken van die verbinding. 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 Remote Desktop Protocol met een sessiehost.

Feeddetectie

Tijdens de detectie van feeds 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 kan zich overal ter wereld bevinden. 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 Broker-service 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 met het feeddetectieproces in één Azure-regio:

   

   De geografische database bevat alleen de informatie die vereist is voor desktops en apps uit hostgroepen in dezelfde Azure-regio's die onder de geografie vallen. Als de gebruiker is toegewezen aan desktops of apps vanuit 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 verbinding maakt met een bureaublad of app vanuit de feed, wordt de RDP-verbinding als volgt tot stand gebracht:

1. Alle externe sessies beginnen met een verbinding met Azure Front Door, dat het globale toegangspunt biedt voor Azure Virtual Desktop. 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 de verbinding 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 om verbinding te maken met dezelfde gatewayservice die het apparaat van de gebruiker heeft verbonden.

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

   1. Transport van omgekeerde verbinding: nadat zowel de client- als sessiehost die is verbonden met de gatewayservice, wordt het RDP-verkeer via Transmission Control Protocol (TCP) tussen de client en sessiehost doorgegeven. Reverse connect transport is het standaardverbindingstype.

   2. RDP Shortpath: er wordt een direct 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 Understanding Azure Virtual Desktop network connectivity and RDP Shortpath for Azure Virtual Desktop.

Servicetolerantie

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

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

• Azure Traffic Manager leidt verkeer voor de webservice en Azure Front Door leidt verkeer voor de gatewayservice door. Als er een storing optreedt waardoor de webservice of gatewayservice niet beschikbaar is vanuit één Azure-regio of als er een volledige regiostoring is, wordt verkeer omgeleid naar het dichtstbijzijnde beschikbare exemplaar in de dichtstbijzijnde regio. Door het verkeer omleiden 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 van de database 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 elke Azure-regio waarin 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 en afzonderlijke exemplaren of clusters van elk onderdeel dat onafhankelijk werkt om fouten in instanties 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 deze exemplaren aan te kunnen. Als een exemplaar van de gatewayservice mislukt, worden eventuele RDP-verbindingen op basis van TCP die via dat specifieke exemplaar van de gatewayservice worden doorgestuurd, verwijderd. Wanneer deze niet-verbonden gebruikers opnieuw verbinding maken, verwerken de resterende exemplaren aanvragen en verbinden ze elke gebruiker opnieuw 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 waarin wordt getoond hoe de door Microsoft beheerde onderdelen onderling zijn verbonden:

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

Globaal bereik

Azure Virtual Desktop is een service waarmee organisaties zich kunnen aanpassen aan de vereisten 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 tolerant te zijn, met behulp van Azure-functies en -services die zorgen voor een maximaal beschikbare service voor uw workloads.

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

Gerelateerde inhoud

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