Velocissimo

Da My-Lab.

Versione delle 00:40, 19 gen 2012, autore: Admin (Discussione | contributi)
(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)

Argonauts.png

Veloce e sicuro. Così dev'essere il caricamento di un sito di qualità. Per questo ho fondato argonauts, un sistema potente, all'avanguardia e sicuro in grado di servire portali con le esigenze più diverse.

Indice

diagramma sintetico

Production argonauts server stack.png

argonauts

Bhost logo.png

Debian-logo.jpg

OpenVZ-logo.png

Argonauts è il successore di argon. È un VPS (virtual private server) con sede negli UK, 4 processori, 25 GByte di HD, 1,5 TB di banda mensile e 1,5Gbyte di memoria RAM a disposizione. L'elettricità, il raffredamento, il networking di base e l'hardware sono gestiti da bhost.net, con sede in Irlanda e un'esperienza che parte dal 2002.

Su argonauts è installato debian squeeze 6.0, il più diffuso ed efficace sistema operativo open source in ambito server, versione minimal, adatta ad un'amministrazione remota via ssh. L'accesso di root è tagliato fuori dalla shell, l'unica maniera per entrare al massimo livello è usare il pannello di gestione solusvm per openvz, oppure sudo.

Rete di consegna

I contenuti transitano attraverso numerosi servizi.


Varnish-logo-red-64.gif

Nginx-logo.png

Php-fpm-logo.gif

Mysql logo.jpg

(DNS argonauts (nscd), risolve l'indirizzo del servizio richiesto - temporaneamente disabilitato e reindirizzato sui server ovh.it/dominiofaidate.com, con intenzione di migrare su godaddy.com)

varnish, restituisce i contenuti non dinamici e frequenti direttamente dalla memoria del server

nginx, server web vero e proprio, restituisce i contenuti non dinamici, riscrive gli url, e gira le richieste dinamiche a php-fpm. nginx imposta un tempo di vita di un giorno per gli oggetti non dinamici, in modo che essi non vengano ulteriormente richiesti, sempre uguali a loro stessi, nel prossimo futuro

php-fpm, serve le pagine dinamiche. Su di esso sono montate le estensioni: memcache che con memcached memorizza dati in RAM, in maniera contigua tra le esecuzioni e apc cache del codice eseguito. Eventuali pagine già compilate vengono servite da memcached, senza passare per l'interprete php.

mysql, con cache e senza innodb, restituisce i risultati delle query

sicurezza

Dropbox logo.png

Ogni notte viene automaticamente eseguito un backup dello stato del database mysql. Questo backup viene collezionato insieme ad altri 7, uno per ogni giorno di una settimana, e inviato a dropbox, quindi su un server esterno, per avere sempre dati freschi in caso di failover hardware o software.

cron-apt aggiorna automaticamente il sistema all'ultima versione dei pacchetti disponibili. I log dell'aggiornamento vengono comunicati via email all'amministratore.

Le connessioni in ingresso sono filtrate da un firewall a livello kernel (iptables based). Vedi Iptables_and_OpenVZ per saperne di più.

monitoraggio

Urlogo.png

È stato attivato un sistema di monitoraggio esterno con avvisi via email: uptimerobot. Potete controllare lo stato dei servici tramite: [1] Attenzione, se desiderate usare questo servizio è consigliabile salvare nei preferiti l'indirizzo soprastante, perché in caso di downtime questa stessa pagina potrebbe non essere disponibile.

servizi aggiuntivi

Postfix-logo.png

argonauts fa girare un server postfix che riceve le mail di tutti i domini interessati e le indirizza ad account speciali, oppure, dove non è abilitata una configurazione multiutente, all'utente principale del sistema tramite una @ rule. Tutto gli mx dei domini puntano quindi a mail.my-lab.it, il quale risolve in argonauts su my-lab.it

evoluzioni future

Per il momento il server non mostra problemi di sovraccarico di sorta. In caso questo dovesse succedere sono previste quattro strade da intraprendere (in ordine di potenza):

  • scorporo del servizio mysql e web su due server differenti all'interno della stessa rete bhost.net. Con questa tecnica si impiegano due computer, invece che uno, per restituire una pagina: uno mantiene i dati (sql) e l'altro restituisce le pagine sulla base dei dati immagazzinati nel server dedicato a questa funzione. E' necessario che i computer risiedano nella stessa rete fisica per far viaggiare veloci le comunicazioni tra tutti i nodi. Per esempio potrebbero essere due macchine virtuali bhost ospitate su server differenti.
  • round robin DNS in questa configurazione sono previste tre macchine server (nel caso in esame) + un server round robin. Il DNS gestito con questa tecnica risponde alla stessa domanda di instradamento con diversi indirizzi IP, presi da una lista di regole A, in maniera da distribuire le richieste: una volta si viene inviati verso la macchina 1, e la seconda volta verso la macchina 2. I dati risiedono invece sulla macchina 3. Questa tecnica garantisce anche un elevatissimo uptime (se gestita bene, anche il 100%), dal momento che se la macchina 1 o la macchina 2 dovessero cadere il client passerebbe automaticamente al secondo server della lista, e se ancora questo non dovesse rispondere, al successivo, e così via. Ciò dà la libertà al sistemista di effettuare aggiornamenti e riavii delle macchine in sicurezza, e di prendersi il tempo per testare le nuove configurazioni. Va detto che questa tecnica funziona bene per i servizi web, ma non è sempre consigliabile per altri servizi che non implementano questa procedura di failover. In tal caso è meglio impiegare un reverse proxy, disattivabile in maniera sicura durante gli aggiornamenti ricorrendo a reindirizzamenti diretti sul server web, bypassando il reverse proxy, tecnica però che richiede 4 macchine + un server DNS ed è notevolmente più complicata.
  • clustering Tramite tecniche di clustering di tipo cloud si possono distribuire i servizi stessi su più macchine, per esempio impiegare 2 o più computer, in costante comunicazione tra loro, per immagazzinare i dati in maniera trasparente, potendo contare su un'affidabilità raddoppiata (i dati sono copiati su due macchine diverse) e una velocità quasi raddoppiata (i dati possono essere serviti indifferentemente da ciascuna delle due macchine).
  • CDN content delivery network: distribuire i propri contenuti su server differenti e dislocati in siti fisici diversi, prerenderizzati dal server principale, in modo da delegare il carico leggero, ma ad alto volume, all'esterno della propria rete, e impiegare la macchina principale solo per il lavoro veramente indispensabile

Sono in programma ulteriori piani per la sicurezza dei file caricati dal momento che uno dei nuovi progetti in cantiere su argonauts apre la possibilità agli utenti di caricare dati, che, devono essere necessariamente copiati anche in una copia di sicurezza per garantire la possibilità di ripristino totale in caso di problemi. L'idea è quella di dedicare una cartella sul disco a questo scopo, e di sincronizzarla tramite rsync, o lftp, con un servizio remoto.

Sempre sul fronte sicurezza sono previsti backup della cartella /etc, e la creazione di uno script che installi e configuri tutto il necessario, per garantire di poter tornare, in caso di guasto, online in tempi rapidissimi. I test verranno effettuati su argon.my-lab.it, che al momento è inattivo e non serve pagine internet.

evitare l'out of memory

Infine, uno dei problemi frequenti, è più che risolto diciamo aggirato con questo script: http://www.my-lab.it/Memory_Low_Memory_Shield che evita che il server muori di starvation, cioè di fame, nel senso affamato di memoria che non ha.