Il server database: dietro le quinte di hwupgrade

Il server database: dietro le quinte di hwupgrade

Il server database del forum di discussione è indubbiamente l'elemento più critico dell'intera infrastruttura di server che utilizziamo per pubblicare quotidianamente i contenuti di Hardware Upgrade. Vediamone le basi di funzionamento tecnico, e quali considerazioni abbiano guidato la scelta del nuovo server in produzione

di Paolo Corsini pubblicato il nel canale Server e Workstation
 

Le esigenze di un server database per forum

Iniziamo l'analisi vedendo quali siano gli elementi alla base della definizione di un server database per un forum di discussione, e quale ne sia il tipico comportamento. Vedremo in seguito quale sia la scelta che è stata fatta internamente in Hardware Upgrade e come il nuovo server database sia stato configurato.

Una premessa storica: il forum di discussione di Hardware Upgrade è online dal mese di Luglio 1999, con una crescita nel numero sia di messaggi che di utenti registrati che è stata proporzionale al traffico raccolto dal sito; al momento attuale sono archiviati oltre 17 milioni di messaggi, con poco meno di 200.000 utenti registrati e 1,1 milioni di discussioni. I messaggi memorizzati non sono tutti quelli che sono stati scritti nel corso della vita del forum di discussione: in passato sono stati cancellati vari post così da alleggerire la dimensione complessiva del database, giunta ai tempi a livelli critici per garantire la continuità del servizio.

forum.gif (67737 bytes)
forum di discussione di Hardware Upgrade: oltre 17 milioni di messaggi memorizzati

La piattaforma software sulla quale è basato il forum di discussione è vBulletin, software commerciale per la creazione e la gestione di forum di discussione basato su database MySQL e codice php; questo mix è lo stesso adottato per la parte editoriale di Hardware Upgrade, e per questo motivo vBulletin si è rivelata una scelta pressoché obbligata nell'anno 2000, periodo di sua prima adozione. Analizzando come vBulletin interagisca con il server database, un evidente collo di bottiglia alle prestazioni è dato da quanti dati siano archiviati nel database del forum: maggiore il loro numero, più elevata sarà la dimensione complessiva del database.

Questo genera due conseguenze dirette: da una parte, un archivio di elevate dimensioni implica un motore di ricerca di altrettante elevate dimensioni. vBulletin esegue delle table lock nel momento in cui viene eseguita una scrittura sul database, in quanto sono utilizzate le tabelle MyISAM: questo implica che sino a quando questa operazione non viene completata le tabelle non possono essere modificate in alcun modo, ad esempio inserendo i dati di un nuovo post che viene scritto. Questo genera una coda di queries che devono essere eseguite dal database, con conseguente rallentamento del server sino a giungere allo stallo del forum. Avete presente quando volete aprire una pagina del forum, la vostra linea funziona correttamente ma la pagina non funziona? Molto spesso questo accade in quanto il database del forum è impegnato nell'eseguire una operazione mandando in coda le altre queries, tra le quali la vostra.

Come ovviare a questa situazione? Esistono vari rimedi:

  • utilizzare hardware sempre più potente: cambiare server per uno più potente permette di avere a disposizione più risorse di elaborazione; fondamentale migliorare le capacità di storage, sia nella forma di tanta memoria di sistema che di sottosistemi dischi adeguati;
  • ridurre la dimensione complessiva del database, cancellando i messaggi più vecchi: in questo modo si riduce la dimensione totale del database perdendo tuttavia dei contenuti;
  • ridurre le tabelle del database utilizzate dal motore di ricerca: in questo caso il numero complessivo dei messaggi memorizzati resta invariato, ma è possibile effettuare ricerche solo su una parte di questi ultimi (ad esempio, i messaggi scritti negli ultimi 7 mesi) così da ridurre la dimensione complessiva del database.

Una soluzione alternativa è quella di utilizzare un cluster per la parte database, ma in questo subentrano le limitazioni proprie di MySQL Cluster che permette di eseguire load balancing su più server ma con impatti prestazionali e requisiti di memoria di sistema improponibili per un utilizzo con un database grande quanto il nostro. Un'ulteriore alternativa è quella di utilizzare un secondo server database, sul quale eseguire una copia del database principale e veicolare tutte le richieste fatte al motore di ricerca: questo permette di sgravare il database principale da tutte le queries legate alla ricerca, lasciando che il database principale gestisca le queries di read e write per la consultazione dei messaggi e per la loro pubblicazione sul forum. E' questo l'approccio adottato circa 2 anni fa per il forum di Hardware Upgrade, così da separare del tutto la ricerca dal database principale e poter evitare lockup delle tabelle nel momento in cui vengono eseguite numerose ricerche contemporaneamente.

Esistono alcune regole per definire i parametri hardware minimi di un server database per l'utilizzo con un forum di discussione? Una regola base, che sostanzialmente abbiamo derivato dalla nostra esperienza, è quella di avere una dotazione di memoria fisica che sia come minimo pari alla dimensione complessiva del database; al momento attuale il database del forum di Hardware Upgrade ha una dimensione di 11 Gbytes circa, pertanto un quantitativo di 11 Gbytes di memoria RAM è il requisito minimo. Più sono veloci i dischi meglio è, in quanto nel momento in cui la memoria di sistema è saturata di dati il sistema operativo accede con molta più frequenza all'hard disk, per sua natura molto più lento della memoria di sistema nel leggere e scrivere i dati.

Con questi dati teorici chiari in mente, passiamo a vedere le caratteristiche del nuovo server database del forum di Hardware Upgrade, andato a sostituire una soluzione Rack 1 unità con due processori Opteron dual core, 16 Gbytes di memoria DDR e 4 hard disk SCSI da 10.000 giri al minuto configurati in una catena Raid 10 con controller hardware.

 
^