Colocación y particiones

Tiene disponibles dos estrategias de colocación para WebSphere eXtreme Scale: partición fija y por contenedor. La elección de la estrategia de colocación afecta a cómo la configuración de despliegue coloca particiones en la cuadrícula de datos remota.

Colocación de partición fija

Puede establecer la estrategia de colocación en el archivo XML de la política de despliegue. La estrategia de colocación predeterminada es la ubicación de partición fija, habilitada con el valor FIXED_PARTITION. El número de fragmentos primarios que se colocan en los contenedores disponibles es igual al número de particiones que ha configurado con el atributo numberOfPartitions. Si ha configurado réplicas, el número mínimo total de fragmentos colocados se define a través de la siguiente fórmula: ((1 fragmento primario + fragmentos mínimos síncronos) * particiones definidas). El número máximo total de fragmentos colocados se define a través de la siguiente fórmula: ((1 fragmento primario + máximo de fragmentos síncronos + máximo de fragmentos asíncronos) * particiones). El despliegue de WebSphere eXtreme Scale se distribuye entre estos fragmentos sobre los contenedores disponibles. Las claves de cada correlación pasan por el código hash en particiones asignadas basándose en las particiones totales que ha definido. Las claves realizan el código hash en la misma partición, aunque la partición se mueva debido a una migración tras error o a cambios de servidor.

Por ejemplo, si el valor de numberPartitions es 6 y el valor de minSync es 1 para MapSet1, el número total de fragmentos para dicho conjunto de correlaciones es 12, porque cada una de las 6 particiones requiere una réplica síncrona. Si se inician tres contenedores, WebSphere eXtreme Scale coloca cuatro fragmentos por contenedor paraMapSet1.

Colocación por contenedor

La estrategia de colocación alternativa es colocación por contenedor, que se habilita con el valor PER_CONTAINER para el atributo placementStrategy en el elemento de conjunto de correlaciones en el archivo XML de despliegue. Con esta estrategia, el número de fragmentos primarios colocados en cada contenedor nuevo es igual al número de particiones, P, que ha configurado. El entorno de despliegue de WebSphere eXtreme Scale coloca P réplicas de cada partición para cada contenedor restante. El valor numInitialContainers se ignora cuando se utiliza la colocación por contenedor. Las particiones cada vez son más grandes a medida que crecen los contenedores. Las claves para las correlaciones no son fijas para una determinada partición de esta estrategia. El cliente se direcciona a una partición y utiliza el primario aleatorio. Si un cliente desea volver a conectarse a la misma sesión que se ha utilizado para volver a encontrar la clave, debe utilizar un descriptor de contexto de sesión.

Para obtener más información, consulte SessionHandle para el direccionamiento.

Para los servidores detenidos o con migración tras error, el entorno de WebSphere eXtreme Scale traslada los fragmentos primarios en la estrategia de colocación por contenedor, si todavía contienen datos. Si los fragmentos están vacíos, se descartan. En la estrategia por contenedor, los fragmentos primarios antiguos no se conservan porque se colocan nuevos fragmentos primarios para cada contenedor.

WebSphere eXtreme Scale permite colocación por contenedor como alternativa a lo que se podría denominar la estrategia de colocación "típica", un enfoque de partición fija con la clave de una correlación en hash en una de estas particiones. En un caso por contenedor (que se establece con PER_CONTAINER), el despliegue coloca las particiones en el conjunto de los servidores de contenedor en línea y automáticamente las amplía o reduce a medida que se añaden o eliminan contenedores de la cuadrícula de datos del servidor. Una cuadrícula de datos con el enfoque de partición fija funciona bien para cuadrículas basadas en clave, donde la aplicación utiliza un objeto de clave para localizar los datos en la cuadrícula. A continuación se explica la alternativa.

Ejemplo de una cuadrícula de datos por contenedor

Las cuadrículas de datos PER_CONTAINER son distintas. Puede especificar que la cuadrícula de datos utiliza la estrategia de colocación PER_CONTAINER con el atributo placementStrategy en el archivo XML de despliegue. En lugar de configurar cuántas particiones en total desea en la cuadrícula de datos, puede especificar cuántas particiones desea por contenedor que inicie.

Por ejemplo, si establece cinco particiones por contenedor, se crearán cinco nuevos primarios de partición anónimos al iniciar el servidor de contenedor y se crearán las réplicas necesarias en los otros servidores de contenedor desplegados.

A continuación se muestra una secuencia potencial en un entorno por contenedor a medida que la cuadrícula de datos crece.

  1. Iniciar el contenedor C0 que aloja 5 primarios (P0 - P4).
    • C0 aloja: P0, P1, P2, P3, P4.
  2. Iniciar el contenedor C1 que aloja 5 primarios más (P5 - P9). Las réplicas se equilibran en los contenedores.
    • C0 aloja: P0, P1, P2, P3, P4, R5, R6, R7, R8, R9.
    • C1 aloja: P5, P6, P7, P8, P9, R0, R1, R2, R3, R4.
  3. Iniciar el contenedor C2 que aloja 5 primarios más (P10 - P14). Las réplicas se siguen equilibrando.
    • C0 aloja: P0, P1, P2, P3, P4, R7, R8, R9, R10, R11, R12.
    • C1 aloja: P5, P6, P7, P8, P9, R2, R3, R4, R13, R14.
    • C2 aloja: P10, P11, P12, P13, P14, R5, R6, R0, R1.

El patrón continúa a medida que se inician más contenedores, creando cinco nuevas particiones primarias cada vez y reequilibrando las réplicas en los contenedores disponibles en la cuadrícula de datos.

Nota: WebSphere eXtreme Scale no traslada fragmentos primarios al utilizar la estrategia PER_CONTAINER, solo réplicas.

Recuerde que los números de partición son arbitrarios y no tienen nada que ver con las claves, por lo que no se puede utilizar el direccionamiento basado en claves. Si un contenedor se detiene, los ID de partición creados para dicho contenedor dejan de utilizarse, de modo que queda un vacío entre los ID de partición. En el ejemplo, ya no habría particiones P5 - P9 si el contenedor C2 fallase, quedando sólo P0 - P4 y P10 - P14, por lo que el hash basado en claves resulta imposible.

La utilización de números como cinco o incluso más probablemente 10 para el número de particiones por contenedor funciona mejor si tiene en cuenta las consecuencias de una anomalía de contenedor. Para distribuir la carga de alojar fragmentos equitativamente en la cuadrícula de datos, necesita más de una partición para cada contenedor. Si tiene una sola partición por contenedor, cuando un contenedor falle, un solo contenedor (el que aloja el fragmento de réplica correspondiente) deberá soportar la carga total del primario perdido. En este caso, la carga se dobla inmediatamente para el contenedor. Sin embargo, si tiene cinco particiones por contenedor, cinco contenedores asumen la carga del contenedor perdido, lo que disminuye el impacto en cada uno en un 80 por ciento. El uso de varias particiones por contenedor suele disminuir el impacto potencial sobre cada contenedor considerablemente. De forma más directa, considere un caso en el que un contenedor aumenta su carga de trabajo de improviso; la carga de réplica de dicho contenedor se distribuye en 5 contenedores en lugar de hacerlo en sólo uno.

Uso de la política por contenedor

Varios escenarios hacen que la estrategia por contenedor sea una configuración ideal, como por ejemplo la réplica de sesiones HTTP o el estado de sesión de aplicaciones. En tal caso, un direccionador HTTP asigna una sesión a un contenedor de servlet. El contenedor de servlet tiene que crear una sesión HTTP y elige uno de los 5 primarios de partición locales para la sesión. El "ID" de la partición elegida se almacena entonces en una cookie. El contenedor de servlet tiene ahora acceso local al estado de la sesión, lo que significa un acceso de latencia cero a los datos correspondientes a esta solicitud siempre que se mantenga la afinidad de sesiones. Y eXtreme Scale replica los cambios de la partición.

En la práctica, recuerde las repercusiones de un caso en el que tenga varias particiones por contenedor (por ejemplo, 5 otra vez). Naturalmente, con cada contenedor nuevo que se inicie, tiene 5 primarios de partición más y 5 réplicas más. Con el tiempo, se deben crear más particiones y no se deben mover ni destruir. Pero los contenedores no se comportarían realmente de este modo. Cuando un contenedor se inicia, aloja 5 fragmentos primarios, que se pueden denominar ser primarios de "inicio", existentes en los contenedores respectivos que los crearon. Si el contenedor falla, las réplicas se convierten en primarios y eXtreme Scale crea 5 réplicas más para mantener la alta disponibilidad (a menos que se haya inhabilitado la reparación automática). Los nuevos nuevas primarios están en un contenedor diferente del que los creó y pueden denominarse primarios "externos". La aplicación nunca debe colocar un estado o sesiones nuevos en un primario externo. Al final, el primario externo no tiene ninguna entrada y eXtreme Scale lo suprime automáticamente y también suprime sus réplicas asociadas. El objetivo de los primarios externos es permitir que las sesiones existentes sigan estando disponibles (pero no las sesiones nuevas).

Un cliente puede seguir interactuando con una cuadrícula de datos que no se basa en claves. El cliente simplemente inicia una transacción y almacena los datos en la cuadrícula de datos independiente de cualquier clave. Solicita a la sesión un objeto SessionHandle, un descriptor de contexto serializable que permite al cliente interactuar con la misma partición cuando sea necesario. WebSphere eXtreme Scale elige una partición para el cliente de la lista de primarios de partición iniciales. No devuelve una partición primaria externa. El SessionHandle se puede serializar en una cookie HTTP, por ejemplo, y más tarde se puede volver a convertir la cookie en un SessionHandle. A continuación, las API WebSphere eXtreme Scale pueden obtener una sesión vinculada de nuevo a la misma partición, utilizando SessionHandle.

Nota: No puede utilizar agentes para interactuar con una cuadrícula de datos PER_CONTAINER.

Ventajas

La descripción anterior es distinta a una cuadrícula de datos hash o FIXED_PARTITION normal porque el cliente por contenedor almacena los datos en un lugar de la cuadrícula, obtiene un manejador para ellos y lo utiliza para volver a acceder a ellos. No hay ninguna clave proporcionada por la aplicación, al contrario que en el caso de partición fija.

El despliegue no crea una partición nueva para cada sesión. Por lo tanto, en un despliegue por contenedor, las claves utilizadas para almacenar datos en la partición deben ser exclusivas en dicha partición. Por ejemplo, puede hacer que su cliente genere un SessionID exclusivo y luego lo utilice como clave para encontrar información en correlaciones en dicha partición. Luego, varias sesiones de cliente interaccionan con la misma partición, por lo que la aplicación tiene que utilizar claves exclusivas para almacenar datos de sesión en cada partición concreta.

Los ejemplos anteriores utilizaban 5 particiones, pero se puede utilizar el parámetro numberOfPartitions del archivo XML para especificar las particiones del modo necesario. En lugar de por cuadrícula de datos, el valor es por contenedor. (El número de réplicas se especifica del mismo modo que en la política de partición fija).

La política por contenedor también se puede utilizar con varias zonas. Si es posible, eXtreme Scale devuelve un SessionHandle a una partición cuyo primario está ubicado en la misma zona que el cliente en cuestión. El cliente puede especificar la zona como un parámetro al contenedor o utilizando una API. El ID de zona del cliente se puede definir utilizando serverproperties o clientproperties.

La estrategia PER_CONTAINER para una cuadrícula de datos es adecuada para las aplicaciones que almacenan estado de tipo conversacional en lugar de datos orientados a base de datos. La clave para acceder a los datos sería un ID de conversación y no está relacionada con un registro de base de datos específico. Proporciona un rendimiento superior (porque los primarios de partición pueden compartir ubicación con los servlets por ejemplo) y facilita la configuración (no es necesario calcular particiones y contenedores).