Scalabilitatea este o proprietate a unui sistem de calcul care oferă o creștere previzibilă a caracteristicilor sistemului, de exemplu, numărul de utilizatori acceptați, viteza de răspuns, performanța generală etc., atunci când i se adaugă resurse de calcul. În cazul unui server DBMS, pot fi luate în considerare două metode de scalare - verticală și orizontală (Fig. 2).

Odată cu scalarea orizontală, numărul de servere DBMS crește, posibil comunicând între ele în mod transparent, împărțind astfel încărcarea generală a sistemului. Este posibil ca această soluție să devină din ce în ce mai populară pe măsură ce crește suportul pentru arhitecturi slab cuplate și baze de date distribuite, dar tinde să fie dificil de administrat.

Scalare verticală presupune creșterea puterii unui server DBMS separat și se realizează prin înlocuirea hardware-ului (procesor, discuri) cu altele mai rapide sau adăugarea de noduri suplimentare. Un bun exemplu este creșterea numărului de procesoare în platformele SMP (simetric multiprocessor). În acest caz, software-ul serverului nu ar trebui schimbat (în special, nu poate fi necesară achiziționarea de module suplimentare), deoarece acest lucru ar crește complexitatea administrării și ar înrăutăți predictibilitatea comportamentului sistemului. Indiferent de metoda de scalare utilizată, câștigul este determinat de cât de complet utilizează programele de server resursele de calcul disponibile. În evaluări ulterioare, vom lua în considerare scalarea verticală, care, potrivit analiștilor, se confruntă cu cea mai mare creștere pe piața modernă a computerelor.

Proprietatea de scalabilitate este relevantă din două motive principale. În primul rând, condițiile moderne de afaceri se schimbă atât de repede încât fac imposibilă planificarea pe termen lung, care necesită o analiză cuprinzătoare și îndelungată a datelor deja învechite, chiar și pentru acele organizații care își permit. În schimb, vine o strategie de creștere treptată, pas cu pas, a puterii sistemelor informaționale. Pe de altă parte, schimbările în tehnologie duc la apariția a tot mai multe soluții noi și a prețurilor hardware mai mici, ceea ce poate face ca arhitectura sistemelor informaționale să fie mai flexibilă. În același timp, interoperabilitatea și deschiderea produselor software și hardware de la diferiți producători se extind, deși până acum eforturile lor de a se conforma standardelor au fost coordonate doar în sectoare restrânse ale pieței. Fără a lua în considerare acești factori, consumatorul nu va putea profita de noile tehnologii fără a îngheța fondurile investite în tehnologii care nu sunt suficient de deschise sau care s-au dovedit a fi nepromițătoare. În zona stocării și procesării datelor, acest lucru necesită ca atât DBMS, cât și serverul să fie scalabili. Astăzi, parametrii cheie de scalabilitate sunt:

• suport pentru multiprocesare;
• flexibilitate arhitecturală.

Sisteme multiprocesor

Pentru scalarea verticală, sistemele multiprocesor simetrice (SMP) sunt din ce în ce mai utilizate, deoarece în acest caz nu este necesară schimbarea platformei, adică. abilități de sistem de operare, hardware și administrare. În acest scop, este posibil să se utilizeze și sisteme cu paralelism masiv (MPP), dar până acum utilizarea lor este limitată la sarcini speciale, de exemplu, cele de calcul. Atunci când se evaluează un server DBMS cu arhitectură paralelă, este indicat să se acorde atenție două caracteristici principale ale extensibilității arhitecturii: adecvarea și transparența.

Proprietatea de adecvare necesită ca arhitectura serverului să suporte în mod egal unul sau zece procesoare fără reinstalare sau modificări semnificative în configurație, precum și module software suplimentare. O astfel de arhitectură va fi la fel de utilă și eficientă atât într-un sistem cu un singur procesor, cât și, pe măsură ce complexitatea sarcinilor de rezolvat crește, pe mai multe sau chiar mai multe procesoare (MPP). În general, consumatorul nu trebuie să cumpere sau să învețe noi opțiuni software.

Oferirea de transparență arhitecturii serverului, la rândul său, face posibilă ascunderea modificărilor configurației hardware din aplicații, de exemplu. garantează portabilitatea sistemelor software de aplicație. În special, în arhitecturile multiprocesoare strâns cuplate, aplicația poate comunica cu serverul printr-un segment de memorie partajată, în timp ce în sistemele multiserver cuplate liber (clustere), un mecanism de mesaje poate fi utilizat în acest scop. Aplicația nu trebuie să țină cont de capacitățile de implementare ale arhitecturii hardware - metodele de manipulare a datelor și interfața software pentru accesarea bazei de date trebuie să rămână aceleași și la fel de eficiente.

Suportul de înaltă calitate pentru multiprocesare necesită ca serverul de baze de date să poată programa independent execuția multor interogări care urmează să fie servite, ceea ce ar asigura cea mai completă împărțire a resurselor de calcul disponibile între sarcinile serverului. Cererile pot fi procesate secvenţial de mai multe sarcini sau împărţite în subsarcini, care, la rândul lor, pot fi executate în paralel (Fig. 3). Acesta din urmă este mai optim deoarece implementarea corectă a acestui mecanism oferă beneficii care sunt independente de tipurile de cereri și aplicații. Eficiența procesării este foarte influențată de nivelul de granularitate al operațiunilor luate în considerare de sarcina de planificare. Cu o granularitate grosieră, de exemplu, la nivelul interogărilor SQL individuale, împărțirea resurselor sistemului informatic (procesoare, memorie, discuri) nu va fi optimă - sarcina va fi inactivă, așteptând sfârșitul operațiunilor I/O necesare pentru a finaliza interogarea SQL, cel puțin în coada de așteptare. Au existat alte interogări care au necesitat o muncă de calcul semnificativă. Cu o granularitate mai fină, partajarea resurselor are loc chiar și în cadrul unei singure interogări SQL, ceea ce este și mai evident atunci când mai multe interogări sunt procesate în paralel. Utilizarea unui planificator asigură că resursele mari ale sistemului sunt utilizate pentru a rezolva sarcinile reale de întreținere a bazei de date și minimizează timpul de nefuncționare.

Flexibilitate arhitecturală

Indiferent de gradul de portabilitate, suport pentru standarde, paralelism și alte calități utile, performanța unui SGBD, care are limitări arhitecturale încorporate semnificative, nu poate fi crescută în mod liber. Prezența unor restricții documentate sau practice privind numărul și dimensiunea obiectelor bazei de date și a bufferelor de memorie, numărul de conexiuni simultane, adâncimea recursiunii a procedurilor de apelare și a subinterogărilor sau declanșarea declanșatorilor bazei de date este aceeași limitare a aplicabilității SGBD, cum ar fi , de exemplu, imposibilitatea transferului pe mai multe platforme de calcul. Parametrii care limitează complexitatea interogărilor bazei de date, în special dimensiunile bufferelor dinamice și dimensiunea stivei pentru apelurile recursive, ar trebui să fie configurabili dinamic și să nu necesite oprirea sistemului pentru reconfigurare. Nu are rost să achiziționați un nou server puternic dacă așteptările nu pot fi îndeplinite din cauza limitărilor interne ale SGBD.

De obicei, blocajul este incapacitatea de a ajusta dinamic caracteristicile programelor de server de baze de date. Abilitatea de a determina parametrii din mers, cum ar fi cantitatea de memorie consumată, numărul de procesoare ocupate, numărul de fire de execuție paralele (fie fire reale, procese ale sistemului de operare sau procesoare virtuale) și numărul de fragmente de tabele de baze de date și indexurile, precum și distribuția acestora pe discuri fizice FĂRĂ oprirea și repornirea sistemului este o cerință care decurge din esența aplicațiilor moderne. În mod ideal, fiecare dintre acești parametri ar putea fi modificați dinamic în limitele specifice utilizatorului.

Oleg Spiryaev

Recent, au existat pretenții frecvente că serverele mid și high-end sunt înlocuite în mod activ de grupuri de servere entry-level, unite în rafturi sau clustere. Cu toate acestea, unii experți nu sunt de acord. Astfel, potrivit Dataquest, ponderea modelelor cu un preț de 500 de mii de dolari și mai mult (aceasta include servere SMP mid-range și high-end) în totalul vânzărilor de servere din 2000 până în 2002 a crescut de la 38 la 52%.

Alte date obținute de IDC indică creștere (cel puțin în ceea ce privește numărul de mașini) în sectorul modelelor de servere low-end - cu două procesoare. IDC mai prezice că în 2005 cel mai comun sistem de operare pentru servere care costă între 50.000 USD și 3 milioane USD va fi Unix. Comparând aceste date, este clar că serverele Unix mid-range și high-end vor rămâne platforma predominantă pentru centrele de date, dar vor fi completate de un număr tot mai mare de servere mai mici (de obicei cu dublu procesor).

Această tendință a apărut ca urmare a separării diferitelor straturi de calcul în centrele de date (Fig. 1). Nivelul 1, sau nivelul frontal, trece treptat la un model scalabil de servere mici, în timp ce nivelul 3 (nivelul bazei de date) este dominat de serverele extinse. Stratul 2 (stratul de aplicație) devine zona în care coexistă arhitecturile verticale și orizontale.

Arhitecturi verticale și orizontale

Să ne uităm la principalele diferențe dintre arhitecturile verticale și orizontale. Serverele de scalare sunt sisteme mari SMP (simetric multiprocessing sau shared memory) cu mai mult de patru unități centrale de procesare. Folosesc o singură copie a sistemului de operare pentru a controla toate procesoarele, memoria și componentele I/O. De obicei, toate aceste resurse sunt găzduite într-un singur rack sau dulap. Aceste servere se interconectează printr-o centrală sau un backplane de mare viteză, cu latență scăzută și acces coerent în cache. Puteți adăuga resurse instalând plăci de sistem suplimentare în interiorul dulapului. În sistemele cu arhitectură verticală (sau sistemele SMP), memoria este partajată, ceea ce înseamnă că toate procesoarele și componentele I/O au acces la toată memoria. Utilizatorul „vede” memoria ca pe un singur obiect mare.

