Wat is noodherstel?

Noodherstel (DR, disaster recovery) is één aspect van de overkoepelende bedrijfscontinuïteitsplannen die door de verschillende bedrijfsonderdelen binnen een organisatie worden opgesteld en onderhouden. Een effectief plan voor noodherstel vermindert de impact die niet-geplande of zelfs geplande uitval van cruciale bedrijfssystemen heeft op het vermogen van een onderneming om te functioneren en omzet te blijven genereren.

Hiertoe biedt een herstelplan organisaties een flexibele structuur waarmee ze op uniforme wijze, gezamenlijk hun systemen opnieuw kunnen ontwikkelen, herstellen en revitaliseren en een veerkrachtigere infrastructuur kunnen opbouwen.

Waarom is noodherstel belangrijk?

Hoelang kan een bedrijf nog functioneren als het salarisadministratiesysteem uitvalt vlak voordat de salarissen worden berekend en de rekeningen worden gefinancierd? Welke sancties zou een bedrijf opgelegd krijgen wanneer de betaling van landelijke, provinciale en lokale belastingen vertraging oploopt? Welke consequenties zou het bedrijf ondervinden als gevolg van het niet op tijd betalen van werknemers en hoelang zouden werknemers nog in dienst willen blijven?

Wel of geen noodherstel? Dat is niet langer de vraag. De werkelijke vraag is: hoeveel kost het om minuten, dagen of weken aan belangrijke data en het in jaren opgebouwde vertrouwen in één klap te verliezen?

