De ce folosesc site-urile mari mai multe servere în loc de un singur server cu specificații mai bune? (Webmasteri, Găzduire Web, Server, Găzduire Dedicată, Arhitectură, Scalabilitate)

utilizator43396 a intrebat.

Am citit că Stack Overflow folosește 10 sau mai multe servere pentru a servi site-ul Stack Overflow. Serverele diferite au funcții diferite, cum ar fi proxy invers, server de baze de date sau server HTTP.

Am văzut un singur server puternic de sine stătător cu aceste specificații:

  • 2 x Xeon E5-2630v2 @2,60 GHz, total 12 nuclee, 24 fire; 30 MB
  • 64 GB ECC Reg. până la 768 GB DDR3 la 1600 MHz
  • 4 x 120 GB Intel 520/530 Series (80k IOPS aleatoriu, ~550 MB/s)
  • HP iLo4 Advanced cu port de management Ethernet dedicat.

De ce nu folosiți un singur server cu specificații mai mari, cum ar fi 768 GB RAM, 20 TB + HDD, 4+ x Xeon? Care sunt avantajele utilizării mai multor servere sau dezavantajele utilizării unui singur server cu specificații ridicate?

Comentarii

  • SE nu numai că are peste 10 servere, dar are și o configurație duplicată într-un alt centru de date pentru failover. În plus, nu s-a inventat încă serverul care să poată gestiona tot traficul Facebook sau Google. –  > Por Michael Hampton.
  • Ce se întâmplă când trebuie să reporniți acel super server? –  > Por Liath.
  • Redundanță… 🙂 –  > Por William Edwards.
  • Paralelismul… –  > Por Curse de luminozitate pe orbită.
  • @SSpoke: nu sunteți limitat la o singură conexiune pe port. Tot ceea ce contează este ca combinația de (adresă src, port src, adresă dst, port dst) să fie unică. –  > Por David.
6 răspunsuri
Stephen Ostermiller

Un singur server puternic poate fi actualizat doar până la un anumit punct. Odată ce aveți cel mai puternic server disponibil, site-ul dvs. nu poate crește mai mult fără a-l împărți între servere sau fără a-l face mai eficient.

Există, de asemenea, factorul cost. Un singur server care este super puternic poate costa de zece ori mai mult decât două servere care sunt pe jumătate la fel de puternice. Vreți să puteți cumpăra hardware-ul la prețul cel mai ieftin și nu să fiți blocat la un preț mai mare pentru că este singurul care funcționează.

Timpul de funcționare și fiabilitatea intră, de asemenea, în joc. Cu două sau mai multe servere, unul dintre ele poate da greș sau poate fi scos din funcțiune pentru întreținere, iar site-ul poate rămâne în funcțiune. Nu se poate face acest lucru cu un singur server.

Cele mai multe site-uri web mari folosesc balansatoare de sarcină și servere multiple. Am lucrat pentru TripAdvisor. Au publicat un articol grozav despre arhitectura TripAdvisor și cum o fac foarte scalabilă cu mai multe servere.

Acesta este posibil să rulezi un serviciu avansat pe un singur server. Un exemplu pe care îl știu este Mailinator. Autorul a publicat un articol despre arhitectura lui Mailinator. El se concentrează pe eficientizarea codului său, mai degrabă decât pe cumpărarea de servere noi. Acest lucru sfârșește prin a fi o limitare care dictează modul în care funcționează serviciul său. Acesta păstrează corespondența doar câteva ore înainte ca o singură mașină să o șteargă pentru a face loc altora.

Actualizarea unui singur server este cunoscută sub numele de scalare pe verticală. Adăugarea mai multor servere este cunoscută sub numele de extinderea pe orizontală. Pentru mai multe informații despre acest subiect, iată câteva articole care compară cele două:

Comentarii

  • Dacă aveți mai multe servere (mai multe decât câteva), iar unele cpu mor, aveți celelalte servere pentru a menține totul în funcțiune. Dacă ai 1 server, iar acela se strică, ești terminat. –  > Por Martijn.
  • Un alt aspect pe care oamenii îl uită este că nu este neapărat un lucru bun să rulezi un server la capacitate maximă sau aproape de ea. Noi am măsurat serverele noastre la o companie globală de telecomunicații (care va rămâne anonimă) la aproximativ jumătate din capacitatea maximă ca regulă generală (fără o logică reală în spatele acesteia – doar urmărind metricile). La un moment dat, începi să ai probleme cu coada de calcul, cu subsistemele IO, cu adresarea și schimbul de memorie și așa mai departe, indiferent de capacitatea hardware, pur și simplu pentru că echilibrul dintre subsisteme poate intra în conflict, în funcție de sistemul de operare, bineînțeles. Există unele sisteme robuste care permit mai mult. –  > Por closetnoc.
  • @closetnoc Cred că cel mai bun mod de a-l descrie este că încercați să evitați blocajele. Un sistem corect echilibrat ar putea teoretic să funcționeze la 100% din capacitate fără efecte secundare negative, dar orice lucru pe care sistemul trebuie să aștepte (timp de procesare, I/O, transfer de bus, etc…) va cauza probleme de performanță. Prin rularea sistemelor la jumătate din capacitatea maximă, ați găsit un punct bun în care nu vă confruntați cu astfel de blocaje. –  > Por Thebluefish.
  • @Thebluefish Da și nu. Sunt un tip vechi de sistem intern. Cele mai multe sisteme au blocaje în sistemul de operare și în hardware-ul intern care nu pot fi compensate cu raiduri, memorie, CPU-uri etc. mai rapide. La fel de bine, există limite în cadrul sistemului de operare. Windows a fost destul de bun pentru că se baza pe VMS, dar avea totuși limite care nu puteau fi reglate ca VMS. Linux este evident mai bun. Unele servere sunt proiectate cu mici limitări hardware, cum ar fi HP, pe care noi l-am folosit. Dar chiar și atunci, nu este niciodată o idee bună să rulezi o coadă de calcul la o capacitate de 100% din cauza creșterii numărului de întreruperi și a schimburilor de procesoare. –  > Por closetnoc.
  • Un alt avantaj al scalării pe orizontală: nu există o cantitate limitată de energie electrică, lățime de bandă, răcire etc. pe care o puteți direcționa către un singur server. Netflix ar putea avea o cutie cu o putere de procesare și memorie infinită, dar nu i-ar folosi la nimic dacă nu ar avea o țeavă suficient de mare pentru a scoate traficul. –  > Por Chris Hayes.
もしもしし

De la contraamiralul Grace Hopper:

Despre construirea de computere mai mari: „Pe vremea pionierilor, se foloseau boi pentru tracțiuni grele și, când un bou nu putea mișca un buștean, nu încercau să crească un bou mai mare. Nu ar trebui să încercăm să facem calculatoare mai mari, ci mai multe sisteme de calculatoare.”

sursa

Comentarii

  • Am întâlnit-o pe Grace Hopper de câteva ori la începutul carierei mele și am petrecut ceva timp cu ea. Era cu adevărat deosebită! O pisică tare! Cu toții o iubeam. Era atât de amabilă și generoasă cu timpul și harurile ei (joc de cuvinte). Felicitări pentru că ați citat-o! Un vot în plus pentru „way-back”. Mulțumesc! –  > Por closetnoc.
  • Deși este un citat relevant, acesta nu răspunde la întrebare. Opinia nefondată a unei persoane nu ar trebui să fie valoroasă aici. –  > Por TankorSmash.
  • @NoahSpurrier Pentru că nu răspunde de fapt la nicio parte a întrebării? Este doar un citat care face o analogie nefundamentată și nu explică de ce ar trebui să tragem pentru mai multe servere. –  > Por Chris Hayes.
  • Aș spune că este un răspuns util, dar nu ar trebui să fie acceptat ca fiind răspunsul PRINCIPAL, deoarece nu detaliază motivele specifice. Cu toate acestea, el precizează în mod clar motivul general pentru principiul împărțirii încărcăturii. –  > Por Ian T. Small.
  • @Bobson Nu susțin deloc că este un jucător important, spun doar că aș vrea să văd un răspuns cu ceva conținut, în loc de o frază sau două care doar sună frumos. –  > Por TankorSmash.
Lilienthal

Stephen explică principalul considerent care trebuie luat în considerare atunci când se decide asupra unei arhitecturi de sistem: compromisul dintre scalarea verticală și cea orizontală. Eu voi adăuga alte câteva considerații:

  • Separarea preocupărilor: menționați mai multe sisteme radical diferite: proxy invers, BD, servere de conținut etc. Din punct de vedere al întreținerii și al securității, este în mod clar avantajos să păstrezi aceste responsabilități repartizate pe sisteme diferite, astfel încât acestea să poată rula un sistem de operare (versiune) diferit dacă este necesar, să poată fi actualizate separat și să nu aibă impact asupra altor servicii atunci când sunt compromise.
  • Furnizarea de conținut: acesta este scopul final al unui server web și se pretează bine la un model distribuit. Sistemele pot fi duplicate și răspândite geografic, astfel încât latența a conexiunilor la distanță este minimizată. De asemenea, acest model permite redundanță. Site-urile web mari utilizează echilibrul de sarcină (încă un set de servere!) pentru a permite o automat de redistribuire automată pentru a menține serviciul în funcțiune în orice moment.

Există de fapt o întreagă clasă de servere care duce scalarea verticală la un alt nivel: mainframe-urile. Acestea au o serie de avantaje (viteză, fiabilitate) și dezavantaje (costuri), dar, în general, sunt utilizate de obicei atunci când trebuie gestionate volume uriașe de date prin procesare de intrare-ieșire în ceea ce numim procesarea tranzacțiilor (gândiți-vă la achizițiile cu cărți de credit, operațiuni bancare, alegeri și date de recensământ). Băncile, de exemplu, deservesc site-urile de pe servere web cu scară verticală, în timp ce back-end-ul ar ajunge să proceseze tranzacțiile prin intermediul mainframe-ului.

Este interesant faptul că societăți precum Paypal și Visa au renunțat la mainframe și s-au orientat către sisteme grupate de mii de sisteme scalate orizontal. În lumea digitală în evoluție rapidă, chiar și mainframe-urile ating plafonul de scalare orizontală:

„Cu toate cerințele de disponibilitate și performanță, nu am mai putut continua să procesăm plăți pe mainframe-uri,

Sursa: Adam Banks, în ComputerWorldUK

Sobrique
  • Limita de dimensiune. Ne place să pretindem că o singură cutie cu mai multe procesoare, cipuri de memorie și discuri este uniformă. Acest lucru nu este în întregime adevărat, dar este suficient de adevărat dacă numerele nu devin prea mari. Există limite tehnice în ceea ce privește căldura, energia, proximitatea etc., ceea ce înseamnă că va exista întotdeauna o limită practică privind dimensiunea unui singur server.

  • Scalabilitate – există o mare diferență între un sistem cu un singur server, care utilizează memoria partajată pentru IPC și un sistem cu mai multe servere care utilizează rețele sau clustering. Cu toate acestea, diferența dintre două servere și 200 este considerabil mai mică – dacă ați construit un sistem care se adaptează, îl puteți adapta la o scară mult mai mare înainte de a apărea o problemă… și dacă ați făcut-o, atunci nu este nevoie de fapt de un singur server uriaș în primul rând.

  • Reziliență – Un singur server este un loc în care un administrator ar putea face „oops”. Sau există o problemă fizică care înseamnă că serviciul pentru întreaga tinichea este întrerupt. (Scurgere de apă în centrul de date, cineva care se lovește de un rack și îl răstoarnă, genul acesta de lucruri). Mai multe servere pot fi distribuite în cadrul unui centru de date sau, mai bine zis, distribuite geografic. Iar dacă vă distribuiți deja aplicația, scalarea pe mașini de dimensiuni „medii” este aproape întotdeauna mai ieftină decât aceeași cantitate de CPU/memorie/IO pe un număr mai mic de mașini mai mari.

  • Actualizări – Dacă pun patch-uri pe un server, acest lucru poate face ca un serviciu să devină instabil, să necesite o repornire sau să necesite în alt mod o anumită perioadă de indisponibilitate. Dacă am 4 servere care rulează același lucru, pot scoate unul din funcțiune pentru o perioadă de timp pentru a face acest lucru. Și să-l las în afara serviciului dacă ciclul de patch-uri/actualizări merge prost.

Ken Forslund

Să luăm problema la scară mică. Un birou micuț cu un singur server care rulează poșta electronică, ActiveDirectory, partajarea fișierelor și site-ul web al companiei.

Hackerii îl atacă și trebuie să reporniți pentru că IIS este stricat. Sau Exchange are nevoie de o actualizare și o repornire. Sau Active Directory a fost corupt.

Oricare dintre aceste probleme izolate de tipul „un serviciu nu funcționează” afectează întregul server, astfel încât orice partajare pe acel server va avea un impact asupra lor, în virtutea faptului că va trebui să repornească sau orice altceva.

Odată ce un tip IT adevărat apare și vede acel server, va recomanda împărțirea lor în servere separate (și un server de controler de domeniu de rezervă).

Este vorba de vechea zicală „nu-ți pune toate ouăle în același coș”.

Acum, această filozofie este aplicată serverelor web. Dacă am doar un singur server web și îmi public aplicația web (noua MyFaceLink.com) și aceasta devine foarte populară, am noi probleme. Nu pot opri site-ul pentru a face mentenanță în timp ce utilizatorii sunt pe el. Iar dacă se blochează sau dacă am prea mulți utilizatori, sunt terminat. Chiar și cel mai mare server din lume va fi copleșit de 1 miliard de convertiți la FB.

Deci, echilibrarea încărcăturii intră în joc, din același motiv „ouă în coș”. Împrăștiați site-ul pe 3 servere, iar dacă unul cade, celelalte 2 se ocupă de capacitate. Dacă trebuie să fac patch-uri, le fac pe rând și nimeni nu observă.

La modul cel mai simplu, nu este vorba de prețul mega-serverului sau dacă acesta poate face cu adevărat față încărcăturii (deși poate fi). Este vorba despre un singur punct de eșec. Odată ce afacerile sunt suficient de aglomerate și se întâmplă 24 de ore din 24, 7 zile din 7, în loc să fie pentru 5 utilizatori care lucrează de la 8 la 5, timpul de nefuncționare nu este acceptabil. Întreruperile programate sunt mai greu de programat. Așa că, repartizați sarcina.

Comentarii

supercat

Dacă se încearcă ca o singură mașină să facă munca a două, unele părți ale mașinii vor trebui să fie mai mari, dar să funcționeze la aceeași viteză, altele pot rămâne de aceeași dimensiune, dar vor trebui să funcționeze mai repede, iar altele vor trebui să fie mai mari și mai rapide. Măsura în care are sens să se combine rolurile mașinilor mai mici într-una mai mare sau să se împartă rolurile mașinilor mai mari în altele mai mici depinde în mare parte de tipul de scalare care se va aplica celor mai scumpe părți ale mașinilor. Dacă sarcinile de lucru ale prea multor mașini sunt combinate într-un colos uriaș, atunci costurile vor fi dominate de lucruri care ar trebui să devină mai mari și mai mari și mai rapide pentru a face față sarcinilor de lucru sporite. Chiar dacă costurile unor astfel de lucruri ar fi liniare în ceea ce privește viteza și dimensiunea, dublarea volumului de lucru ar însemna mai mult decât dublarea costului unei mașini pentru a-l procesa. Faptul că creșterea vitezei dincolo de un anumit punct determină o creștere a costurilor (mult mai mare decât cea liniară) amplifică efectul.

Nu există cu adevărat un punct fix în care caracterul practic obligă la subdivizarea muncii; în funcție de tipul de muncă ce urmează a fi efectuată, o mașină care combină sarcinile de lucru a două ar putea să se descurce cu mai puțin de două ori mai multă memorie sau să funcționeze la o viteză mai mică de două ori mai mică. Pe de altă parte, cu cât mai multe sarcini îi sunt încredințate unei mașini, cu atât mai mare este măsura în care cerințele de memorie și de viteză încep să scadă liniar cu volumul de muncă. Cu cât se depășește această limită, cu atât mai mare este creșterea costului relativ pentru fiecare dublare a volumului de lucru.