Recuperarea In Caz de Dezastru
CUPRINS
1. INTRODUCERE
2. PLANIFICAREA RECUPERĂRII ÎN CAZ DE DEZASTRU
2.1. Identificarea și analiza riscurilor și amenințărilor în caz de dezastru
2.2. Clasificarea riscurilor pe ponderile relative
2.2.1. Riscuri externe
2.2.2. Riscuri facile
2.2.3. Riscurile sistemului de fisiere
2.2.4. Riscuri departamentale
2.2.5. Riscurile la nivel de birou
2.3. Evaluarea riscurilor
2.4. Determinarea efectelor dezastrelor
2.4.1. Lista entităților afectate de dezastrul
2.4.2. Limitele de toleranță și timpul de nefuncționare
2.4.3. Costul timpului de nefuncționare
2.4.4. Interdependența
2.5. Evaluarea mecanismelor de recuperare în caz de catastrofe
2.6. Comitetul de recuperare în caz de dezastru
3. PASII DE RECUPERARE IN CAZ DE DEZASTRU
3.1. Faza de activare a dezastrului
3.1.1. Proceduri de notificare
3.1.2. Evaluarea pagubelor
3.1.3. Activarea planificării
3.2. Faza de execuție
3.2.1. Secventa de recuperare a activității
3.2.2. Limite de toleranta in cazul punctelor de reluare RPO si RTO
3.2.3. Proceduri de recuperare
3.3. Faza de reconstituire
4. ALTERNATIVĂ AUTOMATIZATĂ LA UN DISASTER RECOVERY
4.1. Dezastre de tip "[NUME_REDACTAT]" într-un IMM
4.2. Recuperare în caz de dezastru între mit și realitate.
4.3. Ghid SRM, privire de ansamblu asupra modului de configurare
5. PLANUL DOCUMENTULUI DISASTER RECOVERY
5.1. Cuprins document
5.2. [NUME_REDACTAT]
6. REFERINȚE
CUPRINS
1. INTRODUCERE
2. PLANIFICAREA RECUPERĂRII ÎN CAZ DE DEZASTRU
2.1. Identificarea și analiza riscurilor și amenințărilor în caz de dezastru
2.2. Clasificarea riscurilor pe ponderile relative
2.2.1. Riscuri externe
2.2.2. Riscuri facile
2.2.3. Riscurile sistemului de fisiere
2.2.4. Riscuri departamentale
2.2.5. Riscurile la nivel de birou
2.3. Evaluarea riscurilor
2.4. Determinarea efectelor dezastrelor
2.4.1. Lista entităților afectate de dezastrul
2.4.2. Limitele de toleranță și timpul de nefuncționare
2.4.3. Costul timpului de nefuncționare
2.4.4. Interdependența
2.5. Evaluarea mecanismelor de recuperare în caz de catastrofe
2.6. Comitetul de recuperare în caz de dezastru
3. PASII DE RECUPERARE IN CAZ DE DEZASTRU
3.1. Faza de activare a dezastrului
3.1.1. Proceduri de notificare
3.1.2. Evaluarea pagubelor
3.1.3. Activarea planificării
3.2. Faza de execuție
3.2.1. Secventa de recuperare a activității
3.2.2. Limite de toleranta in cazul punctelor de reluare RPO si RTO
3.2.3. Proceduri de recuperare
3.3. Faza de reconstituire
4. ALTERNATIVĂ AUTOMATIZATĂ LA UN DISASTER RECOVERY
4.1. Dezastre de tip "[NUME_REDACTAT]" într-un IMM
4.2. Recuperare în caz de dezastru între mit și realitate.
4.3. Ghid SRM, privire de ansamblu asupra modului de configurare
5. PLANUL DOCUMENTULUI DISASTER RECOVERY
5.1. Cuprins document
5.2. [NUME_REDACTAT]
6. REFERINȚE
1. INTRODUCERE
Dezastrele sunt inevitabile și în mare parte imprevizibile, ele variază în tip și mărime. Cea mai bună strategie este de a avea un plan de recuperare în caz de dezastru, pentru a reveni la normal după ce acesta a lovit. Pentru un IMM, un dezastru înseamnă întrerupere bruscă totală sau parțială a operațiunilor sale de afaceri, ceea ce poate duce direct la pierderi de venituri. Pentru a reduce la minimum pierderile în caz de dezastru, este foarte important a deține un bun plan de recuperare în caz de dezastru pentru fiecare subsistem de afaceri funcțional din cadrul unui IMM.
Această lucrare discută o abordare pentru a crea un bun plan de recuperare în caz de dezastru pentru o întreprindere de afaceri. Liniile directoare sunt generice în natură, prin urmare, ele pot fi aplicate la orice subsistem de afaceri în cadrul unui IMM .
În subsistemul IT, de recuperare în caz de dezastru nu exista o disponibilitate la fel de mare. Deși ambele concepte sunt legate de continuitatea afacerii, disponibilitatea mare este furnizarea continuității operațiunilor, în timp ce recuperarea în caz de catastrofe implică o anumită cantitate de nefuncționare, de obicei, măsurată în zile. Această lucrare se concentrează doar pe recuperare în caz de dezastru .
Fiecare dezastru are una sau mai multe cauze și efecte. Cauzele pot fi naturale, umane sau mecanice la origine, variind de la evenimente, cum ar fi defecte de hardware sau software, la evenimente cum ar fi cutremure, incendii, inundații și altele. Efectele dezastrelor variază de la mici întreruperi până la oprirea totală a afacerii pentru zile sau luni, chiar fatale pentru afacere.
Procesul de elaborare a unui plan de recuperare în caz de dezastru începe prin identificarea acestor cauze și efecte, analiza, probabilitatea si severitatea lor, și clasificarea acestora în funcție de prioritatea lor în afacerea IMM-ului. Rezultatele finale sunt o evaluare formală a riscului unui plan de recuperare în caz de dezastru, care include toate mecanismele de recuperare disponibile, și un comitet de recuperare în caz de catastrofe nominalizat care are responsabilitatea pentru realizarea și îmbunătățirea planului de redresare în caz de dezastru .
Atunci când dezastrul apare, operațiunile normale ale IMM-ului sunt suspendate și înlocuite cu operațiunile enunțate în planul de recuperare în caz de dezastru . Figura de mai jos prezintă ciclul pe etape care conduc cazul de dezastru la o stare de normalitate. ( vezi figura 1)
Figura 1 . [NUME_REDACTAT] de [NUME_REDACTAT] nevoie de ceva timp într-o întreprindere pentru a evalua efectele exacte ale dezastrului. Numai atunci când acestea sunt evaluate corect și sunt identificate sistemele afectate poate începe un proces de recuperare. Sistemul de recuperare în caz de dezastru nu poate înlocui sistemul normal de lucru pentru totdeauna, dar îl poate suporta pentru o perioadă scurtă de timp. În cel mai scurt timp posibil, procesul de recuperare în caz de dezastru trebuie să fie pus în funcțiune ca afacerea să revină la normal și fără pierderi financiare.
Planul de recuperare în caz de dezastru nu se oprește la definirea resurselor sau proceselor care trebuiesc recuperate în caz de dezastru. Planul ar trebui, de asemenea, să definească modul de a restabili operațiunile la o stare normală, odată ce efectele dezastrului sunt atenuate. În cele din urmă, procedurile în curs de desfășurare pentru testarea și îmbunătățirea eficienței sistemului de recuperare în caz de dezastru sunt parte a unui bun plan de recuperare în caz de dezastru .
Pe scurt, planul de recuperare în caz de dezastru ar trebui să :
(1) identifice și să clasifice amenințările / riscurile care pot duce la dezastre,
(2) să definească resursele și procesele care asigura continuitatea afacerii în timpul dezastrului,
(3) să definească mecanismul de reconstituire pentru ca afacerea să revină la normal, după ce efectele dezastrului sunt atenuate .
2. PLANIFICAREA RECUPERĂRII ÎN CAZ DE DEZASTRU
Această secțiune explică diversele proceduri / metode implicate în planificarea de recuperare în caz de dezastru.
2.1. Identificarea și analiza riscurilor și amenințărilor în caz de dezastru
Primul pas în planificarea de recuperare în caz de catastrofe neașteptate este de a identifica amenințările și riscurile care pot duce la dezastre, de a face o analiză de risc care acoperă amenințările la continuitatea afacerii. Analiza de risc ( uneori numită analiză de impact de afaceri ) implică evaluarea sistemelor de securitate și control fizic și de mediu existente, și evaluarea adecvată a acestora cu privire la potențialele amenințări .
Procesul de analiză a riscului începe cu o listă a funcțiilor esențiale ale afacerii . Această listă va stabili prioritățile în vederea abordării riscurilor . Funcțiile esențiale sunt cele ale căror întrerupere ar putea perturba considerabil operațiunile de afaceri și poate duce la pierderi financiare .
Aceste funcții esențiale ar trebui să fie prioritizate în funcție de importanța lor relativă pentru operațiunile de afaceri . De exemplu, în cazul unui furnizor de servicii de telecomunicații, deși operațiunile de facturare și operațiunile CRM / helpdesk sunt funcții esențiale, CRM / helpdesk este mai important decât operațiunea de facturare .
Prin urmare, diminuarea riscurilor care afectează operațiunile de facturare sunt mai putin importante decât operațiunile de CRM / helpdesk .
În timpul evaluării unui risc apar urmatoarele atribute (vezi figura 2).
Figura 2 . Atribute de risc
Domeniul de aplicare al unui risc este determinat de daunele posibile, în termeni de nefuncționare sau de costul de oportunități pierdute. În evaluarea un risc, este esențial să se țină cont de opțiunile din jurul acestui risc, cum ar fi ora din zi sau ziua din săptămână, care pot afecta domeniul său de aplicare. Locația unde a lovit dezastrul, este un alt atribut important, la fel ca impactul asupra sistemelor din IMM.
Magnitudinea de risc poate fi diferită, având în vedere componentele afectate, localizarea componentelor afectate, precum și momentul apariției . Efectele unui dezastru care lovește întreaga întreprindere sunt diferite de efectele unui dezastru care afectează o anumită zonă sau un anumit birou din cadrul IMM-ului.
2.2. Clasificarea riscurilor pe ponderile relative
La evaluarea riscurilor, se recomandă clasificarea, în clase diferite pentru a le prioritiza corect. În general, riscurile pot fi clasificate în următoarele cinci categorii .
2.2.1 Riscuri externe
Riscurile externe sunt cele care nu pot fi asociate cu un eșec în cadrul IMM-ului. Ele sunt foarte importante în măsura în care nu sunt sub controlul direct al organizației care se confruntă cu pagubele . Riscurile externe pot fi împărțite în patru subcategorii :
Naturale: aceste dezastre sunt în fruntea listei în fiecare plan de recuperare în caz de dezastru. De obicei, deteriorează o zonă geografică mare . Pentru a reduce riscul de întrerupere a operațiunilor de afaceri, o soluție de recuperare ar trebui să implice facilități de recuperare în caz de catastrofe într-o locație la distanță de zona afectată. În prezent cele mai multe dintre amenințările meteorologice pot fi prognozate, prin urmare, șansele de atenuare a efectelor unor dezastre naturale sunt considerabile. Cu toate acestea, este important să ia în considerare și documentarea domeniului de aplicare a acestor riscuri naturale, în cât mai multe detalii posibile.
Umane provocate: Aceste dezastre includ actele de terorism, actele de sabotaj, atacuri de virus, operațiuni greșite, crime, și așa mai departe.
Civil: Aceste riscuri sunt de obicei legate de locul facilități de afaceri. Riscuri civile tipice includ litigiile de muncă care se încheie în greve, revolte sociale, instabilitatea politică locală și așa mai departe.
Furnizor: Aceste riscuri sunt legate de capacitatea furnizorilor de a menține nivelul lor de servicii într-un dezastru. Este necesară menținerea unui furnizor de rezervă pentru cazurile de urgență .
2.2.2 [NUME_REDACTAT]
Riscurile facile sunt utilitățile esențiale, considerate și produse de bază .
Electricitatea : Pentru a analiza riscul de pană de curent, este important să se studieze frecvența penelor de curent și durata fiecărei pene. De asemenea, este util pentru a se determina care este consumul real în cadrul instalației și dacă este necesar, refacerea sistemul de alimentare.
Telefoane : Telefoanele sunt un serviciu deosebit de important în timpul unui dezastru. Un factor cheie în evaluarea riscurilor asociate cu sistemele de telefonie este studierea arhitecturii de telefonie și conceperea unei infrastructuri suplimentare daca este cazul pentru reducerea riscului de a pierde întregul serviciu de telecomunicații în timpul unui dezastru .
De apă: Există anumite scenarii de dezastru în care întreruperile de apă trebuie să fie luate în considerare foarte serios, de exemplu, o oprire de apă pe sistemul de răcire a unui calculator.
Control climatic: Pierderea sistemul de aer condiționat sau de încălzire pot produce diferite riscuri.
Foc: În cazul riscului de incendiu multi factori sunt afectati, de exemplu locația, materialele din locație, întreprinderea în sine și structurile invecinate și altele. Diminuarea factorilor afectati în caz de incendiu trebuiesc luate în considerare în timpul evaluării de risc.
Structurale : riscurile structurale pot fi legate de greșeli de proiectare, materiale de construcție defecte, de proastă calitate sau reparate .
Securitate fizică : riscurile de securitate au atras atenția în ultimii ani. În zilele noastre securitatea este o măsură obligatorie, 24 de ore din 24, pentru a proteja fiecare activ al companiei și nu în ultimul rând pe angajați . Factori, cum ar fi violența la locul de muncă, amenințări cu bombă, sabotaj și pierderile de proprietate intelectuală sunt, de asemenea, luate în considerare în timpul analizei de risc de securitate .
2.2.3 Riscurile sistemului de fisiere
Riscurile sistemelor de fișiere sunt cele legate de utilizarea infrastructurii în comun, cum ar fi rețelele, servere de fișiere, precum și aplicații software care ar putea afecta mai multe departamente. Un obiectiv – cheie în analiza acestor riscuri este de a identifica toate punctele unice de eșec în cadrul arhitecturii sistemelor de date .
Riscurile sistemelor de date pot apărea și din cauza proceselor de funcționare necorespunzătoare . Operațiuni care au fost difuzate pentru o perioadă lungă de timp pe hardware sau software învechit sunt un risc major, având în vedere lipsa de piese de schimb sau de sprijin. Recuperarea acestui tip de eșec poate fi de lungă durată și costisitoare din cauza necesității de a înlocui sau de a actualiza software-ul și echipamentele și chiar recalificarea personalului .
Riscurilor de sisteme de date pot fi evaluate în următoarele subcategorii :
● rețea de comunicații de date
● sisteme de telecomunicatii și rețea
● servere partajate
● Virus
● sisteme de backup de date / stocare
● aplicații software și bug-uri
2.2.4 Riscuri departamentale
Riscurile departamentale sunt eșecurile în cadrul unor departamente. Evenimente, cum ar fi un incendiu într-o zonă în care sunt depozitate lichide inflamabile, sau o cheie de la o usa importantă lipsă .
O evaluare eficientă a riscurilor departamentale trebuie să ia în considerare toate funcțiile critice din departament, echipamentul de operare și înregistrările vitale ale căror absență sau pierderi vor compromite operațiunile. Indisponibilitatea de personal calificat, de asemenea, poate fi un risc departamental. Departamentul ar trebui să aibă planuri necesare pentru a avea personal calificat de rezervă în loc .
2.2.5 Riscurile la nivel de birou
Riscurile la nivel de birou sunt toate riscurile care se poate întâmpla și care ar limita sau opri activitatea de zi cu zi al unui angajat. Evaluarea la acest nivel poate fi interpretat ca un exercițiu de paranoia, dar, fiecare proces și instrument care ține de locul de muncă cu caracter personal trebuie să fie examinate cu atenție și contabilizate ca fiind esențiale .
2.3 Evaluarea riscurilor
Pierderea infrastructurii, a sistemelor, a serverelor este o întrerupere critică a operațiunilor din întreprindere, dar pierderea datelor din sisteme este un risc inacceptabil.
Odată ce evaluarea dintre cele mai importante categorii de risc este finalizat, este timpul să se înscrie și să se sorteze toate aceste categorii în funcție de probabilitatea și impactul acestora . Procesul de punctare poate fi abordată prin elaborarea unei foi scor , așa cum se arată în tabelul 1 , care are următoarele taste :
● Grupurile sunt subcategoriile din categoria de risc principal.
● Riscurile sunt riscurile individuale din cadrul fiecărui grup, care pot afecta afacerea.
● Probabilitatea riscului este estimat pe o scală de la 0 la 10, unde 0 este riscul minim de a se întâmpla și 10 fiind probabilitatea maximă a riscului să se întâmple. Probabilitatea că se va întâmplă ceva trebuie luată în considerare pe o perioadă de plan de lungă durată, de exemplu pe 5 ani.
● Impactul este estimat pe o scală de la 0 la 10, cu 0 fiind riscul minim de impact și 10 fiind un impact care amenință existența intreprinderii. Impactul este foarte sensibil la o oră din zi și la o zi din săptămână .
● Timpul de restaurare este estimat pe o scală de la 1 la 10 . O valoare mai mare ar însemna mai mult timp de restaurare, prin urmare, prioritatea de a avea un mecanism de recuperare în caz de catastrofe de acest risc este mai mare .
Tabelul 1. Formular de evaluare a riscurilor
Privind la exemplul de mai sus, înmulțirea timpului probabil, timpului de impact, și timpul de restaurare rezultă un scor dur de analiză de risc. O valoare zero, în una din cele două coloane face scorul riscului total un zero mare. Sortarea tabelul în ordine descrescătoare va pune cele mai mari riscuri în partea de sus, iar acestea sunt riscurile care merită mai multă atenție.
2.4 Determinarea efectelor dezastrelor
Odată ce riscurile cele mai critice au fost evaluate, următorul pas este determinarea efectelelor probabile ale fiecărui dezastru. Aceste efecte speciale sunt cele ce vor trebui să fie acoperite de procesul de recuperare în caz de dezastru.
Figura 3, poate fi folosită ca instrument pentru specificarea efectelor dezastrelor.
Figura 3. [NUME_REDACTAT] – [NUME_REDACTAT], cauzele multiple pot produce aceleași efecte, iar în unele cazuri, efectele ei înșuși pot fi cauzele altor efecte.
2.4.1 Lista entităților afectate de dezastrul
Intenția acestui exercițiu este de a produce o listă de entități afectate de eșec în urma unor catastrofe, care trebuie să fie abordate prin planul de redresare în caz de dezastru. În figura 3, entitățile care nu reușesc din cauza dezastrului în urma cutremurului sunt birou usor distrus, întreruperea energiei electrice, personalul nu-și poate intra în atribuții, sistemul de date distrus, și sistemul de telefonie stricat. Tabelul 2 oferă o cartografiere eșantion de cauza, efect și entități afectate.
Tabelul 2. Determinarea entităților afectate de dezastrul
Se poate remarca faptul că două sau mai multe dezastre pot afecta aceleași entități și se pot determina entitățile care sunt afectate cel mai adesea. Astfel putem trage o concluzie că entitățile cu cele mai multe apariții în tabel au o tendință mai mare de eșec.
2.4.2 Limitele de toleranță timpul de nefuncționare
Următorul pas este de a determina care este limita de toleranță a timpului de nefuncționare pentru fiecare dintre entități. Această informație devine crucială pentru pregătirea secvenței de recuperare în planul de recuperare în caz de dezastru. Entitățile cu apariții de cele mai puține ori ar trebui să fie atribuite o prioritate mai mare pentru recuperare. Evaluarea metrică a limitei toleranței timpului de nefuncționare este costul de nefuncționare.
2.4.3 Costul timpului de nefuncționare
Costul de nefuncționare este cheia principală pentru a calcula investițiile necesare într- un plan de recuperare în caz de dezastru . Costurile timpului de nefuncționare pot fi împărțite în costurile palpabile și nepalpabile.
Costurile palpabile sunt acele costuri care sunt o consecință a unei întreruperi de afaceri, generatoare de pierderi de venituri și productivitate .
Costurile nepalpabile includ oportunități pierdute atunci când clienții ar aborda concurența , pierderea reputației, și factori similari .
2.4.4 [NUME_REDACTAT] entității afectate depinde în mare parte de informațiile pe care le deținem la momentul producerii dezastrului pentru a putea pregăti în cel mai scurt timp secvența de recuperare din planul de recuperare în caz de dezastru . De exemplu , având sistemele de date restaurate există o dependență de restaurare față de alimentarea cu energie electrică.
2.5 Evaluarea mecanismelor de recuperare în caz de catastrofe
Odată ce lista entitaților afectate este întocmită și fiecare entitate critică a fost evaluată, este timpul pentru a analiza diversele metode de recuperare disponibile pentru fiecare entitate și pentru a determina cea mai bună metodă de recuperare potrivită pentru fiecare . Acest pas definește resursele utilizate în recuperarea și-n procesul de recuperare . Unele dintre entitățile tipice sunt sistemele de date, energia electrică, rețeaua de date, precum și sistemul de telefonie. Pentru fiecare dintre acestea există unul sau mai multe mecanisme de recuperare.
În cazul sistemelor de date, ca exemplu, mecanismul de recuperare, de obicei, implică sistemele de date replicate în altă parte în rețea și de a le pune on-line cu cele mai recente copii de rezervă a datelor disponibile. Pentru sistemele de date mai puțin critice, este posibil să existe o opțiune de a avea hardware server de rezervă, iar dacă se solicită aceste servere pot fi configurate cu aplicația dorită. În funcție de sistemul de date, pot exista opțiuni de autorecovery sau recuperare manuală, costul și timpul de recuperare pe fiecare mecanism variază.
În cazul unei pene de curent ca opțiuni am avea alegerea unui furnizor de energie care au surse alternative, cum ar fi generatoarele diesel. În anumite cazuri, mecanismele ar putea avea nevoie să fie elaborate .
Având în vedere opțiunile și mecanismele de recuperare în caz de dezastru, este necesar să se evalueze cu atenție cel mai bun mecanism de recuperare adecvat pentru o entitate ce a afectat o anumită organizație. Principalii factori care trebuiesc luați în considerare sunt :
● Costul de implementare, întreținere și exploatare
● Timpul de recuperare
● Ușurința activării fazei de recuperare și de funcționare
2.6 Comitetul de recuperare în caz de dezastru
Operațiunile și procedurile de recuperare în caz de dezastru ar trebui să fie guvernate de o comisie centrală. Acestă comisie ar trebui să aibă reprezentare din toate compartimentele IMM-ului, cu rol în procesul de recuperare în caz de dezastru, de obicei, management, din departamentul finanțe, departamentul IT, departamentul electric, departamentul de securitate, departamentul de resurse umane, management de furnizor, și așa mai departe .
Această comisia creează planul de recuperare în caz de dezastru și-l menține funcțional. În timpul unui dezastru, acestă comisie se asigură că există o coordonare adecvată între diferitele compartimente și că procesele de recuperare sunt executate cu succes și în secvența dorită și corectă .
Comisia de recuperare în caz de dezastru ar trebui să fie autorizată și responsabilă pentru :
● Crearea și menținerea planului de redresare în caz de dezastru
● Detectarea și anunțarea dezastrului în cadrul IMM-ului
● Activarea planului de recuperare în caz de dezastru
● Executarea planului de recuperare în caz de dezastru
● Monitorizarea situației dezastrului continuu și revenirea operațiunilor la normal în cel mai scurt timp posibil .
● Restaurarea operațiunilor normale și închiderea operațiunilor de recuperare în caz de dezastru
● Îmbunătățirea continuă a planului de redresare în caz de dezastru prin efectuarea de studii simulate periodic, încorporând lecțiile învățate de după un dezastru real .
Rolurile, responsabilitățile și raportarea ierarhică a diferiților membri ai comisiei ar trebui să fie definite în mod clar, atât în timpul operațiunilor normale cât și în caz de dezastru.
Rezervele membrilor comisiei ar trebui să fie, de asemenea, desemnați în cazul unei indisponibilități.
De reținut este că nu toți membrii comisiei de recuperare în caz de dezastru pot participa activ la recuperarea în caz de dezastru. Dar mulți membri cheie ai comisiei, cum ar fi coordonatorul general sau înlocuitorul legal conduce echipa de operațiuni, întotdeauna va participa în mod activ .
3. PAȘII DE RECUPERARE ÎN CAZ DE DEZASTRU
Recuperarea în caz de dezastru se întâmplă în faze secvențiale:
1. Faza de activare: În această fază, efectele dezastrului sunt evaluate și sunt anunțate.
2. Faza de execuție: În această fază, se execută procedurile de recupere pentru fiecare entitate afectată de dezastru. Operațiunile de afaceri sunt restaurate în sistemul de recuperare.
3. Faza de reconstituire: În această fază sistemul original este restaurat și procedurile fazei de execuție sunt oprite.
3.1 Faza de activare a dezastrului
Întreruperea de urgență se poate întâmpla cu sau fără notificare. Un uragan care afectează o anumită zonă geografică, sau răspândirea unui virus la o anumită dată sunt exemple de dezastre, cu o notificare prealabilă . Cu toate acestea, pot exista și dezastre fară nici o avertizare de exemplu, explozia unei conducte de apă sau un act criminal uman .
Detectarea rapidă și precisă a unui dezastru având și un plan de comunicare adecvat sunt cheile principale pentru reducerea efectelor situației de urgență, iar în unele cazuri, aceasta poate da suficient timp pentru a permite personalului din sistem punerea în aplicare a unei acțiuni de limitare a impactului dezastrului .
Comitetul de recuperare în caz de dezastru este responsabil pentru lansarea fazei de activare .
Ar trebui să fie bine informați cu privire la evenimentele geografice, politice, sociale și de mediu care pot prezenta amenințări la operațiunile de afaceri ale IMM-ului.
Faza de activare a dezastrului implică :
● proceduri de notificare
● evaluarea pagubelor
● activarea planificarii de recuperare în caz de catastrofe
3.1.1 Proceduri de notificare
Procedura de notificare definește măsurile principale luate cât mai rapid atunci când o întrerupere de urgență a fost detectată sau definitiv declarată. La sfarsitul acestei faze, personalul de recuperare va fi gata pentru a executa acțiuni de urgență pentru a restabili funcțiile sistemului pe o bază temporară .
Procedurile ar trebui să conțină procesul de alertă a personalului de recuperare în timpul programului și pe ore în afara programului de lucru . După detectarea dezastru, se trimite o notificare la echipa de evaluare a daunelor, astfel încât să se poată evalua pagubele reale ce a avut loc și punerea în aplicare a acțiunilor ulterioare .
Notificarea poate avea loc prin telefon, telefon mobil sau e-mail. O politică de notificare trebuie să descrie procedurile care ar trebuie urmate atunci când personalul specific nu poate fi contactat. Procedurile de notificare trebuie să fie un document simpu și clar în planul de urgență .
O astfel de tehnică de notificare generală poate fi un copac apel ( Figura 4 ) . Arborele de apel ar trebui să documenteze metode de contact primare și alternative și ar trebui să includă proceduri care trebuie urmate în cazul în care o persoană nu poate fi contactată .
Figura 4 . Graficul arborelui de apel
Personal care urmează să fie alertat ar trebui să fie identificat usor în lista de contacte din plan. Această listă ar trebui să clasifice personal pe atribuțiile lor,gen nume și informații de contact ( casă, locul de muncă, precum, adrese de e-mail , și adresele de domiciliu ) . În cazul în care sistemul (sistemele) perturbat (e) au interconectare cu organizațiile externe , un punct de contact ar trebui să fie identificate și în aceste organizații .
Notificarea informațiilor poate conține următoarele :
● Natura situației de urgență care a avut loc sau este iminentă
● Pierderea de vieți omenești sau răniri
● Estimarea distrugerilor
● Recuperarea detaliilor
● Instrucțiuni de răspuns suplimentare
● Instructiuni de pregătire / relocare pentru o perioada de timp estimată
● Instrucțiuni de completarea notificărilor folosind arborele de apel ( dacă este cazul )
3.1.2 Evaluarea pagubelor
Pentru a stabili modul în care planul de urgență va fi executat în urma unei întreruperi de servicii, este esențial să se evalueze natura și gradul de deteriorare a sistemului. Această evaluare a daunelor ar trebui să fie făcută cât mai rapid posibil în condițiile de autorizare, cu punerea în siguranță a personalului, aceasta fiind cea mai mare prioritate. Prin urmare, atunci când este posibil, echipa de evaluare a daunelor este prima anunțată cu privire la incident.
Este util să se pregătească linii directoare de evaluare a pagubelor pentru investigarea diferitelor tipuri de alarme majore care pot progresa la un dezastru și în cadrul unui dezastru.
Un exemplu ar putea fi o pană de curent observată la o instalație dintr-un centru de date, care are o sursă UPS. Ancheta demarată imediat ar trebui să stabilească dacă pana de curent poate fi remediată și restabilită înainte ca sistemul UPS să rămână fără baterie, în acest caz activarea planului de recuperare în caz de dezastru nu este necesar.
Procedurile de evaluare a daunelor variază în funcție de fiecare caz de urgență, cu toate acestea unele pot fi considerate generalități:
● Originea întreruperi de urgență
● Potențialul întreruperilor sau deteriorărilor ulterioare
● Suprafața afectată de situația de urgență
● Starea fizică a infrastructurii
● Inventarierea și starea functionala a celor mai importante echipamente
● Tipul de deteriorare a echipamentului
● Elemente care trebuiesc înlocuite
● Timpul estimat pentru a restabili servicii normale în cazul în care procedurile în caz de catastrofe nu erau în vigoare
3.1.3 [NUME_REDACTAT]
Este benefic a detecta un dezastru în etapa de început, punând astfel un proces de recuperare în caz de dezastru în acțiune dar o alarmă falsă poate bloca operațiunile normale de afaceri ale IMM-ului și poate duce la costuri nejustificate. Din această cauză, este foarte important ca de recuperarea în caz de dezastru să se ocupe personal calificat fiind astfel în măsură a activa planul de recuperare după o evaluare rapidă și aprofundată.
În funcție de gradul de deteriorare de la dezastru, comisia de recuperare în caz de dezastru sau numai o parte din comisie face planificarea de activare a dezastrului. Rezultatul acestui tip de planificare, ar trebui să cuprindă:
● Lista sistemelor și a serviciilor care au nevoie de restaurare
● Interdependențe și secvența lor de restaurare
● Estimări de timp pentru fiecare restaurare
● Instrucțiuni pentru raportarea eșecurilor de către echipa de conducere
● Comunicare între echipe
Odata ce planul de activare a dezastrului a fost planificat, echipa corespunzătoare va conduce personal și vor începe activitățile, așa cum au fost instruiți.
3.2 Faza de execuție
Operațiunile de recuperare încep doar după ce planul de recuperare în caz de dezastru a fost activat, personalul a fost notificat, iar echipele au fost mobilizate. Activitățile acestei faze se concentreză pe aducerea înapoi a sistemului de recuperare în caz de dezastru.
În funcție de strategiile de recuperare definite în plan, aceste funcții ar putea include prelucrarea manuală, de recuperare și de operare pe un sistem alternativ, sau de relocare și de recuperare de la un site alternativ.
3.2.1 Secvența de recuperare a activității
Procedura de recuperare reflectă prioritățile analizate în timpul fazei de planificare a activității. De exemplu, în cazul în care o cameră de server a fost recuperată după o întrerupere, serverele cele mai importante ar trebui să fie restabilite înainte de alte servere, mai puțin critice. Procedurile ar trebui să includă, de asemenea, instrucțiuni de lucru cu alte echipe, atunci când apar anumite situații, cum ar fi :
● O acțiune nu se realizează în intervalul de timp estimat
● Un pas important a fost finalizat
● Elementele trebuie să fie procurate
În cazul în care un sistem trebuie să fie recuperat de la o locație diferită, elementele specifice legate de acest serviciu trebuie să fie transferate sau obținute. Procedurile de recuperare ar trebui să delege o echipă pentru a gestiona transportul de echipamente, date, și înregistrări vitale. Procedurile ar trebui să explice cerințele la pachet, transport, și materiale de cumpărare necesare pentru a recupera sistemul .
3.2.2 Limitele de toleranță în cazul punctelor de reluare RPO și RTO
[NUME_REDACTAT] de [NUME_REDACTAT], sau "RPO", cum mai este cunoscut, este definit prin planul de continuitate a afacerii. Acesta reprezintă, perioada maxim tolerată, în care datele, existente într-un centru de date IT, pot fi pierdute din cauza unui incident major. RPO oferă proiectanților de sisteme informatice o limită de lucru. Altfel spus, un punct de recuperare obiectiv (RPO) reprezintă vechimea fișierelor ce trebuie a fi recuperate dintru-un „depozit” backup (backup storege) pentru a revenii la operațiuni normale, dacă vorbim despre un calculator, sistem sau rețea, ce nu mai funcționează, ca urmare a unei defecțiuni hardware, de programare sau comunicare. RPO este expresia, unui moment anterior fată de momentul în care a avut loc dezastrul, putând fi specificat în secunde, minute, ore, sau zile. Deci, acesta reprezintă un aspect important în planificarea de recuperare, în caz de dezastru (DRP).
Odată RPO definit, pentru un anumit computer, sistem sau rețea, se determină și frecvența minimă la care trebuie să se facă backup-ul. Acest lucru, împreună cu Timpul de [NUME_REDACTAT] sau „RTO”, despre care vom vorbi mai târziu, ajută administratorii să aleagă tehnologii și proceduri optime de recuperare, în caz de dezastru.
În cazul în care RPO este de cinci zile (120 ore), backup-urile trebuie să se facă la intervale de 120 ore sau chiar mai puțin. În această situație, backup-ul pe bandă sau compact disc (CD-R), poate fi considerată ca o soluție adecvată.
Backup-uri care nu au puncte de sincronizare sunt în general inutile.
Un punct de sincronizare al datelor este un moment, în timp. Acesta este utilizat pentru a evalua modul în care datele backup sunt „legate” între ele. Backup-ul de date trebuie să fie „legat” în mod corect de fiecare dată, atunci când, luăm în calcul momentul din zi în care s-au făcut, sau relația lor la evenimentele din sistemul informatic. Un punct de sincronizare a datelor este un moment în care un set de backup-uri, ce există în momentul în care se doreste restaurarea, pot fi sincronizate la același moment.
O greșeală frecventă la stabilirea RPO pentru cazurile în care backup-ul de zi cu zi, s-a făcut pe bandă, este asumarea de 24 ore pentru RPO.
Această greșeală este rezultatul desconsiderării începutului RPO-ului, care, începe odată cu primul backup pe bandă, utilizat în punctul de sincronizare. Acesta trebuind să includă, timpul de depozitare al benzilor, astfel încât, să existe un timp necesar depozitării acestora așa numitul "waiting for courier transport", timpul necesar „încărcării” acestora cât și timpul de ieșire din site (care nu întotdeauna este același în fiecare zi ). În concluzie, RPO trebuie să fie majorat cu o sumă de timp echivalentă cu oricare din aceste variabile. De asemenea, este riscant să presupunem că aceste casete de backup vor fi mereu intacte din punct de vedere fizic – RPO trebuie să includă, prin urmare suficient timp pentru a utiliza, un punct de sincronizare anterior.
De exemplu, backup-ul zi de zi, existent pe bandă (acestea fiind încă destul de comun), setarea RPO la 49 ar fi considerat ca fiind corect, totuși setarea RPO la 73 ore este cea mai bună, astfel încât acoperă problemele de hardware bandă (asa numitul „eșec de bandă” este încă frecvent, o bandă defectă, utilizată zi de zi, nu poate „scrie” un punct de sincronizare )
Timpul de [NUME_REDACTAT], sau „RTO” cum mai este cunoscut, reprezintă perioada de timp, maximă, tolerabilă, în care un calculator, sistem, retea, sau aplicație poate fi oprită, după ce se produce o defecțiune sau un dezastru, altfel spus RTO este durata de timp în care un proces, trebuie a fi restaurat, după un dezastru sau întrerupere, în scopul de a evita consecințe inacceptabile asociate cu o pauză în continuitatea afacerii.
RTO este o funcție a gradului în care întreruperea perturbă operațiunile normale cât și al sumei veniturilor pierdute pe unitatea de timp, ca urmare a dezastrului.
Un RTO se măsoară în secunde, minute, ore, sau zile și este un element important în planificarea de recuperare în caz de dezastru (DRP).
Momentul de continuitate a afacerii, de obicei, poate începe, în paralel cu momentul de management al incidentului, în aceleași sau diferite momente de timp.
În metodologia planificării continuității afacerii, RTO este stabilit în cursul analizei de impact de afaceri (BIA- [NUME_REDACTAT] Analysis), de către proprietarul unui proces (de obicei în combinație cu planificatorul de continuitate a afacerii). RTOS (real-time operating system) – sistemul de operare în timp real – sunt apoi prezentate conducerii superioare pentru aprobare.
RTO și rezultatele BIA ([NUME_REDACTAT] Analysis ) în toate elementele sale, oferă baza pentru identificarea și analizarea strategiei viabile a fi incluse în planul de continuitate a afacerii. Opțiunile de strategie, viabile, includ orice ar permite reluarea unui proces de afaceri, într-un interval de timp sau în apropierea unui RTO. Aceasta ar include proceduri de evitare manuale sau alternative și nu ar necesita neapărat sisteme informatice pentru a satisface RTOS (real-time operating system).
Numeroase studii au fost efectuate într-o încercare de a determina costul de nefuncționare pentru diverse aplicații în cadrul operațiunilor din întreprindere. Aceste studii indică faptul că, costul depinde de efectele pe termen lung și intangibilee, cât și pe termen scurt, imediat, sau al factorilor tangibili. Odată ce RTO, pentru o aplicație, a fost definit, administratorii pot decide care tehnologie de recuperare în caz de dezastru este cea potrivită pentru situația dată. De exemplu, în cazul în care RTO pentru o aplicație dată este de o oră, de backup redundante pe hard disk-uri externe ar putea fi cea mai bună soluție. În cazul în care RTO este de cinci zile, backup-ul, este mai practic a fi realizat pe bandă, compact disc (CD-R) sau pe un site de stocare, de pe un server Web la distanță (remote web server).
3.2.3 Proceduri de recuperare
Planul de recuperare în caz de dezastru ar trebui să prevadă proceduri detaliate pentru a restabili componentele sistemului sau de sistem. Procedurile pentru daune de servicii IT ar trebui să abordeze acțiuni specifice, cum ar fi:
● Ia autorizația de acces în sediul deteriorat sau în zonă geografică afectată
● Anunță utilizatori asociați cu sistemul
● Obținerea de spații de birouri
● Obținerea și instalarea componentelor hardware necesare
● Obținerea și încărcarea mass-media de rezervă
● Restaurarea sistemelor de operare critice și a aplicațiilor software
● Restaurarea datelor de sistem
● Funcționalitatea sistemului de testare, inclusiv controlul de securitate
● Conectare sistemelor la rețea sau a altor sisteme externe
Pentru a evita confuzia într-o situație de urgență, procedurile de recuperare ar trebui să fie documentate într-un format simplu pas-cu-pas, operatorul neasumându-și măsuri sau pași procedurali noi.
3.3 Faza de reconstituire
În faza de reconstituire, operațiunile sunt transferate înapoi la faza de activare a dezastrului, îndată ce este liberă de „începutul activări efectului” dezastru, și activitățile fazei de execuție sunt ulterior închise. Dacă sistemul original sau instalația este irecuperabilă, această etapă implică, de asemenea, reconstrucție. Prin urmare, faza de reconstituire poate dura de la câteva zile la câteva săptămâni sau chiar luni, în funcție de severitatea de distrugere și de activitatea de pe site-ul pentru restaurare. De îndată ce facilitatea, fie ea reparată sau înlocuită, este capabilă de a sprijini operațiuni normale, serviciile pot fi mutate înapoi. Echipa de execuție ar trebui să continue angajamentul, până la restaurarea și testarea completă. Următoarele activități importante apar în această fază :
● Monitorizarea continuă a site-ului de restaurare .
● Asigurați-vă că site-ul este liber de „începutul activări efectului” de dezastru și că nu există alte amenințări.
● Asigurați-vă că toate nevoie de servicii de infrastructură, cum ar fi alimentarea cu energie electrică, apă, telecomunicații, securitate, controlul mediului, echipamente de birou și consumabile, sunt operaționale.
● Instalațiile hardware-ul de sistem, software-ul și firmware.
● Stabilirea conectivității între sistemele interne și cele externe.
● Operațiunile de sistem de testare pentru a asigura funcționalitatea completă .
● Oprirea sistemului de urgență .
● Finalizarea operațiunilor de urgență .
4. ALTERNATIVĂ AUTOMATIZATĂ LA UN DISASTER RECOVERY
4.1. Dezastre de tip "[NUME_REDACTAT]" într-un IMM
Este bine știut că mașina virtuală VMWare Workstation a fost lider de piață în ultimii 11 ani, de fapt, potrivit Gartner (companie americană de consultanță și cercetare în IT, fondată în anul 1979), mai mult de 80 % din toate aplicațiile virtualizate în lume rulează azi, pe o VMWare. Dar ce este o mașină virtuală? O mașină virtuală funcționează ca un calculator virtual. Acesta va rula în cadrul sistemului de operare curent, denumit și host sau gazdă și va furniza servicii de tip hardware virtual sistemului de operare guest (musafir), care va rula ca orice program, [NUME_REDACTAT] de exemplu. Fiecare mașină virtuală creată va avea propriul hardware: un procesor virtual, memorie RAM, harddisk-uri, interfețe de rețea, interfețe grafice, mai nou chiar și cu accelerare 3D. Toate aceste resurse vor fi asociate resurselor calculatorului fizic. Din acest motiv numărul de mașini virtuale care pot fi rulate simultan este limitat de resursele fizice existente, în special de cantitatea de memorie RAM disponibilă. În cele ce urmează doresc să vă prezint recuperarea de date, dintr-un centru de date al unui IMM, în caz de dezastru, din perspectiva VMware.
”[NUME_REDACTAT] [NUME_REDACTAT]” este o metaforă, care înglobează conceptul de eveniment surpriză care are un impact major. Teoria evenimentelor [NUME_REDACTAT] se referă la evenimente neașteptate de magnitudine mare și în consecință la rolul lor dominant în istorie. Astfel de evenimente, de tip „[NUME_REDACTAT]”, considerate extreme, chiar aberante, joacă un rol mult mai mare decât evenimentele regulate. În cartea ”[NUME_REDACTAT] Swan”, autorul [NUME_REDACTAT] Taleb, explică faptul că, în timp ce evenimentele [NUME_REDACTAT] sunt imprevizibile, o persoană sau o organizație pot planifica evenimente care devin negative, și pot consolida chiar și capacitatea lor de a răspunde astfel încât să exploatăm evenimente pozitive. Taleb susține că oamenii, în general – și în special societățile – sunt foarte vulnerabile la evenimentele periculoase de tip [NUME_REDACTAT] fiind expuse la pierderi mari dacă aceste societăți rămân nepregătite.
Există o paralelă evidentă între teoria evenimentelor de tip [NUME_REDACTAT] și necesitatea de pregătire în caz de dezastre pentru active IT critice .
Implementarea planului de recuperare automată în caz de dezastru ( DR ) este calea de a proteja domeniul IT și o afacere în general, de evenimente imprevizibile de tip [NUME_REDACTAT] . În următoarele pagini voi explica elementele de bază ale DR și a infrastructurii necesare .
Să zicem că Centrul de Date dintr-un IMM este castelul tău în care toate componentele critice IT – hardware, date și software reprezintă reședința ta. Protejează-l cu cele mai recente soluții de securitate, fă-l de încredere, prin utilizarea multiprocesoarelor redundante, a platformelor scalabile, cât și a rețelelor optice super rapide. Chiar și în acest caz, IMM-ul nu este pe deplin protejat de forțe ce nu depind de controlul dumneavoastră, cum ar fi dezastrele naturale sau eventimentele generate de om.
Timpii morți și pierderea de date, chiar dacă temporar, pot avea efecte de lungă durată asupra afacerii și pot chiar contribui la dispariția afacerii dumneavoastra prin:
– piederi de venituri și incapacitatea clienților de a face afaceri cu dumneavoastră
– diminuarea credibilității pe piață și a încrederii clienților
– costuri pentru recuperarea și repararea datelor pierdute
– implicații juridice pe plan intern cât și extern
Cum va echilibra riscul de recuperare în caz de dezastru, ecuația de investiții ? Este riscul potențial mai mare decât investiția? Să-l punem în perspectivă :
– 43 % la companiile ce se confruntă cu dezastre reapărute, iar aproape 29% cu cele ce nu apar în termen doi ani
– 93 % la companiile care au pierdut centrul de date pentru 10 zile și au intrat în faliment, apar odată pe an
– 40 % la toate companiile care se confruntă cu un mare dezastru și vor ieși din afaceri, în cazul în care nu se poate obține acces la date, în termen de 24 ore
DR([NUME_REDACTAT]) reprezintă modul în care întreaga industrie IT se poate pregăti și lupta împotriva evenimentelor de tip [NUME_REDACTAT].
Până când soluțiile fiabile de management de virtualizare au devenit disponibile, cu cațiva ani în urmă, soluțiile DR au fost considerate satisfăcătoare pentru afaceri, cu toate că prezentau cerinte de:
– cost ridicat
– complexitate
– lipsă de fiabilitate
Cu soluțiile tradiționale, adică DR manual, costul ridicat a venit de la necesitatea de a implementa un al doilea punct failover, cu infrastructură dedicată, licențe software, și personal uman specializat. Complexitatea acestui lucru, a fost mare, deoarece, pentru recuperarea întregii afaceri, au trebuit realizate planuri de redresare și recuperare utilizând mai mulți bani, mai multe resurse umane, componente, aplicații, host, rețele și dispozitive de stocare. Lipsa de fiabilitate a acestor proceduri a fost diminuată de automatizarea scăzută și incapacitatea de a testa orice procedură de recuperare. Multe societăți au avut încredere limitată în interdependența dintre Punctul de [NUME_REDACTAT] ( RPO ) și Timpul de [NUME_REDACTAT] ( RTO ), în caz de dezastru. Departamentele IT au ezitat să extindă protecția în caz de dezastre, datorită incertitudinii în calitatea asigurată cât și a costului ridicat. Virtualizarea este fundamentală și esențială pentru succesul de planificarea unui DR. Abstractul virtualizării, complexitatea de hardware și software, permite standardizarea proceselor, fac ca planificarea automată a procedurilor de recuperare să fie mult mai fiabile și repetabile.
PROCES de RECUPERARE FIZICĂ – 40 ore
[NUME_REDACTAT] SO Configurare SO Instalare START
hardware [NUME_REDACTAT]
Automata
într-un singur pas
PROCES de RECUPERARE VIRTUAL – 4 ore
Restaurare VM START VM
Crearea unei infrastructuri virtuale, bazată pe VMware, este considerată baza fundamentală pentru soluțiile DR moderne, ce prezintă adaptabilitate și scalabilitate, ce este optimizat pentru BC ([NUME_REDACTAT]).
Soluția DR VMware prevede :
– cel mai simplu mod de a replica aplicațiile într-o locație secundară
– cel mai simplu mod de a configura recuperarea și configurarea planurilor de migrare
– complet automatizat
Eficiența de cost al DR – Odată cu adoptarea rapidă a virtualizării și a evoluției tehnologiei de replicare, DR este din ce în ce mai eficient din punct de vedere al costurilor. Virtualizarea permite consolidarea infrastructurii din locația failover.
Astfel, sunt disponibile mai puține opțiuni de replicare, care sunt de obicei costisitoare, folosind dispozitive de stocare „lower-end” cât și soluții software de sine stătătoare („stand-alone”). Prezentând aceste caracteristici, DR poate proteja pe scară largă active IT, locații mai mici cât și aplicații de un anumit nivel.
Automatizarea DR – În mediu virtual, utilizatorii finali („end-users”) sunt feriți de complexitatea gestionării fiecărui pas din procesul de recuperare, iar soluția DR poate să coordoneze și să execute în mod automat toate măsurile necesare asigurării nivelului de protecție dorit. Folosind ideile din documentațiile tradiționale se consideră că, nu mai sunt "suficient de bune" pentru a gestiona planurile de redresare, acestea fiind înlocuite cu software bazat pe planuri de redresare și recuperare. Stabilirea unui plan de recuperare într-un mediu virtual este la fel de simplu ca selectarea RPO-ului și RTO-ului pentru fiecare serviciu de afaceri.
Recuperarea și migrarea într-o locație de încredere:
Odată cu virtualizarea, organizațiile obțin asigurări mai mari asupra RPO-ului și RTO-ului. Virtualizarea oferă posibilitatea de a testa planurile de redresare și recuperare, frecvent și într-o manieră non-perturbatorare. Procesele manuale de recuperare sunt acum înlocuite cu recuperarea automată, eliminând astfel, riscul asociat erorilor umane, asigurând o recuperare previzibilă.
Graficul de mai jos arată modul în care organizațiile cu infrastructuri virtualizate utilizează capacitățile DR împreună cu alte beneficii de virtualizare.
G R A F I C
LEGENDĂ:
4.2. Recuperare în caz de dezastru între mit și realitate.
Mitul 1: Recuperarea în caz de dezastru reprezintă o caracteristică de lux, costisitoare și mare consumatoare de resurse.
Realitatea 1: VMware vCenter [NUME_REDACTAT] Manager ™ pe scurt (SRM) – oferă flexibilitatea de a defini scenarii failover care, funcție de alegerea făcută, să îndeplinească atât viteză cât și costuri de recuperare reduse. De exemplu, în timp ce o recuperare dedicată local este o soluție robustă (întradevăr mai scumpă), în multe cazuri, este suficient de a avea o abordare bidirecțională activă în cazul în care două sau mai multe centre de date sunt complementare, având o capacitate suficientă de a susține aplicațiile critice. Prin urmare, nici o resursă nu este irosită, iar continuitatea este menținută.
În general, clienții ce utilizează SRM, raportează în mod constant, în caz de dezastru, o economie semnificativă de bani, resurse, și timp.
Spre exemplu, firma australiană de Management în Investiții, [NUME_REDACTAT], utilizează două centre de date co-localizate, având în jur de 500 de angajați.
În scopul îndeplinirii cerințelor de recuperare rapidă în caz de dezastru, cu pierderi minime de date, [NUME_REDACTAT] a implementat o infrastructură VMware dual-grup, care a fost legată de dispozitive de stocare în rețea, în cele două centre de date. Aceasta s-a făcut la aproximativ o treime din costuri. SRM a permis organizației să renunțe la mai mult de 50 de benzi magnetice de date anterior folosite ca sistem de rezervă a datelor, cât și de personal, fiind utilizată o persoană special pregătită ce realiza acest lucru o dată pe săptămână.
In plus, [NUME_REDACTAT] a automatizat astfel sute de pași în procesele de recuperare în caz de dezastru.
Câteva dintre rezultate:
– s-a îmbunătățit RPO de la 24 de ore la 90 de minute iar timpul de recuperare RTO de la 24 ore la mai puțin de 4 ore
– s-a redus numărul de personal necesar pentru restabilirea sistemului, la o singură persoană
-s-a redus investiția de capital pentru recuperare în caz de dezastru la o treime din costul unui mediu fizic
-s-a eliminat necesitatea achiziționării a cel putin 15 servere fizice
Mitul 2: Arhitectura și gestionarea în mod corespunzător a unei soluții DR este o sarcină complexă, care necesită abilități speciale și resurse costisitoare.
Realitatea 2: Nu, dacă se utilizează VMware. DR fizic poate fi, întradevar complex, din cauza infrastructurilor cât și al problemelor de sincronizare și de configurare din locații.
Virtualizarea, încapsulează servere, sistem de operare și aplicații, inclusiv toate datele de configurare, astfel încât complexitatea este mult redusă. Virtualizarea și automatizarea pot fi executate de personal fără pregătire de specialitate.
Cu SRM, crearea planului de recuperare (redresare) automată se face fară efort fiind vorba de minute și nu de săptămâni, în cazul unui DR fizic.
Exemplu: Swedbank este una dintre cele mai mari instituții financiar-bancare din Scandinavia și zona Baltică, cu 362 sucursale în Suedia și 222 de sucursale în Estonia, Letonia și Lituania. Banca are 9,5 milioane de clienți privați și 534.000 clienții corporații, cu 18.000 de angajați.
Prevenirea întreruperii serviciului este critică pentru Swedbank. Swedbank a trebuit să reconsidere îndeplinirea acestui obiectiv și să renunțe la mijloacele tradiționale de backup și recuperare, care erau complexe și consumatoare de timp. Astfel, Swedbank a hotărât să folosească SRM pentru a simplifica și automatiza procesul de recuperare, management și testare a planurilor de recuperare. Deoarece punerea în aplicare a SRM, Swedbank testează capacitățile sale de DR cel puțin de două ori pe an. Astfel se închide complet (Shut down) centru de date, volumul de lucru fiind transferat într-un alt centru de date de rezervă ([NUME_REDACTAT] Center). Se rulează totul în centru de date de rezervă, timp de 24 de ore, și apoi se transferă din nou la centrul de date original.
Șeful infrastructurii de bază din Grupul IT al Swedbank, [NUME_REDACTAT], declara că :"timpul de recuperare este mai mic de 30 minute pentru volumul de lucru critic și mai puțin de patru ore pentru întregul centrul de date. "
Mitul 3: După ce toate planurile au fost făcute, nu știi niciodată dacă procesul de recuperare va fi întradevăr un succes sau un dezastru.
Realitatea 3: Un plan de recuperare (redresare) nu este un plan complet dacă nu este și testat. De fapt, planul de recuperare (redresare) trebuie să fie testat incluzând suficiente eșecuri după care se retestează pentru a asigura validitatea acestuia. SRM permite frecvențe non-distructive planuri de redresare în vederea recuperării datelor.
Mitul 4: Cheltuielile de protecție cu un DR sunt cheltuieli inutile. Acest plan, probabil nu va fi niciodată utilizat.
Realitatea 4: Chiar dacă dezastrul nu se întâmplă, planul de recuperare poate fi folosit ca un plan de migrare, cu măsuri similare, ajutându-vă în eliminarea timpiilor de planificare în cazul migrării într-o nouă locație. În plus, planificarea unui DR ajută și la respectarea planurilor de recuperare dacă totuși se întâmplă un dezastru. Rezultatul testării recuperărilor de date în caz de dezastru, permite și obținerea capacității de a satisface Timpul de [NUME_REDACTAT] RTO.
Exemplu: Departamentul de Dezvoltare al persoanelor cu handicap și dizabilități din Ohio (DODD) rulează un sistem de servicii de sprijin pentru aproape 80.000 de persoane cu handicap și dizabilități. Un dezastru, cauzând un eșec în sistem, ar avea un impact uman deosebit de grav.
"În plus față de cele 10 centre ale noastre, suntem de asemenea, responsabili pentru toți furnizorii din stat de a obține sprijinul de care au nevoie, pentru a primi finanțare de la guvernul federal", spune [NUME_REDACTAT], manager administrator de rețea. "În cazul în care serviciile noastre <<ar pica>>, nu am putea asigura rambursarea fondurilor Medicaid, aceasta având un impact deosebit asupra furnizorilor și dezvoltatorilor cu handicap".Unii furnizori și-ar putea închide afacerile.
La DODD, SRM-ul este responsabil pentru fiabilitatea unui DR, verificarea la activare putând fi testată. Agenția a testat soluția de recuperare în caz de dezastru de două ori de-a lungul timpului. Al doilea test a implicat 50 de servere, care au reușit cu succes transferul de date într-un centru de date de siguranță în aproximativ 90 minute. "Dacă, într-o zi, vom avea un dezastru adevărat, locația în care s-a realizat DR devine locația noastră de lucru. Ne așteptăm să fim operaționali în mai puțin de două ore", notează [NUME_REDACTAT], IT manager infrastructură și operațiuni DODD.
Câteva dintre rezultate :
– o încredere în locația în care s-a realizat DR și faptul că acesta devine operațional în mai puțin de două ore,
– testat complet, în recuperarea în caz de dezastru,
– sisteme online, oferind rapid, un serviciu de încredere,
În timp ce, centrul de date este esențial pentru capacitatea de a conduce afacerea, evenimente dincolo de controlul propriu (sau chiar cele planificate) pot face serviciile IT indisponibile sau chiar a le limita. Această situație, totuși rară, ar putea fi foarte dăunătoare pentru integritatea afacerii, credibilitatea pe piață, cât și satisfacția și loialitatea clienților dumneavoastră.
Puteți atenua acest risc prin implementarea unei soluții de DR pentru a proteja activele IT critice.
4.3. Ghid SRM, privire de ansamblu asupra modului de configurare.
Să începem cu o diagramă simplă al exemplului, pe care vom lucra.
Așa cum se vedea în figură, utilizăm un exemplu îmbricat. Acest lucru înseamnă că nu trebuie să avem o pereche de servere și un NAS pentru a prezenta acest tutorial. În acest caz, s-a folosit, o stație de lucru echipată cu un procesor dual core Intel CPU moderne, memorie RAM de 16 GB și unele HDD + SSD-uri.
Pe partea de sus a VMware Workstation am pus o pereche de mașini virtuale: 2x vCenter, 2x ESXi îmbricate, 2x simulatoare NetApp și un alt sistem Windows în calitate de controller de domeniu și un server DNS.
NetApp VSA joacă un rol major pentru mediul de laborator. Datorită faptului că avem de gând să utilizăm o replicare de tip array (matrice) nu avem multe alegeri în vederea setării acestui exemplu-laborator. NetApp se replica Datastore printr-o facilitate, numită SnapMirror.
Nu doresc să prezint vSphere Replication (o soluție de replicare pe bază host), care vine cu VMware SRM. Pentru cele mai multe dintre etapele următoare, nu contează ce tehnologie de replicare utilizatăm.
Scenariul pe care-l prezint este unul clasic "Main-și [NUME_REDACTAT] Center". Acest lucru înseamnă că pe [NUME_REDACTAT] A rulează toate mașini virtuale VM, care vor fi protejate pe [NUME_REDACTAT] B. Desigur, este posibil să existe și o configurare de tip bi-direcțional, în acest caz ambele [NUME_REDACTAT] se vor proteja reciproc, dar pentru a întelege mai bine, alegem cazul simplu. Nu vă faceți probleme, pentru a efectua o configurare bi-direcțională aveți nevoie de a urmării unii pași, din alta perspectivă, dar nimic nu este diferit de cazul simplu ales.
Vom arunca o privire asupra fiecarei componente pentru a înțelegere modalitățile de lucru dintr-un mediu SRM.
Începem din nou cu o diagramă, care arată toate componentele logice relevante ale vSphere și SRM stack.
VCenter Server desigur rămâne nucleul infrastructurii VMware, atunci când SRM intră în joc. O cerință, este aceea, de a avea un vCenter pe fiecare site (locație), ceea ce înseamnă, că veți avea nevoie de o licență suplimentară vCenter.
Puteți conecta ambele vCenter Server prin caracteristica link mode ca și cum acestea ar fi integrate în mediul existent. Dacă nu ați lucrat niciodată cu SRM-ul și nu sunteți familiarizat cu acesta, vă sfătuiesc să păstrați vCenter ca fiind independent pentru
început. Cred că acest lucru devine mai clar dacă utilizați două medii separate.
SRM Server este prezentat în diagramă ca un obiect separat, dar aceasta nu înseamnă că trebuie instalat SRM-ul pe un server separat. Aceasta este una din întrebările ce se pun, când vine vorba de utilizarea SRM-ului.
În special pentru mediile mici, aceasta, reprezintă un mare argument împotriva creării unui server separat ce implică costuri suplimentare de licențiere pentru un alt Windows.
Cred că este absolut suficient pentru a rula vCenter și SRM pe un singur server, dacă ai avea o afacere mică. S-au văzut afaceri cu aproximativ 60 de mașini virtuale VM protejate, care rulează fără probleme. Nu aș putea spune un număr maxim fix de masini virtuale VM protejate cu un SRM-ul ruland pe un server separat, dar în cazul în care afacerea, are în jur de 100 de mașini virtuale, puteți lua în considerare folosirea doar a unui singur server.
Dacă aveți o licență [NUME_REDACTAT] Datacenter sau în cazul în care costurile suplimentare de licențiere, nu contează, aș merge cu siguranță pe alegerea unui server dedicat SRM, deoarece există unele beneficii de funcționare, în cazul unui sever separat.
S-au văzut probleme cu SRA (adaptorul care comunică cu matrice de stocare), care a necesitat mai multe reporniri al serverului SRM. În acest caz, acest lucru înseamnă că aveți, un downtime al serverului vCenter, dacă utilizați un server comun pentru ambele servicii.
Aceeași întrebare apare, când vine vorba de baza de date (database) pentru SRM . Chiar dacă pe diagramă se prezintă vCenter DB și SRM DB separat unul de de altul, nu înseamnă că ele nu pot rula pe o bază de date comună. Designul cel mai des întâlnit, un server vCenter, un server SRM și serverul DB (baza de date) ce găzduieste ambele baze de date (vCenter și SRM). Trebuie să țineți minte că baza de date SRM nu conține atât de multe date, astfel încât, în mod normal, nu este nici o problemă să-l punem alături de o altă bază de date.
Dacă utilizați replicarea array (așa cum vom face în acest tutorial) veți avea nevoie de un SRA (adaptor de replicare de stocare – storage replication adapter). Aceste adaptoare sunt furnizate, în mod normal, de către vânzătorul dispozitivelor de stocare, de asemenea, sunt disponibile și în secțiunea download din VMware SRM. SRA este instalat pe serverul SRM și comunică direct cu sistemele de stocare conectate.
Următorul caz, în acest context, îl reprezintă sistemele de stocare. Dacă nu ați făcut-o deja, ar trebui să vă asigurați, în primul rând, că sistemul de stocare al dumneavoastră este suportat de VMware SRM pe HCL. În combinație cu SRA, replicarea array devine "vizibilă" pentru infrastructura virtuală, care în mod normal este invizibilă pe array (matrice). Cred că proiectarea corectă a sistemelor de stocare, este în mare parte, mult subestimată, mai ales în afacerile mari.
De multe ori, nu reușiți a proteja toate mașinile virtuale, ci doar pe cele importante (versiunea SRM 5 este licențiat pe VM). De fapt, replicarea array se face pe fiecare LUN (logical unit number) sau de volum (oricum numele este specific fiecărui furnizor), acest lucru poate duce la situații frustrante, dacă nu instalați o infrastructură noua completă, de la zero. Întotdeauna, trebuie văzută ca o relație între VM și Datastore (replicate). În cazul unui dezastru (sau a migrației planificate) SRM va comuta Datastore complet, la nivelul de array, ceea ce înseamnă că nu pot exista VM-uri cu sau fără protecție SRM pe aceeași Datastore.
Mult mai complicată devine situația, dacă doriți să puneți în aplicare planuri foarte concrete și detaliate ale DR ([NUME_REDACTAT]). Să presupunem că doriți să aveți posibilitatea de failover, doar pentru un grup specificat de VM. Exemplu, aveți hosting VM (găzduire pentru mașinile virtuale) pentru clientul A și B. Pentru a pune în aplicare un plan dedicat și independent DR, este necesar, să existe o separare pe nivel Datastore al VM. Înainte de a pune în aplicare SRM, de multe ori în proiectarea centrului de stocare Datasore, se va ține cont de anumite valori, cum ar fi performanța și capacitatea. În cele mai multe situații SRM aduce un punct de vedere nou, ceea ce poate duce, în cel mai rău caz, la o nouă abordare al proiectării sistemului de stocare.
Dacă, vă încadrați în această situație, veți aprecia caracteristica de stocare vMotion , mai mult, ca înainte.
Ultimul, dar nu cel din urmă, este de remarcat modul în care este administrat SRM-ul. Veți avea nevoie de un SRM plug-in pentru vSphere Client, în vederea instalării și configurării versiunii 5 – VMware [NUME_REDACTAT] Manager. Acest lucru vi-l prezint în detaliu, mai jos.
Înainte de a începe am instalat deja două vCenter Server independente, fiecare cu o instalare standard locală MS SQL 2008 R2 Std. De asemenea, am creat baza de date SRM necesară pe același SQL.
De fapt, în cazul nostru, instalăm SRM pe același sistem pe care a fost instalat și vCenter. În cazul unui IMM, se va utiliza în mod sigur un sistem SRM separat, dar acest lucru a fost deja menționat în detaliu mai sus.
După ce ați început configurarea, e necesar să vă decide dacă doriți să instalați vSphere Replication (VR). În exemplul nostru am folosit două simulatoare NetApp Simulator (cu replicare), ca stocare partajată, așa că nu avem nevoie de vSphere Replication.
Apoi, trebuie să introduceți informațiile de instalare, aferente vCenter Server. La fel ca majoritatea componentelor vSphere, este de asemenea important, să aveți funcțional (și corect configurat) serviciile DNS.
Dacă nu aveți obligația de a folosi certificări oficiale, le puteți genera în mod automat, în pasul următor…
… urmate de unele informații necesare pentru certificare.
Pe lângă unele informații (numele site-ului, adresa de email) vi se va cere adresa IP a host-ului local. Aveți nevoie să selectați interfața de rețea, pe care o va folosi SRM-ul. Din punct de vedere a SRM-ului, nu există o cerință specială, de a avea sau nu mai multe interfețe, dar server-ul, se poate conecta la rețele diferite, din diferite motive.
Ultimul pas pe care trebuie să-l faceți este de a introduce informațiile bazei de date.
După ce am terminat instalarea cu succes, Plug-in Manager-ul vSphere Client, va arăta plug-in-urile SRM ce sunt disponibile a fi instalate.
După aceea, veți găsi pictograma SRM pe ecran!
SRM este acum instalat pe primul site / primar. Acum, trebuie să repetați întregul proces de instalare a SRM-ului, pe site-ul secundar.
Pot apărea și mesaje de erroare. Unul dintre ele ar putea fi Failed to create database tables one :
Dacă vedeți acest mesaj, atunci înseamnă că configurarea bazei de date utilizator, nu este corectă. În cele mai multe cazuri utilizatorul nu este setat ca unic proprietar de bază de date (database owner) sau aveți drepturi atribuite greșit (wrong rights assigned)
Înainte de a continua cu configurarea SRM, vă voi arăta cum să configurați și să setați NetApp ONTAP Simulator inclusiv replicarea cu SnapMirror.
Vă arăt de asemenea cum să instalați simulatorul NetApp ONTAP Simulato și configurația lui de bază, ce este necesară pentru a împărți unele unități de stocare NFS pentru un host ESXi.
Notă: Următorii pași se aplică, de asemenea, dacă doriți să știți cum se instalează ONTAP Simulator (fără VMware vSphere & SRM).
NetApp ONTAP Simulator este disponibil prin intermediul portalului de download de pe pagina NetApp. Trebuie să vă înregistrați pentru a descărca fișierele. Am de gând să vă prezint utilizarea versiunii 7, în acest tutorial.
Puteți alege între un pachet OVA (pentru vSphere), sau un zip-pachet (zip-bundle) cu tot felul de fișiere VM (pentru VMware Workstation).
După adăugarea VM la VMware Workstation, în prima etapă, am anulat cel puțin două din adaptoarele de rețea implicite. Dacă nu doriți să conectați redundant host-urile ESXi, puteți porni cu un singur adaptor.
Pentru a utiliza de mai multe simulatoarele ONTAP Simulators (de exemplu, pentru o replicare SnapMirror) este necesar de a schimba numărul de serie al sistemului. Acest pas nu este necesar dacă utilizați un singur simulator.
La scurt timp după „pornirea” VM, trebuie să apăsați o tastă (nu ENTER) pentru a ajunge la linia de comandă, înainte de boot-area sistemul. Introduceți următoarele comenzi pentru a schimba seria.
set bootarg.nvram.sysid=1234567890
set SYS_SERIAL_NUM=1234567890
boot
La prima pornire, trebuie să intrați în meniul de boot-are, apăsând CTRL + C, atunci când vi se solicită. Aici trebuie să selectați opțiunea 4 pentru a începe initializarea sistemului, în caz contrar se va ajunge într-o buclă de boot-are. Trebuiesc confirmate două mesaje de avertizare cu da (yes) pentru a reseta sistemul și șterge discurile.
Sistemele începe cu un wizard de configurare pentru configurația inițială. Trebuiesc introduse adresele IP pentru interfețele (interfaces), mască de subrețea (subnet mask), etc,.
Important: Asigurați-vă că DNS resolver este enable și introduceți un server DNS. Un DNS funcțional și corect configurat este necesar pentru SnapMirror, pe care-l vom utiliza în exemplu nostru SRM.
Datorită faptului că folosim doar un simulator este necesar să se adauge o pereche de discuri sistemului de la „CLI” (command-line interface)
În primul rând avem nevoie să oferim permisiuni utilizatorului (enable the diag user) cât și o parolă.
priv set advanced
useradmin diaguser unlock
useradmin diaguser password
….dupa [NUME_REDACTAT]
… Trebuie să vă logați cu diag user și parola pe care tocmai ați alocat-o.
Următoarea ordine de comandă va adăuga discurile:
setenv PATH "${PATH}:/usr/sbin"
cd /sim/dev
vsim_makedisks -h
sudo vsim_makedisks -n 14 -t 36 -a 2
sudo vsim_makedisks -n 14 -t 36 -a 3
Logout diag user:
exit
Autentifică-te din nou cu utilizatorul root user și asignați toate discurile, pe care tocmai le-ați creat.
disk show -n
disk assign all
disk show –v
Pentru legătura dintre SRA și sistemul de stocare, avem nevoie de a seta următoarele opțiuni:
options httpd.admin.access legacy
options httpd.admin.enable on
Ultimul pas, pe care trebuie să-l facem din CLI (command-line interface), este de a adăuga o listă lungă de licențe pentru sistem. Desigur, veți avea nevoie doar de o pereche din ele, dar eu nu văd nici un motiv pentru a nu le adăuga pe toate.
Sugestie: Conectati-vă prin SSH la sistem și folosiți Copy-Paste să copiați și să inserați următorul bloc într-o singură operație.
license add MTVVGAF
license add DZDACHD
license add CEVIVFK
license add PZKEAZL
license add NAZOMKC
license add BKHEXNB
license add ADIPPVM
license add ANLEAZL
license add BSLRLTG
license add ELNRLTG
license add BQOEAZL
license add CYLGWWF
license add CGUKRDE
license add UYNXFJJ
license add RKBAFSN
license add HNGEAZL
license add ZOJPPVM
license add PTZZESN
license add BCJEAZL
license add COIRLTG
license add QZJTKCL
license add WICPMKC
license add UPDCBQH
license add DFVXFJJ
license add XJQIVFK
license add DNDCBQH
license add JQAACHD
license add ZYICXLC
license add PVOIVFK
license add PDXMQMI
license add RQAYBFE
license add ZOPRKAM
license add RIQTKCL
license add NQBYFJJ
license add JGFRLTG
Dacă nu ați instalat NetApp OnCommand [NUME_REDACTAT], acum e timpul de a face acest lucru. Puteți să-l găsiți, de asemenea, în portal de download, pe care l-am menționat la început.
Etapele următoare „le parcurgem” prin intermediul [NUME_REDACTAT]. Dacă sunteți începător în utilizarea NetApp, dar aveți ceva experiență, copiați „în masă” comenzile de la CLI.
După ce „s-a deschis” [NUME_REDACTAT] trebuie să adăugați sistemul/le. Ulterior vă puteți loga prin dublu-clic sau butonul login.
Primul lucru pe care-l vom face, este de a crea un nou agregat de discuri pe care le-am adăugat înainte, prin linia de comandă. [NUME_REDACTAT] din partea stângă și faceți clic pe butonul Create.
Un vrăjitor (wizard) ne va ghida, în viitor, prin acest proces. În primul rând avem nevoie de a specifica un nume pentru noul agregat. [NUME_REDACTAT] Type și [NUME_REDACTAT] pe implicit (default).
În fereastra următoare vom selecta grupul de discuri (ar trebui să existe doar unul singur disponibil).
Pentru exemplul nostru am creat un grup raid din 14 discuri, pentru a lăsa ceva și pentru alte lucrări de mai târziu. Puteți configura acesta individual. Faceți clic pe [NUME_REDACTAT] pentru a specifica 14 discuri.
În fereastra pop-up aleg 14 discuri din cele 28 pe care le-am creat recent și faceți clic pe OK.
Verificați rezultatul afișat și faceți clic pe butonul Create
.
…astfel acesta apare în listă
Acum, trebuie să creați unele volume pentru agregatul recent creat. [NUME_REDACTAT] din partea stângă și faceți clic pe butonul Create.
Pentru exemplul nostru SRM, creăm trei volume. Unul mic, pentru fișierele SRM substituent și alte două pentru a stoca mașinile virtuale VM. Aveți nevoie de a le definii printr-un nume, selectați corect agregatul-aggregate (pe care l-am creat înainte), selectați tipul de depozitare-storage type (în această lucrare folosim NFS), specificați dimensiunea și alegeți dacă utilizați acces pe volum.
Notă: Aș sugera să folosiți o denumire diferită pentru Datastores VM pe sistemul secundar. „E frumos” a adăuga un "_secondary" la sfârșitul numelui. În caz contrar, ar putea fi, uneori, un pic confuz, dacă se face replicarea între volume cu exact același nume.
După ce ați creat volumele, selectati butonul Export din partea stângă. Acum ar trebui să vedeți calea (path) către volumele create. În ultima etapă trebuie să ne concentrăm asupra permisiunilor acestor exporturi, acestea se văd în partea de jos.
Selectați folderul Unix existent și faceți clic pe butonul Edit.
În ferestrele următoare, trebuie să editați secțiunea [NUME_REDACTAT]. Există două cazuri diferite, în care aveți nevoie de diferite modificări:
a) În cazul în care nu doriți să utilizați aceste depozite de date Datastore pe VM-urile replicate (pentru utilizare cu SRM), doar lăsați default pentru All hosts – [NUME_REDACTAT] Write și adăugați fiecare adresă IP host ESXi cu permisiuni root access.
b) În cazul în care doriți să utilizați aceste depozite de date (Datastore) pentru „a pune” mașinile virtuale pe ele (care sunt protejate de SRM), există ceva special ce se ia în considerare cu sistemele de stocare NetApp (nu se limitează la simulator). În primul rând trebuie să eliminați „intrarea”(entry) All hosts – [NUME_REDACTAT] Write. După aceea trebuie să adăugați la SRM Server permisiuni read write. Apoi, trebuie să adăugați pe fiecare host ESXi root access și permisiuni read write .
Acum putem trece la Clientul vSphere și a adăuga Datastores. Introduceți numele DNS al sistemului NetApp și folosiți calea / folder, pe care ai putea vedea lista de export pe caseta NetApp.
Important: Pentru laboratorul SRM vom adăuga toate cele trei Datastores pe NetApp-ul primar. Pe sistemul secundar adăugăm numai Datastore SRM substituent.
În final, Datastore este gata de utilizare!
La final, ar trebuii să aveți instalate două simulatoare NetApp, unul pentru fiecare locație
Acum putem trece la configurarea NetApp SnapMirror
După ce am creat Datastore pentru host ESXi, acum este momentul de a pune în aplicare replicarea în locația secundară.
În pasul anterior am creat două Datastores pentru VM de date, pe ambele sisteme NetApp. În mod implicit, volumele obținute, statutul on-line în timpul creării. Primul pas, este acela, de a schimba acest statut, la sistemul secundar în – Restrict. În caz contrar, nu este posibil de a utiliza acest volum ca destinație de replicare.
Înainte de a crea o conexiune SnapMirror, este important de a configura accesul de la distanță (remote access) pe fiecare sistem. Selectați SnapMirror, din partea stângă și faceți clic pe [NUME_REDACTAT].
Aveți posibilitatea de a specifica acest lucru pentru toate volumele sau numai pentru unul singur. În experimentul dat, nu avem nici o restricție, așa că selectam All_volumes. Asigurați-vă că executați aceast lucru, pe ambele simulatoare NetApp Simulators.
După ce ați configurat accesul de la distanță ([NUME_REDACTAT]), faceți clic pe butonul Create.
Expertul (Wizard) vrea să cunoască de la început rolul SnapMirror. Fiind pe sistemul primar, trebuie să selectați butonul Source.
…după aceea, selectați volumul pe care doriți să-l replicați.
Puteți selecta sistemul destinatar, cu ușurință, prin meniul drop-down, dacă acesta este gestionat în cadrul [NUME_REDACTAT] (așa este în majoritatea cazurilor). Dacă ați salvat și prerogativele, ele sunt folosite, de asemenea, în mod automat.
De fapt volumele destinație (țintă), au fost deja create pe sistemul secundar, selectațile alegand butonul Select. În caz contrar, aveți posibilitatea de a crea aici, volumul de destinație (țintă).
În listă veți găsi toate volumele care au statutul Restrict. Dacă, lista este goală, reveniți la pasul 1.
Expertul (Wizard-ul) solicită programul. Așa cum am convenit, utilizând acest experiment, cu resurse limitate, nu dorim a rula SnapMirror în mod automat, deci selectăm butonul On demand. Într-un caz real, veți vedea, de obicei, un program implementat.
Așa cum am plănuit, lansăm replicarea, în mod manual, deci nu am nevoie de a limita lățimea de bandă. Selectați aceasta în funcție de cerințele dumneavoastră.
Repetați acești pași pentru ambele volume de date VM. Nu este necesar ca sistemul secundar să poată îndeplini toate cerintele.
Mai jos, se observă în meniul SnapMirror, cum apar ambele volume de date VM.
Să vorbim în continuare de instalarea SRA
Dacă se folosește replicarea tip array, este necesar a instala un SRA (adaptor de replicare a depozitării – storage replication adapter) pe serverul SRM. În pașii următori prezint instalarea NetApp ASD 2.0.0. Rețineți că fiecare furnizor are propriul SRA, astfel instalarea și configurarea poate varia în funcție de tipul de array de stocare utilizat.
Puteți descărca SRA-ul din secțiunea de download VM SRM sau de pe pagina furnizorului sistemului de salvare (stocare). Asigurați-vă că-l selectați pe cel corect, pentru că pot fi mai multe, de la un singur furnizor (unul pentru fiecare tehnologie de replicare în parte).
SRA-ul este responsabil de comunicarea dintre SRM și matricea de stocare. Nu veți putea finaliza configurarea SRM-ului dacă SRA-ul nu funcționează corect.
Instalarea în sine este destul de simplă. După pornire, programul setup.exe, în cele mai multe cazuri, ne cere a face clic pe butonul [NUME_REDACTAT] Install , numai într-un singur caz ne cere să alegem între două moduri de instalare: Typical sau Complete. În cele mai multe cazuri se alege Complete, care este și selecția implicită.
După instalare, reveniți la SRM GUI. [NUME_REDACTAT] Managers din stânga și faceți clic pe tab-ul SRA. Veți găsi un link, care va scana serverul SRM pentru SRA-ul instalat.
SRM-ul ne arată SRA-ul pe care l-am instalat. Veți primi un avertisment că SRA-ul nu se găsește pe locația asociată. Acesta se poate ignora pe moment, deoarece n-a fost configurată locația asociată.
Trebuie să urmați toti acești pași, pe ambele servere SRM.
După ce am instalat SRM-ul, acum e timpul să-l configurăm. Datorită faptului că, întreag procesul de configurare, este voluminos, l-am împârțit în două părți.
Configurarea conexiunii de la distanță (Remote):
Start vSphere Client și conectați-l la vCenter din locația primară. După ce lansați SRM GUI (graphical user interface) veți vedea doar un singur exemplu SRM. Primul pas este acela, de a crea o conexiune la instanța SRM-ului pe locația secundară.
[NUME_REDACTAT] pe link-ul [NUME_REDACTAT] din partea dreaptă al Wizard-ului.
Apoi, trebuie să introduceți vCenter FQDN în locația de la distanță ([NUME_REDACTAT]).
Dacă nu utilizați certificări oficiale, veți primi un mesaj de avertizare, pe care-l puteți ignora.
Ultimul pas al programului asistent (wizard-ului) vă solicită acreditările Remote vCenter Server al locației de la distanță.
După ce conexiunea a fost stabilită, vi se cere din nou acreditarea. Acest lucru vă va fi solicitat de fiecare dată când porniți SRM plug-in (chiar dacă utilizați linked mode și aveți aceleași date de logare pe ambele locații).
Acum veți vedea ambele locații (sites), în partea stângă al interfeței. Cuvantul "local" ce apare la finalul numelui locației ( SRM-A(Local)) indică pe care locație suntem De asemenea, veți vedea că statutul se va schimba la conectare (Status: Connected).
Adaugă matricea de stocare:
Înainte de a începe să adăugați matricea de stocare (storage array) a SRM-ului, trebuie să verificați cele două adaptoare SRA, dacă funcționează corect. Programul s-ar putea să vă ceară să faceți clic din nou pe link-ul "Rescan SRAs".
[NUME_REDACTAT] Summary din meniul [NUME_REDACTAT] veți găsi opțiunea [NUME_REDACTAT] Manager. Acest pas este necesar pentru ambele locații (sites), dar pentru moment puteți sta în fereastra GUI din locația (site-ul) primară și doar selectați locația (site-ul) secundară din stânga.
În primul rând aveți nevoie de a a selecta SRA-ul potrivit pentru array-ul pe care doriți al adăuga. În acest tutorial am instalat doar un singur SRA, ceea ce înseamnă că în cazul de fața aveți doar o singură opțiune. Într-un mediu cu mai multe array-uri de la diferiți furnizori, veți avea mai multe SRA instalate, pe care le puteți selecta aici. De asemenea, aveți nevoie a defini array-ul (array name)- acesta puteți al schimba oricând.
Trebuie să adăugați adresele IP ale array-ului și acreditările de utilizator pentru root login. În acest exemplu am folosit doar o singură interfață a simulatorului NetApp al sistemului, deci adresa IP NFS este aceeași. Acest lucru nu va apare într-un caz real.
Sperăm că răspunsul wizard-ului, să fie unul de succes. În caz contrar, trebuie căutată problema apărută în secțiunea de depanare, pe care o vom trata la final.
În partea stângă, ar trebui să vedeți acum două tablouri ce prezinta ambele locații (site-uri).
În cele din urmă, trebuie configurată relația dintre cele două array-uri, adăugate recent. Faceți clic pe tab-ul [NUME_REDACTAT], unde veți găsi un buton Enable.
Pe tab-ul Devices, veți vedea acum cele două SnapMirror ce au fost configurate mai sus. Săgeata arată direcția de replicare, care s-ar schimba, după un failover și un Reprotect (mai multe despre aceasta, mai târziu).
Resource, Folder și [NUME_REDACTAT] (Network-Mappings)
Pentru fiecare din locații (site-uri) de pe partea stânga, apar tab-uri noi înainte de a începe configurarea conexiunii dintre locațiile (sit-urile) primare și secundare. Dar, înainte de a începe configurarea, vă prezentăm mediul vSphere.
La centrul de date primar (DataCenter) avem o pereche de mașini virtuale VM, pe care doresc să le protejez cu SRM. Alături de acestea am de asemenea, unele mașini virtuale locale, care nu sunt pe un centru de date replicat și care nu vreau să le protejez cu SRM. Vă rugăm să rețineți utilizarea resurselor unificate, în acest exemplu. Nu este o cerință de a utiliza resursele unificate cu un SRM, dar acesta se poate face folosind maparea resurselor, urmărind pașii următori..
Structura de foldere a VM și Template-urile arată similar cu resursele unificate din exemplu nostru. Desigur, puteți avea orice structură chiar fără nici o relație între Host și Cluster.
În primul rând mapăm resursele pe locația (site-ul) secundară. Creați o relație între grupuri și/sau resursele unificate la fel și pe locația (site-ul) secundară. În exemplul nostru dorim a proteja numai mașinile virtuale, cum se vede mai jos " SRM Protected VMs ". Dacă nu folosiți resurse unite, va trebui să configurați maparea la nivel de grup.
Selectați „obiectul”, faceți clic-dreapta și selectați [NUME_REDACTAT].
În fereastra pop-up observați structura locației (site) secundare. Selectați resursa, în care SRM-ul ar trebui să pună mașinile virtuale, în cazul în care apare un failover.
După configurare, SRM-ul afișează „relațiile”. Desigur, puteți mapa mai multe obiecte.
Abordarea pentru maparea folderelor sunt exact la fel.
De asemenea, pașii de configurare pentru maparea rețelei este la fel. În acest exemplu, această mapare este destul de simplă deoarece avem o singură rețea VM. Într-un caz real, nu există un VLAN între cele două locații (site-uri). În acest caz, s-ar putea să fie nevoie a pune conexiunea de rețea a mașinilor virtuale într-un VLAN cu totul diferit sau în multiple forme de rețea pentru site-ul A sau poate ajunge într-o singură rețea pentru site-ul B.
În primul rând vreau să vă „arăt” ce substituenți sunt folosiți în SRM. Dacă protejați o VM de pe site-ul primar (ceea ce vom face în următoarea parte), atunci, SRM creează un fișier substituent VMX (și alte fișiere mai mici), pe o așa-numită [NUME_REDACTAT] pe site-ul secundar. Fișierul VMX substituent este deja înregistrat în vCenter-ul site-ului secundar și, de asemenea, este afișat, dar sunt tratate ca „obiecte speciale” SRM, până când apare un failover. În cele mai multe cazuri acest fișier este o copie 1:1 a fișierului VMX original, dar include modificarea ce am configurat-o în ultimii pași (întreg procesul de mapare). Vă vom prezenta mai multe despre acest caz în următoarea parte a acestui tutorial. Poate veți să știți de ce aveți nevoie, a crea un substituent Datastore pe site-ul primar. Versiunea SRM 5 prezintă o noi caracteristici Reprotect și failback. După ce trecerea la site-ul secundar a avut loc, puteți reproteja mediul dumneavoastră, atunci când site-ul primar este din nou disponibil, folosind funcția Reprotect. În acest caz, SRM va „sării” (flip over) peste protecție dar în sens invers, ceea ce înseamnă, că în acest scenariu, un substituent Datastore este, de asemenea, necesar la site-ul primar.
În acest moment, mediul este gata pentru protecția mașinilor virtuale cu ajutorul SRM-ului. Cum putem crea planuri de protecție a grupurilor și planuri de refacere, vă arătăm în cele ce urmează.
În primul rând vom începe cu protecția grupurilor. Protecția grupurilor presupune unul sau mai multe Datastore cu VM-uri de protejat. În funcție de caz, pot exista diferite abordări a modului de proiectare a acestor grupuri. Ar trebui să se aibă mereu în vedere faptul că un singur Datastore poate fi doar o parte, dintr-un grup de protecție. Să presupunem că aveți 10 Datastore și toate sunt puse în același grup de protecție. Această configurație nu ar prezenta nici o flexibilitate în ceea ce privește planurile de recuperare pe care le vom crea mai târziu. Ai putea „obține” numai un failover pentru toate Datastore-urile la un loc. Abordarea opusă ar fi, dacă s-ar crea grupuri de protecție cu o relație de 1:1 pentru toate Datastore-urile la un loc. Astfel s-ar obține o mai mare flexibilitate. De cele mai multe ori, un echilibru între aceste două abordări se va potrivi în cele mai multe cazuri. Acest lucru va deveni mai clar, urmând pașii.
Selectați categoria [NUME_REDACTAT] din partea stângă. Se observă folderul implicit [NUME_REDACTAT] Groups. Faceți clic-dreapta pe acesta și selectați [NUME_REDACTAT] Group.
În primul rând selectați site-ul (locația), care are VM-urile pe care doriți a le proteja.
În cele ce urmează veți vedea toate Datastore-urile de replicat în tabelul selectat. În exemplul nostru abordăm această problemă din perspectiva creării numai a unui singur grup de protecție pentru fiecare Datastore în parte, așa că alegem doar unul singur. În partea de jos veți vedea VM-urile, ce apar pe Datastore-ul selectat pe care doriți al proteja.
În cele din urmă, va trebui să specificați un nume. V-aș recomanda ca prin numele ales să existe o legatură între acesta și Datastore-urile, care sunt incluse în acest grup de protecție ([NUME_REDACTAT]).
După ce ați creat grupul de protecție, veți vedea în bara "[NUME_REDACTAT] ", că s-a întâmplat ceva. SRM-ul creează acum fișierele substituent pentru VM-urile pe care tocmai le-a protejat.
Aruncați o privire acum în vCenter-ul de pe site-ul secundar. Veți observa că ceea ce ați protejat va apărea marcat cu iconițe speciale bolt-icon. Vă rugăm să nu ștergeți sau să modificați aceste obiecte (excepție făcându-se numai în cazul depanării). .
Cum am menționat, mai devreme, am creat un singur grup de protecție pentru fiecare dintre cele două Datastore.
Planurile de recuperare ([NUME_REDACTAT])
Ultima parte din procesul de configurație de bază este aceea de a construi planuri de redresare, înainte de a începe testele de failover.
O configurație al planului de redresare include unul sau mai multe grupuri de protecție. Un grup de protecție poate face parte dintr-un multiplu plan de redresare. De asemenea, acesta conține o multitudine de configurații atât al întregului proces de redresare cât și pentru fiecare VM.
Credem că, aproape, pentru fiecare caz în parte, ar trebui să existe un plan de redresare, care include întregul caz în ansamblu. Acest lucru, înseamnă, un singur plan pentru toate grupurile de protecție pe care le-ați creat. În caz de dezastru (întrerupere completă a site-ului (locației) primar), un singur plan va recupera întreaga infrastructă, pe site-ul secundar. De fapt, pot fi mult mai multe cazuri de utilizare al SRM-ului, iar în acest caz, trebuie create mai multe planuri, dar "mici". Poate că ați planificat unele lucrări de întreținere pe anumite zone (poate pentru o matrice de stocare unică sau chiar mai multe) din ansamblu creat de dumneavoastră și doriți să faceți un failover, planificat, numai pentru VM afectat și nu pentru întregul ansamblu.
Selectați din partea stângă, categoria [NUME_REDACTAT] . Vei vedea folderul implicit [NUME_REDACTAT] Plans. Faceți clic-dreapta pe acesta și selectați [NUME_REDACTAT] Plan.
Apoi, selectați site-ul (locația), unde doriți a recupera VM-urile pe care le-ați protejat.
Include-ți grupurile de protecție, create deja, și faceți clic pe Next.
Nota: Având în vedere că am hotărât a crea un singur plan de redresare pentru întregul ansamblu, selectăm toate grupurile protejate (all protection groups).
În aceeași fereastră aveți posibilitatea de a testa o rețea. Versiunea SRM 5 are marea posibilitatea de a testa un plan de redresare al unei rețele. Se prezintă ca o simulare a unui failover, fără a afecta funcționarea site-ul primar. De fapt un SRM puternic protejează VM-ul pe site-ul secundar, în această simulare. Este foarte important de a izola VM din perspectiva de conectivitate într-o rețea. Dacă lăsați aceste setări pe implicit (default), SRM-ul va crea o așa-numita rețea bubble. Acest lucru înseamnă că legătura între VM refăcut și vSwitch nou creat, s-a facut, fără nici un uplink. Poate, în unele cazuri, aveți nevoie de a introduce VM într-un VLAN special, etc, acest lucru se configurază astfel.
Introduceți un nume, pentru plan, opțional, chiar o descriere (în cele mai multe cazuri acest lucru are o însemnătate deosebită, dacă dorim, a proteja un ansamblu complex).
De asemenea, s-au creat două planuri suplimentare de redresare în vederea protejării unui singur Datastore din acest exemplu.
Dacă acum faceți clic, pe unul dintre planurile de recuperare, din partea stângă, veți vedea o fereastră cu o multitudine de taburi noi. În acest moment, nu vom intra în detalii, despre toate opțiunile existente aici. Vă vom arăta, în cele ce urmează, cele mai utile dintre acestea. Pentru început, cele implicite (default) sunt suficiente.
Simulați un failover
Acum e timpul pentru partea cu adevărat interesantă … hai să testem un plan de redresare!
Vă sugerez să selectați tab-ul [NUME_REDACTAT] înainte de a face un clic-dreapta pe planul de redresare și selectați Test. În aceast tab puteți urmări fiecare pas al SRM-ului, ce are loc în timp real.
Înainte de a începe testul, veți primi un avertisment pentru ceea ce faceti. De asemenea, aveți posibilitatea de a selecta o opțiune, pentru a sincroniza toate Datastore. Dacă ați urmat întreaga parte a NetApp din acest tutorial, sperăm, că vă aduceți aminte că am stabilit să folosim replicarea manuală / la cerere. Așa că, ar putea fi o idee bună, de a lăsa SRM-ul să folosească obțiunea de sincronizare, înainte de a testa failover-ul.
Progresele înregistrate cu fiecare pas efectuat este prezentat în tab-ul [NUME_REDACTAT]
Asigurați-vă că aveți deschis pe site-ul secundar clientul vSphere. Veți observa o mulțime de task-uri acolo. În scenariul prezentat în imagine s-a realizat un test failover pentru 4 mașini virtuale VM. Imaginați-vă cât de multe task-uri, veți vedea în bară, într-un caz real, cu sute de mașini virtuale VM.
Ar trebui, aruncată o privire și la configurația rețelei gazdă ESXi, pe site-ul secundar. Acolo veți găsi "bubble-network" pentru VM recuperat, pe care l-am menționat mai înainte.
Dacă toți pașii sau încheiat cu succes, mașinile virtuale VM sunt protejate, rulând, pe site-ul secundar, în timp ce acestea, încă ruleaza pe site-ul primar. Cred că este important să știți cum funcționează acestea în background. Sistemul de stocare de pe site-ul secundar creează o imagine al fiecărui Datastore, atunci când este inițializat un test failover. Acest lucru vă oferă posibilitatea de a avea acces la Datastore de pe acest site. Aceste instantanee (snapshot) cresc, în funcție de cantitatea de modificări care le sunt executate, în timp ce infrastructura rămâne în aceeași stare. Țineți minte acest lucru, când efectuați un test de failover.
Pentru a termina testul, faceți clic-dreapta din nou pe pe planul de recuperare și selectați Cleanup. Acest lucru va inversa toate etapele, care au fost executate înainte.
Veți vedea, din nou, un avertisment, înainte de a începe procesul de curățare (cleanup).
Va fi afișată din nou o fereastră de avertizare. Aici trebuie să selectați explicit „butonul” checkbox, care vă indică că știi ce urmează după ce ați apăsat pe butonul Next. De asemenea, va trebui să alegeți între [NUME_REDACTAT] și [NUME_REDACTAT] . Pașii SRM-ului fiind la fel, totuși există o mare diferență între acestea. Un exemplu de utilizare a obțiunii [NUME_REDACTAT] ar fi aceea ca SRM-ul planifică mutarea infrastructurii VMware pe un nou centru de date Datacenter XY. În acest caz, SRM va opri.mașinile virtuale VM de pe site-ul primar, reproduce Datastore la nivel de array și va trece prin toate etapele pe site-ul secundar pentru a obține totul și a reporni. În caz de eroare, SRM-ul se va opri imediat, dându-vă posibilitatea corectării erorii și obținerii unei tranziții ușoare la site-ul secundar.
Să aruncăm o privire la opțiunea [NUME_REDACTAT]. Cazul tipic de utilizare al acestei obțiuni este aceea de a întrerupe complet utilizarea site-ului primar (locației). Să presupunem că toate host-urile ESXi, vCenter și matricea de stocare sunt inaccesibile de la o secundă la alta. Dacă selectați obțiunea [NUME_REDACTAT] SRM-ul va încerca cu orice preț de a vă pune pe picioare întreaga infrastructură și a lucra pe site-ul secundar. În cazul în care nu este posibil, de exemplu sincronizarea Datastore. SRM-ul va afișa o eroare, dar va merge la următorul pas din planul său de redresare.
Dacă doriți să folosiți opțiunea [NUME_REDACTAT] Option ,vă sugerez, în mod deosebit, a rula înainte, un test, pentru a vă asigura că totul va rula fară nici o eroare, deoarece timpul este cel care ne limitează procesul de întreținere a unei infrastructuri. În general, aș rula simulări SRM, în mod regulat.
Nu contează ce tip de recuperare ați efectuat, ci, cât mai curând, de a reproteja infrastructura din nou. Să presupunem că centrul de date principal este din nou primul pas în a reproteja infrastructura, funcție numită Reprotect. Urmează funcția Recovery and [NUME_REDACTAT] nou o atenționare
Veți vedea că, mai aveți puține etape, de când ați început failover. Practic SRM își schimbă direcția de replicare. De fapt rulați întreaga infrastructă, pe site-ul secundar (nu contează dacă, numai pentru câteva ore, sau săptămâni) și aveți nevoie de a obține, din nou, o stare sincronă a datelor de pe ambele tablouri (array).
După ce replicarea s-a terminat, SRM-ul este gata de a executa un failback la site-ul primar. Ar trebui să alegeți opțiunea [NUME_REDACTAT] Option pentru această operație.
În cele ce urmează vă voi arăta unele situații de configurare avansată, în plus, față de configurarea de bază și configurarea din ultimele etape prezentate. De asemenea, voi trece prin unele erori comune.
Cea mai utilizată modificarea al unui plan de redresare este aceea de a stabili prioritățile, individual pentru mașinile virtuale VM. Implicit pentru toate mașinilor virtuale VM nivelul de prioritate este 3, ceea ce înseamnă că sunt alimentate în același timp. De obicei, aveți unele mașini virtuale pe care doriți a le porni înainte de toate celelalte ca AD, DNS, Firewall, etc. Ar trebui sortate doar acele tipuri de mașini virtuale într-un grup cu prioritate mai mare. SRM va porni, mai întâi, pe toate acele mașini virtuale și apoi va merge la următorul grup de prioritate, până când sunt pornite toate VM (pe VMware Tools sunt utilizate ca un indicator), sau se ajunge la o valoare timeout.
Un alt caz de utilizare a priorităților este de a evita boot storms, care ar trebui, cu siguranță luat în considerare pentru cazuri mari. Timpul total al planului de redresare trebuie să se termine într-un timp mai scurt, dacă vă veți împărți mașinile virtuale VM în mai multe grupuri de prioritate în loc de a alimenta sute de mașini virtuale, în același timp.
Poate că aveți, unele mașini virtuale VM, pe care nu vrei sa le „activezi” automat de la SRM. [NUME_REDACTAT] Action pe “Do not power on” și pornirea VM individual atunci când credeți că-i momentul potrivit.
Există o mulțime de opțiuni disponibile, pentru fiecare VM în parte. Faceți clic-dreapta pe VM-ul dorit și selectați Configure.
O mare facilitate, este aceea că puteți atribui o nouă configurare a rețelei pentru mașinile virtuale VM. Sperăm că aveți un VLAN întins între site-uri și nu are nevoie de aceste opțiuni, deoarece o schimbare de IP-uri, de asemenea, duce la o altă provocare (nu în legătură cu SRM-ul), cum ar fi, actualizarea DNS, etc
Mai sus, v-am arătat capacitatea de a pune mașinile virtuale în grupuri prioritare pentru a avea un ordin de boot-are structurat. Suplimentar, puteți configura dependent două mașini virtuale, care sunt din același grup de prioritate. Acest lucru este foarte util pentru mediile mari, caz în care cele șase grupuri prioritare nu sunt suficiente.
Implicit toate mașinile virtuale sunt monitorizate pentru a răspunde prin instrumentele VMware Tools la succesul acestui proces. Poate aveți unele mașini virtuale în mediul dumneavoastră, fără a rula VMware Tools? Dacă sunteți în acest caz, ar trebui să debifați „caseta” Wait din VMware Tools . Alternativ, puteți seta o valoare de întârziere (delay); în caz contrar conectarea (power on process) este imediat observată ca fiind făcută cu succes.
Ar trebui să verificați, opțiunile power off în cazul în care nu rulează VMware Tools pe un VM. În mod implicit SRM dorește să inițializeze o oprire curată a SO (clean shutdown). Fără VMware Tools sunteți nevoiți a seta shutdown cu power off.
O altă opțiune frumoasă este aceea de a suspenda mașinile virtuale, care rulează pe site-ul secundar, pentru a obține resurse gratuite. Acest lucru vă oferă posibilitatea de a utiliza resursele de la site-ul DR-ul, de exemplu, pentru un mediu de test, etc, fără a bloca orice resursă de sistem, în cazul unui failover cu SRM. În cele mai multe etape, din planul de redresare, veți găsi opțiunea " [NUME_REDACTAT]-Critical VM , pentru a face acest lucru.
SRM aduce o mulțime de alarme pe care le puteți configura individual. Vă recomand să aruncați o privire la acestea.
Pentru cazurile de depanare am să vă prezint unele erori pe care le-am văzut în SRM și câteva sfaturi de depanare.
Eroarea de comunicare între SAR și array-urile de stocare:
O eroare comună este că adaptorul SRA nu este în măsură să comunice cu array-ul de stocare. Veți primi erori, cum ar fi Unable to add array manager or SRA command “discoverArrays” failed.
Chiar se pare că mesajul vine de la Microsoft: Rebot your SRM server. De obicei, nu ați făcut o reboot-are între instalarea SRA și configurarea SRM. În special, în relație cu adaptorul EMC VNX, am văzut de fiecare dată această eroare și numai un reboot a fost întotdeauna soluția.
De asemenea, cu NetApp Simulator am văzut această eroare “options httpd.admin“, în cazul în care nu au fost făcute setările. Aruncați o privire, peste aceste setări din NetApp ONTAP Simulator descrise mai sus.
Enable pentru perechiile array, nu este posibil
Am văzut eroarea „SRA command ‘discoverDevices’ failed “, în cazul în care serverul SRM nu a avut permisiuni corecte pentru Datastores NFS replicate.
4 . [NUME_REDACTAT] [NUME_REDACTAT]
Rezultatul procesului de planificare și recuperare în caz de dezastru este documentul plan de redresare în caz de dezastru .
În timpul unei situații de urgență, acest document va fi principala sursă de informații pentru procedurile de recuperare în caz de dezastru.
4.1 . Cuprins de documente
Documentul plan de recuperare în caz de dezastru este singura sursă de informații de încredere pentru recuperare în caz de dezastru în timpul unei situații de urgență . Ar trebui să fie foarte ușor de citit, cu instrucțiuni simple și detaliate. În urma sunt unele din conținutul care trebuie să fie în acest document .
● Informații document : Documentul ar trebui să includă informații , cum ar fi
autori / proprietari , cu datele lor de contact , istoricul de revizuire și alte detalii de documente ( nume , locatie , versiune ) , referinte , iar publicul a documentului . În istoria de revizuire documentului , este bine să aibă o scurtă descriere a modificările făcute în fiecare versiune .
Un tabel de cuprins este o necesitate pentru referință rapidă , și este foarte recomandat ca secțiunile să fie numerotate de la cel mai mic nivel posibil în scop de referință ușoară . De asemenea, este bine de a oferi un statut confidențial corespunzătoare pentru document , deoarece conține informații sensibile .
● Scop : Scopul documentului trebuie să fie clar în introducerea , definirea obiectivelor planului intenționează să le realizeze .
● Domeniul de aplicare: domeniul de aplicare a planului definește circumstanțele în care planul este invocat și durata procedurilor definite în document sunt în vigoare . Diferitele condiții de avarie care conduc la invocarea planului ar trebui să fie enumerate în mod clar . De exemplu , un sistem fiind în jos pentru câteva ore, nu poate duce la invocarea planul , dar o pană de o zi poate fi suficientă . În mod similar , ar trebui să fie , de asemenea, în mod clar condițiile de la sistem a eșuat / instalația care justifică faza de reconstituire .
● Ipoteze : Orice condiții planul presupune a fi prezent pentru a avea succes trebuie să fie clar . Acest lucru poate implica listarea dependențele ale planului , precum și . De exemplu , un anumit număr de personal calificat poate fi presupus a fi disponibil la facilitatea de recuperare în caz de dezastru . Ori de câte ori este posibil , aceste dependențe trebuie să fie însoțite cu adecvate datele de contact .
● Excluderi : Orice activitati in caz de catastrofe legate de faptul că planul nu acoperă ar trebui să fie menționat și orice referințe cunoscute menționat aici . De exemplu , planul poate exclude planul de restaurare putere depinde , referindu-se în schimb la documentul corespunzător și datele de contact departament . Aceste informații vor fi utile în timpul de recuperare în caz de dezastru .
● [NUME_REDACTAT] :descrierea sistemului de recuperare în caz de dezastru ar trebui să fie ușor de înțeles cu cifrele corespunzătoare , diagrame de flux de lucru , și așa mai departe . Dacă este necesar, descrierile pot referință anexe care să ofere mai multe detalii . Funcțiile care trebuie să fie reînviat trebuie să fie menționat în mod clar .
● Roluri și Responsabilități : rolurile personalului de conducere și tehnic și responsabilitățile lor în timpul de activare , de execuție , și de reconstituire faze ar trebui să fie enumerate în mod clar . O diagramă de structură de organizare arată relațiile de raportare este benefică .
Un rol-cheie ar trebui să aibă personal primare și alternative atribuite .
● Detalii de contact: informații complete de contact ar trebui să fie incluse pentru toate personalului de conducere și tehnic implicat în fazele de planificare, de activare, de execuție, și de reconstituire.
Detalii de contact atât în situații normale și de situații de urgență ar trebui să fie menționate. Se recomandă această informație să fie adăugate ca o anexă la documentul de plan de redresare în caz de dezastru.
● Proceduri de activare : procedurile de notificare , evaluare a daunelor , precum și planificarea de activare ar trebui să fie subliniate . Orice subiect care trebuie să fie acoperite în detaliu poate fi adăugată ca un apendice .
● Proceduri de executie : procedura de recuperare pentru fiecare dintre componentele capacele de plan ar trebui să fie explicate pas cu pas în detaliu . Atunci când există fire paralele de sarcini , este benefic de a avea o schemă tehnologică a vizualiza dependențele ale sarcinilor . Criteriile de eșec Succesul și de fiecare procedură , de asemenea, ar trebui menționat , precum și instrucțiuni cu privire la acțiunile ulterioare în caz de atât succes și eșec .
● Proceduri reconstituire : proceduri similare pentru reconstituirea componentelor ar trebui să fie explicate în detaliu . Ar trebui să se acorde criteriilor de eșec și instrucțiunile pentru acțiuni suplimentare în caz de succes și eșec succesul și .
4.2 [NUME_REDACTAT]
Documentul plan de recuperare în caz de dezastru trebuie să fie ținute la curent cu mediul de organizare actual . Un plan care nu este actualizat și testat este la fel de rau ca nu au un plan de la toate, deoarece în timpul situațiilor de urgență , documentul poate fi înșelătoare . Sunt recomandate următoarele de întreținere a documentației planului .
● periodice Mock burghiu : Planul de redresare în caz de dezastru ar trebui să fie testate din timp în timp , folosind exerciții simulate programate . Un exercițiu de obicei nu va afecta operațiuni active , cu toate acestea , în cazul în care se știe că operațiunile vor fi afectate ,semănătoarea trebuie programat cu grijă astfel încâtefectul este minim și este efectuată în timpul unei ferestre admisă . Aceste activități ar trebui să fie considerate în mod similar cu activități regulate de întreținere a echipamentelor care necesită operațiuni de nefuncționare . Experiența de foraj bate joc ar trebui să fie actualizate în documentul de plan de recuperare în caz de dezastru .
● [NUME_REDACTAT] : Cel mai bun de testare documentul va fi supus este atunci când un dezastru real se intampla , iar lecțiile învățate în timpul de recuperare în caz de dezastru sunt valoroase pentru îmbunătățirea planului . Prin urmare, [NUME_REDACTAT] Recovery trebuie să se asigure că experiența devine capturat ca lecțiile învățate și documentul va fi actualizată în consecință .
● Actualizări periodice: Tehnologii, sisteme, și facilități care acoperă planul se pot schimba in timp. Este important ca documentul plan de recuperare caz de dezastru reflecta informațiile actuale despre componentele pe care le acoperă. În acest scop, Comitetul de recuperare în caz de dezastru ar trebui să se asigure că documentul este auditat periodic (sa zicem o dată pe trimestru) împotriva actuale componente ale organizației. Un alt mod de a realiza acest lucru este de a asigura că comitetul este notificat cu privire la orice schimbare care se intampla la orice sistem / component în organizație, astfel încât comisia poate actualiza documentul în consecință.
5 [NUME_REDACTAT] Ghidul de Planificare pentru [NUME_REDACTAT] Systems: Recomandări de la [NUME_REDACTAT] de Standarde si Tehnologie, de [NUME_REDACTAT], [NUME_REDACTAT], [NUME_REDACTAT], [NUME_REDACTAT], [NUME_REDACTAT], si [NUME_REDACTAT]. NIST 800-34 publicație specială, disponibil la:
http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf.
Dacă vă creați un plan de recuperare în caz de dezastru, unul dintre primele lucruri ce trebuie să faceți este să se determine ceea ce aveți nevoie pentru a proteja. Toate datele nu sunt create egal și nu există probabil nici un motiv de a reproduce și de a stoca fiecare bit și de octet pe serverele dumneavoastră.
Cele două metode primare de măsurare a critic al sistemelor IT sunt cât de mult de date și timp vă puteți permite să piardă.
Punctul de recuperare [NUME_REDACTAT] primul rând, [NUME_REDACTAT] de Recuperare (RPO), este acel prag de cât de multe datele pe care le pot permite să-și piardă de la ultimul backup. Definirea RPO companiei dvs. de obicei, începe cu examinarea cât de des are loc de rezervă. Deoarece rezervă poate fi deranjant pentru sistemele în care nu este de obicei efectuate mai frecvent decât câteva ore. Acest lucru înseamnă că RPO de rezervă este, probabil, măsurată în ore de pierderi de date.
Timp de recuperare Obiectiv
A doua, obiectivul Timp de recuperare (RTO) este pragul de cât de repede aveți nevoie de informații o cerere de restaurat. De exemplu, patru ore, opt ore, sau următoarea zi lucrătoare este un timp tolerat pentru sistemele de e-mail. Păstrați în minte cantitatea de timp este nevoie pentru a serverelor de furnizare, depozitare, resurse de rețea și de configurații de mașini virtuale.
Folosind aceste două măsuri principale vă va ajuta să înțelegeți costul de nefuncționare, ajuta la definirea unui buget pentru un plan de continuitate sistem informatic și de a determina tehnologia care satisface nevoile dumneavoastra în cadrul bugetului dumneavoastră.
Alegerea unei soluții de
Găsirea unui echilibru corect de caracteristici și preț pentru a satisface RPO și RTO este unul dintre lucrurile cele mai importante care le puteți face pentru a proteja afacerea dumneavoastra. Pentru continuitate sistem IT, există trei categorii de solutii: de backup, de disponibilitate ridicată și de recuperare în caz de dezastru.
Backup înseamnă păstrarea în condiții de siguranță de date, în această situație, RPO este mai critică decât RTO.
Disponibilitate ridicată înseamnă păstrarea aplicațiile critice și datele on-line – este necesară o soluție de înaltă disponibilitate pentru RPO și RTO mare
Recuperarea în caz de dezastru este capacitatea de a recupera datele, în cazul în care sistemul este deteriorat, distrus sau devine indisponibil pentru o perioadă nedeterminată de timp. O soluție completă de recuperare în caz de dezastru, care poate restaura datele rapid și complet sunt RPO scăzut și praguri RTO.
Vrei sa stii mai multe despre crearea unui plan de recuperare în caz de dezastru? Check out documentație nostru evaluarea impactului financiar al Downtime .
rpo and rto in disaster recovery
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Recuperarea In Caz de Dezastru (ID: 16480)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.