În mod alternativ, scalarea orizontală, sistemele sunt conectate printr-o rețea sau grupate împreună. Interconexiunile folosesc de obicei tehnologii de rețea standard, cum ar fi Fast Ethernet, Gigabit Ethernet (GBE) și Scalable Coherent Interconnect (SCI), care oferă un debit mai mic și o latență mai mare decât sistemele verticale. Resursele în acest caz sunt distribuite între noduri, de obicei conținând de la unul la patru procesoare; Fiecare nod are propriul procesor și memorie și poate avea propriul subsistem I/O sau îl poate partaja cu alte noduri. Fiecare nod rulează o copie separată a sistemului de operare. Resursele sunt extinse prin adăugarea de noduri, dar nu prin adăugarea de resurse la un nod. Memoria în sistemele orizontale este distribuită, adică fiecare nod are propria memorie care este accesată direct de procesoarele și subsistemul I/O. Accesarea acestor resurse dintr-un alt nod este mult mai lent decât din nodul în care sunt situate. În plus, cu o arhitectură orizontală, nu există acces consecvent între noduri la memorie, iar aplicațiile utilizate consumă relativ puține resurse, așa că „se potrivesc” pe un singur nod și nu au nevoie de acces consistent. Dacă o aplicație necesită mai multe noduri, trebuie să ofere ea însăși acces consecvent la memorie.

Dacă un sistem orizontal îndeplinește cerințele aplicației, atunci această arhitectură este de preferat deoarece costurile sale de achiziție sunt mai mici. De obicei, costul de achiziție per procesor pentru sistemele orizontale este mai mic decât pentru sistemele verticale. Diferența de preț se datorează faptului că sistemele verticale folosesc caracteristici RAS (fiabilitate, disponibilitate, capacitate de service) mai puternice, precum și interconexiuni de înaltă performanță. Cu toate acestea, există o serie de restricții privind utilizarea sistemelor cu arhitectură orizontală. Mai jos vom discuta în ce condiții pot fi utilizate sistemele orizontale și când este necesară scalarea verticală.

Pe lângă un server SMP mare, arhitectura verticală include și grupuri de servere SMP mari utilizate pentru o singură aplicație la scară largă.

Serverele modulare sau blade introduse recent pe piață, echipate de obicei cu unul sau două procesoare, sunt un exemplu de servere orizontale. Aici clusterul este format din noduri mici, fiecare dintre ele având un server SMP entry-level cu un număr de procesoare centrale de la 1 la 4.

O altă modalitate de extindere este prin sisteme mari de calcul masiv paralel (MPP), care constau din multe procesoare mici instalate într-un singur cabinet, fiecare cu propria sa copie a sistemului de operare sau o copie a microkernel-ului OS. În prezent, sunt produse doar câteva sisteme MPP, care cel mai adesea reprezintă soluții specializate. Acestea sunt, de exemplu, sistemele Terradata fabricate de NCR, IBM RS/6000SP (SP-2) și HP Tandem non-stop.

Tabelul 1. Caracteristici ale arhitecturilor verticale și orizontale

Parametru	Sisteme verticale	Sisteme orizontale
Memorie	Partajat mare	Mic dedicat
Fluxuri	Multe fire interdependente	Multe fire independente
Interconexiuni	Intern strâns cuplat	Extern cuplat slab
RAS	Sistem unic RAS puternic	RAS puternic folosind replicare
Unități centrale de procesare	Multe standarde	Multe standarde
OS	O copie a sistemului de operare pentru multe procesoare centrale	Mai multe copii ale sistemului de operare (o copie pentru 1-4 procesoare)
Aspect	Într-un singur dulap	Plasarea unui număr mare de servere într-un rack
Densitate		Densitate mare de procesor pe unitate de suprafață
Echipamente	Standard și proiectat special	Standard
Scalare	Într-un singur șasiu de server	La scară multi-server
Extensie	Prin instalarea de componente suplimentare pe server	Prin adăugarea de noi noduri
Arhitectură	pe 64 de biți	32 și 64 de biți

Masa 1 permite o analiză comparativă a arhitecturilor verticale și orizontale.

• Sistemele verticale partajează memoria și oferă acces constant la cache.
• Sistemele verticale sunt ideale pentru fluxurile de sarcini care trebuie să comunice între ele.
• Sistemele verticale sunt caracterizate de funcții RAS puternice, iar în sistemele orizontale, disponibilitatea este implementată folosind replicarea masivă (mai multe noduri sunt conectate la un cluster, astfel încât defecțiunea unuia dintre ele are un impact redus asupra funcționării întregului sistem).
• În sistemele verticale, o copie a sistemului de operare acoperă toate resursele. Unele sisteme verticale, cum ar fi serverele midframe și high-end ale Sun Microsystems (Sun Fire 4800 până la Sun Fire 15K), pot fi împărțite în servere verticale mai mici.
• Sistemele verticale folosesc cât mai multe componente standard, dar unele componente cheie (cum ar fi interconexiunile) sunt special concepute.
• Sistemele verticale pot fi extinse prin instalarea de componente suplimentare în cadrul existent (procesoare mai puternice, memorie suplimentară, conexiuni I/O suplimentare și mai performante etc.). Sistemele orizontale sunt extinse prin adăugarea unui nod sau înlocuirea nodurilor vechi cu altele noi.
• Aproape toate sistemele verticale sunt pe 64 de biți, în timp ce sistemele orizontale pot fi fie pe 32 de biți, fie pe 64 de biți.

Sistemele verticale sunt mai potrivite pentru unele tipuri de aplicații și sistemele orizontale pentru altele, dar în multe cazuri alegerea optimă a arhitecturii depinde de dimensiunea problemei. În tabel 2 prezintă exemple de aplicații pentru care arhitectura verticală sau orizontală este optimă.

Tabel 2. Tipuri de aplicații pentru arhitecturi verticale și orizontale

Serverele mici și modulare sunt potrivite pentru aplicațiile care sunt apatride, la scară mică și ușor de replicat. Iar pentru aplicațiile care folosesc informații de stat și volume mari de date care necesită transfer intens de date în cadrul sistemului, serverele verticale sunt soluția ideală. Pe piața de calcul tehnic de înaltă performanță (HPTC), există multe aplicații în care firele depind unele de altele și fac schimb de date între ele. Există, de asemenea, aplicații care necesită cantități mari de memorie partajată. Serverele SMP mari sunt cele mai potrivite pentru aceste două tipuri de aplicații. Cu toate acestea, există și aplicații HPTC în care firele de execuție sunt independente și nu necesită cantități mari de memorie partajată. Astfel de aplicații pot fi partiționate, făcând clustere de servere mici ideale pentru rularea lor. La fel, unele aplicații comerciale sunt partiționate și beneficiază de servere orizontale, în timp ce altele nu pot fi partiționate, astfel încât serverele verticale sunt cea mai bună platformă pentru ele.

Factori care afectează performanța

Toate centrele mari de date sunt computere paralele. Aici, chiar și clusterele pot fi considerate ca un tip special de sisteme paralele. Performanța ridicată necesită un sistem echilibrat cu procesoare puternice, interconexiuni de mare viteză și I/O, un sistem de operare scalabil, aplicații optimizate și funcții RAS avansate.

Procesoare și interconexiuni de sistem

Procesoarele sunt cu siguranță o componentă esențială, dar determină doar parțial performanța generală a unui sistem. Este mai important să vă asigurați că procesoarele rulează la capacitate maximă. Un procesor puternic care este încărcat doar 50% va funcționa mai rău decât un procesor mai lent care este încărcat 80%.

În plus, pe măsură ce numărul de procesoare dintr-un sistem paralel crește, interconectările sistemului ies în prim plan mai degrabă decât puterea procesorului. Aceștia sunt responsabili pentru mutarea datelor de pe disc, din memorie și din rețea la procesor. Într-un cluster, interconectarea este o conexiune de rețea, cum ar fi Fast Ethernet sau Gigabit Ethernet. Interconexiunile clusterului mută datele între noduri, în timp ce interconexiunile sistemului mută datele într-un singur sistem. Dacă interconectarea este prea lentă, procesorul va fi inactiv în așteptarea datelor.

Interconexiunile de sistem sunt, de asemenea, folosite pentru a muta adresele de date, ceea ce este necesar pentru a sprijini coerența cache-ului. Dacă interconectarea sistemului este prea lentă în transmiterea adreselor de date, procesorul va fi din nou inactiv în așteptarea datelor deoarece trebuie să-și cunoască adresa pentru a le accesa. Interconexiunile rapide oferă un randament ridicat și o latență scăzută (timp redus de la momentul în care se face cererea de date până când datele încep să fie transmise).

Principala diferență tehnică dintre sistemele orizontale și verticale este debitul și latența interconexiunilor lor. Pentru interconexiunile cluster, debitul poate varia de la 125 MB/s pentru Fast Ethernet la 200 MB/s pentru SCI, iar latența poate varia de la 100 mii ns pentru GBE și până la 10 mii ns pentru SCI. Folosind interfața InfiniBand, este posibil să se implementeze interconexiuni mai rapide cu viteze de vârf variind de la aproximativ 250 MB/s pentru prima versiune și până la 3 GB/s pentru cele ulterioare.

Intrare și ieșire

I/O rapidă este necesară pentru ca interconectarea să poată prelua rapid datele de pe disc și rețea și să le transfere la procesoare. Un blocaj în subsistemul I/O poate avea un impact negativ asupra performanței chiar și a celor mai rapide interconexiuni și procesoare.

sistem de operare

