Resistencia y recuperación ante desastres en Azure SignalR Service

La resistencia y la recuperación ante desastres son necesidades comunes de los sistemas en línea. Azure SignalR Service ya proporciona disponibilidad del 99,9 %, pero sigue siendo un servicio regional. Cuando hay una interrupción en toda la región, la instancia de servicio no conmuta por error a otra región porque siempre se ejecuta en una región.

Para la recuperación ante desastres regional, se recomiendan los dos enfoques siguientes:

• Habilite la replicación geográfica (manera sencilla). Esta característica controla automáticamente la conmutación por error regional. Cuando está habilitada, solo hay una instancia de Azure SignalR y no se introduce ningún cambio de código. Compruebe la replicación geográfica para obtener más información.
• Use varios puntos de conexión en el SDK de servicio. Nuestro SDK de servicio admite varias instancias del servicio SignalR y cambia automáticamente a otras instancias cuando algunas de ellas no están disponibles. Con esta característica, podrá recuperarse cuando se produzca un desastre, pero debe configurar la topología del sistema adecuada por su cuenta. En este documento aprenderá a hacerlo.

Arquitectura de alta disponibilidad para SignalR Service

Para garantizar la resistencia entre regiones del servicio SignalR, debe configurar varias instancias de servicio en distintas regiones. De manera que cuando una región esté inactiva, las demás se puedan usar como reserva. Cuando los servidores de aplicaciones se conectan a varias instancias de servicio, hay dos roles, principal y secundario. Primary es una instancia responsable de recibir tráfico en línea, mientras que la secundaria actúa como una instancia de reserva que es totalmente funcional. En nuestra implementación del SDK, negociar solo devuelve puntos de conexión principales, por lo que los clientes solo se conectan a los puntos de conexión principales en casos normales. Pero cuando la instancia principal está inactiva, negocia los puntos de conexión secundarios para que el cliente pueda seguir realizando conexiones. La instancia principal y el servidor de aplicaciones están conectados mediante conexiones de servidor normales, pero la instancia secundaria y el servidor de aplicaciones están conectados a través de una conexión débil, que es un tipo especial de conexión. Una característica distintiva de una conexión débil es que no puede aceptar el enrutamiento de conexión de cliente debido a la ubicación de la instancia secundaria en otra región. El enrutamiento de un cliente a otra región no es una opción óptima (aumenta la latencia).

Una instancia del servicio puede tener distintos roles cuando se conecta a varios servidores de aplicaciones. Una configuración típica para escenarios entre regiones es tener dos o más pares de instancias de SignalR Service y servidores de aplicaciones. En cada par, el servidor de aplicaciones y SignalR Service se encuentran en la misma región y este último se conecta al servidor de aplicaciones como rol principal. Entre los pares, el servidor de aplicaciones y SignalR Service también están conectados, pero este último se vuelve secundario al conectarse al servidor de otra región.

Con esta topología, todavía se puede entregar el mensaje de un servidor a todos los clientes, ya que todos los servidores de aplicaciones e instancias de servicio de SignalR están interconectados. Pero cuando un cliente está conectado, se enruta al servidor de aplicaciones de la misma región para lograr una latencia de red óptima.

En el diagrama siguiente se muestra esta topología:

Configurar varias instancias de servicio de SignalR

En los servidores de aplicaciones y Azure Functions se admiten varias instancias de servicio de SignalR.

Una vez que tenga el servicio de SignalR y los servidores de aplicaciones/Azure Functions creados en cada región, puede configurar los servidores de aplicaciones/Azure Functions para que se conecten a todas las instancias de servicio de SignalR.

Configurar en servidores de aplicaciones

Esto se puede hacer de dos maneras:

Mediante configuración

Ya debe saber cómo configurar la cadena de conexión de SignalR Service mediante variables de entorno o configuración de aplicaciones o web.cofig, mediante una entrada de configuración denominada Azure:SignalR:ConnectionString. Si tiene varios puntos de conexión, puede establecerlos en varias entradas de configuración, cada una de ellas con el siguiente formato:

Azure:SignalR:ConnectionString:<name>:<role>

En el Conectar ionString, <name> es el nombre del punto de conexión y <role> es su rol (principal o secundario). Name es opcional, pero resulta útil si desea personalizar aún más el comportamiento de enrutamiento entre varios puntos de conexión.

Mediante código

Si prefiere almacenar la cadena de conexión en alguna otra parte, también puede leerla en el código y usarla como parámetros al llamar a AddAzureSignalR() (en ASP.NET Core) o MapAzureSignalR() (en ASP.NET).

Este es el código de ejemplo:

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

Puede configurar varias instancias principales o secundarias. Si hay varias instancias principales o secundarias, negotiate devuelve un punto de conexión en el orden siguiente:

1. Si hay al menos una instancia principal en línea, devuelve una instancia en línea principal aleatoria.
2. Si todas las instancias principales están inactivas, devuelva una instancia en línea secundaria aleatoria.

Configurar en Azure Functions

Consulte este artículo.

Secuencia de conmutación por error y procedimiento recomendado

Ahora tiene la configuración de la topología de sistema correcta. Cada vez que una instancia del servicio SignalR está inactiva, el tráfico en línea se enruta a otras instancias. Esto es lo que sucede cuando una instancia principal está inactiva (y se recupera después de algún tiempo):

1. La instancia de servicio principal está inactiva, todas las conexiones de servidor de esta instancia se quitan.
2. Todos los servidores conectados a esta instancia lo marcan como sin conexión y negocian dejan de devolver este punto de conexión y comienzan a devolver el punto de conexión secundario.
3. Todas las conexiones de cliente de esta instancia también están cerradas, los clientes se vuelven a conectar. Dado que los servidores de aplicaciones ahora devuelven el punto de conexión secundario, los clientes se conectan a la instancia secundaria.
4. Ahora la instancia secundaria toma todo el tráfico en línea. Todos los mensajes del servidor a los clientes pueden entregarse, ya que la instancia secundaria está conectada a todos los servidores de aplicaciones. Pero los mensajes del cliente al servidor solo se enrutan al servidor de aplicaciones de la misma región.
5. Una vez recuperada y en línea la instancia principal, el servidor de aplicaciones restablecerá las conexiones a ella y la marcará como "en línea". Negotiate ahora devuelve el punto de conexión principal de nuevo para que los nuevos clientes se conecten de nuevo a principal. Pero los clientes existentes no quitan y se enrutan a la secundaria hasta que se desconectan.

A continuación, los diagramas muestran cómo se realiza la conmutación por error en SignalR Service:

Fig.1 Antes de la conmutación por error

Fig.2 Después de la conmutación por error

Fig.3 Breve tiempo después de la recuperación principal

Normalmente, solo el servidor de aplicaciones y SignalR Service principales tienen tráfico en línea (en azul). Después de la conmutación por error, el servidor de aplicaciones y SignalR Service secundarios también se activan. Cuando SignalR Service principal vuelve a estar en línea, los nuevos clientes se conectarán a él. Pero los clientes existentes se seguirán conectando a la instancia secundaria, por lo que ambas instancias tendrán tráfico. Una vez desconectados todos los clientes existentes, el sistema volverá a la normalidad (ilustración 1).

Hay dos patrones principales para implementar una arquitectura de alta disponibilidad entre regiones:

1. La primera de ellas consiste en tener un par de servidor de aplicaciones e instancia de servicio de SignalR con todo el tráfico en línea y otro par como copia de seguridad (lo que se denomina "activo/pasivo" en la ilustración 1).
2. El otro es tener dos (o más) pares de servidores de aplicaciones e instancias de servicio de SignalR y que cada uno tenga parte del tráfico en línea y sirva de copia de seguridad para los demás pares (lo que se denomina "activo/pasivo" en la ilustración 3).

SignalR Service admite ambos patrones, la principal diferencia es la manera de implementar los servidores de aplicaciones. Si los servidores de aplicaciones son activos/pasivos, SignalR Service también está activo/pasivo (ya que el servidor de aplicaciones principal solo devuelve su instancia principal de SignalR Service). Si los servidores de aplicaciones están activos o activos, SignalR Service también está activo/activo (ya que todos los servidores de aplicaciones devuelven sus propias instancias principales de SignalR, por lo que todos ellos pueden obtener tráfico).

Tenga en cuenta qué patrones decide usar, debe conectar cada instancia de SignalR Service a un servidor de aplicaciones como principal.

Además, debido a la naturaleza de la conexión de SignalR (se trata de una conexión larga), los clientes experimentan caídas de conexión cuando se produce un desastre y una conmutación por error. Debe controlar estos casos en el lado cliente para que sea transparente para los clientes finales. Por ejemplo, vuelva a realizar la conexión cuando se cierre.

Prueba de una conmutación por error

Siga los pasos para desencadenar la conmutación por error:

1. En la pestaña Redes del recurso principal del portal, deshabilite el acceso a la red pública. Si el recurso tiene habilitada la red privada, use reglas de control de acceso para denegar todo el tráfico.
2. Reinicie el recurso principal.

Pasos siguientes

En este artículo, ha aprendido a configurar la aplicación para lograr resistencia para SignalR Service. Para conocer más detalles acerca de la conexión cliente/servidor y el enrutamiento de conexión en SignalR Service, consulte este artículo para los aspectos internos de SignalR Service.

Para escenarios de escalado como el particionamiento que usa varias instancias juntas para controlar un gran número de conexiones, lea cómo escalar varias instancias.

Para más información sobre cómo configurar Azure Functions con varias instancias de servicio de SignalR, consulte compatibilidad con varias instancias de Azure SignalR Service en Azure Functions.