Herstel na noodgevallen van Azure Virtual Desktop

  • Artikel

Als u de gegevens van uw organisatie veilig wilt houden, moet u een BCDR-strategie (bedrijfscontinuïteit en herstel na noodgevallen) aannemen en beheren. Met een goede BCDR-strategie blijven uw apps en workloads actief tijdens geplande en ongeplande service- of Azure-storingen. Deze plannen moeten betrekking hebben op de sessiehost virtuele machines (VM's) die worden beheerd door klanten, in plaats van de Azure Virtual Desktop-service die wordt beheerd door Microsoft. Zie azure Virtual Desktop-concepten voor herstel na noodgevallen voor meer informatie over beheergebieden.

De Azure Virtual Desktop-service is ontworpen met hoge beschikbaarheid in het achterhoofd. Azure Virtual Desktop is een wereldwijde service die wordt beheerd door Microsoft, met meerdere exemplaren van de onafhankelijke onderdelen die zijn verdeeld over meerdere Azure-regio's. Als er een onverwachte storing optreedt in een van de onderdelen, wordt uw verkeer omgeleid naar een van de resterende exemplaren of zal Microsoft een volledige failover naar redundante infrastructuur in een andere Azure-regio initiëren.

Om ervoor te zorgen dat gebruikers nog steeds verbinding kunnen maken tijdens een regiostoring in sessiehost-VM's, moet u uw infrastructuur ontwerpen met hoge beschikbaarheid en herstel na noodgevallen. Een typisch plan voor herstel na noodgevallen omvat het repliceren van virtuele machines (VM's) naar een andere locatie. Tijdens storingen voert de primaire site een failover uit naar de gerepliceerde VM's op de secundaire locatie. Gebruikers kunnen zonder onderbreking toegang blijven krijgen tot apps vanaf de secundaire locatie. Boven op VM-replicatie moet u gebruikersidentiteiten toegankelijk houden op de secundaire locatie. Als u profielcontainers gebruikt, moet u ze ook repliceren. Zorg er ten slotte voor dat uw zakelijke apps die afhankelijk zijn van gegevens op de primaire locatie, een failover kunnen uitvoeren met de rest van de gegevens.

Als u wilt samenvatten dat uw gebruikers verbonden blijven tijdens een storing, moet u het volgende doen:

  • Repliceer de VM's naar een secundaire locatie.
  • Als u profielcontainers gebruikt, stelt u gegevensreplicatie in op de secundaire locatie.
  • Zorg ervoor dat gebruikersidentiteiten die u instelt op de primaire locatie beschikbaar zijn op de secundaire locatie. Zorg ervoor dat uw Active Directory-domein Controllers beschikbaar zijn op of vanaf de secundaire locatie om de beschikbaarheid te garanderen.
  • Zorg ervoor dat alle Line-Of-Business-toepassingen en -gegevens op uw primaire locatie ook worden overgeschakeld naar de secundaire locatie.

Plannen voor actief-passief en actief-actief herstel na noodgevallen

Er zijn twee verschillende soorten infrastructuur voor herstel na noodgevallen: actief-passief en actief-actief. Elk type infrastructuur werkt op een andere manier, dus laten we eens kijken wat deze verschillen zijn.

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 storing of noodgeval, kan de organisatie overschakelen naar de passieve regio door deze in te schakelen en alle gebruikers daar te leiden.

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.

Zie concepten voor herstel na noodgevallen van Azure Virtual Desktop voor meer informatie over typen noodherstelplannen die u kunt gebruiken.

Identificeren welke methode het beste werkt voor uw organisatie is het eerste wat u moet doen voordat u aan de slag gaat. Zodra u uw plan hebt ingesteld, kunt u beginnen met het bouwen van uw herstelplan.

VM-replicatie

Eerst moet u uw VM's repliceren naar de secundaire locatie. Uw opties hiervoor zijn afhankelijk van de configuratie van uw VM's:

  • U kunt replicatie configureren voor al uw VM's in zowel pool- als persoonlijke hostgroepen met Azure Site Recovery. Zie Azure-VM's repliceren naar een andere Azure-regio voor meer informatie over hoe dit proces werkt. Als u echter hostgroepen hebt gegroepeerd die u hebt gemaakt op basis van dezelfde installatiekopie en geen persoonlijke gebruikersgegevens lokaal hebt opgeslagen, kunt u ervoor kiezen deze niet te repliceren. In plaats daarvan hebt u de mogelijkheid om de VM's van tevoren te bouwen en ze uitgeschakeld te houden. U kunt er ook voor kiezen om alleen nieuwe VM's in te richten in de secundaire regio terwijl er zich een noodgeval voordoet. Als u deze methoden kiest, hoeft u slechts één hostgroep en de bijbehorende toepassingsgroepen en werkruimten in te stellen.
  • U kunt een nieuwe hostgroep maken in de failoverregio terwijl alle resources op uw failoverlocatie zijn uitgeschakeld. Voor deze methode moet u nieuwe toepassingsgroepen en werkruimten instellen in de failoverregio. U kunt vervolgens een Azure Site Recovery-plan gebruiken om hostgroepen in te schakelen.
  • U kunt een hostgroep maken die wordt gevuld door VM's die zijn gebouwd in zowel de primaire als de failoverregio, terwijl de VM's in de failoverregio uitgeschakeld blijven. In dit geval hoeft u slechts één hostgroep en de bijbehorende toepassingsgroepen en werkruimten in te stellen. U kunt een Azure Site Recovery-plan gebruiken om hostgroepen met deze methode in te schakelen.

U wordt aangeraden Azure Site Recovery te gebruiken voor het beheren van replicerende VM's naar andere Azure-locaties, zoals beschreven in de architectuur voor herstel na noodgevallen van Azure naar Azure. We raden u met name aan Om Azure Site Recovery te gebruiken voor persoonlijke hostgroepen, omdat persoonlijke hostgroepen doorgaans iets persoonlijks hebben voor hun gebruikers. Azure Site Recovery ondersteunt zowel server- als client-SKU's.

Als u Azure Site Recovery gebruikt, hoeft u deze VM's niet handmatig te registreren. De Azure Virtual Desktop-agent in de secundaire VM gebruikt automatisch het meest recente beveiligingstoken om verbinding te maken met het service-exemplaar dat zich het dichtst bij het service-exemplaar bevindt. De VM (sessiehost) op de secundaire locatie wordt automatisch onderdeel van de hostgroep. De eindgebruiker moet tijdens het proces opnieuw verbinding maken, maar daarnaast zijn er geen andere handmatige bewerkingen.

Als er bestaande gebruikersverbindingen zijn tijdens de storing, moet u de gebruikersverbindingen in de huidige regio beëindigen voordat de beheerder een failover naar de secundaire regio kan starten.

Als u gebruikers in Azure Virtual Desktop (klassiek) wilt loskoppelen, voert u deze cmdlet uit:

Invoke-RdsUserSessionLogoff

Voer deze cmdlet uit om de verbinding met gebruikers in Azure Virtual Desktop te verbreken:

Remove-AzWvdUserSession

Nadat u alle gebruikers in de primaire regio hebt afgemeld, kunt u een failover uitvoeren voor de VM's in de primaire regio en gebruikers verbinding laten maken met de VM's in de secundaire regio.

Virtueel netwerk

Houd vervolgens rekening met uw netwerkverbinding tijdens de storing. U moet ervoor zorgen dat u een virtueel netwerk (VNET) hebt ingesteld in uw secundaire regio. Als uw gebruikers toegang nodig hebben tot on-premises resources, moet u dit VNET configureren voor toegang tot deze resources. U kunt on-premises verbindingen tot stand brengen met een VPN, ExpressRoute of virtual WAN.

U wordt aangeraden Azure Site Recovery te gebruiken om het VNET in te stellen in de failoverregio, omdat het de instellingen van uw primaire netwerk behoudt en geen peering nodig heeft.

Gebruikersidentiteiten

Controleer vervolgens of de domeincontroller beschikbaar is op de secundaire locatie.

Er zijn drie manieren om de domeincontroller beschikbaar te houden:

  • Een of meer Active Directory-domein Controllers op de secundaire locatie hebben
  • Een on-premises Active Directory-domein controller gebruiken
  • Active Directory-domein-controller repliceren met behulp van Azure Site Recovery

Gebruikersprofielen

U wordt aangeraden FSLogix te gebruiken voor het beheren van gebruikersprofielen. Zie Opties voor bedrijfscontinuïteit en herstel na noodgevallen voor FSLogix voor meer informatie.

Een back-up maken van uw gegevens

U hebt ook de mogelijkheid om een back-up van uw gegevens te maken. U kunt een van de volgende methoden kiezen om een back-up te maken van uw Azure Virtual Desktop-gegevens:

  • Voor rekengegevens raden we u aan alleen een back-up te maken van persoonlijke hostpools met Azure Backup.
  • Voor opslaggegevens is het raadzaam om de back-upoplossing te gebruiken, afhankelijk van de back-endopslag die u hebt gebruikt voor het opslaan van gebruikersprofielen:

App-afhankelijkheden

Zorg er ten slotte voor dat zakelijke apps die afhankelijk zijn van gegevens in de primaire regio, een failover naar de secundaire locatie kunnen uitvoeren. Zorg er ook voor dat u de instellingen configureert die de apps nodig hebben om op de nieuwe locatie te werken. Als een van de apps bijvoorbeeld afhankelijk is van de SQL-back-end, moet u SQL repliceren op de secundaire locatie. U moet de app configureren voor gebruik van de secundaire locatie als onderdeel van het failoverproces of als de standaardconfiguratie. U kunt app-afhankelijkheden modelleren op Azure Site Recovery-plannen. Zie Voor meer informatie over herstelplannen.

Tests voor herstel na noodgevallen

Nadat u klaar bent met het instellen van herstel na noodgevallen, moet u uw plan testen om er zeker van te zijn dat het werkt.

Hier volgen enkele suggesties voor het testen van uw plan:

  • Als de test-VM's internettoegang hebben, nemen ze een bestaande sessiehost over voor nieuwe verbindingen, maar blijven alle bestaande verbindingen met de oorspronkelijke sessiehost actief. Zorg ervoor dat de beheerder die de test uitvoert, alle actieve gebruikers afmeldt voordat u het plan test.
  • U moet alleen volledige hersteltests uitvoeren tijdens een onderhoudsvenster om uw gebruikers niet te verstoren.
  • Zorg ervoor dat uw test alle bedrijfskritieke toepassingen en gegevens omvat.
  • U wordt aangeraden maximaal 100 VM's tegelijk te failovern. Als u meer VM's hebt dan dat, raden we u aan om een failover uit te voeren in batches van 10 minuten.

Volgende stappen

Als u vragen hebt over het beveiligen van uw gegevens naast het plannen van storingen, raadpleegt u onze beveiligingshandleiding.