Infrastruttura web distribuita per carichi medi

E' impossibile fornire uno schema di rete e logico di una infrastruttura distribuita senza avere punti precisi da cui partire: necessità specifiche, requirements, idea dei flussi di dati previsti, indicazione dei servizi utilizzati ecc.
Proviamo comunque a fornire alcuni spunti che possono essere sviluppati ed adattati a casi specifici, mantenendo come riferimenti la necessità di gestire un sito dinamico in grado di erogare traffico medio giornaliero di qualche Megabit al secondo.

Hardware
Il dimensionamento delle singole macchine che vanno a costituire la struttura generale dipende ovviamente da innumerevoli fattori. Noi propendiamo per la serializzazione dell'hardware con tanti piccoli server a distribuire il carico, ma per alcuni servizi questo approccio presenta più problemi che benefici, per cui diventano preferibili singole macchine particolarmente potenti.
Per esempio se individuiamo 3 servizi logici in un sito complesso: web server, application server e  database server, i primi due potranno essere gestiti con una farm di macchine relativamente economiche a carico bilanciato, ma il database dovrà stare su hardware potente eventualmente in cluster.

Software
Le soluzioni Open Source permettono scalabilità e stabilità all'altezza del compito, ma per certe applicazioni critiche potrebbero essere sfavorite rispetto a soluzione proprietarie con un affidabile servizio di assistenza.
Il web server può, inevitabilmente, essere Apache.
L'application server può basarsi su PHP o Perl, con i relativi moduli, ma più probabilmente, per presenza sul mercato e buona scalabilità, potrà basarsi su Java.
Come database, Oracle potrebbe venir preferito a MySQL e PostgreSQL per assistenza, scalabilità, integrità e gestione delle transazioni sotto alto carico.
E' importante cercare di mantenere omoneneità nelle versioni dei sistemi operativi installati e implementare sistemi per un aggiornamento rapido del software di produzione e l'installazione di nuovi server (Jumpstart o Kickstart).

Backup
Su un sistema distribuito il backup deve preferibilmente essere centralizzato, con un backup server eventualmente collegato ad una SAN o una libreria di nastri.
E' pensabile, anche se aumenta considerevolmente la complessità del sistema, prevedere una LAN di amministrazione, che collega su una seconda interfaccia di rete i vari server, per l'accesso da parte degli amministratori, le operazioni di backup e di gestione, in modo che questo traffico non si sovrapponga con quello per i servizi di produzione.

Ridondanza
Oltre a soluzioni di clustering per certi servizi (tipicamente il database server) è pensabile una struttura con tanti piccoli server paralleli e bilanciati per i server Web.
In questi casi, oltre alla soluzione di load balancing scelta (appliance dedicata, soluzioni software come LVS ecc) è importante considerare la modalità di accesso ai dati da parte dei singoli server.
Le configurazioni e le pagine del sito web possono essere accessibili via rete, per esempio via NFS, da un unico punto centralizzato o distribuite con sistemi tipo rdist, rsync o cvs.
Ogni alternativa ha i suoi svantaggi e vantaggi.
Un unico repository raggiungibile via NFS garantisce l'integrità e l'omogeneità dei dati sui diversi web server ma aumenta latenza, point of failure e traffico di rete.
Un sistema di distribuzione dei contenuti sui singoli server richiede maggiore storage locale, rischia di portare a directory di documenti non omogenee sulle diverse macchine e richiede procedure custom per la distribuzione dei contenuti. Al contempo non ha i difetti di una soluzione basata su un network file system.

Sicurezza
Quando le macchine da gestire iniziano a diventare molte è consigliabile centralizzare le policy di packet filtering introducendo un firewall perimetrale che permette dall'esterno solo l'accesso ai servizi pubblici.
Tipicamente un simile firewall, che va ridondato, tende a riempirsi di specifiche regole per la gestione dei contenuti da parte di fornitori o redattori esterni, o per l'amministrazione remota da parte di partner vari ecc.
Il rischio diventa quindi quello di appesantire il firewall di frontend con molte regole specifiche.
In ogni caso, anche in presenza di un filtro esterno sui pacchetti in entrata, è opportuno eseguire un hardening minimo sulle macchine dietro il firewall: rimozione dei servizi inutili, aggiornamento dei software sia per i servizi di produzione che per quelli accessori.

Privacy Policy