Plan de Recuperare în caz de Dezastru

Plan de Recuperare în caz de Dezastru

Asocierea S.C. CCT S.R.L. și S.C. Indaco Systems S.R.L.

Unitatea Executivă pentru FinanŃarea ÎnvăŃământului Superior, Cercetării, Dezvoltării și Inovării (UEFISCDI)

Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 2

Controlul Documentului

Istoricul versiunilor:

Versiune Data Autori

1 03.12.2010 CCT S.R.L. și INDACO Systems S.R.L.

1.1 12.09.2011 CCT S.R.L. și INDACO Systems S.R.L.

Istoricul autorizărilor:

Verificat de: Aprobat și impus de:

Gabriela Jitaru Manager de Proiect RMU

Manager RMU

Ion Gh. ROŞCA Coordonator Dezvoltare Sistem Informatic RMU

Gabriel Şutac Manager Proiect de Dezvoltare Aplicație

Marius Nicolaescu Coordonator IT UEFISCDI

Rezumatul schimbărilor:

Versiune Descriere

1 Prima versiune a Planului de Recuperare în caz de Dezastru aferent sistemului RMU.

1.1 Versiunea actualizată în urma finalizării implementării sistemului RMU

Distribuție:

Tip Către

Intern Toate departamentele

Grup Persoanele autorizate, cu nivel de acces >= C2 sau cu aprobarea explicită a Managerului RMU.

Extern Furnizori de servicii, cu nivel de acces aprobat și validat prin NDA >= C2.


Cuprins

1 Scop 5

2 Domeniu de aplicabilitate 5

3 Descriere generală 6

3.1 Vedere de ansamblu 6

3.2 Misiunea DRP 7

3.3 Strategia de recuperare în caz de dezastru și scopul planului DRP 7

3.3.1 Strategia de recuperare în caz de dezastru 7

3.3.2 Scopul DRP 8

3.4 Designul soluției de recuperare în caz de dezastru 8

4 Organizare, echipă și responsabilități 8

4.1 Organizarea planului DRP 8

4.2 Echipe și responsabilități 10

4.2.1 Comitetul de conducere DR 10

4.2.2 Echipa de intervenție DR 11

5 Definiția dezastrului și planul de escaladare 16

5.1 Definiția dezastrului 17

5.2 Scenarii de defecțiuni 17

5.3 Planul de escaladare 18

5.3.1 Planul de escaladare în cazul defecțiunilor din cauze naturale sau sociale 18

5.3.2 Planul de escaladare în cazul dezastrelor datorate defecțiunii directe a echipamentelor IT20

6 Descrierea sistemelor critice 22

6.1 Descrierea generală a Portalului central RMU 22

6.1.1 Descriere roluri utilizatori la nivel central 22

6.1.2 Prezentarea fluxurilor informaționale specifice nivelului central, coroborate cu prelucările locale, de la nivelul universității 24

7 Echipamente hardware existente la nivelul fiecărui sistem 25

7.1.1 Infrastructură la nivel central 25

7.1.2 Infrastructura de rețea pe care se face replicarea la nivelul DRC 28

8 Comutarea 28

8.1 Semnarea procesului verbal de constatare a comutării manuale 29

9 Replicarea 30

10 Planul de acțiune DRP 32

11 Testarea planului de recuperare în caz de dezastru 32

11.1 Opțiuni și metodologie de testare ale planului DRP 33

11.1.1 Optiuni de testare DRP 33


11.1.2 Metodologia testelor de DR 33

11.2 Planificarea testelor de recuperare în caz de dezastru 33

11.2.1 Dezvoltarea unui scenariu de testare 34

11.2.2 Criteriile testării 34

11.2.3 Verificarea și evaluarea rezultatelor testului 34

11.3 Documentarea testului de DR 35

11.3.1 Formular de evaluare a testului 35

11.3.2 Jurnalul problemelor 36

12 Mentenanța planului DRP 38

12.1 Privire de ansamblu 38

12.1.1 Mentenanța programată 38

12.1.2 Mentenanța neprogramată 38

12.2 Managementul problemelor și al schimbărilor 39

13 Procedura de revenire la locația primară 39

14 Neconformare 40

15 Revizuirea Planului de Recuperare în caz de Dezastru 40

16 Anexe 41

Anexa A. Echipamente IT în locația primară și în cea de recuperare în caz de dezastru 41

Anexa B. Inventarul facilitățile locației de recuperare în caz de dezastru 41

Anexa C. Inventarul aplicațiilor / modulelor și a metodelor de backup și replicare 41

Anexa E. Componența Echipei de intervenție DR 41

Anexa F. Diagramele de conectivitate 41


1 Scop

Scopul planului de recuperare în caz de dezastru, numit DRP (Disaster Recovery Plan), este de a prezenta infrastructura organizațională (proceduri și personal) și materială a sistemului RMU, creată pentru a recupera locația primară în cazul unui dezastru.

Infrastructura IT a locației primare include:

- Servere (servere web, servere de aplicație, servere de baze de date, servere de monitorizare, servere de managementul accesului și raportare);

- Infrastructura și echipamentele de rețea (rutere, switch-uri, firewall-uri, load-balancer-e, circuit fibră optică etc.);

- Software (sisteme de operare, baze de date, aplicații aferente sistemului RMU); - Alte echipamente și consumabile de birou; - Personal; - Documentații.

Planul de recuperare în caz de dezastru este un document operațional și va servi scopului său numai dacă:

- Organizarea, logistica, procedurile și alte documente definite în acest plan au fost create, testate și verificate;

- Dacă ghidurile şi procedurile definite în manualul DRP sunt îndeaproape urmărite la toate nivelele şi pe întreaga durată a acestei activități: pre-dezastru, dezastru și post-dezastru;

- Orice schimbare survenită în planul DRP sau în activitățile conexe este înregistrată urmând procedura de Managementul Schimbărilor.

Documentul prezintă următoarele aspecte:

- Descriere generală a Planul de Recuperare în caz de Dezastru (DRP); - Organizare, echipă și responsabilități; - Definiția dezastrului și planul de escaladare; - Descrierea sistemelor critice - Infrastructura logică și hardware RMU, atât din locația primară cât și din cea secundară; - Modalități de comutare și replicare - Planul de acțiune DRP; - Testarea planului DRP; - Mentenanța planului DRP; - Procedura de revenire la locația primară.

2 Domeniu de aplicabilitate

Măsurile detaliate în acest document fac referire la sistemul RMU și prezintă o modalitate integrată de recuperare în caz de dezastru.


3 Descriere generală

3.1 Vedere de ansamblu

Planul de recuperare în caz de dezastru trebuie să includă următoarele faze, atât la pregătirea cât și la implementarea sa:

Obiectivele

afacerii

Stabilitea strategiei de

recuperare în caz de

dezastru

Design infrastructură de


dezastru

Instalarea infrastructurii de


dezastru

Testare și validare DRPInstruire personal

operațional DRP

Creare și

documentare DRP

Locația principală

operațională

Execută procedură backup

DRP

Dezastru?

Execută plan de acțiunea

DRP*

Locația secundară de

recuperare operațională

Execută procedură backup

DRP

Execută procedură de

întoarcere la locația

principală

DAM

an

agem

entu

l sc

him

bă

rilo

r**

NU

* Este declarată situație de tip Dezastru, când se vor aplica măsurile capitolului 8.

** Trebuie folosite procedurile de Managementul Schimbării pentru mentenanța strategiei de recuperare în caz de dezastru.

Așa cum reiese din schema de mai sus, la baza unui plan de recuperare în caz de dezastru rezidă activitățile ce sunt executate atunci când este instituită starea de dezastru. Aceste activități nu pot fi izolate de planul general DRP deoarece sunt doar o parte a unui plan structurat. Pe de altă parte, planul DRP poate deveni inconsistent și poate eșua dacă orice parte a sa este neglijată sau ignorată.


Schema de mai sus indică faptul că planul DRP este supus unei evoluții continue, strâns legată de cea a Structurii RMU și a mediului în care aceasta evoluează. Dacă planul DRP nu evoluează, dacă nu este dezvoltat în paralel cu evoluția sistemului RMU, în final va deveni învechit și, invariabil, va eșua.

3.2 Misiunea DRP

Misiunea planului de recuperare în caz de dezastru este de a reduce sau elimina impactul unui dezastru asupra activităților Structurii RMU, astfel:

