Oracle Technology Day a Padova: Relazione

giovedì 19 aprile 2007 alle 19:29 | Pubblicato su Diario | 4 commenti

Ieri sono stato all’Oracle Technology Day tenutosi a Padova presso l’albergo Sheraton (il cui parcheggio costa più che in centro a Udine). Il tema era tanto per cambiare l’offerta Oracle di “Grid Computing” relativamente al database, quindi il RAC (Real Application Clusters, un vero cluster applicativo come ha detto il relatore). A parte qualche nota sulle caratteristiche introdotte con la Release 2 della 10g non ho visto nulla di più di quanto già esposto più di un anno fa a Milano ad un incontro più specifico dedicato ai partner Oracle (mirato a spingere  l’utilizzo di Oracle 10g da parte dei partner). In particolare devo dire che la demo, basata su dei server gia pronti in America sulle potenzialità di un RAC a 4 Nodi e con 3 servizi, è sempre la stessa, con un client grafico custom che fa vedere il comportamento del RAC, simulando dei carichi e la possibilità di uccidere una istanza per vederne gli effetti. C’è da dire che i tempi erano ristretti. In più c’era la  doverosa presentazione commerciale dei servizi di consulenza e assistenza forniti da Oracle Italia.

In sostanza al convegno sono stati evidenziati i potenziali di scalabilità della soluzione Oracle RAC, con in più una fetta di HA (High Avalilability) estesa anche a servizi non Oracle la versione 10.2 del clusterware Oracle. La presentazione ha però fatto sorgere in me una domanda di cui io una mia risposta, ma che ho voluto porre ai relatori:

“RAC per come viene presentato dimostra di essere una soluzione per poter scalare la potenza computazionale, generalmente identificata con la risorsa CPU. Una soluzione RAC a due nodi può migliorare le prestazioni dell’85%-95% rispetto ad un database  single instance. Il problema è che RAC permette di scalare la potenza computazionale in termini di CPU, e RAM, introducendo una sorta di fault tollerance dovuta ad una ridondanza di intere macchine, tecnologicamente meno complesso che ridondare ogni singola componente all’interno di una macchina. Nel caso specifico dell’applicazione sviluppata dove lavoro però quello che solitamente si osserva in situazioni di forte carico non è un alto utilizzo di CPU, ma di I/O sullo storage. RAC fornisce scalabilità in questo caso?”

Il relatore ha boffonchiato qualcosa sulla capacità dei canali dello storage. In realtà sappiamo bene che i canali degli storage moderni arriva a capacità di 2Gbit, quindi molto alti. Il problema sono sempre quella tecnologia ormai archeologica che sono gli Hard Disk, con quel cavolo di braccetto che deve andare su e giu come un pazzo.

La mia risposta quindi, analoga a quella implicitamente (e non volontariamente) data  dal relatore è che RAC non da scalabilità nel mio caso. L’unica soluzione tecnologica attualmente disponibile è lo Striping dei dati, ovvero la loro distribuzione su più dischi, sfruttando così il lavoro parallelo di più dischi. Oracle e molti esperti consigliano di usare il metodo SAME: Stripe And Mirror Everywhere. Questo metodo garantisce protezione e prestazioni, parlando in codici RAID diremmo “0+1”

In effetti stiamo parlando di sistemi RDBMS, database cribbio! dati che stanno su disco, quello che io (e molti sviluppatori) chiedo ad Oracle è gestire dati strutturati leggendoli e scrivendoli su disco, non di fare conti!

4 commenti »

RSS feed for comments on this post. TrackBack URI

  1. […] 2007 · No Comments Colgo la palla al balzo per proseguire un discorso cominciato con un mio post di qualche giorno fa, la palla me l’ha lanciata il Kevin Closson con questo post del 24 […]

  2. […] complesse di quelle con cui ho a che fare io solitamente. Francamente anche quando sono stato al seminario di Padova il relatore parlava di cluster con più di 10 nodi come di una cosa che esiste solo nei […]

  3. […] neanche problemi di cambio CD in quanto dispongo di un DVD che mi era stato dato in occasione del seminario a Padova del 18 Settembre scorso. Ho modificato anche il titolo del post per renderlo più […]

  4. […] La mia esperienza quindi rispecchia in effetti quanto denuncia Nuno, i nostri database solitamente sono “I/O bound”, non “CPU bound” ovvero la nostra applicazione richiede un sacco di dati e l’elaborazione di tali dati non impegna tanto la CPU del database server quanto il sistema di I/O. Questo in effetti si discosta molto dai presupposti di molti messaggi di marketing di Oracle. Ne ho gia parlato in passato. […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: