În acest articol vom discuta despre ceea ce se întâmplă cu datele transmise între regiunile Azure şi sistemele locale.
Microsoft deschide din ce ȋn ce mai multe centre ȋn ȋntreaga lume. Regiuni precum Japonia, UK (urmează să fie anunţată), Brazilia, Germania, Corea sunt deja instalate sau urmează să fie instalate.
Aceste ţări au legi care precizează că datele dintr-o anume industrie nu au voie să părăsească ţara. Ȋn industria serviciilor de sănătate, este normal să existe restricţii pentru ca informaţiile personale ale pacienţilor să nu părăsească ţara ȋn niciun moment. Există legi similare și pentru alte industrii precum domeniul bancar și protecţia datelor.
Trebuie să ţinem cont de aceste legi, de soluţiile existente și de ceea ce se ȋntâmplă cu conţinutul transmis ȋntre regiunile Azure și sistemele locale.
Scopul acestui articol este să arate ce se ȋntâmplă cu conţinutul care este transmis ȋntre regiuni Azure și sisteme locale, și să evidenţieze lucrurile la care trebuie să fim atenţi. Un alt articol se va ocupa de diferitele configurări ale serviciilor Azure și a modului ȋn care ne pot afecta.
Premisă: Nu luăm ȋn calcul diferitele configurări ale serviciilor Azure care ar putea să mute datele ȋntr-o altă regiune. Presupunem că clientul nu a configurat serviciul Azure pentru a face backup sau a replica conţinutul ȋn alte regiuni Azure.
Toate datele stocate ȋntr-o regiune Azure, vor rămâne ȋn acea regiune. Conţinutul stocat ȋntr-o regiune specifică nu va părăsi acea regiune. Deci, putem stoca date ȋn regiunea Azure UK fără probleme. Conţinutul nu va părăsi regiunea Azure UK ca prin magie pentru a fi stocat ȋntr-o altă regiune precum Germania.
Dacă regiunile Azure din acea regiune au probleme tehnice, chiar și ȋn caz de cădere de sistem, conţinutul nostru nu va părăsi acea ţară sau acea regiune-pereche Azure (bazată pe configurarea serviciilor Azure).
Ȋn acest link veţi găsi un tabel util care specifică regiunile-pereche pentru fiecare regiune Azure. După cum putem observa, Japan East are drept pereche Japan West, aceeași ţară cu două locuri diferite. Există câteva excepţii pe care le vom discuta ȋn articolul următor.
Acesta este un caz generic, valabil pentru orice furnizor cloud, nefiind specific doar mediului Azure.
Tot conţinutul trimis dintr-o regiune Azure la un sistem local va trece prin furnizorii locali ISP (Internet Service Providers/furnizori de servicii Internet) ai ţărilor respective. Conţinutul nu va părăsi acea ţară specifică atâta timp cât sistemul local este ȋn aceeași ţară ca regiunea Azure.
Lucrurile devin mai complicate când datele merg de la un furnizor ISP la altul și așa mai departe. Putem avea furnizori ISP care ar putea detecta că ȋncărcătura de pe o anumită rută părăsește, apoi revine pe rută, iar aceasta să fie o opţiune mai bună decât ceea ce există ȋn ţară. Ȋn acest caz, se poate decide să se folosească o altă rută. Ȋn timpul transportului, conţinutul va părăsi ţara. Acest lucru se poate ȋntâmpla ȋn interiorul aceluiași ISP, ȋn funcţie de cât de ȋncărcate sunt rutele și de cum se face echilibrarea.
Un lucru similar se ȋntâmplă când, de exemplu, un furnizor local ISP sau o rută principală cedează, iar conţinutul este redirecţionat pe alte rute. Chiar dacă avem o rută cu destinaţie specifică acestui lucru, de exemplu, ȋntre Spania continentală și insulele Grand Canary (care fac parte din Spania), dacă această rută este compromisă, datele se pot reorienta spre alte rute precum Egipt sau UK (ţări date aici doar ȋn calitate de exemplu). Deci, chiar dacă avem o conexiune destinată acestui scop, conţinutul poate urma o altă rută și să părăsească ţara.
Ȋn cazul unui astfel de scenariu, nu aveţi niciun fel de control. Dacă aveţi resurse suficiente, vă puteţi construi propriile linii, dar acest lucru este scump. La nivel de transport, nu avem control asupra modului ȋn care ISP trimite conţinutul și asupra modului ȋn care se face transmisia pe o anumită rută.
După cum putem vedea, este ușor să controlăm, la nivel de serviciu Azure, ca datele să nu părăsească o regiune Azure. Lucrurile se complică la nivel de transport efectiv. Nu există garanţii ȋn absenţa unei linii destinate acestui lucru sau a unor contracte customizate, cu furnizori ISP (acolo unde este posibil).
Ceea ce trebuie investigat, ȋn continuare, este care sunt trăsăturile de replicare care nu corespund cerinţelor noastre. Dorim ca datele şi plăţile (Data and Payload) să nu părăsească ţara ȋn care se află regiunea Azure. Vom prezenta cele mai uzuale și mai importante servicii Azure.
Ȋnsă, ȋnainte de a face acest lucru, ar trebui să vorbim puţin despre Azure Paired Regions (regiunile-pereche Azure). Dacă o regiune Azure e o zonă dintr-o regiune geografică specifică care conţine unul sau mai multe centre de date, o regiune-pereche Azure e o altă regiune din aceeași regiune geografică utilizată pentru Business Continuity and Disaster Recovery (BCDR, adică continuitatea afacerii și recuperarea ȋn caz de dezastru). O regiune-pereche este utilizată ȋn scop de replicare și de backup.
Din perspectiva mea, cel mai important aspect legat de regiunile-pereche Azure este că se află ȋn aceeași regiune geografică. Pentru ţări mari precum SUA, China, Australia, India, regiunea geografică se va afla ȋn aceeași ţară. Pentru ţări mici, regiunea geografică va presupune că regiunea-pereche se găsește ȋntr-o altă ţară.
De exemplu, ȋn Europa, avem o regiune Azure ȋn Irlanda și una ȋn Olanda. Cu alte cuvinte, dacă ne configurăm serviciul Azure pentru a replica conţinutul ȋn regiunea-pereche (Irlanda ȋn cazul de faţă), datele vor părăsi Olanda și nu se vor supune legilor locale, pentru o anume industrie (serviciile de sănătate).
Evident, există un schimb permanent ȋntre costuri și riscuri, pe care dorim să ȋl luăm ȋn calcul. De multe ori, e acceptabil ca o regiune Azure să aibă defecţiuni din cauza unor căderi de sistem, deoarece aceasta ȋnseamnă că s-a produs un dezastru şi că puteţi replica datele sau face backup la un alt furnizor local.
Există câteva industrii unde acest lucru nu este acceptabil. De exemplu, dacă se ȋntâmplă un dezastru ȋn sănătate, trebuie să te asiguri că sistemul va continua să funcţioneze, deoarece spitalele vor trebui să ȋl utilizeze şi aceasta va face diferenţa dintre viaţă și moarte.
Dacă doriţi să aflaţi care este regiunea pereche pentru regiuni Azure diferite, consultaţi pagina Microsoft (Microsoft page), care este updatată de ȋndată ce intervine o schimbare ȋn ceea ce privește regiunile-pereche Azure.
Azure Storage (Stocarea Azure)
Când vorbim de Azure Storage, trebuie luat în calcul că acest serviciu este des folosit de alte servicii, fiind un serviciu-nucleu (core). În acest context, trebuie ştiut că pentru alte servicii Azure, precum Azure VMs care au nevoie de Azure Storage pentru disc şi stocare, trebuie să utilizaţi , de asemenea, configuraţia corectă pentru serviciile-nucleu (core).
Azure Store oferă suport pentru patru tipuri de storage replication:
Locally redundant storage (LRS) (stocare redundantă local),
Zone-redundant storage (ZRS) (stocare redundantă zonal),
Geo-redundant storage (GRS) (stocare redundantă geografic),
LRS este singura care poate replica stocarea doar pentru regiunea unde creaţi şi păstraţi conţinutul.
Fiţi atenţi când folosiţi ZRS şi aveţi constrângeri la nivel de ţară. ZRS replică conţinutul în zone multiple, care pot să fie în aceeaşi regiune Azure sau în altă regiune Azure. În acest context trebuie să ştiţi dacă celelalte zone unde conţinutul dumneavoastră este replicat sunt în aceeaşi regiune Azure Region sau în alte regiuni-pereche (Paired Region).
Există mai mult feature-uri care oferă ajutor, astfel încât clienţii Azure SQL Database să nu îşi piardă datele şi să aibă un Recovery Time Objective (RTO) minim.
Primul feature este Point in Time Restore. Acesta este un backup automat al Azure SQL Database şi se poate folosi pentru a restaura baza dumneavoastră de date. Backup-urile realizate sunt stocate între 7 şi 35 de zile (în funcţie de nivel). Backup-ul se face în aceeaşi regiune Azure ca Azure SQL Database.
Al doilea feature este Geo-Restore care este similar cu Point in Time Restore. Acesta se bazează pe Geo-redundant storage (GRS) al Azure Storage. Backup-ul bazei dumneavoastră de date este replicat într-o altă regiune Azure care se poate afla într-o altă ţară.
Active Geo-Replication este unul dintre cele mai puternice feature-uri de replicare de pe piaţă. Puteţi avea până la 4 replicări în regiuni Azure diferite care vor fi sincronizate cu baza de date principală. Dacă există restricţii la nivel de ţară, trebuie să ştim ce regiuni folosim când ne configurăm replicările.
Dacă utilizaţi acest serviciu Azure, e bine de ştiut că backup-ul se realizează automat de Microsoft de un serviciu built-in. Acest serviciu de back-up utilizează backup de tip geo-redundancy în regiuni-pereche Azure. Dacă aveţi constrângeri la nivel de ţară, iar dumneavoastră sunteţi din Europa sau Brazilia, ar trebui să verificaţi de două ori ce date stocaţi acolo.
În combinaţie cu Azure Data Factory putem să customizăm backup-ul şi să îl stocăm în Azure Storage, care se poate afla în aceeaşi regiune Azure Region ca instanţa DocumentDB.
Aduc acest serviciu în atenţia dumneavoastră, pentru că mulţi folosesc sistemul Hadoop nu doar pentru procesarea de date, ci şi pentru sotcarea de date.
Partea bună a HDInsight la nivel de backup este că se bazează pe Hadoop standard (HBase,...), fapt ce presupune că avem control complet asupra backup-ului.
Azure Storage-ul utilizat de acest fel de clustere este specificat în timpul procesului de creare de clustere. Aceste zone de stocare sunt de tip Locally redundant storage (LRS).
Geo-Replication (Geo-Replicarea) este susţinută de aceste clustere care ne permit să avem replicări în alte regiuni Azure. Dacă avem restricţii de ţară, trebuie să ţinem cont de Geo-Replication dacă regiunea-pereche Azure nu e în aceeaşi ţară (similar cu geo-replicarea Azure SQL Databases).
Acest nou serviciu care conectează dispozitivele de pe teren cu backend-ul devine din ce în ce mai puternică, iar fiecare release aduce noi feature-uri.
Din perspectiva nevoii de recuperare a datelor după o calamitate, Azure IoT Hub nu asigură o rezolvare completă şi va trebuii să intervenim direct dacă dorim să transpunem un failure de la o instanţă la alta.
Din această perspectivă, partea bună este că nu vom avea probleme dacă există restricţii de ţară. Tot conţinutul rămâne în aceeaşi regiune Azure, ca instanţă principală. Nu există replicări sau backup-uri de date într-o altă regiune.
În acest moment, Azure Service Fabric rulează doar pe o regiune Azure. Similar lui Azure IoT Hub, nu există replicări sau backup-uri care se face automat în alte regiuni Azure.
Atât backup-ul complet, cât şi cel incremental (full and incremental) din interiorul Azure Service Fabric sunt realizate utilizând resurse de stocare din aceeaşi regiune Azure precum clusterul nostru. Când facem backup, putem specifica Azure Storage-ul unde backup-urile sunt menţinute. Din acest motiv, în contextul restricţiilor la nivel de ţară, este responsabilitatea dumneavoastră să folosiţi Azure Storage care au doar ZRS activat.
private async Task BackupCallbackAsync(BackupInfo backupInfo, CancellationToken cancellationToken)
{
Guid backupId = GetBackupId();
await externalBackupStore
.UploadBackupFolderAsync(
backupInfo.Directory,
backupId,
cancellationToken);
return true;
} Acest serviciu nou este încă în faza de teste şi ne permite să stocăm şi să procesăm petabytes de date. Această bază de date creează backup la date în Azure Storage şi le conservă în cazul unei erori.
Aceste date sunt stocate în Local Redundant Storage (LRS), ceea ce înseamnă că datele nu părăsesc regiunea Azure curentă.
Într-una din versiunile de SQL Data Warehouse aflate în preview, a existat suport pentru Geo-Restore, prin utilizarea RA-GRS al Azure Storage. Se pare că acest feature nu mai este valid.
Pentru serviciile aflate în preview, trebuie să fim la curent cu modificările care se întâmplă continuu. Aceste modificări nu ar trebui să ne influenţeze munca major şi frecvent.
Lucurile sunt simple pentru acest serviciu. În spatele scenei, specificăm Azure Storage-ul pe care îl folosim pentru "Play on Demand" ("Rulează la cerere"). Putem utiliza orice Azure Storage - chiar şi LRS-ul care nu este replicat în alte regiuni Azure.
Toate evenimentele trimise către o instanţă Azure Event Hub sunt stocate doar în regiunea unde instanţa noastră a fost creată. Pentru acest serviciu nu există restricţii de ţară.
În momentul de faţă, nu există un feature (asociat acestui serviciu) care să ne permită să facem back-up/să replicăm conţinutul (secret) într-o altă regiune Azure. Din acest punct de vedere, scenariile în care utilizatorii ar avea nevoie de o replicare sau de backup nu sunt uzuale.
Nu se face replicare manuală şi nici backup într-o altă regiune Azure.
Replicarea se realizează automat în aceeaşi regiune geografică. În acest context, trebuie să analizăm dacă aceasta se află în aceeaşi ţară sau nu.
Ca în cazul Azure Event Hub, Service Bus are o poveste simplă. Mesajele persistă doar în regiunea Azure iniţială şi nu se realizează backup în regiuni diferite - câmpul nume nu oferă suport pentru regiuni Azure multiple.
Geo-Replication se poate realiza doar manual, având două câmpuri de nume (puncte finale) în două regiuni diferite.
Acest serviciu ne permite să creăm instanţe de backup utilizând Redis Persistence Model (RPM). Astfel, se poate crea un backup în Azure Storage care poate apoi fi restaurat.
Azure Storage trebuie să fie din aceeaşi regiune Azure, dar nu este restricţionat să utilizeze doar Local Redundancy Storage (LRD). Prin urmare, trebuie să ştim foarte bine ce tip de stocare utilizăm când avem restricţii pentru datele noastre la nivel de ţară.
Acesta este serviciul visurilor mele. Neavând nicio restricţie în materie de stocare, puteţi folosi cât spaţiu doriţi pentru stocare. Este oceanul perfect pentru stocare şi analiză de date.
Când creaţi Azure Data Lake, trebuie să specificaţi o locaţie, o regiune Azure, unde va fi stocat tot conţinutul. Practic acolo se creează oceanul dumneavoastră de date.
Ţinând cont de informaţia de ultimă oră, nu e clar (nu pentru mine, cel puţin), dacă există feature-uri de replicare în toate regiunile. Deoarece vorbim de cantităţi mari de date, bănuiesc că intenţia nu este de a replica conţinutul în toate regiunile Azure (iar acesta e un lucru bun). În acest context, consider că Azure Data Lake poate fi folosit în siguranţă dacă există restricţii la nivel de ţară, dar recomand o discuţie cu un reprezentant Microsoft înainte de a sări direct în ocean.
Există o serie de servicii Azure care oferă mecanisme variate de recuperare şi de backup în aceeaşi regiune Azure sau în alte regiuni. E important să nu uităm să verificăm fiecare serviciu când avem cerinţe şi restricţii speciale.
Cerinţe, precum legile specifice unei ţări în materie de date, nu sunt comune şi, de multe ori, putem găsi alte metode de a le respecta, precum criptarea sau segmentarea datelor în funcţie de tipul de informaţie la care se referă. Voi aborda celelalte moduri în care putem rezolva această problemă în articole viitoare.
de Ovidiu Mățan
de Vasile Boris
de Paul Hrimiuc
