it-swarm.it

Quali potenziali problemi devo conoscere in un ambiente multi server / cluster?

Lavoro su un sito Web con un cliente da qualche tempo e il sito stesso è cresciuto enormemente in popolarità. Siamo ora nella fase in cui il singolo computer che ospita il sito sta lottando per soddisfare le richieste e abbiamo ottimizzato il sito stesso per quanto possiamo andare (memorizzazione nella cache, ecc.).

Siamo ora nella fase in cui è necessario aggiungere un altro server per sopportare la tensione aggiuntiva che porta alla mia domanda: quali potenziali insidie ​​e avvertenze sono necessarie per essere a conoscenza o testare il sito quando mi trasferisco in una Web farm o in un hosting cluster ambiente?

3
Wolfwyrd

Esistono diverse avvertenze possibili:

Sessions

Se le sessioni sono archiviate sul lato server, (ovvero PHP), entrambi i server dovranno accedere a un percorso di archiviazione delle sessioni condivise. Altrimenti, perderai sessioni poiché il bilanciamento del carico invia la richiesta da un server all'altro o, eventualmente, (sussulta) un utente con due sessioni uniche. Questo può essere particolarmente frustrante con AJAX. Le sessioni 'appiccicose' possono anche essere possibili, a seconda del bilanciamento del carico.

File temporanei

Entrambi i server dovrebbero condividere la stessa directory/tmp, se in effetti si utilizza qualsiasi tipo di file temporaneo mentre si lavora per soddisfare le richieste. Questo potrebbe essere un archivio temporaneo compresso per un download, un DB di file flat che tiene traccia di qualcosa, qualunque cosa.

Blocco SQLite

Se usi SQLite3, potresti notare alcune stranezze che non sono mai emerse prima, specialmente se stai usando qualcosa come NFS per condividere i file di database tra i server. NFS è lento con questo, quindi consiglio di usare qualcos'altro. I file system distribuiti come Lustre sono facili da configurare, oppure è possibile utilizzare GFS/OCFS2.

SSL

Probabilmente si desidera che il bilanciamento del carico sia ciò che gestisce l'handshake SSL, che quindi effettua la richiesta ai server back-end utilizzando qualsiasi vecchio certificato autofirmato.

Alcune note generali:

  • Come notato, utilizzare un file system ad alte prestazioni per la condivisione di directory. Tutti i file condivisi dovrebbero vivere su un archivio di rete, non su uno dei server web. Altrimenti, se si scende, entrambi sono inutili, in qualche modo sconfigge lo scopo.

  • Se il sito utilizza un RDBMS, hai due opzioni. Eseguirlo su entrambi i nodi e utilizzare una sincronizzazione master-master o posizionare il server DB nella propria home. Consiglio il secondo perché ciò offre ai server Web molto più spazio per il gomito.

  • Anche i sistemi di bilanciamento del carico necessitano di ridondanza.

Nella maggior parte dei casi, è possibile passare da un singolo server a una farm con bilanciamento del carico con poche o nessuna modifica al sito/all'applicazione stessa, ma è necessario assicurarsi che tutti i nodi possano leggere e scrivere negli stessi file. Ciò potrebbe richiedere l'aggiunta di una logica per il blocco dell'app stessa.

1
Tim Post

Lo stato della sessione (se si tratta di un problema) è un potenziale problema. La maggior parte delle appliance di bilanciamento del carico può utilizzare sessioni permanenti, il che significa che un utente che si avvia su SERVER1 rimarrà su SERVER1, in genere mediante l'uso di un cookie memorizzato nella memoria del browser. L'unica avvertenza è che quando SERVER1 si disconnette per qualsiasi motivo, l'utente dovrà accedere nuovamente su un altro server.

Ho iniziato a ignorare questo sulle mie app (sono app CF) condividendo sessioni nella server farm. Quindi una macchina che cade non avrà alcun impatto sull'esperienza dell'utente.

L'unica altra sfida che ho affrontato nel replicare correttamente il contenuto su tutti i server della farm. C'è un software là fuori per farlo (robocopy, Fling del software NCH sono due che ho usato), ma ho ancora avuto casi in cui la sincronizzazione non funzionava al 100% delle volte.

0
Milner

La tua applicazione ha a cuore lo stato? Se un utente ha una richiesta servita da una macchina e poi un'altra servita da un'altra, importa? Se è necessario mantenere una qualche forma di stato tra le richieste, allora tutto è più complicato e ci sono vari modi per affrontare il problema.

Se non devi preoccuparti dello stato, allora buon lavoro nel costruire il tuo sito, e le cose dovrebbero essere relativamente a posto con un proxy e alcuni server back-end.

Se è necessario mantenere lo stato, ci sono vari modi per creare una sessione adesiva tramite il proxy in modo che lo stesso server back-end gestisca tutte le richieste da un singolo utente, ma ci sono anche molte cose che rendono difficili quelle sessioni da mantenere appiccicose .

È inoltre possibile mantenere lo stato in un supporto comune sul back-end, quindi ogni server caricherà lo stesso stato per lo stesso utente. Puoi farlo con un database (forse troppo lento) o qualcosa del genere memcached .

Stai aumentando anche il numero di server di database? Ciò porterà un altro mucchio di problemi di cui preoccuparsi.

Alcuni dei problemi della sessione sono discussi nel podcast di overflow dello stack Numero 6

Per i test, assicurati di colpire con forza un cluster di test simile in modo da poter vedere come fanno le tue richieste quando sono dirette su molti server, perché molte richieste dallo stesso client a backend diversi sono dove è probabile che tu abbia problemi, quindi assicurati qualcosa nel piano di test fa sì che ciò accada.

Potresti anche leggere informazioni su Stack Overflow configurazione di rete

0
danivovich