Arquitectura de colectivos

El conjunto de servidores de Liberty en un único dominio de gestión se denomina colectivo. Un colectivo consta como mínimo de un servidor con la característica collectiveController-1.0 habilitada que se denomina controlador colectivo. Opcionalmente, un colectivo puede tener muchos servidores con la característica collectiveMember-1.0 habilitada que se denominan miembros de colectivo y un colectivo puede configurarse para tener muchos controladores colectivos.

El controlador de colectivo proporciona un punto de control administrativo centralizado para realizar operaciones como direccionamiento de beans gestionados, transferencia de archivos y gestión de clústeres. Un rol central de los controladores colectivos es recibir la información, como los atributos de bean gestionado y estado operativo, de los miembros dentro del colectivo para que se puedan recuperar los datos inmediatamente sin tener que invocar una operación en cada miembro individual.

Figura 1. Arquitectura de colectivos Liberty
El conjunto de servidores de Liberty en un único dominio de gestión se denomina colectivo. Un colectivo consta de un servidor como mínimo con la característica collectiveController-1.0 habilitada. De modo opcional, tiene muchos miembros de colectivo y existe en un conjunto de muchos controladores colectivos.

Un conjunto de controladores colectivos se denomina conjunto de réplicas. Solo hay un conjunto de réplicas por colectivo y todos los controladores deben ser parte del conjunto de réplicas. Cuando hay más de un controlador colectivo, cada controlador colectivo duplica sus datos en los demás controladores colectivos del conjunto de réplicas para permitir la alta disponibilidad y protección de datos. El conjunto de réplicas está lógicamente presente aun cuando solo esté en uso un controlador. Al cambiar la configuración para varias réplicas en un conjunto, incluya al menos tres réplicas en el conjunto. Los controladores del conjunto de réplicas se comunican entre sí mediante un esquema de colaboración para garantizar que se duplican los datos en todo el conjunto de controladores sin importar qué controlador del conjunto recibe una operación para almacenar los datos. Cada controlador tiene un puerto dedicado para que lo utilice el protocolo de réplica. La comunicación entre los controladores del conjunto de réplicas siempre se autentica y se protege con SSL. Para garantizar la coherencia entre las réplicas de controlador, se utiliza un algoritmo de quórum. Para una alta disponibilidad, el número de controladores de un conjunto de réplicas debe ser un número impar. Para garantizar el mantenimiento del quórum, es necesario que los miembros del conjunto de réplicas de controlador de colectivo no abarquen varios centros de datos. Si no hay quórum, los cambios como un inicio o detención del servidor, o las actualizaciones de configuración no se pueden realizar en el colectivo.

Un miembro de colectivo se puede configurar con varios puntos finales del controlador de colectivo. Un miembro de colectivo se comunica con un único controlador de colectivo a la vez; sin embargo, una configuración con más de un punto final de controlador de colectivo proporciona migración tras error y equilibrio de carga de trabajo. La comunicación de miembro a controlador es siempre en forma de operaciones de MBean que se realizan a través de IBM® JMX REST Connector. La comunicación entre controladores y miembros siempre se autentica y se protege con SSL.

Para obtener más información, consulte Configuración del entorno de gestión del servidor para Liberty mediante el uso de colectivos.

Configuración de seguridad de dominio administrativo:
La configuración de seguridad de dominio administrativo se compone de dos partes:
  • Dominio de usuario

    Este dominio se basa en seguridad basada en roles Java™ que define el rol de administrador. Este se puede correlacionar con los usuarios dentro del registro de usuarios configurado.

  • Dominio de servidor

    Este dominio se basa en la autenticación basada en certificados SSL.

Para obtener más información sobre seguridad de colectivo, consulte Seguridad de colectivos.

Réplicas configuradas y en espera

Las réplicas que se han añadido a un conjunto de réplicas configurado se están ejecutando (réplicas activas) o se han detenido (réplicas inactivas). Una réplica que se inicia y que nunca ha sido añadido a un conjunto de réplicas configurado, o se ha eliminado de un conjunto de réplicas configurado, se denomina réplica en espera.

Figura 2. Réplicas configuradas y en espera en un controlador colectivo
Un colectivo puede contener un conjunto de réplicas configurado que tiene réplicas en ejecución (activas) y réplicas detenidas (inactivas). Un colectivo también puede contener réplicas en espera, que son réplicas en ejecución que no se han añadido nunca a un conjunto de réplicas configurado o se han eliminado de un conjunto de réplicas configurado.

Resumen de términos de arquitectura de colectivo

colectivo
Conjunto de servidores de Liberty en un único dominio de gestión.
controlador colectivo
Servidor que tiene la característica collectiveController-1.0 habilitada.
miembro de colectivo
Servidor que tiene la característica collectiveMember-1.0 habilitada.
conjunto de réplicas
Conjunto de controladores colectivos. Para un funcionalidad óptima y una alta disponibilidad, un conjunto de réplicas debe tener al menos tres controladores.
puerto de réplica
Puerto dedicado en un controlador utilizado por el protocolo de réplica
conjunto de réplicas configurado
Unión de las réplicas activas y las réplicas inactivas.
réplicas activas
Réplicas iniciadas que se han añadido al conjunto de réplicas configurado.
réplicas inactivas
Réplicas detenidas que se han añadido al conjunto de réplicas configurado.
réplica en espera
Réplicas iniciadas que no se han añadido al conjunto de réplicas configurado o que se han eliminado del conjunto de réplicas configurado.

Icono que indica el tipo de tema Tema de concepto

Nombre de archivo: cwlp_collective_arch.html