|
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 ad 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.
Figura 1 - Esempio di architettura Oracle affidabile
e scalabile
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.
Giovanni
Cuccu è laureato in ingegneria informatica a
Bologna. Attualmente svolge attività di consulenza
per lo sviluppo di applicazioni web tramite Java, Oracle.
Si interessa di applicazioni open source, usa Linux
regolarmente ed è autore di un Oracle session
profiler open source (scritto in Java) scaricabile da
http://sourceforge.net/projects/oraresprof/
|
