Resiliencia de Aplicaciones a través de Akka Cluster Sharding

Introducción

Este documento existe para comunicar cómo IPF applications usar Akka Cluster Sharding para la recuperación y la resiliencia. Esto no es un análisis profundo en Akka Cluster Se proporcionan fragmentos y referencias para una lectura adicional. Lo clave a tener en cuenta al revisar y comprender cómo IPF proporciona resiliencia y recuperación, es que IPF utiliza el Akka características y un IPF flow es meramente una entidad dentro de un sistema Actor.

Akka Cluster Sharding

Akka Cluster Sharding funciona permitiendo que una aplicación se escale a través de múltiples nodos (instancias de aplicación), distribuyendo entidades (flujos en IPF) entre varios nodos en un clúster, enviando mensajes a ellos a través de un ID único, pero sin tener que preocuparse por en qué nodo reside la entidad en el clúster. Este último punto es crucial para cómo Akka proporciona resiliencia y puede mover transparentemente la ubicación de una entidad a otro nodo en caso de fallo.

Definiciones

Entidad-para nuestra discusión, una entidad es el equivalente a una instancia de un IPF Flow(i.e. la instancia de un IPF flow procesando una transacción única particular).

Fragmento - Un shard es un grupo de entidades que serán gestionadas juntas.

Región de Shard - Actúa como mediador para los fragmentos y gestiona el enrutamiento de mensajes a la entidad correcta, ya sea a uno de sus fragmentos o a través de otra región de fragmentos en otros nodos.

Nodo - Entorno de ejecución para su IPF application(normalmente un pod dentro de un entorno en contenedores).

Persistencia-el almacenamiento de las entidades state registrando todos sus events.

akka shard

Puntos Clave

  • El sharding significa que los actores con un identificador, llamado entidades, pueden ser distribuidos automáticamente a través de múltiples nodos en el clúster.

  • Cada actor de entidad (IPF flow la instancia) se ejecuta solo en un lugar.

  • Los mensajes que deben ser procesados por una entidad pueden ser enviados a la entidad (IPF flow instancia) sin requerir que el remitente conozca la ubicación física del actor de destino.

  • La ubicación física de la entidad puede cambiar con el tiempo.

  • La persistencia se utiliza junto con el Cluster Sharding para recuperar la state de una entidad (IPF Flow) después de que haya sido movido.

  • Desde Akka persistence se basa en un principio de un solo escritor, donde solo un actor persistente está activo en cualquier lugar dentro del clúster.

  • El uso compartido de clústeres también ayuda con la escalabilidad para permitir la distribución de muchos actores con estado en más de una unidad de procesamiento (típicamente un pod).

Los siguientes escenarios hablan mucho sobre cómo Akka cluster ing está funcionando en IPF porque su funcionalidad principal bajo pines cómo se gestionan los flujos. Donde lea la palabra "entidad", intercámbiela por " IPF flow instancia".

Operación del Clúster BAU

Considere un despliegue típico de su aplicación de procesamiento de pagos IPF (una aplicación Springboot que envuelve el IPF flow/ s, ejecute dentro de un pod). En este ejemplo tenemos 3 nodos (3 instancias del pod).

bau cluster

Solo una instancia de una entidad se ejecuta en el clúster en un momento dado, pero los mensajes entrantes pueden llegar a diferentes nodos.

Así que, por ejemplo, cuando un mensaje llega a una Región de Shard pero la ubicación de esa entidad se encuentra en otra región en un nodo separado, el mensaje se enruta dentro de la Akka Cluster al fragmento correcto para ser procesado por la entidad única (IPF flow instancia). En el diagrama a continuación, las siguientes cosas están ocurriendo cuando se procesa un mensaje en un nodo específico.

  1. El nodo 2 recibe el mensaje que es para la entidad/flujo ID=6.

  2. La Región Shard (SR) en el Nodo 2 no tiene esa entidad dentro de ninguno de sus shards (la entidad ID=6 no está en funcionamiento en el Nodo 2).

  3. SR en el Nodo 2 busca la ubicación de la entidad y reenvía el mensaje a través del Akka Cluster al SR que se ejecuta en el Nodo 3

  4. El SR en el Nodo 3 conoce la ID de entidad=6 y reenvía el mensaje para su procesamiento por esa entidad.

shard coordination

El escenario real para esto desde una perspectiva de procesamiento de IPF es donde usted tiene múltiples nodos procesando desde el mismo Kafka temas.

  • Donde el IPF flow envía una solicitud a un dominio externo, el nodo que procesa la respuesta no está controlado en el Kafka nivel.

  • Cada nodo leerá las respuestas del mismo Kafka el tema, pero el nodo que lee la respuesta podría no haber sido el nodo que procesó la solicitud (y, por lo tanto, la ubicación de la entidad de flujo)

Esto es la Transparencia de Ubicación, y significa que para el procesamiento BAU el clúster maneja el enrutamiento a una ubicación física, y podemos simplemente referirnos a la entidad por su ID lógico. Así es como IPF funciona para enrutear los mensajes al correcto IPF flow instancia. Y esto es crucial no solo desde una perspectiva de BAU, sino también desde una perspectiva de resiliencia y escenarios de fallo, para hacer frente a la falla de nodos y restart.

Tenga en cuenta la introducción de un Coordinador de Shard. Este tiene una serie de responsabilidades y es crucial para permitir la transparencia de enrutamiento y ubicación. Los shards son gestionados por el Coordinador de Shard (SC) y este:

  • es un cluster singleton(solo hay 1 dentro de un Akka Cluster)

  • monitorea los nodos del sistema y la ubicación de cada fragmento

  • asegura que el sistema sepa dónde enviar mensajes para una entidad específica

  • decide qué fragmento reside en qué región de fragmentos

  • Está respaldado por Akka persistence– para reproducir events en caso de que el SC no permita que se reanude su state.

Escenario de Nodo Caído

Lo siguiente muestra lo que sucede en el Akka Cluster cuando un nodo falla o está restarted La funcionalidad y el comportamiento aquí aseguran que las entidades puedan reanudarse en otros nodos y que el procesamiento pueda continuar con normalidad, independientemente de la falla del nodo.

En este escenario, están ocurriendo dos cosas en las que parte de la infraestructura está caída, lo que hace que una Región de Fragmento (SR) no esté disponible.

  1. El nodo 2 recibe el mensaje que es para la entidad/flujo ID=6.

  2. La Región Shard (SR) en el Nodo 2 no tiene esa entidad dentro de ninguno de sus shards (la entidad ID=6 no está en funcionamiento en el Nodo 2).

  3. El SR que recibe el mensaje intenta enviarlo al SR que tiene la entidad (esto fue en el Nodo 3)

  4. Pero el SR en el Nodo 3 ahora no está disponible.

  5. El Coordinador de Shard interviene para mover el Shard a un SR diferente (en nuestro caso, el Nodo 1).

  6. SR en el Nodo 2 ahora reenvía el mensaje a través del Akka Cluster al SR que se ejecuta en el Nodo 1

  7. El SR en el Nodo 1 conoce la ID de entidad=6 (su Shard fue trasladado aquí) y reenvía el mensaje para su procesamiento por esa entidad.

node down

Las cosas más importantes a tener en cuenta en este escenario son que la ubicación del flujo en ejecución (entidad) es transparente, y es el Akka Cluster que proporciona el enrutamiento al fragmento correcto y, por ende, al nodo. Cada entidad se ejecuta en un solo lugar y, por lo tanto, esas entidades en ejecución pueden ser distribuidas y movidas por el clúster sin que ningún remitente tenga que conocer la ubicación/nodo del actor de destino. Las entidades son persistentes y, por lo tanto, pueden reanudarse en cualquier fragmento en cualquier nodo, ya que se reproducirá el events para reanudar el correcto state.

Particiones de Red / Resolución de Cerebro Dividido

Por defecto, implementamos el método predeterminado de resolución de división de cerebro de mantener la mayoría en IPF proporcionado por Akka, esto permite la mejor combinación de escalabilidad en un entorno de nube.

Estrategia Requisitos

keep-majority (predeterminado)

Número impar de nodos en total Akka Cluster

lease-majority

Debe ser un único Kubernetes clúster

keep-oldest

Podría llevar a la terminación del quórum más grande.

Si un cliente está operando en un entorno donde solo están disponibles dos Centros de Datos, y cada centro de datos tiene su propia aislada Kubernetes cluster, luego keep-oldest se ocupa de escenarios en los que un único DC (la mitad de los nodos) se ve particionado y utiliza el cluster singleton actuar en arbitraje para la salud del clúster.

