Concludiamo la serie dedicata all‘esplorazione dei meccanismi Oracle per garantire affidabilità e scalabilità spiegando con quale architettura hardware/software si possano ottenere entrambi.

Introduzione

Un requisito comune a molti progetti Java di grosse dimensioni e quello di garantire sia l‘affidabilità , ovvero la possibilità  del sistema di non perdere i dati e di renderli disponibili anche in caso di eventi catastrofici, che la scalabilità , ovvero la possibilità  di poter aumentare le risorse computazionali del sistema per far fronte a incrementi del carico di lavoro. Lo scopo dell‘articolo è quello di analizzare come è possibile, utilizzando Oracle, soddisfare tale requisiti a livello di RDBMS. La soluzione presentata consiste nel “mettere insieme” le componenti viste negli articoli precedenti per realizzare un sistema robusto senza richiedere modifiche al codice Java.

Oracle Data Guard

Nel numero di luglio/agosto 2005 abbiamo visto in cosa consista l‘architettura Oracle Data Guard; una serie di server (almeno due) in cui ne esiste uno che ha il ruolo di primario dove l‘applicazione legge/modifica i dati e gli altri, detti di stand by, a cui il primario propaga le modifiche. Abbiamo visto come sia possibile scegliere fra diverse politiche di propagazione delle modifiche, si va da quella che garantisce il minimo impatto sulle prestazioni (denominata maximum performance) a quella (maximum protection) che ci assicura che nessun dato possa essere salvato sul primario se la modifica non è stata trasmessa anche ai secondari. E‘ possibile optare anche per una soluzione ibrida in cui il sistema opera in modalità  massima sicurezza, ma in caso di guasto al collegamento fra il primario ed il secondario passa alla modalità  massima performance fino a quando il problema non viene risolto. Abbiamo esaminato la modalità  di propagazione delle modifiche, che si basa sulla copia iniziale di una “fotografia consistente” del database e sulla trasmissione delle modifiche tramite redo log o archive log. L‘architettura Data Guard consente, se opportunamente configurata, di ottenere delle piattaforme estremamente affidabili, in grado di garantire la disponibilità  dei dati anche in caso di eventi catastrofici; infatti i server possono essere collocati in datacenter diversi, in maniera che, anche nel caso di inagibilità  completa di una server farm i dati siano disponibili ed utilizzabili. La soluzione Data Guard consente, in caso di guasto del server primario, di poter convertire uno stand by in un database pienamente funzionante in qualche decina di minuti (nella versione 10 Release 2 il failover da primario a secondario può avvenire in maniera automatica ed in tempi ancora più ridotti). E‘ importante ricordare che la soluzione Data Guard richiede una licenza Entreprise, per cui è opportuno valutare oculatamente il rapporto costi/benefici.

Oracle RAC

Oracle RAC è la soluzione che consente di costruire soluzioni scalabili, ovvero in grado di poter rispondere ad incrementi del carico di lavoro garantendo la continuità  del servizio. Essa si basa sul concetto di cluster, in cui più unità  elaborative condividono l‘area di storage. Sebbene anche la soluzione RAC possa essere considerata ad alta affidabilità , in realtà  essa non garantisce la conservazione dei dati in caso di guasto del sottostema dischi comune ai nodi del cluster. Le soluzione RAC sono pensate per garantire la possibilità  di aggiungere capacità  elaborative (ovvero nodi al cluster) senza dover intervenire senza dover fermare il database, inoltre fornisce meccanismi per effettuare il bilanciamento del carico fra i vari nodi del cluster e di failover, ovvero in caso di guasto di un singolo nodo èpossibile che la sessione Oracle venga automaticamente rediretta su un nodo ancora attivo. Purtroppo il driver JDBC thin mette a disposizione la funzionalità  di load balancing, ma non di transparent failover (che comunque vale solo per l‘istruzione di select), per cui, per poter sfruttare entrambe le funzionalità  è necessario ricorrere al driver oci che richiede l‘installazione di un client Oracle nativo.
A differenza di Data Guard Oracle RAC, a partire dalla versione 10, può essere utilizzato con la versione standard di Oracle (con una limitazione sul numero massimo di processori e a patto di utilizzare Oracle ASM per la gestione dello storage).

La soluzione Data Guard + RAC

Sia la soluzione Data Guard che quella RAC hanno il vantaggio di essere trasparenti dal punto di vista della programmazione, ovvero di non richiedere particolari accorgimenti a livello di codice Java, lo stesso si può dire per la soluzione ad alta affidabilità  e scalabilità  che consiste nel “mettere insieme” i due pezzi. Per realizzare un‘architettura che sia in grado di reggere un aumento nel carico di lavoro e di garantire che i dati siano sempre disponibili, anche in caso di eventi disastrosi è possibile combinare la potenza del RAC con la sicurezza di Data Guard. In tale scenario il server primario, che viene utilizzato dagli utenti, è una soluzione RAC e ogni nodo del cluster invia i suoi redo/archived (a seconda della modalità  scelta) log a più server stand by; essi possono essere a loro volta Oracle RAC o database “semplici”, a seconda della capacità  elaborativa richiesta in caso di guasto del server primario. La seguente figura illustra uno scenario in cui un cluster RAC di due nodi invia i redo log al server (non RAC) di stand-by.

Conclusioni

Si conclude con questo articolo la serie dedicata alla presentazione di soluzioni Oracle in grado di fornire alle nostra applicazioni il grado di affidabilità  e prestazioni necessarie. Utilizzando sia Data Guard che Oracle RAC è possibile ottenere, in maniera completamente trasparente per il programmatore, uno strato database in grado di sostenere futuri aumenti di carico computazionale e di tollerare anche i guasti più gravi.