Introduzione
Quando si sviluppa una applicazione Java spesso ci si
concentra sulle prestazioni e sulla miminizzazione degli
errori, ma quando la si deve mettere in produzione è
necessario considerare anche il grado di continuità
di servizio che l'applicazione deve garantire. Esiste
una serie di settori (sanità, finanza, etc) in
cui esistono delle applicazioni definite mission critical,
ovvero il cui funzionamento continuo è di fondamentale
importanza. Si pensi ad un web store di grosse dimensioni
come Amazon o ad un sistema di gestione/scambio di titoli
finanziari, la mancata possibilità di inserire
o recuperare dati può avere conseguenze molto
gravi sia dal punto di vista finanziario che dal punto
di vista di perdita dei clienti.
Il database Oracle consente tramite l'opzione Data Guard
di realizzare una serie di soluzioni che consentono
di bilanciare in maniera efficace sia le prestazioni
che la disponibilità e l'integrità dei
dati. Oracle Data Guard anche se teoricamente realizzabile
con la versione Standard del database è in pratica
utilizzabile solo con l'acquisto della versione EnterpriseI
meccanismi base di Oracle Data Guard
Oracle Data Guard consiste nella definizione di un gruppo
di database identici, uno dei quali ha il ruolo di primario,
tutti gli altri sono definiti standby e sono delle repliche
del primario. Il numero massimo di standby database
per un singolo primario è 10. I database standby
possono essere aggiunti anche "a caldo", ovvero
durante il normale funzionamento operativo, in un momento
successivo alla messa in esercizio, l'unico requisito
richiesto è che il database operi in modalità
archivelog mode (che dovrebbe essere, tranne rarissime
eccezioni, l'unica modalità in cui operano i
database Oracle in produzione). Oracle Data Guard consente
di propagare le modifiche dal database primario agli
standby secondo vari criteri, a seconda del compromesso
prestazioni/affidabilità che si vuole ottenere.
Il meccanismo di replica dei dati avviene tramite la
propagazione dei redo/archive log.
Cosa
sono i redo log?
Sono dei file nei quali Oracle scrive tutte le modifiche
effettuate ai dati; semplificando si può pensare
che i redo log contengono le differenze fra uno stato
del database ed uno successivo. Quando si esegue una
transazione all'atto del commit Oracle scrive le modifiche
effettuate nei redolog e fintanto che tali modifiche
non sono state salvate non viene ritornato il controllo
alla procedura chiamante; i dati veri e propri (non
solo le differenze) vengono scritte sui file che ospitano
i dati in maniera asincrona rispetto alle procedure
utente. Poichè in sistemi altamente transazionali
i database sono continuamente soggetti a richieste di
inserimenti, modifiche e cancellazioni i redolog tendono
a riempirsi piuttosto velocemente; esiste un meccanismo
di rotazione degli stessi, ovvero Oracle ne richiede
un minimo di due e scrive sono su uno alla volta, una
volta che questo risulta pieno (la loro dimensione è
fissa) si passa al successivo e così via fino
al riempimento di tutti quelli disponibili. Quando anche
l'ultimo redo log è stato riempito si passa riutilizzare
il primo, previa verifica che le modifiche in esso contenute
siano già state riportate sui file dati.
Quando si sovrascrive un redolog si perdono tutte le
modifiche in esso contenute, è vero che sono
state già salvate nel file dati, ma cosa succede
se il file dati viene accidentalmente cancellato o un
disco si rompe?
Tutti i dati sono irrimediabilmente persi.
Per evitare simili epiloghi è consigliabile attivare
la modalità archive log, che consiste nell'abilitare
un meccanismo che salva i redo log (creando gli archivelog)
in un altra directory utilizzabili in caso di disaster
recovery. Gli archive log non sono altro che le copie
dei redolog salvati in un altra directory.
Propagando i redo/archive log (ovvero solo i dati strettamente
modificati) da un database ad un altro Data Guard riesce
a mantenere delle repliche sempre sincronizzate.
Prima di procedere con l'analisi delle varie opzioni
che regolano i meccanismi di sincronizzazione dei database
è opportuno chiarire il processo di creazione
di uno standby database. Abbiamo detto che la sincronia
fra master e standby avviene tramite propagazione dei
redo/archive log ovvero delle differenze fra due stati
del database, questo implica che sullo standby ci devono
essere i file dati necessari per avere una rappresentazione
dello stato del database in un certo istante. Questo
implica che la prima operazione da eseguire quando si
crea uno standby database è la "cattura"
e la copia dei datafile (termine specifico Oracle per
indicare i file che contengono i dati) dal database
primario a quello destinato ad essere la replica. Particolare
attenzione deve essere posta alla fase di cattura in
quanto Oracle, essendo un database multiutente, scrive
continuamente sui data file, una semplice operazione
di copia dal sistema operativo produrrebbe una "fotografia"
inconsistente del database. E' possibile raccogliere
uno stato corretto del database durante il normale ciclo
di lavoro effettuando un backup "a caldo"
ovvero tramite comandi che informano i processi che
regolano l'accesso ai dati di non scrivere su quel determinato
datafile fino alla fine del backup, gli utenti possono
continuare a lavorare come se nulla fosse in quanto
le modifiche vengono salvate nei redo log. Una volta
che è stato effettuato il backup di tutti i file
dati è possibile trasferirli sullo standby e
avviare il meccanismo di replica applicando tutte le
differenze presenti nei redo log dal momento del backup
del primo datafile.
L'avvio della copia dei redo/archived log avviene specificando
un parametro nel file di configurazione di Oracle che
indica che essi devono essere salvati anche su un database
remoto, lo standby deve essere raggiungibile via TCP/IP
e indirizzabile dal server primario.
Adesso che è più chiaro quali sono le
modalità di funzionamento di Data Guard è
possibile approfondire le possibilità di configurazione
offerte per trovare la risposta corretta alle esigenze
di affidabilità/prestazioni.
Possibili
configurazioni di Data Guard
Se si vuole privilegiare "l'aspetto velocistico"
è possibile configurare Oracle Data Guard nella
modalità maximum peformance che consente di replicare
i dati minimizzando l'impatto sulle prestazioni; in
questo caso il meccanismo di propagazione delle differenze
avviene tramite archive log che vengono inviati ai server
standby solo dopo che sono stati scritti su disco. Le
operazioni eseguite sul database primario sono le seguenti:
- scrittura
sequenziale dei redo log online
- al
loro riempimento essi diventano candidati per l'archiviazione
locale
- un
processo Oracle si occupa di copiare gli online redo
log in una specifica directory facendoli diventare
archive log
- al
termine di questa operazione un processo legge gli
archive log e li invia ai server standby in maniera
asincrona (questa
è
una delle nuove feature di Oracle 10g) rispetto al punto
precedente
Il grande vantaggio di tale soluzione è dato
dall'asincronia fra scrittura degli archive log ed il
loro invio ai server standby, se si riservano dei dischi
per opsitare gli archive log le prestazioni del sistema
rimangono praticamente invariate. La controindicazione
più evidente è che i server standby sono
virtualmente sempre disallineati rispetto al server
principale e in caso di guasto del database primario
alcuni minuti di lavoro potrebbero andare persi.
Se i requisiti di affidabiltà impongono che nessun
dato debba andare perso è possibile optare per
"l'estremo opposto" ovvero la modalità
chiamata maximum protection. Essa lavora in modalità
differente rispetto alla precedente in quanto la scrittura
sui redo log avviene in maniera sincrona sia sul database
primario che sugli standby, un fallimento locale o remoto
(su tutti gli standby) di tale operazione comporta lo
spegnimento del database principale. Le operazioni eseguite
sui datase (primario e standby) sono le seguenti:
- scrittura
sequenziale dei redo log del primario
- contemporaneamente
ed in maniera sincrona avviene la stessa cosa sui
server standby
E'
facile intuire come tale impostazione richieda un collegamento
di rete estremamente veloce ed affidabile fra i vari
server in quanto ogni latenza di comunicazione si traduce
automaticamente in una attesa per l'utente.
Esiste una terza soluzione di compromesso denominata
maximum availability che consiste nell'operare in una
delle due modalità precedentemente analizzate
a seconda delle condizioni del sistema; il database
primario lavora se possibile in maximum protection,
ma al verificarsi di un errore di propagazione dei redo
log passa alla modalità maximum performance che
può essere abbandonata non appena il problema
che aveva causato la transazione è stato corretto.
Impatto
sull'archiettura complessiva
Oracle Data Guard ha il vantaggio che non richiede cambiamenti
o particolari accorgimenti nel codice applicativo; il
suo funzionamento è completamente database-side
e trasparente alle applicazioni che accedono ai dati.
L'aspetto più importante da considerare è
quello dell'architettura hardware e di rete necessaria
per essere sicuri di limitare al minimo la perdita di
dati; se si sceglie la modalità maximum protection
è consigliabile valutare la collocazione dei
vari database in luoghi (data-center, sale server, etc)
distinti e anche geograficamente distanti (dopo gli
eventi di qualche anno fa chi si sentirebbe di considerare
la caduta di un areo su un edificio commerciale un evento
al limite dell'impossibile?). Se si collocano i server
in zone geografiche sufficientemente distanti è
necessario assicurarsi che l'infrastruttura di rete
sia affidabile al fine di evitare fermi operativi perchè
non si riescono a trasferire i log. La collocazione
in locali distinti è, quando possibile, sempre
consigliabile in quanto si evita che un danno strutturale
(che può andare dalla mancanza di corrente, all'indisponibilità
della rete fino all'incendio) possa coinvolgere sia
il primario che gli standby; la soluzione Data Guard
richiede la versione Enterprise di Oracle che di solito
ha un costo dell'ordine delle decine di migliaia di
euro, è importante che, in caso di incidente,
tale investimento dia i suoi frutti.
Conclusioni
Oracle Data Guard è un meccanismo lato database
che consente, in funzione della quantità di dati
che (non) si vogliono perdere, di costruire soluzioni
veloci e affidabili. Esso si basa sulla modalità
archivelog di Oracle (che consente di memorizzare le
modifiche fatte ai dati presenti nel database e di ri-applicarle
ai server standby). La sua implementazione non richiede
modifiche al codice applicativo e può essere
realizzata anche ad applicativi già in produzione.
Una sua corretta applicazione richiede una attenta valutazione
della collocazione dei server e delle infrastrutture
di rete.
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/
|