WebSphere Extended Deployment, Version 6.0.x     Sistemi operativi: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Partizionamento dei database

I database come DB2/390 hanno un partizionamento integrato e potrebbero rendere la funzione di partizionamento dell'applicazione non necessaria.

Sebbene sia possibile configurare un cluster affidabile per eseguire l'applicazione, se il cluster utilizza un'unica istanza del database, il database diventa un unico punto di errore esattamente come il limite di scalabilità verticale. Il database è un unico punto di errore in quanto se non è disponibile, non può essere effettuata alcuna operazione nel cluster. Questo è un problema di scalabilità verticale in quanto la maggior parte dei database può essere scalata solo orizzontalmente, ad esempio per una velocità maggiore è necessario acquistare una macchina più capace.

Il seguente diagramma mostra l'architettura di un server di database. Nel diagramma sono riportati due WebSphere Application Servers ma solo un server di database. Quando vengono aggiunti dei server, il database diventa un collo di bottiglia per le prestazioni.

È possibile che sia necessario che i database scalino orizzontalmente e non interrompano l'interno cluster di server delle applicazioni in seguito a un errore. Molte applicazioni con requisiti non funzionali consentono errori temporanei che influenzano una parte delle applicazioni non si verifica mai una interruzione completa. Tali architetture utilizzano un database con partizioni.

Un esempio di una tale configurazione include tre macchine che eseguono un database DB2 autonomo. Lo schema delle tabelle e il sistema di sicurezza sono uguali per tutte e tre i database. Tutti i dati di riferimento di sola lettura vengono replicati sui tre database da un'istanza DB2 dei dati di riferimento principale che è particolarmente disponibile. Questa istanza DB2 di riferimento principale non rappresenta un singolo punto di errore durante le normali operazioni in quanto non viene utilizzata direttamente dall'applicazione.

Quando sono pronti più server, il passaggio successivo consiste nel garantire che i dati dell'applicazione possano essere divisi sulle partizioni. Associare i dati di una determinata partizione a una particolare istanza DB2 utilizzando un semplice schema hash o un meccanismo di intervallo oppure utilizzando una tabella replicata nei database. Tale tabella è memorizzata nella cache dal cluster di server delle applicazioni e specifica l'istanza DB2 che contiene i dati per una particolare partizione. Durante l'impostazione, i dati critici possono essere spostati tra i vari database senza richiedere modifiche all'applicazione.

La partizione su una tabella dell'istanza DB2 viene conservata sull'istanza principale e su quella replicata per tutti e tre i nodi di database. Un protocollo applicativo è necessario per coordinare una partizione da un nodo di database a un altro. Con questo coordinamento, un'applicazione può aggiungere un'istanza di database alla serie di database in uso per scalabilità orizzontale. Il vantaggio di utilizzare una delle istanze dei database sta in una disponibilità maggiore rispetto a un normale database in un cluster, quale Oracle RAC o DB2 EEE. I database sono indipendenti l'uno dall'altro e l'errore di un database implica soltanto che la serie di dati su esso presenti non sono disponibili, ma l'applicazione può continuare a elaborare le transazioni per i dati presenti sulle altre istanze di database online.

Questa situazione è naturalmente preferibile a un errore completo. Tuttavia, la gestione è leggermente più complessa in quanto sono presenti tre database invece di uno solo. L'applicazione utilizza transazioni dirette per indicare al server delle applicazioni quale istanza del database contiene i dati per la transazione successiva. Questo modello fornisce una gestione flessibile dell'applicazione del database, in particolare se utilizzata con la tabella MAPPER che indica all'applicazione quale nodo del database contiene i dati per una determinata partizione.

Le applicazioni che utilizzano i bean CMP di solito specificano un unico database da utilizzare con i bean CMP. Questo approccio ha dei problemi se si utilizza questo modello. Èpossibile distribuire i bean CMP N volte, una volta per ogni database, ma questa non è una buona opzione per i seguenti motivi:

WebSphere Extended Deployment ha una funzione che consente all'applicazione di indicare quale database utilizzare prima dell'avvio della transazione. Quando un membro del cluster riceve una richiesta per una particolare partizione dell'applicazione, allora comunica al runtime CMP di ignorare l'origine dati su cui sono distribuiti i bean e utilizzare una determinata origine dati per la durata della transazione successiva. Il modello delle transazioni dirette può essere utilizzato con l'applicazione, aumentandone la disponibilità, e supporta la scalabilità orizzontale del livello di database in ambienti di tipo blade. Le applicazioni possono inoltre sfruttare il modello della tabella MAPPER per gestire i dati e spostare le partizioni.

Il seguente diagramma mostra la nuova architettura. Con due database sul sistema, l'EJB1 viene distribuito su entrambi i server. In una transazione, l'EJB1 del server principale accede al database 1. In un'altra transazione, l'EJB1 sul server accede al database 2. Il carico del database viene quindi diviso su più server di database invece che su uno solo.




Related concepts
Caratteristiche del partizionamento J2EE

Argomento Concetti    

Termini di utilizzo | Commenti Ultimo aggiornamento: Mar 20, 2006 1:10:47 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/WPF51/cwpfdb_pdf.html

© Copyright IBM 2005, 2006. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org)