Arquitectura cotilla

Arquitectura cotilla es un framework desarrollado por Ladin et al. [1992] para la implementación de servicios de alta disponibilidad. El nombre viene dado por el hecho de que los distintos gestores de réplicas “cotillean” (intercambian mensajes periódicamente) para informar al resto de las actualizaciones que han recibido de los clientes.​​​

Un servicio cotilla dispone de dos tipos de operaciones:

• Queries o consultas: Operaciones de sólo lectura.
• Updates o actualizaciones: Operaciones de sólo escritura.

Ilustración 1: Operaciones de consulta y actualización en un servicio cotilla

En general, el sistema tiene que garantizar:

• Cada cliente obtiene un servicio consistente a lo largo del tiempo: Los gestores de réplicas únicamente proporcionan como respuesta a una consulta aquellos datos que reflejan al menos las actualizaciones que el cliente ya conocía. Esto tiene que cumplirse incluso en los casos en los que el cliente se haya comunicado previamente con algún otro gestor que se encontrase más actualizado que el actual y, por tanto, este gestor no conozca dichas actualizaciones.
• Consistencia relajada entre réplicas: Con el tiempo, todos los gestores reciben todas las actualizaciones y las aplican con garantía de ordenación, de modo que las réplicas sean suficientemente similares para poder cumplir las necesidades de la aplicación. Por tanto, se suele utilizar un grado de consistencia más débil que puede suponer que dos clientes vean réplicas distintas, aunque incluyan el mismo conjunto de actualizaciones o que un cliente observe datos antiguos.

Fases

Es importante destacar que los frontales envían la petición de los clientes a un gestor de su elección, siempre y cuando éste esté disponible y tenga tiempos de respuesta razonables. En este proceso se distinguen las siguientes fases:

1. Petición: el frontal normalmente manda una petición a un mismo gestor, pero puede ocurrir que dicho gestor falle, sea inalcanzable o simplemente tenga mucha carga, en cuyo caso lo intentará con uno diferente.
   • Petición pregunta: el cliente (y frontal) se quedan bloqueados
   • Petición actualización: el cliente continúa tan pronto como la petición pasa al frontal, que propaga la operación en segundo plano.
2. Respuesta a actualización: En el caso de que la petición mandada sea una actualización, el gestor responde tan pronto como la recibe.
3. Coordinación: el gestor no procesa una petición hasta que se cumplan todas las restricciones de orden requeridas. Esto puede conllevar el recibir actualizaciones por parte de otros gestores en forma de mensajes de “cotilleo”.
4. Ejecución: el gestor ejecuta la petición.
5. Respuesta a consulta: En el caso de que la petición sea una consulta, es en este momento cuando el gestor responde.
6. Acuerdo: los gestores se actualizan entre ellos con mensajes de ‘cotilleo’, que contienen las actualizaciones más recientes que hayan recibido. Dichos mensajes se enviarán de manera ocasional, por ejemplo, cuando se hayan recogido varias actualizaciones o cuando un gestor se dé cuenta de que le falta alguna actualización que necesita para procesar una determinada petición.

Marcas temporales

Ilustración 2: Los frontales propagan sus marcas temporales cuando los clientes se comunican de manera directa

Como ya sabemos, en la arquitectura cotilla (gossip) los front-end (FE) envían "queries" y "update" a un replica manager (RM) seleccionado, además garantiza que cada cliente obtiene un servicio con integridad en el tiempo y entre las réplicas.

Para la resolución de consistencia, conflictos de versiones y propagación de estados u operaciones entre réplicas, cuando se produce una partición en el sistema, esta arquitectura utiliza los relojes vectoriales (vectores de marcas de tiempo). El proceso que sigue para la detección y resolución de conflictos es:

• Un front-end envía una solicitud de actualización a uno o más replica managers
• Cada solicitud de actualización contiene una especificación de la actualización, una marca de tiempo y un identificador único generado por el front-end.
• Finalmente, cuando un replica manager recibe una solicitud de actualización comprueba que esa solicitud no haya sido ya procesada mirando el identificador de la operación.

Un servicio basado en la arquitectura cotilla mejora la escalabilidad convirtiendo a la mayor parte de las réplicas en réplicas de solo lectura, sobre todo cuando el ratio de actualizaciones/lectura es pequeño. En dichas circunstancias las réplicas de solo lectura deben estar situadas cerca de los grupos de clientes y las actualizaciones deben ser recibidas por un grupo relativamente pequeño replica managers. Bajo estas circunstancias el trafico se reduce ya que las réplicas de solo lecuta no propagan mensajes "gossip" y los vectores de tiempo solo necesitan contener entradas para las réplicas actualizadas.

Mensajes usados

Ilustración 1: Operaciones de consulta y actualización

Para explicar de manera más detallada como funciona todo este sistema, también se pueden considerar las marcas temporales y estructuras de datos que los gestores de réplicas y frontales poseen para mantener las garantías de ordenación de actualización, utilizándose para explicar cómo los gestores procesan las consultas y actualizaciones:

Cada frontal tiene un vector de marcas temporales con la última versión de los datos a la que accedió (prev). El frontal adjunta prev, que contiene una entrada por cada gestor, a cada mensaje de petición a un gestor, junto con el tipo de petición (update o query).

• Si es una actualización (update), el gestor responde al frontal inmediatamente, aunque se encargará de asegurarse de tener una versión adecuada antes de efectuar la actualización.

• En caso de consulta (query), debe asegurarse de que tiene una versión más actualizada que prev (no necesariamente la más actualizada en el sistema) antes de contestar.

En ambos casos, para actualizar sus versiones, el gestor intercambia mensajes de cotilleo (gossip) con otros gestores. Cuando un gestor devuelve un valor como resultado de una consulta, proporciona a su vez un nuevo vector de marcas temporales (new), debido a que es posible que las réplicas hayan sido actualizadas desde la última operación. De manera similar, una actualización también proporciona un nuevo vector (Update ID) único a la actualización. Cada marca temporal que se recibe se fusiona con la anterior para registrar la versión de los datos replicados observados por el cliente. Los clientes intercambian información accediendo al mismo servicio cotilla y comunicándose directamente entre sí.

En conclusión, con este sistema se consigue una alta disponibilidad al responder al frontal lo más rápido posible y posteriormente propagar los cambios al resto de réplicas. No obstante, la necesidad de varias estructuras de datos, y de un tráfico importante de mensajes para mantener a los gestores de réplicas actualizados conlleva que surjan problemas de escalabilidad.

Referencias

• Datos: Q97171340