Las bases de datos como DB2/390 tienen particiones incorporadas, por lo que puede que las particiones de base de datos no sean necesarias en la aplicación.
Aunque puede configurar un clúster fiable para ejecutar la aplicación, si el clúster utiliza una única instancia de base de datos, la base de datos será un punto único de anomalía, así como un límite de escalado vertical. La base de datos es un punto único de anomalía porque si no está disponible, no se puede realizar ningún trabajo en el clúster. También es un problema de escalado vertical porque la mayoría de bases de datos sólo se escalan verticalmente; por lo tanto, para ir más rápido, debe adquirir un recuadro más grande.
En el diagrama siguiente se muestra la arquitectura de un servidor de base de datos individual. En este diagrama, hay dos productos WebSphere Application Server, pero sólo un servidor de base de datos. Cuando se añaden más y más servidores de aplicaciones, la base de datos se convierte en un cuello de botella de rendimiento.
Quizá necesite bases de datos que se escalen horizontalmente y que no detengan todo el clúster de servidores de aplicaciones cuando falle. Muchas aplicaciones con requisitos no funcionales permiten que las anomalías temporales afecten a una parte de la aplicación, pero no aceptan una caída total. Este tipo de arquitecturas utiliza un diseño de base de datos particionada.
Un ejemplo de este tipo de diseño incluiría tres recuadros ejecutando bases de datos DB2 autónomas. El esquema de tabla y el sistema de seguridad son idénticos para las tres bases de datos. Todos los datos de referencia de sólo lectura se duplican en las tres bases de datos desde una instancia maestra de DB2 de datos de referencia a la que se proporciona una alta disponibilidad de la forma habitual. Esta instancia maestra de DB2 de referencia no es un punto único de anomalía durante el funcionamiento normal porque no la utiliza directamente la aplicación.
Cuando varios servidores estén preparados, el siguiente paso es garantizar que se puedan particionar los datos de aplicación. Correlacione los datos para una partición determinada con una instancia de DB2 determinada utilizando un esquema hash simple o un mecanismo de rango, o bien utilice una tabla duplicada en las bases de datos. El clúster de servidores de aplicaciones guarda en antememoria la tabla, que especifica la instancia de DB2 que mantiene los datos de una determinada partición. Con esta configuración, los datos críticos se pueden mover entre las bases de datos sin necesidad de cambios de aplicación.
La instancia maestra mantiene la partición en la tabla de instancias de DB2, que se duplica en los tres nodos de base de datos. Es necesario un protocolo de aplicación para coordinar una partición de un nodo de base de datos con otro. Con coordinación, una aplicación puede añadir una instancia de base de datos al conjunto de bases de datos en uso para obtener la escalabilidad horizontal. La ventaja de utilizar tres instancias de base de datos independientes es que la disponibilidad es mayor que con una base de datos en clúster normal como, por ejemplo, Oracle RAC o DB2 EEE. Las bases de datos son independientes y un error en una de ellas sólo significa que el conjunto de datos que reside en esa base de datos no estará disponible ahora, pero la aplicación puede continuar procesando transacciones para los datos que residen en las otras instancias de base de datos en línea.
Esta situación es preferible antes que una anomalía completa. No obstante, la administración es ahora más compleja, ya que dispone de tres bases de datos, en lugar de una. La aplicación utiliza transacciones dirigidas para indicar al servidor de aplicaciones qué instancia de base de datos contiene los datos completos de la próxima transacción. Este patrón proporciona una gestión flexible del aspecto de base de datos de la aplicación, especialmente cuando se utiliza con la tabla MAPPER que indica a la aplicación qué nodo de base de datos tiene los datos de una determinada partición.
WebSphere Extended Deployment ofrece una nueva característica, el origen de datos del proxy, que puede utilizar la aplicación para indicar a WebSphere qué base de datos debe utilizar antes de que empiece la transacción. Cuando un miembro de clúster recibe una petición de una determinada partición de la aplicación, puede indicar al tiempo de ejecución CMP que ignore el origen de datos con el que se han desplegado los beans y que utilice un origen de datos específico el tiempo que dure la siguiente transacción. Se puede utilizar el patrón de transacciones dirigidas con la aplicación, lo que permite aumentar su disponibilidad y se puede escalar horizontalmente el nivel de la base de datos en los entornos de tipo Blade. Las aplicaciones también pueden aprovechar el patrón de tabla MAPPER para gestionar datos y mover particiones.
En el diagrama siguiente se muestra la nueva arquitectura. Con dos bases de datos del sistema, EJB1 se despliega en los dos servidores. En una transacción, el EJB1 del servidor superior accede a la base de datos 1. En otra transacción, el EJB2 del servidor inferior accede a la base de datos 2. La carga de base de datos se reparte entre varios servidores de base de datos, en lugar de utilizar uno solo.
Related concepts
Posibilidades de partición J2EE