HP Oracle Database Machine – prima parte
In questo post vorrei esaminare le caratteristiche dei nuovi prodotti che HP ed Oracle hanno annunciato il 28 settembre scorso all’Oracle Open World Conference di San Francisco: Exadata Storage Server e la soluzione HP Oracle Database Machine. Visti gli spazi ristretti di cui dispone un post e volendo trattare l’argomento quanto più esaurientemente possibile, ho pensato di suddividere il mio intervento in più parti. Se avrete la pazienza di seguire questo blog, cercherò di esaminare tutti gli aspetti: caratteristiche tecniche, costi, consumi energetici.
Supponiamo che un’applicazione acceda ad un grande database relativo ad un data warehouse aziendale e che si voglia migliorarne le prestazioni, soprattutto quelle di alcune query la cui durata risulti eccessiva per i livelli di servizio desiderati. Alcuni degli interventi possibili sono:
- Ottimizzare il codice SQL
- Aumentare la RAM
- Modificare lo schema dei dati (introdurre ridondanza e denormalizzazione, generalmente tollerati per il questo genere di applicazioni, aggiungere indici, partizionare il database ecc.
- Aumentare il numero di CPU
- Potenziare il sistema di storage
- Cambiare il server
- Cambiare il DMBS
Nonostante tutti gli accorgimenti possibili, alcune operazioni (come la scansione piena di una tabella delle dimensioni nell’ordine dei TB, magari senza indici e con l’aggiunta di un predicato per la selezione delle tuple) sono sempre molto critiche e comportano un notevole carico computazionale con alti tempi di elaborazione. Sarà necessario, infatti, trasferire una gran quantità di dati dal sistema di storage verso la RAM del server ed il software DBMS dovrà selezionare solo quelli che soddisfano il criterio di selezione.
La strategia che Oracle e HP hanno adottato per rispondere con efficacia a questo tipo di problemi (ma non solo), ha seguito due linee di sviluppo:
- Connettere al server che esegue il DBMS (single instance database oppure RAC) un certo numero di server “intelligenti” ed indipendenti (chiamati celle Exadata)
- Connettere le celle Exadata al server che esegue il DBMS attraverso un link ad alta capacità che possa garantire un elevata ampiezza di banda (InfiniBand)
Nella figura seguente è riportato uno schema di fabric InfiniBand.
Le velocità ottenibili da un link InfiniBand sono le seguenti:
- Link InfiniBand 1X – Full Duplex Data rate 4 Gb/s
- Link InfiniBand 4X – Full Duplex Data rate 16 Gb/s
- Link InfiniBand 12X – Full Duplex Data rate 48 Gb/s
Per inquadrare meglio il paradigma tecnologico adottato, è utile descrivere brevemente il prodotto Oracle RAC. RAC è un’architettura cluster in cui un certo numero di server (nodi) accedono ad uno storage condiviso (tipicamente uno storage array connesso in fibre channel). In RAC ciascun nodo esegue un’istanza del database e poiché gli utenti possono potenzialmente accedere agli stessi dati da nodi diversi, è necessario che il DBMS coordini e sincronizzi le attività per mantenere l’integrità dei dati su disco. Le comunicazioni tra i nodi avvengono attraverso un link di interconnessione che può anche essere un normale link Ethernet.
Fonte: HP Reference Architecture for Oracle Real Application Clusters on HP ProLiant DL500 series servers and HP StorageWorks EVA – http://www.hp.com
Nella figura seguente è riportato un altro schema RAC che utilizza per le comunicazioni tra i nodi un link InfiniBand.
Fonte: HP InfiniBand solution for Oracle RAC environments – http://www.hp.com
Nota: i componenti siglati FCA2214DC sono schede HBA Fibre Channel per la connessione allo storage; i componenti siglati NC570C sono schede HCA Dual Port PCI-X InfiniBand.
Nella figura seguente sono rappresentati un database Oracle single-istance ed uno RAC che utilizzano gli spazi fisici resi disponibili dalle celle Exadata.
Fonte: A Technical Overview of the HP Oracle Exadata Storage Server – An Oracle White Paper October 2008 – http://www.oracle.com
Le celle Exadata sono singoli server specializzati per il supporto dell’I/O da/verso un sistema di storage locale e interpretano ed eseguono in parallelo la query SQL, in modo da restituire al DBMS solo la parte del record set filtrata dei dati non pertinenti. Parallelizzando l’esecuzione delle operazioni si aumenta il numero di processori che eseguono contemporaneamente lavoro utile (ciascuno su dati locali) e si diminuisce il traffico dati sul link verso il server che esegue il DBMS.
Per i dettagli tecnici e di performance vi rimando al prossimo appuntamento.
Molto interessante
Con questo articolo non rimpiangiamo più Google-Govoni!
Ho letto di questo post su http://www.oracleportal.it, quando è previsto il secondo appuntamento? Grazie
Penso di pubblicare il prossimo post verso la metà della prossima settimana. Saluti.
Ho letto questo articolo e non ho capito nemmeno l’argomento..forse perche’ non sono informatica?
Io sul blog vorrei questa radio http://www.musicovery.com/
[...] Oracle Exadata è stato ampiamente trattato in una serie di post pubblicati su questo stesso blog: prima parte, seconda parte, terza parte, quarta parte. Fonte: [...]
[...] più in dettaglio l’architettura trattata nel post precedente. Ciascuna cella Exadata è costituita da un server standard HP Proliant DL180 G5 con [...]