Chiar și cel mai bun hardware este ineficient dacă sistemul de operare nu este suficient de scalabil. Pentru sistemele orizontale, scalabilitatea sistemului de operare nu este atât de importantă, deoarece nu mai mult de patru procesoare rulează pe un singur nod sau cu o copie separată a sistemului de operare.

Disponibilitatea sistemului

În general, disponibilitatea sistemului depinde în mare măsură de tipul de arhitectură. În sistemele SMP mari, funcționalitatea RAS este încorporată în sistem și completată cu failover pentru două până la patru noduri. În sistemele orizontale, RAS-ul nodurilor individuale este mai rău, dar îmbunătățirile acestor funcții sunt obținute prin replicarea nodurilor de mai multe ori.

Aplicații optimizate

Aplicațiile trebuie optimizate pentru arhitectura sistemului de calcul. Este cel mai ușor să scrieți și să optimizați aplicații pentru sistemele SMP. Aplicațiile comerciale majore sunt optimizate special pentru sistemele SMP și chiar au fost dezvoltate pe acestea, motiv pentru care SMP-urile au dominat piața sistemelor mid-range și high-end în ultimii zece ani.

Dimensiunea aplicației

După cum s-a menționat, sistemele SMP mari folosesc interconexiuni de mare viteză pentru a oferi o performanță suficientă a sistemului. Sistemele orizontale pot întâmpina probleme de performanță din cauza debitului scăzut și a latenței mari de interconectare în cazurile în care datele trebuie transferate frecvent între noduri. Cu toate acestea, unele aplicații nu necesită viteze mari de interconectare pentru a obține performanțe ridicate - de obicei aplicații mici și aplicații care pot fi reproduse cu ușurință (de exemplu, servere web, proxy, firewall-uri și servere de aplicații mici). În astfel de sisteme orizontale, fiecare nod îndeplinește o sarcină mică independent de munca tuturor celorlalți.

De exemplu, într-o arhitectură orizontală (sau memorie distribuită), patru noduri de procesor (fiecare cu RAM separată și subsistem I/O dedicat sau partajat) pot utiliza o interconexiune de rețea, cum ar fi Gigabit Ethernet. Acest mediu de calcul rulează trei tipuri de sarcini de lucru. Cea mai mică sarcină se potrivește pe un singur nod, dar pe măsură ce crește, sunt necesare mai multe noduri pentru ao finaliza. Potrivit experților, atunci când se execută o sarcină pe mai multe noduri, performanța se deteriorează semnificativ din cauza interconexiunilor lente între noduri. Sarcinile de lucru mici care nu trebuie să comunice între ele funcționează bine cu o arhitectură orizontală, dar rularea sarcinilor de lucru la scară largă pe aceasta prezintă provocări.

O configurație mare de sistem SMP poate include, de exemplu, până la 100 de procesoare, 576 GB de memorie partajată și interconexiuni de mare viteză. Un astfel de sistem poate gestiona toate tipurile de sarcini de lucru deoarece nu există comunicare între noduri și comunicare eficientă între procese. Toate unitățile centrale de procesare pot accesa simultan toate discurile, toate conexiunile de memorie și de rețea - aceasta este o caracteristică cheie a sistemelor SMP (sau a sistemelor verticale).

Adesea apare întrebarea cu privire la oportunitatea plasării sarcinilor mici pe SMP-uri mari. Deși acest lucru este posibil din punct de vedere tehnic, din punct de vedere economic această abordare nu este justificată. Pentru SMP-urile mari, costul de achiziție per procesor este mai mare decât pentru sistemele mici. Prin urmare, dacă o aplicație poate rula pe un nod mic (sau mai multe noduri mici) fără probleme majore de management, scalarea este o alegere mai bună pentru implementare. Dar dacă aplicația este prea mare pentru a rula pe un nod mic (sau mai multe astfel de noduri), atunci un server SMP mare va fi cea mai bună opțiune atât în ​​ceea ce privește performanța, cât și administrarea sistemului.

Performanță la nivel de bază de date

Principala întrebare aici este de a compara performanța unui singur server SMP mediu și mare cu un cluster de servere mici (nu mai mult de patru procesoare).

Atunci când discută despre scalabilitate, companiile producătoare folosesc o serie de termeni tehnici. Astfel, creșterea performanței (Speedup) pentru SMP este definită ca raportul dintre vitezele de execuție a aplicației pe mai multe procesoare și pe unul. Accelerarea liniară înseamnă, de exemplu, că pe 40 de procesoare o aplicație rulează de 40 de ori (40x) mai rapid decât pe unul. Creșterea performanței nu depinde de numărul de procesoare, adică pentru o configurație de 24 de procesoare va fi aceeași ca și pentru 48 de procesoare. Creșterea performanței clusterului (Cluster speedup) diferă doar prin aceea că, atunci când se calculează, se ia numărul de noduri, nu și numărul de procesoare. La fel ca creșterea performanței SMP, creșterea performanței clusterului rămâne constantă în diferite numere de noduri.

Eficiența scalării caracterizează capacitatea aplicațiilor, în special a celor grupate, de a scala pe un număr mare de noduri. În general, se crede că eficiența scalării depinde de numărul de noduri care participă la măsurare. Eficiența de scalare SMP este creșterea performanței împărțită la numărul de procesoare, iar eficiența clusterului este creșterea performanței clusterului împărțit la numărul de noduri din acesta. Trebuie să înțelegeți ce înseamnă acești parametri, astfel încât să nu obțineți o imagine greșită, deoarece eficiența de scalare de 90% pe două noduri nu este aceeași cu eficiența de scalare de 90% pe patru noduri.

În fig. Figura 2 prezintă trei grafice: scalabilitate liniară ideală, scalabilitate a unui server SMP cu 24 de procesoare la 95% și scalabilitate a unui cluster de două servere cu 4 procesoare la 90%. Se poate observa că există anumite limitări privind scalabilitatea bazelor de date în clustere (cu scalare orizontală). Înlănțuirea mai multor servere mici împreună nu oferă scalabilitatea necesară pentru aplicațiile medii până la mari. Motivul pentru aceasta este limitările lățimii de bandă ale interconexiunilor intra-cluster, sarcina suplimentară pentru software-ul bazei de date asociat cu managementul cluster-ului și dificultatea de a scrie aplicații pentru mediile cluster cu memorie distribuită.

Rezultatele de referință publicate arată, de exemplu, că Oracle9i RAC (Real Application Cluster) are un câștig de performanță de 1,8 și o eficiență de scalare de 90%. Această eficiență de scalabilitate poate părea destul de ridicată, dar, de fapt, scalabilitatea de 90% pentru patru noduri este ineficientă în comparație cu rezultatele serverelor SMP mari.

Performanță la nivel de aplicație

Stratul de aplicație într-un centru de date cu trei niveluri este foarte diferit de stratul de bază de date. De obicei, aplicațiile de la acest nivel sunt apatride - cu alte cuvinte, nu sunt stocate date pe serverul însuși sau doar o mică parte din acestea sunt stocate. Acest strat conține reguli de afaceri pentru serviciile de aplicații. Tranzacțiile ajung la nivelul aplicației și sunt procesate de acesta. Când datele trebuie scrise sau citite, tranzacțiile sunt trecute la nivelul bazei de date. Serverele de aplicații tind să consolideze conexiunile la baze de date deoarece un număr mare de conexiuni au un impact negativ asupra performanței.

În cele mai multe cazuri, nivelul serverului de aplicații necesită mult mai multe procesoare decât nivelul bazei de date pentru fiecare serviciu de aplicație individual. De exemplu, în cazul SAP R/3, acest raport este de aproximativ 10 procesoare pentru fiecare procesor de bază de date, adică dacă SAP R/3 necesită 20 de procesoare pentru nivelul de bază de date, atunci ar trebui să existe aproximativ 200 de procesoare pentru nivelul de aplicație. Întrebarea este ce este mai profitabil de implementat - 100 de servere cu două procesoare sau zece servere cu 20 de procesoare. În mod similar, la Oracle, raportul dintre procesoarele de aplicații și procesoarele de baze de date este de aproximativ 5 la 1.

Se crede că serverele de aplicații nu trebuie să fie distribuite pe mai multe noduri. Copii multiple ale aplicației software pot fi distribuite pe diferite servere fizice de diferite capacități sau pe domenii dinamice ale serverelor mari.

Numărul de procesoare necesare pentru stratul de aplicație va fi aproximativ același, indiferent de arhitectura computerului. Costul achiziționării de hardware și software pentru o arhitectură orizontală va fi mai mic, deoarece costul pe procesor este mai mic în acest caz. În cele mai multe cazuri, sistemele orizontale pot oferi performanța necesară pentru a îndeplini acordul privind nivelul de servicii. Costurile asociate cu achiziționarea de licențe software sunt aproximativ aceleași pentru ambele arhitecturi.

În același timp, costurile de gestionare și întreținere a infrastructurii pentru o arhitectură orizontală pot fi mai mari. Când este implementat pe sisteme orizontale, sunt utilizate mai multe copii ale sistemului de operare și ale software-ului serverului de aplicații. Costurile de întreținere a infrastructurii cresc de obicei proporțional cu numărul de copii ale sistemului de operare și ale aplicațiilor. În plus, cu o arhitectură orizontală, backup-ul și recuperarea în caz de dezastru devin descentralizate, iar infrastructura de rețea este mai dificil de gestionat.

Costul administrării sistemului este greu de măsurat. De obicei, modelele care compară implementările de servere de aplicații orizontale și verticale arată că gestionarea mai puține servere mai puternice (servere verticale) este mai puțin costisitoare decât gestionarea multor servere mai mici. În general, atunci când aleg tipul de arhitectură pentru implementarea unui strat de aplicație, managerii IT ar trebui să ia în considerare cu atenție costul achiziției hardware.

Impactul arhitecturii asupra disponibilității

Disponibilitatea este critică pentru centrele de date moderne - serviciile de aplicații trebuie să fie disponibile 24x7x365 (24 de ore pe zi, 7 zile pe săptămână, 365 de zile pe an). În funcție de nevoile unui anumit centru de date, sunt utilizate diferite scheme de înaltă disponibilitate. Pentru a selecta o soluție specifică, este necesar să se determine timpul de nefuncționare acceptabil (planificat și neplanificat). În fig. Figura 3 arată modul în care procentul de disponibilitate afectează durata timpului de nefuncționare.

Pe măsură ce cerințele de disponibilitate cresc, la fel crește și costul soluției. Managerii centrelor de date trebuie să stabilească ce combinație de cost, complexitate și disponibilitate îndeplinește cel mai bine cerințele de nivel de serviciu. Centrele de date care necesită o disponibilitate de aproximativ 99,95% pot implementa un singur server SMP cu caracteristici RAS, cum ar fi redundanța hardware completă și întreținerea online.

Cu toate acestea, pentru a obține o disponibilitate mai mare de 99,95%, va fi necesar un cluster. Software-ul Sun Cluster cu failover HA (High Availability) oferă o disponibilitate de 99,975%. HA failover-ul folosește un server primar și un hot standby; Dacă serverul principal eșuează, serverul de rezervă preia încărcarea acestuia. Timpul necesar pentru a reporni un serviciu variază în funcție de aplicație și poate dura câteva minute, în special pentru aplicațiile de baze de date care necesită rollback-uri mari de date pentru a restabili tranzacțiile.

Dacă un timp de nefuncționare de câteva minute este inacceptabil pentru un centru de date, un sistem activ-activ poate fi o soluție, în care aplicația este implementată pe două sau mai multe noduri, astfel încât dacă unul dintre ele eșuează, celelalte vor continua să ruleze aplicația. Ca urmare, întreruperea va fi foarte scurtă (unii clienți raportează că durează mai puțin de 1 minut), uneori este posibil ca utilizatorul să nu observe nici măcar defecțiunea nodului.

Serverele verticale oferă disponibilitate ridicată prin încorporarea multor caracteristici RAS într-un singur server pentru a minimiza timpul de nefuncționare planificat și neplanificat. În serverele orizontale, funcțiile care asigură un nivel ridicat de RAS sunt implementate nu la nivelul unui server individual, ci prin duplicarea și plasarea mai multor servere. Datorită diferitelor implementări ale caracteristicilor și interconexiunilor RAS, serverele orizontale sunt de obicei mai ieftine pe procesor.

Pentru o arhitectură cu trei niveluri, un bun exemplu de înaltă disponibilitate orizontală este implementarea serverelor Web. Puteți implementa multe servere mici, fiecare cu o copie separată a software-ului serverului Web instalată. Dacă un server Web se defectează, tranzacțiile sale sunt redistribuite între serverele sănătoase rămase. În cazul serverelor de aplicații, acestea pot fi găzduite atât pe servere orizontale, cât și pe cele verticale, iar disponibilitatea ridicată se realizează prin redundanță. Indiferent dacă implementați câteva servere SMP mari sau multe servere mai mici, redundanța rămâne modalitatea principală de a obține un RAS ridicat la nivel de aplicație.

Cu toate acestea, la nivelul bazei de date situația se schimbă. Bazele de date sunt cu stare și prin natura lor necesită, în majoritatea cazurilor, ca datele să fie partiționate și accesibile de la toate procesoarele/nodurile. Aceasta înseamnă că pentru disponibilitate ridicată cu redundanță, trebuie să utilizați software de clustering, cum ar fi Sun Cluster sau Oracle9i RAC (pentru disponibilitate foarte ridicată).

concluzii

Atât arhitecturile verticale, cât și cele orizontale își au nișa în centrul de date de astăzi. În timp ce astăzi se pune accentul pe noile tehnologii, cum ar fi serverele modulare și bazele de date paralele, piața rămâne în mare căutare pentru servere de gamă medie și de vârf.

Sistemele verticale și orizontale pot folosi același software, sistem de operare și chiar aceleași procesoare. Principala diferență care afectează prețul și performanța este interconexiunile utilizate în fiecare arhitectură. Serverele orizontale folosesc interconexiuni externe slab cuplate, în timp ce serverele verticale folosesc interconexiuni strâns cuplate care oferă rate mai mari de transfer de date.

Pentru front-end, serverele orizontale oferă de obicei soluția optimă în ceea ce privește performanța, costul total de achiziție și disponibilitatea. Pentru stratul de aplicație, atât arhitecturile verticale, cât și cele orizontale pot fi utilizate eficient. Pentru nivelul bazei de date, soluția optimă este utilizarea serverelor verticale, indiferent de nivelul de disponibilitate necesar.

Alexander Makarov, dezvoltatorul popularului framework Yii, va vorbi despre scalarea proiectelor web.

Scalare este capacitatea de a extinde sistemul pentru a procesa mai mult trafic fără a pierde calitățile utilizatorului: viteză și capacitate de răspuns.

Există două tipuri de scalare: verticală (mai multă memorie, disc, procesor mai bun) și orizontală (mai multe servere în cluster).

• De ce este nevoie dacă totul funcționează așa?
• Când? Monitorizare, decizii pripite, optimizare și viață cu un singur server.
• Schema tipica.
• Echilibrarea sarcinii.
• Care sunt problemele din partea aplicațiilor în general?
• De ce PHP este atât de bun pentru scalare.
• Sesiuni.
• Bază de date.
• Fișiere.
• Dar statisticile?

Alexander Makarov (Yii, Stay.com)

Buna ziua! Sunt Alexander Makarov și poate mă cunoașteți din cadrul Yii - sunt unul dintre dezvoltatorii acestuia. Am și un job full-time – iar acesta nu mai este un startup – Stay.com, care se ocupă de călătorii.

Astăzi voi vorbi despre scalarea orizontală, dar în termeni foarte, foarte generali.

Ce este scalarea, oricum? Aceasta este o oportunitate de a crește productivitatea proiectului într-un timp minim prin adăugarea de resurse.

De obicei, scalarea nu implică rescrierea codului, ci fie adăugarea de servere, fie creșterea resurselor unuia existent. Acest tip include scalarea verticală și orizontală.

Verticală este atunci când sunt adăugate mai multe RAM, discuri etc. pe un server deja existent, iar orizontală este atunci când pun mai multe servere în centrele de date, iar serverele de acolo deja interacționează cumva.

Cea mai tare întrebare pe care o pun este: de ce este nevoie dacă totul funcționează bine pentru mine pe un singur server? De fapt, trebuie să verificăm ce se va întâmpla. Adică funcționează acum, dar ce se va întâmpla mai târziu? Există două utilități minunate - ab și siege, care par să ajungă din urmă cu un nor de utilizatori ai concurenților care încep să lovească serverul, încearcă să solicite pagini, să trimită unele solicitări. Trebuie să le spui ce să facă, iar utilitățile generează rapoarte de genul acesta:

Principalii doi parametri: n - numărul de solicitări care trebuie făcute, c - numărul de solicitări simultane. Astfel ei verifică concurența.

La ieșire obținem RPS, adică numărul de solicitări pe secundă pe care serverul este capabil să le proceseze, din care va deveni clar câți utilizatori poate gestiona. Totul, desigur, depinde de proiect, variază, dar de obicei necesită atenție.

Mai există un parametru - Timpul de răspuns - timpul de răspuns în care serverul a servit în medie o pagină. Variază, dar se știe că aproximativ 300 ms sunt norma, iar orice mai mare nu este foarte bine, pentru că acești 300 ms sunt procesați de server, iar la aceasta se adaugă alți 300-600 ms, care sunt procesați de client. , adică În timp ce totul se încarcă - stiluri, imagini și restul - trece și timpul.

Se întâmplă că, de fapt, nu este nevoie să vă faceți griji cu privire la scalare - mergem la server, actualizăm PHP, obținem o creștere de 40% a performanței și totul este cool. Apoi, configurăm Opcache și îl reglam. Opcache, apropo, este reglat în același mod ca APC, cu un script care poate fi găsit în depozitul lui Rasmus Lerdorf și care arată hit-uri și rateuri, unde hit-urile sunt de câte ori PHP a mers în cache, iar ratele sunt de câte ori a mers la sistemul de fișiere obține fișiere. Dacă rulăm întregul site sau rulăm un fel de crawler pe link-uri sau îl introducem manual, atunci vom avea statistici despre aceste accesări și rateuri. Dacă există 100% accesări și 0% rateuri, atunci totul este în regulă, dar dacă există erori, atunci trebuie să alocăm mai multă memorie, astfel încât tot codul nostru să se potrivească în Opcache. Aceasta este o greșeală comună care se face - se pare că Opcache este acolo, dar ceva nu funcționează...

De asemenea, deseori încep să se extindă, dar nu se uită deloc la asta, motiv pentru care totul funcționează încet. Cel mai adesea intrăm în baza de date, uite - nu există indici, punem indici - totul funcționează imediat, suficient pentru încă 2 ani, frumusețe!

Ei bine, trebuie să activați și memoria cache, să înlocuiți apache cu nginx și php-fpm pentru a economisi memorie. Totul va fi grozav.

Toate cele de mai sus sunt destul de simple și vă oferă timp. Este timp pentru faptul că într-o zi acest lucru nu va fi suficient și trebuie să ne pregătim pentru asta acum.

Cum, în general, puteți înțelege care este problema? Fie că aveți deja o sarcină mare, iar acesta nu este neapărat un număr nebun de solicitări etc., este atunci când proiectul dvs. nu poate face față sarcinii și acest lucru nu mai poate fi rezolvat în moduri banale. Trebuie să crești fie mai lat, fie mai sus. Trebuie făcut ceva și, cel mai probabil, este puțin timp pentru asta; trebuie inventat ceva.

Prima regulă este că nu trebuie să faci niciodată nimic orbește, de exemplu. avem nevoie de o monitorizare excelentă. În primul rând, câștigăm timp pentru o optimizare evidentă, cum ar fi activarea unui cache sau stocarea în cache a paginii de pornire etc. Apoi punem la punct monitorizarea, ne arată ce lipsește. Și toate acestea se repetă de multe ori - nu puteți opri niciodată monitorizarea și îmbunătățirea.

Ce poate arăta monitorizarea? Ne putem odihni de disc, adică. la sistemul de fișiere, la memorie, la procesor, la rețea... Și se poate ca totul să pară mai mult sau mai puțin, dar apar niște erori. Toate acestea se rezolvă în moduri diferite. Puteți rezolva o problemă cu, de exemplu, un disc adăugând un nou disc pe același server sau puteți instala un al doilea server care se va ocupa doar de fișiere.

La ce ar trebui să fiți atenți acum când monitorizați? Acest:

1. accesibilitate, adică dacă serverul este viu sau nu;
2. lipsa resurselor de disc, procesor etc.;
3. erori.

Cum să monitorizezi toate acestea?

Iată o listă de instrumente grozave care vă permit să monitorizați resursele și să afișați rezultatele într-un mod foarte convenabil:

• Monit - http://mmonit.com/monit/
• Zabbix - http://www.zabbix.com/
• Munin - http://munin-monitoring.org/
• Nagios - http://www.nagios.org/
• ServerDensity - https://www.serverdensity.com/

Primele 4 instrumente pot fi instalate pe server, sunt puternice și cool. Și ServerDensity este găzduit de cineva, de exemplu. plătim bani pentru el și poate colecta toate datele de pe servere și le poate afișa pentru analiză.

Există două servicii bune pentru monitorizarea erorilor:

• Rollbar - https://rollbar.com/
• Sentry - https://getsentry.com/

De obicei monitorizăm erori de genul acesta - fie scriem totul în jurnal și apoi ne uităm la el, fie în plus începem să trimitem e-mailuri sau SMS-uri către dezvoltatori.Totul este normal, dar de îndată ce avem o mulțime de oameni vine la serviciu și există un fel de - această eroare, începe să se repete de un număr foarte mare de ori, e-mailul începe să facă spam nebunește sau, în general, devine plin, sau dezvoltatorul pierde complet atenția și începe să ignore Literele.Serviciile de mai sus preiau și colectează erori de același tip într-un singur pachet mare, plus ele numără de câte ori au apărut erori recent și ridică automat întreaga problemă în priorități.

Sentry poate fi instalat pe serverul dvs., există un cod sursă, dar Rollbar nu, dar Rollbar este mai bine pentru că încasează bani pentru numărul de erori, adică. îi încurajează să le corecteze.

În ceea ce privește notificările, vă repet că nu trebuie să trimiteți spam, deoarece vă va pierde atenția.

Ce, în general, trebuie analizat?

RPS și timp de răspuns - dacă timpul nostru de răspuns începe să scadă, atunci trebuie să facem ceva.

Numărul de procese, fire și dimensiuni de cozi - dacă toate acestea încep să se înmulțească, să se înfunde etc., atunci ceva nu este în regulă aici, trebuie să-l analizăm mai detaliat și să schimbăm cumva infrastructura.

De asemenea, merită să te uiți la analiza de afaceri. Google Analytics este excelent pentru tipurile de site-uri web, iar mixpanel este excelent pentru înregistrarea evenimentelor; funcționează pe aplicații desktop, aplicații mobile și web. Puteți scrie pe baza unora dintre propriile date, dar aș recomanda servicii gata făcute. Ideea este că monitorizarea noastră poate arăta că serviciul este activ, că totul funcționează, că timpul general de răspuns este normal, dar când, să zicem, începem să urmărim înregistrările în mixpanel, arată că, cumva, nu sunt suficiente. În acest caz, trebuie să vă uitați la cât de repede sunt procesate anumite evenimente și pagini și care sunt problemele. Proiectul ar trebui să fie întotdeauna „atârnat” cu analize pentru a ști întotdeauna ce se întâmplă și să nu funcționeze orbește.

Sarcina, în general, apare fie planificată, fie nu, poate apărea treptat, poate nu treptat:

Cum să faci față sarcinii? Afacerile decid totul și doar prețul problemei este important. Important:

1. pentru ca serviciul să funcționeze,
2. ca sa nu fie foarte scump si sa nu strice firma.

Restul nu este foarte important.

Dacă este mai ieftin să profilezi, să optimizați, să scrieți în cache, să corectați unele configurații, atunci acest lucru ar trebui făcut, fără să vă gândiți la scalarea sau achiziționarea de hardware suplimentar etc. Dar se întâmplă ca hardware-ul să devină mai ieftin decât munca unui programator, mai ales dacă programatorii sunt foarte pricepuți. În acest caz, scalarea începe deja.

În imagine, lucrul albastru este internetul de la care provin cererile. Este instalat un echilibrator, singura sarcină a căruia este să distribuie cererile către servere front-end separate, să accepte răspunsuri de la acestea și să le trimită clientului. Ideea aici este că 3 servere pot procesa (ideal) de 3 ori mai multe cereri, excluzând orice costuri generale pentru rețea și munca echilibratorului în sine.

Ce ne oferă asta? Capacitatea menționată mai sus de a procesa mai multe cereri, precum și fiabilitatea. Dacă în schema tradițională nginx sau o aplicație se blochează, sau discul are probleme etc., atunci totul se oprește. Aici, dacă unul dintre front-end-urile noastre eșuează, atunci este în regulă, cel mai probabil echilibrantul va înțelege acest lucru și va trimite cereri celor 2 servere rămase. S-ar putea să fie puțin mai lent, dar asta nu este mare lucru.

În general, PHP este excelent pentru scalare, deoarece urmează principiul Share nimic în mod implicit. Aceasta înseamnă că dacă luăm, să zicem, Java pentru web, atunci aplicația pornește acolo, citește tot codul, scrie cât mai multe date posibil în memoria programului, totul se învârte acolo, funcționează, se petrece foarte puțin timp la cerere. , foarte puține resurse suplimentare. Cu toate acestea, există o ambuscadă - pentru că. Aplicația este scrisă în așa fel încât trebuie să ruleze pe o singură instanță, să fie stocată în cache, să fie citită din propria memorie, apoi nu va ieși nimic bun la scalare. Dar în PHP nu există nimic comun în mod implicit și asta este bine. Orice dorim să împărtășim, îl punem în memcached și memcached poate fi citit de pe mai multe servere, așa că totul este grozav. Acestea. Cuplarea liberă este realizată pentru stratul de server de aplicații. Acest lucru este minunat.

Cum se echilibrează sarcina în general?

Cel mai adesea acest lucru a fost făcut de Squid sau HAProxy, dar asta a fost înainte. Acum autorul lui nginx a luat și a partiționat echilibrerul din nginx+ în nginx, așa că acum poate face tot ce făceau Squid sau HAProxy. Dacă începe să eșueze, puteți instala un echilibrator hardware scump.

Problemele pe care le rezolvă echilibrerul sunt cum să alegeți un server și cum să stocați sesiunile? A doua problemă este pur PHP, iar serverul poate fi selectat fie unul câte unul din listă, fie după geografia unor IP-uri, fie după unele statistici (nginx acceptă cele mai puțin conectate, adică care server are mai puține conexiuni, el va arunca este asupra lui). Putem scrie un cod pentru echilibrator care va alege cum ar trebui să funcționeze.

Ce se întâmplă dacă lovim un echilibrator?

Există un astfel de lucru ca DNS Round robin - acesta este un truc minunat care ne permite să nu cheltuim bani pe un echilibrator hardware. Ce facem? Luăm un server DNS (de obicei nimeni nu găzduiește un server DNS, este scump, nu foarte fiabil, dacă eșuează, atunci nu va ieși nimic bun, toată lumea folosește un fel de companie), înregistrăm mai mult de un server în A înregistrare, dar câteva. Acestea vor fi înregistrări A de la diferiți echilibratori. Când browserul merge acolo (de fapt, nu există garanții, dar toate browserele moderne procedează astfel), selectează una câte una o adresă IP din A-records și ajunge fie pe un echilibrator, fie pe al doilea. Sarcina poate să nu se împrăștie uniform, desigur, dar cel puțin se răspândește și balansierul se poate descurca puțin mai mult.

Ce să faci cu sesiunile?

Avem sesiuni în fișiere în mod implicit. Nu este cazul, deoarece fiecare dintre serverele noastre front-end va păstra sesiunile în propriul sistem de fișiere, iar utilizatorul poate merge mai întâi la unul, apoi la al doilea, apoi la al treilea, adică. va pierde ședințe de fiecare dată.

Există o dorință evidentă de a crea un sistem de fișiere comun și de a conecta NFS. Dar nu trebuie să faci asta - este teribil de lent.

Îl poți scrie în baza de date, dar nici nu merită, pentru că Baza de date nu este optimă pentru acest loc de muncă, dar dacă nu ai altă opțiune, atunci, în principiu, se va descurca.

Puteți scrie în memcached, dar foarte, foarte atent, deoarece memcached este, până la urmă, un cache și tinde să fie șters de îndată ce are puține resurse sau nu există unde să scrie chei noi - atunci începe să piardă cele vechi fără avertisment, sesiunile încep să se piardă. Trebuie fie să monitorizați acest lucru, fie să alegeți același Redis.

Redis este o soluție bună. Ideea este că avem Redis pe un server separat, iar toate front-end-urile noastre se grăbesc acolo și încep să-și citească sesiunile de la Redis. Dar Redis are un singur thread și, mai devreme sau mai târziu, putem avea cu adevărat probleme. Apoi creează sesiuni sticky. același nginx este instalat și este informat că trebuie să facă sesiuni, astfel încât atunci când utilizatorul vine la server și primește un cookie de sesiune, astfel încât ulterior să ajungă doar la acest server.De cele mai multe ori, acest lucru se face folosind un hash IP Se pare că, dacă Redis este pe fiecare instanță, în consecință, există sesiuni separate acolo, iar viteza de citire-scriere va fi mult mai bună.

