Ce este recuperarea în caz de dezastru?

Recuperarea în caz de dezastru (DR) este o fațetă a planurilor generale de continuitate a activității, elaborate și întreținute de diversele linii de business din cadrul unei organizații. Un plan eficient de recuperare în caz de dezastru reduce impactul întreruperilor funcționării sistemelor esențiale, neplanificate sau chiar planificate, asupra capacității companiei de a-și desfășura activitatea și a obține venituri.

În acest scop, un plan DR le oferă organizațiilor o structură flexibilă, care le permite să funcționeze într-un mod unificat și interactiv pentru restabilirea, reabilitarea și revitalizarea sistemelor, astfel încât infrastructura să devină mai rezistentă.

De ce este importantă recuperarea în caz de dezastru?

Cât timp ar putea să mai funcționeze o companie dacă și-ar pierde sistemul de salarizare chiar înainte de calcularea salariilor și de efectuarea plăților? Ce penalizări ar suporta o companie din cauza plății întârziate a taxelor federale, către stat și locale? Care ar fi consecințele pentru companie ca urmare a faptului că nu își plătește angajații la timp – și cât timp vor mai rămâne angajații angajați?

A face sau a nu face recuperarea în caz de dezastru? Nu mai este aceasta întrebarea. Întrebarea, de fapt, se referă la costurile pierderii, într-o clipă, a minute, zile sau săptămâni pentru datele importante și pentru încrederea acumulată de-a lungul anilor?

Recuperarea în caz de dezastru nu mai poate rămâne doar o intenție sau ceva luat în considerare doar atunci când există suficient buget, deoarece organizațiile de astăzi trebuie să răspundă prompt la evenimentele perturbatoare și să rămână operaționale. În loc să fie descurajate de costurile implementării unui plan de reziliență, organizațiile trebuie să aprofundeze problema și să evalueze costul real al lipsei unui astfel de plan. De exemplu, să examineze acordurile privind nivelul serviciilor (SLA) care nu pot fi respectate sau penalitățile și pierderea de venituri care ar rezulta din întreruperea activității. Comparând costul implementării DR cu penalizările, pierderea de venituri și pierderea încrederii clienților, alegerea este clară.

Imaginea se intitulează „Venituri, productivitate și fidelitate pierdută". În această imagine, sunt afișate trei statistici esențiale. Aceste statistici au fost preluate dintr-un studiu efectuat de Forrester Consulting în numele IBM, în 2019. Întrebarea sondajului a fost „Cu care dintre următoarele costuri se confruntă organizația dvs. din cauza inactivității planificate și neplanificate?”
În partea stângă, statistica afișată arată că 53% dintre cei chestionați au răspuns „Venituri pierdute”. În mijloc, statistica arată că 47% au răspuns „Productivitate pierdută”. În partea dreaptă, statistica arată că 41% au răspuns „S-a pierdut valoarea mărcii sau încrederea în marcă”.

Întreruperi neplanificate

Indiferent dacă întreruperile sunt cauzate de dezastre naturale, de erori ale furnizorilor de IT/servicii, coruperea datelor sau atacuri ransomware, organizațiile trebuie să se poată proteja de întreruperea operațiunilor de business care duc la pierderi catastrofale ca urmare a înlocuirii lor cu concurenții și a pierderii reputației și fondului comercial.

Deși aceste rezultate par dramatice, ele reflectă experiențele recente ale multor organizații binecunoscute, care nu au reușit să se recupereze în timp util și au pierdut cantități mari de date tranzacționale esențiale și de informații despre clienți, precum și reputația.

O mare varietate de scenarii și cauze de bază pot perturba operațiunile de business.

Această imagine se intitulează „Principalele cauze ale întreruperilor neplanificate”. Imaginea afișează o diagramă cu bare care reprezintă cauzele întreruperilor neplanificate. Diagrama cu bare este segmentată în trei categorii: defecțiuni, dezastre naturale și incidente cauzate de oameni. Defecțiunile sunt grupate în partea stângă a graficului cu bare, dezastrele naturale sunt la mijloc, iar incidentele cauzate de oameni sunt grupate în partea dreaptă. Sursa acestui grafic este Forrester Research, Inc.

Întreruperi planificate

Recuperarea în caz de dezastru ca serviciu (DRaaS) în cloud le oferă companiilor opțiuni fără egal pentru flexibilitate operațională. Organizațiile folosesc soluții de recuperare în caz de dezastru pentru întreruperile planificate mai frecvent decât pentru recuperarea în urma evenimentelor catastrofale.

Probleme tipice

• Abordările tradiționale privind recuperarea în caz de dezastru necesită investiții în automatizare.
• Chiar și sistemele de afaceri din centrele de date de nivel 1 pot fi afectate de pene de curent, care sunt prea frecvente. Cât de des a provocat un incident comun, cum ar fi o întrerupere de curent, o zi sau două de productivitate pierdută? Personalul IT sfârșește prin a petrece ore sau zile întregi în teleconferințe, pentru a repune sistemele în funcțiune utilizând soluții paliative. • Unele companii cheltuiesc o parte semnificativă din bugetele lor IT dezvoltând automatizarea internă pentru gestionarea recuperării în caz de dezastru, pe care, însă, nu o folosesc – și nici măcar nu o testează pentru a se asigura că funcționează conform așteptărilor. • Adesea, este nevoie de o zi (sau zile) pentru recuperarea după o perioadă de întrerupere a activității planificată. • Chiar și planurile sau registrele DR bine documentate pot implica zile întregi de pierdere a productivității în timp ce personalul IT face eforturi eroice pentru a repune totul în funcțiune.

Principalele obiective ale recuperării în caz de dezastru

Cele două obiective principale ale recuperării în caz de dezastru sunt readucerea sistemelor afectate la o stare operațională cât mai rapid posibil și reducerea cât mai mult a pierderii de date după un eveniment catastrofal sau o întrerupere planificată. Parametrii pentru aceste două obiective sunt unanim cunoscuți ca perioada de recuperare (RTO) și, respectiv, punctul de recuperare (RPO).

Fiecare sistem de business va avea cerințe diferite pentru acești doi parametri, în funcție de acordul privind nivelul de servicii dintre operațiunile IT și proprietarii de companii.

Imaginea se intitulează „Termologia protecției datelor”. Toleranța pentru pierderea de date și toleranța pentru durata întreruperii activității sunt reprezentate pe o linie dreaptă care se extinde în direcții opuse din centrul imaginii. În partea stângă este „pierderea de date”, iar în partea dreaptă este „perioada de inactivitate”.

Perioada de recuperare

Perioada de recuperare este timpul necesar pentru restabilirea unui sistem de business într-o stare complet operațională, după întreruperile planificate sau neplanificate.

Punctul de recuperare

Punctul de recuperare este cantitatea maximă de date care poate fi pierdută înainte de a cauza prejudicii grave oricărui sistem de business. De obicei, RPO reprezintă diferența față de cea mai recentă versiune a datelor din backup, replică sau instantaneu.

Recuperarea în caz de dezastru față de disponibilitatea ridicată

În mod tradițional, disponibilitatea ridicată (HA) protejează împotriva defecțiunilor singulare, în timp ce recuperarea în caz de dezastru protejează împotriva defecțiunilor repetate. La sistemele de calcul în cloud, protecția împotriva defecțiunilor singulare de la nivelul infrastructurii fizice, inclusiv alimentarea, răcirea, stocarea, rețelele și serverele, este complet abstractizată în arhitectura generală prin intermediul domeniilor de disponibilitate și de eroare.

În acest caz, disponibilitatea ridicată este scalabilă și extrem de rezistentă la pierderea datelor sau pierderea performanței de procesare. Aproape fiecare furnizor de servicii cloud de nivel corporativ include o disponibilitate ridicată în ofertă.

Soluțiile de recuperare în caz de dezastru cu disponibilitate ridicată care asigură protecția fără pierderi de date și fără întreruperea activității pentru bazele de date devin costisitoare atunci când este implicată maparea și replicarea complexă a datelor. Aceste soluții nu oferă protecție ransomware, care se obține printr-o copie de siguranță completă cu recuperarea la un termen și într-un spațiu de stocare prestabilite.

Soluțiile HA tradiționale funcționează bine împreună cu o soluție DR (CDR) cloud cu costuri mici. Tehnologia CDR de tip add-on oferă un nivel de protecție suplimentar pentru bazele de date care necesită zero pierderi de date, disponibilitate ridicată fără întreruperi și protecție la ransomware cu actualizare permanentă.

DR on-premises este o soluție inflexibilă și costisitoare, având în vedere costul ridicat al duplicării infrastructurii IT într-o locație sursă și o locație fixă a centrului de date vizat. Nu poate să funcționeze prin WAN sau să migreze servere între medii separate, deci necesită un circuit dedicat între centrele de date sursă și destinație pentru a funcționa ca un singur mediu LAN interconectat. De asemenea, DR tradițională nu poate migra servere între medii eterogene disparate, cum ar fi mediul on-premises și o platformă cloud sau două platforme cloud diferite.

