Concepten voor herstel na noodgevallen van Azure Virtual Desktop

Artikel
10/18/2023

Azure Virtual Desktop is de afgelopen jaren enorm gegroeid als een externe en hybride werkoplossing. Omdat zoveel gebruikers nu op afstand werken, vereisen organisaties oplossingen met hoge implementatiesnelheid en lagere kosten. Gebruikers moeten ook een externe werkomgeving hebben met gegarandeerde beschikbaarheid en tolerantie waarmee ze zelfs tijdens noodgevallen toegang hebben tot hun virtuele machines. In dit document worden plannen voor herstel na noodgevallen beschreven die u kunt aanbevelen om uw organisatie actief te houden.

Om systeemstoringen of downtime te voorkomen, moeten elk systeem en onderdeel in uw Azure Virtual Desktop-implementatie fouttolerant zijn. Fouttolerantie is wanneer u een dubbele configuratie of systeem in een andere Azure-regio hebt die tijdens een storing de hoofdconfiguratie overneemt. Deze secundaire configuratie of het systeem vermindert de impact van een gelokaliseerde storing. Er zijn veel manieren waarop u fouttolerantie kunt instellen, maar dit artikel richt zich op de methoden die momenteel beschikbaar zijn in Azure.

Azure Virtual Desktop-infrastructuur