Preguntas Comunes

P. ¿Cómo sabe la Región de Fragmentos (SR) qué entidades/instancias de flujo tiene?

El SR realiza un seguimiento de todos los shards y entidades que tiene. Esto significa que no necesita resolver la ubicación externamente (con el Coordinador de Shards) cada vez.

P. Si el fragmento está en otro SR, ¿cómo se envía el mensaje al SR correcto (y, por ende, al nodo)?

Si el fragmento se encuentra en otro SR, entonces los mensajes deben ser reenviados a ese SR en su lugar. El SR que recibe el mensaje debe resolver la ubicación del fragmento objetivo desde el clúster, y el Coordinador de Fragmentos (SC) es responsable de conocer la ubicación de todos los fragmentos y entidades en todo el clúster. Una vez que se resuelve la ubicación, los mensajes se entregan al fragmento objetivo.

P. Mientras el SR está resolviendo la ubicación de un fragmento, ¿qué sucede con los mensajes entrantes para esa entidad?

Mientras se resuelve la ubicación del fragmento, los mensajes entrantes se almacenan en un búfer y se entregarán más tarde una vez que se conozca la ubicación del fragmento. Cualquier mensaje subsiguiente que se resuelva a ese fragmento 'remoto' puede ser entregado a la destino objetivo de inmediato sin involucrar al coordinador del fragmento para determinar la ubicación.

Q. ¿Cómo aseguramos que no state¿Se pierde al mover entidades/flujos entre SR?

Utilizamos Akka persistence para almacenar el events, y permita el state de un actor que debe ser recuperado mediante la reproducción events sobre entidad/flujo restart.

el coordinador de fragmentos también está respaldado por Akka persistence– para reproducir events en caso de no permitir que reanude su state.
Q. Si un nodo envía una solicitud a un dominio externo (por ejemplo, Sanciones) pero su respuesta se lee desde Kafka por un nodo diferente, ¿cómo obtiene el flujo correcto esa respuesta?

Este es el escenario descrito anteriormente en "Operación del Clúster BAU" y es la operación normal, ya que deseamos la Transparencia de Ubicación para la entidad (lo que significa que puede ser trasladada o recuperada según sea necesario).

P. Si un nodo falla, ¿qué sucede con las entidades/flujos que se procesan en la región de fragmento de ese nodo?

Este es el escenario descrito anteriormente en "Escenario de caída de nodo" y abarca cómo se mueven los fragmentos con sus entidades para ejecutarse dentro de otra región de fragmentos.

P. ¿Qué es el reequilibrio de fragmentos?

Este es el proceso mediante el cual el coordinador de fragmentos facilita el reequilibrio de fragmentos, donde se añaden nuevos miembros al clúster. Así, las entidades pueden ser trasladadas de un nodo a otro. El proceso de reequilibrio hará que las regiones de fragmentos almacenen mensajes entrantes para un fragmento y el coordinador no responderá a las solicitudes de ubicación hasta que se complete el reequilibrio. Por lo tanto, esos mensajes de entidad se almacenan hasta que el coordinador responda a las solicitudes de ubicación, momento en el cual se puede reanudar el enrutamiento de esos mensajes almacenados.

P. ¿Qué sucede si el coordinador de fragmentos falla?

El state del coordinador de fragmentos es persistente y, por lo tanto, puede ser recuperado. Si el coordinador falla o el nodo se vuelve inalcanzable, un nuevo coordinador de fragmentos singleton tomará el control y state se recupera del almacenamiento persistente. Durante este tiempo, cualquier ubicación conocida sigue estando disponible para las regiones de fragmentos, pero cualquier solicitud de ubicaciones se almacena en búfer hasta que el coordinador vuelva a estar en línea.

Referencia

Para más información sobre los conceptos de compartición de clúster, consulte aquí.

Para una inmersión más completa en los detalles técnicos de Akka Cluster Sharding, por favor, lea.https://doc.akka.io/docs/akka/current/typed/cluster-sharding.html[aquí].

Para un análisis técnico sobre cómo Akka Cluster ing funciona (con ejemplos de código) esto vale la pena verlo, parte 1 aquí.

Para obtener detalles sobre la Resolución de Cerebro Dividido, consulte aquí.