Jelastic Cloud: bilanciare i carichi di lavoro e migrare i servizi in modo rapido ed efficace

Con l’espressione load balancing o bilanciamento di carico ci si riferisce a quella particolare attività utile alla distribuzione ragionata del traffico e dei carichi di lavoro. La corretta gestione del problema del load balancing consente di distribuire le richieste sui vari nodi utilizzati per erogare applicazioni e servizi.

Si prenda in esame il caso di WordPress che abbiamo presentato nell’articolo Come ospitare WordPress e ogni tipo di applicazione grazie alla flessibilità di Jelastic Cloud.
Come abbiamo spesso ricordato, un CMS come WordPress è in generale molto semplice da installare e configurare ma i problemi puntualmente si presentano quando il proprio progetto comincia a diventare sempre più apprezzato e popolare.

Secondo le statistiche elaborate da W³Techs, il 35% di tutti i siti web a livello mondiale usano WordPress con il secondo CMS opensource per utilizzo – Joomla – che risulta staccatissimo al 2,7%. Alcuni tra i più importanti siti web a livello mondiale usano proprio WordPress per proporre informazioni ai lettori, ai clienti e per interagire con loro.
Eppure nonostante questa sconfinata popolarità, secondo Pagely i 3 principali problemi più spesso lamentati dagli utenti di WordPress hanno a che fare con: performance, sicurezza e malfunzionamenti.

Fonte: “What Are The Top Biggest Challenges Of WordPress Users“ (Medium).

Quando un sito web diventa improvvisamente lento è un problema perché ciò impatta direttamente sull’esperienza d’uso e potenziali clienti possono abbandonare subito l’acquisto nel caso dei siti di ecommerce.

Problematiche di sicurezza possono essere invece sfruttate da parte di malintenzionati per forzare il caricamento di codice nocivo sul sito WordPress altrui, per sottrarre informazioni personali e riservate, per danneggiare l’immagine e il business di un’impresa.

Talvolta, poi, aggiornamenti del CMS in sé o dei plugin installati possono causare malfunzionamenti sull’intero sito web richiedendo interventi incisivi con il rischio di presentare agli utenti un sito web non più fruibile.

Jelastic Cloud di Aruba consente di risolvere brillantemente questi ed altri problemi.

Load balancing con Jelastic Cloud di Aruba: come funziona

Come abbiamo visto negli altri articoli dedicati a Jelastic Cloud, la soluzione presentata in Italia da Aruba consente di usare un approccio intelligente basato sulla clusterizzazione per adattare la piattaforma al traffico e ai carichi di lavoro istantanei.
Con Jelastic Cloud si può usare una vera e propria batteria di nodi application server, nodi database, load balancer e così via che cresce o diminuisce a seconda delle esigenze del momento e sulla base di svariati parametri (gran parte dei quali configurabili dagli amministratori): Jelastic Cloud: scalabilità in orizzontale e in verticale.

Niente più siti web esasperatamente lenti o addirittura irraggiungibili al verificarsi di un improvviso picco di traffico in ingresso, come molto spesso accade – per esempio – nel caso dei siti di ecommerce durante il periodo dei saldi, nella settimana del Black Friday e così via.

Torniamo all’esempio di WordPress. Quando si allestisce un cluster con Jelastic Cloud di Aruba, la piattaforma consente di automatizzare la creazione dell’ambiente utile a gestire traffico e carichi di lavoro variabili.

Il menu a tendina Scaling strategy permette di definire la strategia da usare per l’aggiunta o la rimozione dinamica dei nodi chiamati a gestire il funzionamento dell’applicazione o del servizio.
Nell’articolo Jelastic Cloud: scalabilità in orizzontale e in verticale abbiamo visto che l’approccio applicato per la gestione dei nodi è personalizzabile anche in un secondo tempo ma in fase di creazione del cluster si può già indicare se si prevede che la propria applicazione debba gestire elevati, medi o ridotti carichi di lavoro.
Selezionando una voce piuttosto che un’altra, Jelastic Cloud di Aruba aggiungerà o toglierà i vari nodi nel momento in cui le CPU virtuali dovessero essere usate al di sopra o al di sotto di una certa soglia. Lasciando il puntatore del mouse sopra a ciascuna voce, si può sapere di più sulle “politiche” utilizzate da Jelastic Cloud optando per i “profili” Low Load, Medium Load o High Load. Ove necessario, Jelastic Cloud di Aruba aggiungerà uno o due nodi alla volta, a seconda del profilo scelto, per gestire situazioni in cui la piattaforma è chiamata a rispondere a un numero più consistente di richieste provenienti dai client simultaneamente connessi.

Cliccando su Change Environment Topology, come abbiamo già visto, è possibile verificare la struttura del cluster creato sul cloud da Jelastic. In verde è evidenziato il load balancer, in blu l’application server e più sotto gli altri elementi che concorrono al funzionamento dell’applicazione (database, sistemi di caching, storage, VPS e così via).

Allo stato attuale, la piattaforma offre quattro load balancer tra i quali è possibile scegliere: NGINX, HAProxy, Varnish e Apache Balancer.
In produzione, ovvero quando si deve erogare un’applicazione o un servizio a livello professionale, è altamente consigliabile configurare un load balancer su più nodi così da conferire all’intero sistema ridondanza e assicurare elevata disponibilità.

Per default, quando si crea un nuovo cluster WordPress con Jelastic Cloud viene automaticamente scelto NGINX come load balancer ma scegliendo di creare un progetto in proprio (New environment) si può decidere in totale autonomia.

Il meccanismo di bilanciamento di carico risulta quindi automaticamente attivo su più livelli, ad esempio anche sui database (che utilizzano un meccanismo di failover automatizzato oltre che di auto scaling e auto discovery) ed è possibile configurare un certo quantitativo di storage condiviso tra i vari application server.

Nell’esempio si vede come la procedura di creazione automatica del cluster WordPress abbia aggiunto anche 100 GB (casella Disk limit) di spazio condiviso aggiuntivo.

Migrare i servizi e aggiornare gli stack

Una volta configurato ad esempio un cluster WordPress, i file che compongono l’installazione core del CMS possono essere aggiornati usando semplicemente l’interfaccia di amministrazione dell’applicazione web.

Ciò che nel caso di Jelastic Cloud di Aruba è davvero interessante è che per qualunque stack in uso è possibile passare a una versione precedente o successiva senza perdere i dati.
Cliccando sull’icona Redeploy containers, si potrà migrare da una versione all’altra di qualsiasi stack.

Nell’immagine, come si vede, si può passare ad esempio da una versione di PHP all’altra; cosa utilissima perché i requisiti dei CMS sono soliti cambiare, anche radicalmente, nel corso del tempo. La stessa cosa, però, si può fare anche con gli altri stack, ad esempio con MariaDB Galera.

Optando per Sequential deployment with delay, i vari container saranno automaticamente aggiornati – uno per uno – con un ritardo di alcuni secondi in modo da ottimizzare l’operazione e non ingenerare fenomeni di irraggiungibilità temporanea dell’applicazione o del servizio.

Si tratta di un meccanismo efficiente e davvero meraviglioso perché in un colpo solo è possibile aggiornare i vari componenti che cooperano al funzionamento dell’applicazione in modalità “live”, senza causare problemi e mettendosi al riparo dalle varie vulnerabilità di sicurezza. Chi è abituato a lavorare direttamente sulla configurazione dei singoli server sa bene quanto sia problematico, senza usare qualche forma di orchestrazione, gestire le configurazioni software e gli aggiornamenti di ogni singolo componente in uso senza provocare downtime.

Cliccando sull’icona Config in corrispondenza di AppServer, è possibile controllare la configurazione dell’applicazione (nella cartella \webroot\ROOT si troveranno in questo caso i file di WordPress) e dello stack (nell’esempio, PHP).
Nella colonna di sinistra Jelastic Cloud fornisce i riferimenti diretti ai file di configurazione solitamente più utilizzati.
Il file redeploy.conf contiene l’elenco dei file che Jelastic Cloud di Aruba manterrà durante l’operazione di aggiornamento dei vari stack (icona Redeploy containers vista in precedenza).