- Stabilirea în avans a metodelor alternative de funcționare; - Instruirea personalului în proceduri de criză; - Micșorarea întreruperilor aduse funcționării obișnuite; - Revenirea operațiunilor, rapidă şi lină, în locația primară.

Toate aceste scopuri sunt atinse prin:

- Angajamentul management-ului la strategia stabilită de recuperare în caz de dezastru; - Implicarea și cooperarea personalului pentru stabilirea și documentarea DRP; - Instruirea și reinstruirea personalului pentru recuperare în caz de dezastru; - Testarea continuă a DRP; - Actualizarea continuă a planului prin procesul de management al schimbării.

3.3 Strategia de recuperare în caz de dezastru și scopul planului DRP

3.3.1 Strategia de recuperare în caz de dezastru

Strategia de recuperare în caz de dezastru constă în opțiuni bazate în primul rând pe obiectivele și nevoile de business, dar și pe fezabilitatea economică și tehnologică. În cazul de față au fost luate următoarele decizii strategice:

- Următoarele echipamente și aplicația centrală RMU din locația primară sunt considerate critice și se vor regăsi în locația de recuperare în caz de dezastru:

Nume modul aplicația centrală Număr mașini fizice

Oracle Business Intelligence Suite Enterprise Edition Plus 2

Internet Application Server Enterprise Edition 2

Oracle Portal 2

Oracle Access Management 2

Oracle Enterprise Manager Grid Control 2

Oracle Database Enterprise Edition 2

- Pentru aplicațiile specificate mai sus indicele RTO (Recovery Time Objective) este de 15 minute. Indicele RPO (Recovery Point Objective) este de 5-10 minute.

- Întoarcerea la funcționare normală, urmată de o perioadă de funcționare limitată în locația secundară reprezintă întoarcerea operațiunilor în locația primară.


3.3.2 Scopul DRP

Scopul DRP este rezumat în următoarele puncte:

- Planul DRP acoperă echipamentele și operațiunile IT din centrul de date aferent aplicației centrale RMU aflat în [DE DEFINIT].

- Centrul de date din locația secundară va servi ca centru de recuperare în caz de dezastru (locația secundară);

- Planul DRP se aplică întregului mediu IT de producție.

3.4 Designul soluției de recuperare în caz de dezastru

Scopul strategiei de recuperare în caz de dezastru subliniat mai înainte trebuie să se materializeze în decizii de design, care în schimb pot aduce constrângeri sau cerințe legate de designul detaliat sau de operațiunile IT, în general. Mai jos sunt prezentate aceste decizii de design împreună cu alte considerente strâns legate (ipoteze, constrângeri și premise).

Scenariul de dezastru și principalele ipoteze:

- Un scenariu de dezastru este considerat orice întrerupere totală a activității sistemelor informatice RMU. Fiecare întrerupere parțială de sistem nu impune activarea locației secundare și nu este considerată dezastru;

- Precedând un dezastru este preferabil un mediu stabil, în care sistemele au fost corect și complet sincronizate.

Constrângeri legate de design:

- În practică, un timp RTO redus este posibil numai cu un Plan DRP foarte bine testat și repetat. Execuția eficientă a DRP-ului depinde atât de factorul uman, cât și de cel organizațional și de infrastructura informațională. Cea mai importantă problemă a soluției de design o reprezintă modalitatea de replicare a datelor: aceasta trebuie să garanteze integritatea și consistența acestora. Aceste calități trebuie să fie garantate atât de motoarele de replicare ale aplicațiilor / bazelor de date (replicare sincronă/asincronă) cât și de sistemele de stocare (replicare sincronă/asincronă).

- Atingerea timpului RTO depinde foarte mult și de eficiența și viteza procesului de rezolvare a problemelor, dar și timpului de decizie care influențează direct timpul total de recuperare în caz de dezastru.

4 Organizare, echipă și responsabilități

4.1 Organizarea planului DRP

Execuția și mentenanța planului DRP este bazată pe o structură organizațională specială, paralelă cu structura operațională obișnuită, care este mai mult sau mai puțin activă, depinzând de ciclul de viață al procesului de recuperare în caz de dezastru.

Structura organizațională include factori de decizie (Managerul RMU), coordonatori de plan (Managerul tehnic RMU), designeri, dezvoltatori și executanți. Toți aceștia vor fi grupați în echipe funcționale, fiecare cu propriul rol și propria responsabilitate.


În caz de dezastru recomandăm următoarea structură:

Structura RMU

Departament IT

Manager tehnic

RMU

Responsabil cu

securitatea informațiilor

Responsabil

aplicații universități

Responsabil baze de

date

Responsabill

hardware

Responsabil politici

Departament

nomenclatoare și rapoarte RMU

Manager științific

RMU

Responsabil

nomenclatoare

Responsabil

rapoarte central

Responsabil

rapoarte

universități

Manager RMU


4.2 Echipe și responsabilități

4.2.1 Comitetul de conducere DR

În principal acest comitet este format din Managerul RMU împreună cu Managerul tehnic și Managerul științific, dar pot fi implicate și alte persoane reprezentând factori de decizie la nivelul sistemului RMU. Rolul său este de a lua decizii majore legate de strategia de recuperare în caz de dezastru, decizii care de obicei au la bază investiții mari financiare.

Întâlnirile acestui comitet sunt generate de o cerere a managementului sau printr-o escaladare făcută de Coordonatorul DR.

De asemenea, comitetul trebuie să decidă dacă, într-un caz particular, este asigurată starea de recuperare în caz de dezastru sau nu, bazat pe datele transmise de membrii Echipei de intervenție.

Rolul acestui comitet este critic mai ales pentru că declararea unui dezastru este:

- O decizie costisitoare - Implică riscuri tehnice și de business - Poate impacta imaginea companiei pe piață

În cazul declarării unei situații de tip dezastru, Echipa de intervenție DR trebuie convocată.

Structura RMU

Echipă de

intervenție DR

Coordonator DR

Responsabil baze de date DR

Responsabil aplicații DR

Responsabil hardware DR

Responsabil cu securitatea

informațiilor DR

Operațional (nomenclatoare

și rapoarte RMU) DR

Comitet de

conducere DR


4.2.2 Echipa de intervenție DR

Aceasta este împărțită pe următoarele roluri:

- Coordonator DR;

- Responsabil baze de date DR;

- Responsabil aplicații universități DR;

- Responsabil hardware DR;

- Responsabil cu securitatea informațiilor DR;

- Operațional (nomenclatoare și rapoarte RMU) DR;

4.2.2.1 Coordonator DR

Acest rol poate fi luat de Managerul tehnic RMU și presupune cea mai mare responsabilitate legată de planul DRP.

Faza DRP Responsabilități

Dezvoltare - Supraveghează documentarea, publicarea și propagarea planului DRP

- Actualizează manualul DRP atunci când infrastructura, operațiunile sau organizarea se schimbă;

- Participa la toate ședințele în care se iau decizii majore legate de planul DRP;

- Participă la stabilirea procedurilor de declarare a stării de dezastru.

Testare - Organizează testele de recuperare în caz de dezastru în colaborare cu ceilalți membri ai Echipei de intervenție, după un program fix sau ori de câte ori este nevoie;

- Evalueaza și prezintă testele de DR și raportează constatările către Comitetul de conducere.

Operațiune Normală

- Actualizează planul DRP prin procedura de managementul schimbărilor atunci când schimbările din locația primară impactează locația de recuperare;

- Asigură că planul DRP este aplicat și respectat la toate nivelurile în organizație;

- Organizează centrul de control al dezastrului în locația secundară și notifică tot personalul implicat să raporteze la locația de recuperare în caz de dezastru. Inițiază procedurile de recuperare;

- Se întâlnește cu ceilalți membri ai Echipei de Intervenție, la intervale regulate, pentru actualizare planului și dezbaterea problemelor ce pot influența planul.

Declararea dezastrului. Recuperare

- Are contactul inițial cu personalul DR la apariția unei probleme critice pentru a raporta situația. Escaladează problemele către Comitetul de conducere DR;

- Are contactul inițial atunci când dezastru survine. Are o întâlnire cu Comitetul de conducere DR;

- Coordonează activitățile Echipelor de intervenție pe durata mutării, dar și pe durata operațiunilor în locația secundară, până când toate serviciile sunt în stare de funcționare. Până la reîntoarcerea în locația primară, Coordonatorul DR va prelua conducerea locației de recuperare;

- Ține la curent Comitetul de conducere DR.

Întoarcere la - Planifică și programează aducerea în stare de funcționare a locației primare;


locația primară - Planifică, programează și organizează întoarcerea în locația primară;

- Coordonează întoarcerea în locația primară.

4.2.2.2 Responsabil hardware DR

Este persoana responsabilă pentru infrastructura hardware IT și are datoria de a asigura ca planul DRP este aplicat la toate nivelele în locația secundară, și că toate echipamentele din acestă locație sunt în stare bună de funcționare.


Dezvoltare - Identifică toate echipamentele IT necesare în locația secundară, cu accent pe cele critice;

- Identifica versiunile de microcod / firmware / software necesare în locația secundară;

- Cooperează cu Coordonatorul DR pentru documentarea echipamentelor și infrastructurii IT;

- Crează design și dezvoltă infrastructura și procedurile de backup;

- Creaza design și dezvoltă procedurile de recuperare;

- Pregătește scripurile / codul pentru locația primară și cea de recuperare;

- Dezvoltă reguli de control ale planului DRP în colaborare DR Responsabil cu securitatea informațiilor;

- Creaza SLA-uri cu furnizorii de echipamente și servicii critice pentru locația de recuperare în caz de dezastru;

- Documentează scenarii de recuperare / comutare parțială și totală;

- Dezvoltă procedurile de test pentru recuperare în caz de dezastru;

- Documentează toate acțiunile de mai sus.

Testare - Cooperează cu Coordonatorul DR pentru programarea testelor și alegerea personalului din cadrul Echipei de intervenție;

- Realizează testele de recuperare în caz de dezastru;

- Verifică starea operațională a echipamentelor IT din locația secundară;

- Notifică Coordonatorul DR relativ la problemele găsite și recomandă soluții;

- Evaluează și prezintă rezultatele testelor de recuperare în caz de dezastru;

- Notifică Coordonatorul DR relativ la eventualele schimbări necesare în sistemele de producție.

- Creaza și menține un jurnal cu problemele apărute;

- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de rezultatele testelor;

- Verifica și programează job-urile tip batch.


- Realizează verificări periodice asupra situației operaționale a echipamentului IT din locația secundară;

- Asigură funcționarea corectă a rețelei în locația secundară, incluzând linia de replicare;

- Notifică Coordonatorul DR relativ la eventualele schimbări necesare în


sistemele de producție și replicarea acestora în locația secundară (dacă este nevoie);

- Asigură bune condiții de bună funcționare a locației secundare (alimentare cu energie electrică, UPS, umiditate etc.);

- Asigură că furnizorii au la dispoziție orice documentație necesară în cazul în care este instaurată starea de dezastru;

- Escaladează problemele către Comitetul de conducere DR, atunci când intervenția acestuia este necesară. Problemele pot fi de strategie sau tehnice.;

- Participă, împreună cu ceilalți membri ai Echipei de intervenție la ședințe regulate pentru discutarea problemelor ce pot impacta viabilitatea planului DRP.

- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de rezultatele întâlnirilor;

- Efectuează zilnic operații de backup/restore;


- Aplică procedurile de recuperare în caz de dezastru;

- Ajunge în locația de recuperare pentru a verifica funcționarea echipamentelor și a infrastructurii IT;

- Notifică Coordonatorul DR despre problemele apărute. Recomanda soluții;

- Contactează furnizorii de servicii și echipamente și monitorizează acțiunile acestora;

- Ajută Coordonatorul DR în managementul personalului și al problemelor tehnice;

- Menține un jurnal cu problemele apărute;

- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de situația de facto și de deciziile luate;

- Programează job-urile tip batch.

Întoarcere la locația primară

- Recomandă Coordonatorului DR cerințele pentru repornirea activităților IT în locația primară;

- Ajută la „reconstruirea” locației primare din punctul de vedere al infrastructurii hardware, inclusiv al rețelei;

- Instalează și configurează echipamentele hardware din locația primară pentru mediul de producție;

- Aplică procedurile de întoarcere la locația primară;

- Monitorizeaza activitățile furnizorilor (instalare de echipamente, configurare echipamente, etc.);

4.2.2.3 Responsabil baze de date DR


Dezvoltare - Identifică sistemele critice (baze de date) care sunt necesare în locația secundară;

- Documentează aceste sisteme;

- Creaza design și dezvoltă procedurile și infrastructură de backup și restore;

- Documentează infrastructura și procedurile de backup/restore;

- Pregătește și documentează scripturile de backup/restore;


- Creaza designul și dezvoltă infrastructura și procedurile de recuperare la nivelul sistemului; documentează aceste acțiuni;

- Pregătește și documentează scripturile de recuperare la nivelul sistemului;

- Dezvoltă teste și proceduri de recuperare în caz de dezastru pentru acțiunile de mai sus; documentează testele și procedurile de recuperare în caz de dezastru.

Testare - Realizează teste de recuperare în caz de dezastru și de replicare;

- Crează și menține un jurnal cu problemele apărute;

- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de rezultatele testelor.


- Monitorizeaza periodic operațiunile și infrastructura de backup (incluzând replicarea între locația primară și cea secundară) în locația primară;

- Monitorizează periodic operațiunile și infrastructura de backup (incluzând replicarea între locația primară și cea secundară) în locația secundară;

- În urma acțiunilor de mai sus aplică măsuri corective, dacă este cazul;

- Se întâlnește regulat cu Coordonatorul DR pe care îl informează cu privire la problemele apărute ce pot influența viabilitatea planului DRP;

- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de rezultatele întâlnirilor.


- Aplică procedurile de recuperare a sistemului din planul DRP;


- Actualizează scripturi, cod, proceduri, manualul DRP în funcție de rezultate.


- Recomandă Coordonatorului DR cerințele pentru repornirea activităților IT în locația primară;

- Ajută la „re construirea” locației primare din punctul de vedere al sistemelor IT;

- Instalează și configurează serverele de baze de date în locația primară pentru mediul de producție;

- Aplică procedurile de întoarcere la locația primară.

4.2.2.4 Responsabil cu securitatea informațiilor DR


Dezvoltare - Pune la dispoziție instrucțiuni astfel încât manualul DRP să fie conform cu standardele Structurii RMU din perspectiva securității informației.

Testare - Asigură documentarea corectă a rezultatelor testelor conform cu standardele organizației.


- Actualizează planul DRP cu potențiale riscuri.


- Investighează cauzele dezastrului.


- Evaluează activitățile de recuperare în caz de dezastru;

- Documentează activitățile de recuperare în caz de dezastru.


4.2.2.5 Responsabil aplicații DR


Dezvoltare - Stabilește ordinea în care modulele aplicației centrale trebuie pornite în locația secundară, interdependența lor;

- Identificarea aplicațiile critice pentru funcționarea locației de recuperare;

- Realizează designul, dezvoltă și îmbunătățește procedurile de recuperare;

- Pregătește scripturile/codul necesar și le documentează;

- Pregătește procedurile de testare de recuperare pentru aplicații, împreună cu Responsabilul baze de date DR și Operațional DR. Documentează aceste proceduri.

Testare - Realizează testele de recuperare pentru aplicația centrală.

- Lucrează împreună cu echipa Responsabilul baze de date DR și Operațional DR pentru verificarea testelor și a integrității și validității datelor de ieșire rezultate din testare;


- Actualizează planul DRP în funcție de rezultatele testelor.


- Se întâlnește regulat cu Coordonatorul DR pentru informări asupra problemelor ce pot influența validitatea planului DRP;

- Actualizează planul DRP în funcție de aceste întâlniri.


- Efectuează procedurile de DRP.

- Lucrează cu Responsabilul baze de date DR și Operațional DR pentru verificarea integrității și validității datelor, după aplicarea procedurii de recuperare în caz de dezastru;

- Menține un jurnal cu problemele apărute în timpul procedurii de recuperare în caz de dezastru;

- Actualizează planul DRP în funcție de rezultatele procesului de recuperare.


- Lucrează cu Responsabilul baze de date DR și Operațional DR pentru verificarea integrității și validității datelor, după procesul de întoarcere în locația primară;


- Actualizează planul DRP în funcție de rezultatele procesului de întoarcere în locația primară.


4.2.2.6 Operațional DR

Această echipă conține membrii Departamentului de nomenclatoare și rapoarte RMU care sunt relocați în locația secundară și are următoarele responsabilități:


Dezvoltare - Colaborează cu Responsabilul aplicații DR și Responsabilul baze de date DR pentru verificarea și aprobarea proceselor și procedurilor de recuperare ale aplicației centrale;

- Colaborează cu Responsabilul aplicații DR și Responsabilul baze de date DR pentru dezvoltarea și documentarea procedurilor de verificare și reconciliere ale datelor ce vor fi aplicate după procesul de recuperare;

- Dezvoltă și documentează proceduri adiționale de business pentru operarea în locației de recuperare;

- Colaborează cu Responsabilul aplicații DR și Responsabilul baze de date DR pentru dezvoltarea procedurilor de testare a aplicației centrale în locația de recuperare;

Testare - Participă la testarea aplicației centrale în locația secundară

- Colaborează cu Responsabilul aplicații DR și Responsabilul baze de date DR pentru verificarea și validarea datelor după testele de recuperare.


- Nu au nici o îndatorire directă.


- Participă la pornirea aplicației central în locația secundară;

- Colaborează cu Responsabilul aplicații DR și Responsabilul baze de date pentru verificarea și validarea datelor după terminarea procedurii de recuperare.


- Nu au nici o îndatorire directă.

5 Definiția dezastrului și planul de escaladare

În acest capitol sunt definite caracteristicile evenimentelor ce pot avea loc în locația primară și care sunt considerate ”dezastru”.

Intenția acestei secțiuni este aceea de a ghida factorii de decizie IT, atunci când aceștia se confrunta cu defecțiuni majore în sistemul RMU, în a lua decizii demne de încredere, decizii în cel mai bun folos al activității curente. Se încearcă o simplificare și sistematizare a proceselor de decizie, introducând categorii predefinite de probleme și modele de răspuns pentru fiecare categorie.

Decizia de a declara “dezastru” trebuie luată cu mare atenție, dar pe cât de obiectiv posibil, întrucât:

- Este posibil ca mutarea operațiunilor în locația secundară să nu rezolve problema; - Este posibil ca mutarea în locația secundară să coste mai mult decât pierderile datorate

problemei în sine.


5.1 Definiția dezastrului

Planul DRP definește ca dezastru, în primul rând, distrugerea fizică a echipamentelor, infrastructurii informatice și a altor facilități din locația primară. Distrugerea este într-o astfel de măsură încât nu mai poate fi reparată într-un interval de timp rezonabil, aducând astfel prejudicii foarte mari sau chiar iremediabiabile organizației / activității curente.

O a doua definiție a dezastrului este defectarea permanentă a unuia din echipamentele critice operațiunilor, defecțiune ce, de asemenea, nu poate fi reparată într-un interval de timp rezonabil și care poate crea pierderi foarte mari sau chiar iremediabiabile organizației / activității curente.

Definițiile de mai sus exclud următoarele evenimente ca fiind incluse în categoria “dezastre”:

- Cazuri de nefuncționare a unor componente individuale ale unuia sau mai multor sub-sisteme, ce sunt rezolvate prin mentenanța obișnuită a respectivelor echipamente. Pentru a optimiza mentenanța echipamentelor, trebuie încheiate contracte cu furnizorii acestora;

- Defecțiuni de sistem sau aplicație din cauza oricărei forme de distrugere / corupere de date (fizică sau logică) ce poate fi reparată on-site, în timp util, conform cu procedurile de rezolvare a problemelor și cele de backup/recovery.

5.2 Scenarii de defecțiuni

În cadrul acestui sub-capitol este prezentată o listă de categorii majore de defecțiuni ce pot apărea în locația primară. Pentru fiecare categorie este indicat răspunsul cel mai potrivit.

Categoriile sunt prezentate la nivel general, și nu vor putea asigura 100% că decizia luată în acel caz este corecta.

De asemenea, anumite aspecte ale defecțiunilor descrise nu sunt luate în considerare, dar acestea pot avea o greutate semnificativă în balanța decizională. Aceste sunt:

- Natura exactă a defecțiunii; - Temporizarea defecțiunii: zi, noapte, sfârșit de săptămână, sfârșit de luna etc.; - Intervalul de timp necesar pentru a identifica cu exactitate defecțiunea și pentru a evalua

impactul acesteia asupra activității curente; - Timpul necesar pentru repararea defecțiunii; - Dacă este posibilă repararea defecțiunii prin procedeele obișnuite.

Acoperirea acestor aspecte nu se află în scopul următoarei liste:

Nr. Descrierea evenimentului Dezastru? Acțiuni

1 Pierderea echipamentelor IT din cauza avarierii clădirii (incendiu, inundație, cutremur)

DA Planul de acțiune DRP

2 Avaria parțială a clădirii fără pierderi la nivelul infrastructurii IT

NU Controlul pierderilor și continuarea operațiunilor.

3 Pierderea sau inoperabilitatea echipamentelor IT datorită defecțiunilor de infrastructură a clădirii (curent, aer condiționat) și care sunt prevăzute să dureze pentru mai mult de 1 zi.

DA Planul de acțiune DRP

4 Distrugere parțială a infrastructurii clădirii fără pierderi ale infrastructurii IT


5 Pierderi în infrastructura IT datorită unei distrugeri DA Planul de acțiune DRP


generalizate.

6 Defecțiuni ale echipamentelor de rețea sau defecțiuni a unor conexiuni de date.


7 Pierderea capabilității de replicare NU Repară, apoi resincronizează

8 Defecțiune fizică în sistemul de stocare a datelor. NU Repară în locația primară, apoi restaurează datele.

9 Defecțiune logică în sistemul de stocare a datelor. NU Repară în locația primară, apoi restaurează datele.

Este subliniat astfel că problemele directe ale echipamentelor IT (defecțiunile de la sine) nu constituie un dezastru și pot fi reparate prin procedurile standard.

5.3 Planul de escaladare

Acest plan conține o serie de acțiuni ce trebuie efectuate din momentul în care problema este descoperită până în momentul în care trebuie luată decizia de rezolvare: on-site sau declararea dezastrului (mutarea în locația secundară).

Cursul planului de escaladare diferă, în funcție de sursa defecțiunii sau a dezastrului. Sunt definite două cauze majore ale unui dezastru:

- Defecțiuni din cauze naturale sau sociale; - Defecțiuni ale unor echipamente.

5.3.1 Planul de escaladare în cazul defecțiunilor din cauze naturale sau sociale

Această categorie include evenimente distructive naturale (cum ar fi incendiile, cutremurele, inundațiile etc.) și cele obstructive (cum sunt: greve, amenințări cu bombă, incendii în vecinătate etc.).

Planul DRP este valabil pentru dezastrele după care suficient personalul Structurii RMU este disponibil pentru continuarea operațiunilor în locația secundară și nu cazurile în care membrii personalului devin victime ale dezastrului.

Sunt acoperite punctele 1, 3 și 5 din tabelul de scenarii.


Eveniment/Stare Acțiuni Responsabili și participanți Durata*

Social/Dezastru natural Trebuie implicat Coordonatorul DR Orice persoană care identifică un astfel de eveniment

Evaluarea dezastrului Contactare și consultare cu:

- Personalul de mentenanță al clădirii - Personalul de securitate a clădirii - Furnizorii de echipamente IT (dacă este necesar) - Serviciile publice implicate în incident.

Evaluare dimensiunilor daunelor și duratei întreruperi activităților.

Coordonator DR

(mentenanța clădirii, securitatea clădirii, furnizori, servicii publice)

Rezultat pozitiv după evaluarea întreruperii:

- Aplicațiile critice nu sunt întrerupte?

- Echipamentele de rețea critice nu sunt întrerupte?

- Durata totala este rezonabilă?

- Evită/admite dauna; - Repară/Repornește aplicația centrală; - Continuarea operațiunilor în mod “degradat”

(informează departamentele)

Coordonator DR

(mentenanța clădirii, securitatea clădirii, furnizori, suport tehnic intern, operațiuni)

Rezultat negativ după evaluarea întreruperii:

- Aplicațiile critice sunt întrerupte?

- Echipamentele de rețea critice sunt întrerupte?

- Durata totala este prea mare?

- Escaladează la Comitetul de conducere DR Coordonator DR

Comitetul de conducere DR - Comitetul este informat - Dezastrul este recunoscut/declarat

Comitetul de conducere DR

(Coordonator DR)

Inițierea Planului DRP Pornește execuția planului DRP Coordonator DR

* Coloana ”Durata” trebuie completată la prima simulare de recuperare în caz de dezastru.


5.3.2 Planul de escaladare în cazul dezastrelor datorate defecțiunii directe a echipamentelor IT

Acest plan acoperă punctele 2, 4, 6, 7, 8 și 9 din tabelul cu scenarii de dezastru.

Eveniment/Stare Acțiuni Responsabili și participanți Durata*

Oricare din următoarele defecțiuni:

- Verificarea unui proces - Verificarea datelor într-o baza de

date

- Caută cauza defecțiunii - Contactează suportul tehnic - Contactează furnizorii

Coordonator DR

Problema este rezolvată de Responsabilul baze de date, de Responsabilul aplicații sau de Responsabilul hardware?

- Repară/repornește sistemul - Continuă operațiunile

Coordonator DR

(Responsabilul baze de date, Responsabilul aplicații și Responsabilul hardware)

Problema persistă?

- Suport tehnic on-site - Specialiștii furnizorilor on-site

- Descoperă cauza/rezolva problema - Aplicarea unor măsuri corective

Coordonator DR

(furnizori)

Problema descoperită/rezolvată? - Repară/repornește sistemul - Continuă operațiunile

Coordonator DR

(Echipa de intervenție DR)

Problema persistă? - Evaluează daunele; - Evaluează durata.

Coordonator DR

(Suport tehnic și specialiștii furnizorilor)

Rezultat pozitiv după evaluarea întreruperii:

- Aplicațiile critice nu sunt întrerupte?

- Echipamentele de rețea critice nu sunt întrerupte?

- Durata totala este rezonabilă?

- Evită/admite dauna; - Repară/repornește sistemul - Continuarea operațiunilor în mod “degradat”

(informează Comitetul de conducere DR)

Coordonator DR

(Suport tehnic și specialiștii furnizorilor)


Rezultat negativ după evaluarea întreruperii:

- Aplicațiile critice sunt întrerupte? - Echipamentele de rețea critice

sunt întrerupte? - Durata totală este prea mare?

- Escaladează la Comitetul de conducere DR Coordonator DR

Comitetul de conducere DR - Comitetul este informat - Dezastrul este recunoscut/declarat

Comitetul de conducere DR (Coordonator DR)

- Inițierea Planului DRP - Pornește execuția planului DRP Coordonator DR

* Coloana ”Durata” trebuie completată la prima simulare de recuperare în caz de dezastru.


6 Descrierea sistemelor critice

În continuare este prezentată componenta critică a sistemului RMU vizată în cadrul planului DRP – Portalul central RMU. Aplicația locală instalată la nivelul fiecărui universități nu face obiectul prezentei proceduri, fiecare universitate fiind responsabilă de buna funcționare a acestei componente, implicit de confidențialitatea, disponibilitatea și integritatea datelor proprii.

6.1 Descrierea generală a Portalului central RMU

Scopul principal al Portalului RMU presupune realizarea unei baze de date comună cu toate persoanele din învățământul superior și identificarea în mod unic a persoanelor, prin atribuirea și implicit generarea unui Număr Matricol Unic la nivelul RMU.

Portalul central RMU își propune colectarea informațiilor furnizate de universități și expunerea acestora în diverse formate de raportare. Pentru realizarea bazei de date centralizate, Portalul RMU extrage datele despre studenți/masteranzi/doctoranzi de la fiecare universitate acreditată sau autorizate să funcționeze provizoriu.

Portalul poate fi accesat atât de utilizatorii publici (fără niciun fel de autentificare), precum și de utilizatorii privați (cei care accesează aplicația cu nume de utilizator și parolă). Utilizatorii privați vor avea acces, în funcție de rolul fiecăruia în sistem, la diferite funcționalități ale aplicație.

La nivel de categorii de utilizitatori, fiecare student va beneficia, la cerere, de un cont de acces în Portalul RMU. Totodată, fiecare universitate va avea în mod obligatoriu un cont în Portalul RMU care va fi utilizat și pentru exportul datelor despre studenți din aplicațiile locale către Portalul RMU.

Portalul central RMU este interconectat cu toate aplicațiile locale RMU de culegere și validare a datelor, iar schimbul de informații se realizează biunivoc:

- Portalul central RMU va expune către aplicațiile locale versiunile nomenclatoarelor ce vor utilizate pentru exportul datelor către centru;

- Aplicațiile locale vor exporta datele către Portalul central RMU (exportul datelor se va realiza folosind conturile universității respective).

6.1.1 Descriere roluri utilizatori la nivel central

Rolurile sistemului vor asigura accesul la anumite categorii de informații. Fiecare utilizator din sistem va avea un rol predefinit de administratorul RMU. În momentul în care se generează un nou utilizator, administratorul RMU va selecta rolul acestui utilizator în sistem.

Sistemul va avea următoarele roluri:

- administratorul – are acces la secțiunea de administrare a portalului RMU; editează zonele publice din Portalul RMU; operatorii vor edita sectiunea de informaŃii generale şi secŃiunea cu fişiere care vor fi afișate în zona publică a Portalului RMU;

- manager – acces să vizualizeze toate datele (accesul se va realiza prin intermediul rapoartelor puse la dispoziție de administratorul RMU și publicate prin Oracle BI);

- student – acces numai la datele personale; - universitate – acces numai la datele raportate de universitatea respectivă; În cadrul

aceste categorii se disting două sub-categorii: manager și operator universitate, fiecare cu funcționalitățile aferene;


- acces instituții – acces numai la setul de date pus la dispoziție de administratorul RMU prin intermediul rapoartelor.

Aceste roluri sunt gestionate de administratorul RMU și vor fi atribuite utilizatorilor în momentul în care se face un nou cont de utilizator.

Utilizatorii vor accesa sistemul prin următoarele posibilități:

- Acces liber în secțiunile publice ale Portalului; - Acces pe baza unui nume de utilizator și a unei parole (în zonele de editare informații, în cele de administrare și în cele de vizualizare informații raportate de către universități).

Administrator

Are acces la secțiunea de administrare a portalului RMU; Editează zonele publice din Portalul RMU; operatorii vor edita sectiunea de informaţii generale şi secţiunea cu fişiere care vor fi

afisate in zona publică a Portalului RMU

Universitate

Acces numai la datele raportate de universitatea respectivă

Manager / Operator

Manager

Acces să vizualizeze datele prin intermediul

rapoartelor

Student

Acces numai la datele personale

Acces institutii

Acces numai la setul de date pus la dispoziție de

administratorul RMU prin intermediul rapoartelor


6.1.2 Prezentarea fluxurilor informaționale specifice nivelului central, coroborate cu prelucările locale, de la nivelul universității

Fluxul informatic la nivel central RMU este următorul:


7 Echipamente hardware existente la nivelul fiecărui sistem

7.1.1 Infrastructură la nivel central

La nivel central există mai multe aplicații instalate, fiecare fiind responsabilă de anumite funcționalități ale RMU. Principalele module la nivel logic care alcătuiesc componenta centrală din RMU sunt:

- Oracle Business Intelligence Suite Enterprise Edition Plus; - Internet Application Server Enterprise Edition; - Oracle Portal; - Oracle Access Management; - Oracle Enterprise Manager Grid Control; - Oracle Database Enterprise Edition:

� Real Application Cluster; � Partitioning Pack; � Advance Security Pack; � Diagnostic Pack; � Management Pack.

Pentru a asigura redundanța și no single point of failure la nivel de servere, fiecare modul este instalat pe câte două mașini fizice identice:

Nume Rol Descriere

Db1 Nod 1 Baze de date:prod CPU: 2 x Intel Xeon x5670 2.93GHz

Memorie: 72 Gb DDR3 PC3-10600 (1333MHz)

OS: RHEL 5

Storage: -local :/oracle

-SAN : /DATA, /LOG,/CRS

Db2 Nod 2 Baze de date:prod CPU: 2 x Intel Xeon x5670 2.93GHz


OS: RHEL 5


-SAN : /DATA, /LOG,/CRS

Ias1 Server aplicatie central.rmu.ro, server OID LDAP, OAM (Oracle Access

Manager)

CPU: 2 x Intel Xeon x5670 2.93GHz


OS: RHEL 5


Ias2 Server aplicatie central.rmu.ro, server OID LDAP, OAM (Oracle Access




Nume Rol Descriere

Manager) OS: RHEL 5


www1 Server aplicatie portal.rmu.ro , OAM

(Oracle Access Manager)



OS: RHEL 5


www2 Server aplicatie portal.rmu.ro , OAM

(Oracle Access Manager)



OS: RHEL 5


mon1 Server Monitoring CPU: Intel Xeon x5670 2.93GHz


OS: RHEL 5


mon2 Server Monitoring CPU: Intel Xeon x5670 2.93GHz


OS: RHEL 5


mon3 Server Access Management

(ORACLE BI)

CPU: Intel Xeon x5670 2.93GHz


OS: WIN 2008 Server X64 R2


mon4 Server Access Management

(ORACLE BI)

CPU: Intel Xeon x5670 2.93GHz




mon5 Server Reporting CPU: Intel Xeon x5670 2.93GHz



Storage: -local


Nume Rol Descriere

mon6 Server Reporting CPU: Intel Xeon x5670 2.93GHz



Storage: -local

Următoarea diagramă prezintă în detaliu infrastructura centrală RMU:


7.1.2 Infrastructura de rețea pe care se face replicarea la nivelul DRC

În cadrul locației DRC este recomandat ca serverele să fie identice din perspectiva numărului și a capacității de stocare; restul de specificații tehnice ale echipamentelor trebuie să asigure buna funcționare a sistemului RMU în cazul în care locația de recuperare în caz de dezastru preia în întregime încărcarea site-ului principal.

Este recomandată utilizarea unei infrastructuri de rețea redundante din prisma firewall-ului, switch-ului și a load-balancer-ului și a ruterelor care trebuie să suporte otocolul BGPv4 pentru o comutare optimă între cele 2 locații.

8 Comutarea

Comutarea între locația primară și cea de recuperare în caz de dezastru trebuie să se poată realiza în 2 moduri: Manual și Automat.

Comutarea controlată se realizează în următoarele cazuri:

- mentenanță pe serverele principale; - probleme cu site-ul principal; - verificarea anuală a comutării controlate;

Pentru aceasta procedura sunt implicate serviciile:

- Comunicații; - Sisteme de operare; - Baze de date; - Aplicații.

Procedura de comutare controlată se va efectua în următoarele etape:

- Procedura pentru comutarea aplicațiilor; - Comutarea controlată din punctul de vedere al comunicației; - Comutarea controlată din punctul de vedere al sistemelor de operare; - Comutarea controlată din punctul de vedere al bazei de date.

Detalii referitoare la procedura de replicare și la cea de comutare se vor regăsi separat documentate.

Comutarea automată de pe site-ul principal pe locația de recuperare este recomandat să se realizeze prin configurarea protocolului BGP pe ruterele RMU. Sistemul autonom al RMU va fi anunțat atât din București cât și din DRC, cu o prioritate mai mare pentru locația principala. În cazul unui dezastru, sau în cazul în se pierde conexiunea cu ambii furnizori de servicii Internet din București, clienții vor fi rutați automat de către ISP-ul propriu către DRC. Aici se vor face mapările adreselor publice cunoscute și anunțate în DNS către adresele IP interne ale serverelor corespunzătoare din DRC. Toate ruterele sistemului RMU (București + 2 DRC) vor rula protocolul BGPv4 cu câte un furnizor de servicii Internet diferit. Trebuie luat în considerare ca cei doi furnizori din locația de recuperare să nu folosească același unic transportator către București.

Comutarea automată este doar totală și presupune indisponibilitatea accesului din exterior la Portalul central RMU din locația principală (ex. compromiterea legăturilor la Internet din partea furnizorilor din București, compromiterea ruterelor de acces din București).


În cazul comutării automate, revenirea la locația primară nu trebuie să fie automată, deoarece pe perioada de indisponibilitate a locației primare pot să apară inconsistențe la nivelul bazelor de date și este necesară o perioadă pentru replicarea în sens invers între locația de recuperare și locația primară.

Comutarea manuală presupune configurarea echipamentelor de către administratori sau de persoane desemnate de Structura RMU.

Comutarea manuală se va putea realiza la 2 nivele:

- Comutarea manuală totală realizată de administrator prin schimbarea metricilor și forțarea comutării pe locația de recuperare și invers pentru întoarcerea la locația primară;

- Comutarea manuală selectivă – se va realiza la nivelul unuia sau mai multor subsisteme prin intermediul aplicației oferite și prin configurarea la nivelul firewall-urilor care în mod default preferă echipamentele locale; cererile vor sosi tot în București și vor fi rutate prin VPN în locația de recuperare; răspunsurile vor fi rutate tot la nivel de firewall-uri prin VPN înapoi în București, astfel asigurând transparența la nivelul utilizatorilor.

În momentul implementării soluției de recuperare în caz de dezastru vor fi anexate procedurile detaliate cu instrucțiunile necesare la nivelul fiecărui echipament sau prezentarea scripturilor care eficientizează / facilitează comutarea manuală între cele 2 locații.

De asemenea va fi posibila modificarea configurației la nivelul switch-urilor de layer 3 din București pentru rutarea traficului primit pe site-ul primar prin conexiunile VPN către locația de recuperare și rezolvarea cererilor remote.

Un alt aspect important care trebuie luat în considerare este adresarea IP a sistemelor din DRC care va fi identică în ceea ce privește porțiunea de host, însă diferită în zona de rețea. Astfel se asigura comunicația de replicare peste conexiunile VPN. Se recomandă ca totalitatea subnet-urilor dintr-un site să poată fi agregate pentru a putea folosi facilitățile de sumarizare și rute statice. De asemenea, se recomandă ca translatarea de adrese (NAT public�privat) să fie făcută pe switch-urile de layer 3 sau pe firewall-uri/VPN-uri pentru a permite comutarea manuală a unui singur sistem.

8.1 Semnarea procesului verbal de constatare a comutării manuale

La finalul execuției operațiunilor de comutare manuală pe locația de recuperare pentru situații de dezastru se va semna procesul verbal de constatare a comutării. Procesul verbal va conține minim următoarele date:

- ora la care a fost lansat ordinul de comutare; - ora la care a fost disponibilă echipa de recuperare în locația de recuperare pentru

situații de dezastru; - ora la care s-a încheiat procesul de comutare a conexiunilor; - ora la care s-a încheiat procesul de comutare; - starea operațională a sistemului din locația de protecție pentru situații de dezastru; - propuneri de modificare a procedurilor de comutare pentru eliminarea eventualelor

neconformități descoperite la nivelul celor două locații; - observații.


9 Replicarea

Replicarea în timp real se va realiza la nivelul fiecărei componente a Portalului central RMU la nivel de sistem de fișiere (byte-level replication) și la nivel de baza de date unde acest lucru este considerat oportun.

Update-ul aplicațiilor se va face automat prin procesul de replicare. Trebuie definite regiunile care vor fi sincronizate automat împreună cu Dezvoltatorul, precum și o procedură în cazul unor update-uri ce conțin informații specifice unei locații (cum ar fi elemente de adresare IP codate în aplicație, adăugarea unor servicii externe aplicației care nu sunt disponibile încă în DRC, etc.). Unele sisteme vor necesita reconstrucția de la zero (ex. configurațiile echipamentelor de rețea – firewall, switch-uri, rutere).

Este recomandat ca replicarea să se realizeze folosind o soluție software de replicare integrată. Pentru toate serverele Windows aplicația va realiza replicarea asincronă la nivel de octet (byte-level replication) pentru zonele definite, protecție completă a serverului cu funcție de comutare pe serverul secundar ce poate prelua numele, adresa IP și configurația mașinii sursa. Toate serverele identificate în tabelul de replicare se vor afla sub aceeași umbrelă.

Aplicația de replicare va permite replicarea în ambele sensuri. Astfel recuperarea locației principale în caz de incident critic va fi realizată prin intermediul aceleași aplicații, dar va fi necesară o perioadă pentru sincronizarea datelor și pentru asigurarea integrității la nivelul locației primare.

De asemenea, pentru a evita compromiterea informațiilor (coruperea datelor din cauza virușilor, hacking, etc), soluția de replicare va permite realizarea de shadow copies / snapshot-uri în timp real sau alte mecanisme similare la nivelul bazelor de date.

Din punct de vedere al serverelor, arhitectura se bazează pe replicare automată de la serverul sursă (de producție) la server fizic destinație; la comanda administratorului sistemului se poate realiza și comutarea manuală (serverul destinație poate prelua numele, configurația IP, etc). Utilizatorii se vor conecta la fel ca înainte datorită transparenței oferite de nivelul de comunicații. Soluția ar trebui să ofere posibilitatea contopirii suitelor de câte două clustere din ambele site-uri în geo-clustere multi-nod pentru distribuția încărcării către DRC, datorită replicării transparente a storage-ului. Replicarea se va realiza prin conexiunile VPN peste rețeaua IP existentă, soluția oferind posibilitatea de setare a lățimii de bandă maxime pe care o utilizează (bandwidth throttling).

Este recomandat ca soluția de replicare automată a datelor să asigure:

- funcție de comutare (failover) a serverului de producție plecând de la nivelul sistemului de operare cu configurația acestuia, a aplicațiilor ce rulează pe acesta precum și a datelor către serverul destinație;

- funcția de comutare (failover) este de tip minim conexiune server sursa – server destinația (unu la unu) pentru servere de tip 32bit și 64bit;

- funcția de comutare (failover) asigură comutarea serverelor sursă pe servere destinație diferite din punct de vedere hardware (independența față de hardware) atât în mediu LAN cât și WAN;

- utilizează protocol standard TCP/IP fără limitare de distanță și tip de rețea: LAN, WAN, VPN sau NAT;

- oferă extensie către protecție de tip many-to-one; - oferă suport pentru compresia datelor pentru micșorarea costurilor liniilor de

comunicație;


- oferă suport pentru replicare de tip asincron pentru un impact minim asupra mediului de producției. Procesul de replicare va transfera doar modificările de la nivel de byte ale fișierului și nu tot blocul fizic sau logic sau fișierul întreg;

- permite reglarea lățimii de bandă WAN utilizată pentru replicare; - permite stabilirea intervalelor de timp pentru replicare pentru optimizarea utilizării

canalului de comunicație WAN; - restabilirea copiei în cazul întreruperii canalului de comunicație WAN se realizează la

nivel de bloc prin tehnologie de tip „block checksum”. Restabilirea copiei se realizează în mod automat la repunerea în operare a canalului de comunicații WAN dintre serverul sursă și serverul destinație;

- posibilitatea alegerii datelor ce vor fi replicate atât la nivel de director cât și la nivel de fișier;

- asigure replicarea atât a datelor criptate, compresate, fișiere cu nume foarte lungi, etc.;

- mecanism de verificare a faptului că datele destinație sunt identice cu cele sursă, la intervale de timp prestabilite sau la cerere;

- posibilitatea de execuție de scripturi pentru personalizarea și integrarea soluției; - transmiterea evenimentelor de stare prin e-mail administratorilor sistemului; - posibilitatea administrării folosind o interfață grafică, web sau în linie de comandă

pentru un grad ridicat de flexibilitate; - protecție la erori umane, coruperi datorate programelor software de tip „virus” (ca

funcție built-in sau prin integrare cu servicii existente în sistemul de operare); - posibilitatea integrării cu aplicații de tip system management (folosind de exemplu

SNMP sau syslog); - monitorizare centralizată a proceselor de replicare și a celor de comutare (failover); - statistici și rapoarte despre procesele de replicare, starea acestora, starea sistemelor,

etc.;

Pentru asigurarea conectivității în vederea replicării datelor este necesară interconectarea la nivel 3 a subnet-urilor corelate configurate pentru replicare între cele două locații. La nivel fizic recomandăm configurarea switch-urilor de Layer 3 și a firewall-urilor folosind politici de securitate stricte. Aceste politici implică configurarea unor liste de acces care să permită doar traficul de replicare între adresele punctuale ale serverelor configurate în redundanță.

Nu se consideră o necesitate existența unor echipamente și proceduri de backup a datelor în locația de recuperare datorită caracterului permanent al liniilor de replicare. De asemenea, transportul imaginilor de backup de la București către locația secundară nu este o necesitate deoarece, datorită diferenței de timp dintre momentul creării informației și până la recuperarea acesteia în DRC, datele recuperate ar fi oricum inutile, o copie mai recentă a acestora existând deja în locația secundară.


10 Planul de acțiune DRP

Planul de acțiune pentru recuperarea în caz de dezastru trebuie să conțină toate acțiunile ce sunt executate după declararea ”dezastrului”. Modelul prezentat aici este cu titlu de exemplu și trebuie completat de persoanele responsabile după instalarea și configurarea locației de recuperare.

Codul ActivităŃii*

Activitatea Responsabili Durata**

DRA-LOG-000

Activități logistice de pregătire a mutării în locația de recuperare

Coordonator DR

DRA-NET-001

Stabilește conectivitatea de rețea Responsabil hardware DR

DRA-NET-002

Rutează traficul de rețea în locația secundară


DRA-SYS-003

Restartează toate sistemele Responsabil hardware DR

DRA-APP-004

Pornește aplicația centrală Responsabil aplicații DR și Responsabil baze de date DR

* Codul activității este în formatul „DRA-xxx-yyy” unde:

- DRA= Disaster Recovery Activity

- xxx=LOG (Logistică), NET (Network – Rețea), SYS (Sistem), APP (Aplicație)

- yyy=numărul activităŃii

** Trebuie completat după primele teste de recuperare în caz de dezastru.

11 Testarea planului de recuperare în caz de dezastru

Scopul acestui capitol este de a identifica și documenta procedurile de testare ale planului DRP. Pentru fiecare test trebuie pregătit anterior un scenariu. Acesta include parametrii de testare, obiective, criterii de măsurare, grafice de activități și temporizare pentru a valida eficacitatea planurilor de backup și recuperare.

Când se efectuează un test de recuperare este foarte important să fie folosite numai informațiile și facilitățile din locația de recuperare. Acestea includ imagini de backup, documente, documentații, aplicații, sisteme, echipamente de rețea. Astfel se asigură următoarele:

- Simularea condițiilor cât mai aproape de o situație reală; - Datele și documentația aflate în locația secundară sunt complete și actualizate; - Competența și eficiența Echipei de intervenție participante; - Abilitatea de a restaura serviciile dorite; - Stabilirea unor cerințe de recuperare în caz de dezastru valide.

Un test major trebuie să fie programat o dată pe an. Teste intermediare ce valideaza schimbări minore pot fi efectuate de mai multe ori pe an.


11.1 Opțiuni și metodologie de testare ale planului DRP

11.1.1 Optiuni de testare DRP

Sunt prezentate patru tipuri de teste ce pot fi folosite ca metode intermediare de testare.

Parcurgere structurată:

Aceasta este o simulare pe hârtie a unei situații de dezastru, folosind metoda role-playing cu participarea cel puțin a Coordonatorului DR. Scenariul de testare trebuie pus la dispoziția Echipei de intervenție DR cu suficient timp înainte, pentru a permite acestora o pregătire adecvată. Un astfel de test poate dura până la 3 ore.

Test de recuperare în caz de dezastru neanunțat:

Este un test tehnic surpriză și implică pornirea limitată a operațiunilor IT în locația secundară. Operațiunile de producție nu sunt întrerupte. Doar o mică parte a componentei Echipei de intervenție DR este necesară. Dea asemenea, este necesară participarea unui eșantion, în prealabil selectat, de utilizatori.

Test de recuperare în caz de dezastru anunțat:

Este tot o simularea a mutării activității din locația primară în cea secundară. Activitățile de producție nu sunt întrerupte. Doar o mică parte a componentei Echipei de intervenție DR este necesară. De asemenea este necesară participarea unui eșantion, în prealabil selectat, de utilizatori. Acest test este ceva mai complex decât cel neanunțat deoarece dă posibilitatea unei planificări mai bune.

Exercițiu Tactic:

Este o simulare foarte apropiată de prima metoda (parcurgerea structurată). Diferența este că toți membrii Echipei de intervenție DR trebuie să fie prezenți. Datele referitoare la progresul activităților sunt prezentate în timp real, așa cum ar fi de așteptat în cazul unei situații reale.

11.1.2 Metodologia testelor de DR

Este propusă ordinea de testare în funcție de tipurile de teste prezentate anterior:

- Realizează o ”parcurgere structurată” imediat ce planul DRP a fost terminat; - Realizează un ”exercițiu tactic” pentru a verifica dacă toate cerințele au fost definite și că

toți membrii Echipei de intervenție DR înțeleg responsabilitățile pe care le au; - Realizează un ”test de recuperare în caz de dezastru anunțat” care necesită pornirea

tuturor sistemelor de operare și tuturor aplicațiilor critice. În acest test nu sunt implicați utilizatorii. Comunicațiile de date nu sunt testate;

- Realizează un ”test de recuperare în caz de dezastru anunțat” care necesită pornirea tuturor sistemelor de operare și tuturor aplicațiilor critice. Sunt implicați utilizatorii, cel puțin unul pentru fiecare modul. Se verifică liniile de comunicație;

- Realizează un ”test de recuperare în caz de dezastru neanunțat”. Trebuie implicat cel puțin un utilizator pentru fiecare modul. Sun testate și liniile de comunicație.

11.2 Planificarea testelor de recuperare în caz de dezastru

Orice test de DR necesită planificare. Vom prezenta problemele majore ce trebuie adresate la planificarea unui astfel de test.


Planul trebuie să definească atât obiectivele primare cât și cele secundare, precum și rezultatele așteptate. Un membru al Echipei de intervenție DR trebuie să completeze un jurnal pentru problemele ce vor apărea în timpul testului.

11.2.1 Dezvoltarea unui scenariu de testare

Acest scenariu urmărește realizarea următoarelor obiective:

- Retestarea acelor părți din planul DRP ce au avut probleme în trecut; - Testarea aplicațiilor / modulelor / funcționalităților ce nu au mai fost testate. - Implicarea acelor membri ai Echipei de intervenție DR care au nevoie de familiarizare cu

acest plan.

11.2.2 Criteriile testării

A. Parametrii de testare:

- Participanții implicați (utilizatorii și membrii Echipei de intervenție DR); - Planul de notificare; - Sistemele și modulele aplicație centrale ce vor fi testate; - Configurația rețelei;

B. Obiectivele testului:

- Obiectivele primare și rezultatele așteptate; - Obiectivele secundare și rezultatele așteptate; - Durata testului;

C. Lista de acțiuni:

- Documentarea acțiunilor ce vor fi executate; - Temporizarea fiecărei acțiuni (când începe și când se termină); - Atribuirea acțiunilor pe participanți;

D. Măsuratorile testului:

- Înregistrarea timpul de la demarare până la finalizare pentru fiecare acțiune; - Validarea datelor restaurate; - Documentarea fiecărei probleme apărute; - Documentarea fiecărei devieri de la plan;

E. Verificarea după test:

- Au fost parametrii corecți? - Au fost obiectivele atinse? - Au fost criteriile de măsurare corect enunțate? - Identificarea zonelor cu probleme, plusurile și devierile de la plan; - Recomandări pentru îmbunătățirea planului.

11.2.3 Verificarea și evaluarea rezultatelor testului

În orice test de recuperare, progresul acestuia trebuie observat de către Coordonatorul DR și de membrii Comitetului de conducere DR. Pentru a fi observatori obiectivi ei trebuie:

- Să fie familiari cu planul DRP și cu planul de testare; - Să înțeleagă obiectivele testului; - Să monitorizeze toate acțiunile echipelor implicate;


- Să compare rezultatele testului cu obiectivele acestuia.

Observatorii trebuie să documenteze rezultatele testului în formularul imediat după terminarea acestuia.

Coordonatorul DR trebuie să conducă întâlnirea pentru verificarea rezultatelor și să autorizeze modificările ce trebuie aduse planului.

11.3 Documentarea testului de DR

11.3.1 Formular de evaluare a testului

1. Au fost parametrii corecți?

2. Au fost obiectivele atinse?

3. Au fost criteriile de măsurare corect enunțate?

4. Identifică următoarele:

Zonele cu probleme:

Plusurile:

Devierile de la planul DRP:

Recomandări pentru îmbunătățirea planului:

Semnături: Observator Coordonator DR: Data:

___________________ ______________________ ___/___/____


11.3.2 Jurnalul problemelor

Data incidentului/testului: / /

Motivul incidentului/testului:

Prob. Nr.

Descrierea Problemei Data Problemei

Planul de acțiune: Task

Code

Data: HW reparat

Data: Cod actualizat

Data: Documentație

actualizată

Posesorul problemei

Probleme de logistica

Probleme de sistem


Probleme de aplicație

Probleme de baze de date

Probleme de rețea


12 Mentenanța planului DRP

12.1 Privire de ansamblu

Scopul acestei secțiuni este de a defini activitățile necesare pentru a menține planul într-o stare funcțională și validă. Toate schimbările activității curente trebuie luate în considerare deoarece acestea pot influența planul DRP.

Am definit 2 tipuri de schimbări:

- Mentenanță programată; - Mentenanță neprogramată.

12.1.1 Mentenanța programată

Mentenanța programată a planului este generată de întâlnirile regulate ale Echipei de intervenție DR. Verificarea acestuia ajută la detectarea schimbărilor ce au fost trecute cu vederea.

Coordonatorul DR este responsabil cu înglobarea schimbărilor în planul DRP.

Următorul formular va fi completat cu schimbările efectuate:

Recenzent Comentarii Schimbări necesare

Data actualizării

12.1.2 Mentenanța neprogramată

Unele schimbări nu sunt previzibile. Managerii sunt responsabili pentru a-l notifica pe Coordonatorul DR de toate schimbările și evenimentele ce pot genera schimbări în planul DRP. În continuare sunt prezentate câteva exemple de schimbări:

- Schimbări în hardware: procesor, discuri, memorie; - Schimbări în software: software de sistem, storage sau utilitare. - Schimbări în designul aplicației centrale sau a serverelor de aplicație; - Schimbări în designul unei baze de date; - Schimbări în designul rețelei sau a componentelor acesteia; - Schimbări în procedura de backup/recovery; - Achiziția de sisteme noi; - Eliminarea unui modul / funcționalități; - Îmbunătățiri la infrastructura centrului de date; - Schimbări în infrastructura centrului de date; - Transferuri, promovări, încheieri de contract ale personalului. - Schimbări în organizarea Departamentului IT.


12.2 Managementul problemelor și al schimbărilor

Având în vedere schimbările enunțate mai sus, se va crea un jurnal al acestora după următorul model:

Data Tipul

schimbării Domeniul

afectat Comentarii

13 Procedura de revenire la locația primară

După o perioadă de timp în care activitățile sunt efectuate în locația secundară, se presupune că problemele ce au generat starea de dezastru au fost rezolvate. Este necesară mutarea activităților în centrul de date primar. Lista de activități necesare este similară cu cea a activităților de activare a locației de recuperare în caz de dezastru.



DRA-LOG-000

Activități logistice de pregătire a mutării în locația primară

Coordonator DR

DRA-NET-001

Stabilește conectivitatea de rețea Responsabil hardware DR

DRA-NET-002

Rutează traficul de rețea în locația secundară





DRA-SYS-003

Restartează toate sistemele Responsabil hardware DR

DRA-APP-004

Pornește aplicația centrală Responsabil aplicații DR și Responsabil baze de date DR

* Codul activității este în formatul „DRA-xxx-yyy” unde:

- DRA= Disaster Recovery Activity

- xxx=LOG (Logistică), NET (Network – Rețea), SYS (Sistem), APP (Aplicație)

- yyy=numărul activităŃii

** Trebuie completat după primele teste de recuperare în caz de dezastru.

14 Neconformare

Încălcarea prevederilor din cadrul acestei politici vor fi sancționate prin măsuri disciplinare în conformitate cu reglementările interne ale Structurii RMU.

Toate acțiunile care contravin legilor vor fi raportate organelor competente.

15 Revizuirea Planului de Recuperare în caz de Dezastru

Planul de Recuperare în caz de Dezastru trebuie să fie supus unei analize anuale urmând ca rezultatul acesteia să fie prezentat spre analiză și avizare către Managerului Structurii RMU. Documentul va fi revizuit și actualizat ori de câte ori situația de fapt a organizației, condițiile conjuncturale externe sau reglementările legislative o impun.

Revizuirea trebuie să includă evaluarea necesităților de control al accesului la informații în cadrul sistemului RMU, dar și demersurile de coordonare a securității informației în concordanță cu schimbările de mediu, circumstanțele de business, condițiile legale, standardele în vigoare sau mediul tehnologic.


16 Anexe

Vor fi introduse după finalizarea implementării soluției de recuperare în caz de dezastru

Anexa A. Echipamente IT în locația primară și în cea de recuperare

în caz de dezastru

Anexa B. Inventarul facilitățile locației de recuperare în caz de

dezastru

Anexa C. Inventarul aplicațiilor / modulelor și a metodelor de

backup și replicare

Anexa E. Componența Echipei de intervenție DR

Anexa F. Diagramele de conectivitate

Plan de Recuperare în caz de Dezastru

Documents

Transcript of Plan de Recuperare în caz de Dezastru