VM's beveiligen die zijn geïmplementeerd op Azure Stack Hub
Gebruik dit artikel als richtlijn bij het ontwikkelen van een strategie voor gegevensbescherming en herstel na noodherstel voor door de gebruiker geïmplementeerde virtuele IaaS-machines (VM's) die zijn geïmplementeerd op Azure Stack Hub.
Ter bescherming tegen gegevensverlies en uitgebreide downtime implementeert u een plan voor back-upherstel of herstel na noodherstel voor gebruikerstoepassingen en hun gegevens. Elke toepassing moet worden geëvalueerd als onderdeel van de uitgebreide strategie voor bedrijfscontinuïteit en herstel na noodherstel (BC/DR) van uw organisatie. Een goed uitgangspunt is Azure Stack Hub : Overwegingen voor bedrijfscontinuïteit en herstel na noodherstel.
Overwegingen voor het beveiligen van IaaS-VM's
Rollen en verantwoordelijkheden
Zorg er eerst voor dat er een duidelijk inzicht is in de rollen en verantwoordelijkheden die zijn toegeschreven aan toepassingseigenaren en -operators in de context van beveiliging en herstel.
Gebruikers zijn verantwoordelijk voor het beveiligen van VM's. Operators zijn verantwoordelijk voor het online Azure Stack Hub en in orde houden. Azure Stack Hub omvat een service die back-up maakt van interne servicegegevens van infrastructuurservices en geen gebruikersgegevens bevat, waaronder door de gebruiker gemaakte VM's, opslagaccounts met gebruikers- of toepassingsgegevens of gebruikersdatabases.
| Toepassingseigenaar/architect | Azure Stack Hub operator |
|---|---|
|
|
Combinaties van bron/doel
Gebruikers die zich moeten beveiligen tegen een datacenter of sitestoring, kunnen een andere Azure Stack Hub of Azure gebruiken om hoge beschikbaarheid of snel herstel te bieden. Met de primaire en secundaire locatie kunnen gebruikers toepassingen implementeren in een actief/actief of actief/passief-configuratie in twee omgevingen. Voor minder kritieke workloads kunnen gebruikers capaciteit op de secundaire locatie gebruiken om toepassingen op aanvraag te herstellen vanuit een back-up.
Een of meer Azure Stack Hub clouds kunnen worden geïmplementeerd in een datacenter. Om een onherstelbare ramp te overleven, zorgt de implementatie van ten minste één Azure Stack Hub cloud in een ander datacenter ervoor dat u fail over workloads kunt uitvoeren en ongeplande downtime kunt minimaliseren. Als u slechts één cloud Azure Stack Hub, kunt u overwegen om de openbare Azure-cloud te gebruiken als uw herstelcloud. De beslissing waar uw toepassing kan worden uitgevoerd, wordt bepaald door overheidsvoorschriften, bedrijfsbeleid en strenge latentievereisten. U hebt de flexibiliteit om per toepassing de juiste herstellocatie te bepalen. U kunt bijvoorbeeld toepassingen in het ene abonnement hebben die back-up maken van gegevens naar een ander datacenter en in een ander abonnement, door gegevens te repliceren naar de openbare Azure-cloud.
Doelstellingen voor toepassingsherstel
Toepassingseigenaren zijn voornamelijk verantwoordelijk voor het bepalen van de hoeveelheid downtime en gegevensverlies die de toepassing en de organisatie kunnen tolereren. Door acceptabele downtime en acceptabel gegevensverlies te kwantificeren, kunt u een herstelplan maken dat de impact van een noodherstel op uw organisatie minimaliseert. Houd voor elke toepassing rekening met het volgende:
- Beoogde hersteltijd (RTO)
RTO is de maximaal acceptabele tijd dat een app niet beschikbaar kan zijn na een incident. Een RTO van 90 minuten betekent bijvoorbeeld dat u de app binnen 90 minuten na het begin van een noodherstel moet kunnen herstellen naar een status die wordt uitgevoerd. Als u een lage RTO hebt, kunt u een tweede implementatie continu stand-by houden om u te beschermen tegen regionale uitval. - Recovery Point Objective (RPO)
RPO is de maximale duur dat gegevensverlies acceptabel is tijdens een noodgeval. Als u bijvoorbeeld gegevens opgeslagen in één database waarvan elk uur een back-up wordt gemaakt en die geen replicatie naar andere databases heeft, kunt u maximaal een uur aan gegevens verliezen.
Een andere metrische waarde is Gemiddelde tijd om te herstellen (MTTR), de gemiddelde tijd die nodig is om de toepassing te herstellen na een fout. MTTR is een empirische waarde voor een systeem. Als MTTR de RTO overschrijdt, veroorzaakt een fout in het systeem een onacceptabele bedrijfsonderbreking, omdat het niet mogelijk is om het systeem te herstellen binnen de gedefinieerde RTO.
Beveiligingsopties
Back-up terugzetten
Door een back-up te maken van uw toepassingen en gegevenssets, kunt u snel herstellen van downtime vanwege beschadiging van gegevens, onbedoelde verwijderingen of noodvallen. Voor IaaS-VM-toepassingen kunt u een in-guest agent gebruiken om toepassingsgegevens, besturingssysteemconfiguratie en gegevens die zijn opgeslagen op volumes te beveiligen.
Back-up maken met behulp van een gastagent
Het maken van een back-up van een VM met behulp van een gastbesturingssysteemagent omvat doorgaans het vastleggen van besturingssysteemconfiguratie, bestanden/mappen, schijven, binaire bestanden van toepassingen of toepassingsgegevens.
Als u een toepassing van een agent wilt herstellen, moet u de VM handmatig opnieuw maken, het besturingssysteem installeren en de gastagent installeren. Op dat moment kunnen gegevens worden hersteld in het gast-besturingssysteem of rechtstreeks naar de toepassing.
Back-up maken met schijfmomentopname voor gestopte VM's
Back-upproducten kunnen de configuratie van IaaS-VM's en schijven die zijn gekoppeld aan een gestopte VM beveiligen. Gebruik back-upproducten die zijn geïntegreerd met Azure Stack Hub API's om VM-configuratie vast te leggen en momentopnamen van schijven te maken. Als geplande downtime voor de toepassing mogelijk is, moet u ervoor zorgen dat de VM is gestopt voordat u de back-upwerkstroom start.
Back-up maken met schijfmomentopname voor het uitvoeren van VM's
Belangrijk
Het gebruik van schijfmomentopnamen wordt momenteel niet ondersteund voor VM's die actief zijn. Het maken van een momentopname van een schijf die is gekoppeld aan een virtuele harde schijf, kan de prestaties verslechteren of invloed hebben op de beschikbaarheid van het besturingssysteem of de toepassing in de VM. Het wordt aanbevolen om een in-guest agent te gebruiken om de toepassing te beveiligen als geplande downtime geen optie is.
VM's in een schaalset of beschikbaarheidsset
Van VM's in een schaalset of beschikbaarheidsgroep die als kortstondige resources worden beschouwd, mag geen back-up worden gemaakt op VM-niveau, met name als de toepassing staatloos is. Voor stateful toepassingen die zijn geïmplementeerd in een schaalset of beschikbaarheidsset, kunt u de toepassingsgegevens beveiligen (bijvoorbeeld een database of volume in een opslaggroep).
Replicatie/handmatige failover
Voor toepassingen waarvoor minimaal gegevensverlies of minimale downtime is vereist, kan gegevensreplicatie worden ingeschakeld op het niveau van het gastbesturingssysteem of de toepassing om gegevens naar een andere locatie te repliceren. Sommige toepassingen, zoals Microsoft SQL Server, bieden standaard ondersteuning voor replicatie. Als de toepassing geen ondersteuning biedt voor replicatie, kunt u software in het gastbesturingssysteem gebruiken om schijven te repliceren of een partneroplossing die als agent in het gastbesturingssysteem wordt geïnstalleerd.
Met deze methode wordt de toepassing geïmplementeerd in de ene cloud en worden de gegevens gerepliceerd naar de andere on-premises cloud of naar Azure. Wanneer een failover wordt geactiveerd, moet de toepassing in het doel worden gestart en gekoppeld aan de gerepliceerde gegevens voordat deze serviceaanvragen kan starten.
Hoge beschikbaarheid/automatische failover
Voor staatloze toepassingen die slechts enkele seconden of minuten downtime kunnen tolereren, kunt u een configuratie met hoge beschikbaarheid overwegen. Toepassingen met hoge beschikbaarheid zijn ontworpen om te worden geïmplementeerd op meerdere locaties in een actief/actief-topologie waar alle exemplaren aanvragen kunnen verwerken. Voor lokale hardwarefouten implementeert de Azure Stack Hub hoge beschikbaarheid in het fysieke netwerk met behulp van twee top-of-rack-switches. Bij fouten op rekenniveau gebruikt Azure Stack Hub meerdere knooppunten in een schaaleenheid en wordt er automatisch een failover van een VM gemaakt. Op VM-niveau kunt u schaalsets of VM's in een beschikbaarheidsset gebruiken om ervoor te zorgen dat knooppuntfouten uw toepassing niet plat maken. Dezelfde toepassing moet worden geïmplementeerd op een secundaire locatie in dezelfde configuratie. Om de toepassing actief/actief te maken, kan een load balancer of DNS worden gebruikt om aanvragen naar alle beschikbare exemplaren te sturen.
Geen herstel
Sommige apps in uw omgeving hebben mogelijk geen bescherming nodig tegen ongeplande downtime of gegevensverlies. VM's die worden gebruikt voor ontwikkeling en testen hoeven bijvoorbeeld doorgaans niet te worden hersteld. Het is uw beslissing om te doen zonder beveiliging voor een toepassing of gegevensset.
Aanbevolen topologies
Belangrijke overwegingen voor uw Azure Stack Hub implementatie:
| Aanbeveling | Opmerkingen | |
|---|---|---|
| Back-up maken van VM's of deze herstellen naar een extern back-updoel dat al is geïmplementeerd in uw datacenter | Aanbevolen | Profiteer van bestaande back-upinfrastructuur en operationele vaardigheden. Zorg ervoor dat de grootte van de back-upinfrastructuur zo is dat deze klaar is om de extra VM-exemplaren te beveiligen. Zorg ervoor dat de back-upinfrastructuur zich niet in de buurt van uw bron bevinden. U kunt VM's herstellen naar de Azure Stack Hub, naar een secundair Azure Stack Hub-exemplaar of Azure. |
| VM's back-ups maken/herstellen naar een extern back-updoel dat is toegewezen aan Azure Stack Hub | Aanbevolen | U kunt een nieuwe back-upinfrastructuur aanschaffen of een toegewezen back-upinfrastructuur inrichten voor Azure Stack Hub. Zorg ervoor dat de back-upinfrastructuur zich niet in de buurt van uw bron bevinden. U kunt VM's herstellen naar de Azure Stack Hub, naar een secundair Azure Stack Hub-exemplaar of Azure. |
| Een back-up maken van VM's of deze rechtstreeks herstellen naar azure wereldwijd of een vertrouwde serviceprovider | Aanbevolen | Zolang u kunt voldoen aan de privacy- en regelgevingsvereisten voor uw gegevens, kunt u uw back-ups opslaan in Azure of een vertrouwde serviceprovider. In het ideale moment wordt de serviceprovider ook Azure Stack Hub zodat u consistentie krijgt in de operationele ervaring wanneer u herstelt. |
| Virtuele VM's repliceren/failovers naar een Azure Stack Hub exemplaar | Aanbevolen | In het geval van een failover moet u een tweede Azure Stack Hub cloud volledig operationeel hebben, zodat u uitgebreide app-downtime kunt voorkomen. |
| Virtuele VM's rechtstreeks repliceren/failovers uitvoeren naar Azure of een vertrouwde serviceprovider | Aanbevolen | Zolang u kunt voldoen aan de privacy- en regelgevingsvereisten voor uw gegevens, kunt u uw gegevens repliceren naar globale Azure of een vertrouwde serviceprovider. In het ideale moment wordt de serviceprovider ook Azure Stack Hub zodat u consistentie krijgt in de operationele ervaring na een failover. |
| Implementeer een back-updoel op dezelfde Azure Stack Hub die ook alle toepassingen host die door hetzelfde back-updoel worden beveiligd. | Stand-alone doel: Niet aanbevolen Doel dat back-upgegevens extern repliceert: aanbevolen | Als u ervoor kiest om een back-upapparaat te implementeren op Azure Stack Hub (om operationeel herstel te optimaliseren), moet u ervoor zorgen dat alle gegevens continu worden gekopieerd naar een externe back-uplocatie. |
| Fysiek back-upapparaat implementeren in hetzelfde rek waar de Azure Stack Hub is geïnstalleerd | Niet ondersteund | Op dit moment kunt u geen andere apparaten verbinden met de bovenkant van rackswitches die geen deel uitmaken van de oorspronkelijke oplossing. |
Overwegingen voor een herstelde IaaS-VM
U moet enkele wijzigingen aanbrengen in uw virtuele machine nadat u de machine vanuit een back-up hebt hersteld. Deze omvatten:
- MAC-adres
De virtuele netwerkadapter krijgt een nieuw MAC-adres. Er is geen methode om het oorspronkelijke MAC-adres te behouden. - IP-adres
Als uw virtuele machine intern een statisch IP-adres heeft ingesteld, kan het interne IP-adres op de virtuele netwerkadapter worden ingesteld op het oorspronkelijke IP-adres. Mogelijk moet u overwegen of het VNET een S2S VPN heeft naar een externe omgeving waar het IP-adres mogelijk wordt gebruikt. - Onnodige artefacten
Als er een back-up van de VM is gemaakt op een ander platform, zoals VMware vSphere, moet u een aantal extra stappen volgen om alle onnodige artefacten uit de bron op te schonen.
Volgende stappen
Dit artikel heeft algemene richtlijnen gegeven voor het beveiligen van gebruikers-VM's die zijn geïmplementeerd op Azure Stack Hub. Voor informatie over het gebruik van Azure-services voor het beveiligen van gebruikers-VM's raadpleegt u:
- Azure Stack IaaS - deel vier - Uw zaken beveiligen
- Considerations for business continuity and disaster recovery (Overwegingen voor bedrijfscontinuïteit en herstel na noodgevallen)
Azure Backup-server
- Gebruik Azure Backup back-up te maken van bestanden en apps op Azure Stack Hub
- Azure Backup Server ondersteuning voor Azure Stack Hub