Om erachter te komen welke gebieden fouttolerant moeten worden, moeten we eerst weten wie verantwoordelijk is voor het onderhouden van elk gebied. U kunt de verantwoordelijkheid in de Azure Virtual Desktop-service verdelen in twee gebieden: door Microsoft beheerd en door de klant beheerd. Metagegevens zoals de hostgroepen, toepassingsgroepen en werkruimten worden beheerd door Microsoft. De metagegevens zijn altijd beschikbaar en vereisen geen extra instellingen door de klant om hostgroepgegevens of configuraties te repliceren. We hebben de gatewayinfrastructuur ontworpen die mensen verbindt met hun sessiehosts om een wereldwijde, zeer tolerante service te zijn die wordt beheerd door Microsoft. Ondertussen omvatten door de klant beheerde gebieden de virtuele machines (VM's) die worden gebruikt in Azure Virtual Desktop en de instellingen en configuraties die uniek zijn voor de implementatie van de klant. De volgende tabel geeft een duidelijker beeld van welke gebieden worden beheerd door welke partij.

Beheerd door Microsoft	Beheerd door klant
Load balancer	Netwerk
Sessiebroker	Sessiehosts
Gateway	Storage
Diagnostiek	Gebruikersprofielgegevens
Cloud identity platform	Identiteit

In dit artikel richten we ons op door de klant beheerde onderdelen, omdat dit instellingen zijn die u zelf kunt configureren.

Basisbeginselen van herstel na noodgevallen

In deze sectie bespreken we acties en ontwerpprincipes die uw gegevens kunnen beschermen en voorkomen dat er grote inspanningen worden geleverd om gegevens te herstellen na kleine storingen of volledige rampen. Voor kleinere storingen kan het volgen van bepaalde kleinere stappen helpen voorkomen dat ze grotere rampen worden. Laten we enkele basistermen bekijken die u helpen bij het instellen van uw plan voor herstel na noodgevallen.

Wanneer u een plan voor herstel na noodgevallen ontwerpt, moet u rekening houden met de volgende drie dingen:

Hoge beschikbaarheid: het distribueren van infrastructuur zodat kleinere, gelokaliseerde storingen uw hele implementatie niet onderbreken. Ontwerpen met hoge beschikbaarheid kan de impact van storingen minimaliseren en voorkomen dat een volledig herstel na noodgevallen nodig is.
Bedrijfscontinuïteit: hoe een organisatie kan blijven werken tijdens storingen van elke grootte.
Herstel na noodgeval: het proces van teruggaan naar de bewerking na een volledige storing.

Azure heeft veel ingebouwde, gratis functies die hoge beschikbaarheid op veel niveaus kunnen bieden. De eerste functie is beschikbaarheidssets, die VM's distribueren over verschillende fout- en updatedomeinen in Azure. Vervolgens zijn beschikbaarheidszones, die fysiek zijn geïsoleerd en geografisch gedistribueerde groepen datacenters die de impact van een storing kunnen verminderen. Ten slotte biedt het distribueren van sessiehosts in meerdere Azure-regio's nog meer geografische distributie, waardoor de impact van storingen verder wordt verminderd. Alle drie de functies bieden een bepaald beschermingsniveau binnen Azure Virtual Desktop. Houd er rekening mee dat u deze functies zorgvuldig moet overwegen, samen met eventuele gevolgen voor de kosten.

In principe is de strategie voor herstel na noodgevallen die we aanbevelen voor Azure Virtual Desktop het implementeren van resources in meerdere beschikbaarheidszones binnen een regio. Als u meer beveiliging nodig hebt, kunt u ook resources implementeren in meerdere gekoppelde Azure-regio's.

Actief-passieve en actief-actieve implementaties

Iets anders waar u rekening mee moet houden, is het verschil tussen actief-passief- en actief-actief-abonnementen. Actief-passieve plannen zijn wanneer u een regio hebt met één set resources die actief is en een regio die is uitgeschakeld totdat deze nodig is (passief). Als de actieve regio offline wordt gehaald door een noodgeval, kan de organisatie overschakelen naar de passieve regio door deze in te schakelen en al hun gebruikers daar te verplaatsen.

Een andere optie is een actief-actieve implementatie, waarbij u beide sets infrastructuur tegelijk gebruikt. Hoewel sommige gebruikers mogelijk worden beïnvloed door storingen, is de impact beperkt tot de gebruikers in de regio die zijn uitgegaan. Gebruikers in de andere regio die nog steeds online zijn, worden niet beïnvloed en het herstel is beperkt tot de gebruikers in de betrokken regio die opnieuw verbinding maken met de werkende actieve regio. Actief-actieve implementaties kunnen vele vormen aannemen, waaronder:

Overprovisioning infrastructuur in elke regio voor getroffen gebruikers in het geval een van de regio's uitvalt. Een potentieel nadeel van deze methode is dat het onderhouden van de extra resources meer kost.
Extra sessiehosts in beide actieve regio's hebben, maar de toewijzing ervan ongedaan maken wanneer ze niet nodig zijn, waardoor de kosten worden verlaagd.
Alleen nieuwe infrastructuur inrichten tijdens herstel na noodgevallen en toestaan dat betrokken gebruikers verbinding maken met de zojuist ingerichte sessiehosts. Deze methode vereist regelmatig testen met hulpprogramma's voor infrastructuur als code, zodat u de nieuwe infrastructuur zo snel mogelijk kunt implementeren tijdens een noodgeval.

Aanbevolen methoden voor herstel na noodgevallen

De aanbevolen methoden voor herstel na noodgevallen zijn:

Azure-resources configureren en implementeren in meerdere beschikbaarheidszones.
Configureer en implementeer Azure-resources in meerdere regio's in actief-actief- of actief-passieve configuraties. Deze configuraties worden doorgaans gevonden in gedeelde hostgroepen.
Voor persoonlijke hostgroepen met toegewezen VM's repliceert u VM's met Behulp van Azure Site Recovery naar een andere regio.
Configureer een afzonderlijke hostgroep voor herstel na noodgevallen in de secundaire regio. Tijdens een noodgeval kunt u gebruikers overschakelen naar de secundaire regio.

In de volgende secties gaan we dieper in op de twee belangrijkste methoden waarmee u deze methoden kunt bereiken voor gedeelde en persoonlijke hostgroepen.

Herstel na noodgevallen voor gedeelde hostgroepen

In deze sectie bespreken we gedeelde (of gegroepeerde) hostgroepen met behulp van een actief-passieve benadering. De actief-passieve benadering is wanneer u bestaande resources opsplitst in een primaire en secundaire regio. Normaal gesproken doet uw organisatie al zijn werk in de primaire (of 'actieve') regio, maar tijdens een noodgeval hoeft u alleen maar over te schakelen naar de secundaire (of passieve) regio om de resources in de primaire regio uit te schakelen (als u dit kunt doen, afhankelijk van de omvang van de storing) en de resources in te schakelen in de secundaire regio.

In het volgende diagram ziet u een voorbeeld van een implementatie met redundante infrastructuur in een secundaire regio. 'Redundant' betekent dat een kopie van de oorspronkelijke infrastructuur in deze andere regio bestaat en standaard is in implementaties om tolerantie voor alle onderdelen te bieden. Onder één Microsoft Entra-id bevinden zich twee regio's: VS - west en VS - oost. Elke regio heeft twee sessiehosts waarop een besturingssysteem met meerdere sessies wordt uitgevoerd, een server met Microsoft Entra Verbinding maken, een Active Directory-domein Controller, een Azure Files Premium-bestandsshare voor FSLogix-profielen, een opslagaccount en een virtueel netwerk (VNET). In de primaire regio, VS - west, worden alle resources ingeschakeld. In de secundaire regio, VS - oost, worden de sessiehosts in de hostgroep uitgeschakeld of in de afvoermodus en bevindt de Microsoft Entra-Verbinding maken-server zich in de faseringsmodus. De twee VNET's in beide regio's zijn verbonden door peering.

A diagram of a deployment using the recommended shared host pool disaster recovery strategy described in the previous paragraph.

In de meeste gevallen, als een onderdeel mislukt of de primaire regio niet beschikbaar is, is de enige actie die de klant moet uitvoeren, de hosts inschakelen of de afvoermodus in de secundaire regio verwijderen om verbindingen van eindgebruikers mogelijk te maken. Dit scenario is gericht op het verminderen van downtime. Een noodherstelplan op basis van redundantie kan echter meer kosten omdat deze extra onderdelen in de secundaire regio moeten worden onderhouden.

De mogelijke voordelen van dit plan zijn als volgt:

Minder tijd besteed aan het herstellen van rampen. U besteedt bijvoorbeeld minder tijd aan het inrichten, configureren, integreren en valideren van nieuw geïmplementeerde resources.
Het is niet nodig om ingewikkelde procedures te gebruiken.
Het is eenvoudig om failover te testen buiten noodgevallen.

De mogelijke nadelen zijn als volgt:

Het kan duurder zijn omdat er meer infrastructuur nodig is om te onderhouden, zoals opslagaccounts, hosts, enzovoort.
U moet meer tijd besteden aan het configureren van uw implementatie om tegemoet te komen aan dit plan.
U moet de extra infrastructuur onderhouden die u instelt, zelfs wanneer u deze niet nodig hebt.

Belangrijke informatie voor herstel van gedeelde hostgroepen

Wanneer u deze strategie voor herstel na noodgevallen gebruikt, is het belangrijk om rekening te houden met het volgende:

Het online hebben van meerdere sessiehosts in veel regio's kan van invloed zijn op de gebruikerservaring. De load balancer van het beheerde netwerk houdt geen rekening met geografische nabijheid, maar behandelt alle hosts in een hostgroep evenzeer.
Tijdens een noodgeval maken gebruikers nieuwe profielen in de secundaire regio. U moet bedrijfs- of bedrijfskritieke gegevens opslaan in OneDrive (met behulp van bekende mapomleiding) of Sharepoint. Door hier gegevens op te slaan, hebben gebruikers snel toegang tot hun toepassingen met een kleine onderbreking van de gebruikerservaring.
Zorg ervoor dat u uw virtuele machines (VM's) op exact dezelfde manier configureert binnen uw hostgroep. Zorg er ook voor dat alle VM's in uw hostgroep dezelfde grootte hebben. Als uw VM's niet hetzelfde zijn, verdeelt de load balancer van het beheerde netwerk gebruikersverbindingen gelijkmatig over alle beschikbare VM's. De kleinere VM's worden mogelijk eerder beperkt dan verwacht in vergelijking met grotere VM's, wat resulteert in een negatieve gebruikerservaring.
Beschikbaarheid van regio's is van invloed op gegevens- of werkruimtebewaking. Als een regio niet beschikbaar is, verliest de service mogelijk alle historische bewakingsgegevens tijdens een noodgeval. U wordt aangeraden een aangepaste export of dump van historische bewakingsgegevens te gebruiken.
U wordt aangeraden uw sessiehosts minstens één keer per maand bij te werken. Deze aanbeveling is van toepassing op sessiehosts die u gedurende langere tijd uitgeschakeld houdt.
Test uw implementatie door minstens één keer per zes maanden een gecontroleerde failover uit te voeren. Een deel van de beheerde failover kan betekenen dat uw secundaire locatie primair wordt tot de volgende beheerde failover. Als u uw secundaire locatie wijzigt in primaire locatie, kunnen gebruikers bijna identieke profielen hebben tijdens een echte ramp.

De volgende tabel bevat aanbevelingen voor implementatie voor strategieën voor herstel na noodgevallen van hostgroepen:

Technologie	Aanbevelingen
Netwerk	Maak en implementeer een secundair virtueel netwerk in een andere regio en configureer Azure-peering met uw primaire virtuele netwerk.
Sessiehosts	Maak en implementeer een gedeelde hostgroep van Azure Virtual Desktop met SKU voor meerdere sessies en neem VM's op uit andere beschikbaarheidszones en een andere regio.
Storage	Maak opslagaccounts in meerdere regio's met behulp van premium-laag-accounts.
Gebruikersprofielgegevens	SMB-opslaglocaties maken in meerdere regio's.
Identiteit	Active Directory-domein Controllers uit dezelfde map.

Herstel na noodgevallen voor persoonlijke hostgroepen

Voor persoonlijke hostgroepen moet uw strategie voor herstel na noodgevallen betrekking hebben op het repliceren van uw resources naar een secundaire regio met behulp van Azure Site Recovery Services Vault. Als uw primaire regio uitvalt tijdens een noodgeval, kan Azure Site Recovery een failover uitvoeren en de resources in uw secundaire regio inschakelen.

Stel dat we een implementatie hebben met een primaire regio in de VS - west en een secundaire regio in VS - oost. De primaire regio heeft een persoonlijke hostgroep met elk twee sessiehosts. Elke sessiehost heeft een eigen lokale schijf met de gebruikersprofielgegevens en hun eigen VNET dat niet is gekoppeld aan iets. Als er zich een noodgeval voordoet, kunt u Azure Site Recovery gebruiken om een failover uit te voeren naar de secundaire regio in VS - oost (of naar een andere beschikbaarheidszone in dezelfde regio). In tegenstelling tot de primaire regio heeft de secundaire regio geen lokale machines of schijven. Tijdens de failover neemt Azure Site Recovery de gerepliceerde gegevens uit de Azure Site Recovery-kluis en gebruikt deze om twee nieuwe VM's te maken die kopieën zijn van de oorspronkelijke sessiehosts, inclusief de lokale schijf en gebruikersprofielgegevens. De secundaire regio heeft een eigen onafhankelijk VNET, dus het VNET dat offline gaat in de primaire regio, heeft geen invloed op de functionaliteit.

In het volgende diagram ziet u de voorbeeldimplementatie die we zojuist hebben beschreven.

A diagram of a deployment using the recommended personal host pool disaster recovery strategy described in the previous paragraph.

De voordelen van dit plan zijn een lagere totale kosten en vereisen geen onderhoud om te patchen of bij te werken omdat resources alleen worden ingericht wanneer u ze nodig hebt. Een potentieel nadeel is echter dat u meer tijd besteedt aan het inrichten, integreren en valideren van de failover-infrastructuur dan bij het instellen van herstel na noodgevallen voor een gedeelde hostgroep.

Belangrijke informatie over herstel van persoonlijke hostgroepen