Dar cookie-uri? Puteți scrie în cookie-uri, nu va exista stocare, totul este în regulă, dar, în primul rând, încă trebuie să punem datele sesiunii undeva și, dacă începem să scriem în cookie-uri, s-ar putea să crească și să nu se potrivească în stocare, dar , în al doilea rând, doar ID-urile pot fi stocate în cookie-uri și va trebui totuși să contactăm baza de date pentru unele date de sesiune. În principiu, acest lucru este normal, rezolvă problema.

Există un lucru grozav - un proxy pentru memcached și Redis:

Se pare că susțin paralelizarea din cutie, dar acest lucru se face într-un mod care nu aș spune că este foarte optim. Dar acest lucru - twemproxy - funcționează aproximativ ca nginx cu PHP, adică. de îndată ce se primește răspunsul, trimite imediat datele și închide conexiunea în fundal, se dovedește mai rapid și consumă mai puține resurse. Lucru foarte bun.

Foarte des această eroare de „ciclare” apare atunci când încep să scrie, de genul „Nu am nevoie de sesiuni! Acum voi face un token minunat care va fi transferat înainte și înapoi”... Dar, dacă te gândești bine, atunci aceasta este din nou o sesiune.

PHP are un astfel de mecanism ca un handler de sesiune, de exemplu. putem pune propriul nostru handler și scrie în cookie-uri, în baza de date, în Redis - oriunde, și toate acestea vor funcționa cu pornirea sesiunii standard etc.

Sesiunile ar trebui să fie închise folosind această metodă minunată.

De îndată ce am citit totul din sesiune, nu vom scrie acolo, trebuie să fie închis, pentru că sesiunea este adesea blocată. De fapt, ar trebui blocat, pentru că fără blocare vor fi probleme cu concurența. Acest lucru este vizibil imediat pe fișiere; pe alte stocări, blocantele nu sunt disponibile pentru întreg fișierul simultan, iar acest lucru este puțin mai ușor.

Ce să faci cu fișierele?

Le poți trata în două moduri:

1. o soluție specializată care oferă o abstractizare și lucrăm cu fișiere ca sistem de fișiere. Este ceva de genul NFS, dar NFS nu este necesar.
2. „sharding” folosind PHP.

Soluțiile specializate din ceea ce funcționează cu adevărat este GlusterFS. Acesta este ceva pe care îl puteți seta singur. Funcționează, e rapid, oferă aceeași interfață ca NFS, doar că funcționează la o viteză normală tolerabilă.

Și Amazon S3 este, dacă te afli în cloudul Amazon, și un sistem de fișiere bun.

Dacă implementați din partea PHP, există o minunată bibliotecă Flysystem, acoperită cu teste excelente, poate fi folosită pentru a lucra cu tot felul de sisteme de fișiere, ceea ce este foarte convenabil. Dacă scrieți imediat toate lucrările cu fișiere cu această bibliotecă, atunci transferul de la sistemul de fișiere local pe Amazon S3 sau altele va fi simplu - rescrieți linia din configurație.

Cum functioneaza? Un utilizator descarcă un fișier dintr-un browser, poate fie să meargă la front-end și de acolo să se răspândească pe serverele de fișiere, fie pe fiecare server de fișiere este creat un script de încărcare și fișierul este încărcat direct în sistemul de fișiere. Ei bine, în paralel, se scrie în baza de date ce fișier este pe ce server și îl putem citi direct de acolo.

Cel mai bine este să distribuiți fișiere cu nginx sau Varnish, dar este mai bine să faceți totul cu nginx, pentru că cu toții îl iubim și îl folosim - se poate descurca, este bine.

Ce se întâmplă cu baza noastră de date?

Dacă totul se reduce la cod PHP, facem o grămadă de front-end-uri și totuși apelăm la o singură bază de date - va face față pentru o perioadă destul de lungă. Dacă încărcarea nu este groaznică, atunci baza de date trăiește bine. De exemplu, am făcut JOIN-uri de 160 de milioane de rânduri într-un tabel și totul a fost grozav, totul a mers bine, dar acolo, totuși, ar trebui să fie alocată mai multă RAM pentru buffer-uri, pentru cache...

Ce să facem cu baza de date dacă ne întâlnim cu ea? Există tehnici precum replicarea. De obicei, există replicare master-slave și există replicare master-master. Puteți face replicarea manual, puteți face sharding și puteți face partiționare.

Ce este un sclav stăpân?

Un server este selectat ca principal și o grămadă de servere sunt selectate ca secundare. Se scrie la cea principală, și putem citi de la stăpân, sau putem și de la sclavi (în imagine săgețile roșii sunt ceea ce scriem, cele verzi sunt ceea ce citim). Într-un proiect tipic, avem mult mai multe citiri decât scrieri. Sunt proiecte atipice.

În cazul unui proiect tipic, un număr mare de sclavi vă permite să eliberați atât masterul, cât și, în general, să creșteți viteza de citire.

Acest lucru oferă, de asemenea, toleranță la erori - dacă unul dintre sclavi eșuează, atunci nu trebuie făcut nimic. Dacă stăpânul cade, putem face rapid pe unul dintre sclavi stăpân. Adevărat, acest lucru nu se face de obicei automat, aceasta este o situație de urgență, dar există o posibilitate.

Ei bine, și copii de rezervă. Toată lumea face backup-uri de baze de date diferit, uneori acest lucru se face cu un dump MySQL și îngheață întregul proiect, ceea ce nu este foarte bun. Dar dacă faci o copie de rezervă de la un sclav, după ce ai oprit-o mai întâi, utilizatorul nu va observa nimic. Acest lucru este minunat.

În plus, se pot face calcule grele pe sclavi pentru a nu afecta baza principală, proiectul principal.

Există un astfel de lucru ca diviziunea citire/scriere. Există 2 pool-uri de servere - master, slave, conexiune la cerere, iar logica de selecție a conexiunii variază. Ideea este că, dacă citim întotdeauna de la sclavi și scriem întotdeauna stăpânului, atunci va exista o mică ambuscadă:

acestea. replicarea nu are loc imediat și nu există nicio garanție că s-a finalizat atunci când facem orice cerere.

Există două tipuri de mostre:

1. pentru citire sau ieșire;
2. pentru înregistrare, adică atunci când am selectat ceva și apoi acest lucru trebuie schimbat și scris înapoi.

Dacă eșantionul este pentru scriere, atunci putem fie citi întotdeauna de la master și scrie pe master, fie putem executa „SHOW SLAVE STATUS” și ne uităm la Seconds_Behind_Master acolo (pentru PostgreSQL există și o super-interogare în imagine) - ne va arăta numărul. Dacă este 0 (zero), atunci totul a fost deja replicat și puteți citi în siguranță de la slave. Dacă numărul este mai mare decât zero, atunci trebuie să ne uităm la valoare - fie ar trebui să așteptăm puțin și apoi să citim de la sclav, fie să citim imediat de la master. Dacă avem NULL, înseamnă că nu l-am replicat încă, ceva s-a blocat și trebuie să ne uităm la jurnalele.

Motivele pentru o astfel de întârziere sunt fie o rețea lentă, fie o replică nu poate face față, fie prea mulți sclavi (mai mult de 20 per 1 master). Dacă rețeaua este lentă, atunci este clar că trebuie să fie cumva accelerată, colectată în centre de date unice etc. Dacă o replică eșuează, atunci trebuie să adăugați replici. Dacă sunt prea mulți sclavi, atunci trebuie să veniți cu ceva interesant, cel mai probabil, să creați un fel de ierarhie.

Ce este un maestru meșter?

Aceasta este o situație în care există mai multe servere și totul este scris și citit peste tot. Avantajul este că poate fi mai rapid, este tolerant la greșeli. În principiu, totul este la fel ca pentru sclavi, dar logica este în general simplă - pur și simplu selectăm o conexiune aleatorie și lucrăm cu ea. Dezavantaje: întârzierea de replicare este mai mare, există șansa de a obține un fel de date inconsecvente și, dacă are loc un fel de defecțiune, atunci începe să se răspândească în toate master-urile și nimeni nu știe care master este normal, care este. rupt... Aici începe totul să se replice într-un cerc, adică. Înfunda foarte bine rețeaua. În general, dacă trebuie să faci un master-master, trebuie să te gândești de 100 de ori. Cel mai probabil, te poți descurca cu un sclav maestru.

Puteți face oricând replicarea manual, de exemplu. organizați câteva conexiuni și scrieți la 2, 3 deodată sau faceți ceva în fundal.

Ce este sharding-ul?

De fapt, acest lucru răspândește datele pe mai multe servere. Puteți fragmenta mese individuale. Să luăm, de exemplu, un tabel cu fotografii, un tabel cu utilizatori etc. și să le tragem în servere separate. Dacă tabelele erau mari, atunci totul devine mai mic, se consumă mai puțină memorie, totul este în regulă, dar nu te poți alătura și trebuie să faci interogări precum WHERE IN, adică mai întâi selectăm o grămadă de ID-uri, apoi înlocuim toate aceste ID-uri. în interogare, ci la o altă conexiune, la un alt server.

Puteți fragmenta o parte din aceleași date, adică, de exemplu, luăm și creăm mai multe baze de date cu utilizatori.

Puteți selecta pur și simplu un server - restul împărțirii după numărul de servere. O alternativă este să obțineți un card, de ex. Pentru fiecare înregistrare, păstrați cheia valorii în unele Redis sau altele asemenea, adică unde se află fiecare înregistrare.

Există o variantă mai ușoară:

