Compartir por

Procedimientos recomendados para aislar aplicaciones ante desastres e interrupciones de Service Bus

  • Artigo

Las aplicaciones esenciales deben funcionar de manera continua, incluso si se producen interrupciones imprevistas o desastres. Muchas empresas y, en algunos casos, las normativas del sector imponen como requisito la resistencia frente a interrupciones desastrosas de los recursos de procesamiento de datos. 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.

Azure Service Bus ya distribuye el riesgo de errores catastróficos de máquinas individuales, o incluso de bastidores completos, entre clústeres que abarcan varios dominios de error en un centro de recursos. Además, implementa mecanismos transparentes tanto de detección de errores como de conmutación por error, de modo que el servicio siga funcionando dentro de los niveles de servicio garantizados y normalmente sin interrupciones apreciables cuando se produzcan dichos errores.

Además, el riesgo de interrupción se reparte aún más entre tres instalaciones físicamente separadas (zonas de disponibilidad), y el servicio tiene suficientes reservas de capacidad para hacer frente instantáneamente a la pérdida completa y catastrófica de un centro de datos. El modelo de clústeres totalmente activos de Azure Service Bus dentro de un dominio de error, junto con la compatibilidad con la zona de disponibilidad, es superior a cualquier producto de agente de mensajes local en términos de resistencia contra errores graves de hardware e incluso contra la pérdida catastrófica de instalaciones completas del centro de datos. Aun así, puede haber situaciones graves en las que se produzca una destrucción física generalizada frente a las que ni siquiera estas medidas puedan ofrecer una protección suficiente.

Las características de recuperación ante desastres geográfica y replicación geográfica de Service Bus están diseñadas para que sea más fácil recuperarse ante un desastre de esta magnitud y abandonar para siempre una región de Azure con errores, sin necesidad de cambiar las opciones de configuración de la aplicación.

Interrupciones y desastres

Es importante tener en cuenta la distinción entre "interrupciones" y "desastres".

Una interrupción es la falta de disponibilidad temporal de Azure Service Bus y puede afectar a algunos componentes del servicio, como un almacén de mensajes o incluso todo el centro de datos. Sin embargo, una vez corregido el problema, Service Bus vuelve 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. Algunas interrupciones son solo breves pérdidas de conexión debido a problemas transitorios o de red.

Un desastre se define como la pérdida permanente o a largo plazo de un clúster, una región de Azure o un centro de datos de Service Bus. La región o el centro de datos podrían volver a estar disponibles o no, o podrían estar fuera de servicio durante horas o días. Algunos ejemplos de esos desastres son los incendios, las inundaciones o los terremotos. Un desastre que se convierte en permanente podría provocar la pérdida de algunos mensajes, eventos u otros datos. Sin embargo, en la mayoría de los casos, no se producirá una pérdida de datos y se pueden recuperar los mensajes una vez que el centro de datos vuelva a funcionar.

Protección contra interrupciones y desastres

Hay dos características que proporcionan recuperación ante desastres geográfica en Azure Service Bus para el nivel premium. En primer lugar, hay recuperación ante desastres geográfica (recuperación ante desastres de metadatos) que proporciona replicación de metadatos (entidades, configuración, propiedades). En segundo lugar, hay replicación geográfica, que se encuentra actualmente en versión preliminar pública, lo que proporciona replicación de metadatos y datos (datos de mensajes y cambios de propiedad o estado del mensaje). Ninguna característica de recuperación ante desastres geográfica debe confundirse con Availability Zones. Independientemente de si se trata de recuperación ante desastres de metadatos o replicación geográfica, ambas características de recuperación geográfica proporcionan resistencia entre regiones de Azure como Este de EE. UU. y Oeste de EE. UU.

Availability Zones está disponible en todos los niveles de Service Bus y la compatibilidad proporciona resistencia dentro de una región geográfica específica, como Este de EE. UU. Para obtener una explicación detallada de la recuperación ante desastres en Microsoft Azure, consulte este artículo.

Los conceptos de alta disponibilidad y recuperación ante desastres están integrados en el nivel de premium de Azure Service Bus, tanto dentro de la misma región (a través de Availability Zones) como en diferentes regiones (a través de la recuperación ante desastres geográficas y la replicación geográfica).

Opciones de recuperación ante desastres geográficas

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 geográfica, disponible solo para el nivel 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.

Replicación geográfica

El nivel Premium de Service Bus también admite la replicación geográfica en el nivel del espacio de nombres. Para más información, consulte Replicación geográfica de Azure Service Bus (versión preliminar pública). La característica de replicación geográfica, disponible solo para el nivel premium y actualmente en versión preliminar pública, implementa la recuperación ante desastres de metadatos y datos y depende de regiones principales y secundarias. Con la replicación geográfica, tanto los metadatos como los datos para las entidades se replican entre las regiones principal y secundaria.

Diferencias de características de alto nivel

La característica Recuperación ante desastres geográfica (DR de metadatos) replica los metadatos de un espacio de nombres de espacio de nombres principal a espacio de nombres secundario. Admite una conmutación por error única en la región secundaria. Durante la conmutación por error iniciada por el cliente, el nombre de alias del espacio de nombres se redirecciona al espacio de nombres secundario y después se rompe el emparejamiento. No se replican datos distintos de los metadatos ni se replican las tareas de RBAC.

La característica de replicación geográfica replica los metadatos y todos los datos de una región primaria a una o más regiones secundarias. Cuando el cliente realiza una conmutación por error, el secundario seleccionado pasa a ser el primario y el primario anterior se convierte en secundario. Los usuarios pueden realizar una conmutación por error volviendo al primario original cuando lo deseen.

Zonas de disponibilidad

Todos los niveles de Service Bus admiten zonas de disponibilidad, lo que proporciona ubicaciones con errores aislados en 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 solo está disponible en aquellas regiones de Azure en las que hay zonas de disponibilidad.

Al crear un espacio de nombres, la compatibilidad con zonas de disponibilidad (si está disponible en la región seleccionada) se habilita automáticamente para el espacio de nombres. 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.

Nota:

Anteriormente era necesario establecer la propiedad zoneRedundant en true para habilitar Availability Zones, pero este comportamiento ha cambiado para habilitar Availability Zones de forma predeterminada. Los espacios de nombres existentes también se migran a Availability Zones y la propiedad zoneRedundant está en desuso. Es posible que la propiedad zoneRedundant se siga mostrando como false, incluso cuando se ha habilitado Availability Zones.

Protección contra desastres: nivel estándar

Para lograr resistencia frente a desastres con el nivel estándar de Service Bus, 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.

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: