No more maintained.
Now just a test in a lab.
Design di una infrastruttura Web
Design della rete, dei server, dei servizi.
Introduzione al design di una web farm
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR
Le scelte su come strutturare una rete che debba erogare servizi Web, e non solo, dipendono da molti fattori diversi:
- Risorse economiche (il budget a disposizione per l'intero progetto)
- Skill disponibili (le conoscenze del personale interno, la disponibilità di consulenti esterni)
- Infrastruttura esistente (eventuali vincoli dovuti ad una situazione preesistente)
- Traffico previsto (è importante dimensionare le strutture per gestire senza problemi il carico previsto e scalare facilmente quando questo aumenta)
- Tipo di informazioni e servizi offerti online (se si trattano dati personali, sensibili, critici, come vanno inseriti e gestiti)
- Criticità del servizio (un'idea di quanto è sopportabile un down del servizio da indicazione sui sistemi di High Availability da implementare)
- Variabilità ed espandibilità del servizio (avere un'idea se la nostra web farm è destinata ad aumentare i servizi erogati).
- Necessità di interfacciamento con altri sistemi (se è necessario uno scambio di dati con altri sistemi, eventualmente non su Internet, se sono richieste compatibilità e interoperabilità con sistemi proprietari, ecc)
Questi ed altri fattori inevitabilmente influenzano il tipo di infrastruttura Web che si deve mettere in campo.
Semplificando, e lasciando a BOX di approfondimento i dettagli e le distinzioni del caso, possiamo ipotizzare tre principali categorie di implementazione:
Singolo server per gestire basso traffico - Può essere il singolo sito aziendale, statico o dinamico, con un traffico relativamente basso (meno di 2000 visite al giorno, gestibile con meno di 512Kb/s di banda) o anche un hosting server di un provider con vari siti virtuali con poco traffico.
Per simili casi può bastare una singola macchina Unix che contenga tutto quanto serve per erogare anche pagine dinamiche. Il trittico Apache-PHP-MySQL su piattaforma Linux appare una soluzione economica, affidabile e testata, ma non è certo necessariamente l'unica.
Le funzioni di firewalling possono essere fornite da un dispositivo esterno o anche dalla macchina stessa.
Infrastruttura distribuita per medi carichi - Può riferirsi a siti con traffico medio (da 512Kb/s a qualche Megabit al secondo) o caratteristiche complesse. In questo caso diverse macchine forniscono diversi servizi. Oltre a un DB server autonomo è legittimo prevedere uno o più application server, uno o più web server, eventuali cache server e firewall indipendenti. Un caso simile può presentare una notevole varietà di soluzioni e implementazioni, secondo i fattori sopra indicati e il livello di ridondanza richiesto
Infrastruttura complessa per alti carichi - Necessaria per gestire siti che erogano traffico per varie decine di Megabit al secondo. E' ovviamente distribuita, con diverse macchine, o pool di macchine, a fornire diversi servizi.
La scalabilità orizzontale dovrebbe essere prevista per ogni livello (i web server su cui viene fatto bilanciamento di carico devono poter aumentare in numero senza problemi, e lo stesso vale, per gli altri servizi), la ridondanza e l'high availability diventano, su siti ad alto traffico, quasi obbligatorie, per cui è prevedibile che si debba implemntare a tutti i livelli. Meccanismi di caching e staticizzazione delle pagine sono quasi obbligatori, visto l'alto carico e la natura quasi certamente dimanica di un simile sito.
Singolo Web Server per carichi bassi
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED
Se le nostre stime sul traffico Web da sostenere non sono alte e si presume che, quantomeno in una fase iniziale, possono bastare meno di, indicativamente, 512 Kbit di banda e un server in grado di gestire qualche centinaio di visite medie al giorno o qualche migliaia di pageviews, probabilmente una singola macchina può bastare.
Ovviamente è un'indicazione di massima, che si adatta a contesti medi con queste caratteristiche e necessità di uptime non estreme.
Se il nostro web server è il frontend di un datawarehouse di un TeraByte di dati, è ovvio che ci dovrà essere almeno una macchina separata per gestire il DB, se dovrà ospitare un sito estremamente sicuro, si dovrà considerare una o più macchine aunomome con funzioni di intrusion detection e traffic analysys, se il servizio deve avere uptime nell'ordine del 99,9% ci sarà da considerare l'implementazione di un cluster o di un'altra struttura di HA, e così dicendo.
Dimensionamento hardware
Casi particolari a parte, le necessità richieste possono essere erogate con un sistema Linux munito di Apache + PHP o Mod_Perl, con database MySql su un singolo server Intel Based, con RAM di almeno 256Mb (minimo), dischi EIDE di capacità sufficienti per ospitare le pagine web e i dati del DB, scheda di rete a 10/100 Mbit/sec, processore Pentium 3 o superiore.
Ovviamente visti i costi sempre descrescenti dell'hardware, è preferibile acquistare una macchina nuova, con le garanzie di assistenza del caso, che ormai offre capacità superiori.
La RAM, in particolare influisce sulle prestazioni del server, i 256 MB indicati probabilmente non bastano a riempire i 512 Mbit di banda ipotizzati con contenuti dinamici.
Software installati
Se la scelta è l'OpenSource le soluzioni sono quasi ovvie: Linux o *BSD come sistema operativo, Apache come web server, PHP o Perl come linguaggio più comune per la gestione di pagine dinamiche (anche se le alternative sono molte), MySQL o PostgreSQL come database server. Si possono installare programmi o servizi specifici (ftp server per l'uplodad delle pagine del sito, traffic analyzer per statistiche sul traffico web ecc.) e considerare l'uso di un sistema di firewalling interno: le Iptables su Linux sono estremamente efficaci e "leggere" e rappresentano un buon modo per limitare l'accesso pubblico a tutte le porte che non siano l'80 su cui deve essere erogato il servizio web pubblico.
Impostazione della struttura applicativa
Molte scelte che influenzano in modo determinante la possibilità di espansione di un sito dipendono da come si impostano, fin dall'inizio, le strutture a livello applicativo.
MAI, per quasi nessun motivo, si dovrebbe inserire all'interno del codice (PHP, Perl o altri) degli indirizzi IP fissi, che inchiodano il server ad uno specifico indirizzo che renderebbe complicata e faticosa ogni migrazione o upgrade.
Usare sempre nomi di host diversi per diversi servizi: se ci si deve collegare al database, chiamarlo in modo diverso da come si chiama la macchina su cui gira il web server (e il database stesso). Usare un alias, ad esempio db.openskills.info: il giorno in cui il sito crescerà e ci sarà bisogno di una macchina separata per il DB, basterà cambiare una entry nel DNS senza dover intervenire sul codice nelle pagine.
Individuare i diversi servizi logici del sistema chiamandoli con nomi diversi fin dall'inizio facilita la possibilità di scalare in tempi successivi.
Usare classi, oggetti, include: evitare di scrivere lo stesso dato legato al contesto specifico e quindi potenzialmente mutabile (per esempio i parametri di connessione al DB) in file diversi.
Backup dei dati
Esistono molteplici modi per fare un backup, l'unica cosa che li accomuna è il FARLO.
Non è pensabile, in alcuna situazione, di non prevedere un sistema di backup di qualche tipo dei propri dati.
Alcune regole generali possono comunque essere indicate:
- Eseguire un backup remoto, su una macchina diversa dal server stesso e, se possibile in un edificio diverso.
- Se non si hanno grandi quantità da backuppare è preferibile usare un hard disk più che un nastro, come medium su cui scrivere le copie: permette tempi di recovery più rapidi e maggiore affidabilità.
- Può bastare backuppare solo i dati (pagine del sito, dump del db) e le configurazioni custom, in caso di guasti un nuovo sistema Linux/Unix si mette in piedi in tempi relativamente rapidi.
- Valutare l'opportunità di avere un server di backup che operi anche come cold standby: con poche riconfigurazioni e procedure è possibile far diventare la macchina che fa la copia dei dati anche una macchina di backup per il servizio stesso.
- Fra i metodi di backup via rete più efficaci che conosciamo, per moli di dati nell'ordine dei Gigabyte, segnaliamo rsync che permette copie differenziali di intere directory fra macchine remote (e possibilità di ripristino dei dati in tempi rapidi e con pochi sforzi).
Ridondanza
Come sempre, il budget influenza in modo determinante le tecniche di ridondanza praticabili. Per il dimensionamento indicato, ipotizzando un budget ridotto, ci sentiamo di consigliare l'uso di hardware relativamente cheap (dischi IDE e non SCSI, niente mirror hardware, nessun specifico hardware di ridondanza) e prevedere la predisposizione di un server gemello, da usare per il backup e il cold standy.
Una simile configurazione, con un server principale in produzione, basato su economico hardware Intel-like e un server analogo configurato per eseguire regolare backup dei dati e già predisposto e configurato per offrire gli stessi servizi in caso di guasto del main server, può successivamente evolvere in una struttura ridondata più complessa, eventualmente con un hot standby.
In pratica, se il budget è un issue, l'esperienza di vari anni di utilizzo sia di hardware cheap che di soluzioni costose e più affidabili, ci porta a preferire una ridondanza completa di macchine economiche piuttosto che più costose soluzioni di ridondanza di singoli componenti.
Sicurezza
I requisiti minimi sono gli stessi prevedibili per ogni sistema presente su Internet:
- Esposizione ad IP pubblici solo delle porte strettamente necessarie per erogare il servizio;
- Aggiornamento costante, in presenza di nuove vulnerability, almeno del software che ascolta sulle porte pubbliche;
- Verifica di potenziali problemi di sicurezza degli script e delle pagine dinamiche a cui si può accedere tramite la porta pubblica (l'80, per il nostro web server).
Tutto quello che viene in più (Intrusion Detection a livello di rete, integrity check, statistiche ecc.) può essere utile o divertente, ma perde ogni significato se i 3 punti sopra elencati non vengono seguiti.
Per esporre il minor numero possibile di porte al pubblico, oltre ad eliminare tutti i servizi che di fatto non vengono utilizzati, si possono utilizzare firewall esterni o direttamente meccanismi di firewalling a livello dello stesso host.
Per certe porte ausiliarie (porta FTP per l'upload dei dati, porta TELNET o SSH per la gestione remota, porta utilizzata dal sistema di Network Backup in essere ecc.) è raccomandabile permettere l'accesso solo da range di IP limitati e fidati.
La struttura del network su cui appoggiare il proprio Web Server può ricalcare uno dei modelli tipici per il design di network pubblici, con presenza o meno di DMZ, firewall perimetrali e interni, bastion host ecc, la logica comunque deve rimanere quella esposta: lasciare accesso pubblico soltanto alle porte necessarie (solo la 80 per il server web), limitare il range di IP abilitati ad accedere a porte per i servizi accessori.
Infrastruttura web distribuita per carichi medi
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
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.
Logica del TOPIC e approccio in Aula
Tipo Infobox: TEACHER'S NOTES - Skill: 1- NOVICE
Questo topic tende a presentare una serie di informazioni di massima piuttosto generiche.
La cosa è quasi inevitabile, a meno che non si voglia scrivere molte più informazioni potendosi permettere di affrontare casi specifici con dovizia di particolari.
In se le info scritte sul topic sono le classiche regole di buon senso che sono facilmente immaginabili.
In aula si consiglia un approccio più pragmatico al problema.
Il docente dovrebbe esemplificare (eventualmente con disegni alla lavangna) la struttura di almeno due tipi di sito web:
- Sito a basso traffico basato su un singolo server
- Sito ad alto traffico basato su una struttura distribuita.
Su questi due esempi dovrebbe, a ruota libera, presentare possibili soluzioni di design per la gestione delle problematiche del caso: gestione dei contenuti (upload, backend ecc.), sicurezza (firewall e punti di accesso), sistemi di backup, strutture a più livelli (web-appl-db oppure cache-web-appl-db o soluzioni ibride basate su configurazione di Apache), gestione sistemistica (metodi di backup, metodi di accesso amministrativo alle macchine, gestione dei log...) ecc.
Il topic, durante il corso, dovrebbe avere quindi un approccio prevalentemente "cattedratico" senza componente pratica, ma diventa più interessante se ad una esposizione unidirezionale da parte del docente si stimolano gli interventi dei partecipanti, per valutare le diverse alternative che si possono valutare nel design di una rete complessa (per cui non esiste un unica soluzione assoluta, ma diverse possibilità basate su principi generali di buon senso sistemistico).