Replicación geográfica en Azure Web PubSub

Las aplicaciones críticas a menudo necesitan tener un sistema de conmutación por error sólido y servir a los usuarios más cerca de dónde están. Antes del lanzamiento de la característica de replicación geográfica, los desarrolladores necesitaban implementar varios recursos de Web PubSub y escribir código personalizado para orquestar la comunicación entre recursos. Ahora, con la configuración rápida a través de Azure Portal, puede habilitar fácilmente esta característica.

Ventajas de la replicación geográfica

• Más resistente a la interrupción regional: Si se produce una interrupción regional, los clientes se enrutarán automáticamente a una réplica correcta.
• Comunicación entre regiones: Los desarrolladores usan un recurso habilitado para replicación geográfica como de costumbre, aunque haya más de un recurso en segundo plano. El servicio controla la comunicación entre réplicas.
• 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.
• Administrabilidad. Todas las réplicas comparten la configuración del recurso principal de Web PubSub.

Requisitos previos

• Un recurso de Web PubSub en nivel Premium.

Ejemplo de caso de uso

Contoso, una empresa de redes sociales

Contoso es una empresa de redes sociales cuya base de clientes se encuentra en Estados Unidos y Canadá. Contoso proporciona una aplicación móvil y web a sus usuarios para que puedan conectarse entre sí. La aplicación de Contoso se implementa en el Centro de EE. UU. Como parte de la arquitectura de Contoso, Web PubSub se usa para establecer conexiones WebSocket persistentes entre las aplicaciones cliente y el servidor de aplicaciones. A Contoso le gusta poder descargar la administración de conexiones de WebSocket a Web PubSub, pero no le gusta leer informes de usuarios en Canadá experimentando una mayor latencia. Además, el equipo de desarrollo de Contoso quiere asegurar la aplicación contra la interrupción regional para que los usuarios puedan acceder a la aplicación sin interrupciones.

Contoso podría configurar otro recurso de Web PubSub en el Centro de Canadá, que está geográficamente más cerca de sus usuarios en Canadá. Sin embargo, la administración de varios recursos de Web PubSub conlleva algunos desafíos:

1. Sería necesario implantar un mecanismo de comunicación interregional para que los usuarios de Canadá y EE.UU. puedan interactuar entre sí.
2. El equipo de desarrollo tendría que administrar dos recursos independientes de Web PubSub, cada uno con un dominio y una cadena de conexión distintos.
3. Si se produce una interrupción regional, el tráfico debe dirigirse a un recurso disponible.

Todo lo anterior resta recursos de ingeniería para centrarse en la innovación del producto.

Aprovechamiento de la característica de replicación geográfica

Con la característica de replicación geográfica, Contoso ahora puede establecer una réplica en el Centro de Canadá, superando eficazmente los desafíos mencionados anteriormente. El equipo de desarrolladores se alegra al comprobar que no es necesario realizar ningún cambio en el código. Es tan fácil como hacer clic en unos pocos botones en Azure Portal. El equipo de desarrolladores también está encantado de compartir con las partes interesadas, dado que Contoso planea entrar en el mercado europeo, simplemente necesitan agregar otra réplica en Europa.

Habilitación de la replicación geográfica en un recurso de Web PubSub

Portal

Para crear una réplica en una región de Azure, vaya al recurso Web PubSub y busque la hoja Réplicas en Azure Portal y haga clic en Agregar para crear una réplica.

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 Web PubSub service')
param primaryName string = 'contoso'

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

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

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

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

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

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

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

resource replica 'Microsoft.SignalRService/webpubsub/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

CLI

Actualice la extensión webpubsub a la versión más reciente y, a continuación, ejecute:

az webpubsub replica create --sku Premium_P1 -l eastus --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

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.

Réplica es una característica de nivel Premium del servicio Azure Web PubSub. 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 para un recurso de Web PubSub, puede eliminarla en cualquier momento si ya no es necesaria.

Para eliminar una réplica en Azure Portal:

1. Vaya al recurso de Web PubSub 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.

Para eliminar una réplica mediante la CLI de Azure:

 az webpubsub replica delete --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Comprender cómo funciona la característica de replicación geográfica

1. El cliente resuelve el Nombre de dominio completo (FQDN) contoso.webpubsub.azure.com del servicio Web PubSub. Este FQDN apunta a un Traffic Manager, que devuelve el nombre canónico (CNAME) de la instancia de Web PubSub regional más cercana.
2. Con este CNAME, el cliente establece una conexión websocket a 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 de los resultados de la 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 Web PubSub principal funciona de forma idéntica a sus réplicas

---

Resistencia y recuperación ante desastres

El servicio Azure Web PubSub utiliza un administrador de tráfico para las comprobaciones de estado y la resolución 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.

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é 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 habilitar la característica de replicación geográfica

Una vez habilitadas las réplicas, los clientes se distribuirán naturalmente en función de sus ubicaciones geográficas. Aunque Web PubSub asume la responsabilidad de sincronizar los datos entre estas réplicas, se complacerá en saber que la sobrecarga asociada en Carga del servidor es mínima para los casos de uso más comunes.

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 va a enviar grupos pequeños (tamaño < 10), es posible que observe un poco más de sobrecarga de sincronización.

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 principal; sin embargo, algunas opciones deben configurarse directamente en las réplicas. A continuación se muestra la lista de esas configuraciones:

1. SKU: cada réplica tiene su propio nombre de SKU y tamaño de unidad. Las reglas de escalado automático para las réplicas deben configurarse por separado en función de sus métricas individuales.
2. Puntos de conexión privados compartidos: mientras que los puntos de conexión privados compartidos se replican automáticamente en 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 habilitar la réplica hasta que se haya aprobado su punto de conexión privado compartido.
3. Configuración de destino del registro. 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.