Perché i grandi siti utilizzano più server invece di un server con specifiche migliori?

Ho letto che Stack Overflow utilizza 10 o più server per servire il sito Stack Overflow. Server diversi hanno funzioni diverse come proxy inverso, server di database o server HTTP.

Ho visto un potente server singolo standalone con queste specifiche:

• 2 x Xeon E5-2630v2 a 2,60 GHz, 12 core totali, 24 thread; 30 MB
• 64 GB Reg. ECC DDR3 fino a 768 GB a 1600 MHz
• 4 x 120 GB Intel 520/530 Series (IOPS casuali 80k, ~ 550 MB / s)
• HP iLo4 Advanced con porta di gestione Ethernet dedicata.

Perché non utilizzare un singolo server con specifiche più elevate come 768 GB RAM, 20 TB + HDD, 4+ x Xeon? Quali sono i vantaggi dell'utilizzo di molti server o gli svantaggi dell'utilizzo di un singolo server ad alta specifica?

Un singolo server potente può essere aggiornato solo finora. Una volta che hai a disposizione il server più potente, il tuo sito non può crescere di più senza dividerlo tra i server o renderlo più efficiente.

C'è anche il fattore costo. Un singolo server che è super potente può costare dieci volte tanto quanto due server che sono la metà potenti. Vuoi essere in grado di acquistare il tuo hardware al prezzo più basso e non essere bloccato in un prezzo più alto perché è l'unica cosa che funzionerà.

Anche l'uptime e l'affidabilità entrano in gioco. Con due o più server, uno può non funzionare o essere disattivato per manutenzione e il sito può rimanere attivo. Non puoi farlo con un singolo server.

La maggior parte dei siti Web di grandi dimensioni utilizza bilanciatori di carico e più server. Lavoravo per TripAdvisor. Hanno pubblicato un ottimo articolo sull'architettura di TripAdvisor e su come renderlo altamente scalabile con più server.

È possibile eseguire un servizio avanzato su un singolo server. Un esempio che conosco è Mailinator. L'autore ha pubblicato un articolo sull'architettura di Mailinator . Si concentra sul rendere il suo codice più efficiente piuttosto che sull'acquisto di nuovi server. Questo finisce per essere un limite che determina come funziona il suo servizio. Mantiene la posta solo poche ore prima che la singola macchina la elimini per fare spazio per altro.

L'aggiornamento di un singolo server è noto come ridimensionamento verticale . L'aggiunta di più server è nota come ridimensionamento orizzontale . Per ulteriori informazioni su questo argomento, ecco alcuni articoli che confrontano i due:

• Wikipedia: ridimensionamento orizzontale e verticale
• Pensieri IBM sul cloud: come spiegare il ridimensionamento verticale e orizzontale nel cloud
• Video internap: ridimensionamento verticale vs orizzontale

Dall'ammiraglio Grace Hopper:

Sulla costruzione di computer più grandi: "Ai tempi dei pionieri usavano i buoi per tirare pesantemente e quando un bue non riusciva a muovere un tronco, non cercavano di far crescere un bue più grande. Non avremmo dovuto cercare computer più grandi, ma per più sistemi di computer ".

fonte

Stephen spiega la principale considerazione da prendere quando si decide su un'architettura di sistema: il compromesso nel ridimensionamento verticale e orizzontale. Aggiungerò alcune altre considerazioni:

• Separazione delle preoccupazioni: menzioni più sistemi radicalmente diversi: proxy inversi, DB, server di contenuti, ecc. Dal punto di vista della manutenzione e della sicurezza è chiaramente vantaggioso mantenere queste responsabilità distribuite su sistemi diversi in modo che possano eseguire un sistema operativo diverso (versione) se necessario, può essere aggiornato separatamente e non influire su altri servizi quando compromesso.
• Consegna dei contenuti: questo è l'obiettivo finale di un web server e si presta bene a un modello distribuito. I sistemi possono essere duplicati e distribuiti geograficamente in modo da ridurre al minimo la latenza delle connessioni a lunga distanza. Inoltre consente la ridondanza . I siti Web di grandi dimensioni utilizzano i servizi di bilanciamento del carico (un altro set di server!) Per consentire il failover automatico per mantenere il servizio sempre attivo.

In realtà esiste un'intera classe di server che porta il ridimensionamento verticale a un altro livello: mainframe. Hanno una varietà di vantaggi (velocità, affidabilità) e svantaggi (costo) ma nel complesso sono generalmente utilizzati quando enormi volumi di dati devono essere gestiti tramite elaborazione Input-Output in ciò che chiamiamo elaborazione delle transazioni (pensiamo acquisti di carte di credito, operazioni bancarie , dati elettorali e di censimento). Le banche, ad esempio, servono siti da server Web in scala verticale mentre il back-end finirebbe per elaborare le transazioni tramite il mainframe.

È interessante notare che aziende come Paypal e Visa si sono allontanate dal mainframe verso sistemi raggruppati di migliaia di sistemi su scala orizzontale. Nel mondo digitale in rapida evoluzione, anche i mainframe stanno colpendo il massimale del ridimensionamento orizzontale:

"Con tutti i requisiti di disponibilità e prestazioni, non siamo riusciti a continuare a elaborare i pagamenti su mainframe,

Fonte: Adam Banks, in ComputerWorldUK

• Limite di dimensione. Ci piace far finta che una singola scatola con più processori, chip di memoria e dischi sia uniforme. Questo non è del tutto vero, ma è abbastanza vero se i tuoi numeri non diventano troppo grandi. Ci sono limiti tecnici su calore, energia, prossimità ecc. Ciò significa che ci sarà sempre un limite pratico su quanto può essere grande un singolo server.

• Scalabilità: esiste una grande differenza tra un sistema a server singolo, che utilizza la memoria condivisa per IPC e un sistema a più server che utilizza reti o clustering. Tuttavia, la differenza tra due server e 200 è considerevolmente più piccola: se hai creato un sistema che si ridimensiona, puoi ridimensionarlo MOLTO più grande prima che ci sia un problema ... e se lo hai, allora in realtà non è necessario un enorme server singolo innanzitutto.

• Resilienza: un server è un luogo in cui un amministratore potrebbe "oops". Oppure c'è un problema fisico che significa che il servizio all'intero pezzo di stagno viene interrotto. (Perdita d'acqua di Datacentre, qualcuno che si schianta contro un rack e lo fa cadere, quel genere di cose). Più server possono essere distribuiti all'interno di un datacenter o meglio ancora distribuiti geograficamente. E se stai già distribuendo la tua app, il ridimensionamento su macchine di medie dimensioni è quasi sempre più economico della stessa quantità di CPU / memoria / IO su un numero inferiore di macchine più grandi.

• Aggiornamenti - Se aggiorno un server, questo potrebbe rendere instabile un servizio, richiedere un riavvio o richiedere tempi di inattività. Se ho 4 server che eseguono la stessa cosa, posso farlo per un po 'fuori servizio per farlo. E lasciarlo fuori servizio se il ciclo di patch / aggiornamento va storto.

Prendiamo il problema su piccola scala. Un minuscolo ufficio con un server che esegue posta, ActiveDirectory, condivisione file e il sito Web dell'azienda.

Gli hacker lo colpiscono e devi riavviare perché IIS è incasinato. Oppure Exchange ha bisogno di un aggiornamento e di un riavvio. O Active Directory è stato danneggiato.

Ognuno di questi problemi isolati "un servizio è inattivo" interessa l'intero server, quindi qualsiasi condivisione su quel server avrà un impatto su di essi in virtù del riavvio o di qualsiasi altra cosa.

Una volta che un vero ragazzo IT si presenta e vede quel server, raccomanderà di suddividerli in server separati (e avere un server controller di dominio di backup).

È il vecchio adagio di "non mettere tutte le uova nello stesso paniere"

Ora quella filosofia è applicata ai server web. Se ho un solo server Web e pubblico la mia app Web (il nuovo MyFaceLink.com) e diventa molto popolare, ho nuovi problemi. Non riesco a smontare il sito per fare manutenzione mentre gli utenti ci sono. E se si blocca o ottengo troppi utenti, mi viene il brutto colpo. Anche il singolo server più grande del mondo verrà sopraffatto da 1 miliardo di FB in arrivo.

Quindi, il bilanciamento del carico entra in gioco, per lo stesso motivo "uova nel carrello". Distribuire il sito su 3 server e, in caso contrario, i restanti 2 gestiscono la capacità. Se devo fare delle patch, ne faccio una alla volta e nessuno se ne accorge.

In parole povere, non si tratta del prezzo del mega-server o se può davvero gestire il carico (anche se può essere). Si tratta di un singolo punto di errore. Una volta che l'attività è abbastanza occupata e si verifica 24 ore su 24, 7 giorni su 7 anziché per 5 utenti che lavorano 8-5, i tempi di fermo non sono accettabili. Le interruzioni programmate sono più difficili da pianificare. Quindi, dividi il carico.

Se si tenta di fare in modo che una macchina faccia il lavoro di due, alcune parti della macchina dovranno essere più grandi ma funzionare alla stessa velocità, alcune possono rimanere delle stesse dimensioni ma dovranno funzionare più velocemente e alcune dovranno essere più grandi e più veloce. La misura in cui ha senso combinare i ruoli di macchine più piccole in una più grande, o dividere i ruoli di macchine più grandi in macchine più piccole, dipende in gran parte dal tipo di ridimensionamento che si applicherebbe alle parti più costose delle macchine. Se i carichi di lavoro di troppe macchine vengono combinati in un unico enorme colosso, i costi saranno dominati da cose che dovrebbero essere più grandi epiù veloce per gestire maggiori carichi di lavoro. Anche se i costi di tali cose fossero lineari rispetto alla velocità e alle dimensioni, il raddoppio del carico di lavoro sarebbe più che raddoppiare il costo di una macchina per elaborarlo. Il fatto che la velocità aumenti oltre un certo punto comporta un aumento dei costi (molto) maggiore di quello lineare che ingrandisce l'effetto.

Non c'è davvero un punto fisso in cui la praticità costringe la suddivisione del lavoro; a seconda del tipo di lavoro da eseguire, una macchina che combina i carichi di lavoro di due potrebbe cavarsela con meno del doppio della memoria o funzionare a una velocità inferiore al doppio. D'altro canto, maggiore è il numero di compiti assegnati da una macchina, maggiore è la misura in cui i requisiti di memoria e velocità iniziano a ridimensionarsi in modo lineare con il carico di lavoro. Più si va oltre, maggiore è l'aumento del costo relativo per ogni raddoppio del carico di lavoro.