Este mai dificil când nu poți grupa datele. Trebuie să cunoașteți ID-ul de date pentru a-l obține. Fără ÎNSCRIERE, COMANDĂ etc. De fapt, ne reducem MySQL sau PostgreSQL la un magazin cheie-valoare, deoarece nu putem face nimic cu ele.

Sarcinile obișnuite devin extraordinare:

• Selectați TOP 10.
• Defalcarea paginii.
• Alege-l pe cel cu cel mai mic cost.
• Selectați postări de la utilizatorul X.

Dacă am spart atât de mult încât totul s-a împrăștiat pe toate serverele, acest lucru începe să fie rezolvat într-un mod foarte non-trivial. În această situație, apare întrebarea - de ce avem nevoie de SQL? Nu ar trebui să-i scriem imediat lui Redis? Am ales depozitul potrivit?

Din cutie, fragmentarea este susținută de lucruri precum:

• memcache;
• Redis;
• Cassandra (dar ea, se spune, la un moment dat nu poate face față și începe să cadă).

Dar statisticile?

Adesea le place să calculeze statistici de pe serverul principal - de pe un singur server de bază de date. Acest lucru este grozav, dar interogările în statistici sunt de obicei înfiorătoare, cu mai multe pagini etc., așa că calcularea statisticilor din datele principale este o mare greșeală. În cele mai multe cazuri, timpul real nu este necesar pentru statistici, așa că putem configura replicarea în slave master și putem calcula aceste statistici pe slave. Sau putem lua ceva gata făcut - Mixpanel, Google Analytics sau similar.

Aceasta este ideea principală care ajută la distribuirea totul pe diferite servere și la scară. În primul rând, profitul din acest lucru este vizibil imediat - chiar dacă aveți un server și începeți să faceți ceva în fundal, utilizatorul primește un răspuns mult mai rapid, dar și ulterior distribuie încărcarea, de exemplu. putem trage toată această procesare pe alt server, o putem procesa chiar și nu în PHP. De exemplu, la Stay.com, imaginile sunt redimensionate în Go.

Puteți lua imediat Gearman. Acesta este un lucru gata făcut pentru procesare în fundal. Există biblioteci și drivere pentru PHP... Sau poți folosi cozi, adică. ActiveMQ, RabbitMQ, dar cozile de așteptare redirecționează doar mesajele; nu apelează și nu execută ei înșiși handlerii și atunci va trebui să găsești ceva.

Semnificația generală este întotdeauna aceeași - există software-ul principal care plasează unele date în coadă (de obicei, acesta este „ce ar trebui să fac?” și date pentru asta) și un serviciu - fie le primește, fie îi sunt trimise. (dacă coada poate conduce în mod activ) aceste date, procesează totul în fundal.

Să trecem la arhitectură.

Cel mai important lucru la scalare este să faceți proiectul cât mai puțin conectat posibil. Cu cât este mai puțină conexiune, cu atât este mai ușor să schimbați o soluție cu alta, cu atât mai ușor este să mutați o piesă pe un alt server.

Coeziunea are loc în cod. SOLID, GRASP sunt principii care vă permit să evitați cuplarea în cod. Dar conectivitatea din cod afectează, desigur, distribuția pe servere, dar nu la fel de mult ca și conectivitatea stratului de domeniu cu mediul nostru. Dacă scriem mult cod în controler, se dovedește că cel mai probabil nu îl vom putea folosi în altă parte. Nu ne va fi ușor să transferăm toate acestea de la controlerul web la consolă și, în consecință, va fi mai dificil să le transferăm pe alte servere și să le procesăm diferit acolo.

Arhitectura orientată spre servicii.

Există două abordări pentru împărțirea sistemelor în părți:

când se concentrează pe părți tehnice, adică, de exemplu, există o coadă, au eliminat serviciul de așteptare, există procesare de imagini, au eliminat acest serviciu etc.

Acest lucru este bine, dar atunci când aceste cozi, imagini etc. interacționează în cadrul a două zone de domeniu... De exemplu, într-un proiect există o zonă de vânzări și o zonă de clienți - acestea sunt zone diferite, utilizatori diferiți lucrează cu ele, dar ambele au cozi diferite. Când totul începe să cadă împreună, proiectul devine o mizerie;

Soluția corectă este împărțirea în părți logice separate, de ex. dacă zonele Vânzări și Clienți folosesc modelul utilizator, atunci creăm 2 modele utilizator. Ei pot citi aceleași date, dar le prezintă ușor diferit. Dacă defectați sistemul în acest fel, atunci totul este perceput mult mai bine și este mult mai ușor să le împrăștiați pe toate.

Un alt lucru important este că piesele trebuie să comunice întotdeauna prin interfețe. Deci, în exemplul nostru, dacă Vânzările interacționează cu ceva, atunci nu scrie în baza de date, nu folosește un model comun și „vorbește” cu alte zone printr-un anumit contract.

Dar stratul de domeniu?

Stratul de domeniu este împărțit în unele servicii etc. - acest lucru este important pentru dezvoltarea unei aplicații, dar pentru scalarea designului acesteia nu este foarte important. În stratul de domeniu, este extrem de important să îl separăm de mediu, de contextul în care este executat, adică. din controler, mediu de consolă etc., astfel încât toate modelele să poată fi folosite în orice context.

Există 2 cărți despre nivelul de domeniu pe care le recomand tuturor:

• „Domain-Driven Design: Tackling Complexity in the Heart of Software” de Eric Evans,
• „Implementarea designului bazat pe domeniu, implementarea designului bazat pe domeniu”.

• despre BoundedContext - http://martinfowler.com/bliki/BoundedContext.html (ceea ce s-a menționat mai sus - dacă cele două zone ale tale par să se intersecteze, dar sunt diferite, atunci merită să duplicați unele entități, precum modelul utilizatorului);
• despre DDD în general - link către o altă carte.

În arhitectură, din nou, merită să adere la principiul share nimic, adică. dacă vrei să faci ceva comun, fă-o întotdeauna în mod conștient. Este de preferat să puneți logica pe partea aplicației, dar merită să știți când să vă opriți. Nu ar trebui niciodată, de exemplu, să creați proceduri stocate într-un SGBD, deoarece scalarea acestuia este foarte dificilă. Dacă transferăm acest lucru în partea aplicației, atunci devine mai ușor - vom crea mai multe servere și totul va fi realizat acolo.

Nu subestimați optimizarea browserului. După cum am mai spus, din cei 300-600 ms pe care solicitările sunt executate pe server, acestora li se adaugă 300-600 ms, care sunt cheltuiți pe client. Clientului nu îi pasă dacă serverul nostru este rapid sau dacă site-ul funcționează atât de repede, așa că vă sfătuiesc să utilizați Google PageSpeed ​​etc.

Ca de obicei, abstracția și fragmentarea nu sunt deloc gratuite. Dacă împărțim serviciul în mai multe microservicii, atunci nu vom mai putea lucra cu noii veniți și va trebui să plătim mult, mult echipei noastre, care va scotoci prin toate acestea, va sorta toate straturile, în plus. , serviciul poate începe să funcționeze mai lent. Dacă acest lucru nu este înfricoșător în limbile compilate, atunci în PHP, cel puțin până la versiunea 7, acest lucru nu este foarte...

Nu acționați niciodată orbește, monitorizați și analizați întotdeauna. În orb, aproape toate deciziile implicite sunt greșite. Gândi! Nu crede că există un glonț de argint, verifică întotdeauna.

Mai multe link-uri utile:

Sisteme, sisteme software, sisteme de baze de date, routere, rețele etc., dacă necesită capacitatea de a funcționa sub sarcină grea. Sistemul este numit scalabil, dacă este capabil să crească productivitatea proporțional cu resursele suplimentare. Scalabilitatea poate fi evaluată prin raportul dintre creșterea performanței sistemului și creșterea resurselor utilizate. Cu cât acest raport este mai aproape de unu, cu atât mai bine. Scalabilitate înseamnă, de asemenea, capacitatea de a crește resursele suplimentare fără modificări structurale ale nodului central al sistemului.

Într-un sistem cu scalabilitate slabă, adăugarea de resurse duce doar la o ușoară creștere a performanței, iar după un anumit punct „prag”, adăugarea de resurse nu are niciun efect benefic.

Scalare pe verticală

Creșterea performanței fiecărei componente a sistemului pentru a îmbunătăți performanța generală.

Scalare orizontală

Împărțirea sistemului în componente structurale mai mici și distribuirea lor pe mașini fizice separate (sau grupuri de ele) și/sau creșterea numărului de servere care îndeplinesc aceeași funcție în paralel.

Note

Vezi si

Legături

Fundația Wikimedia. 2010.

Vedeți ce înseamnă „Scalabilitate” în alte dicționare:

scalabilitate- extensibilitate Caracteristica unei aplicații care rulează pe diferite platforme și variază în dimensiune (de exemplu, pe un PC care rulează Windows și pe o stație de lucru Sun care rulează Unix). Pentru hardware, creștere previzibilă a performanței sistemului cu... ...

scalabilitate- 3.1.43 scalabilitate: capacitatea de a oferi funcționalități în sus și în jos pentru un set ordonat de platforme de aplicații care variază ca viteză și resurse. Sursă … Dicționar-carte de referință de termeni ai documentației normative și tehnice

Capacitatea software-ului de a rula corect pe sisteme mici și mari, cu performanță care crește proporțional cu puterea de procesare a sistemului. În engleză: Scalabilitate Vezi și: Software pentru sisteme deschise... Dicţionar financiar

scalabilitatea sistemului (în SCADA)- scalabilitate sistem [Intenție] Scalabilitate sistem. Aceasta înseamnă că proiectul dezvoltat poate fi testat pe un computer sau o rețea mică și apoi extinde sistemul (în conformitate cu programul de dezvoltare, bugetul etc.) fără... ... Ghidul tehnic al traducătorului

