Introducción a WebSphere eXtreme Scale (Parte 1): ¿Qué es WebSphere eXtreme Scale y cómo funciona?

Este artículo introductorio le ofrece las bases que lo ayudarán a lograr una buena comprensión técnica de qué es IBM® WebSphere® eXtreme Scale, de las características que ofrece y de la gran cantidad de beneficios que brinda. Esta guía describe los principios subyacentes de los datos en memoria, el particionamiento y la copia caché. Luego de esto, también describe los aspectos fundamentales de WebSphere eXtreme Scale en relación a todo esto. Se incluyen casos de uso con el objetivo de mostrarle cómo estos principios subyacentes generan beneficios de negocios. This content is part of the IBM WebSphere Developer Technical Journal.

O. Ted Kirby , Sr. Software Engineer, IBM

Author photoTed Kirby はノースキャロライナ州 Research Triangle Park にある IBM のシニア・ソフトウェア・エンジニアです。彼は WebSphere Application Server Community Edition の開発とマイグレーションを担当するチームのメンバーです。それ以前には、e-コマース用の Web サイトの機能強化と維持管理、また (Deep Blue マシンに使われたシステムを含む) 分散オペレーティング・システムの開発を行っていました。



15-08-2011

Introducción

¿Qué es IBM WebSphere eXtreme Scale y cómo funciona? Adoptemos un enfoque doble para responder a esta pregunta. En primer lugar, consideremos la explicación que usted podría encontrar en el Centro de información:

WebSphere eXtreme Scale opera como una cuadrícula en memoria que procesa, particiona, replica y gestiona datos de aplicación y lógica de negocios de manera dinámica a lo largo de cientos de servidores. Además, le ofrece integridad transaccional y conmutación por error transparente para garantizar una alta disponibilidad, una alta confiabilidad y tiempos de respuesta consistentes. WebSphere eXtreme Scale es una plataforma esencial de copia caché distribuida desde IBM que le ofrece una escalabilidad elástica y entornos de computación en nube de próxima generación.

Elástica significa que la cuadrícula se monitorea y gestiona a sí misma, permite las capacidades de escalabilidad interna y horizontal y se puede arreglar a sí misma recuperándose automáticamente después de una falla. La escalabilidad horizontal permite que se agregue capacidad de memoria mientras que la cuadrícula se está ejecutando (sin que sea necesario reiniciar el sistema). De manera contraria, la escalabilidad interna permite la eliminación de capacidad de memoria al instante.

¿Entendió? De no ser así, observemos un ejemplo y tratemos de explicar de qué se trata este producto tan innovador.

Simplemente, el objetivo de WebSphere eXtreme Scale consiste en mejorar dramáticamente el rendimiento de la aplicación. Como lo sugiere el nombre, uno de sus objetivos principales consiste en aumentar dramáticamente la cantidad de usuarios que una aplicación puede soportar. Este aumento podría servir para atender a más usuarios, o a muchos más usuarios, con tiempos de respuesta predecibles y razonables.

Figura 1. ¿Qué es WebSphere eXtreme Scale?
¿Qué es WebSphere eXtreme Scale?

Por ejemplo, una organización WebSphere eXtreme Scale que usa un tiempo de acceso mejorado a los datos clave, de 60 ms (milisegundos) a 6 ms, con 450.000 usuarios concurrentes y 80.000 solicitudes por segundo. La implementación y los ahorros llevaron seis semanas desde el concepto hasta la producción y ayudaron a aliviar las limitaciones anteriores provocadas porque la base de datos ya había alcanzado su capacidad máxima. La tecnología WebSphere eXtreme Scale nos ofrece todo lo necesario para adaptarnos a los requisitos de trabajar con una carga 10 veces superior, escalar hasta un millón de solicitudes por segundo y activar más de cinco millones de usuarios concurrentes.

¿Pero cómo WebSphere eXtreme Scale hace esto? Lo que resta de este artículo se ocupa de responder a esa pregunta. Para ello, se comienza por analizar algunos de los principios subyacentes de WebSphere eXtreme Scale.


Principios de la escalabilidad extrema

Estos principios fundamentales son una parte integral de la idea de WebSphere eXtreme Scale:

Las próximas secciones describen estos principios en detalle.

Colocar datos en memoria

Generalmente, los datos se almacenan en un disco (probablemente, en una base de datos en un disco). Para procesar estos datos, se los debe colocar en la memoria de la computadora para que el programa los pueda procesar (Figura 2). Esta operación de entrada / salida (I/O) lleva mucho tiempo en comparación con la cantidad de tiempo necesario para acceder a los datos que ya están en la memoria de la computadora.

Por ejemplo, puede llevar 20 ms (o 0,020 segundos o 20 x 10 3 segundos) leer un conjunto de datos desde un disco. A los datos que ya se encuentran en la memoria se puede acceder en décimas de nanosegundos (o 10 9 segundos). Por lo tanto, acceder a los datos que ya se encuentran en la memoria es literalmente un millón (o 10 6 ) de veces más rápido.

Figura 2. Jerarquía de memoria
Jerarquía de memoria

JVMs de 32-bit vs. de 64-bit

32 y 64 hacen referencia a la cantidad de bits en el espacio de dirección del hardware subyacente:

  • La mayoría de las máquinas tienen hardware de 32 bits, lo que significa que un espacio de dirección puede ser de 232bytes (ó 2 GB) como máximo.
  • La mayoría de las máquinas tienen hardware de 32 bits, lo que significa que un espacio de dirección puede ser de 2 32 bytes (ó 2 GB) como máximo.

Si 2 GB en un JVM de 32 bits no es suficiente, ¿se puede usar un JVM de 64 bits que ofrecería 4 Exa Bytes (ó 4x10 18 bytes)? La memoria JVM es virtual. Un JVM de 64 bits está limitado por la memoria física del servidor que lo ejecuta. Cuando la memoria física de la máquina llega a su límite, usted debe obtener todos los datos restantes de un disco a una velocidad menor. El tamaño de la memoria física de la máquina determina su rendimiento y, por lo tanto, colocar todos sus datos en un JVM de 64 bits crea un solo cuello de botella del servidor y anula el principio de escalabilidad horizontal ( próxima sección ) que usted está tratando de lograr.

También existen límites prácticos que involucran los tiempos de™ recolección de basura (GC) en Java. Uno de los principios guía consiste en permanecer por debajo de 5-6 GB en un solo JVM de 64 bits. De lo contrario, la GC podría consumir una gran parte de su poder de procesamiento. Es posible que le resulte más aconsejable usar JVMs de 32 bits más pequeños para la escalabilidad horizontal y distribuir la carga en vez de usar menos JVMs de 64 bits más grandes. Los trabajos recientes validan esta opción, ya que demuestran que los JVM de 64 bits usan 50% más de memoria real que los JVM de 32 bits para almacenar la misma cantidad de objetos.

