Sistemul în curs de dezvoltare este scalabil și anume. Scalare orizontală. Ce, de ce, când și cum? Arhitecturi verticale și orizontale

Printre numeroasele funcții ale unui sistem informatic necesare pentru gestionarea logisticii rețelei, ne vom concentra mai întâi pe două funcții cheie de „rețea”: managementul sortimentului și suport pentru managementul categoriei.

1. Managementul sortimentului într-o societate comercială de rețea.

Întreprinderile de comerț cu amănuntul din rețea, în special din sectorul alimentar, se caracterizează prin cel mai înalt nivel de complexitate a sarcinilor de management. Un aspect deosebit de provocator este gestionarea sortimentelor.

Cu cât este mai bine rezolvată, cu atât mai eficient se dezvoltă întreprinderea de comerț cu amănuntul în ansamblu și cu atât este mai ridicată competitivitatea acesteia.

Sarcina de gestionare a sortimentului poate fi împărțită în două subsarcini – „externă” și „internă”.

Primul vizează colaborarea cu cumpărătorul în materie de sortiment, al doilea vizează facilitarea muncii personalului cu categorii de sortiment.

Rezolvarea cu succes a acestor probleme ar trebui să conducă la îmbunătățirea rezultatelor vânzărilor de produse.

Pentru o soluție eficientă grup de sarcini „extern”. necesar:

• 1) furnizarea de informații despre produse clienților. Sistemele de asistență informatică și multimedia sunt concepute pentru a ajuta clienții să navigheze în marea nemărginită de mărfuri, să facă alegerea corectă și să obțină informații valoroase în cel mai scurt timp posibil. În același timp, ajută retaileri să analizeze preferințele consumatorilor, să stimuleze vânzarea mărfurilor necesare, să optimizeze amenajarea etajului de vânzare, să plaseze rațional sortimentul, ceea ce asigură rezolvarea cu succes a sarcinilor externe de automatizare a managementului sortimentului;
• 2) rezolva problemele personale de marketing. Implementarea funcției de marketing personal este una dintre cele mai importante sarcini ale managementului sortimentelor pentru formatele „supermarket” și „hipermarket”. Mai mult decât atât, dacă pentru un supermarket este cel mai important să se efectueze marketing personal direcționat, cu urmărirea fluctuațiilor în preferințele anumitor clienți obișnuiți ai unui anumit magazin, atunci pentru un hipermarket este important să se lucreze cu grupuri tipice de clienți aparținând unei categorii definite convențional. a clienților obișnuiți. În ceea ce privește discounterii, marketingul personal este mai puțin relevant pentru aceștia. Pentru a identifica preferințele clienților obișnuiți, disponibilitatea în sistemul informațional a capacității de a efectua o analiză cuprinzătoare a vânzărilor și de a determina structura achizițiilor este, de asemenea, o sarcină extrem de importantă;
• 3) desfășurați visual merchandising de înaltă calitate. Afișarea eficientă a mărfurilor pe rafturile magazinelor crește semnificativ volumele vânzărilor. Pentru a evalua calitatea soluțiilor la problemele de merchandising vizual, sistemul informațional trebuie să fie capabil să mențină și să analizeze planograme care descriu plasarea mărfurilor pe rafturile magazinelor.

La hotărâre sarcini interne de gestionare a sortimentului este necesar să se automatizeze următoarele procese de afaceri:

1) proces activ de gestionare a sortimentului (menținerea matricelor de sortiment).

Cert este că informațiile despre un produs, odată introduse în baza de date, rămân în el pentru o lungă perioadă de timp. De exemplu, cu un sortiment actual de 7.000 de articole de mărfuri, sistemul poate stoca 20-30 de mii de articole de mărfuri. În aceste condiții, este necesar să se ofere utilizatorului sistemului posibilitatea de a lucra numai cu informații actuale despre sortimentul activ (Fig. 3.4).

Orez. 3.4.

Pentru a rezolva această problemă este necesar asigura urmatoarele functii:

• introducerea mărfurilor în sortimentul activ. Acest proces este de obicei precedat de o serie de activități de marketing de probă cu un produs dat, pregătirea logisticii și pregătirea înainte de vânzare a produsului;
• încetarea achizițiilor de mărfuri, ca primă fază a scoaterii mărfurilor din sortimentul activ. Motivele tipice pentru acest proces includ:
  • a) nemulțumire față de rezultatele vânzărilor de produse;
  • b) schimbarea sortimentului de către producător;
  • c) prezența unor probleme de relație cu furnizorul; si etc.;
• încetarea realimentării stocurilor din centrul de distribuție al companiei;
• încetarea lucrului cu produsul, ca fază finală a scoaterii produsului din sortimentul din informare

sistem (de obicei apare atunci când rezervele ajung la zero);

Ștergerea informațiilor despre mărfuri în sistemele de casă de marcat (efectuată, de regulă, după un inventar).

Avantajele automatizării acestui proces de afaceri :

• comoditate pentru utilizatori atunci când lucrează cu gama de produse;
• o reducere semnificativă a numărului de erori asociate cu imposibilitatea includerii în documente a unui produs care nu aparține sortimentului activ;
• capacitatea de a primi rapoarte analitice doar pe sortimentul activ;
• creșterea productivității managerilor implicați în managementul sortimentelor; si etc.;
• 2) procesul de gestionare a unui sortiment activ de întreprinderi de retail de diverse formate , incluse într-o întreprindere comercială de rețea multi-format (gestionarea matricelor de sortimente multiple).

Automatizarea acestui proces de afaceri face posibilă prevenirea deplasării mărfurilor către un obiect de gestiune, matricelor de sortimentare cărora acest produs nu aparține (Fig. 3.5).

Orez. 3.5.

De asemenea, trebuie remarcat faptul că o soluție de înaltă calitate pentru problemele „interne” de gestionare a sortimentului este de cea mai mare importanță pentru o întreprindere de comerț cu amănuntul în rețea multiformat.

2. Procesul de suport pentru managementul categoriilor prin formarea vederilor de produs și a vizualizărilor obiectelor de management cu care lucrează un anumit manager de categorie.

Pentru un manager implicat în managementul unor categorii specifice de produse, combinate în așa-numitele unități strategice de afaceri, atunci când lucrează cu un sistem informațional, este important să se concentreze asupra unui anumit subset de produse și obiecte de management.

Este indicat ca un manager de categorie să vadă doar ceea ce privește „categoriile lui de produse”, astfel încât să se creeze iluzia că în sistemul informațional nu există nimic în afară de bunurile incluse în unitatea sa de afaceri și acele obiecte de management pentru care este responsabil.

Este necesar ca managerul să creeze perspective asupra fluxului de produse care să prezinte informații logistice și analitice prin prisma unității strategice de afaceri cu care lucrează în cadrul funcțiilor sale.

Pentru a asigura lucrul cu sistemul informatic în acest mod, acesta trebuie să implementeze capacitatea de a atribui vizualizări ale produselor și vizualizări ale obiectelor de management.

În același timp, există cel puțin două tipuri de bază de vizualizări ale produsului - statice și dinamice.

Fiecare manager are propria sa perspectivă asupra produsului, care îi definește unitatea strategică de afaceri. În acest caz, managerilor responsabili pentru aceeași unitate de afaceri li se atribuie o singură vizualizare.

În cazul definirii unei vizualizări statice a produsului, un set de produse este de fapt înregistrat ca o listă cu nume (Fig. 3.6). Este convenabil pentru fixarea strictă a unui set (de exemplu, pentru analiză).

Orez. 3.6.

Pentru a administra eficient vizualizările produselor pentru definirea unităților de afaceri, este mai bine să le definiți pe nodurile clasificatorului de produse. Să numim astfel de vederi dinamice (Fig. 3.7).

Orez. 3.7.

În acest caz, de îndată ce un produs nou este introdus într-un anumit subgrup, care este inclus în perspectiva dinamică a managerului de categorie, acesta devine automat un element al unității strategice de afaceri, iar managerul începe să lucreze cu el prompt.

Când un produs este mutat într-un alt subgrup (de exemplu, din cauza unei modificări de categorizare), acesta se mută într-o altă unitate strategică de afaceri și este transferat automat unui alt manager de categorie pentru muncă.

Vederea obiectelor de management este formată într-un mod similar - aceasta este o vedere statică care definește lista magazinelor și centrelor de distribuție în care funcționează un anumit manager de categorie (Fig. 3.8).

Orez. 3.8.

Această abordare permite utilizatorilor sistemului, inclusiv producătorilor sau furnizorilor de mărfuri, să acceseze informațiile și funcțiile necesare ale sistemului informațional dintr-un anumit subset al gamei de produse active și al obiectelor comerciale corespunzătoare.

Această funcție este foarte importantă în implementarea conceptului de logistică VMI, atunci când un furnizor sau producător este implicat în gestionarea lanțului de aprovizionare a mărfurilor „lor”.

În concluzie, să formulăm câteva concluzii din cele de mai sus:

• 1) gestionarea sortimentului unei întreprinderi comerciale este cea mai importantă sarcină, a cărei calitate a soluției determină direct succesul acesteia;
• 2) soluțiile la grupul extern de probleme de gestionare a sortimentelor, în special întreprinderile de retail de format mare, sunt concepute pentru a furniza sisteme de informare a clienților (chioșcuri de informații, terminale multimedia, cărucioare de informații etc.);
• 3) capacitatea de a menține matrice de sortiment, vizualizări de produse și vizualizări ale obiectelor de management în sistemul informațional facilitează capacitatea de a rezolva un grup intern de sarcini de gestionare a sortimentelor, care este direct legată de calitatea implementării funcției de management al categoriei la o întreprindere comercială .

Scalabilitatea sistemului informatic

Pe măsură ce se dezvoltă o companie de vânzare cu amănuntul online, uneori vine un moment în care sistemul informațional nu mai poate susține creșterea ulterioară a afacerii. Prin urmare, problema adecvării sistemului informațional la creșterea companiei este extrem de importantă.

În acest caz, trebuie luate în considerare două aspecte - adecvarea la creștere și scalabilitatea sistemului.

Dacă creșterea unei companii este însoțită de o creștere disproporționată a costurilor infrastructurii IT, atunci sistemul informațional nu este capabil să susțină în mod optim expansiunea afacerii.

Sistemele informatice care sunt inadecvate pentru creșterea companiei pot duce la o creștere accelerată a costurilor de funcționare a acestora.

În primul rând, arhitectura soluției trebuie să corespundă creșterii companiei. Atunci când o companie crește și are sute de facilități, construirea unui sistem pe o arhitectură distribuită înseamnă, în opinia noastră, să te confrunți cu o creștere din ce în ce mai mare a costurilor de suport IT per magazin.

În contextul unei companii de rețea care administrează o sută sau mai multe puncte de vânzare cu amănuntul, devine din ce în ce mai dificil să sincronizați datele cu consolidarea ulterioară a acestora în centru și vine un moment în care acest lucru devine imposibil.

Pentru a asigura scalabilitatea sistemului informatic (capacitatea de a oferi numărul necesar de utilizatori, de a opera cu cantitatea necesară de informații cu performanțe satisfăcătoare), este necesar să alegeți platforma potrivită - software și hardware de server adecvat.

Dacă o companie de retail este în creștere, volumul informațiilor de vânzări se calculează nu în gigaocteți, ci în terabytes, iar acest lucru nu se poate face fără utilizarea unor sisteme de gestionare a bazelor de date „industriale”, scalabile, precum Oracle, Progress etc.

Vor fi necesare și sisteme de operare, cu ajutorul cărora s-ar putea „migra” la o altă clasă de echipamente de calcul.

Este evident că atunci când aleg un sistem informațional și îl operează, companiile lanțului de retail a căror strategie implică o creștere rapidă trebuie să se gândească serios la scalabilitatea și costul de proprietate al sistemului informațional.

Suntem convinși că pe măsură ce o companie crește, arhitectura distribuită devine un obstacol colosal în calea reducerii costurilor de management al afacerii și de operare a infrastructurii IT.

Arhitectura centralizata a sistemului informatic presupune un cost de proprietate mai mic si nu necesita o crestere constanta a numarului de personal IT pe masura ce reteaua de retail creste.

Se referă la capacitatea unui sistem, rețea sau proces de a gestiona o creștere a volumului de lucru (își crește performanța) atunci când sunt adăugate resurse (de obicei hardware).

Scalabilitatea este un aspect important al sistemelor electronice, pachetelor software, sistemelor de baze de date, routerelor, rețelelor etc., dacă necesită capacitatea de a funcționa sub sarcină mare. 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.

Verticală și

Scalare pe verticală

Scalare pe verticală- creșterea performanței fiecărei componente a sistemului pentru a îmbunătăți performanța generală. Scalabilitate în acest context înseamnă capacitatea de a înlocui componentele unui sistem de calcul existent cu altele mai puternice și mai rapide, pe măsură ce cererile cresc și tehnologia evoluează. Acesta este cel mai simplu mod de scalare, deoarece nu necesită nicio modificare a programelor de aplicație care rulează pe astfel de sisteme.

Scalare orizontală

Scalare orizontală- împărțirea sistemului în componente structurale mai mici și distribuirea acestora pe mașini fizice separate (sau grupuri ale acestora) și (sau) creșterea numărului de servere care îndeplinesc aceeași funcție în paralel. Scalabilitate în acest context înseamnă capacitatea de a adăuga noi noduri, servere, procesoare la sistem pentru a crește performanța generală. Această metodă de scalare poate necesita modificări ale programelor, astfel încât programele să poată profita din plin de cantitatea crescută de resurse.

Indicatori

Vezi si

Note

Legături

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

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

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

Scalare verticală și orizontală, scalare pentru web

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

Capacitățile de scalare pentru serverele de baze de date sunt determinate de soluțiile software utilizate: 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 cea de-a doua opțiune, de exemplu, MongoDB, va fi mult mai profitabilă din punct de vedere financiar și nu va necesita setări care necesită forță de 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 de CPU și RAM; astfel de servere au un cost semnificativ.

Scalare orizontală
Cu MongoDB poți adăugați un alt 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 limitări și atunci când acestea sunt atinse sau când costul unui server mai puternic se dovedește a fi nerezonabil de mare, se adaugă noi mașini. 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 bazele de date relaționale și NoSQL este o situație care apare cel mai des. Serverele frontend și backend sunt, de asemenea, scalabile.

Citiți despre echilibrator

Un număr în continuă creștere de vizitatori ai site-ului web este întotdeauna o mare realizare pentru dezvoltatori și administratori. Desigur, cu excepția acelor situații în care traficul crește atât de mult încât blochează serverul web sau alt software. Întreruperile constante ale site-ului web sunt întotdeauna foarte costisitoare pentru companie.

Cu toate acestea, acest lucru poate fi remediat. Și dacă acum te gândești la scalare, ești pe drumul cel bun.

Pe scurt, scalabilitatea este capacitatea unui sistem de a gestiona un volum mare de trafic și de a se adapta la creșterea acestuia, menținând în același timp UX-ul dorit. Există două metode de scalare:

• Verticală (numită și scalare): creșterea resurselor sistemului, cum ar fi adăugarea de memorie și putere de procesare. Această metodă vă permite să rezolvați rapid problemele legate de procesarea traficului, dar resursele sale se pot epuiza rapid.
• Orizontală (sau extindere): adăugarea de servere la cluster. Să aruncăm o privire mai atentă la această metodă.

Ce este scalarea orizontală?

Mai simplu spus, un cluster este un grup de servere. Un echilibrator de încărcare este un server care distribuie sarcina de lucru între serverele dintr-un cluster. În orice moment, puteți adăuga un server web la un cluster existent pentru a gestiona mai mult trafic. Aceasta este esența scalarii orizontale.

Echilibratorul de încărcare este responsabil doar pentru a decide care server din cluster va procesa cererea primită. Practic, funcționează ca un proxy invers.

