În lumea reală, pot exista situații în care o scădere a performanței serverelor dvs. poate apărea din cauza unor evenimente care variază de la un vârf brusc de trafic poate duce la o pană de curent bruscă. Poate fi mult mai rău și serverele dvs. pot fi paralizate- indiferent dacă aplicațiile dvs. sunt găzduite în cloud sau pe o mașină fizică. Astfel de situații sunt inevitabile. Cu toate acestea, în loc să sperați că nu se întâmplă, ceea ce ar trebui de fapt să faceți este să vă pregătiți astfel încât sistemele dvs. să nu se confrunte cu defecțiuni.
Răspunsul la această problemă este utilizarea unei configurații sau arhitecturi de înaltă disponibilitate (HA). Arhitectura de înaltă disponibilitate este o abordare de definire a componentelor, modulelor sau a implementării serviciilor unui sistem care asigură o performanță operațională optimă, chiar și în momente de încărcare ridicată. Deși nu există reguli fixe de implementare a sistemelor HA, există, în general, câteva bune practici pe care trebuie să le urmați astfel încât să obțineți cât mai mult din resursele minime.
De ce aveți nevoie de ea?
Lasă-ne să definim timpul de nefuncționare înainte de a merge mai departe. Timpul de nefuncționare este perioada de timp în care sistemul (sau rețeaua) dvs. nu este disponibil pentru utilizare sau nu răspunde. Timpul de nefuncționare poate cauza pierderi uriașe unei companii, deoarece toate serviciile lor sunt puse în așteptare atunci când sistemele lor nu funcționează. În august 2013, Amazon a fost indisponibilă timp de 15 minute (atât serviciile web, cât și cele mobile) și a ajuns să piardă peste 66 000 de dolari pe minut. Acestea sunt cifre uriașe, chiar și pentru o companie de mărimea Amazon.
Există două tipuri de întreruperi – programate și neprogramate. O oprire programată este un rezultat al întreținerii, care este inevitabilă. Aceasta include aplicarea de patch-uri, actualizarea softurilor sau chiar modificări în schema bazei de date. O întrerupere neprogramată este, însă, cauzată de un eveniment neprevăzut, cum ar fi o defecțiune hardware sau software. Acest lucru se poate întâmpla din cauza întreruperilor de curent sau a defectării unei componente. Timpii de nefuncționare programați sunt, în general, excluși din calculele de performanță.
Obiectivul principal al implementării unei arhitecturi de înaltă disponibilitate este acela de a vă asigura că sistemul sau aplicația este configurată pentru a face față unor sarcini diferite și unor defecțiuni diferite cu un timp de nefuncționare minim sau deloc. Există mai multe componente care vă ajută să realizați acest lucru, iar noi le vom discuta pe scurt.
Cum se măsoară disponibilitatea?
Organizațiile care plănuiesc să utilizeze pe deplin o infrastructură cloud trebuie să fie, de asemenea, capabile să satisfacă cererile de disponibilitate 24/7. Disponibilitatea poate fi măsurată ca procent de timp în care sistemele sunt disponibile.
x = (n – y) * 100/n
Unde n este numărul total de minute într-o lună calendaristică și y este numărul total de minute în care serviciul este indisponibil în luna calendaristică dată. Disponibilitatea ridicată se referă pur și simplu la o componentă sau un sistem care este în permanență operațional pentru o perioadă de timp dezirabil de lungă durată. Standardul de disponibilitate pentru un produs sau un sistem, foarte răspândit, dar aproape imposibil de atins, este denumit disponibilitate „cinci 9” (99,999%). Disponibilitatea ridicată este o cerință pentru orice întreprindere care speră să își protejeze afacerea împotriva riscurilor generate de o întrerupere a sistemului. Aceste riscuri, pot duce la pierderi de venituri de milioane de dolari.
Se merită cu adevărat banii?
Faptul că optarea pentru o arhitectură de înaltă disponibilitate vă oferă o performanță mai mare este în regulă, dar are și un cost mare. Trebuie să vă întrebați dacă credeți că decizia este justificată din punct de vedere financiar.
Trebuie luată o decizie cu privire la faptul dacă timpul de funcționare suplimentar merită cu adevărat suma de bani care trebuie investită. Trebuie să vă întrebați cât de dăunătoare pot fi eventualele timpii de nefuncționare pentru compania dvs. și cât de importante sunt serviciile dvs. în derularea afacerii.
Cum îl realizăm?
Acum că v-ați decis să mergeți pe această cale, să discutăm despre modalitățile de implementare. În mod neintuitiv, adăugarea mai multor componente la un sistem nu ajută la creșterea stabilității acestuia și la obținerea unei disponibilități ridicate. De fapt, poate duce la opusul, deoarece mai multe componente cresc probabilitatea de defecțiuni. Proiectele moderne permit distribuirea sarcinilor de lucru pe mai multe instanțe, cum ar fi o rețea sau un cluster, ceea ce ajută la optimizarea utilizării resurselor, la maximizarea randamentului, la minimizarea timpilor de răspuns și la evitarea supraîncărcării oricărui sistem în procesul cunoscut sub numele de echilibrare a sarcinii. De asemenea, implică trecerea la o resursă de rezervă, cum ar fi un server, o componentă sau o rețea, în cazul defectării uneia active, cunoscută sub numele de sisteme Failover.
Utilizarea mai multor servere de aplicații:
Imaginați-vă că aveți un singur server pentru a vă presta serviciile și că un vârf brusc de trafic duce la defectarea acestuia (sau îl prăbușește). Într-o astfel de situație, până când serverul dvs. este repornit, nu mai pot fi servite alte cereri, ceea ce duce la un timp de nefuncționare.
Soluția evidentă în acest caz este să vă implementați aplicația pe mai multe servere. Trebuie să distribuiți sarcina între toate acestea, astfel încât niciunul dintre ele să nu fie supraîncărcat, iar randamentul să fie optim. De asemenea, puteți implementa părți ale aplicației dvs. pe servere diferite. De exemplu, ar putea exista un server separat pentru gestionarea e-mailurilor sau unul separat pentru procesarea fișierelor statice, cum ar fi imaginile (ca o rețea de livrare de conținut).
Scalarea bazelor de date:
Bazele de date sunt cele mai populare și poate una dintre cele mai simple modalități din punct de vedere conceptual de a salva datele utilizatorilor. Trebuie reținut faptul că bazele de date sunt la fel de importante pentru serviciile dvs. ca și serverele de aplicații. Bazele de date rulează pe servere separate (cum ar fi Amazon RDS) și sunt, de asemenea, predispuse la căderi. Ceea ce este mai rău este că prăbușirile bazelor de date pot duce la pierderea datelor utilizatorilor, ceea ce se poate dovedi costisitor.
Redundanța este un proces care creează sisteme cu niveluri ridicate de disponibilitate prin realizarea detectabilității defecțiunilor și evitarea defecțiunilor de cauză comună. Acest lucru poate fi realizat prin menținerea unor sclavi, care pot interveni în cazul în care serverul principal cedează. Un alt concept interesant de scalare a bazelor de date este sharding. Un shard este o partiție orizontală într-o bază de date, în care rândurile aceleiași tabele care este apoi rulată pe un server separat.
Localizări geografice diversificate:
Scalarea aplicațiilor și apoi a bazelor de date este un pas foarte mare înainte, dar ce se întâmplă dacă toate serverele se află în aceeași locație fizică și ceva teribil, cum ar fi un dezastru natural, afectează centrul de date în care se află serverele dumneavoastră? Acest lucru poate duce la timpi de indisponibilitate potențial uriași.
Este, prin urmare, imperativ să vă păstrați serverele în locații diferite. Majoritatea serviciilor web moderne vă permit să selectați locația geografică a serverelor dumneavoastră. Ar trebui să alegeți cu înțelepciune pentru a vă asigura că serverele dvs. sunt distribuite peste tot în lume și nu localizate într-o zonă.
În acest post, am încercat să ating ideile de bază care formează ideea de arhitectură de înaltă disponibilitate. În analiza finală, este evident că niciun sistem nu poate rezolva toate problemele. Prin urmare, trebuie să vă evaluați cu atenție situația și să decideți ce opțiuni li se potrivesc cel mai bine. Sperăm că acest lucru v-a introdus în lumea arhitecturii de înaltă disponibilitate și v-a ajutat să decideți cum să realizați acest lucru pentru dumneavoastră.
Care sunt cele mai bune practici?
Pentru a limita defecțiunile sistemului și pentru a ține la distanță atât timpii de nefuncționare planificați, cât și cei neplanificați, utilizarea unei arhitecturi de înaltă disponibilitate (HA) este foarte recomandată, în special pentru aplicațiile critice. Experții în materie de disponibilitate insistă asupra faptului că, pentru ca orice sistem să fie de înaltă disponibilitate, părțile sale trebuie să fie bine proiectate și riguros testate. Proiectarea și implementarea ulterioară a unei arhitecturi de înaltă disponibilitate poate fi dificilă, având în vedere gama vastă de opțiuni software, hardware și de implementare. Cu toate acestea, un efort de succes începe de obicei cu cerințe de afaceri clar definite și înțelese în mod cuprinzător. Arhitectura aleasă ar trebui să fie capabilă să satisfacă nivelurile dorite de securitate, scalabilitate, performanță și disponibilitate.
Singura modalitate de a garanta că mediile de calcul au un nivel dezirabil de continuitate operațională în timpul orelor de producție este proiectarea acestora cu disponibilitate ridicată. Pe lângă proiectarea corespunzătoare a arhitecturii, întreprinderile pot menține online aplicațiile cruciale prin respectarea celor mai bune practici recomandate pentru disponibilitate ridicată.
- Salvare, recuperare și replicare a datelor
Semnele distinctive ale unui plan bun de protecție a datelor care protejează împotriva defecțiunilor sistemului sunt o strategie solidă de salvare și recuperare. Datele valoroase nu ar trebui să fie niciodată stocate fără copii de rezervă adecvate, replicare sau capacitatea de a recrea datele. Fiecare centru de date ar trebui să planifice din timp pierderea sau corupția datelor. Erorile de date pot crea probleme de autentificare a clienților, pot afecta conturile financiare și, ulterior, credibilitatea comunității de afaceri. Strategia recomandată pentru menținerea integrității datelor constă în crearea unei copii de rezervă complete a bazei de date primare, apoi testarea incrementală a serverului sursă pentru a detecta eventualele corupții de date. Crearea de copii de rezervă complete se află în prima linie a recuperării în urma unei defecțiuni catastrofale a sistemului.
- Clustering
Chiar și cu cea mai bună calitate a ingineriei software, toate serviciile de aplicații sunt sortite să eșueze la un moment dat. Înalta disponibilitate se referă la furnizarea de servicii de aplicații indiferent de eșecuri. Clusterizarea poate oferi servicii de aplicații cu basculare instantanee în caz de defecțiune. Un serviciu de aplicație care este „conștient de cluster” este capabil să apeleze resurse de pe mai multe servere; acesta revine la un server secundar în cazul în care serverul principal devine offline. Un cluster de înaltă disponibilitate include mai multe noduri care fac schimb de informații prin intermediul unor grile de memorie de date partajate. Acest lucru înseamnă că orice nod poate fi deconectat sau oprit din rețea, iar restul clusterului va continua să funcționeze normal, atât timp cât cel puțin un singur nod este complet funcțional. Fiecare nod poate fi actualizat în mod individual și reîntregit în timp ce clusterul funcționează. Costul ridicat al achiziționării de hardware suplimentar pentru a implementa un cluster poate fi atenuat prin configurarea unui cluster virtualizat care utilizează resursele hardware disponibile.
- Network Load Balancing
Balansarea încărcăturii este o modalitate eficientă de a crește disponibilitatea aplicațiilor critice bazate pe web. Atunci când sunt detectate instanțe de defecțiune a serverelor, acestea sunt înlocuite fără probleme atunci când traficul este redistribuit automat către serverele care sunt încă în funcțiune. Nu numai că echilibrarea încărcării duce la o disponibilitate ridicată, dar facilitează și scalabilitatea incrementală. Echilibrarea încărcării rețelei poate fi realizată fie prin intermediul unui model „pull”, fie prin intermediul unui model „push”. Aceasta facilitează niveluri mai ridicate de toleranță la erori în cadrul aplicațiilor de servicii.
- Soluții fail over
Arhitectura de înaltă disponibilitate constă, în mod tradițional, într-un set de servere slab cuplate care au capacități de failover. Failoverul este practic un mod operațional de rezervă în care funcțiile unei componente de sistem sunt preluate de un sistem secundar în cazul în care cel primar devine offline, fie din cauza unei defecțiuni, fie din cauza unei opriri planificate. Un „failover la rece” are loc atunci când serverul secundar este pornit numai după ce cel primar a fost complet oprit. Un „failover la cald” are loc atunci când toate serverele funcționează simultan, iar sarcina este direcționată în întregime către un singur server la un moment dat. În ambele scenarii, sarcinile sunt transferate automat către o componentă a sistemului de rezervă, astfel încât procesul să rămână cât mai transparent pentru utilizatorul final. Failover-ul poate fi gestionat prin intermediul DNS, într-un mediu bine controlat.
- Redundanța geografică
Redundanța geografică este singura linie de apărare atunci când vine vorba de prevenirea întreruperii serviciului în fața unor evenimente catastrofale, cum ar fi dezastrele naturale care provoacă întreruperi ale sistemului. Ca și în cazul georeplicării, mai multe servere sunt implementate în locații geografice distincte. Locațiile ar trebui să fie distribuite la nivel global și nu localizate într-o anumită zonă. Este esențial să se ruleze stive de aplicații independente în fiecare dintre locații, astfel încât, în cazul în care există o defecțiune într-o locație, cealaltă să poată continua să funcționeze. În mod ideal, aceste locații ar trebui să fie complet independente una de cealaltă.
- Planificați pentru eșec
În ciuda faptului că aplicarea celor mai bune practici de înaltă disponibilitate reprezintă, în esență, planificarea pentru eșec; există și alte acțiuni pe care o organizație le poate întreprinde pentru a-și spori gradul de pregătire în cazul unei defecțiuni a sistemului care duce la întreruperi. Organizațiile ar trebui să păstreze date privind eșecurile sau consumul de resurse care pot fi utilizate pentru a izola problemele și a analiza tendințele. Aceste date pot fi colectate numai prin monitorizarea continuă a volumului de lucru operațional. Un birou de asistență pentru recuperare poate fi pus în funcțiune pentru a colecta informații despre probleme, a stabili istoricul problemelor și a începe rezolvarea imediată a problemelor. Un plan de recuperare ar trebui nu numai să fie bine documentat, ci și testat în mod regulat pentru a asigura caracterul său practic atunci când se confruntă cu întreruperi neplanificate. Formarea personalului în domeniul ingineriei disponibilității va îmbunătăți competențele acestuia în ceea ce privește proiectarea, implementarea și întreținerea arhitecturilor de înaltă disponibilitate. Ar trebui, de asemenea, să se instituie politici de securitate pentru a reduce incidentele de întrerupere a sistemului din cauza breșelor de securitate.
Exemplu: Arhitectura FileCloud High Availability
Diagrama următoare explică modul în care serverele FileCloud pot fi configurate pentru High Availability pentru a îmbunătăți fiabilitatea serviciului și a reduce timpii morți. Faceți clic aici pentru mai multe detalii.