Scalabilitate - capacitatea unui dispozitiv de a-și crește
posibilităților
prin creșterea numărului de blocuri funcționale,
performând singur şi
aceleași sarcini.
Glosar.ru

De obicei, oamenii încep să se gândească la scalare atunci când sunt
serverul nu poate face față muncii care i se atribuie. Cu ce ​​nu este mai exact?
face față? Funcționarea oricărui server web se rezumă în mare parte la elementele de bază
Ocupația calculatoarelor este prelucrarea datelor. Răspuns la o solicitare HTTP (sau orice alta).
presupune efectuarea unor operaţii asupra unor date. Respectiv,
avem două entităţi principale – date (caracterizate prin volumul său) şi
calcule (caracterizate prin complexitate). Este posibil ca serverul să nu poată face față
funcționează din cauza cantității mari de date (este posibil să nu se potrivească fizic
server), sau din cauza sarcinii de calcul grele. Discuția aici este
desigur, despre sarcina totală - complexitatea procesării unei cereri poate fi
este mic, dar un număr mare dintre ele poate copleși serverul.

Vom vorbi în principal despre scalare folosind un exemplu
proiect web tipic în creștere, dar principiile descrise aici sunt potrivite și pentru
alte domenii de aplicare. Mai întâi ne vom uita la arhitectura proiectului și simplă
distributia acestuia componente pe mai multe servere și apoi vom vorbi despre
scalarea calculelor și a datelor.

Arhitectura tipică a site-ului

Viața unui site web tipic începe cu o arhitectură foarte simplă
- acesta este un server web (de obicei Apache își joacă rolul),
care se ocupă de toată munca de deservire a solicitărilor HTTP,
primit de la vizitatori. El le dă clienților așa-numita „statică”, atunci
există fișiere aflate pe discul serverului care nu necesită procesare: imagini (gif,
jpg, png), foi de stil (css), scripturi client (js, swf). Același server
răspunde întrebărilor care necesită calcule – de obicei formând
pagini html, deși uneori imagini și alte documente sunt create din mers.
Cel mai adesea, răspunsurile la astfel de solicitări sunt generate de scripturi scrise în PHP,
perl sau alte limbi.

Dezavantajul unei scheme de lucru atât de simple este atât de diferit
natura solicitărilor (încărcarea fișierelor de pe disc și munca de calcul scenarii)
procesate de același server web. Interogările de calcul necesită
păstrați o mulțime de informații în memoria serverului (interpret de limbaj de script,
scripturile în sine, datele cu care lucrează) și pot ocupa mult
resurse de calcul. Emiterea de date statice, dimpotrivă, necesită puține resurse
procesor, dar poate ocupa perioadă lungă de timp, dacă clientul are scăzut
viteza de comunicare. Organizare internă server Apache presupune că fiecare
conexiunea se face printr-un proces separat. Acest lucru este convenabil pentru rularea scripturilor,
totuși nu este optim pentru prelucrare interogări simple. Se dovedește că greu (de la
scripturi și alte date) Procesele Apache petrec mult timp așteptând (mai întâi când primesc
cerere, apoi la trimiterea unui răspuns), pierderea memoriei serverului.

Soluția la această problemă este distribuirea lucrărilor de procesare
cereri între doi diferite programe- adica împărțirea în frontend și
backend Un server frontend ușor îndeplinește sarcinile de difuzare a conținutului static și restul
cererile sunt redirecționate (proxy) către backend, unde se realizează formarea
pagini. Așteptarea clienților lenți este, de asemenea, îngrijită de front-end și dacă folosește
multiplexare (când un proces deservește mai mulți clienți - deci
funcționează, de exemplu, nginx sau lighttpd), atunci așteptarea este practic nimic
cheltuieli.

Printre alte componente ale site-ului, trebuie remarcată baza de date, în
care stochează de obicei datele principale ale sistemului - cele mai populare aici sunt
gratuit SGBD MySQLși PostgreSQL. Depozitarea este adesea alocată separat
fișiere binare, care conține imagini (de exemplu, ilustrații pentru articole
site-ul, avatarele și fotografiile utilizatorului) sau alte fișiere.

Astfel, am primit o diagramă de arhitectură formată din
mai multe componente.

De obicei, la începutul vieții unui site, toate componentele arhitecturii
situat pe același server. Dacă nu mai face față sarcinii, atunci
Există o soluție simplă - mutați părțile cele mai ușor separate în alta
Server. Cel mai simplu mod de a începe cu o bază de date este să o mutați pe un server separat și
modificați detaliile de acces în scripturi. Apropo, în acest moment ne confruntăm
importanța unei arhitecturi adecvate codul programului. Dacă lucrați cu o bază de date
prezentat la modul separat, comun pentru întregul site - apoi remediați parametrii
conexiunile vor fi ușoare.

