Gossip y Detección de fallos en Apache Cassandra

Para admitir la descentralización y la tolerancia de partición, Cassandra usa un protocolo de Gossip que permite a cada nodo realizar un seguimiento de la información de estado sobre los otros nodos en el clúster. El gossiper se ejecuta cada segundo en un temporizador.

Los protocolos de Gossip (a veces llamados "protocolos epidémicos") generalmente asumen una red defectuosa, se emplean comúnmente en sistemas de redes muy grandes y descentralizados, y se usan a menudo como un mecanismo automático para la replicación en bases de datos distribuidas.

Toman su nombre del concepto de chisme humano, una forma de comunicación en la que los compañeros pueden elegir con quién desean intercambiar información y no solo intercambian información de ellos mismos sino tambien de otros compañeros, lo que permite disminuir el trafico de la red, ya que no todos se comunican con todos.

El protocolo de Gossip en Cassandra se implementa principalmente mediante la clase org.apache.cassandra.gms.Gossiper, que es responsable de administrar los chismes para el nodo local. Cuando se inicia un nodo de servidor, se registra con el gossiper para recibir información del estado del punto final.

Debido a que los Gossip de Cassandra se usan para la detección de fallas, la clase Gossiper mantiene una lista de nodos que están vivos y muertos.

Así es como funciona el Gossiper:

1. Una vez por segundo, el Gossiper elegirá un nodo aleatorio en el clúster e iniciará una sesión de chismes con él. Cada ronda de chismes requiere tres mensajes.
2. El iniciador de chismes envía a su amigo elegido un GossipDigestSynMessage.
3. Cuando el amigo recibe este mensaje, devuelve un GossipDigestAckMessage.
4. Cuando el iniciador recibe el mensaje de acuse de recibo del amigo, le envía un mensaje de GossipDigestAck2 para que complete la ronda de chismes.

Cuando el Gossiperer determina que otro punto final está muerto, "condena" ese punto final al marcarlo como muerto en su lista local y registrar ese hecho.

Cassandra tiene un soporte robusto para la detección de fallas, como lo especifica un algoritmo popular para la computación distribuida llamada Phi Accrual Failure Detection. Esta forma de detección de fallas se originó en el Instituto Avanzado de Ciencia y Tecnología en Japón en 2004.

La detección del fracaso acumulado se basa en dos ideas principales. La primera idea general es que la detección de fallas debe ser flexible, lo que se logra al desacoplarla de la aplicación que se está monitoreando. La segunda y más novedosa idea desafía la noción de detectores de falla tradicionales, que se implementan mediante simples "latidos" y deciden si un nodo está muerto o no, según si se recibe un latido o no. Pero la detección de fallos acumulados decide que este enfoque es ingenuo, y encuentra un lugar entre los extremos de muertos y vivos, un nivel de sospecha.

Por lo tanto, el sistema de monitoreo de fallas genera un nivel continuo de "sospecha" con respecto a la confianza de que un nodo ha fallado. Esto es deseable porque puede tener en cuenta las fluctuaciones en el entorno de red. Por ejemplo, solo porque una conexión quede atrapada no significa necesariamente que todo el nodo esté muerto.

Por lo tanto, la sospecha ofrece una indicación más fluida y proactiva de la posibilidad de falla más débil o más fuerte basada en la interpretación (el muestreo de los latidos), en lugar de una simple evaluación binaria.

La detección de fallos se implementa en Cassandra mediante la clase org.apache.cassandra.gms.FailureDetector, que implementa la interfaz org.apache.cassandra.gms.IFailureDetector. Juntos, permiten operaciones que incluyen:

• isAlive (InetAddress) : Lo que el detector informará sobre la vida de un nodo dado.
• interpret (InetAddress): Utilizado por el Gossiper para ayudarlo a decidir si un nodo está vivo o no basado en nivel de sospecha alcanzado mediante el cálculo de Phi.
• report (InetAddress) : Cuando un nodo recibe un latido, invoca este método.