Singolo Web Server per carichi bassi

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.

Privacy Policy