Modalitățile de separare suplimentară a componentelor sunt, de asemenea, clare - de exemplu, puteți muta interfața pe un server separat. Dar de obicei frontend
necesită puțin resursele sistemului iar în această etapă eliminarea sa nu va oferi semnificativ
câștiguri de productivitate. Cel mai adesea, site-ul este limitat de performanță.
scripturi - generarea unui răspuns (pagina html) durează prea mult.
De aceea urmatorul pas de obicei scalarea serverului backend.

Distribuția de calcul

O situație tipică pentru un site în creștere - baza de date este deja
mutat pe o mașină separată, împărțirea în frontend și backend este finalizată,
cu toate acestea, traficul continuă să crească și backend-ul nu are timp să proceseze
cereri. Aceasta înseamnă că trebuie să distribuim calculele pe mai multe
servere. Acest lucru este ușor de făcut - doar cumpărați un al doilea server și instalați-l
Conține programe și scripturi necesare pentru ca backend-ul să funcționeze.
După aceasta, trebuie să vă asigurați că solicitările utilizatorilor sunt distribuite
(echilibrat) între serverele primite. DESPRE în diverse feluri balansare
va fi discutat mai jos, dar deocamdată observăm că acest lucru se face de obicei de către interfață,
care este configurat astfel încât să distribuie uniform cererile între
servere.

Este important ca toate serverele backend să fie capabile corect
raspunde la solicitari. Acest lucru necesită de obicei să lucreze cu fiecare dintre ei
același set de date actualizat. Dacă stocăm toate informațiile într-un singur
baza de date, atunci DBMS-ul însuși va furniza partajareași consistența datelor.
Dacă unele date sunt stocate local pe server (de exemplu, sesiuni php
client), atunci ar trebui să vă gândiți să le transferați într-un spațiu de stocare partajat sau mai mult
algoritm complex de distribuție a cererilor.

Nu numai munca poate fi distribuită pe mai multe servere
scripturi, dar și calcule efectuate de baza de date. Dacă SGBD-ul funcționează foarte mult
interogări complexe, ocupând timpul CPU al serverului, puteți crea mai multe
copii ale bazei de date către servere diferite. Acest lucru ridică problema sincronizării
date atunci când se modifică și mai multe abordări sunt aplicabile aici.

• Sincronizare la nivelul aplicatiei. În acest caz nostru
  scripturile scriu în mod independent modificări la toate copiile bazei de date (și ele însele poartă
  responsabilitatea pentru corectitudinea datelor). Nu este cea mai bună opțiune deoarece el
  necesită atenție în implementare și este foarte tolerant la erori.
• Replicare- adică replicare automată
  modificările efectuate pe un server afectează toate celelalte servere. De obicei când
  Când se utilizează replicarea, modificările sunt întotdeauna scrise pe același server - se numește master, iar copiile rămase sunt numite slave. Majoritatea SGBD-urilor au
  încorporat sau fonduri externe pentru a organiza replicarea. Distinge
  replicare sincronă - în acest caz, va aștepta o solicitare de modificare a datelor
  până când datele sunt copiate pe toate serverele și numai atunci se vor finaliza cu succes - și asincron - în acest caz, modificările sunt copiate pe serverele slave de la
  întârziere, dar cererea de scriere se finalizează mai repede.
• Multi-master replicare. Această abordare este similară
  cea precedentă, dar aici putem schimba datele fără a le accesa
  un anumit server, dar la orice copie a bazei de date. În același timp, schimbări
  sincron sau asincron vor fi transferate în alte copii. Uneori se numește această schemă
  termenul „cluster de baze de date”.

Posibil diferite variante distribuirea sistemului între servere.
De exemplu, putem avea un server de baze de date și mai multe backend-uri (foarte
schema tipică), sau invers - un backend și mai multe baze de date. Dacă am scala
atât serverul backend, cât și baza de date, apoi puteți combina backend-ul și o copie a bazei de date
o mașină. În orice caz, de îndată ce avem mai multe exemplare
orice server, se pune întrebarea cum să se distribuie corect între ele
sarcină.

Metode de echilibrare

Să creăm mai multe servere (pentru orice scop - http, bază de date etc.), fiecare dintre ele poate procesa cereri. Inainte de
ne confruntăm cu sarcina de a distribui munca între ei, cum să aflăm care
serverul trimite o cerere? Există două moduri principale de a distribui cererile.

