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 no volverá necesariamente a estar disponible. 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 en el SDK volverá a establecer la conexión con Service Bus automáticamente.
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.
Puede habilitar zonas de disponibilidad solo en los espacios de nombres nuevos mediante Azure Portal. Service Bus no admite la migración de espacios de nombres existentes. No se puede deshabilitar la redundancia de zona después de habilitarla en el espacio de nombres.
Protección contra interrupciones y desastres: nivel estándar
Para lograr resistencia frente a interrupciones del centro de datos al usar el plan de tarifa de mensajería estándar, Service Bus admite dos enfoques: replicación activa y 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 BrokeredMessage.MessageId o BrokeredMessage.Label, o bien una propiedad personalizada, para etiquetar el mensaje. El receptor debe mantener una lista de los mensajes que ya haya recibido.
En el ejemplo de replicación geográfica con el nivel estándar de Service Bus se 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. En caso de desastre, puede que el receptor no reciba nunca 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.
En el ejemplo de replicación geográfica con el nivel estándar de Service Bus se muestra la replicación pasiva de entidades de mensajería.
Pasos siguientes
Para obtener más información acerca de la recuperación ante desastres, consulte estos artículos: