ComprarBuy
1-855-856-7678
Soporte técnicoSupport
Aislar las aplicaciones de Service Bus contra interrupciones y desastres de Service Bus
Las aplicaciones más importantes deben funcionar sin interrupción, incluso en el caso de un corte o desastre inesperado. En este tema se describen las técnicas que puede usar para proteger a las aplicaciones de un posible corte o desastre en Service Bus de Windows Azure.
Un corte se define como la indisponibilidad temporal de una unidad de escala de Service Bus. Cuando el problema se haya solucionado, la unidad de escala vuelve a estar disponible. Normalmente, un corte de red no provoca la pérdida de mensajes u otros datos. Entre algunos ejemplos de cortes se incluye la interrupción del suministro eléctrico del centro de datos o un conmutador de red de centro de datos defectuoso. Un corte puede durar de varios minutos a varios días.
Un desastre se define como la pérdida permanente de una unidad de escala o un centro de datos de Service Bus. Puede que el centro de datos vuelva o no vuelva a estar disponible. Normalmente, un desastre provoca la pérdida de algunos o todos los mensajes u otros datos. Entre los ejemplos de desastres se incluyen incendios, inundaciones o terremotos.
Arquitectura actual
Todas las entidades de mensajes de Service Bus residen en un espacio de nombres de servicio. Lo mismo sucede para Active Directory Access Control de Windows Azure (también conocido como Access Control Service o ACS), que proporciona los tokens necesarios para acceder a las entidades de Service Bus. Un espacio de nombres de servicio está afiliado a un centro de datos. Service Bus y ACS no permiten la replicación geográfica de datos automática ni que un espacio de nombres de servicio abarque varios centros de datos.
Para permitir la conmutación entre dos centros de datos, puede crear un espacio de nombres de servicio Service Bus y ACS en cada centro de datos. Por ejemplo, el espacio de nombres de servicio Service Bus contosoPrimary.servicebus.windows.net puede encontrarse en la región de Estados Unidos (Norte/Central) y contosoSecondary.servicebus.windows.net, en Estados Unidos (Sur/Central). Si una entidad de mensajes de Service Bus debe estar accesible en el caso de un corte de red en el centro de datos, puede crearla en ambos espacio de nombres de servicio.
Mensajería retransmitida
La replicación geográfica de los extremos de retransmisión permite que un servicio que expone un extremo de retransmisión sea accesible en caso de cortes de red de Service Bus. Para lograr la replicación geográfica, el servicio debe crear dos extremos de retransmisión en distintos espacio de nombres de servicio. Ambos espacio de nombres de servicio deben residir en distintos centros de datos y ambos extremos deben tener nombres diferentes. Por ejemplo, se puede acceder a un extremo principal en contosoPrimary.servicebus.windows.net/myPrimaryService y a su equivalente secundario, en contosoSecondary.servicebus.windows.net/mySecondaryService.
A continuación, el servicio escucha ambos extremos y un cliente puede invocar el servicio a través de cualquiera de ellos. Una aplicación cliente selecciona de forma aleatoria una de las retransmisiones como extremo principal y envía su solicitud al extremo activo. Si se produce un error en la operación con un código de error, esto significa que el extremo de retransmisión no está disponible. La aplicación abre un canal al extremo de seguridad y vuelve a emitir la solicitud. En ese momento, el extremo activo y el de seguridad intercambian sus roles: la aplicación cliente considera que el antiguo extremo activo es el nuevo extremo de seguridad y que el antiguo extremo de seguridad es el nuevo extremo activo. Si se produce un error en ambas operaciones de envío, los roles de las dos entidades no cambian y se devuelve un error.
El ejemplo de replicación geográfica con mensajes retransmitidos de Service Bus muestra la replicación de retransmisiones.
Mensajería con confianza establecida
Si se usa la mensajería con confianza establecida, Service Bus admite dos enfoques para protegerse de los cortes de red en los centros de datos: replicación activa y pasiva. En ambos enfoques, si una cola o tema determinado debe estar accesible en el caso de un corte de red en el centro de datos, puede crearlo en ambos espacio de nombres de servicio. El nombre de las dos entidades puede ser igual. Por ejemplo, se puede acceder a una cola principal en contosoPrimary.servicebus.windows.net/myQueue y a su equivalente secundario, en contosoSecondary.servicebus.windows.net/myQueue.
Si la aplicación no requiere una comunicación permanente de remitente a destinatario, puede implementar una cola de cliente duradera para evitar la pérdida de mensajes y proteger al remitente de los errores transitorios de Service Bus.
Replicación activa
La replicación activa usa entidades en ambos espacio de nombres de servicio para cada operación. Cualquier cliente que envía un mensaje, envía dos copias del mismo mensaje. La primera copia se envía a la entidad principal (por ejemplo, contosoPrimary.servicebus.windows.net/sales) y la segunda, a la entidad secundaria (por ejemplo, contosoSecondary.servicebus.windows.net/sales).
Un cliente recibe mensajes de ambas colas. El receptor procesa la primera copia del mensaje y suprime la segunda. Para suprimir los mensajes duplicados, el remitente debe etiquetar cada mensaje con un identificador único. Ambas copias del mensaje se deben etiquetar con el mismo identificador. Puede usar MessageId, Label o una propiedad personalizada para etiquetar el mensaje. El receptor debe conservar una lista de los mensajes recibidos.
El ejemplo de replicación geográfica con mensajes retransmitidos de Service Bus muestra la replicación activa de entidades de mensajes.
 Nota |
|---|
| La replicación activa dobla la cantidad de operaciones, por lo que puede suponer un coste mayor. |
Replicación pasiva
Si no se produce ningún error, la replicación pasiva solo usa una de las dos entidades de mensajes. Un cliente envía el mensaje a la entidad activa. Si se produce un error en el funcionamiento de la entidad activa y un código de error indica que el centro de datos que hospeda la entidad puede no estar disponible, el cliente envía una copia del mensaje a la entidad de seguridad. En ese momento, las entidades activa y de seguridad intercambian sus roles: el cliente remitente considera que la antigua entidad activa es la nueva entidad de seguridad y que la antigua entidad de seguridad es la nueva entidad activa. Si se produce un error en ambas operaciones de envío, los roles de las dos entidades no cambian y se devuelve un error.
Un cliente recibe mensajes de ambas colas. Dado que es posible que el receptor reciba dos copias del mismo mensaje, este debe suprimir los mensajes duplicados. Puede hacerlo como se ha descrito 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, solo se realiza una operación. La latencia, el rendimiento y los costes monetarios son idénticos a los de una situación sin réplicas.
Si se usa la replicación pasiva, los mensajes se pueden perder o recibir por duplicado en los casos siguientes:
-
Demora o pérdida de mensajes: supongamos que el remitente envía un mensaje m1 correctamente a la cola principal y que esta deja de estar disponible antes de que el destinatario reciba m1. El remitente envía el mensaje m2 subsiguiente a la cola secundaria. Si la cola principal no está disponible temporalmente, el destinatario recibe m1 cuando vuelva a estarlo. En el caso de un desastre, es posible que el remitente nunca reciba m1.
-
Recepción duplicada: supongamos que el emisor envía el mensaje m a la cola principal. Service Bus procesa m correctamente pero no envía ninguna respuesta. Cuando se agota el tiempo de espera de la operación de envío, el remitente envía una copia idéntica de m a la cola secundaria. Si el receptor consigue recibir la primera copia de m antes de que la cola principal deje de estar disponible, recibirá ambas copias de m en el mismo momento, aproximadamente. Si el receptor no consigue recibir la primera copia de m antes de que la cola principal deje de estar disponible, recibirá únicamente la segunda copia de m. Cuando la cola principal vuelva a estar disponible, recibirá una segunda copia de m.
El ejemplo de replicación geográfica con mensajes retransmitidos de Service Bus muestra la replicación pasiva de entidades de mensajes.
Cola de cliente duradera
Si la aplicación puede tolerar la indisponibilidad de una entidad de Service Bus, pero no debe perder mensajes, el remitente puede emplear una cola de cliente duradera que almacena localmente todos los mensajes que no se pueden enviar a Service Bus. Cuando la entidad de Service Bus vuelva a estar disponible, todos los mensajes almacenados en el búfer se envían a ella. El ejemplo Remitente de mensajes duradero implementa este tipo de cola con la ayuda de MSMQ. Como alternativa, los mensajes se pueden grabar en el disco local.
Una cola de cliente duradera conserva el orden de los mensajes y protege a la aplicación cliente contra excepciones cuando la entidad de Service Bus no está disponible. Se puede usar con transacciones simples y distribuidas.
Vea también
