Sesiunea 8 din 12
Unde Trăiesc Datele Tale în Cloud?
Azure Storage Fundamentals
Bine ați revenit! Astăzi descoperim un capitol esențial al oricărei arhitecturi cloud serioase: Azure Storage. Vom înțelege de ce serverul nu este locul potrivit pentru date, cum funcționează un Storage Account și cum protejăm ceea ce contează cu adevărat.
Agenda Sesiunii de Astăzi
Fiecare parte construiește peste cea anterioară, de la concept la practică.
Serverul vs. Storage-ul
De ce nu ținem datele pe VM și care este principiul fundamental al separării compute de storage.
Ce este un Storage Account?
Blob Storage, File Share, Queue Storage — cele trei tipuri principale și analogiile lor din lumea reală.
Practică: Creăm Storage Account
Configurare pas cu pas în Azure Portal, cu discuție despre redundanță (LRS, ZRS, GRS).
Securitate: Public vs. Private
Una dintre cele mai frecvente cauze de scurgeri de date în cloud — și cum o evităm.
File Share și Queue Storage
Scenarii practice de utilizare și cum se integrează în arhitecturi moderne.
Cleanup și Tema pentru Acasă
Curățarea resurselor și cele trei întrebări de consolidare.
Principiul Fundamental
Serverul Procesează, Storage-ul Păstrează
Până acum am construit compute — mașini virtuale, web apps. Am configurat rețele și reguli de securitate. Dar am ignorat o întrebare fundamentală: Ce se întâmplă cu datele când serverul se oprește?
Dacă șterg o mașină virtuală pe care am lucrat săptămâni întregi — fișierele, configurațiile, documentele, imaginile salvate direct pe VM — dispar odată cu mașina? Răspunsul, în majoritatea cazurilor, este da.
VM-ul este Biroul
Biroul este locul unde angajații lucrează, fac calcule, scriu rapoarte. Este spațiul activ, dinamic — dar volatil. VM-ul procesează cereri, rulează cod. Dar când se oprește sau este șters, tot ce era stocat local pe el dispare.
Storage-ul este Arhiva
Arhiva este locul unde documentele importante sunt stocate în siguranță — contracte, facturi, istoricul întregii activități. Storage-ul în cloud este construit pentru durabilitate: separat de compute, redundant, persistent.
Regula de aur a arhitecturii cloud: Niciodată nu stoca date importante exclusiv pe discul local al unui VM. Folosește un serviciu de stocare dedicat, independent de ciclul de viață al serverului.
Tipuri de Storage
Ce Este un Storage Account în Azure?
Un Storage Account în Azure este un container mare — un fel de depozit central — care ține datele tale în cloud. Nu este un server. Nu procesează nimic. Pur și simplu stochează, organizează și pune la dispoziție datele ori de câte ori este nevoie, de oriunde din lume.
Blob Storage
Fișiere nestructurate de orice tip: imagini, video, backup-uri, arhive. Cel mai folosit serviciu din familia Azure Storage.
File Share
Echivalentul unui folder partajat în rețea, montat ca drive pe Windows sau Linux. Ideal pentru configurații și fișiere comune.
Queue Storage
Mesagerie asincronă între componente ale unei aplicații. Decuplează serviciile și le permite să lucreze independent.
Table Storage
Stocare NoSQL pentru date semi-structurate. Îl menționăm astăzi, dar nu îl detaliem — va reveni în sesiunile despre baze de date.
Blob Storage — Depozitul Universal
Blob vine de la Binary Large Object. Este locul unde stochezi fișiere neorganizate, obiecte de orice fel — indiferent de format sau dimensiune. Gândiți-vă la un depozit mare cu cutii: nu contează ce este în cutie, nu contează ordinea. Pui cutia, primești o adresă unică (un URL), și o poți accesa oricând, de oriunde.
Ce se stochează în Blob?
Date de aplicație
Avataruri și fotografii de profil, documente uploadate de clienți (PDF, Word, Excel), imagini de produs pentru magazine online.
Date de infrastructură
Fișiere video și audio pentru platforme media, backup-uri automate ale bazelor de date, log-uri ale aplicațiilor, artefacte de build.
Fiecare fișier (blob) are un URL unic, accesibil prin HTTP/HTTPS. Aplicațiile pot citi și scrie direct prin acest URL.
File Share — Folderul Partajat în Cloud
File Share este echivalentul unui drive de rețea pe care toți angajații unei firme îl văd și îl accesează — același concept, dar în cloud, accesibil de oriunde. Poate fi montat ca o unitate de rețea pe Windows (drive G:, H:) sau ca un director în filesystem-ul Linux.
Fișiere de configurare partajate
Zece servere accesează aceleași configurări. O modificare se reflectă imediat pe toate.
Aplicații legacy
Share-uri de fișiere pentru aplicații care nu pot fi migrate la Blob. Protocolul SMB — același folosit de Windows.
Medii de dezvoltare
Fișiere comune între developeri, accesibile ca un folder local.
Queue Storage — Comunicare Asincronă
Imaginați-vă o cutie poștală. Aplicația A pune un mesaj în cutie. Aplicația B vine mai târziu, găsește mesajul și îl procesează. Cele două aplicații nu trebuie să funcționeze simultan. Nu trebuie să comunice direct.
Când un client plasează o comandă online, se întâmplă mai multe lucruri: email de confirmare, scăderea din stoc, generarea facturii, notificarea depozitului. Cu Queue Storage, aplicația principală pune pur și simplu un mesaj în coadă: „a venit o comandă nouă". Fiecare serviciu procesează la propria viteză.
Conceptul cheie: Queue Storage decuplează componentele unei aplicații și le permite să comunice fără să depindă una de cealaltă în timp real. Sistemul devine rezistent și scalabil.
Practică
Creăm Storage Account — Pas cu Pas
Creați un Resource Group Nou
Mergeți la Resource Groups → Create. Numiți-l rg-s08-[prenumele_vostru]. Selectați regiunea West Europe.
Creați Storage Account
Create a Resource → Storage Account. Name: s08storage[prenumele] — fără cratime, fără spații, doar litere mici și cifre. Trebuie să fie unic la nivel global! Region: West Europe. Performance: Standard. Redundancy: LRS.
Review and Create
Verificați configurația în pagina de sumar. Dați Create. Deployment-ul durează câteva secunde. Așteptați mesajul „Your deployment is complete".
Redundanță în Azure Storage — Cât de Sigure Sunt Datele?
Opțiunea Redundancy determină câte copii ale datelor păstrează Azure și unde sunt stocate.
LRS — Locally Redundant
3 copii ale datelor în același datacenter. Dacă un disc fizic se defectează, datele sunt recuperate automat. Cel mai ieftin. Potrivit pentru date necritice sau dev/test.
ZRS — Zone Redundant
3 copii în trei zone de disponibilitate diferite din aceeași regiune. Dacă un datacenter întreg cade, datele rămân disponibile. Recomandat pentru producție cu High Availability.
GRS — Geo Redundant
6 copii — 3 în regiunea primară și 3 într-o regiune secundară. Protecție maximă contra catastrofelor naturale. Cel mai scump, pentru date critice de business.
Într-un mediu de producție real, alegerea redundanței depinde de cât de critice sunt datele și care este RTO/RPO acceptat de business.
Practică: Blob Container și Primul Upload
Acum că avem Storage Account-ul creat, hai să creăm primul container Blob.
Navigați la Containers
În Storage Account, în meniul din stânga, găsiți secțiunea Containers.
Creați Container Nou
Dați + New Container. Name: s08-container-[prenumele]. Public access level: Private. Confirmați.
Upload Fișier
Intrați în container. Selectați Upload, alegeți un fișier text sau o imagine, confirmați.
Verificați Rezultatul
Fișierul vostru este acum în cloud. Stocat în Azure, redundant în trei copii, accesibil de oriunde printr-un URL unic.
Securitate
Public vs. Private — Una Dintre Cele Mai Periculoase Setări
Aceasta este una dintre cele mai importante discuții despre securitate în storage. Urmați pașii și observați cu atenție.
Pasul 1: Schimbați în Public
Navigați la containerul vostru. Schimbați temporar nivelul de acces din Private în Blob (permite acces public la fișierele individuale).
Pasul 2: Copiați URL-ul
Selectați fișierul uploadat, copiați URL-ul. Deschideți un tab nou și lipiți URL-ul.
Pasul 3: Observați
Oricine cu acel link poate vedea fișierul vostru. Fără autentificare. Fără parolă. Fără niciun fel de verificare.
Pasul 4: Reveniți la Private ⚠
Schimbați înapoi la Private. Verificați că URL-ul nu mai funcționează pentru acces anonim. Aceasta este setarea corectă și sigură.
Scurgerile de Date din Cloud: Un Risc Real
De Ce Contează Această Setare?
Dacă un Storage Account cu date sensibile este setat la Public, oricine care găsește URL-ul poate descărca datele — fără autentificare. Companii mari au expus accidental milioane de înregistrări din cauza unui singur container Blob setat la Public.
Regula de Bază în Producție
Containerele Blob sunt Private by default și rămân Private dacă nu aveți un motiv explicit. Scenarii legitime pentru public: imagini de produs, fișiere statice (CSS, JS), documente publice. Alternativa sigură: SAS Tokens — URL-uri cu expirare automată.
Practică: Creăm un File Share
Navigați la File Shares
În Storage Account, în meniul din stânga, găsiți File Shares.
Creați File Share Nou
Selectați + New File Share. Name: s08-fileshare-[prenumele]. Confirmați.
Explorați Opțiunile
Observați opțiunile de Connect — Azure vă oferă automat scriptul de PowerShell sau bash pentru montarea ca drive de rețea.
Diferența Blob vs. File Share
Blob Storage
Pentru fișiere accesate prin HTTP, prin URL, printr-o aplicație. Optimizat pentru acces web și volume mari de date nestructurate.
File Share
Pentru situații în care vrei să montezi un folder ca drive de rețea — vizibil în File Explorer pe Windows. Protocolul SMB — aplicațiile legacy pot fi migrate fără modificări de cod.
Practică: Creăm un Queue Storage
În Storage Account-ul vostru, găsiți Queues în meniu. Dați + Queue și introduceți numele: s08-queue-[prenumele]. Queue-ul creat este inițial gol — mesajele sunt de obicei adăugate de aplicații prin cod. Puteți adăuga manual un mesaj de test prin butonul Add Message.
Mesajele din Queue Storage expiră după maxim 7 zile dacă nu sunt procesate. Serviciul garantează livrare at-least-once.
Cleanup: Ștergem Resursele
Ultima operație a sesiunii: curățarea resurselor pentru a evita costuri inutile.
Navigați la Resource Group
Mergeți la Resource Groups și găsiți rg-s08-[prenumele_vostru].
Inițiați ștergerea
Selectați Delete Resource Group. Introduceți exact numele resource group-ului în câmpul de confirmare.
Confirmați și Așteptați
Dați Delete. Toate resursele din grup — Storage Account, containere, date — vor fi șterse.
Tema pentru Acasă — Sesiunea 8
Răspunsurile trebuie să demonstreze că ați înțeles conceptele, nu doar că le-ați memorat. Folosiți analogii proprii.
Blob, File Share și Queue
Explicați diferența dintre cele trei tipuri de stocare. Folosiți câte o analogie proprie pentru fiecare — diferită de cele discutate astăzi.
De Ce Nu Pe Discul VM-ului?
De ce nu ținem datele importante exclusiv pe discul local al unei mașini virtuale? Descrieți cel puțin două scenarii concrete în care această decizie greșită ar duce la pierdere de date.
Ce Este LRS și De Ce Contează?
Definiți LRS și explicați mecanismul din spatele lui. Când ar trebui o companie să aleagă ZRS sau GRS în locul LRS?
Ce Am Construit Împreună în 8 Sesiuni
1 Rețea (S4–S5)
VNet, Subnet, NSG, porturi, reguli de securitate, izolare și conectivitate controlată.
2 Compute (S6–S7)
Mașini virtuale (IaaS), Web Apps (PaaS), scalare, disponibilitate, alegerea modelului potrivit.
3 Storage (S8 — Astăzi)
Blob, File Share, Queue, redundanță (LRS/ZRS/GRS), securitate (Public vs. Private), separarea compute de stocare.
Următoarea sesiune
Sesiunea 9 — Baze de Date în Cloud
Mai lipsește o piesă esențială: datele structurate. Diferența dintre o bază de date pe VM (tu o administrezi) și una managed (Azure se ocupă de tot). Același framework IaaS vs PaaS, aplicat la baze de date.
Vă mulțumesc pentru participare și pentru implicare! Ne vedem la Sesiunea 9.