WebSphere eXtreme Scale soporta JVMs de 64 bits y usted los debería usar cuando ayuden. Pero tenga cuidado de no usarlos de forma tal que esto termine siendo contraproducente. Los JVM de 64 bits conllevan gastos generales adicionales modestos, incluso si usted evita ser víctima de la GC. (Explore WebSphere Real Time si tiene dudas sobre la GC.)

Debido a que la mayoría de los datos se encuentra en un disco, ¿cómo hace para escalar aplicaciones de forma tal que no terminen esperando recibir y enviar datos desde y hasta discos lentos? La respuesta es colocando todos los datos posibles en memoria para así eliminar estas costosas operaciones de entrada / salida. El acceso más rápido a los datos hace que sus aplicaciones funcionen más rápido. Por ende, usted logra un mejor tiempo de respuesta para los usuarios, una mejor capacidad de procesamiento de la aplicación y una mejor capacidad para soportar más usuarios.

Esto suena bien y parece ser obvio. ¿Entonces por qué todo el mundo no hace esto?

Dos razones:

  • Generalmente, estos datos importantes deben ser persistentes (como, por ejemplo, los registros de cuentas bancarias). Uno de los problemas con la memoria de las computadoras es que, cuando se apaga la máquina o se reiniciar el sistema, se pierden los datos que estaban en memoria. El almacenamiento en disco es persistente porque los datos no se pierden cuando se apaga la máquina.
  • ¡Todos los datos no caben en la memoria de la computadora! La memoria de las computadoras y los espacios de direcciones cada vez son más grandes. Un JVM de 32 bits significa alrededor de 2 GB de memoria usable. Esto representa una gran cantidad de datos. Pero la lógica de su aplicación y su middleware también deben compartir dicho espacio.

Otro lugar a considerar para colocar datos en memoria es otra máquina. Mientras que obtener datos de un disco local puede tardar entre 20 y 40 ms, obtener datos de una máquina cercana a través de una red rápida sólo tarda 2 ms. El uso de la memoria de otras máquinas puede resultar maravilloso al momento de escalar. La memoria de la máquina se usa para el sistema operativo y para la lógica de aplicación y el middleware, entre otras cosas, además de los datos que usted coloca ahí. El uso de máquinas remotas, posiblemente dedicadas al almacenamiento de datos, le ofrece mucha más memoria para datos de la que usted puede obtener de un disco y una velocidad muy superior.

El uso de otras máquinas también resulta de gran ayuda a fines de lograr una mayor disponibilidad. Si almacena una réplica de los datos en otra máquina, usted podrá recuperar dichos datos en el caso que algo falle en la primera máquina.

Partición de los datos para activar la escalabilidad horizontal

El enfoque fundamental para analizar y poner a punto el rendimiento consiste en encontrar y eliminar los cuellos de botella. Asuma que un procesador le ofrece una capacidad de procesamiento X. Como se puede observar en la línea verde de escalabilidad lineal en la Figura 3, cada vez que se agrega un procesador a su solución, usted obtiene una capacidad de procesamiento adicional X veces superior. La línea azul le muestra la escalabilidad no lineal (donde, cada vez que se agrega un procesador a su solución, usted obtiene una capacidad de procesamiento adicional X veces inferior). La línea roja (cuello de botella) le muestra lo que ocurre cuando uno de sus recursos ya alcanzó el máximo de su capacidad (en este ejemplo, la base de datos) y no puede seguir aumentando su tamaño. A medida que la carga va creciendo, su capacidad de procesamiento permanece constante (al índice más alto permitido del recurso en cuestión).

Figura 3. Rendimiento, escalamiento y cuellos de botella
Rendimiento, escalamiento y cuellos de botella

El primer enfoque para aliviar este cuello de botella consiste en hacer que una máquina más grande y rápida ejecute la base de datos. Este es un enfoque de escalabilidad vertical. Esto significa hacer que la máquina que presenta el cuello de botella sea más grande. La escalabilidad vertical sólo le permitirá alcanzar un punto más alto (es decir, un punto de saturación más alto) y, además, conseguir hardware de última tecnología es una solución costosa.

Más sobre este tema

La sección 1.1 de la User’s Guide to WebSphere eXtreme Scale (Guía de usuario de WebSphere eXtreme Scale) incluye una excelente discusión sobre la escalabilidad horizontal lineal. La mayor parte de esta sección se resume a partir de este Redbook.

Por lo tanto, ¿qué pasa si usted necesita escalar todavía más?

Obviamente, el próximo paso consiste en usar más máquinas para solucionar el problema. A esto se lo denomina escalabilidad horizontal. ¿Pero sirve eso para ayudar a la base de datos? En términos generales, la respuesta es no. Esto no resulta de gran ayuda. La Figura 4 le muestra la situación de una forma realista:

  • Los servidores de aplicación realizar una escalabilidad horizontal bastante buena. Por ende, se eliminan todos los cuellos de botella a ese nivel.
  • Se aplica la escalabilidad vertical a la base de datos, pero no resulta suficiente eliminar la base de datos como el cuello de botella para el tipo de escalabilidad que usted desea.
Figura 4. Opciones de escalabilidad en una aplicación tradicional de tres niveles
Opciones de escalabilidad en una aplicación tradicional de tres niveles

El segundo principio consiste en particionar los datos: Use dos máquinas, coloque la mitad de los datos en cada una de ellas y rutee las solicitudes de datos hacia las máquinas que contienen los datos. Si puede particionar los datos de esta forma en dos máquinas, cada una de ellas tendrá la mitad de la carga total y se duplicará el rendimiento y la capacidad de procesamiento de una máquina sola.

No todos los datos y las aplicaciones se pueden particionar. Aquellos / Aquellas que sí se pueden particionar se escalan en gran medida. Aquellos / Aquellas que no se pueden particionar no evidenciarán ningún beneficio.

Lo más relevante en relación a la partición de datos es que permite una excelente escalabilidad. Si dividir la carga entre dos máquinas es bueno, ¿qué pasará si usamos 10, 100 o incluso 1.000 máquinas? Eso es exactamente lo que WebSphere eXtreme Scale le permite hacer. Ese es el tipo exacto de escalabilidad que le ofrece.

El particionamiento permite la escalabilidad lineal (la línea verde en la Figura 3). Las solicitudes se rutean eficientemente hacia la máquina que alberga los datos requeridos. Sin particionamiento, se ocasionan muchos gastos generales como resultado de llevar los datos actuales al lugar correcto para su procesamiento. Además, estos gastos generales crecen de manera exponencial (y no lineal) a medida que se van agregando más máquinas. Cuando se usa el particionamiento, cada máquina que usted agrega trabaja feliz y eficientemente por su cuenta y sus pares no incurren en ningún tipo de gasto general o impuesto. A medida que se van agregando máquinas, todas ellas comparten la carga total de procesamiento en proporciones iguales. Usted puede agregar la cantidad de máquinas que considere necesaria para procesar su carga de trabajo.

En el ejemplo inicial que figura con anterioridad, los datos clave eran los perfiles de usuario, que se podían distribuir (particionar) entre un conjunto de máquinas para su procesamiento en paralelo. Para lograr que el tiempo de respuesta sea diez veces menor, se usaron diez servidores. WebSphere eXtreme Scale puede escalar hasta miles de máquinas, lo que significa que esta solución puede escalar de 100 a 1.000 veces para soportar entre 50 y 500 millones de usuarios (y todo esto con un tiempo de respuesta de sólo 6 ms). Los datos en memoria y el particionamiento permitieron reducir el tiempo de respuesta de 60 ms a 6 ms, pero el particionamiento es el que permite un crecimiento de entre 100 y 1.000 veces en lo que hace a la cantidad de usuarios soportados (con el mismo tiempo de respuesta de 6 ms). A esto nos referimos cuando hablamos de escalabilidad lineal.

Copia caché

Una característica clave de WebSphere eXtreme Scale es que ofrece un caché grande, escalable y elástico.

Limitación del caché

El caché suele tener un tamaño limitado. Luego de que se llena, usted debe expulsar un elemento para colocar otro en su lugar. Una típica estrategia de expulsión consiste en expulsar el elemento más viejo o que no se usa hace más tiempo (LRU).

Un caché es una porción de memoria que se usa para almacenar datos. El primer lugar en el que se debe buscar un elemento es en el caché. Si los datos están ahí, hablaremos de un acierto de caché y usted obtendrá el elemento que busca a velocidad de memoria (décimas de nanosegundos). Si los datos no están en el caché, hablaremos de un desacierto de caché y usted deberá obtener el elemento que busca del disco a velocidad de disco (décimas de milisegundos). Una vez que haya obtenido el elemento del disco, lo coloca en el caché y lo devuelve. Este uso básico del caché está representado por el caché lateral que aparece en la Figura 5. Como lo discutiremos más adelante, la aplicación se comunica tanto con el caché lateral como con el disco.

Figura 5. Caché lateral
Caché lateral

La efectividad del caché es directamente proporcional al índice de aciertos, que es el porcentaje de solicitudes satisfechas gracias al hecho de tener el elemento en el caché. Si todos los datos entran en el caché, los datos se leen del disco sólo una vez. Luego de eso, todas las solicitudes se satisfacen desde el caché a velocidad de memoria.

El uso del caché tiene dos beneficios muy importantes:

  • El primer beneficio favorece al proceso que solicita los datos que están en el caché. Este proceso se acelera debido a que los datos se entregan a velocidad de memoria. Todos los aciertos de caché significan que se eliminó la operación de lectura necesaria para obtener los datos desde el disco. Por lo tanto, se redujo la carga de trabajo en el disco.
  • Esta carga menor en el disco es el otro beneficio del caché. Ahora, el disco puede soportar más solicitudes de otros datos. En el ejemplo inicial que se menciona con anterioridad, la reducción del tiempo de acceso a los datos clave (de 60 ms a 6 ms) fue un resultado directo de este beneficio de copia caché y de la reducción de la carga en la base de datos back-end.

El índice de aciertos es una función del tamaño del caché, la cantidad de datos subyacentes y el patrón de acceso a los datos. Si el patrón de acceso de una aplicación consiste en leer de manera continua y secuencial todos los datos que usted está tratando de recuperar, la copia caché no lo ayudará a menos que todos los datos estén en el caché. Cuando se llene el caché, se expulsarán datos antes de que la aplicación pueda volver a acceder. En estos casos, la copia caché es mucho peor que algo inútil. En primer lugar, porque cuesta más colocar datos en el caché y porque este tipo de aplicación mostraría un rendimiento inferior que en el caso que no tuviese ningún caché.

En muchos casos, el caché se encuentra en el mismo espacio de dirección del proceso que desea usar los datos. Esto ofrece la mayor velocidad posible, pero limita el tamaño del caché. WebSphere eXtreme Scale puede usar otros JVM para la copia caché. Estos JVM pueden ser JVMs de caché dedicados para que la mayor parte de la memoria del JVM se use y esté disponible para los datos de la aplicación (no se comparte con el middleware, la infraestructura o la memoria o el código de la aplicación).

Estos JVM pueden estar en la misma máquina. Los JVM locales ofrece un rápido acceso a la memoria. Pero finalmente, los ciclos del CPU y la memoria física se deben compartir con el sistema operativo y otras aplicaciones y JVMs en la máquina. Por lo tanto, para conseguir cachés más grandes, y cargas de acceso equilibradas y en paralelo, es posible que usted desee usar los JVM en otras máquinas remotas con el objetivo de poder acceder a más memoria física. La memoria física es la clave de un acceso rápido. Los JVM remotos ofrecen la posibilidad de contar con un caché mucho más grande y más escalable.

¿Qué ocurre cuando se modifican los datos que están en el caché?

Las escrituras pueden complicar las cosas cuando se trabaja con cachés. Un factor importante para determinar qué datos se deben incluir en el caché es el índice escritura-lectura. La copia caché funciona mejor cuando los datos no se modifican (es decir, no se realizan escrituras y, por ende, el índice escritura-lectura es igual a cero) o no se modifican frecuentemente (por ejemplo, si se colocaron los perfiles de usuario en el caché, se los modifica muy de vez en cuando y, por ende, el índice escritura-lectura es muy bajo). Cuando se discuten las escrituras, conviene discutir el uso de un caché en línea (Figura 6). Como lo discutiremos más adelante, la aplicación se comunica sólo con el caché y éste se comunica con el disco.

Figura 6. Caché en línea
Caché en línea

Existen dos casos importantes en los que se usa la escritura:

  • El proceso que usa el caché modifica los datos.
  • Un proceso que no usa el caché modifica los datos.

En el primer caso, existen dos opciones:

  • En un caché de escritura adelantada (write-through), los datos se escriben en el caché y en el disco antes de volver al proceso de escritura para que continúe. En este caso, las escrituras ocurren a velocidad de disco (lo que no es bueno). La buena noticia es que los datos que se encuentran en el disco son consistentes con los datos que están en el caché (lo que es muy bueno).
  • En un caché de escritura retrasada (write-behind), una vez que los datos están en el caché, se devuelve la solicitud y el procesamiento continua. En este caso, su proceso de escritura continúa a velocidad de memoria, y no a velocidad de disco (lo que es bueno). Pero los datos que se encuentran en el disco no se actualizan por un tiempo (lo que no es bueno). Si la nueva copia del caché no se escribe en el disco antes del apagado o la falla del caché, se pierde la actualización (lo que es terrible). Sin embargo, WebSphere eXtreme Scale puede conservar copias adicionales del caché en otras máquinas para ofrecer un caché de escritura retrasada confiable. Por lo tanto, un caché de escritura retrasada le ofrece velocidad de memoria para acceder a los datos en todas las escrituras y para todas las lecturas de aciertos de caché. Además, también ofrece otros beneficios que discutiremos más adelante.

Si otro proceso modifica los datos subyacentes sin pasar por el caché, estamos en problemas. Si usted no puede lograr que todos los procesos usen el caché, tendrá que vivir con datos no actualizados (por un tiempo). Muchos usuarios emplean un copia sombra de su base de datos ( Figura 4 ) para soportar consultas grandes y ad-hoc que involucran a los datos operacionales. Aunque estas copias sombra están desactualizadas por algunos minutos, se las considera aceptables.

Existen dos enfoques diferentes para tratar esta falta de actualización del caché:

  • Cronometrar todas las entradas en el caché. Por ejemplo, todas las entradas se expulsan automáticamente del caché después de un intervalo definido por el usuario (como, por ejemplo, 10 minutos). Esto obliga al caché a recargarse del disco y, por lo tanto, nunca permanecerá desactualizado por más de 10 minutos.
  • Detectar las modificaciones en los datos subyacentes y, luego de esto, expulsar los datos modificados del caché (lo que hará que éste se recargue cuando se lo solicite) o recargar los datos actualizados en el caché.

WebSphere eXtreme Scale soporta ambos enfoques.

La Figura 7 le muestra en qué lugar encaja la copia caché en el escenario completo que se describe con anterioridad en la Figura 4.

Figura 7. Introducción de la copia caché como respuesta al desafío de escalabilidad
Introducción de la copia caché como respuesta al desafío de escalabilidad

Detalles de implementación

WebSphere eXtreme Scale es un middleware no invasivo que forma parte de un paquete de un solo archivo JAR de 15 MB, no depende de WebSphere Application Server Network Deployment y funciona con las versiones actuales y más viejas de WebSphere Application Server Network Deployment, WebSphere Application Server Community Edition y algunos servidores de aplicación que no son de IBM (como, por ejemplo, JBoss y WebLogic). WebSphere eXtreme Scale también funciona con J2SE, JVMs de™ Sun™ e IBM y Spring. Debido a esta independencia, de ser necesario, un solo caché o una red de cachés puede abarcar múltiples células de WebSphere Application Server.

Mientras que WebSphere eXtreme Scale es independiente, requiere un marco externo para la instalación de aplicaciones y para iniciar / detener los JVM que sirven de host para dichas aplicaciones (a menos que desee hacer todo a través de comandos) como WebSphere Application Server (también se soportan los marcos WebLogic y JBoss). WebSphere eXtreme Scale se puede gestionar y monitorear por medio de IBM Tivoli® Monitoring, al igual que por medio de Hyperic HQ y Wily Introscope.

WebSphere eXtreme Scale sólo usa TCP para la comunicación (no usa multidifusión o UDP). No se requiere el uso de topologías de red especiales (como, por ejemplo, una subred compartida) o requisitos previos similares. Se pueden usar nodos geográficamente remotos para las réplicas de caché.

Particiones

WebSphere eXtreme Scale usa el concepto de una partición para la escalabilidad horizontal de un caché. Los datos (objetos Java) se almacenan en un caché. Cada dato tiene una clave única. Los datos se colocan en el caché y se recuperan del mismo por medio de esta clave.

Considere este ejemplo simple, aunque arcaico, de almacenar correo en un armario de oficina. La clave es la misma: el último nombre va primero. Se puede imaginar un armario de oficina con dos cajones: uno tiene un rótulo que dice A-L y el otro tiene un rótulo que dice M-Z. Cada cajón es una partición. Usted puede escalar su caché de correo agregando otro armario. Para esto, es necesario cambiar los rótulos de los cajones (A-F, G-L, M-R, S-Z) y, luego de esto, hay que volver a ordenar todo el correo en los cajones correctos. De esta forma, usted logra duplicar el tamaño de su caché de correo y puede continuar con la expansión.

Un problema con su caché de correo es que los nombres de las personas no se distribuyen de manera equitativa. Es probable que las letras M, R y S se llenen más rápido que las letras Q, X e Y. Esto provocará la carga despareja de su caché en lo que se refiere a la memoria y al procesamiento.

La forma en la que realmente funcionan las particiones es la siguiente: se calcula un código hash con respecto a la clave. Dicho código hash es un número entero que se debería devolver como un número único de cada clave única. Por ejemplo, si la clave es un número entero, este valor puede servir como código hash. En Java, el método de código hash String calcula el código hash de una cadena tratando a dicha cadena, en cierta forma, como un número base 31. En WebSphere eXtreme Scale, usted decide la cantidad de particiones para su caché desde un primer momento. Para colocar un elemento en el caché, WebSphere eXtreme Scale calcula el código hash de la clave, lo divide por la cantidad de particiones y la cantidad restante identifica a la partición que almacenará el elemento. Por ejemplo, si usted tiene tres particiones y el código hash de su clave es 7, 7 dividido 3 da 2 y el resto es 1. Por lo tanto, el elemento se almacena en la partición 1. Las particiones se enumeran comenzando con 0. El código hash debería brindar una distribución uniforme de los valores a lo largo de todo el espacio de la clave, de forma tal que las particiones estén bien equilibradas. WebSphere eXtreme Scale calcula los códigos hash sobre las claves por usted de manera automática. Si lo desea, usted puede indicar sus propios códigos hash.

Una clave para la escalabilidad horizontal lineal es la distribución uniforme de datos entre todas las particiones. Esto le permite elegir una gran cantidad de particiones de forma tal que cada nodo de servidor esté listo para manipular la carga en cada partición.

¿Cómo WebSphere eXtreme Scale expande su caché?

En el ejemplo de caché de correo que figura con anterioridad, un cajón equivale a una partición y usted usó armarios de oficina con dos cajones. Ambos cajones y armarios de oficina tienen un tamaño fijo. Si usted transfiere esta analogía a WebSphere eXtreme Scale, es posible comparar un armario de oficina con un servidor de almacenamiento que funciona en un JVM. Esto significa que el armario de oficina puede almacenar 2 GB de elementos como máximo (o mucho más si se usa un JVM de 64 bits). En WebSphere eXtreme Scale, un armario de oficina (servidor de almacenamiento) puede tener una cantidad variable de cajones (particiones). Cada partición puede almacenar 2 GB de elementos como máximo (asumiendo que se trata de un JVM de 32 bits y no de un JVM de 64 bits). Si sus objetos consumen n bytes de almacenamiento cada uno, cada partición puede contener, como mucho, 2 GB / n elementos.

En WebSphere eXtreme Scale, la cantidad de particiones se determina desde un principio para que pueda contener una cantidad proyectada de elementos. Supongamos que usted usa una gran cantidad de particiones (por ejemplo, 101). Esto significa que su caché de correo puede almacenar hasta casi 202 GB (101 particiones por 2 GB por partición) de elementos. Los servidores de almacenamiento se pueden distribuir en varias máquinas y muchos de ellos pueden compartir la misma máquina. En el caso inicial simple que se menciona con anterioridad y que involucra a un solo servidor de almacenamiento (lo que corresponde al caso de un armario de oficina), usted tendrá las 101 particiones en el mismo servidor de almacenamiento y, por lo tanto, sólo podrá almacenar 2 GB de elementos. Para expandir esta capacidad, usted debe contar con otro servidor de almacenamiento, preferentemente en otra máquina, para distribuir la carga.

Al contar con otro servidor de almacenamiento, WebSphere eXtreme Scale equilibraría la carga de su caché de correo automáticamente entre los dos servidores de almacenamiento, de manera tal que 50 de las 101 particiones se moverían al segundo servidor de almacenamiento. Si usted agregase un tercer servidor de almacenamiento en una tercera máquina, la carga se volvería a distribuir de manera equitativa moviendo 17 particiones desde el primer servidor de almacenamiento y 16 particiones desde el segundo servidor de almacenamiento hacia el servidor de almacenamiento nuevo. Por lo tanto, el servidor de almacenamiento nuevo tendría 33 particiones, mientras que los dos primeros tendrían 34 particiones cada uno.

De esta forma, WebSphere eXtreme Scale ofrece una escalabilidad horizontal lineal. Con 101 particiones y un solo servidor de almacenamiento, usted puede almacenar hasta 2 GB de elementos. Con 101 particiones, usted puede escalar hasta 101 servidores de almacenamiento para lograr un total de 202 GB de elementos. Estos servidores de almacenamiento se deberían distribuir en diferentes máquinas. La idea de todo esto consiste en distribuir la carga de manera equitativa entre todas las particiones. Por lo tanto, WebSphere eXtreme Scale distribuye las particiones equitativamente entre todas las máquinas disponibles. Por ende, esto nos ofrece la escalabilidad lineal. Al usar WebSphere Application Server, WebSphere eXtreme Scale iniciará y detendrá automáticamente los servidores de almacenamiento, en máquinas diferentes, a medida que la capacidad y la carga vaya variando. Por lo tanto, esto nos ofrece un caché elástico y dinámico (automáticamente gestionado).

Replicación

La escalabilidad horizontal es buena, ¿pero qué pasa si una máquina falla y usted pierde servidores?

WebSphere eXtreme Scale ofrece disponibilidad en caso de fallas mediante la replicación de datos. Una partición del caché se almacena en uno o más fragmentos. Al primer fragmento se lo denomina fragmento primario. Cuando usted define un caché de WebSphere eXtreme Scale, se especifica el nivel de replicación mediante la especificación de la cantidad de fragmentos de réplica. Los fragmentos de réplica son copias de seguridad de todos los datos que se encuentran en el fragmento primario y su principal propósito consiste en realizar la recuperación luego de una falla para que se pueda seguir ofreciendo una alta disponibilidad. En algunos casos, también se los puede usar para satisfacer solicitudes de lectura y así quitarle carga al fragmento primario.

La diferencia entre una partición y un fragmento puede no ser clara al principio:

  • Una partición es un concepto lógico. Representa 1 / x de los datos que están en el caché, donde el caché está particionado en x partes o particiones.
  • Un fragmento es una porción real y física de memoria que almacena los contenidos de una partición.

Para garantizar la tolerancia ante fallas y una alta disponibilidad, los algoritmos de distribución de fragmentos de WebSphere eXtreme Scale garantizan que el fragmento primario y el replicado nunca se encuentren en el mismo servidor de almacenamiento. Cuando el fragmento primario falla, se hace que la réplica se transforme en el fragmento primario y se crea una réplica nueva en otro servidor de almacenamiento.

Las réplicas pueden ser sincrónicas o asincrónicas. Esta distinción es importante cuando los datos se escriben en un caché de WebSphere eXtreme Scale. Las transacciones se usan para todas las lecturas y escrituras del caché de WebSphere eXtreme Scale. Una transacción de escritura no se completa hasta que todos los fragmentos de réplica sincrónica confirmen la recepción de los datos nuevos. Los fragmentos de réplica asincrónica se actualizan luego de completar la transacción. Por lo tanto, ofrecen un rendimiento más rápido de la transacción (generalmente, por lo menos seis veces más rápido), pero se incrementa el riesgo de perder datos a causa de fallas.

Seleccione la cantidad de réplicas sincrónicas y asincrónicas basándose en los requisitos de rendimiento y disponibilidad de su aplicación. Por ejemplo, usted puede tener una réplica sincrónica en otra máquina en el mismo centro de datos y una réplica asincrónica en una máquina en otro centro de datos. En WebSphere eXtreme Scale, se usan zonas para definir la noción de centros de datos y WebSphere eXtreme Scale se encarga de manejar esto de manera automática. Al seleccionar la cantidad de réplicas sincrónicas y asincrónicas, y la zona en la que se colocan, usted puede equilibrar su rendimiento y su disponibilidad y resiliencia en caso de fallas.

Volvamos al ejemplo del armario de oficina que mencionamos con anterioridad que tenía dos cajones para el correo (A-L y M-Z). En esta ocasión, suponga que usted define un fragmento de réplica. La Figura 8 le muestra un ejemplo de esto (aunque sólo con 3 particiones). Inicialmente, al contar con un solo contenedor, existen 101 fragmentos primarios que no incluyen fragmentos de réplica. Los fragmentos de réplica son completamente inútiles cuando contamos con un solo contenedor. Cuando se agrega el segundo contenedor, 50 de los fragmentos primarios se mueven al segundo contenedor. Los 51 fragmentos de réplica restantes también se mueven al segundo contenedor para que exista equilibrio. Además, en el caso de cada fragmento, su fragmento primario y su réplica se encuentran en contenedores diferentes. Lo mismo ocurre cuando usted agrega un tercer contenedor. Cada máquina pasa a tener 33 ó 34 fragmentos primarios y 33 ó 34 fragmentos de réplica diferentes.

Figura 8. Ejemplo de partición que muestra la ubicación de los fragmentos
Ejemplo de partición que muestra la ubicación de los fragmentos

Ahora, si algunos de los contenedores falla o se apaga, WebSphere eXtreme Scale reconfigura su caché para que cada uno de los dos servidores tenga 50 ó 51 fragmentos primarios y de réplica. Además, para cada fragmento, su fragmento primario y el de réplica se encuentran en contenedores diferentes. En este escenario de falla / apagado del servidor, el servidor que falló tenía 33 ó 34 fragmentos primarios y 33 ó 34 fragmentos de réplica. Para los fragmentos primarios, el fragmento de réplica que sobrevive pasa a ser un fragmento primario y se crean nuevos fragmentos de réplica en el otro servidor mediante el copiado de los datos desde el nuevo fragmento primario. Para los fragmentos de réplica que fallan, se deben crear nuevos fragmentos de réplica mediante el copiado de ellos desde el fragmento primario y colocándolos en un servidor que no sea el que sirve de host para el fragmento primario. WebSphere eXtreme Scale hace todo esto automáticamente, mientras que la carga y los datos en los servidores se mantienen equilibrados. Naturalmente, esto lleva poco tiempo. Recuerde que los fragmentos originales están en uso durante este proceso y, por lo tanto, no existe ningún tipo de tiempo de inactividad.

APIs

¿Qué APIs usa su código de aplicación para acceder a los datos?

Existen muchas opciones. Por ejemplo, los datos se suelen almacenar en una base de datos. JDBC (Java Database Connectivity) es una de las opciones establecidas y JPA (Java Persistence API) es el nuevo estándar. JPA es una especificación para la persistencia de los objetos Java en un almacén de datos relacional (generalmente, una base de datos como IBM DB2)®. Muchos usuarios tienen su propio nivel de acceso a los datos, con sus propias API, de acuerdo con el que se codifica su lógica de negocios. Por lo tanto, el nivel de acceso puede usar JDBC o JPA para obtener los datos. Por ende, estas llamadas de acceso de datos subyacentes se consolidan en el nivel de acceso de datos y se esconden de la lógica de negocios.

En un caché lateral, se usan dos API: interfaces para obtener datos del disco e interfaces diferentes para obtener datos del caché. Por lo tanto, usted suele tener que cambiar el código de aplicación para usar un caché lateral, como se lo describe con anterioridad. En una solicitud de lectura, primero verifique el caché. En caso de desacierto, busque los datos en el disco y colóquelos en el caché. La aplicación debe codificar esta lógica, usando las interfaces de disco y caché. Si se usa un nivel de acceso de datos, el código se podría consolidar allí y esconder de la aplicación involucrada.

El caché en línea parece ser mejor, ya que usted sólo tiene una interfaz (hacia el caché). Sin embargo, generalmente, las aplicaciones comienzan con una interfaz hacia el disco, que luego se debe convertir en una interfaz de caché en línea. Una vez más, si se usa un nivel de acceso de datos, el código se puede consolidar allí y esconder de la aplicación involucrada.

WebSphere eXtreme Scale le ofrece tres API para acceder a los datos que contiene:

  • La API denominada ObjectMap es la API de nivel más bajo y más alto rendimiento. Es muy parecida a un Java (Hash) Map común, con operaciones simples de crear, leer, actualizar y borrar.
  • La API denominada EntityManager es la interfaz de nivel más alto y la más fácil de usar. Es muy similar a la interfaz JPA. Si su código usa la interfaz JPA, el uso de la API denominada EntityManager hace que la conversión sea más fácil.
  • La API denominada servicio de datos REST permite que los clientes HTTP y Microsoft .NET usen el ADO.NET Data Services Protocol para acceder a las cuadrículas de datos de WebSphere eXtreme Scale.

Desde la perspectiva de una API, existen tres formas generales de usar WebSphere eXtreme Scale:

  • No se requiere cambio de codificación; sólo cambios de configuración. En estos casos, WebSphere eXtreme Scale le ofrece complementos para la infraestructura existente que las aplicaciones ya están usando con el objetivo de extender las capacidades de copia de caché de la infraestructura de acuerdo con las de WebSphere eXtreme Scale. WebSphere eXtreme Scale se usa como caché lateral. Los casos de uso A, B y C que figuran a continuación son ejemplos de esto.
  • Use WebSphere eXtreme Scale como caché lateral para descongestionar. En estos cachés, usted podría insertar una pequeña cantidad de código en unas pocas áreas clave y usar la API denominada ObjectMap para realizar el caché de los datos. El caso de uso D que figura a continuación es un ejemplo de esto.
  • Grandes mejoras a la escalabilidad resultan del reemplazo de la interfaz de datos de la aplicación por WebSphere eXtreme Scale, de forma tal que pasa a ser el registro del sistema. En este caso, WebSphere eXtreme Scale es un caché en línea. Si en la actualidad usa JPA, usted podría usar la API EntityManager de WebSphere eXtreme Scale para hacer que la conversión sea más fácil. El caso de uso E describe este enfoque.

El caché lateral potencia los datos en memoria y los principios de copia de caché, mientras que el caché en línea también permite el potenciamiento del principio de particionamiento / escalabilidad horizontal.

WebSphere eXtreme Scale le ofrece la API denominada Data Grid como una forma adicional de potenciar ventajosamente el particionamiento. La idea de esto consiste en mover el procesamiento de los datos en vez de mover los datos hacia el procesador. Existe la posibilidad de ejecutar la lógica de negocios en paralelo sobre todas las particiones de los datos o sobre un subgrupo de ellas. Luego de esto, los resultados del procesamiento paralelo se pueden consolidar en un solo lugar. Más allá de distribuir la carga de datos de recuperación y almacenamiento a lo largo de la cuadrícula, el procesamiento de estos datos también se puede distribuir a lo largo de los servidores de partición de la cuadrícula y, por lo tanto, estar particionado, con el objetivo de ofrecer una escalabilidad más lineal.

Otros elementos de implementación

Hasta ahora, este artículo se concentró en un caché, un contenedor que almacena objetos Java basándose en claves. En la terminología de WebSphere eXtreme Scale, se considera que un caché es un mapa. A continuación, incluimos otros elementos y términos que son importantes en relación con WebSphere eXtreme Scale:

  • Un mapSet incluye un conjunto o una colección de mapas que comparten un algoritmo de particionamiento común. La cantidad de particiones y las configuraciones de replicación se configuran en un mapSet.
  • Una cuadrícula incluye una colección de uno o más mapSets.
  • Un contenedor incluye una colección de una o más cuadrículas.
  • Un (contenedor) servidor incluye y gestiona una colección de uno o más contenedores.
  • Un JVM o proceso Java puede incluir un servidor o ningún servidor.

Casos de uso de muestra

La clave del éxito consiste en identificar los puntos complicados y los cuellos de botella en su aplicación y, luego de esto, usar WebSphere eXtreme Scale para aliviarlos o eliminarlos, basándose en los principios de los datos en memoria, la copia caché y la escalabilidad horizontal (particionamiento). A continuación, ilustramos algunos casos de uso.

A. Mejora del servicio de caché dinámico de WebSphere Application Server

El servicio de caché dinámico de WebSphere Application Server (al que se suele denominar DynaCache) es un excelente ejemplo del uso de un caché lateral para mejorar el rendimiento. DynaCache es una característica de WebSphere Application Server que se originó gracias al trabajo que se realizó cuando IBM estuvo a cargo de la página Web para los Juegos Olímpicos de 1998. Para ofrecer una escalabilidad extrema para una audiencia mundial, la idea consistía en realizar el caché en memoria de los datos de la página Web luego de generarla. Éste es el ya conocido patrón de datos en memoria. El caché no sólo ahorra entradas / salidas del disco sino que también el tiempo de procesamiento que lleva juntar todas las páginas HTML.

Hay algunas cosas con las que hay que tener cuidado en el caso de los grandes cachés dinámicos. Algunos pueden superar los 2 GB y alcanzar 30 ó 40 GB de tamaño. Esto excede la capacidad de la memoria virtual del proceso. La mayoría de estos datos se encuentran en disco y acceder a ellos cuesta bastante. Además, estos cachés se encuentran en cada máquina. El caché dinámico también es parte del espacio de dirección de la aplicación.

WebSphere eXtreme Scale le ofrece un complemento fácil de usar para reemplazar el sistema de disco y memoria en proceso del caché dinámico (lateral) por una cuadrícula en memoria dinámica y distribuida. Usted especifica los parámetros de configuración en un archivo XML y no se requiere ningún tipo de codificación. Los beneficios de esto incluyen lo siguiente:

  • El caché se elimina del espacio de dirección de la aplicación y se coloca en el espacio de dirección de un contenedor de WebSphere eXtreme Scale.
  • El caché puede escalar fácilmente hasta los 40 GB y se puede distribuir en varias máquinas para que todo el caché esté en memoria y se minimice el tiempo de acceso.
  • Todas las aplicaciones y las instancias de WebSphere Application Server que lo necesiten pueden compartir este (único) caché.

WebSphere eXtreme Scale es el que más provecho saca de todo esto y es fácil de usar. Vea Reemplazo de Dynacache Disk Offload por Dynacache usando IBM WebSphere eXtreme Scale para mayor información.

B. El caché L2 para Hibernate y OpenJPA

WebSphere eXtreme Scale incluye complementos de caché nivel 2 (L2) para los proveedores de OpenJPA y Hibernate JPA. WebSphere Application Server soporta tanto a Hibernate como a OpenJPA. JPA le permite configurar un solo caché lateral (como se puede observar en la Figura 5) para mejorar el rendimiento. Además, éste también es un caché en proceso y, por ende, su tamaño está limitado.

Como los discos son lentos, es más rápido conseguir los datos de un caché nivel 2. Como ya hemos visto, WebSphere eXtreme Scale le puede ofrecer cachés muy grandes. Las instancias de procesos que usan OpenJPA o Hibernate también pueden compartir los grandes cachés distribuidos de WebSphere eXtreme Scale. Una de las características más importantes del caché JPA es que no es necesario realizar ningún cambio de codificación para usarlos. Usted sólo debe configurar algunas propiedades (como, por ejemplo, el tamaño y los tipos de objeto a incluir en el caché) en su archivo persistence.xml. Vea Uso de eXtreme Scale con JPA para mayor información.

C. Replicación de sesión HTTP

Los datos de sesión HTTP son uno de los usos ideales de WebSphere eXtreme Scale. Por su naturaleza, los datos son temporarios y no existe ningún requisito de persistencia para conservarlos en el disco. Según el principio de datos en memoria, usted puede aumentar el rendimiento de manera muy relevante moviendo los datos desde el disco hasta la memoria. En primer lugar, los datos se almacenaban en disco (o en la base de datos) para que estuviesen disponibles en caso de que se presentase una falla (permitiendo que otro servidor Web tuviese acceso a los datos de sesión si el servidor fallaba).

WebSphere eXtreme Scale no ofrece conmutación por error y disponibilidad en caso de fallas y tiene un rendimiento y una capacidad de escalabilidad muy superior a la de las soluciones de disco. Por lo tanto, es una solución ideal para estos datos. WebSphere eXtreme Scale es muy fácil de usar para esta aplicación. No es necesario realizar ningún tipo de cambio al código de su aplicación. Simplemente, coloque un archivo XML en el directorio META-INF del archivo .war de su aplicación Web para configurarla de manera tal que WebSphere eXtreme Scale sea el lugar de almacenamiento (sistema de registro con copia caché en línea) para los datos de sesión HTTP. En el caso de presentarse una falla, el acceso a los datos de sesión será más rápido, ya que estarán en memoria, y los datos en sí mismos conservarán una alta disponibilidad. Vea Gestión de sesión HTTP escalable y robusta con WebSphere eXtreme Scale para mayor información.

D. Mediación de caché de ESB de SOA

Un banco minorista que tiene 22 millones de usuarios almacena los perfiles de sus clientes en un CICS Enterprise Information System (EIS) en un host System z®. Varias aplicaciones acceden a estos perfiles. En este caso, el host es una gran computadora y los perfiles se almacenan en una base de datos que se encuentra en dicha computadora. Cada aplicación usa un servicio SOA a través de un Bus de Servicios Empresariales (Enterprise Service Bus o ESB) para obtener los datos del perfil. Antes de la implementación de WebSphere eXtreme Scale, cada aplicación tenía su propio caché de perfiles, pero estos cachés se encontraban en cada espacio de dirección de la aplicación (es decir que no se compartían). El caché reduce parte de la carga de búsqueda de perfiles del EIS del host, aunque un caché compartido más grande reduciría la carga todavía más.

En este caso, WebSphere eXtreme Scale se usa como un caché lateral adjunto a la red que contiene alrededor de 8 GB en perfiles (4 GB + 4 GB de réplicas para ofrecer una alta disponibilidad). Se inserta una mediación en el ESB para memorizar las llamadas del servicio de búsqueda de perfiles. El nombre del servicio y sus parámetros se usan como una clave y el valor es el perfil en sí mismo. Si el perfil no se encuentra en el caché, la mediación lo obtiene desde el host y almacena el resultado en el caché. Un expulsador elimina las entradas que se realizaron hace más de 30 minutos para evitar el estancamiento y limitar el tamaño del caché. No es necesario realizar ningún cambio al código de la aplicación. La mediación se inserta de manera transparente en el ESB.

Antes de la implementación de WebSphere eXtreme Scale, el inicio de sesión llevaba 700 ms y dos llamadas al back-end. Ahora, el inicio de sesión lleva 20 ms y el acceso al caché de perfiles es 35 veces más rápido. Además, la carga en el EIS se redujo debido a que se eliminaron las llamadas de búsqueda de perfiles. El caché se comenzó a encargar de todo esto. Los ahorros en los costos mensuales como resultado de esta reducción en la carga fueron considerables.

Un ESB de SOA es un excelente lugar para agregar la copia caché de forma económica. Esto le ofrece puntos de invocación de servicio fáciles de usar y se puede insertar un mediador de servicio que usa un caché coherente con gran facilidad sin que exista la necesidad de modificar las aplicaciones de flujo ascendente (cliente) o de flujo descendente (servidor original).

E. Servicio de perfil del cliente

Volvamos al primer ejemplo que describimos en este artículo, donde se agotaba la capacidad de la base de datos y el usuario debía soportar 10 veces más de su carga actual. Este usuario registraba un índice máximo de 8.000 vistas por segundo a la página. La aplicación estaba usando una base de datos SQL para consultar y actualizar los perfiles. Cada página de la aplicación realizaba 10 búsquedas de perfil en la base de datos a 60 ms cada una (lo que daba un total máximo de 90.000 solicitudes por segundo). Cada perfil de usuario pesa 10 KB. Como en la actualidad hay 10 millones de usuarios registrados, esto representa 100 GB en datos de perfiles. Si la base de datos deja de funcionar o si hay problemas de acceso a la red en diversas partes del mundo, la aplicación deja de funcionar. Estos problemas se solucionan conservando los datos en memoria.

La aplicación reemplazó la base de datos por un caché en línea de WebSphere eXtreme Scale como sistema de registro. WebSphere eXtreme Scale se insertó como un front end para la base de datos. El caché de WebSphere eXtreme Scale se configuró como un caché de escritura retrasada. El el caso de replicación de la sesión HTTP, usted vio cómo se usaba WebSphere eXtreme Scale como la memoria de almacenamiento para ofrecer un mejor rendimiento. En ese caso, los datos no eran realmente temporarios. En este caso, usted desea que los datos sean persistentes en la base de datos para favorecer un almacenamiento por un período de tiempo prolongado. Como ya hemos visto, WebSphere eXtreme Scale le ofrece replicación para favorecer la disponibilidad y el soporte de transacciones. Estas características le permiten colocar un caché de WebSphere eXtreme Scale en frente de la base de datos con el objetivo de sacar provecho de todo esto.

Como ya lo hemos discutido, en el caso de un caché de escritura retrasada, la transacción se completa cuando los datos se escriben en el caché (lo que ocurre rápido). Luego de esto, los datos se escriben en el disco de la base de datos. Esto quiere decir que el caché de escritura retrasada debe conservar los datos de manera confiable en el caché hasta que se puedan escribir en el disco. WebSphere eXtreme Scale le ofrece esta confiabilidad por medio de réplicas. Usted puede configurar este retraso de escritura en términos de la cantidad de escrituras o de la cantidad de tiempo. Si la base de datos back-end falla, o si su conexión de red a dicha base de datos falla o comienza a funcionar más lentamente, su aplicación seguirá funcionando. Además, esta falla resulta transparente para su aplicación y no la daña. WebSphere eXtreme Scale realiza un caché de todos los cambios y los aplica cuando la base de datos se recupera (o los aplica sobre una copia de seguridad de la base de datos en el caso que se la ponga online).

Esta escritura retrasada tiene diversas ventajas, incluso más allá del menor tiempo de respuesta que se ofrece a los usuarios para sus operaciones de escritura. Se puede aliviar bastante la carga de la base de datos back-end para así lograr usarla de manera más eficiente:

Se instala un caché de WebSphere eXtreme Scale distribuido, adjuntado a la red y que usa escritura retrasada antes de una base de datos SQL. Los contenedores del servidor del caché se implementan en diez cajas x86 de 8 núcleos que prestan servicios a los perfiles de usuario y que aceptan modificaciones. Las réplicas asincrónicas se usan para lograr el mayor rendimiento con una buena disponibilidad. Cada caja se ocupa de 8.000 solicitudes por segundo, lo que ofrece una capacidad de procesamiento total de 80.000 solicitudes por segundo con 6 ms de tiempo de respuesta (es decir, diez veces más rápido que antes).

La solución debe escalar a 1 millón de solicitudes por segundo sin que se modifique el tiempo de respuesta. WebSphere eXtreme Scale podrá lograr esto gracias a la escalabilidad lineal agregando alrededor de 120 servidores adicionales. Cada servidor se ocupa de alrededor de 110 MB por segundo (8.000 solicitudes por segundo con tamaños de registro de 10 KB) del tráfico total (90 MB por solicitudes y 20 MB por replicación). Cada servidor debe tener una placa Ethernet de varios GB. En la actualidad, es necesario contar con varias placas de red en cada servidor debido al poder de procesamiento de incluso los servidores pequeños y al rendimiento de WebSphere eXtreme Scale. Se usan 300 JVM de 32 bits y 1 GB de capacidad.


Resumen

IBM WebSphere eXtreme Scale opera como una cuadrícula en memoria que procesa, particiona, replica y gestiona los datos de la aplicación y la lógica de negocios a lo largo de cientos de servidores de manera dinámica. Además, ofrece integridad transaccional y conmutación por error transparente para garantizar una alta disponibilidad, una alta confiabilidad y tiempos de respuesta consistentes. WebSphere eXtreme Scale es una plataforma esencial de copia caché distribuida que le ofrece una escalabilidad elástica y entornos de computación en nube de próxima generación.

Elástica significa que la cuadrícula se monitorea y gestiona a sí misma, permite las capacidades de escalabilidad interna y horizontal y se puede arreglar a sí misma recuperándose automáticamente después de una falla. La escalabilidad horizontal permite que se agregue capacidad de memoria mientras que la cuadrícula se está ejecutando (sin que sea necesario reiniciar el sistema). De manera contraria, la escalabilidad interna permite la eliminación de capacidad de memoria al instante.

¡Espero que esto tenga mucho más sentido para usted ahora que la primera vez que lo leyó! WebSphere eXtreme Scale hace que las aplicaciones puedan escalar con el objetivo de soportar grandes volúmenes de usuarios y transacciones. También resulta muy útil en aplicaciones más pequeñas al momento de ofrecer una mejor capacidad de procesamiento y un menor tiempo de respuesta.

Con esta información, usted ahora puede comenzar a aprovechar el potencial de WebSphere eXtreme Scale para que lo ayude a solucionar los peores problemas de escalabilidad con las aplicaciones vitales que cuenta en la actualidad. WebSphere eXtreme Scale le ofrece muchos beneficios, incluyendo la gestión automática del crecimiento, la disponibilidad continua, el uso óptimo de las bases de datos existentes, tiempos de respuesta menores, la escalabilidad lineal y la capacidad de sacar provecho del hardware común y corriente. Los resultados de negocios incluyen menores tiempos de respuesta para sus clientes, menores costo total de propiedad (TCO) y un mayor retorno sobre la inversión (ROI) gracias a una escalabilidad y a una utilización de recursos más efectiva.


Agradecimientos

Me gustaría agradecer a las siguientes personas por revisar este documento y haber contribuido con su redacción: Veronique Moses, Art Jolin, Richard Szulewski y Lan Vuong.

Recursos

Aprender

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=963352
ArticleTitle=Introducción a WebSphere eXtreme Scale (Parte 1): ¿Qué es WebSphere eXtreme Scale y cómo funciona?
publish-date=08152011