Azure Bezbednost zasnovana na cloudu

Izgradnja i korišćenje sopstvenog Disaster recovery centra je skupa opcija koju u najvećem broju slučajeva može zameniti rešenje zasnovano na cloud‑u. Microsoft Azure je jedan od najvećih cloud provajdera s data centrima po celom svetu, dobrim SLA uslovima i konkurentnom cenom.

Zamislite da se upravo pokvario file server u vašoj firmi, na kome su svi dokumenti i podaci. Zamislite da je provalnik ušao i odneo oba servera na kojima je poslovni softver s kompletnim podacima Zamislite da je buknuo požar ili su prostorije poplavljene. Zamislite da je administrator greškom obrisao jedan od foldera s kompletnom dokumentacijom u prethodne tri godine. U takvim situacijama, dve stvari su suštinski bitne: koliko je star backup i kakav scenario za oporavak (disaster recovery) imate. Iako deluje jednostavno, da bi oporavak u svim nepredviđenim situacijama bio uspešan potrebna je ozbiljna priprema i planiranje.

Problemi su neminovni

Problemi mogu nastati kvarom na hardveru ili softveru. Isto tako, mogu se pojaviti na računarskoj mreži, električnim instalacijama, može doći do pljačke, požara, poplave, zemljotresa, fizičkih oštećenja na zgradi, ljudske greške i još mnogo toga. Jedan deo ovih problema može se preduprediti ili umanjiti mogućnost da do njih dođe, ali na prirodne nepogode ne možemo da utičemo. Realno je pretpostaviti da će se neki od problema, ili više njih, pre ili kasnije javiti i zbog toga moramo biti spremni. Potrebni su analiza, priprema, plan, provera plana kroz testove, dokumentacija, obuka ljudi i jasni procesi u slučaju problema. Sve ovo treba konstantno proveravati, menjati i unapređivati, što iziskuje mnogo vremena i resursa. Ali, samo zamislite bilo koji od scenarija u kojima su podaci nestali ili su oštećeni, pa izračujante koliko bi tek prekid u radu koštao.

Upravo ta analiza raznih scenarija početni je korak u kome treba da se definišu dva osnovna parametra: Recovery Point Objective (RPO) i Recovery Time Objective (RTO). Jednostavnije, RPO je tačka poslednjeg backup‑a na koju se možemo vratiti. RTO je očekivano vreme oporavka. Iako ovo izgleda kao posao za informatičare, određivanje RPO‑a i RTO‑a je prvenstveno zadatak za biznis sektor, uz konsultacije sa informatičarima. Osnovni razlog je u tome što je vreme unazad do backup‑a i vreme unapred do oporavka direktno vezan za troškove. S jedne strane, trošak gubitka dela podataka od tačke kada se desio problem do tačke poslednjeg backup‑a. S druge strane, tu je trošak jer deo ili ceo IT sistem ne radi, kao i trošak samog sistema za oporavak.

Što kraće vreme za oporavak želimo manji će biti troškovi zastoja u poslu, ali će sistem koji nam to omogućava biti skuplji. Produžavanjem željenog vremena oporavka smanjujemo cenu sistema za oporavak, ali će troškovi prekida u radu biti veći. Na osnovu analize troškova u slučaju problema kao cene sistema za backup i oporavak, kao i drugih relevantnih poslovnih kriterijuma, biznis treba da donese odluku koliki će se RPO i RTO koristiti.

Terminologija

Informatičari tada imaju parametre na osnovu kojih će tražiti odgovarajuća tehnička rešenja. Najpre primenjuju Fault Tolerance u dizajniranju svojih IT sistema. Cilj je da se obezbedi redundansa i replikacija delova sistema tako da u slučaju otkaza jednog dela sistem nastavlja da radi, eventualno uz manji kapacitet i slabije performanse sistema dok se pokvareni deo ne zameni novim i stavi u upotrebu. Recimo, imamo servere s duplim (redundantnim) napajanjem, gde u slučaju otkaza jednog, server nastavlja da radi zahvaljujući drugom. Moguće je postaviti dva servera gde će se podaci na njima replicirati te ukoliko dođe do otkaza jednog od njih, drugi nastavlja da radi i opslužuje zahteve.

Slično važi i za druge delove okruženja, kao što su sistem za napajanje, računarska mreža i drugi. Sistem se može tako dizajnirati da u slučaju otkaza delova sistema, drugi nastavljaju da rade bez ikakvog prekida. Ipak, češće srećemo dizajn u kome postoji kraći prekid, a za to vreme rezervni sistem preuzima ulogu glavnog.

Fault Tolerance sistemi mere se po njihovoj dostupnosti u slučajevima planiranih i neplaniranih prekida ka krajnjim korisnicima. Sistemi u kojima je dostupnost na visokom nivou, tj. planski i neplanski prekidi su projektovano mali, zovu se High‑Availability (HA) sistemi. Logično je da u organizacijama koje su poslovno veoma zavisne od informacionog sistema High‑Availability bude obavezan.

Deo sistema koji će omogućiti High‑Availablity svakako je Disaster recovery. To je set procesa, pravila i procedura za vraćanje kritičnih delova informacionog sistema u rad nakon događaja koji je doveo do kraha dela ili celog sistema.

Sopstveni ili iznajmljeni resursi

Informatičari mogu, recimo, da postave informacioni sistem u poslovnoj zgradi koristeći različita rešenja za High‑Availability. Ali, šta se dešava u slučaju oštećenja na zgradi, zemljotresa, poplava ili požara? Šta se dešava kod provala i oštećenja i onih delova sistema koji su obezbeđivali redundansu, kao i backup‑a podataka koji se nalaze u poslovnoj zgradi?

Jedna opcija jeste da firma sama obezbedi udaljenu lokaciju na koju će smeštati backup, ali koja će biti korišćena i kao Disaster recovery lokacija u slučaju problema i s glavnim i s redudantnim sistemom u poslovnoj zgradi. Troškovi te dodatne lokacije mogu da budu veoma visoki: sa sopstvenim data centrom za Disaster recovery treba platiti prostor, link od centralnog data centra do Disaster recovery data centra, održavati sistem, platiti hardver i softver… Alternativa je korišćenje servis provajdera koji će obezbediti backup i redundansu u svom data centru. Naravno, postoji i mogućnost da se pojedini delovi ili kompletan kritični deo informacionog sistema iz poslovne zgrade prebaci kod provajdera.

Ne postoji jedinstveno rešenje koje je najbolje za sve korisnike – svaki slučaj treba analizirati i dizajnirati sistem na osnovu postavljenih kriterijuma i raspoloživih tehničkih rešenja. Ekspanzija data centara lokalnih i globalnih provajdera, kao i ponude cloud usluga, olakšavaju izbor i realizaciju. Sada je relativno jednostavno da u velikom broju slučajeva umesto sopstvenog dislociranog data centra za Disaster recovery koristimo data centre provajdera.

Pri izboru provajdera, treba detaljno analizirati Service Level Agreement (SLA), a posebno deo koji govori o dostupnosti sistema provajdera. Iako procenti koji govore o dostupnosti izgledaju slično, naizgled mala procentna razlika donosi relativno velik produžetak vremena prekida. Recimo, 99% dostupnost na mesečnom nivou znači maksimalni prekid od 7,20 sati, a na godišnjem 3,65 dana! S druge strane, 99,9% znači maksimalno 43,8 minuta na mesečnom nivou, tj. 8,76 sati godišnje nedostupnosti, a 99,999% je maksimalno samo 25,9 sekundi mesečno i 5,26 minuta godišnje nedostupnosti. Iako veći procenat dostupnosti deluje primamljivo, on poskupljuje usluge. Cena, dostupnost i željeni RPO i RTO parametri su za odluku o provajderu, kao i o nivou usluge kod provajdera.

Uzmimo za primer Microsoft Azure. Ako zakupimo jednu virtuelnu mašinu, SQL bazu i storage, njihova dostupnost pojedinačno je 99,95% za virtuelnu mašinu, 99,99% za SQL bazu i 99,9% za storage. Uz to, Microsoft Azure ima data centre po celom svetu, tako da u slučaju ogromnih problema u jednom od njih (što je vrlo retko, ali se ne može potpuno isključiti), na raspolaganju su drugi data centri.

Disaster recovery opcije

Disaster recovery okruženja se tradicionalno dele na Cold, Warm i Hot rešenja. Cold rešenje je najjeftinije i njajjednostavnije: u Disaster recovery data centru odvoji se prostor i osnovna infrastruktura za slučaj disaster scenarija. Kada problem nastupi, administratori kreiraju hardversko i softversko okruženje koje uz korišćenje backup‑a može da preuzme funkcije sistema koje su u prekidu. Hot rešenje je praktično replika glavnog okruženja koje je u pripravnosti da preuzme funkcije glavnog okruženja u slučaju potrebe, što je najskuplja opcija. Warm rešenje nalazi se negde između Cold i Hot rešenja, gde je u Disaster recovery data centru već pripremljen hardver i deo infrastrukture dovoljan da se, uz minimalnu konfiguraciju i korišćenje backup‑a, osposobi okruženje za rad.

Kada se cloud koristi za Disaster recovery, Cold, Warm i Hot rešenja nešto su drugačija. Kod Cold rešenja, farma je podignuta ali virtuelne mašine nisu stalno u pogonu. Obično se podižu s vremena na vreme radi update‑a i provere funkcionalnosti. Kod Warm rešenja, virtuelne mašine su update‑ovane i stalno rade. Obično se replicira baza i file storage. U slučaju Disaster recovery scenarija, povezuju se baza i file storage, podiže se i konfiguriše okruženje. Hot rešenje podrazumeva kompletno okruženje spremno da preuzme sve funkcije u svakom trenutku.

Microsoft Azure

Cold, Warm i Hot je osnovna podela rešenja. Svako rešenje je specifično i zavisi od postavljenih ciljeva, troškova i konkretnih tehničkih rešenja. Ako bismo počeli od najjednostavnijih usluga Microsoft Azure, kao cloud provajdera, možemo koristiti za backup. Osim lokalnog backup‑a, dodatni backup se šalje na Azure. S obzirom da Azure data centri postoje na više lokacija u svetu, na raspolaganju su opcije snimanja više kopija u okviru istog data centra ili snimanje dodatnih kopija u drugom, geografski udaljenom data centru. Napredak cloud servisa omogućio je pristupačne cene za cloud storage. Na Azure‑u, na primer, za prvi terabajt (za Block blobs), cena je od 0,024 dolara po gigabajtu mesečno.

Ako želimo Warm rešenja, možemo da podignemo virtuelne mašine, fajl server i SQL bazu. Konifgurisaćemo replikaciju, na primer koristeći Distributed File System Replication (DFSR) i na taj način imati spremno Warm Disaster recovery okruženje. S obzirom na različite dizajne primarnog data centra, brojne su opcije za podizanje Warm okruženja u Azure‑u. Nekada će nam, recimo, biti potreban i server sa aktivnim direktorijumom uz DNS ili neke druge opcije. Spremno okruženje može biti u minimalnoj konfiguraciji uz minimalne troškove. U slučaju preuzimanja primarnih funkcija, okruženje se može skalirati – prednosti cloud -a kao što je Azure upravo su fleksibilnost i mogućnosti skaliranja po potrebama.

Hot rešenje podrazumeva kompletnu replikaciju primarnog okruženja. S obzirom na kompletan spektar cloud usluga koje nudi Microsoft Azure, ne bi trebalo da postoje prepreke da se replicira primarno okruženje i kad nije bazirano na Microsoft rešenjima, npr. Linux ili Oracle.

A troškovi?

Važno je primetiti da Disaster recovery opcije ne donose velike troškove dok primarni centar normalno funkcioniše, pošto se cloud servisi plaćaju po korišćenju. Dok primarni sistem uspešno radi, on opslužuje korisnike dok su servisi na Azure‑u minimalno angažovani. Tek kada Azure preuzme funkcije primarnog data centra i krene da opslužuje korisnike, očekivani troškovi će porasti, ali samo dok ne osposobimo primarni data centar. Da bismo izračunali koliko će koštati planirano Disaster recovery okruženje u Azure‑u, na raspolaganju je kalkukator na adresi azure.microsoft.com/en‑us/pricing/calculator/. Osim troškova cloud servisa, treba obezbediti i odgovarajući Internet link i uračunati i njegove troškove.

Izgradnja i korišćenje sopstvenog Disaster recovery centra je skupa opcija koju u najvećem broju slučajeva može zameniti cloud rešenje. Microsoft Azure je jedan od najvećih cloud provajdera s data centrima po celom svetu, dobrim SLA uslovima i konkurentnom cenom. Korišćenje Azure okruženja je brže, jeftinije i jednostavnije od kreiranja sopstvenog data centra uz punu cloud fleksibilnost promena primarnog sistema i, eventualno, novim ciljevima za Disaster recovery. Testiranje Azure‑a i upoznavanje sa okruženjem veoma je jednostavno i donosi minimalne troškove.

Maksimalna nedostupnost kod provajdera na osnovu procenta iz SLA

Pavle Peković

(Objavljeno u časopisu PC#214)