Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus
Las aplicaciones esenciales deben funcionar de manera continua, incluso si se producen interrupciones imprevistas o desastres. En este artículo se describen técnicas que puede usar para proteger las aplicaciones de Service Bus ante un posible desastre o una interrupción del servicio.
Se define la interrupción como la falta temporal de disponibilidad de Azure Service Bus. La interrupción puede afectar a algunos componentes de Service Bus, como a un almacén de mensajería, o incluso a todo el centro de datos. Una vez corregido el problema, Service Bus vuelva a estar disponible. Normalmente, una interrupción no provoca la pérdida de mensajes ni otros datos. Un ejemplo de error de componente es la falta de disponibilidad de un determinado almacén de mensajería. Un ejemplo de interrupción de todo el centro de datos es un error de alimentación del centro de datos o un conmutador de red defectuoso en él. Una interrupción puede durar desde unos pocos minutos hasta varios días.
Un desastre se define como la pérdida permanente de una unidad de escalado de Service Bus o un centro de datos. EL centro de datos podría volver a estar disponible o no. Normalmente, un desastre provoca la pérdida de algunos o todos los mensajes u otros datos. Algunos ejemplos de desastres son los incendios, las inundaciones o los terremotos.
Protección contra interrupciones y desastres: nivel Premium
Los conceptos de alta disponibilidad y recuperación ante desastres se han integrado en el nivel Premium de Azure Service Bus, ambos en la misma región (mediante zonas de disponibilidad) o en regiones diferentes (mediante la recuperación ante desastres geográfica).
Recuperación ante desastres geográfica
El nivel Premium de Service Bus admite la recuperación ante desastres geográfica en el nivel del espacio de nombres. Para más información, consulte Recuperación ante desastres geográfica de Azure Service Bus. La característica de recuperación ante desastres, disponible solo para la SKU premium, implementa la recuperación ante desastres de metadatos y depende de espacios de nombres principales y secundarios. Con la recuperación ante desastres geográfica, solo los metadatos de las entidades se replican entre los espacios de nombres principal y secundario.
Zonas de disponibilidad
El nivel Premium de Service Bus es compatible con zonas de disponibilidad, lo que proporciona ubicaciones con aislamiento de errores dentro de la misma región de Azure. Service Bus administra tres copias del almacén de mensajería (una principal y dos secundarias). Service Bus mantiene las tres copias sincronizadas para las operaciones de datos y administración. Si se produce un error en la copia principal, una de las copias secundarias se promueve a principal sin tiempo de inactividad perceptible. Si las aplicaciones experimentan desconexiones transitorias de Service Bus, la lógica de reintento del SDK vuelve a conectar automáticamente con Service Bus.
Al utilizar zonas de disponibilidad, tanto los metadatos como los datos (mensajes) se replican en los centros de datos de la zona de disponibilidad.
Nota
La compatibilidad de zonas de disponibilidad con el nivel premium solo está disponible en aquellas regiones de Azure en las que hay zonas de disponibilidad.
Al crear un espacio de nombres de nivel Premium a través del portal, la compatibilidad con zonas de disponibilidad (si está disponible en la región seleccionada) se habilitará automáticamente para el espacio de nombres. Al crear un espacio de nombres de nivel Premium a través de otros mecanismos, como las plantillas de Azure Resource Manager/Bicep, la CLI o PowerShell, la propiedad zoneRedundant deberá establecerse explícitamente en true para habilitar las zonas de disponibilidad (si están disponibles en la región seleccionada). No hay ningún coste adicional al usar esta característica y no se puede deshabilitar ni habilitar tras la creación del espacio de nombres.
Protección contra interrupciones y desastres: nivel estándar
Para lograr resistencia frente a interrupciones del centro de datos con el plan de tarifa de mensajería estándar, puede usar la replicación activa o pasiva. Para cada enfoque, si una cola o un tema determinados deben permanecer accesibles en el caso de una interrupción del centro de datos, puede crear la entidad en ambos espacios de nombres. Ambas entidades pueden tener el mismo nombre. Por ejemplo, se puede tener acceso a una cola principal en contosoPrimary.servicebus.windows.net/myQueue, mientras que se puede tener acceso a su equivalente secundario en contosoSecondary.servicebus.windows.net/myQueue.
Nota
La configuración de replicación activa y replicación pasiva son soluciones de uso general, no características específicas de Service Bus. La lógica de replicación (el envío a 2 espacios de nombres distintos) se encuentra en las aplicaciones del remitente y el receptor debe tener una lógica personalizada para la detección de duplicados.
Si la aplicación no requiere comunicación permanente entre remitente y receptor, esta puede implementar una cola del lado cliente duradera para evitar la pérdida de mensajes y proteger al remitente ante los errores transitorios de Service Bus.
Replicación activa
La replicación activa usa entidades en ambos espacios de nombres para cada operación. Cualquier cliente que envíe un mensaje envía dos copias de él. La primera copia se envía a la entidad principal (por ejemplo, contosoPrimary.servicebus.windows.net/sales), y la segunda copia del mensaje se envía a la entidad secundaria (por ejemplo, contosoSecondary.servicebus.windows.net/sales).
Un cliente recibe mensajes de ambas colas. El receptor procesa la primera copia de un mensaje y se suprime la segunda copia. Para suprimir mensajes duplicados, el remitente debe etiquetar cada mensaje con un identificador único. Ambas copias del mensaje deben estar etiquetadas con el mismo identificador. Puede usar las propiedades ServiceBusMessage.MessageId o ServiceBusMessage.Subject o una propiedad personalizada para etiquetar el mensaje. El receptor debe mantener una lista de los mensajes que ya haya recibido.
El ejemplo [replicación geográfica con el nivel estándar de Service Bus][Replicación geográfica con el nivel estándar de Service Bus] muestra la replicación activa de entidades de mensajería.
Nota:
La replicación activa dobla el número de operaciones; por lo tanto, este enfoque puede suponer un costo mayor.
Replicación pasiva
En el caso de que no se hayan producido errores, la replicación pasiva solo usa una de las dos entidades de mensajería. Un cliente envía el mensaje a la entidad activa. Si la operación de la entidad activa genera un código de error que indica que es posible que el centro de datos que hospeda la entidad activa no esté disponible, el cliente envía una copia del mensaje a la entidad de reserva. En ese momento, las entidades activa y de copia de seguridad intercambian sus roles. El cliente remitente considera que la antigua entidad activa es la nueva entidad de seguridad y la entidad de seguridad anterior es la nueva entidad activa. Si ambas operaciones de envío generan un error, no se modifican los roles de las dos entidades y se devuelve un error.
Un cliente recibe mensajes de ambas colas. Dado que es probable que el receptor reciba dos copias del mismo mensaje, este debe suprimir los mensajes duplicados. Puede suprimir duplicados de la misma manera descrita para la replicación activa.
En general, la replicación pasiva es más económica que la activa porque en la mayoría de los casos se realiza una única operación. La latencia, el rendimiento y el costo económico son idénticos para el escenario sin replicación.
Cuando se usa la replicación pasiva, en los siguientes escenarios se pueden perder mensajes o recibirse dos veces:
- Demora o pérdida de mensajes: se supone que el remitente envió correctamente un mensaje m1 a la cola principal y después la cola deja de estar disponible antes de que el receptor reciba m1. El remitente envía otro mensaje m2 a la cola secundaria. Si la cola principal no está disponible temporalmente, el receptor recibe m1 una vez que la cola esté disponible de nuevo. Cuando se produce un desastre, es posible que el receptor nunca reciba m1.
- Recepción duplicada: supongamos que el remitente envía un mensaje m a la cola principal. Service Bus procesa m correctamente , pero no envía una respuesta. Una vez que la operación de envío agota el tiempo de espera, el remitente envía una copia idéntica de m a la cola secundaria. Si el receptor puede recibir la primera copia de m antes de que la cola principal deje de estar disponible, el receptor recibe ambas copias de m aproximadamente al mismo tiempo. Si el receptor no recibe la primera copia de m antes de que la cola principal deje de estar disponible, el receptor recibe inicialmente solo la segunda copia de m pero, a continuación, recibe una segunda copia de m cuando la cola principal vuelve a estar disponible.
El ejemplo tareas de replicación de mensajería de Azure con .NET Core muestra la replicación de mensajes entre espacios de nombres.
Pasos siguientes
Para obtener más información acerca de la recuperación ante desastres, consulte estos artículos: