bilanciamento del carico di più istanze orizzontali di drupal

Ho sviluppato un'API Web REST utilizzando il modulo Servizi. Funziona bene Ho un client di quell'API con utilizzo previsto che richiede il ridimensionamento orizzontale della mia istanza di Drupal. Si noti che a causa della natura della mia API, che richiede risorse significative di CPU e GPU, non riesco a utilizzare i server cloud. Inoltre, a causa della natura della mia API, le istanze di Drupal devono essere eseguite sul sistema operativo Windows. (La mia applicazione richiede software disponibile solo su Win64.) Ora ho un server abbastanza robusto in una posizione condivisa, e per questo ambizioso client ho intenzione di ridimensionare orizzontalmente il mio hardware nel modo seguente:

• Un server CentOS che esegue HaProxy come bilanciamento del carico front-end,
• Due per iniziare, con l'aggiunta di altri se necessario, server Windows Server 2008 R2 che ospitano Drupal,
• Un server di database CentOS che fornisce un singolo database per le istanze multiple di Drupal,
• Un server di database CentOS in esecuzione in modalità di replica in caso di interruzione del server DB 1.

Le mie domande riguardano il funzionamento del bilanciamento del carico HaProxy. Suppongo che gli sessionIds creati dalle istanze di Drupal siano unici l'uno dall'altro. Il bilanciamento del carico esamina sessionId e instrada tutte le richieste allo stesso server che ha prodotto tale sessionId? Come funzionerebbe una comunicazione RAP WebAPI se il bilanciamento del carico fa sì che ogni richiesta API passi a un server diverso? Qualunque dato a cui fa riferimento WebAPI deve essere archiviato nel database perché non posso assicurare che più richieste API per la stessa risorsa vengano instradate alla stessa istanza di Drupal?

Avere più server Web dietro un bilanciamento del carico / proxy inverso è abbastanza comune per Drupal e ben supportato. La vernice è generalmente usata nel mondo Linux perché quella cosa è follemente veloce quando è in grado di usarla effettivamente, il che significa visitatori anonimi. Il che ovviamente non è il caso del tuo sito.

Le sessioni sono memorizzate nel database per impostazione predefinita, quindi non è un problema. L'unica altra cosa che deve essere condivisa su tutti i server è la directory dei file pubblici e qualsiasi altra come i file privati ​​se stai usando qualcosa del genere). Nella maggior parte dei casi, viene utilizzato un file system condiviso / distribuito come NFS, sebbene esistano alcuni approcci più avanzati. In un sito in cui sono coinvolto c'è il file system fornito da un altro server che è un mount NFS sui server Drupal (quindi l'accesso è lento) e viene distribuito in un dominio diverso da Lighthttpd. Ma di nuovo, probabilmente non è così rilevante per te dato che non hai intenzione di server molte immagini e file CSS, immagino.

Come menzionato da rocketeerbkw, ci sono backend di cache per Memcache, Redis e altri. Finora ho usato solo Memcache ma di recente ho iniziato a esaminare Redis e sembra molto promettente ma non sono sicuro che sia disponibile per Windows. Tuttavia, sarebbe possibile configurare un server Linux separato da utilizzare per la cache. Drupal 7 si basa molto sulle cache, essere in grado di toglierle dal database è molto importante per due motivi:

1. Strumenti come Redis e Memcache sono progettati per ricerche rapide basate su tasti e mantengono i loro dati sempre in memoria per rendere la ricerca il più veloce possibile. Hanno anche integrato il supporto per la pulizia automatica dei vecchi dati della cache se il limite configurato si avvicina.

2. Forse ancora più importante, aiuta a scaricare il database. Dopo aver impostato la configurazione di base, aggiungere altri server web è semplice. Una volta che inizi a raggiungere i limiti di un singolo server di database, le cose diventano molto più complicate e devi esaminare cose come la replica master / master (Drupal 7 non guadagna molto dagli ambienti master / slave).

Quindi, è fondamentalmente solo la tua API di cui devi occuparti. Se possibile, è necessario assicurarsi che tutto sia sempre disponibile da tutti i server. Puoi usare il databse, il file system o qualcos'altro (Drupal può anche usare MongoDB per memorizzare determinati dati, ad es. Campi). Se questa non è un'opzione, dovrai utilizzare sessioni adesive in modo che gli utenti finiscano sempre sulla stessa istanza. Dovresti comunque cercare di evitarlo, perché se uno dei server fallisce, tutti gli utenti che si trovavano su quel server devono riconnettersi a un altro server, probabilmente perdendo i dati.

Per impostazione predefinita, PHP memorizza le sessioni su disco. Se un utente accede al Server 1, quindi accede al Server 2, verrà disconnesso. Ci sono alcune opzioni per risolvere questo problema:

1. Non archiviare sessioni su disco
2. Assicurarsi che gli utenti colpiscano sempre lo stesso server
3. Montare un filesystem condiviso su tutti i server

Per implementare # 2 e rispondere alle tue domande su HAProxy; Nella configurazione di base è possibile eseguirlo in modalità TCP e utilizzare l'algoritmo di bilanciamento "sorgente" ( http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#4-balance ) per assicurarsi che gli utenti colpiscano lo stesso server. Dovresti leggere i documenti per determinare se ci sono aspetti negativi per te usando questo approccio.

Per # 1 puoi usare un archivio chiave / valore come Redis o Memecached a cui tutti i tuoi server si connetterebbero e recupererebbero le sessioni. Questo fa sì che le sessioni vengano caricate / salvate molto rapidamente e puoi anche usarle come cache Drupal condivisa.