DRaaS folosește un mozaic de soluții de backup de la furnizor și instrumente de migrare open-source pentru a crea un mediu controlat strict și extrem de specific. Utilizatorul final poate recupera doar sarcinile de lucru în mediul de găzduire tradițional al furnizorului de DRaaS din mediul VMware on-premises. Aceste soluții de la furnizori pot fi costisitoare și limitate în privința gamei de fluxuri de lucru pe care le pot proteja și a mediilor de calcul pe care le pot accepta.

Fluxuri de lucru, registre și planuri DR

Oracle se referă, de obicei, la un flux de lucru DR ca la un plan DR. Un plan de recuperare – sau un registru – în caz de dezastru este o listă de etape sau sarcini predeterminate care trebuie finalizate pentru transferarea instanței de calcul, platformei, bazei de date și aplicațiilor la o regiune de recuperare prestabilită din cloud. Acestea includ toate sarcinile sau etapele executate de o persoană sau de un sistem automat în timpul unei operațiuni de recuperare în caz de dezastru, precum un switchover sau failover. Termenii de plan DR, registru de rulare DR și flux de lucru DR sunt interschimbabili.

Operațiuni DR (switchover față de failover)

O operațiune de recuperare în caz de dezastru este procesul de executare a fiecărei etape sau sarcini prestabilite dintr-un plan DR, necesar pentru restabilirea infrastructurii, bazei de date și aplicațiilor la o stare complet operațională. Pentru a descrie transferarea stivei unei aplicații într-o altă locație, se folosesc doi termeni: failover și switchover.

Failover

Un failover implică o întrerupere neplanificată, în care aplicațiile, bazele de date și mașinile virtuale au cedat, iar toate resursele, inclusiv stocarea, datele și sistemele de operare vizitatoare, sunt într-o stare inconsecventă. În acest caz, se presupune că regiunea cloud principală este complet inaccesibilă și indisponibilă, ceea ce indică faptul că trebuie declanșată o operațiune de recuperare în caz de dezastru.

Prin urmare, toate sarcinile de recuperare în caz de dezastru dintr-un plan DR pot fi efectuate doar în regiunea cloud stand-by. Este esențial ca soluția DRaaS a unui furnizor de cloud să fie concepută pentru disponibilitate ridicată în regiunea de așteptare, astfel încât să fie accesibilă și funcțională în cazul unui dezastru de proporții catastrofale.

Switchover

Switchover implică o perioadă de inactivitate planificată, care include o oprire ordonată a aplicațiilor, bazelor de date și mașinilor sau serverelor virtuale. În acest caz, atât regiunea principală, cât și cea în stand-by funcționează normal, iar personalul de operațiuni IT se va concentra, probabil, pe „mutarea” unuia sau mai multor sisteme dintr-o regiune în alta pentru întreținere sau finalizarea upgrade-urilor curente.

Strategia de implementare în cloud

Companiile moderne pot profita de unul sau mai multe dintre modelele de implementare în cloud de mai jos, din diverse motive, inclusiv costuri, performanță și continuitatea activității. O strategie de implementare în cloud robustă devine tot mai răspândită, pe măsură ce companiile continuă să își mute operațiunile în cloud.

Soluții DR interregionale

Soluțiile interregionale de recuperare în caz de dezastre protejează organizațiile împotriva întreruperilor complete, care ar avea un impact asupra accesului la sistemele de business găzduite în infrastructura cloud a unui singur furnizor de cloud. După cum sugerează și numele, o întreagă stivă de aplicații pentru orice sistem de business, inclusiv mașinile virtuale, bazele de date și aplicațiile, poate fi transferată la cerere într-o regiune cloud complet diferită, într-o locație geografică diferită.

Soluțiile DRaaS trebuie să poată transfera un întreg sistem corporativ, cum ar fi un portal de resurse umane, un portal de servicii financiare sau o aplicație de management al resurselor companiei, într-o regiune cloud complet diferită. DRaaS ar trebui să poată îndeplini obiectivele privind perioada de recuperare și punctul de recuperare impuse de acordurile privind nivelul serviciilor pentru fiecare aplicație în parte.

Soluțiile DR interregionale precum Oracle Cloud Infrastructure (OCI) Full Stack Recovery protejează aplicații corporative întregi de pierderea catastrofală a accesului la o întreagă regiune cloud, inclusiv pierderea tuturor domeniilor de disponibilitate din acea regiune.

Soluții DR în cloud hibrid

DR în cloud hibrid este o soluție foarte populară, care le permite companiilor să își transfere sarcinile de lucru și mașinile virtuale de la propriile centre de date la infrastructura din cloud. Un cloud hibrid este folosit adesea ca soluție de recuperare în caz de dezastru pentru a proteja datele și viabilitatea sistemelor de business esențiale ale unei corporații.

Pentru clienții Oracle, cloudul hibrid este o configurație neconformă între OCI și serverele fizice, dispozitivele cloud Oracle sau alte sisteme din centrul de date fizic al unei companii. Aparatele cloud Oracle, cum ar fi Oracle Private Cloud Appliance X9-2 și Oracle Exadata Cloud@Customer, sunt exemple excelente de sisteme on-premises care se integrează bine cu OCI.

Unele produse de la partenerii Oracle, cum ar fi Rackware, pot fi utilizate pentru obținerea DR între infrastructura on-premises și OCI. Rackware este disponibil prin Oracle Cloud Marketplace.

Soluții DR multicloud

Soluțiile DR multicloud protejează aplicațiile și datele prin răspândirea diverselor componente ale unei stive de aplicații în infrastructurile cloud a doi sau mai mulți furnizori de cloud. Parteneriatul dintre Oracle și Microsoft Azure este un exemplu bun de relație multicloud.

Recuperarea în caz de dezastru ca serviciu trebuie să permită DR la nivel interregional, DR în cloud hibrid și DR multicloud. OCI poate furniza în prezent DRaaS pentru DR la nivel interregional și DR în cloud hibrid.

Consecvența datelor pentru bazele de date

Soluțiile de recuperare în caz de dezastru viabile în care sunt implicate baze de date ar trebui să includă întotdeauna mijloacele prin care să asigure consecvența datelor. Punctul în care o bază de date poate fi recuperată pentru consecvența completă a datelor, inclusiv tranzacțiile în curs, definește obiectivul punctului de recuperare.

Consecvența datelor este o problemă mult mai mică pentru bazele de date serverless sau pentru fișiere nestructurate, dar recuperarea bazelor de date relaționale sofisticate, cum ar fi Oracle Database sau MySQL, într-o stare în care datele sunt consecvente la un moment dat este foarte complexă – dar esențială.

Considerații privind recuperarea în caz de dezastru pentru bazele de date MySQL

Când utilizați MySQL Database Service în OCI, un sistem de baze de date MySQL reprezintă un container logic pentru una sau mai multe instanțe MySQL. Acesta oferă o interfață care permite gestionarea sarcinilor precum alocarea, copierea de siguranță automată, precum și recuperarea de la un anumit moment din timp.

Tehnologiile MySQL de jurnalizare binară și de replicare nativă permit recuperarea de la un anumit moment din timp, cu disponibilitate ridicată și recuperare în caz de dezastru. MySQL Group Replication se utilizează de obicei pentru crearea de clustere locale tolerante la eșec pentru disponibilitate ridicată, în timp ce replicarea asincronă MySQL se utilizează de obicei pentru recuperarea în caz de dezastru distribuită geografic.

Un sistem de baze de date cu disponibilitatea ridicată activată are trei instanțe MySQL plasate în domenii de disponibilitate diferite sau domenii cu toleranță la eșec. Sistemul bazei de date garantează că, dacă o instanță eșuează, alta preia controlul, fără pierderi de date și cu perioade de inactivitate minime. Pentru recuperarea în caz de dezastru în diferite regiuni, pot fi create, de asemenea, canale de replicare în intrare între două sisteme de baze de date.

Pentru a afla mai multe despre recuperarea în caz de dezastru pentru MySQL în cloud, accesați linkurile care urmează.

• Prezentare generală pentru continuitatea activității în cazul MySQL
• Prezentare generală pentru disponibilitatea ridicată în cazul MySQL
• Prezentare generală pentru replicarea de intrare în cazul MySQL

Considerații privind recuperarea în caz de dezastru pentru bazele de date Oracle

Oracle Maximum Availability Architecture (MAA) oferă cele mai bune practici pentru arhitectura, configurarea și ciclul de viață ale bazelor de date Oracle, oferind niveluri de servicii cu disponibilitate ridicată pentru bazele de date din configurații on-premises, cloud sau hibride.

Pentru a afla mult mai multe despre Oracle Maximum Availability Architecture pentru recuperarea în cloud în caz de dezastru, accesați linkurile care urmează.

• Pagina de destinație Oracle Maximum Availability Architecture
• Arhitecturi de referință Oracle Maximum Availability Architecture
• Cele mai bune practici pentru Oracle Fusion Middleware în Oracle Maximum Availability Architecture
• Cele mai bune practici pentru aplicațiile din Oracle Maximum Availability Architecture

Arhitecturi de implementare bazate pe cloud

Arhitectura de implementare descrie modul în care sunt implementate diferite componente, precum calculul, platforma/baza de date și aplicațiile, între regiunile cloud, pentru a crea un mijloc de recuperare rezistent după căderea totală a unui centru de date. Arhitectura de implementare descrie locurile în care se află totul în timpul funcționării normale a unei suite de aplicații și ce trebuie recuperat în regiunea stand-by pentru a se repune totul în funcțiune.

Oracle consideră că soluțiile DRaaS trebuie să aibă flexibilitatea de a încorpora orice combinație de arhitecturi de implementare DR pentru a satisface cerințele individuale ale nivelului serviciilor pentru fiecare sistem corporativ în parte. Furnizorii de cloud trebuie să le ofere clienților libertatea de a alege „toate soluțiile de mai sus”, astfel încât să fie îndeplinite cerințele SLA pentru o gamă largă de sisteme de business pe care organizațiile le acceptă în mod obișnuit.

Pentru descrierea strategiilor și arhitecturilor de implementare ale DR, se folosesc mai mulți termeni. Totuși, diferitele abordări și tipare pentru descrierea modului de implementare a infrastructurii, platformei și aplicațiilor de recuperare în caz de dezastru se încadrează în două mari categorii strategice: DR activ/activ și DR activ/stand-by.

Tabelul următor prezintă termenii utilizați frecvent pentru a descrie diferitele arhitecturi de implementare care intră sub incidența celor două strategii generale de DR.

Strategie	Arhitectura de implementare	RPO	RTO
Activ/stand-by	Stand-by rece	Ore	Ore
Activ/stand-by	Lumină pilot	Minute	Ore
Activ/stand-by	Stand-by cald	Secunde	Ore
Activ/stand-by	Stand-by fierbinte	Secunde	Minute
Activ/activ	Activ/activ	Aproape zero	Aproape zero

Această secțiune încearcă să demistifice unele dintre variațiile metodelor activ/activ și activ/stand-by privind recuperarea în caz de dezastru. Ambele strategii de recuperare în caz de dezastru își au locul în arsenalul disponibil pentru asigurarea continuității activității.

Arhitecturi de implementare activ/stand-by

Există multe variante de arhitecturi de implementare activ/stand-by. Implementările activ/stand-by, denumite uneori implementări activ/pasiv, sunt deseori caracterizate ca implementări de tip lumină pilot, stand-by rece, stand-by cald și stand-by fierbinte.

Scenariile de tip lumină pilot, stand-by rece, stand-by cald și stand-by fierbinte reprezintă, toate, variațiuni pe aceeași temă, întreaga stivă de aplicații rulând în regiunea principală, în timp ce o parte a aceluiași sistem corporativ rulează activ în regiunea stand-by.

Următoarea serie de diagrame conceptuale de nivel foarte înalt are scopul de a ilustra unele diferențe fundamentale între arhitecturile de implementare comune, nefiind considerate arhitecturi de referință; ele nu descriu modul de implementare a DR pentru o stivă de aplicații.

Stand-by rece

În acest scenariu, mașinile virtuale (VM), baza de date și aplicațiile există doar în regiunea principală curentă. Grupurile de volume de stocare pentru fișiere și blocuri care conțin discul de inițializare și orice alte discuri virtuale pentru fiecare mașină virtuală sunt replicate în regiunea stand-by.

Afișează o imagine cu regiunea principală în stânga și regiunea stand-by în dreapta. Regiunea principală are trei blocuri: aplicație, bază de date și infrastructură, fiecare conținând propriile sale pictograme. Ambele regiuni au o pictogramă care reprezintă un load balancer în partea de sus. Pictograma load balancer din regiunea în stand-by este într-o nuanță mai deschisă decât cea din regiunea principală. Regiunea în stand-by are trei blocuri: aplicație, bază de date și infrastructură. În regiunea în stand-by, doar blocul de infrastructură este populat cu pictograme – câte una pentru stocarea obiectelor, stocarea în blocuri și stocarea fișierelor. Baza de date și blocurile de aplicații din regiunea în stand-by sunt goale. Două săgeți, care reprezintă replicarea Object Storage și replicarea Storage, sunt afișate între cele două blocuri de infrastructură. Aceste săgeți reprezintă replicarea din regiunea principală în regiunea în stand-by.

În timpul unei operațiuni de DR, cum ar fi un switchover sau un failover, spațiul de stocare replicat care conține aceleași mașini virtuale este activat în regiunea în stand-by, iar exact aceleași mașini virtuale sunt repornite de la momentul în care s-au oprite sau defectat. Mașinile virtuale sunt exact aceleași care rulau anterior în regiunea activă.

Această arhitectură de implementare are mai multe avantaje, inclusiv costuri de implementare, costuri indirecte de întreținere și costuri operaționale mai mici. Totuși, aceasta nu este soluția cea mai bună pentru aplicațiile care se bazează pe baze de date relaționale pentru back-end, deoarece singura modalitate de a asigura consecvența datelor este efectuarea periodică de backupuri la rece. Această abordare funcționează bine pentru aplicațiile care pot tolera scurte întreruperi totale ocazionale.

Majoritatea operațiunilor IT rezolvă această problemă prin închiderea periodică a bazei de date, preluarea unui instantaneu al stocării în blocuri și apoi reluarea operațiunilor normale. Acesta este obiectivul punctului de recuperare, deoarece puteți restabili doar de la momentul finalizării copiei de siguranță.

Această arhitectură va avea o perioadă de recuperare puțin mai lungă și există un risc mult mai mare de pierdere a datelor, dar este o soluție viabilă pentru fluxurile de lucru corecte. De exemplu, această soluție poate fi ideală pentru aplicațiile care se bazează pe o bază de date cu fișiere nestructurate, o bază de date fără server sau pe nicio bază de date ori pentru clienții care doresc doar să creeze un set de mașini virtuale mobile între regiuni, pentru un nivel mai ridicat de flexibilitate.

Exemple de fluxuri de lucru DR pentru această arhitectură de implementare

Următoarele două scenarii arată cum decurge procesul pentru operațiunile DR în cazul implementărilor în stand-by rece.

În cazul unui switchover, următoarele sarcini vor fi efectuate și în regiunea principală, dar și în cea în stand-by:

• Aplicațiile primare sunt verificate.
• Bazele de date principale sunt verificate și sincronizate în regiunea în stand-by.
• Mașinile virtuale principale sunt oprite lin.
• Spațiul de stocare principal este sincronizat cu regiunea în stand-by.
• Spațiul de stocare replicat este online, replicarea este inversată și acum este principală în regiunea în stand-by.
• Sunt lansate copiile replicate ale mașinilor virtuale principale și sunt pornite toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații, fiind acum principale în regiunea în stand-by.
• Copiile replicate ale bazelor de date principale sunt recuperate în regiunea în stand-by utilizând cele mai recente copii de siguranță sau tranzacții la rece și jurnale de repetare din spațiul de stocare replicat.
• Copiile replicate ale bazelor de date principale sunt pornite și montate și acum sunt principale în regiunea în stand-by.
• Copiile replicate ale aplicațiilor principale sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

În cazul unui failover, următoarele sarcini sunt efectuate doar în regiunea în stand-by:

• Spațiul de stocare replicat este online, replicarea este inversată și acum este principală în regiunea în stand-by.
• Sunt lansate copiile replicate ale mașinilor virtuale principale și sunt pornite toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații, fiind acum principale în regiunea în stand-by.
• Copiile replicate ale bazelor de date principale sunt recuperate în regiunea în stand-by utilizând cele mai recente copii de siguranță sau tranzacții la rece și jurnale de repetare din spațiul de stocare replicat.
• Copiile replicate ale bazelor de date principale sunt pornite și montate și acum sunt principale în regiunea în stand-by.
• Copiile replicate ale aplicațiilor principale sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

Stand-by cald

În acest scenariu, mașinile virtuale există și în regiunea principală, dar și în cea în stand-by, dar sunt complet independente unele față de altele și au propriile nume de gazde unice și adrese de IP prealocate. Mașinile virtuale din regiunea în stand-by există și pot fi oprite sau rulate în funcție de preferințele clientului.

Afișează o imagine cu regiunea principală în stânga și regiunea stand-by în dreapta. Regiunea principală are trei blocuri: aplicație, bază de date și infrastructură, fiecare conținând propriile sale pictograme. Ambele regiuni au o pictogramă care reprezintă un load balancer în partea de sus. Pictograma load balancer din regiunea în stand-by este într-o nuanță mai deschisă decât cea din regiunea principală. Regiunea în stand-by are trei blocuri: aplicație, bază de date și infrastructură. În regiunea în stand-by, blocul de infrastructură este populat cu pictograme – câte una pentru stocarea obiectelor, stocarea în blocuri și stocarea fișierelor. Există o pictogramă și pentru mașinile virtuale la nivel de infrastructură, dar are o nuanță mai deschisă. Pictogramele bazei de date și pictograma aplicației din regiunea în stand-by sunt, de asemenea, într-o nuanță mai deschisă. Două săgeți, care reprezintă replicarea Object Storage și replicarea Storage, sunt afișate între cele două blocuri de infrastructură. Aceste săgeți reprezintă replicarea din regiunea principală în regiunea în stand-by.

Bazele de date trebuie să ruleze în regiunea principală și în cea în stand-by.

Pentru bazele de date Oracle, recomandăm utilizarea Oracle Data Guard pentru replicarea bazei de date principală și bazei de date în stand-by. Pentru mai multe detalii, consultați arhitectura noastră de referință Gold MAA.

Pentru bazele de date non-Oracle, se vor utiliza tehnologiile de replicare native corespunzătoare, pentru menținerea bazelor de date sincronizate între regiunea principală și cea în stand-by.

Și în regiunea cloud în stand-by există aplicații, dar nu rulează și nu sunt accesibile.

Exemple de fluxuri de lucru DR pentru această arhitectură de implementare

Următoarele două scenarii arată cum decurge procesul pentru operațiunile DR în cazul implementărilor în stand-by cald.

În cazul unui switchover, următoarele sarcini vor fi efectuate și în regiunea principală, dar și în cea în stand-by:

• Aplicațiile primare sunt verificate.
• Bazele de date principale sunt verificate și sincronizate în regiunea în stand-by.
• Mașinile virtuale principale sunt oprite lin.
• Spațiul de stocare principal este sincronizat cu regiunea în stand-by.
• Spațiul de stocare replicat este online, replicarea este inversată și acum este principală în regiunea în stand-by.
• Mașinile virtuale în stand-by sunt pornite, dacă nu funcționează deja, iar toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații sunt lansate, fiind acum principale în regiunea în stand-by.
• Bazele de date în stand-by sunt comutate la acces complet citire/scriere și sunt acum principale în regiunea în stand-by.
• Aplicațiile în stand-by sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

În cazul unui failover, următoarele sarcini sunt efectuate doar în regiunea în stand-by:

• Spațiul de stocare replicat este online, replicarea se inversează, dacă este posibil, devenind principală în regiunea în stand-by.
• Mașinile virtuale în stand-by sunt pornite, dacă nu funcționează deja, iar toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații sunt lansate, fiind acum principale în regiunea în stand-by.
• Bazele de date în stand-by sunt recuperate utilizându-se cele mai recente jurnale de tranzacții și de repetare din spațiul de stocare replicat.
• Bazele de date în stand-by sunt comutate la acces complet citire/scriere și sunt acum principale în regiunea în stand-by.
• Aplicațiile în stand-by sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

Stand-by fierbinte

În acest scenariu, mașinile virtuale există și rulează și în regiunea principală, și în cea în stand-by, cu propriile nume de gazde unice și adrese IP prealocate.

Afișează o imagine cu regiunea principală în stânga și regiunea stand-by în dreapta. Regiunea principală are trei blocuri: aplicație, bază de date și infrastructură, fiecare conținând propriile sale pictograme. Ambele regiuni au o pictogramă care reprezintă un load balancer în partea de sus. Pictograma load balancer din regiunea în stand-by este într-o nuanță mai deschisă decât cea din regiunea principală. Regiunea în stand-by are trei blocuri: aplicație, bază de date și infrastructură. Atât regiunea principală, cât și cea în stand-by au pictograme în blocurile aplicației, bazei de date și infrastructurii. Blocul de infrastructură are pictograme pentru mașinile virtuale, spațiul de stocare pentru fișiere, spațiul de stocare pentru obiecte și spațiul de stocare în blocuri, atât în regiunea principală, cât și în cea în stand-by. Doar pictogramele bazei de date din regiunea în stand-by sunt într-o nuanță mai deschisă. Două săgeți, care reprezintă replicarea Object Storage și replicarea Storage, sunt afișate între cele două blocuri de infrastructură. Aceste săgeți reprezintă replicarea din regiunea principală în regiunea în stand-by.

Bazele de date trebuie să ruleze în regiunea principală și în cea în stand-by.

Pentru bazele de date Oracle, recomandăm utilizarea Oracle Data Guard pentru replicarea bazei de date principală și bazei de date în stand-by. Pentru mai multe detalii, consultați arhitectura noastră de referință Gold MAA.

Pentru bazele de date non-Oracle, se vor utiliza tehnologiile de replicare native corespunzătoare, pentru menținerea bazelor de date sincronizate între regiunea principală și cea în stand-by.

Aplicațiile rulează în regiunea cloud în stand-by, dar nu sunt accesibile prin rețeaua publică.

Exemple de fluxuri de lucru DR pentru această arhitectură de implementare

Următoarele două scenarii arată cum decurge procesul pentru operațiunile DR în cazul implementărilor în stand-by fierbinte.

În cazul unui switchover, următoarele sarcini vor fi efectuate și în regiunea principală, dar și în cea în stand-by:

• Aplicațiile primare sunt verificate.
• Bazele de date principale sunt verificate și sincronizate în regiunea în stand-by.
• Mașinile virtuale principale sunt oprite lin.
• Spațiul de stocare principal este sincronizat cu regiunea în stand-by.
• Spațiul de stocare replicat este online, replicarea este inversată și acum este principală în regiunea în stand-by.
• Mașinile virtuale în stand-by deja funcționează, iar toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații sunt lansate, fiind acum principale în regiunea în stand-by.
• Bazele de date în stand-by sunt comutate la acces complet citire/scriere și sunt acum principale în regiunea în stand-by.
• Aplicațiile în stand-by sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

În cazul unui failover, următoarele sarcini sunt efectuate doar în regiunea în stand-by:

• Spațiul de stocare replicat este online, replicarea se inversează, dacă este posibil, devenind principală în regiunea în stand-by.
• Mașinile virtuale în stand-by sunt pornite, dacă nu funcționează deja, iar toate aplicațiile sau instrumentele de sistem necesare în stiva de aplicații sunt lansate, fiind acum principale în regiunea în stand-by.
• Bazele de date în stand-by sunt recuperate utilizându-se cele mai recente jurnale de tranzacții și de repetare din spațiul de stocare replicat.
• Bazele de date în stand-by sunt comutate la acces complet citire/scriere și sunt acum principale în regiunea în stand-by.
• Aplicațiile în stand-by sunt lansate și validate, fiind acum principale în regiunea în stand-by.
• Pentru a se permite accesul la aplicație prin rețeaua publică, se efectuează modificările necesare la DNS și load balancere.

Arhitecturi de implementare activ/activ

În acest scenariu, întreaga stivă a aplicației este complet funcțională și tratează o sarcină de lucru atât în regiunea principală, cât și în cea în stand-by.

Afișează o imagine cu regiunea principală în stânga și regiunea stand-by în dreapta. Atât regiunea principală, cât și cea în stand-by au câte trei blocuri: aplicație, bază de date și infrastructură, fiecare conținând propriile sale pictograme. Ambele regiuni au o pictogramă care reprezintă un load balancer în partea de sus. Niciuna nu este gri. Pictogramele din aplicație, din baza de date și din blocurile infrastructurii, atât în regiunea principală, cât și în cea în stand-by, sunt colorate. O săgeată, care reprezintă replicarea opțională a spațiului de stocare, este afișată între cele două blocuri de infrastructură. Această săgeată reprezintă replicarea din regiunea principală în regiunea în stand-by.

Bazele de date trebuie să ruleze în regiunea principală și în cea în stand-by.

În cazul bazelor de date Oracle, recomandăm utilizarea Oracle GoldenGate pentru a se obține o configurație activ/activ a aplicației. În plus, recomandăm ca bazele de date în stand-by locale din fiecare regiune să utilizeze Oracle Data Guard pentru ca RTO și RPO să fie aproape zero. Pentru mai multe detalii, consultați arhitectura noastră de referință Platinum MAA.

Pentru bazele de date non-Oracle, se vor utiliza tehnologiile de replicare native și activ/activ corespunzătoare, pentru menținerea fiecărei baze de date sincronizată între regiunea principală și cea în stand-by.

Aplicațiile rulează și pot fi accesate prin rețeaua cu acces public din regiunea cloud în stand-by, după care au o sarcină de lucru continuă.

Automatizarea sarcinilor de recuperare în caz de dezastru cu ajutorul DRaaS

Echipele Oracle s-au străduit să creeze o disponibilitate ridicată a produselor lor – inclusiv marea majoritate a bazelor de date și aplicațiilor de nivel enterprise de la Oracle – și, adesea, utilizează cele mai bune practici și arhitecturi de implementare pentru recuperarea în caz de dezastru în configurațiile on-premises tradiționale, precum și în cloud. Fiecare serie de produse utilizează pentru aplicațiile sale o abordare DR proprie, care încorporează etape conectate flexibil pentru recuperarea tuturor componentelor necesare susținerii aplicației respective.

Recuperarea în urma dezastrelor bazată pe cloud ca serviciu poate lega toate etapele flexibile concepute de dezvoltatori, arhitecți de cloud și arhitecți de soluții pentru produse într-un singur flux de lucru perfect, care poate fi inițiat cu un singur clic. OCI oferă o soluție DRaaS denumită Full Stack Disaster Recovery (Recuperare completă în caz de dezastru în stivă flexibilă), care este extrem de scalabilă și de extensibilă.

OCI Full Stack Disaster Recovery gestionează transferul infrastructurii, bazelor de date și aplicațiilor între regiunile OCI din orice parte a lumii cu un singur clic. Clienții pot implementa medii de recuperare în caz de dezastru fără a reproiecta sau reimplementa infrastructura, bazele de date sau aplicațiile existente, eliminându-se totodată necesitatea unor servere de gestionare sau de conversie specializate.

• Aflați mai multe despre OCI Full Stack Disaster Recovery
• Aflați mai multe despre recuperarea în caz de dezastru pentru OCI