Noodherstel mag niet langer een bijzaak zijn of iets dat alleen wordt overwogen als er voldoende budget is, omdat vandaag de dag van organisaties wordt verwacht dat ze direct reageren op verstorende gebeurtenissen en operationeel blijven. In plaats van zich te laten afschrikken door de kosten van de implementatie van een herstelplan, moeten organisaties zich meer verdiepen in de werkelijke kosten van het ontbreken van een plan. Doe bijvoorbeeld onderzoek naar de Service Level Agreements (SLA's) die niet kunnen worden nagekomen of de sancties en het omzetverlies die het gevolg zijn van een uitval. Vergelijk de kosten van de implementatie van noodherstel met die van sancties, omzetverlies en verloren vertrouwen van de klant en de keuze is duidelijk.

De titel van de afbeelding luidt: "Omzet, productiviteit en loyaliteitsverlies". In deze afbeelding worden drie belangrijke statistieken weergegeven. Deze statistieken zijn afkomstig uit een onderzoek dat Forrester Consulting in opdracht van IBM in 2019 heeft uitgevoerd. De vraag die aan de respondenten werd gesteld was "Met welke van de volgende kosten krijgt uw organisatie te maken als gevolg van geplande en ongeplande uitvaltijd?"
De aan de linkerkant weergegeven statistiek laat zien dat 53% van de ondervraagden "Omzetverlies" aangaf. De middelste statistiek laat zien dat 47% "Productiviteitsverlies " noemde. De statistiek aan de rechterkant laat zien dat 41% "Verlies van merkwaarde of vertrouwen" heeft geantwoord.

Niet-geplande uitval

Of de uitval nu wordt veroorzaakt door een natuurramp, fouten van de IT-operator of -serviceprovider, datacorruptie of ransomware-aanvallen, een organisatie moet zich kunnen beschermen tegen verstoringen van de bedrijfsvoering die leiden tot catastrofale verliezen, vervanging door opportunistische concurrenten en verlies van reputatie en goodwill.

Hoewel deze gevolgen zeer dramatisch klinken, weerspiegelen ze wel de recente ervaringen van veel bekende organisaties die er niet in slaagden hun problemen tijdig te herstellen en grote hoeveelheden kritieke transactiedata, klantgegevens en vertrouwen verloren zagen gaan.

Er zijn tal van scenario's en oorzaken die de bedrijfsvoering kunnen verstoren.

De titel van deze afbeelding luidt: "Belangrijkste oorzaken van niet-geplande uitvaltijd". In de afbeelding wordt een staafdiagram getoond met de oorzaken van niet-geplande uitval. Het staafdiagram is onderverdeeld in drie categorieën: operationele storingen, natuurrampen en door mensen veroorzaakte gebeurtenissen. Operationele storingen zijn gegroepeerd in het meest linkse deel van het staafdiagram, natuurrampen staan in het midden en door mensen veroorzaakte gebeurtenissen staan in het meest rechtse deel van het staafdiagram. De bron van dit diagram is Forrester Research, Inc.

Geplande uitval

Disaster Recovery as a Service (DRaaS) in de cloud biedt bedrijven ongeëvenaarde mogelijkheden voor operationele flexibiliteit. Organisaties gebruiken oplossingen voor noodherstel vaker voor geplande uitval dan om te herstellen van catastrofale gebeurtenissen.

Kenmerkende pijnpunten

• Traditionele methoden voor noodherstel vereisen dat er wordt geïnvesteerd in automatisering.
• Zelfs bedrijfssystemen in Tier 1-datacenters kunnen worden getroffen door stroomuitval, iets wat maar al te vaak voorkomt. Hoe vaak is het niet voorgekomen dat een alledaags incident zoals een stroomstoring een dag of twee aan productiviteitsverlies heeft veroorzaakt? IT-medewerkers zijn uren of soms dagen kwijt aan conferencecalls om systemen weer aan de praat te krijgen met noodoplossingen. • Sommige bedrijven besteden een aanzienlijk deel van hun IT-budget aan de ontwikkeling van interne automatisering voor het beheer van noodherstel, maar zijn bang om deze systemen te gebruiken of zelfs om ze periodiek te testen, omdat ze er zeker van willen zijn dat alles blijft werken zoals verwacht. • Het duurt vaak een dag (of dagen) om te herstellen van gepland onderhoud • Zelfs goed gedocumenteerde noodherstelplannen of -runbooks kunnen leiden tot dagenlang productiviteitsverlies terwijl IT-medewerkers heldendaden verrichten om alles weer aan de praat te krijgen.

Belangrijkste doelen van noodherstel

De twee belangrijkste doelen van noodherstel zijn: getroffen systemen zo snel mogelijk weer operationeel maken en ervoor zorgen dat er zo weinig mogelijk data verloren gaan na een catastrofale gebeurtenis of geplande uitval. De meetwaarden voor deze twee hoofddoelen zijn algemeen bekend als respectievelijk de doelstelling voor de hersteltijd (RTO, Recovery Time Objective) en de doelstelling voor het herstelpunt (RPO, Recovery Point Objective).

Elk bedrijfssysteem stelt andere eisen aan deze twee meetwaarden, afhankelijk van de Service Level Agreement tussen de IT-afdeling en de bedrijfseigenaren.

De titel van de afbeelding luidt: "Terminologie van databescherming". Tolerantie voor dataverlies en tolerantie voor uitvaltijd worden weergegeven op een rechte lijn die zich in twee richtingen uitstrekt vanuit het midden van de afbeelding. Links staat "Dataverlies" en rechts "Uitvaltijd".

Doelstelling voor hersteltijd

De doelstelling voor de hersteltijd (RTO, Recovery Time Objective) is de tijd die nodig is om een bedrijfssysteem weer volledig operationeel te maken na geplande of niet-geplande uitval.

Doelstelling voor herstelpunt

Een doelstelling voor het herstelpunt (RPO, Recovery Point Objective) is de maximale hoeveelheid data die verloren mag gaan voordat een bedrijfssysteem schade oploopt. De RPO wordt gewoonlijk gemeten in tijd vanaf het moment dat de laatste back-up, replicatie of momentopname is gemaakt.

Noodherstel versus hoge beschikbaarheid

Hoge beschikbaarheid beschermt gewoonlijk tegen individuele storingspunten, terwijl noodherstel bescherming biedt tegen meerdere storingspunten. Bij cloud computing is de bescherming tegen individuele storingspunten op de fysieke infrastructuurlaag, waaronder stroom, koeling, opslag, netwerken en fysieke servers, volledig geïntegreerd in de algemene architectuur door middel van beschikbaarheids- en foutdomeinen.

Hoge beschikbaarheid is in dit geval schaalbaar en in hoge mate bestand tegen dataverlies of verlies van verwerkingsprestaties. Bijna elke provider van cloudoplossingen voor bedrijven bouwt hoge beschikbaarheid in zijn aanbod in.

Oplossingen voor noodherstel met hoge beschikbaarheid die bescherming bieden tegen dataverlies en uitvaltijd voor databases zijn duur wanneer er gebruik wordt gemaakt van complexe technologie voor datatoewijzing en datareplicatie. Deze oplossingen bieden geen bescherming tegen ransomware. Dergelijke bescherming wordt verkregen via een uitgebreide back-up met een momentopname van een doelstelling voor het herstelpunt en een onveranderbare opslag.

Traditionele oplossingen voor hoge beschikbaarheid werken goed in combinatie met een goedkope cloudoplossing voor noodherstel. De aanvullende technologie voor noodherstel in de cloud biedt een extra beschermingslaag voor databases waarvoor hoge beschikbaarheid zonder dataverlies en uitvaltijd is vereist en waarbij bescherming tegen ransomware nodig is met incrementeel herstel voor de lange termijn.

On-premises noodherstel is een niet-flexibele en dure oplossing vanwege de hoge kosten voor het dupliceren van IT-infrastructuur op een bronlocatie en een vaste locatie van het datacenter. Bij deze optie is een verbinding met het WAN niet mogelijk en er kunnen geen servers worden gemigreerd tussen ongelijksoortige omgevingen. Er is daarom een dedicated circuit nodig tussen de bron- en doeldatacenters om dit systeem te laten werken als één verbonden LAN-omgeving. Bij de traditionele noodherstelmethode is het ook niet mogelijk om servers te migreren tussen ongelijksoortige heterogene omgevingen, zoals een on-premises omgeving en een cloudplatform of twee verschillende cloudplatforms.

Bij DRaaS wordt een mengelmoes van door leveranciers verstrekte back-upoplossingen en open source-migratietools gebruikt om een streng gecontroleerde en zeer specifieke omgeving te realiseren. De eindgebruiker kan alleen workloads in de oorspronkelijke hostingomgeving van de DRaaS-provider herstellen vanuit zijn eigen on-premises VMware-omgeving. Deze door leveranciers verstrekte oplossingen kunnen prijzig zijn en zijn mogelijk beperkt in de reeks workloads die ze kunnen beschermen en de compute-omgevingen waarvoor ze ondersteuning bieden.

Workflows, runbooks en plannen voor noodherstel

Oracle noemt een noodherstelworkflow meestal een noodherstelplan. Een noodherstelplan – ook wel 'runbook' genoemd – is een lijst van vooraf bepaalde stappen of taken die moeten worden uitgevoerd om de compute-instance, het platform, de database en de applicaties over te zetten naar een vooraf bepaald herstelgebied in de cloud. Dit omvat alle taken of afzonderlijke stappen die worden uitgevoerd door een persoon of een vorm van automatisering tijdens een noodhersteloperatie zoals een overschakeling of failover. De termen noodherstelplan, runbook voor noodherstel en noodherstelworkflow zijn onderling verwisselbaar.

Noodhersteloperaties (overschakeling versus failover)

Een noodhersteloperatie is het proces van het uitvoeren van elke vooraf bepaalde stap of taak in een noodherstelplan die nodig is om de infrastructuur, database en applicaties te herstellen naar een volledig operationele toestand. Er worden twee verschillende termen gebruikt om de overgang van een applicatiestack naar een andere locatie te beschrijven: failover en overschakeling.

Failover

Een failover is een niet-geplande uitval waarbij applicaties, databases en virtuele machines zijn gecrasht en alle resources, inclusief opslag, data en gastbesturingssystemen, in een inconsistente toestand verkeren. In dit geval wordt aangenomen dat de primaire cloudregio volledig ontoegankelijk en in het geheel niet beschikbaar is, wat betekent dat een echte noodhersteloperatie moet worden geactiveerd.

Daarom kunnen alle noodhersteltaken in een noodherstelplan alleen worden uitgevoerd in de regio van de stand-bycloud. Het is van cruciaal belang dat de DRaaS-oplossing van een cloudprovider is ontworpen voor hoge beschikbaarheid in de stand-byregio, zodat deze toegankelijk is en werkt wanneer zich een ramp voordoet.

Overschakeling

Overschakeling is een geplande uitvaltijd waarbij applicaties, databases en virtuele machines of servers gecontroleerd worden afgesloten. In dit geval werken zowel de primaire als de stand-byregio normaal en zijn de IT-medewerkers waarschijnlijk gericht op het "verplaatsen" van een of meer systemen van de ene regio naar de andere voor onderhoud of het voltooien van doorlopende upgrades.

Cloudimplementatiestrategie

Moderne bedrijven kunnen om tal van redenen profiteren van een of meer van de volgende cloudimplementatiemodellen, zoals kosten, prestaties en bedrijfscontinuïteitseisen. Een robuuste cloudimplementatiestrategie komt steeds vaker voor nu bedrijven hun activiteiten steeds meer naar de cloud verplaatsen.

Interregionale oplossingen voor noodherstel

Interregionale oplossingen voor noodherstel beschermen organisaties tegen volledige uitval die gevolgen zou hebben voor de toegang tot bedrijfssystemen die in de cloudinfrastructuur van één cloudprovider worden gehost. Zoals de naam al aangeeft, kan een volledige applicatiestack voor een bepaald bedrijfssysteem, inclusief virtuele machines, databases en applicaties, op verzoek worden overgezet naar een geheel andere cloudregio op een andere geografische locatie.

DRaaS-oplossingen moeten in staat zijn een volledig bedrijfssysteem, zoals een portaal voor human resources of financiële services of een applicatie voor enterprise resource management, naar een andere cloudregio over te zetten. DRaaS moet kunnen voldoen aan de doelstellingen voor de hersteltijd en de herstelpunten die in de Service Level Agreements voor elke afzonderlijke applicatie zijn vastgelegd.

Interregionale oplossingen voor noodherstel, zoals Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery, beschermen volledige bedrijfsapplicaties tegen het catastrofale verlies van toegang tot een volledige cloudregio, inclusief het verlies van alle beschikbaarheidsdomeinen in die regio.

Hybride cloudoplossingen voor noodherstel

Noodherstel in de hybride cloud is een uiterst populaire oplossing waarmee ondernemingen workloads en virtuele machines vanuit hun eigen datacenters kunnen overzetten naar een cloudinfrastructuur. Een hybride cloud wordt vaak gebruikt als noodhersteloplossing om de data en de levensvatbaarheid van de kritieke bedrijfssystemen van een bedrijf te beschermen.

Voor klanten van Oracle is hybride cloud een vrije samenvoeging van OCI en fysieke servers, Oracle cloudappliances of andere systemen in het fysieke datacenter van een bedrijf. Oracle cloudappliances zoals Oracle Private Cloud Appliance X9-2 en Oracle Exadata Cloud@Customer zijn uitstekende voorbeelden van on-premises systemen die goed kunnen worden geïntegreerd met OCI.

Sommige producten van Oracle partners, zoals Rackware, kunnen worden gebruikt voor het realiseren van noodherstel tussen on-premises infrastructuur en OCI. Rackware is beschikbaar via Oracle Cloud Marketplace.

Multicloud-oplossingen voor noodherstel

Multicloud-oplossingen voor noodherstel beschermen applicaties en data door de verschillende onderdelen van een applicatiestack te verspreiden over de cloudinfrastructuren van twee of meer cloudproviders. De samenwerking tussen Oracle en Microsoft Azure is een goed voorbeeld van een multicloudrelatie.

Disaster Recovery as a Service moet geschikt zijn voor interregionaal noodherstel, noodherstel in de hybride cloud en noodherstel in meerdere clouds. OCI kan op dit moment DRaaS leveren voor interregionaal noodherstel en noodherstel in de hybride cloud.

Dataconsistentie voor databases

Levensvatbare oplossingen voor noodherstel waarbij databases een rol spelen, moeten altijd mogelijkheden bevatten om de dataconsistentie te waarborgen. Het punt waarop een database kan worden hersteld naar volledige dataconsistentie, inclusief actieve transacties, bepaalt de doelstelling voor het herstelpunt.

Dataconsistentie is niet zo'n groot probleem voor serverloze databases of databases met platte bestanden, maar het herstellen van geavanceerde relationele databases, zoals Oracle Database of MySQL, naar een dataconsistente toestand voor een bepaald punt in de tijd is zeer complex, maar desondanks van cruciaal belang.

Aandachtspunten inzake noodherstel voor MySQL databases

Wanneer u MySQL Database Service in OCI gebruikt, is een MySQL databasesysteem een logische container voor een of meer MySQL instances. Het systeem biedt een interface waarmee taken zoals inrichting, automatische back-ups en herstel naar een bepaald tijdstip kunnen worden beheerd.

Het binaire logbestand en de native replicatietechnologieën van MySQL maken herstel naar een bepaald tijdstip, hoge beschikbaarheid en noodherstel mogelijk. MySQL Group Replication wordt gewoonlijk gebruikt om lokale fouttolerante clusters voor hoge beschikbaarheid te maken, terwijl asynchrone MySQL-replicatie gewoonlijk wordt gebruikt voor geografisch gedistribueerd noodherstel.

Een databasesysteem met hoge beschikbaarheid heeft drie MySQL instances in verschillende beschikbaarheidsdomeinen of foutdomeinen. Het databasesysteem garandeert dat bij uitval van één instance een andere het overneemt, zonder dataverlies en met minimale uitvaltijd. Voor noodherstel in verschillende regio's kunnen ook inkomende replicatiekanalen tussen twee databasesystemen worden gemaakt.

Gebruik onderstaande koppelingen voor meer informatie over noodherstel voor MySQL in de cloud.

• Overzicht van bedrijfscontinuïteit voor MySQL
• Overzicht van hoge beschikbaarheid voor MySQL
• Overzicht van inkomende replicatie voor MySQL

Aandachtspunten inzake noodherstel voor Oracle databases

Oracle Maximum Availability Architecture (MAA) biedt best practices voor de architectuur, configuratie en levenscyclus van Oracle databases en maakt hierdoor service met hoge beschikbaarheid mogelijk voor databases in on-premises, cloud- of hybride configuraties.

Gebruik onderstaande koppelingen voor meer informatie over Oracle Maximum Availability Architecture voor noodherstel in de cloud.

• Landingspagina Oracle Maximum Availability Architecture
• Referentiearchitecturen voor Oracle Maximum Availability Architecture
• Best practices van Oracle Maximum Availability Architecture voor Oracle Fusion Middleware
• Best practices van Oracle Maximum Availability Architecture voor applicaties

Architecturen van implementaties in de cloud

In implementatiearchitecturen wordt beschreven hoe verschillende componenten zoals computing, platform/database en applicaties worden geïmplementeerd tussen cloudregio's om te zorgen voor een veerkrachtig herstel na totale uitval van een datacenter. Een implementatiearchitectuur bevat een beschrijving van waar alles zich bevindt wanneer een applicatiesuite op de normale manier werkt en wat er in de stand-byregio moet worden hersteld om alles weer aan de gang te krijgen.

Bij Oracle vinden we dat DRaaS-oplossingen flexibel genoeg moeten zijn om elke gewenste combinatie van implementatiearchitecturen voor noodherstel op te nemen, zodat aan de individuele vereisten van het serviceniveau voor elk uniek bedrijfssysteem kan worden voldaan. Cloudproviders moeten hun klanten de vrijheid bieden om 'alle bovenstaande' oplossingen te kiezen om te voldoen aan SLA's voor de grote verscheidenheid aan bedrijfssystemen die door organisaties worden gebruikt.

Noodherstelstrategieën en implementatiearchitecturen worden op veel verschillende manieren aangeduid. De verschillende methoden en patronen om te beschrijven hoe de infrastructuur, het platform en de applicaties voor noodherstel moeten worden geïmplementeerd, kunnen echter in twee grote strategische categorieën worden ingedeeld: actief/actief en actief/stand-by noodherstel.

Onderstaande tabel geeft een overzicht van de gangbare termen voor het beschrijven van de verschillende implementatiearchitecturen die onder deze twee algemene noodherstelstrategieën vallen.

Strategie	Implementatiearchitectuur	RPO	RTO
Actief/stand-by	Cold stand-by	Uren	Uren
Actief/stand-by	Pilot light	Minuten	Uren
Actief/stand-by	Warm stand-by	Seconden	Uren
Actief/stand-by	Hot stand-by	Seconden	Minuten
Actief/actief	Actief/actief	Bijna nul	Bijna nul

In dit gedeelte proberen we enkele variaties van actieve/actieve en actieve/stand-by methoden van noodherstel te verduidelijken. Beide noodherstelstrategieën maken deel uit van het arsenaal van beschikbare wapens om bedrijfscontinuïteit te bereiken.

Architecturen van actief/stand-by implementaties

De architectuur van actieve/stand-by implementaties kent vele variaties. Actieve/stand-by implementaties, soms actieve/passieve implementaties genoemd, worden vaak omschreven als pilot light, cold, warm en hot stand-by implementaties.

De scenario's pilot light, cold stand-by, warm stand-by en hot stand-by zijn allemaal varianten van hetzelfde thema, waarbij 100% van een applicatiestack in de primaire regio draait, terwijl minder dan 100% van hetzelfde bedrijfssysteem actief draait in de stand-byregio.

Onderstaande reeks van veralgemeniseerde conceptuele diagrammen is bedoeld om enkele fundamentele verschillen tussen gangbare implementatiearchitecturen te illustreren en is niet bedoeld als referentiearchitectuur. In deze diagrammen staat niet beschreven hoe noodherstel voor een applicatiestack moet worden geïmplementeerd.

Cold stand-by

In dit scenario zijn de virtuele machines (VM's), de database en applicaties alleen aanwezig in de huidige primaire regio. De volumegroepen voor bestands- en blokopslag waarin de opstartschijf en andere virtuele schijven voor elke VM zijn opgeslagen, worden gerepliceerd naar de stand-byregio.

Hier ziet u een afbeelding met links de primaire regio en rechts de stand-byregio. De primaire regio bestaat uit drie blokken: applicatie, database en infrastructuur, die elk hun eigen pictogrammen bevatten. Bij beide regio's staat bovenaan een pictogram dat een lastverdeler voorstelt. Het pictogram van de lastverdeler in de stand-byregio is lichter gekleurd dan het pictogram in de primaire regio. De stand-byregio bevat drie blokken: applicatie, database en infrastructuur. In de stand-byregio wordt alleen het blok 'Infrastructuur' gevuld met pictogrammen: één voor objectopslag, één voor blokopslag en één voor bestandsopslag. De blokken 'Database' en 'Applicatie' in de stand-byregio zijn leeg. Tussen de twee blokken 'Infrastructuur' staan twee pijlen die replicatie van objectopslag en opslag weergeven. Deze pijlen symboliseren de replicatie van de primaire naar de stand-byregio.

Tijdens een noodhersteloperatie, zoals een overschakeling of failover, wordt de gerepliceerde opslag met dezelfde VM's geactiveerd in de stand-byregio en worden exact dezelfde VM's opnieuw gestart op het punt waar ze waren gestopt of gecrasht. De VM's zijn precies dezelfde virtuele machines die voorheen in de actieve regio actief waren.

Deze implementatiearchitectuur heeft verschillende voordelen, zoals lagere implementatiekosten, minder onderhoudsoverhead en lagere bedrijfskosten. Het is wellicht echter niet de beste oplossing voor applicaties die afhankelijk zijn van relationele databases voor de backend, aangezien het uitvoeren van periodieke koude back-ups de enige manier is om de dataconsistentie te waarborgen. Deze aanpak werkt prima voor applicaties die incidenteel korte, volledige uitval kunnen hebben.

De meeste IT-afdelingen lossen dit probleem op door de database periodiek af te sluiten, een momentopname van de blokopslag te maken en vervolgens de normale werkzaamheden te hervatten. Hiermee wordt ook de doelstelling voor het herstelpunt bepaald, aangezien u slechts kunt herstellen tot het tijdstip waarop de back-up werd voltooid.

Deze architectuur heeft een iets langere hersteltijd en er is een veel groter risico op dataverlies, maar het is een bruikbare oplossing als de workload hiervoor geschikt is. Het kan bijvoorbeeld een uitstekende oplossing zijn voor applicaties die afhankelijk zijn van een database met platte bestanden, een serverloze database of helemaal geen database, of voor klanten die gewoon een aantal virtuele machines tussen verschillende regio's mobiel willen maken voor meer flexibiliteit.

Voorbeelden van noodherstelworkflows voor deze implementatiearchitectuur

In de onderstaande twee scenario's wordt geschetst hoe de processtroom voor noodhersteloperaties voor 'cold stand-by' implementaties zou kunnen verlopen.

In het geval van een overschakeling worden de volgende taken uitgevoerd in zowel de primaire als de stand-byregio:

• Primaire applicaties worden gepauzeerd.
• Primaire databases worden gepauzeerd en gesynchroniseerd naar de stand-byregio.
• Primaire virtuele machines worden op een correcte manier stopgezet.
• Primaire opslag wordt gesynchroniseerd naar de stand-byregio.
• De gerepliceerde opslag wordt online gezet, de replicatie wordt omgekeerd en nu is de stand-byregio de primaire regio.
• Gerepliceerde kopieën van primaire virtuele machines worden opgestart en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Gerepliceerde kopieën van primaire databases worden in de stand-byregio hersteld met behulp van de laatste koude back-up of transactie en de redo-logbestanden van de gerepliceerde opslag.
• Gerepliceerde kopieën van primaire databases worden gestart en gekoppeld en zijn nu primair in de stand-byregio.
• Gerepliceerde kopieën van primaire applicaties worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

In het geval van een failover worden de volgende taken alleen in de stand-byregio uitgevoerd:

• De gerepliceerde opslag wordt online gezet, de replicatie wordt omgekeerd en nu is de stand-byregio de primaire regio.
• Gerepliceerde kopieën van primaire virtuele machines worden opgestart en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Gerepliceerde kopieën van primaire databases worden in de stand-byregio hersteld met behulp van de laatste koude back-up of transactie en de redo-logbestanden van de gerepliceerde opslag.
• Gerepliceerde kopieën van primaire databases worden gestart en gekoppeld en zijn nu primair in de stand-byregio.
• Gerepliceerde kopieën van primaire applicaties worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

Warm stand-by

In dit scenario bevinden virtuele machines zich zowel in de primaire als in de stand-byregio, maar zijn ze volledig onafhankelijk van elkaar en hebben ze hun eigen unieke hostnamen en vooraf toegewezen IP-adressen. De stand-byregio heeft eigen VM's die kunnen worden stopgezet of kunnen draaien, al naar gelang de voorkeur van de klant.

Hier ziet u een afbeelding met links de primaire regio en rechts de stand-byregio. De primaire regio bestaat uit drie blokken: applicatie, database en infrastructuur, die elk hun eigen pictogrammen bevatten. Bij beide regio's staat bovenaan een pictogram dat een lastverdeler voorstelt. Het pictogram van de lastverdeler in de stand-byregio is lichter gekleurd dan het pictogram in de primaire regio. De stand-byregio bevat drie blokken: applicatie, database en infrastructuur. In de stand-byregio wordt het blok 'Infrastructuur' gevuld met pictogrammen: één voor objectopslag, één voor blokopslag en één voor bestandsopslag. Op het niveau 'Infrastructuur' is ook een pictogram voor virtuele machines afgebeeld, maar deze heeft een lichtere kleur. De pictogrammen 'Database' en 'Applicatie' in de stand-byregio zijn ook lichter van kleur. Tussen de twee blokken 'Infrastructuur' staan twee pijlen die replicatie van objectopslag en opslag weergeven. Deze pijlen symboliseren de replicatie van de primaire naar de stand-byregio.

Databases moeten zowel in de primaire als in de stand-byregio draaien.

Voor Oracle databases raden we aan om Oracle Data Guard te gebruiken voor het repliceren van de primaire database en de stand-bydatabase. Raadpleeg onze Gold MAA referentiearchitectuur voor meer informatie.

Voor andere databases dan die van Oracle worden de respectievelijke native replicatietechnologieën gebruikt om de databases voortdurend te blijven synchroniseren tussen de primaire en de stand-byregio.

Er zijn ook applicaties aanwezig in de regio van de stand-bycloud, maar deze zijn ofwel niet actief ofwel niet toegankelijk.

Voorbeelden van noodherstelworkflows voor deze implementatiearchitectuur

In de onderstaande twee scenario's wordt geschetst hoe de processtroom voor noodhersteloperaties voor 'warm stand-by' implementaties zou kunnen verlopen.

In het geval van een overschakeling worden de volgende taken uitgevoerd in zowel de primaire als de stand-byregio:

• Primaire applicaties worden gepauzeerd.
• Primaire databases worden gepauzeerd en gesynchroniseerd naar de stand-byregio.
• Primaire virtuele machines worden op een correcte manier stopgezet.
• Primaire opslag wordt gesynchroniseerd naar de stand-byregio.
• De gerepliceerde opslag wordt online gezet, de replicatie wordt omgekeerd en nu is de stand-byregio de primaire regio.
• Virtuele machines in stand-bystand worden opgestart (als ze nog niet actief zijn) en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Stand-bydatabases schakelen over op volledige lees-/schrijftoegang en zijn nu primair in de stand-byregio.
• Applicaties in stand-bystand worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

In het geval van een failover worden de volgende taken alleen in de stand-byregio uitgevoerd:

• De gerepliceerde opslag wordt online gezet, de replicatie wordt indien mogelijk omgekeerd en nu wordt de stand-byregio de primaire regio.
• Virtuele machines in stand-bystand worden opgestart (als ze nog niet actief zijn) en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Stand-bydatabases worden hersteld met de laatste transactie- en redo-logbestanden van de gerepliceerde opslag.
• Stand-bydatabases schakelen over op volledige lees-/schrijftoegang en zijn nu primair in de stand-byregio.
• Applicaties in stand-bystand worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

Hot stand-by

In dit scenario staan en draaien virtuele machines in zowel de primaire als de stand-byregio met hun eigen unieke hostnamen en vooraf toegewezen IP-adressen.

Hier ziet u een afbeelding met links de primaire regio en rechts de stand-byregio. De primaire regio bestaat uit drie blokken: applicatie, database en infrastructuur, die elk hun eigen pictogrammen bevatten. Bij beide regio's staat bovenaan een pictogram dat een lastverdeler voorstelt. Het pictogram van de lastverdeler in de stand-byregio is lichter gekleurd dan het pictogram in de primaire regio. De stand-byregio bevat drie blokken: applicatie, database en infrastructuur. In zowel de primaire als de stand-byregio staan pictogrammen in de blokken 'Applicatie', 'Database' en 'Infrastructuur'. Het blok 'Infrastructuur' bevat pictogrammen voor virtuele machines, bestandsopslag, objectopslag en blokopslag in zowel de primaire als de stand-byregio. Alleen de databasepictogrammen in de stand-byregio zijn lichter van kleur. Tussen de twee blokken 'Infrastructuur' staan twee pijlen die replicatie van objectopslag en opslag weergeven. Deze pijlen symboliseren de replicatie van de primaire naar de stand-byregio.

Databases moeten zowel in de primaire als in de stand-byregio draaien.

Voor Oracle databases raden we aan om Oracle Data Guard te gebruiken voor het repliceren van de primaire database en de stand-bydatabase. Raadpleeg onze Gold MAA referentiearchitectuur voor meer informatie.

Voor andere databases dan die van Oracle worden de respectievelijke native replicatietechnologieën gebruikt om de databases voortdurend te blijven synchroniseren tussen de primaire en de stand-byregio.

Applicaties draaien in de regio van de stand-bycloud, maar zijn niet beschikbaar via het openbare netwerk.

Voorbeelden van noodherstelworkflows voor deze implementatiearchitectuur

In de onderstaande twee scenario's wordt geschetst hoe de processtroom voor noodhersteloperaties voor 'hot stand-by' implementaties zou kunnen verlopen.

In het geval van een overschakeling worden de volgende taken uitgevoerd in zowel de primaire als de stand-byregio:

• Primaire applicaties worden gepauzeerd.
• Primaire databases worden gepauzeerd en gesynchroniseerd naar de stand-byregio.
• Primaire virtuele machines worden op een correcte manier stopgezet.
• Primaire opslag wordt gesynchroniseerd naar de stand-byregio.
• De gerepliceerde opslag wordt online gezet, de replicatie wordt omgekeerd en nu is de stand-byregio de primaire regio.
• Virtuele machines in stand-bystand zijn al actief en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Stand-bydatabases schakelen over op volledige lees-/schrijftoegang en zijn nu primair in de stand-byregio.
• Applicaties in stand-bystand worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

In het geval van een failover worden de volgende taken alleen in de stand-byregio uitgevoerd:

• De gerepliceerde opslag wordt online gezet, de replicatie wordt indien mogelijk omgekeerd en nu wordt de stand-byregio de primaire regio.
• Virtuele machines in stand-bystand worden opgestart (als ze nog niet actief zijn) en alle systeemapplicaties of tools die nodig zijn voor de applicatiestack worden gestart en zijn nu primair in de stand-byregio.
• Stand-bydatabases worden hersteld met de laatste transactie- en redo-logbestanden van de gerepliceerde opslag.
• Stand-bydatabases schakelen over op volledige lees-/schrijftoegang en zijn nu primair in de stand-byregio.
• Applicaties in stand-bystand worden opgestart en gevalideerd en zijn nu primair in de stand-byregio.
• Eventuele wijzigingen in de DNS en lastverdelers worden doorgevoerd om toegang tot de applicatie via het openbare netwerk mogelijk te maken.

Architectuur van actieve/actieve implementatie

In dit scenario is de gehele applicatiestack volledig functioneel en wordt een workload verwerkt in zowel de primaire als de stand-byregio.

Hier ziet u een afbeelding met links de primaire regio en rechts de stand-byregio. De primaire regio en de stand-byregio bestaan beide uit drie blokken: applicatie, database en infrastructuur, die elk hun eigen pictogrammen bevatten. Bij beide regio's staat bovenaan een pictogram dat een lastverdeler voorstelt. Geen van beide heeft een lichtere kleur. Pictogrammen in de blokken 'Applicatie', 'Database' en 'Infrastructuur' in zowel de primaire als de stand-byregio zijn in kleur weergegeven. Tussen de twee blokken 'Infrastructuur' staat één pijl die replicatie van optionele opslag weergeeft. Deze pijl symboliseert de replicatie van de primaire naar de stand-byregio.

Databases moeten zowel in de primaire als in de stand-byregio draaien.

Voor Oracle databases raden we aan om Oracle GoldenGate te gebruiken voor actieve/actieve applicatieconfiguratie. Daarnaast raden we aan om in elke regio lokale stand-bydatabases te hebben met behulp van Oracle Data Guard, zodat uw RTO en RPO bijna nul is. Raadpleeg onze Platinum MAA referentiearchitectuur voor meer informatie.

Voor andere databases dan die van Oracle worden de respectievelijke native replicatie- en actief/actief-technologieën gebruikt om de databases voortdurend te blijven synchroniseren tussen de primaire en de stand-byregio.

Applicaties draaien op en zijn beschikbaar via het openbare netwerk in de regio van de stand-bycloud en hebben een actieve workload.

Noodhersteltaken automatiseren met DRaaS

Oracle-teams hebben veel moeite gedaan om producten met hoge beschikbaarheid te ontwerpen, waaronder de overgrote meerderheid van de databases en applicaties van Oracle voor bedrijven. Ze bedenken vaak best practices en implementatiearchitecturen voor het realiseren van noodherstel in zowel traditionele on-premises omgevingen als in de cloud. Voor elke productlijn wordt een noodherstelmethode voor de afzonderlijke applicaties ontwikkeld, met losjes gekoppelde stappen om alle onderdelen te herstellen die nodig zijn om de applicatie te ondersteunen.

Met Disaster Recovery as a Service in de cloud kunnen alle losjes gekoppelde stappen die door ontwikkelaars, cloud-architecten en architecten van productoplossingen zijn bedacht, worden samengebracht in één naadloze workflow die met één klik kan worden gestart. OCI biedt met Full Stack Disaster Recovery een DRaaS-oplossing die flexibel, zeer schaalbaar en uitstekend uit te breiden is.

In OCI Full Stack Disaster Recovery beheert u met één klik het overzetten van infrastructuur, databases en applicaties tussen OCI-regio's, waar ook ter wereld. Klanten kunnen noodherstelomgevingen implementeren zonder de bestaande infrastructuur, databases of applicaties opnieuw te ontwerpen of opnieuw te implementeren, terwijl er geen speciale beheer- of conversieservers nodig zijn.

• Meer informatie over OCI Full Stack Disaster Recovery
• Meer informatie over noodherstel voor OCI