Replicación geográfica en Azure SignalR

Las empresas que buscan presencia local o requieren un sistema sólido de conmutación por error suelen optar por implementar servicios en varias regiones de Azure. Con la integración de la replicación geográfica en Azure SignalR, la administración de escenarios de varias regiones es ahora mucho más sencilla.

Ventajas de la replicación geográfica

• Más resistente a las interrupciones regionales: si se produce una interrupción regional, el DNS de Azure SignalR se resolverá en réplicas en buen estado de otras regiones.
• Comunicación entre regiones: las distintas réplicas pueden comunicarse entre sí como si fueran la misma instancia.
• Velocidad de red mejorada: los clientes dispersos geográficamente se conectarán a la réplica más cercana. Estas réplicas se comunican a través de la red troncal global de Azure, que garantiza redes rápidas y estables.
• Configuraciones compartidas: todas las réplicas conservan la configuración del recurso principal de Azure SignalR Service.

Requisitos previos

• Azure SignalR Service en el nivel Premium.

Ejemplo de caso de uso

Contoso es una empresa de redes sociales cuya base de clientes se encuentra en Estados Unidos y Canadá. Para atender a esos clientes y permitirles comunicarse entre sí, Contoso ejecuta sus servicios en la región Centro de EE. UU. Azure SignalR Service se usa para controlar las conexiones de usuario y facilitar la comunicación entre los usuarios. Los usuarios finales de Contoso son principalmente usuarios de teléfonos. Debido a las largas distancias geográficas, los usuarios finales de Canadá pueden experimentar una latencia alta y una calidad de red deficiente.

Antes de la llegada de la característica de replicación geográfica, Contoso podía configurar otra instancia de Azure SignalR Service en la región Centro de Canadá para atender a sus usuarios canadienses. Al configurar una instancia de Azure SignalR Service más cercana geográficamente, los usuarios finales tienen ahora una mejor calidad de red y una menor latencia.

Sin embargo, la administración de varias instancias de Azure SignalR Service plantea algunos desafíos:

1. Se necesitaría un mecanismo de comunicación entre regiones para habilitar la conversación entre los usuarios de Canadá y EE. UU.
2. El equipo de desarrollo tendría que administrar dos instancias de Azure SignalR Service independientes, cada una con un dominio y una cadena de conexión distintos.
3. Si se produjera una interrupción regional, se debería cambiar el tráfico a otra región.

Aprovechamiento de la replicación geográfica

Con la nueva característica de replicación geográfica, Contoso ahora puede establecer una réplica en la región Centro de Canadá, con lo que se solventarían eficazmente los obstáculos mencionados.

Creación de una réplica de SignalR

Portal

Para crear una réplica, vaya a la hoja Réplicas de SignalR en Azure Portal y haga clic en Agregar. Se habilitará automáticamente tras la creación.

Después de crear la réplica, podrá verla o editarla en el portal haciendo clic en el nombre de la réplica.

Bicep

Use Visual Studio Code o su editor favorito para crear un archivo con el siguiente contenido y asígnele el nombre main.bicep:

@description('The name for your SignalR service')
param primaryName string = 'contoso'

@description('The region in which to create your SignalR service')
param primaryLocation string = 'eastus'

@description('Unit count of your SignalR service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/signalr@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your SignalR replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the SignalR replica')
param replicaLocation string = 'westus'

@description('Unit count of the SignalR replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/signalr/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

Implementación de archivo Bicep mediante la CLI de Azure

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

Nota:

• El recuento de réplicas está limitado actualmente a un máximo de 8 por recurso principal.

Precios y unidad de recursos

Cada réplica tiene sus propias unit y autoscale settings.

La réplica es una característica de nivel Premium de Azure SignalR Service. Cada réplica se factura por separado según su unidad y su tráfico saliente. La cuota de mensajes gratis también se calcula por separado.

En el ejemplo anterior, Contoso agregó una réplica en la región Centro de Canadá. Contoso pagaría la réplica de la región Centro de Canadá según su unidad y cuota de mensajes con el precio Premium.

Habrá tarifas de salida para el tráfico saliente entre regiones. Si un mensaje se transfiere entre réplicas y se envía correctamente a un cliente o servidor después de la transferencia, se facturará como un mensaje saliente.

Eliminación de una réplica

Después de crear una réplica de Azure SignalR Service, puede eliminarla en cualquier momento cuando ya no sea necesaria.

Para eliminar una réplica en Azure Portal:

1. Vaya a la instancia de Azure SignalR Service y seleccione la hoja Réplicas. Haga clic en la réplica que quiera eliminar.
2. Haga clic en el botón Eliminar de la hoja de información general de la réplica.

Cómo funciona la réplica de SignalR

En el diagrama siguiente se proporciona una breve ilustración de la funcionalidad de las réplicas de SignalR:

1. El cliente negocia con el servidor de aplicaciones y recibe un redireccionamiento a Azure SignalR Service. A continuación, resuelve el nombre de dominio completo (FQDN) del servicio SignalR: contoso.service.signalr.net. Este FQDN apunta a Traffic Manager, que devuelve el nombre canónico (CNAME) de la instancia regional de SignalR más cercana.
2. Con este CNAME, el cliente establece una conexión con la instancia regional (réplica).
3. Las dos réplicas sincronizarán los datos entre sí. Si es necesario, los mensajes enviados a una réplica se transferirán a otras réplicas.
4. En caso de que una réplica produzca un error en la comprobación de estado realizada por Traffic Manager (TM), TM excluirá el punto de conexión de la instancia con error del proceso de resolución de dominios. Para obtener más información, consulte a continuación Resistencia y recuperación ante desastres

Nota:

• En el plano de datos, un recurso de Azure SignalR principal funciona de forma idéntica a sus réplicas.

Resistencia y recuperación ante desastres

Azure SignalR Service utiliza un administrador de tráfico para las comprobaciones de estado y la resolución de DNS hacia sus réplicas. En circunstancias normales, cuando todas las réplicas funcionan correctamente, se dirigirá a los clientes a la réplica más cercana. Por ejemplo:

• A los clientes cercanos a eastus se les dirigirá a la réplica ubicada en eastus.
• Del mismo modo, a los clientes cercanos a westus se les dirigirá a la réplica ubicada en westus.

En caso de una interrupción regional en eastus (se muestra a continuación), el administrador de tráfico detectará el error de comprobación de estado de esa región. A continuación, el DNS de esta réplica con errores se excluirá de los resultados de la resolución de DNS del administrador de tráfico. Después del tiempo de período de vida de DNS (TTL), que está establecido en 90 segundos, se redirigirá a los clientes de eastus para conectarlos con la réplica de westus.

Una vez que se resuelva el problema en eastus y la región vuelve a estar en línea, la comprobación de estado se realizará correctamente. A continuación, se dirigirá a los clientes de eastus de vuelta a la réplica de su región. Esta transición es fluida, ya que los clientes conectados no se verán afectados hasta que se cierren las conexiones existentes.

Este proceso de conmutación por error y recuperación es automático y no requiere intervención manual.

En el caso de las conexiones de servidor, la conmutación por error y la recuperación funcionan de la misma manera que para las conexiones de cliente.

Nota:

• Este mecanismo de conmutación por error es para Azure SignalR Service. Las interrupciones regionales del servidor de aplicaciones están fuera del ámbito de este documento.

Deshabilitación o habilitación del punto de conexión de la réplica

Al configurar una réplica, tiene la opción de habilitar o deshabilitar su punto de conexión. Si está deshabilitado, la resolución de DNS principal de FQDN no incluirá la réplica y, por lo tanto, no se dirigirá el tráfico a ella.

También puede habilitar o deshabilitar el punto de conexión una vez creado. En la hoja de réplicas del recurso principal, haga clic en el botón de puntos suspensivos situado en el lado derecho de la réplica y elija Habilitar punto de conexión o Deshabilitar punto de conexión:

Antes de eliminar una replicación, considere la posibilidad de deshabilitar primero su punto de conexión. Con el tiempo, las conexiones existentes se desconectarán. Al no llegar nuevas conexiones, la replicación se queda inactiva finalmente. Esto garantiza un proceso de eliminación sin problemas.

Esta característica también es útil para solucionar problemas regionales.

Nota:

• Debido a la caché de DNS, la actualización de DNS puede tardar varios minutos en surtir efecto.
• Las conexiones existentes no se ven afectadas hasta que se desconectan.

Impacto en el rendimiento después de agregar réplicas

Una vez habilitadas las réplicas, los clientes se distribuirán naturalmente en función de sus ubicaciones geográficas. Si bien SignalR es responsable de sincronizar los datos entre las réplicas, le alegrará saber que la sobrecarga correspondiente en la carga del servidor es mínima en la mayoría de los casos de uso habituales.

En concreto, si la aplicación suele transmitir a grupos grandes (tamaño > 10) o a una única conexión, apenas se notarán los efectos de la sincronización en el rendimiento. Si envía mensajes a grupos pequeños (tamaño < 10) o a usuarios individuales, es posible que observe una sobrecarga de sincronización ligeramente superior.

Para garantizar una administración de conmutación por error eficaz, se recomienda establecer el tamaño de unidad de cada réplica para controlar todo el tráfico. Como alternativa, puede habilitar laescalabilidad automática para administrarlo.

Para obtener más información sobre la evaluación del rendimiento, consulte Rendimiento.

Configuraciones no heredadas y heredadas

Las réplicas heredan la mayoría de las configuraciones del recurso primario; sin embargo, algunas configuraciones deben establecerse directamente en las réplicas. A continuación encontrará la lista de dichas configuraciones:

1. SKU: cada réplica tiene su propio nombre de SKU y tamaño de unidad. Las reglas de escalabilidad automática para las réplicas deben configurarse por separado en función de sus métricas individuales.
2. Puntos de conexión privados compartidos: aunque los puntos de conexión privados compartidos se replican automáticamente en las réplicas, se requieren aprobaciones independientes en los recursos de vínculo privado de destino. Para agregar o quitar puntos de conexión privados compartidos, adminístrelos en el recurso principal. No habilite la réplica hasta que se haya aprobado su punto de conexión privado compartido.
3. Configuración de destino de registros. Si no está configurado en las réplicas, solo se transferirán los registros del recurso principal.
4. Alertas.

Todas las demás configuraciones se heredan del recurso principal. Por ejemplo, claves de acceso, identidad, firewall de aplicaciones, dominios personalizados, puntos de conexión privados y control de acceso.