Scalare orizontală este, fără îndoială, o metodă mai fiabilă de creștere a performanței aplicației, dar este mai dificil de configurat decât scalarea verticală. Sarcina principală și cea mai dificilă în acest caz este să păstrați în mod constant toate nodurile aplicației actualizate și sincronizate. Să presupunem că utilizatorul A trimite o cerere către mydomain.com, după care echilibratorul transmite cererea către serverul 1. Apoi cererea utilizatorului B va fi procesată de serverul 2.

Ce se întâmplă dacă utilizatorul A face modificări în aplicație (de exemplu, încarcă un fișier sau actualizează conținutul bazei de date)? Cum poate fi transmisă această modificare către restul serverelor din cluster?

Răspunsul la aceste și alte întrebări poate fi găsit în acest articol.

Separarea serverelor

Pregătirea sistemului pentru scalare necesită separarea serverelor; este foarte important ca serverele cu mai puține resurse să aibă mai puține responsabilități decât serverele mai mari. În plus, împărțirea aplicației în aceste „părți” vă va permite să identificați rapid elementele sale critice.

Să presupunem că aveți o aplicație PHP care vă permite să vă autentificați și să încărcați fotografii. Aplicația se bazează pe stiva LAMP. Fotografiile sunt salvate pe disc, iar linkurile către ele sunt stocate în baza de date. Provocarea aici este de a sprijini sincronizarea între mai multe servere de aplicații care partajează aceste date (fișiere încărcate și sesiuni de utilizator).

Pentru a scala această aplicație, trebuie să separați serverul web și serverul bazei de date. Astfel, în cluster vor apărea noduri care partajează serverul bazei de date. Acest lucru va crește performanța aplicației prin reducerea încărcării pe serverul web.

În viitor, puteți configura echilibrarea sarcinii; Puteți citi despre acest lucru în manualul „”

Consecvența sesiunii

Cu serverul web și baza de date separate, trebuie să vă concentrați pe gestionarea sesiunilor utilizatorilor.

Baze de date relaționale și sisteme de fișiere de rețea

Datele sesiunii sunt adesea stocate în baze de date relaționale (cum ar fi MySQL), deoarece sunt ușor de configurat.

Cu toate acestea, această soluție nu este cea mai fiabilă, deoarece în acest caz sarcina crește. Serverul trebuie să scrie fiecare citire și scriere în baza de date pentru fiecare cerere, iar dacă există o creștere bruscă a traficului, baza de date va eșua de obicei înaintea altor componente.

Sistemele de fișiere din rețea sunt o altă modalitate simplă de stocare a datelor; acest lucru nu necesită modificări ale codului sursă, dar sistemele de rețea procesează operațiunile I/O foarte lent și acest lucru poate avea un impact negativ asupra performanței aplicației.

Sesiuni lipicioase

Sesiunile sticky sunt implementate pe echilibrator de încărcare și nu necesită nicio modificare a nodurilor aplicației. Aceasta este metoda cea mai convenabilă pentru gestionarea sesiunilor utilizator. Echilibratorul de încărcare va direcționa întotdeauna utilizatorul către același server, eliminând nevoia de a distribui datele de sesiune între nodurile rămase din cluster.

Cu toate acestea, această soluție are și un dezavantaj serios. Acum echilibratorul nu numai că distribuie sarcina, ci are o sarcină suplimentară. Acest lucru îi poate afecta performanța și poate duce la blocarea acestuia.

Servere Memcached și Redis

De asemenea, puteți configura unul sau mai multe servere suplimentare pentru a procesa sesiunile. Acesta este cel mai fiabil mod de a rezolva problemele legate de procesarea sesiunii.

Acțiuni finale

Scalarea orizontală a unei aplicații poate părea o soluție foarte complicată și confuză la început, dar ajută la eliminarea problemelor grave de trafic. Principalul lucru este să învățați cum să lucrați cu un echilibrator de încărcare pentru a înțelege ce componente necesită o configurație suplimentară.

Scalarea și performanța aplicației sunt foarte strâns legate. Desigur, nu toate aplicațiile și site-urile au nevoie de scalare. Cu toate acestea, este mai bine să vă gândiți la acest lucru în avans, de preferință în etapa de dezvoltare a aplicației.

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

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.