MokaByte 98 - Lug/Ago 2005
 
MokaByte 98 - Lug/Ago 2005 Prima pagina Cerca Home Page

 

 

 

Soluzioni Oracle per l'alta affidabilità:
Oracle Data Guard

Quando si progetta una applicazione complessa basata su database è importante garantire oltre a scalabilità e prestazioni anche un elevato grado di affidabilità, ovvero di tolleranza ai guasti. Se l'applicazione si basa su database Oracle è possibile sfruttare l'opzione Data Guard (precedentemente nota come standby database) per implementare una architettura in grado di non perdere i dati nemmeno nei casi più tragici. Tramite Oracle Data Guard è possibile realizzare sia soluzioni estremamente affidabili che garantiscono la disponibilità dei dati anche in caso di guasto fisico al server (o addirittura dei locali che ospitano il database primario), sia soluzioni che, pur garantendo un livello elevatissimo di prestazioni, riescono a replicare i dati fino a qualche minuto prima del possibile disastro

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 Enterprise
I 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/