• Unitate de echilibrare. În acest caz, clientul trimite o cerere către unul
  un server fix cunoscut de el și redirecționează deja cererea către unul dintre
  servere de lucru. Exemplu tipic- un site cu un front-end și mai multe
  servere backend la care solicitările sunt trimise proxy. Cu toate acestea, „clientul” poate
  fi în interiorul sistemului nostru - de exemplu, un script poate trimite o solicitare către
  către un server proxy de bază de date care va transmite cererea unuia dintre serverele DBMS.
  Nodul de echilibrare în sine poate funcționa atât pe un server separat, cât și pe unul singur
  de pe serverele de lucru.

  Avantajele acestei abordări sunt
  despre care clientul nu trebuie să știe nimic structura interna sisteme - despre cantitate
  servere, despre adresele și caracteristicile lor - numai
  echilibrist Cu toate acestea, dezavantajul este că unitatea de echilibrare este una singură
  punctul de defecțiune al sistemului - dacă eșuează, întregul sistem va fi
  inoperant. În plus, sub sarcină mare, balansierul se poate opri pur și simplu
  să facă față muncii lor, așa că această abordare nu este întotdeauna aplicabilă.

• Echilibrare partea clientului. Dacă vrem să evităm
  există un singur punct de eșec Opțiune alternativă- încredințați selecția serverului
  clientului însuși. În acest caz, clientul trebuie să cunoască structura internă a noastră
  sisteme pentru a putea alege corect ce server să contacteze.
  Un avantaj incontestabil este absența unui punct de eșec - dacă unul dintre
  servere clientul va putea contacta alții. Cu toate acestea, prețul pentru aceasta este
  logica client mai complexa si mai putina flexibilitate de echilibrare.

Desigur, există și combinații ale acestor abordări. De exemplu,
astfel de metoda cunoscuta echilibrarea încărcăturii, ca și echilibrarea DNS, se bazează pe
ca la determinarea adresei IP a unui site, clientul este dat
adresa unuia dintre mai multe servere identice. Astfel, DNS acționează ca un
rolul nodului de echilibrare de la care clientul primește „distribuția”. in orice caz
însăși structura serverelor DNS implică absența unui punct de eșec din cauza
duplicarea - adică avantajele a două abordări sunt combinate. Desigur, acesta
Există și dezavantaje ale metodei de echilibrare - de exemplu, un astfel de sistem este dificil de dinamic
reconstrui.

Lucrul cu un site nu se limitează de obicei la o singură solicitare.
Prin urmare, atunci când proiectați, este important să înțelegeți dacă interogările secvenţiale pot
clientul să fie procesat corect de diferite servere, sau clientul trebuie să fie
legat de un server în timp ce lucrați cu site-ul. Acest lucru este deosebit de important dacă
site-ul stochează informații temporare despre sesiunea utilizatorului (în acest
În acest caz, este posibilă și distribuția gratuită - dar atunci este necesar să se depoziteze
sesiuni (stocare comună tuturor serverelor). „Leagă” vizitatorul de
puteți specifica un anumit server după adresa sa IP (care, totuși, se poate schimba),
sau prin cookie (în care identificatorul serverului este preînregistrat), sau chiar
pur și simplu redirecționând-o către domeniul dorit.

Pe de altă parte, este posibil ca serverele de calcul să nu aibă drepturi egale.
În unele cazuri, este avantajos să faci invers, să aloci un server separat pentru
procesarea cererilor de un singur tip - și obțineți o divizare verticală
funcții. Apoi clientul sau nodul de echilibrare va selecta serverul în
in functie de tipul cererii primite. Această abordare ne permite să ne despărțim
solicitări importante (sau invers, nu critice, ci dificile) de la alții.

Distribuția datelor

Am învățat să distribuim calcule, deci un mare
prezența nu este o problemă pentru noi. Cu toate acestea, volumele de date continuă să crească,
stocarea și procesarea acestora devine din ce în ce mai dificilă - ceea ce înseamnă că este timpul să le construiți
stocarea distribuită a datelor. În acest caz, nu vom mai avea unul sau
mai multe servere care conțin copie integrală Bază de date. În schimb, datele
vor fi distribuite pe diferite servere. Ce scheme de distribuție sunt posibile?

• Distribuție verticală(compartimentare verticală) - în cel mai simplu caz
  constituie o hotărâre mese separate baza de date către un alt server. La
  În acest caz, va trebui să schimbăm scripturile pentru a accesa diferite servere pentru
  date diferite. În limită, putem stoca fiecare tabel pe un server separat
  (deși în practică este puțin probabil ca acest lucru să fie benefic). Evident, cu asta
  distribuție, pierdem capacitatea de a face interogări SQL care combină date din
  două mese situate pe servere diferite. Dacă este necesar, puteți implementa
  logica de îmbinare în aplicație, dar nu va fi la fel de eficientă ca într-un SGBD.
  Prin urmare, atunci când partiționați o bază de date, trebuie să analizați relațiile dintre tabele,
  pentru a distribui mese cât mai independente.

  Caz mai complex
  distribuția verticală a bazei este o descompunere a unui tabel atunci când este parte
  unele dintre coloanele sale ajung pe un server, iar unele dintre ele ajung pe altul. Această tehnică
  este mai puțin comun, dar poate fi folosit, de exemplu, pentru a separa mici
  și date actualizate frecvent dintr-un volum mare de date rar utilizate.

• Distribuție orizontală(compartimentare orizontală) - constă din
  distribuirea datelor dintr-un tabel pe mai multe servere. De fapt, pe
  fiecare server creează un tabel cu aceeași structură și stochează
  o anumită bucată de date. Puteți distribui date pe servere în moduri diferite
  criterii: după interval (înregistrări cu id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
  A, restul - către serverul B) sau prin valoarea hash a unui anumit câmp
  înregistrări. Partiționarea orizontală a datelor vă permite să stocați nelimitat
  numărul de înregistrări complică însă selecția. Cel mai eficient mod de a alege
  înregistrează numai atunci când se știe pe ce server sunt stocate.

Pentru selecție schema corecta distribuirea datelor este necesară
analizați cu atenție structura bazei de date. Tabelele existente (și eventual
câmpuri individuale) pot fi clasificate după frecvența accesului la înregistrări, după frecvență
actualizări și relații (necesitatea de a face selecții din mai multe
Mese).

După cum am menționat mai sus, pe lângă o bază de date, un site are adesea nevoie
stocare pentru fișiere binare. Sisteme distribuite de stocare a fișierelor
(de fapt, sistemele de fișiere) pot fi împărțite în două clase.

• Lucru la nivel sistem de operare . Mai mult, pentru
  aplicațiile care lucrează cu fișiere într-un astfel de sistem nu sunt diferite de munca regulata Cu
  fișiere. Schimbul de informații între servere este gestionat de sistemul de operare.
  Ca exemple de astfel sisteme de fișiere putem cita ceea ce este cunoscut de mult timp
  Familia NFS sau mai puțin cunoscută, dar mai mult sistem modern Luciu.
• Implementat la nivelul aplicatiei distribuite
  depozitele implică faptul că munca de schimb de informații se desfășoară de la sine
  aplicarea. De obicei, sunt plasate funcții pentru lucrul cu stocarea
  bibliotecă separată. Unul dintre exemplele izbitoare de astfel de stocare este MogileFS, dezvoltat de
  de creatorii LiveJournal. Un alt exemplu comun este utilizarea
  Protocolul WebDAV și stocarea care îl acceptă.

Trebuie menționat că distribuția datelor decide nu numai
o chestiune de depozitare, dar și parțial o chestiune de distribuție a sarcinii - pe fiecare
Există mai puține înregistrări pe server și, prin urmare, sunt procesate mai rapid.
Combinația de metode de distribuire a calculelor și a datelor face posibilă construirea
arhitectură potențial scalabilă nelimitat, capabilă să lucreze cu
orice cantitate de date și orice încărcare.

concluzii

Pentru a rezuma cele spuse, să formulăm concluzii sub forma unor scurte teze.

• Cele două provocări principale (și legate) de scalare sunt distribuția de calcul și distribuția datelor
• Arhitectura tipică a site-ului implică separarea rolurilor și
  include frontend, backend, bază de date și uneori stocare de fișiere
• Dacă nu volume mari sunt utilizate date și sarcini grele
  oglindirea bazei de date - replicare sincronă sau asincronă
• Pentru cantități mari de date, este necesară distribuirea bazei de date - împărțită
  acesta pe verticală sau pe orizontală
• Binarele sunt stocate pe sisteme de fișiere distribuite
  (implementat la nivel de sistem de operare sau în aplicație)
• Echilibrarea (distribuirea cererilor) poate fi uniformă sau
  împărțit după funcționalitate; cu un nod de echilibrare sau pe partea clientului
• Combinația corectă de metode vă va permite să rezistați oricărei sarcini;)

Legături

Puteți continua să studiați acest subiect pe site-uri și bloguri interesante în limba engleză.

Scalare pe verticală— extindere — creșterea numărului de resurse disponibile pentru software prin creșterea puterii utilizate de la servere.

— extindere — creșterea numărului de noduri combinate într-un cluster de servere atunci când există o lipsă de CPU, memorie sau spatiu pe disc.

Ambele sunt soluții de infrastructură care sunt necesare în diferite situații când un proiect web crește.

Verticală și scalare orizontală, scalare pentru web

De exemplu, luați în considerare serverele de baze de date. Pentru aplicații mari aceasta este întotdeauna cea mai încărcată componentă a sistemului.

Capacitățile de scalare pentru serverele de baze de date sunt determinate de aplicabil soluții software: cel mai adesea acestea sunt baze de date relaționale (MySQL, Postgresql) sau NoSQL(, Cassandra etc.).

Scalare orizontală pentru serverele de baze de date sub sarcini grele este mult mai ieftină

Un proiect web este de obicei pornit pe un server, ale cărui resurse se epuizează pe măsură ce crește. Într-o astfel de situație, există 2 opțiuni:

• muta site-ul pe un server mai puternic
• adăugați un alt server de consum redus și combinați mașinile într-un cluster

MySQL este cel mai popular RDBMS și, ca oricare dintre ele, necesită o mulțime de resurse de server pentru a rula sub sarcină. Scalare este posibilă în principal în sus. Există sharding (care necesită modificări de cod pentru a configura) și sharding, care poate fi dificil de suportat.

Scalare pe verticală

NoSQL se scalează cu ușurință, iar a doua opțiune cu, de exemplu, MongoDB, va fi mult mai profitabilă din punct de vedere financiar și nu va necesita setări intensive în muncă și suport pentru soluția rezultată. Partajarea se realizează automat.

Astfel, cu MySQL veți avea nevoie de un server cu o cantitate mare CPU și RAM, astfel de servere au un cost semnificativ.

Scalare orizontală
Cu MongoDB poți mai adauga unul server mediu iar soluția rezultată va funcționa stabil, oferind toleranță suplimentară la erori.

Extindere sau este o etapă naturală a dezvoltării infrastructurii. Orice server are limite și când sunt atinse sau când costul este mai mare server puternic se dovedește a fi nerezonabil de mare, sunt adăugate mașini noi. Sarcina este distribuită între ele. De asemenea, oferă toleranță la erori.

Ar trebui să începeți să adăugați servere de dimensiuni medii și să configurați clustere atunci când posibilitățile de creștere a resurselor unei mașini au fost epuizate sau când achiziționarea unui server mai puternic se dovedește a fi neprofitabilă

Exemplul dat cu baze de date relaționale date și NoSQL este situația care apare cel mai des. Serverele frontend și backend sunt, de asemenea, scalabile.

Citiți despre echilibrator

ALEXANDER KALENDAREV, RBC Media, programator, [email protected]

Probleme și soluții

Mai devreme sau mai târziu, un proiect web sau mobil popular cu partea de server va întâmpina o problemă de performanță. O soluție este să scalați baza de date pe orizontală. Vorbim despre capcane și moduri posibile ocolindu-le

Fiecare proiect în creștere se confruntă cu o provocare de productivitate. Prin urmare, dacă credeți că proiectul dvs. este ambițios și va cuceri în curând întreaga lume, atunci este indicat să includeți posibilitatea de scalare deja la nivelul dezvoltării inițiale a arhitecturii.

Să clarificăm terminologia:

• Performanţă– capacitatea aplicației de a îndeplini cerințe precum timpul maxim de răspuns, debitul.
• Debit (capacitate) – oportunitate maxima aplicații pentru a trece prin o anumită cantitate de solicitări pe unitatea de timp sau păstrați un anumit număr de sesiuni de utilizator.
• Scalabilitate este o caracteristică a unei aplicații care își arată capacitatea de a menține performanța în timp ce crește debitul. La rândul său, scalarea este procesul de asigurare a creșterii sistemului. Scalare poate fi verticală sau orizontală.
• Scalare pe verticală– aceasta este o creștere a productivității datorită creșterii puterii hardware-ului, cantității de RAM etc. Mai devreme sau mai târziu, scalarea verticală își va atinge limita superioară.
• Scalare orizontală este o creștere a productivității prin împărțirea datelor pe mai multe servere.

Separarea datelor funcționale

Există mai multe opțiuni pentru scalarea orizontală. De exemplu, este foarte des folosit pentru a separa datele pe baza utilizării funcționale. De exemplu, datele pentru albumele foto sunt conținute într-un grup de servere, datele profilului utilizatorului sunt situate într-un alt grup, iar corespondența utilizatorului este localizată într-un al treilea. În fig. Figura 1 prezintă o diagramă de scalare orizontală prin distribuție funcțională.

Scalare folosind replicare

Cea mai ușoară modalitate de scalare, folosită adesea pentru proiecte mici și mijlocii, este să folosești replicarea. Replicarea este un mecanism pentru sincronizarea mai multor copii ale unui obiect și a tabelelor bazei de date (vezi Fig. 2). Replicarea master-slave este sincronizarea datelor de la serverul principal principal la serverele slave.

Din moment ce majoritatea web și proiecte mobile Există un ordin de mărime mai multe operațiuni de citire decât operațiuni de scriere, apoi putem efectua operațiuni de scriere pe un server master și citim date de pe mai multe servere slave. Replicarea trebuie configurată între serverele master și slave.

Multe baze de date au replicare încorporată sau, după cum se spune, o „soluție gata de fabricație”. De exemplu, replicarea PostgreSQL poate fi efectuată de următoarele utilitare:

• Slony-I – replicare asincronă (master la mai mulți sclavi);
• pgpool-I/II – replicare multimaster sincronă;
• Pgcluster – replicare multimaster sincronă;
• Bucardo;
• Londra;
• RubyRep.
• începând cu versiunea 9.0, replicare în flux încorporată.

Când scalați folosind replicarea, trebuie să utilizați conexiuni diferite: unul cu server master, doar pentru scriere sau actualizare, iar al doilea, doar cu server slave, direct pentru citire. Mai mult, dacă folosim mai multe servere slave, atunci strategia de selecție poate fi aleatorie, sau un anumit server de bază de date este alocat unui anumit server web.

Citiți întregul articol în revistă " Administrator de sistem„, nr. 10 pentru 2014 la paginile 54-62.

Versiune PDF număr dat poate fi achiziționat din magazinul nostru.

In contact cu

Model de subsistem de încredere (sau server de încredere)

În unele situații, poate fi necesară mai mult de o identitate de încredere, de exemplu, dacă există două grupuri de utilizatori, dintre care unul trebuie să fie autorizat să efectueze operațiuni de citire/scriere, iar celălalt trebuie să fie autorizat să efectueze operațiuni doar de citire. Utilizarea mai multor identități de servicii de încredere permite un control mai granular al accesului la resurse și un audit fără un impact prea mare asupra scalabilității. În fig. Figura 14 prezintă un model care utilizează mai multe identități de servicii de încredere.

Model de identitate pentru servicii de încredere multiple

Scalare pe verticală și orizontală

Abordarea implementării scalarii este critică aspect important proiecta. Indiferent dacă intenționați să efectuați orizontală

scalând soluția utilizând un cluster echilibrat de încărcare sau o bază de date partiționată, designul trebuie să accepte opțiunea selectată. Există două tipuri principale de scalare: verticală (bloc mare) și

orizontală (mai multe blocuri).

Suport de scalare verticală sarcina crescuta furnizate prin introducerea în serverele existente echipament adițional, cum ar fi procesoarele, RAMși plăci de interfață de rețea (NIC). Această opțiune simplă nu adaugă costuri de întreținere și suport, ci poate fi doar rentabilă până la anumit punct. Cu toate acestea, există întotdeauna posibilitatea de eșec, ceea ce este un risc. În plus, adăugarea de hardware suplimentar la serverele existente nu atinge rezultatele dorite la nesfârșit, iar obținerea ultimilor 10% din performanța calculată prin creșterea capacității unui singur computer poate fi foarte costisitoare.

Scalare verticală eficientă a unei aplicații poate fi realizată numai dacă infrastructura de bază, mediul de rulare și arhitectura computerului se scalează corespunzător. Luați în considerare ce resurse limitează performanța aplicației dvs. De exemplu, dacă acest lucru se datorează memoriei scăzute sau scăzute debitului rețea, adăugarea de procesoare nu va face nimic.

Când scalați pe orizontală, adaugă mai multe servereși se folosesc soluții cu echilibrare a sarcinii și clustering. Pe lângă posibilitatea de prelucrare sarcină mai mare,Scalarea orizontală atenuează efectele defecțiunilor hardware. Dacă unul dintre servere eșuează, alte servere din cluster preiau încărcarea acestuia. De exemplu, stratul de prezentare și stratul de afaceri al unei aplicații pot fi găzduite pe mai multe servere Web cu încărcare echilibrată care formează o fermă Web. Sau puteți separa fizic logica de afaceri a aplicației și utilizați una separată pentru aceasta nivel mediuîncărcare echilibrată, dar plasați nivelul de prezentare în nivelul exterior echilibrat cu sarcina. Dacă aplicația are limitări I/O și trebuie să accepte foarte baza de date mare date, acestea pot fi distribuite pe mai multe servere de baze de date. De obicei, capacitatea unei aplicații de a scala pe orizontală depinde mai mult de arhitectura sa decât de infrastructura de bază.

Probleme de scalare verticală

Scalare verticală prin puterea procesorului crescută și memorie sporită poate fi rentabilă solutie eficienta. De asemenea, cu această abordare, nu este nevoie de costuri suplimentare de management, ca și în cazul scalarii orizontale datorită utilizării fermelor Web și a grupării. Primul pas este să luați în considerare opțiunile de scalare verticală și să efectuați teste de performanță pentru a vă asigura că soluția dvs. de scalare verticală îndeplinește criteriile dvs. de scalare și oferă performanțe acceptabile pentru numărul necesar de utilizatori concurenți. Este necesar să se elaboreze un plan de scalare pentru sistem care să reflecte perspectivele sale de creștere.

Proiectare pentru extindere

Dacă scalarea verticală a unei soluții nu oferă scalabilitatea necesară datorită atingerii limitelor de procesor, I/O sau memorie, este necesar să se scaleze pe orizontală și să se introducă servere suplimentare. Pentru a asigura scalarea orizontală eficientă a aplicației dvs., utilizați următoarele practici atunci când proiectați:

Identificarea și scalarea orizontală a blocajelor . Adesea, blocajul sunt resursele partajate care nu se scalează bine pe verticală. De exemplu, există o singură instanță SQL Server, cu care funcționează multe servere de aplicații. În acest caz, partiționarea datelor astfel încât să poată fi servite de mai multe instanțe de SQL Server va permite soluției să se extindă. Dacă există posibilitatea ca serverul de baze de date să fie blocajul, partiționarea datelor în design va salva o mulțime de probleme pe drum.

Design ușor cuplat și stratificat . Un design slab cuplat, stratificat, cu interfețe clare care pot fi utilizate de la distanță este mai ușor de scalat pe orizontală decât un design care utilizează straturi strâns cuplate cu interfețe granulare. Un design stratificat va avea puncte de întrerupere naturale, făcându-l ideal pentru scalarea orizontală în limitele de nivel. Principalul lucru este să definiți corect limitele. De exemplu, lociga afacerii Mai ușor de migrat la o fermă de servere de aplicații de nivel mediu cu încărcare echilibrată.

Compensații și consecințe ale realizării acestora

Există considerații de scalabilitate de luat în considerare, care pot varia în funcție de diferite straturi, niveluri sau tipuri de date. Identificarea compromisurilor necesare vă va permite să vedeți unde există flexibilitate și unde nu. În unele cazuri, scalarea verticală urmată de scalarea orizontală folosind servere Web sau de aplicații nu este cea mai bună abordare. De exemplu, puteți instala un server cu 8 procesoare, dar din motive de economie, cel mai probabil, în loc de unul server mare vor fi folosite mai multe servere mai mici.

Pe de altă parte, în anumite situații, în funcție de rolul datelor și de utilizarea acestora, scalarea verticală urmată de scalarea orizontală poate fi abordarea optimă pentru serverele de baze de date. Cu toate acestea, capabilitățile de echilibrare a sarcinii și de failover nu sunt nesfârșite, iar numărul de servere care pot fi acoperite de aceste procese este limitat. Alte aspecte, cum ar fi partiționarea bazei de date, au, de asemenea, un impact. Cu exceptia probleme tehniceși problemele de performanță, nu trebuie să uităm de operare și management și cost totalîntregul sistem.

De obicei, prețul și performanța sunt optimizate în limitele impuse de toate celelalte constrângeri. De exemplu, folosind patru Web cu 2 procesoare

pot exista mai multe servere/servere de aplicații cea mai bună opțiune din punct de vedere al prețului și performanței în comparație cu utilizarea a două servere cu 4 procesoare. Cu toate acestea, trebuie luate în considerare și alte constrângeri, cum ar fi numărul maxim de servere care pot fi găzduite într-o anumită infrastructură de echilibrare a sarcinii, precum și consumul de energie sau spațiul disponibil în centrul de date.

Serverele virtualizate pot fi utilizate pentru implementarea fermelor de servere și a serviciilor gazdă. Această abordare vă va ajuta să găsiți raport optim performanță și cost, asigurând în același timp utilizarea maximă a resurselor și rentabilitatea investiției.

Componente apatride

Utilizarea componentelor apatride (componente apatride care pot fi implementate pe front-end-ul unei aplicații Web) înseamnă că puteți crea un design care este mai capabil să se scaleze atât pe orizontală, cât și pe verticală. Există multe compromisuri care trebuie făcute pentru conștientizarea designului apatrid, dar beneficiile pe care le oferă în ceea ce privește scalabilitatea tind să depășească orice posibile dezavantaje.

Partiționarea datelor și a bazelor de date

Dacă aplicația dvs. rulează pe o bază de date foarte mare și vă îngrijorează că I/O va deveni un blocaj al sistemului, luați în considerare partiționarea bazei de date în avans. Partiționarea unei baze de date mai târziu în proiectare necesită de obicei o reproiectare completă a bazei de date și, prin urmare, modificări majore la întregul cod al aplicației. Partiționarea oferă mai multe beneficii, inclusiv capacitatea de a direcționa toate cererile către o singură partiție (limitând astfel utilizarea resurselor la o singură bucată de date) și capacitatea de a utiliza mai multe partiții (obținând astfel cele mai bune oportunități munca simultanași performanță excepțională prin preluarea datelor de pe mai multe discuri).

Cu toate acestea, în unele situații, a avea mai multe secțiuni poate avea consecințe negative. De exemplu, unele operațiuni sunt mai eficiente de efectuat cu date concentrate pe o singură unitate.

Deciziile de partiționare a stocării datelor în scenariile de implementare sunt în mare măsură determinate de tipul de date. Să luăm în considerare factorii semnificativi:

Date de referință statice numai pentru citire . Pentru acest tip de date, pentru a îmbunătăți performanța și scalabilitatea, puteți păstra cu ușurință mai multe copii diferite unități, amplasate în locuri adecvate. Acest lucru are un impact minim asupra designului și este de obicei determinat de considerente de optimizare. Consolidarea mai multor baze de date separate logic și independente pe un singur server de baze de date, chiar dacă spațiul pe disc permite, poate fi decizie proasta, iar plasarea copiilor mai aproape de consumatorii de date poate fi o abordare la fel de acceptabilă. Cu toate acestea, nu trebuie să uităm că oricare

replicarea necesită utilizarea unor mecanisme care să asigure sincronizarea sistemului.

Date dinamice (schimbând frecvent) ușor de parționat . Acestea sunt date specifice unui anumit utilizator sau sesiune, cum ar fi un coș de cumpărături dintr-un sistem comerțul electronic, unde datele utilizatorului A nu au legătură în niciun fel cu datele utilizatorului B. Aceste date sunt puțin mai complexe de gestionat decât datele statice numai pentru citire, dar sunt destul de ușor de optimizat și distribuit, deoarece pot fi partiționate. Nu există dependențe între grupuri până la utilizatori individuali. Caracteristică importantă Aceste date sunt că solicitarea nu este efectuată aici pentru toate secțiunile: conținutul coșului utilizatorului A este solicitat, dar nu toate coșurile, inclusiv produs specific. Vă rugăm să rețineți că solicitările ulterioare pot ajunge pe o altă variantă server web sau un server de aplicații, toate aceste servere trebuie să poată accesa secțiunea corespunzătoare.

Date de bază . Acesta este principalul caz de utilizare pentru scalarea verticală urmată de scalarea orizontală. De regulă, nu este recomandabil să replicați acest tip de date din cauza dificultății de sincronizare. Soluția clasică pentru astfel de date este scalarea verticală până la limită (în mod ideal, menținând o singură instanță logică cu clustering adecvat) și utilizarea partiționării și distribuției numai dacă scalarea orizontală este singura opțiune viabilă. Progresul și progresele în tehnologiile de baze de date, cum ar fi vizualizările partiționate distribuite, au făcut partiționarea mult mai ușoară, cu toate acestea, ar trebui să fie folosită numai atunci când este absolut necesar. Prea mult marime mare Baza de date este rareori factorul determinant în decizie; de ​​cele mai multe ori, alte considerații precum cine deține datele, distribuția geografică a utilizatorilor, apropierea de consumator și accesibilitatea joacă un rol major.

Sincronizare întârziată a datelor . Unele date utilizate în aplicații nu necesită deloc sincronizare sau sincronizare imediată. Excelent exemplu- astfel de date magazine online, ca „Cu produsul X, oamenii cumpără adesea Y și Z”. Aceste date sunt extrase din datele de bază, dar nu necesită actualizare în timp real. Proiectarea strategiilor de mutare a datelor de la bază la partiționat (dinamic) la statice este cheia pentru construirea de aplicații extrem de scalabile.

Schemele pentru mutarea și replicarea datelor sunt discutate mai detaliat în articolul „Data Movement Patterns” (Data Transfer Patterns) la http://msdn.microsoft.com/en-us/library/ms998449.aspx.

Sisteme, pachete software, sisteme de baze de date, routere, rețele etc., dacă necesită capacitatea de a lucra sub incarcatura 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 altele mai mici componente structuraleși despărțindu-le în separate mașini fizice(sau grupurile acestora) ș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 Caracteristicile unei aplicații care rulează platforme diferiteși variază în dimensiune (de exemplu, pe un PC Windows și pe stație de lucru Soare sub Unix). Creștere previzibilă pentru hardware caracteristicile sistemului la……

scalabilitate- 3.1.43 scalabilitate: capacitatea de a oferi funcţionalitate sus și în jos o serie 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

Abilitatea software lucrați corect la scară mică și mare sisteme mari cu productivitatea care crește proporțional putere de calcul sisteme. Î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)- Criteriul economic sistem eficient automatizarea statiilor, tinand cont de diverse caracteristici functionale, diverse intelectuale dispozitive electronice, 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.: Întreprinderea de stat TsNIIS, 2003.] Subiecte tehnologia de informație scalabilitate generală EN 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 construcției sisteme deschise, se asigură că investițiile în informații și software sunt menținute 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 acoperă toate cele noi Caracteristici SharePoint- din componente noi retele sociale la căutare avansată - care vă ajută să profitați la maximum de ambele SharePoint...