Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

100 ottobre
, anno 2005

Soluzioni Oracle per la scalabilità e l‘affidabilità

III parte

Avatar

Giovanni Cuccu

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/

MokaByte

Soluzioni Oracle per la scalabilità e l‘affidabilità

III parte

Giovanni Cuccu

Giovanni Cuccu

  • Questo articolo parla di: DataBase & elaborazione dei dati, Programmazione & Linguaggi

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.

Facebook
Twitter
LinkedIn
Avatar

Giovanni Cuccu

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/

Giovanni Cuccu

Giovanni Cuccu

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/
Tutti gli articoli
Nello stesso numero
Loading...

Integration Patterns

I parte

Il tunneling HTTP

Comunicare con un‘applicazione server

Il networking in Java

III parte: UDP e Datagrammi

Process Oriented Development: il processo alla base dello sviluppo

I parte: un approccio diverso ai requisiti di business

Applicazioni Full-Text con Apache Lucene

Una libreria per la ricerca testuale

Java Business Integration

I parte

MJPF: micro Java Plugin Framework

Un framework per realizzare applicazioni estensibili

Java in pista!

Un sistema di telemetria per la Formula 1

Service Oriented Architecture: dalla teoria alla pratica

I parte: Introduzione

JSP (o WebWork?), riposa in pace…

Architetture e tecniche di progettazione EJB

II parte: la comunicazione con client-session

Applicazioni Desktop

Parte I: toolbar in stile aqua

Nella stessa serie
Loading...

Soluzioni Oracle per la scalabilità

Come rendere scalabili le applicazioni Oracle

Soluzioni Oracle per l‘alta affidabilità

Oracle Data Guard

Oracle Java Stored Procedures

Scrivere stored procedures direttamente in Java

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte