Disponibilitatea în cloud: SLA, redundanță și zone

Disponibilitatea unui serviciu este proporția de timp în care el funcționează și poate fi folosit. Când un furnizor promite „99,9%”, îți spune că, într-o perioadă lungă, serviciul va fi funcțional în 99,9% din timp. Restul este timp de nefuncționare permis, iar diferența dintre cifre pare mică, dar în practică este uriașă.

Niciun sistem nu funcționează fără oprire pentru totdeauna. Discurile se defectează, cablurile se taie, programele au erori. Arta unui serviciu bun nu este să evite orice defect, ci să fie construit astfel încât defectele să nu ajungă la utilizator.

Ce înseamnă procentele din SLA?

SLA vine de la „service level agreement”, adică acordul privind nivelul serviciului: documentul prin care furnizorul se obligă la o disponibilitate minimă și precizează ce primești dacă nu o respectă. De obicei, compensația este un credit în factură, nu o despăgubire pentru pierderile tale.

Procentele se traduc ușor în timp de oprire permis într-o perioadă de un an:

Fiecare cifră de 9 adăugată înseamnă o reducere de zece ori a timpului permis și, de regulă, un cost mult mai mare. Un blog personal se descurcă foarte bine cu 99,9%. O aplicație de plăți sau un sistem de urgență vizează cifre mult mai mari.

Citește mereu și literele mici: SLA-ul acoperă de obicei doar serviciul furnizorului, nu și greșelile tale de configurare, și exclude de regulă întreruperile programate anunțate din timp. Dacă aplicația ta are mai multe piese, disponibilitatea totală este mai mică decât a oricărei piese luate separat, pentru că ele se înmulțesc.

Ce este redundanța și cum ajută?

Redundanța înseamnă să ai mai multe copii ale aceleiași componente, astfel încât, dacă una cade, alta preia imediat. Este ideea din spatele roții de rezervă, al generatorului dintr-un spital sau al celor două motoare ale unui avion.

În infrastructura digitală, redundanța se aplică pe mai multe niveluri:

• discuri: datele se scriu pe mai multe discuri, deci pierderea unuia nu șterge nimic;
• servere: mai multe copii ale aplicației rulează în paralel, în spatele unui echilibrator de încărcare;
• alimentare și răcire: surse duble de curent, baterii și generatoare, descrise în Centrele de date: cum funcționează și ce resurse consumă;
• conexiuni de rețea: cel puțin două legături către internet, de la furnizori diferiți.

Redundanța funcționează numai dacă defectele sunt independente. Dacă două servere „diferite” stau pe aceeași sursă de curent, când aceasta se oprește cad amândouă. De aceea proiectanții caută mereu locul unde ceva este încă unic: punctul unic de cădere.

Ce sunt regiunile și zonele de disponibilitate?

O regiune este o zonă geografică în care furnizorul are centre de date, iar o zonă de disponibilitate este un centru de date sau un grup de centre izolate din interiorul regiunii. Zonele au curent, răcire și rețea separate, dar sunt legate între ele prin conexiuni foarte rapide.

Dacă pui aplicația în două zone ale aceleiași regiuni, un incendiu, o pană de curent sau o defecțiune de rețea dintr-o clădire nu o oprește. Dacă o pui în două regiuni, reziști și la evenimente mai mari, cum ar fi o calamitate naturală care lovește o zonă întreagă. Cu cât separarea este mai mare, cu atât crește și întârzierea dintre copii, deci sincronizarea datelor devine mai grea.

Alegerea regiunii influențează și viteza. Un serviciu aflat aproape de utilizatori răspunde mai repede, subiect tratat în Latența și lățimea de bandă: ce înseamnă viteza internetului. Mai influențează și aspectele legale legate de locul datelor, despre care citești în Suveranitatea datelor: de ce contează unde sunt stocate.

Cum construiești un sistem care rezistă la defecte?

Un sistem tolerant la defecte se construiește pornind de la ipoteza că ceva va cădea, nu că nu va cădea. Din această ipoteză rezultă câteva practici simple.

1. Elimini punctele unice de cădere. Pentru fiecare componentă te întrebi: dacă dispare, ce se oprește?
2. Verifici automat starea fiecărei piese. Un echilibrator de încărcare trimite cereri doar către serverele care răspund corect la verificări periodice.
3. Repari automat. Un server defect este înlocuit cu unul nou, fără intervenție umană.
4. Degradezi elegant. Dacă o funcție secundară nu merge, restul aplicației rămâne utilizabil; de exemplu, un magazin afișează produsele chiar dacă recomandările nu se încarcă.
5. Testezi defectele. Echipele serioase opresc intenționat componente, în condiții controlate, ca să vadă dacă sistemul reacționează cum trebuie.

Redundanța nu înlocuiește copia de siguranță. Dacă o greșeală sau un program rău intenționat șterge datele, ștergerea se propagă instantaneu pe toate copiile active. De aceea ai nevoie și de copii separate, ca în Backupul datelor: regula 3-2-1 explicată pe înțeles, iar în cazul atacurilor de tip răscumpărare vezi și Ransomware-ul: cum funcționează și cum te protejezi.

Atenție: Disponibilitatea ridicată nu este gratuită. Dublarea tuturor componentelor dublează aproape costul, iar sistemele mai complexe au mai multe locuri în care ceva poate merge prost. Stabilește un nivel potrivit nevoii reale, nu cel mai înalt posibil.

Care nivel de disponibilitate ți se potrivește?

Nivelul potrivit depinde de cât te costă o oră de oprire. Pentru un site de prezentare, o oră de oprire într-o noapte de duminică este neglijabilă. Pentru un magazin online în plin sezon de reduceri, aceeași oră înseamnă vânzări pierdute și clienți nemulțumiți.

Un exercițiu util este să răspunzi la două întrebări: cât timp poți trăi fără serviciu (timpul de recuperare) și câtă muncă îți permiți să pierzi (ultimele date nesalvate). Din răspunsuri decizi dacă ai nevoie de o singură zonă, de mai multe sau de mai multe regiuni. Pentru multe proiecte mici, un singur server cu backup regulat și un plan clar de reinstalare acoperă nevoia, la un cost mult mai mic.