Aunque puede desplegar una cuadrícula de datos sobre miles de máquinas virtuales Java, es posible que desee considerar dividir la cuadrícula de datos en unidades o contenedores para que sea más fiable y fácil probar la configuración. Un contenedor es un grupo de servidores que ejecuta el mismo conjunto de aplicaciones.
Las pruebas han verificado que eXtreme Scale puede escalar hasta más de 1.000 JVM. Estas pruebas promueven la creación de aplicaciones para desplegar cuadrículas de datos individuales en gran cantidad de máquinas. Aunque es posible hacerlo, no se recomienda, por diversas razones:
La división de la cuadrícula de datos de la aplicación en contenedores (unidades) es una opción más fiable. Un contenedor es un grupo de servidores que se ejecutan en una pila de aplicaciones homogénea. Los contenedores pueden tener cualquier tamaño, pero lo ideal es que consten de unos 20 servidores físicos. En lugar de tener 500 servidores físicos en una única cuadrícula de datos, puede tener 25 contenedores de 20 servidores físicos. Una sola versión de una pila de aplicaciones se debe ejecutar en un determinado contenedor, pero distintos contenedores pueden tener sus propias versiones de una pila de aplicaciones.
Un contenedor es una unidad de despliegue de tamaño apropiado para las pruebas. En lugar de tener cientos de servidores para las pruebas, es más práctico tener 20 servidores. En este caso, se sigue probando la misma configuración que tendría en el entorno de producción. En el entorno de producción se utilizan cuadrículas con un tamaño máximo de 20 servidores, que constituyen un contenedor. Puede someter a pruebas de tensión un solo contenedor y determinar su capacidad, número de usuarios, cantidad de datos y rendimiento de las transacciones. Esto facilita la planificación y se ajusta al estándar de disponer de un escalamiento previsible por un coste previsible.
En diferentes casos, el contenedor no tiene que tener necesariamente 20 servidores. El objetivo del tamaño del contenedor es ajustarse a las pruebas prácticas. El tamaño de un contenedor debe ser suficientemente pequeño, de modo que si un contenedor encuentra problemas en producción la fracción de transacciones afectadas resulte tolerable.
Idealmente, cualquier error afecta a un único contenedor. Un error sólo afectaría al 4% de las transacciones de aplicación en lugar de afectar al 100%. Además, las actualizaciones resultan más fáciles porque se pueden desplegar en un contenedor a la vez. Como resultado, si una actualización de un contenedor causa problemas, el usuario puede conmutar de contenedor de nuevo al nivel anterior. Entre las actualizaciones figuran los cambios a la aplicación, la pila de aplicaciones o las actualizaciones del sistema. En la mayor medida posible, las actualizaciones sólo deben cambiar un único elemento de la pila a la vez para conseguir que el diagnóstico de problemas resulte más preciso.
Para implementar un entorno con contenedores, necesita una capa de direccionamiento sobre los contenedores que sea compatible con versiones anteriores y posteriores si se aplican actualizaciones de software a los contenedores. Además, debe crear un directorio que incluya la información acerca de qué contenedor incluye qué datos. Puede utilizar otra cuadrícula de datos de eXtreme Scale con este fin con una base de datos tras ella, preferiblemente utilizando el escenario de grabación diferida). Esto ofrece una solución de dos niveles. El nivel 1 es el directorio y se utiliza para ubicar qué contenedor maneja una determinada transacción. El nivel 2 consta de los propios contenedores. Cuando el nivel 1 identifica un contenedor, la configuración direcciona cada transacción al servidor correcto del contenedor, que es por lo general el servidor que contiene la partición correspondiente a los datos utilizados por la transacción. Opcionalmente, también puede utilizar una memoria caché cercana en el nivel 1 para reducir el impacto asociado con la búsqueda del contenedor correcto.
La utilización de contenedores es un poco más compleja que disponer de una sola cuadrícula de datos, pero las mejoras en el funcionamiento, las pruebas y la fiabilidad hacen que sea una parte crucial de las pruebas de escalabilidad.