scalabilitate (în tehnologia informației)- Capacitatea unui serviciu IT, proces, element de configurare etc. de a-și îndeplini funcția convenită anterior atunci când volumul de lucru sau domeniul de aplicare se modifică. [ITIL Glosar de termeni versiunea 1.0, 29 iulie 2011] EN scalabilitate Capacitatea unui IT... ... Ghidul tehnic al traducătorului

scalabilitate (aplicații)- scalabilitate extensibilitate Caracteristici ale unei aplicații care rulează pe diferite platforme și variază ca dimensiune (de exemplu, pe un PC sub Windows și pe o stație de lucru Sun sub Unix). Pentru hardware, creștere previzibilă a sistemului... ... Ghidul tehnic al traducătorului

scalabilitate (rețele și sisteme de comunicații)- Un criteriu pentru un sistem de automatizare a substației rentabil, ținând cont de diverse caracteristici funcționale, diverse dispozitive electronice inteligente, dimensiunea stației și intervalele de tensiune ale stației. [GOST R 54325 2011... ... Ghidul tehnic al traducătorului

Scalabil pe scară largă- - [L.G. Sumenko. Dicționar englez-rus de tehnologia informației. M.: State Enterprise TsNIIS, 2003.] Subiecte tehnologia informației în general EN scalabilitate terabyte ... Ghidul tehnic al traducătorului

scalabilitate orizontală- Creșterea capacității sistemului prin adăugarea de noduri la cluster. Subiecte tehnologia informației în general EN scalabilitate orizontală... Ghidul tehnic al traducătorului

SCALABILITATE - scalabilitate- unul dintre principiile de bază ale construirii sistemelor deschise, garantează păstrarea investițiilor în informații și software atunci când se trece la o platformă hardware mai puternică... Dicţionar E-Business

Cărți

• Microsoft SharePoint 2010. Ghidul complet, Michael Noel, Colin Spence. Cartea explorează toate noile funcții din SharePoint — de la noile funcții de rețele sociale la căutare îmbunătățită — care vă ajută să profitați la maximum de ambele SharePoint...

9 iulie 2015 la ora 09:10

Scalare orizontală a serverelor de baze de date pentru sisteme OLTP, sau ceea ce este pe piață

• Administrarea bazei de date,
• Optimizarea serverului

De regulă, companiile mari și mijlocii au sisteme de informații tranzacționale foarte încărcate, care sunt cea mai importantă componentă a afacerii; ele sunt numite sisteme OLTP. Pe măsură ce afacerea crește, încărcarea crește foarte repede, astfel încât sarcina de a crește productivitatea resurselor existente pentru serverele de baze de date este foarte urgentă. Adesea, pentru a rezolva problema creșterii performanței serverelor de baze de date, se achiziționează echipamente mai puternice (așa-numita scalare „verticală”), dar această metodă are un dezavantaj foarte semnificativ: mai devreme sau mai târziu compania va cumpăra un server de baze de date cu maximum performanță la un preț accesibil și ce să faci în continuare? Perspectivele ulterioare pentru afaceri pot să nu fie atât de roz - în multe cazuri vorbim despre o deteriorare a reputației companiei, incapacitatea de a servi clienții în perioadele de creștere a cererii și o pierdere semnificativă a profitului.

Pentru a elimina astfel de situații și a asigura funcționalitatea sistemelor OLTP, multe companii iau calea scalării „orizontale” a serverelor de baze de date. Spre deosebire de creșterea performanței serverului principal (scalarea „verticală”), cu scalarea „orizontală”, serverele sunt combinate într-un cluster (set), iar sarcina de pe serverele de baze de date este distribuită între ele. Această abordare este mai avansată din punct de vedere tehnologic, deoarece pe lângă avantajele evidente sub forma posibilității de creștere a productivității prin adăugarea de noi servere, se rezolvă și problema atingerii toleranței la erori și dezastre.

Multe companii IT din Rusia și din lume dezvoltă soluții similare; mai jos voi încerca să vorbesc despre ele mai detaliat.

Prima solutie - Oracle RAC (Cluster de aplicații reale)- a apărut în 2001 în versiunea 9i pentru a crește disponibilitatea și performanța în sistemele foarte încărcate bazate pe Oracle DBMS. Vă permite să distribuiți încărcarea unei baze de date foarte încărcate între serverele de baze de date și, prin urmare, să creșteți capacitățile sistemului OLTP pentru creșterea lină a fluxurilor de informații. Pentru informații mai detaliate, consultați documentația sau cărțile de la Oracle Press. Prin urmare, mă voi opri asupra unor puncte care sunt interesante din punctul de vedere al principiului de funcționare.

Deoarece Oracle RAC implementează arhitectura Shared-everything (cu toate avantajele și dezavantajele sale inerente), apoi pentru fiecare server din Oracle RAC există propriul cache, care conține datele interogărilor SQL executate pe acesta. Există, de asemenea, un cluster cache global, implementat folosind tehnologia Cache Fusion, care este sincronizat cu cache-urile serverului local pe baza datelor. Un rol special în coordonarea resurselor clusterului și a punerii în cache în cache îl joacă structura de date Global Resource Directory, care înregistrează pe ce server, ce date și pentru ce obiecte sunt relevante; care este modul de blocare pentru obiectul din instanță. Toate aceste informații vă ajută să decideți care server este mai potrivit pentru a trimite o interogare SQL din punct de vedere al performanței, deoarece dacă luați o decizie greșită, timpul de interogare SQL va crește din cauza timpului necesar pentru sincronizarea datelor între cache.

O caracteristică importantă a acestei abordări a distribuției încărcării între serverele de baze de date este necesitatea de a lua în considerare „diversitatea” traficului SQL din sistemul OLTP. În cazurile în care interogările SQL preiau date din mai multe tabele în același timp, iar rata de modificare a acestor tabele este mare, se poate pierde timp la sincronizarea datelor cache între diferite servere din cluster (de aceea o interconectare rapidă și fiabilă între servere Este nevoie). Acest lucru, la rândul său, poate duce la un răspuns slab al sistemului OLTP, iar beneficiile utilizării Oracle RAC pot fi complet anulate.

Pro:

• Cluster activ/activ
• Echilibrarea sarcinii
• Scalare cu performanță sporită, dar și disponibilitate sporită
• Creștere aproape liniară a performanței la adăugarea de noi noduri la cluster
• Scalare transparentă a aplicației

Minusuri:

• Funcționează numai cu Oracle DBMS
• Pentru funcționare este necesară o interconectare de înaltă performanță cu latență scăzută
• Sistemele de stocare pot fi un singur punct de defecțiune. Pentru a asigura un nivel ridicat de toleranță la erori, RAC trebuie să fie combinat cu standby sau oglindirea de stocare.

A doua soluție - Citrix NetScaler– implementează scalarea orizontală a serverelor de baze de date pentru sistemele OLTP bazate pe MS SQL Server și MySQL diferit de Oracle RAC. Caracteristicile tehnice pot fi găsite accesând linkul.

Dacă în Oracle RAC serverele de baze de date sunt sincronizate automat, atunci Citrix NetScaler trebuie să utilizeze tehnologii terțe pentru sincronizare: AlwaysOn de la Microsoft, replicare MySQL. Soluția Citrix NetScaler în sine este un server proxy între stratul de aplicație (server de aplicații, server web) și serverele de baze de date, astfel încât toate solicitările SQL către serverul de baze de date trec prin el.

Conform specificației, soluția poate recunoaște semnătura interogărilor SQL (pentru citirea sau scrierea datelor) și le poate redirecționa către serverele necesare (definite de setări) din cluster. Latența pentru procesarea unei interogări SQL de către serverul proxy este minimă, astfel încât răspunsul sistemului OLTP nu ar trebui să se deterioreze după implementare. În ciuda acestui beneficiu, capacitatea de a echilibra încărcarea interogărilor SQL depinde și de caracteristicile de trafic ale sistemului OLTP. În multe sisteme OLTP, datele modificate într-o tranzacție sunt citite imediat de următoarea interogare SQL pentru lucrări ulterioare. Având în vedere caracteristicile unei astfel de tehnologii, cum ar fi MS AlwaysOn, datele de pe serverele suplimentare rămân de ceva timp în urma celui principal (în modul sincron și asincron). Fără a ține cont de acest lucru, aplicația și utilizatorul pot ajunge la o situație în care datele adăugate nu vor fi preluate în următoarea interogare SQL. De regulă, tehnologia Citrix NetScaler este recomandată să fie utilizată nu în modul automat, ci în modul manual, astfel încât domeniul său de aplicare este limitat la interogări simple de baze de date în aplicațiile web.

A treia tehnologie - Cluster de date Softpoint– o dezvoltare rusească, care este similară celor două anterioare, dar în mai multe moduri este mai aplicabilă problemelor practice de scalare „orizontală” a serverelor de baze de date pentru sistemele OLTP. Informații mai detaliate despre produs pot fi găsite pe site-ul vânzătorului.

La prima vedere, tehnologia este similară cu Citrix NetScaler, deoarece este un server proxy între nivelul aplicației și nivelul bazei de date și este, de asemenea, strâns integrată cu tehnologiile de sincronizare a bazelor de date (de exemplu, MS AlwaysOn), dar spre deosebire de Citrix NetScaler monitorizează baza de date. desincronizările serverului în cluster și garantează pe deplin consistența datelor din mostre, indiferent de locul în care interogarea SQL este executată pe servere. Această caracteristică vă permite să oferiți echilibrarea automată a sarcinii fără a vă adapta la traficul aplicației.

Tehnologia asigură, de asemenea, sincronizarea tabelelor temporare între serverele din cluster, ceea ce este foarte important pentru o mai bună echilibrare, inclusiv interogările SQL folosind tabele temporare. Un avantaj important al utilizării Softpoint Data Cluster este oportunitatea de a vă familiariza cu exemple de implementări pentru