Bancos de dados como o DB2/390 têm particionamento integrado, e podem tornar desnecessário o particionamento do banco de dados no aplicativo.
Embora você possa configurar um cluster confiável para executar o aplicativo, se o cluster utilizar uma única instância do banco de dados, o banco de dados se tornará um único ponto de falha, bem como um limite de escala vertical. O banco de dados é um ponto único de falha porque, caso se torne indisponível, nenhum trabalho poderá ser feito no cluster. Este é um problema de escala vertical porque a maioria dos bancos de dados são escalados apenas verticalmente; ou seja, para maior velocidade, é necessário comprar uma caixa maior.
O seguinte diagrama mostra a arquitetura do servidor de banco de dados único. Nesse diagrama, existem dois WebSphere Application Servers, mas apenas um servidor de banco de dados. Quando mais e mais servidores de aplicativos forem incluídos, o banco de dados se tornará um gargalo de desempenho.
Você pode precisar de bancos de dados que são escalados horizontalmente e não param todo o cluster do servidor de aplicativos após a falha. Muitos aplicativos cujos requisitos não funcionais permitem que falhas temporárias impactem uma parte do aplicativo, mas uma interrupção total não é aceitável. Estas arquiteturas utilizam um design de banco de dados particionado.
Um exemplo de tal design inclui três caixas executando o DB2 independente. O esquema de tabela e o sistema de segurança são idênticos para todos os três bancos de dados. Todos os dados de referência de leitura são replicados para todos os três bancos de dados a partir de uma instância do DB2 de dados de referência master que se tornou altamente disponível de maneira normal. Esta instância do DB2 de referência master não é um ponto único de falha durante a operação normal, pois não é utilizada diretamente pelo aplicativo.
Quando vários servidores estiverem prontos, a próxima etapa será assegurar que os dados do aplicativo sejam particionáveis. Mapeie os dados para uma partição específica em uma instância do DB2 específica utilizando um esquema de hash simples ou um mecanismo de intervalo ou utilizando uma tabela replicada nos bancos de dados. A tabela é armazenada em cache pelo cluster do servidor de aplicativos e especifica a instância do DB2 que contém os dados para uma partição específica. Com a configuração, os dados críticos podem ser movidos entre bancos de dados sem precisar de alterações no aplicativo.
A partição para uma tabela de instâncias do DB2 é mantida pela master e replicada para todos os três nós do banco de dados. Um protocolo de aplicativo é necessário para coordenar uma partição de um nó de banco de dados a outro. Com a coordenação, um aplicativo pode incluir uma instância de banco de dados para o conjunto de bancos de dados em uso para escalabilidade horizontal. A vantagem de utilizar três instâncias de banco de dados independentes é a melhor disponibilidade do que um banco de dados normal armazenado em cluster, como o Oracle RAC ou DB2 EEE. Os bancos de dados são independentes e uma falha de um deles significa apenas que o conjunto de dados residentes nele agora está indisponível, mas o aplicativo pode continuar processando transações para os dados que residem nas outras instâncias de banco de dados on-line.
Essa situação é preferível para uma falha completa. No entanto, a administração agora é mais complexa, porque existem três bancos de dados em vez de um. O aplicativo utiliza transações direcionadas para informar ao servidor de aplicativos qual instância do banco de dados contém os dados completos para a próxima transação. Este padrão permite um gerenciamento flexível do aspecto do banco de dados do aplicativo, principalmente quando utilizado com a tabela MAPPER que informa ao aplicativo qual nó do banco de dados possui os dados para uma partição específica.
O WebSphere Extended Deployment oferece um novo recurso, a origem de dados do proxy, que permite que o aplicativo indique qual banco de dados utilizar antes que a transação seja iniciada. Quando um membro de cluster recebe um pedido para uma partição do aplicativo específica, ele pode instruir o tempo de execução CMP a ignorar a origem de dados com a qual os beans são implementados e utilizar uma origem de dados específica pela duração da próxima transação. O padrão de transação direcionada pode ser utilizado com o aplicativo, permitindo que ele aumente a sua disponibilidade e suporte a escala horizontal da camada do banco de dados nos ambientes de tipo blade. Os aplicativos também podem tirar proveito do padrão da tabela MAPPER para gerenciar os dados e mover as partições.
O diagrama a seguir mostra a nova arquitetura. Com dois bancos de dados no sistema, o EJB1 é implementado em ambos os servidores. Em uma transação, o EJB1 no servidor superior acessa o banco de dados 1. Em outra transação, o EJB2 no servidor inferior acessa o banco de dados 2. O carregamento do banco de dados é espalhado por vários servidores de banco de dados, em vez de apenas um.
Related concepts
Recursos de Particionamento de J2EE