Een plan ontwikkelen voor bedrijfscontinuïteit en herstel na noodgevallen
Uw organisatie wilt dat u een siteherstelstrategie voor uw toepassingen ontwikkelt. Eerst moet u inzicht hebben in de specifieke vereisten voor het bouwen van siteherstel voor uw hybride omgeving. U moet ook begrijpen welke hulpprogramma's beschikbaar zijn in Azure om u te helpen.
In deze les leert u hoe u belangrijke infrastructuren, beoogde hersteltijd (RPO's) en beoogde herstelpunten (RPO's) kunt identificeren. U leert welke vereisten relevant kunnen zijn voor paaS-services (Platform as a Service) die u mogelijk gebruikt. U leert ook hoe u een back-up en herstel na noodgevallen kunt plannen. Ten slotte ontdekt u enkele van de Azure-functies waarmee u een sitehersteloplossing kunt bouwen.
Bedrijfscontinuïteit en herstel na noodgevallen
U moet een BCDR-plan ontwikkelen om een geschikte sitehersteloplossing te ontwerpen. BCDR verwijst naar een proces waarmee u uw toepassingen na een belangrijke gebeurtenis kunt herstellen naar een functionele status. Deze gebeurtenis kan een natuurramp zijn, zoals een aardbeving. Het kan ook technisch van aard zijn, zoals het verwijderen van een database. Deze gebeurtenissen zijn doorgaans breder binnen het bereik en hebben meer inspanning nodig om van te herstellen.
Als u een geslaagd herstelproces voor noodgevallen wilt bedenken, moet u eerst evalueren wat voor soort bedrijfsimpact potentiële fouten kunnen hebben. Overweeg om het herstelproces zoveel mogelijk te automatiseren. Sommige onderdelen van uw proces voor herstel na noodgevallen omvatten onvermijdelijk menselijke invoer, dus u moet het proces volledig documenteer. U moet ook regelmatig noodgevallen simuleren, zodat uw herstelproces effectief blijft.
Belanghebbenden en infrastructuur identificeren
Identificeer iedereen die er belang in heeft dat uw toepassingen functioneel blijven. Deze belanghebbenden kunnen externe of interne gebruikers zijn. Uw ondersteuningsmedewerkers en iedereen die nodig is voor handmatige invoer in het BCDR-proces, is een belanghebbende. Andere toepassingen en services die afhankelijk zijn van uw toepassingen, kunnen ook belanghebbenden zijn.
Identificeer de infrastructuur die de omgeving vormt voor uw toepassingen. Deze infrastructuur is doorgaans de virtuele machines (VM's), netwerkbronnen, opslagbronnen en andere services die ernaast worden uitgevoerd.
Beoogde herstelpunten en beoogde hersteltijd identificeren
Een RPO geeft aan hoeveel gegevensverlies acceptabel is voor uw toepassing als er een noodgeval is. Als uw toepassing niet beschikbaar is, kan het zijn dat u het alleen acceptabel vindt dat de toepassing gegevens gebruikt die minder dan een half uur na herstel oud zijn. Sommige toepassingen functioneren met oudere gegevens, maar voor andere is het noodzakelijk dat altijd de actueelste gegevens beschikbaar zijn.
Een RTO is de maximale duur van acceptabele downtime voor uw toepassing. U vindt het bijvoorbeeld niet acceptabel dat uw toepassing langer dan vier uur niet beschikbaar is vanwege het mogelijke verlies voor het bedrijf na die tijd. Voor kritieke toepassingen is een kortere RTO vereist.
Contractuele of wettelijke vereisten kunnen vaak invloed hebben op de RPO en RTO voor uw toepassing. De RPO en RTO kunnen ook per toepassing verschillen. Minder kritieke toepassingen hebben mogelijk grotere waarden voor RPO en RTO, terwijl bedrijfskritieke toepassingen mogelijk een kleinere tolerantie hebben voor downtime en gegevensverlies. U berekent RTO en RPO op basis van het inzicht in het risico van uw organisatie en de kosten die voortvloeien uit het verlies van gegevens en downtime.
Eventuele PaaS-vereisten identificeren
Hoewel u mogelijk controle hebt over downtime en herstel voor de toepassingen die u beheert, hebt u mogelijk niet dezelfde controle over PaaS-services. PaaS-services die u gebruikt, hebben mogelijk hun eigen beschikbaarheidsgaranties en herstelplannen die u moet overwegen in uw BCDR-plan.
Identificeer en inventariseer de services die u afhankelijk bent, zodat u hun herstelmogelijkheden kunt opnemen in uw BCDR-plan. Het is belangrijk om inzicht te hebben in de relevante vereisten en hoe deze van invloed zijn op het BCDR-proces.
Azure Site Recovery
Azure Site Recovery is een service die BCDR-functies voor uw toepassingen biedt in Azure, on-premises en in andere cloudproviders. Site Recovery heeft plannen waarmee herstel na noodgevallen kan worden geautomatiseerd. Hiermee kunt u definiëren hoe failover van machines wordt uitgevoerd en de volgorde waarin ze opnieuw worden opgestart nadat een failover is uitgevoerd. Op deze manier helpt Site Recovery taken te automatiseren en uw RTO verder te verminderen. U kunt Site Recovery ook gebruiken om regelmatig failovers en de algehele effectiviteit van het herstelproces te testen.
Gegevensback-ups
Back-ups helpen toepassingen te beschermen tegen onbedoelde verwijdering of beschadiging van gegevens. Back-ups spelen een belangrijke rol in elk BCDR-plan.
Uw RPO is afhankelijk van hoe vaak en hoe regelmatig u back-upprocessen uitvoert. Als u bijvoorbeeld een back-upproces hebt geconfigureerd om om de twee uur uit te voeren en u vijf minuten voor de volgende back-up een noodgeval ondervindt, verliest u één uur en 55 minuten aan gegevens. Als u vaker back-ups uitvoert, betekent dat u een verminderd RPO hebt. In uw algehele plan moet u een back-upproces opnemen.
U kunt Azure Backup gebruiken voor uw back-upproces. De Azure Backup-service biedt beveiligde back-ups voor alle door Azure beheerde gegevensassets. Het maakt gebruik van oplossingen zonder infrastructuur om selfserviceback-ups en herstelbewerkingen mogelijk te maken, met beheer op schaal tegen voorspelbare kosten.
Azure Backup biedt gespecialiseerde back-upoplossingen voor Azure en on-premises VM's. Met Azure Backup kunnen workloads zoals SQL Server of SAP HANA die worden uitgevoerd op Azure-VM's ook back-up- en herstelopties van bedrijfsklasse hebben.
Zowel Azure Backup als Azure Site Recovery streven ernaar het systeem toleranter te maken voor fouten en fouten. Het primaire doel van Azure Backup is echter om kopieën van stateful gegevens te onderhouden waarmee u terug in de tijd kunt gaan. Site Recovery repliceert de gegevens in bijna realtime en maakt een failover mogelijk. Meer informatie over Azure Backup.
Azure-tolerantiefuncties
Azure wordt geleverd met functies om ervoor te zorgen dat uw toepassingen en infrastructuur tolerant zijn.
Regiokoppeling
Alle Azure-regio's worden gekoppeld met een andere regio. In een regiopaar worden de regio's nooit gelijktijdig bijgewerkt. In plaats daarvan worden ze één voor één bijgewerkt. Als er iets gebeurt met de ene regio, wordt de andere beschikbaar.
Deze regioparen worden ook gebruikt voor replicatie. Opslagservices en veel PaaS-services worden gerepliceerd en hebben failoverparen in de gekoppelde regio. Als onderdeel van uw BCDR-planning is het belangrijk om regiokoppeling te gebruiken om te profiteren van de isolatie die het biedt. U kunt de hoeveelheid tijd die nodig is om te herstellen van een fout verminderen en uw beschikbaarheid verhogen.
Beschikbaarheidssets
Een beschikbaarheidsset is een logische groeperingsmogelijkheid in Azure. Het zorgt ervoor dat de VM-resources die u erin plaatst, van elkaar worden geïsoleerd wanneer ze worden geïmplementeerd in een Azure-datacenter. Beschikbaarheidssets bestaan uit updatedomeinen en foutdomeinen.
Updatedomeinen helpen ervoor te zorgen dat een subset van de servers van uw toepassing actief blijft wanneer de VM-hosts in een Azure-datacenter downtime vereisen voor onderhoud. De meeste updates voor VM-hosts kunnen worden uitgevoerd zonder dat dit van invloed is op de vm's die erop worden uitgevoerd, maar er zijn gevallen waarin dit type update niet mogelijk is.
Om ervoor te zorgen dat updates niet in alle VM's in één keer plaatsvinden, wordt het Azure-datacenter logisch gesegmenteerd in updatedomeinen. Wanneer een onderhoudsgebeurtenis plaatsvindt, zoals een prestatie-update en een kritieke beveiligingspatch die op de host moet worden toegepast, wordt deze gesequentieerd via updatedomeinen. Het gebruik van sequentiëren via updatedomeinen zorgt ervoor dat het hele datacenter niet beschikbaar is tijdens platformupdates en patches.
Foutdomeinen vertegenwoordigen fysieke secties van het datacenter en zorgen voor rekdiversiteit van servers in een beschikbaarheidsset. Foutdomeinen zijn afgestemd op de fysieke scheiding van gedeelde hardware in het datacenter. Gedeelde hardware bevat stroom-, koelings- en netwerkhardware die ondersteuning biedt voor de fysieke servers op serverrekken.
Als de hardware die ondersteuning biedt voor een serverrek niet meer beschikbaar is, is de storing alleen van invloed op dat serverrek. Wanneer u uw VM's in een beschikbaarheidsset plaatst, worden deze automatisch verspreid over meerdere foutdomeinen. Als er een hardwarefout optreedt, is dit alleen van invloed op enkele van uw VM's.
Beschikbaarheidszones
Beschikbaarheidszones zijn onafhankelijke fysieke datacenterlocaties binnen een regio. Ze omvatten hun eigen vermogen, koeling en netwerken. Wanneer u rekening houdt met beschikbaarheidszones tijdens het implementeren van resources, kunt u helpen bij het beveiligen van workloads tegen storingen in datacenters terwijl de aanwezigheid in een regio behouden blijft.
Zonegebonden services zijn services (zoals virtuele machines) die u in specifieke zones binnen een regio kunt implementeren. Andere services zijn zone-redundante services en repliceren over de beschikbaarheidszones in de specifieke Azure-regio. Beide typen zorgen ervoor dat er binnen een Azure-regio geen single points of failure zijn.
