Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Barramento de Serviço

  • Artigo

Os aplicativos de missão crítica devem funcionar continuamente, mesmo na presença de interrupções ou de desastres não planejados. Este artigo descreve técnicas que podem ser usadas para proteger aplicativos do Barramento de Serviço contra uma potencial interrupção de serviço ou um desastre.

Uma interrupção é definida como a indisponibilidade temporária do Barramento de Serviço do Azure. A interrupção pode afetar alguns componentes do Barramento de Serviço, como um repositório de mensagens ou até mesmo o datacenter inteiro. Depois que o problema tiver sido corrigido, o Barramento de Serviço ficará disponível novamente. Normalmente, uma interrupção não causa a perda de mensagens nem de outros dados. Um exemplo de falha de um componente é a indisponibilidade de um repositório de mensagens específico. Um exemplo de uma paralisação de todo o datacenter é uma falha de energia do datacenter ou uma chave de rede do datacenter com defeito. Uma falha pode durar de alguns minutos até alguns dias.

Um desastre é definido como a perda permanente de uma unidade de escala ou de um datacenter do Barramento de Serviço. O datacenter pode ou não ficar disponível novamente. Normalmente, um desastre causa perda de algumas ou de todas as mensagens ou de outros dados. Exemplos de desastres são incêndios, enchentes ou terremoto.

Proteção contra interrupções e desastres – camada premium

Os conceitos de alta disponibilidade e recuperação de desastres são integrados diretamente à camada do Barramento de Serviço Premium do Azure, ambos na mesma região (por meio de zonas de disponibilidade) e em diferentes regiões (via recuperação de desastre geográfico).

Recuperação de desastre geográfico

A camada de Barramento de Serviço Premium oferece suporte à recuperação de desastre geográfico no nível do namespace. Para mais informações consulte Recuperação de desastre em área geográfica do Barramento de Serviço do Azure. O recurso de recuperação de desastre, disponível apenas para SKU Premium, implementa a recuperação de desastre dos metadados e se baseia em namespaces primário e secundário. Com a recuperação de desastre geográfico, somente os metadados para entidades são replicados entre os namespaces primário e secundário.

Zonas de disponibilidade

A camada premium do Barramento de Serviço oferece suporte às zonas de disponibilidade, fornecendo locais isolados de falhas dentro da mesma região do Azure. O Barramento de Serviço gerencia três cópias do repositório de mensagens (uma primária e duas secundárias). O Barramento de Serviço mantém todas as três cópias em sincronia para operações de gerenciamento e dados. Se a cópia primária falhar, uma das cópias secundárias será promovida para primária sem nenhum tempo de inatividade percebido. Se os aplicativos experimentarem desconexões transitórias do Barramento de Serviço, a lógica de repetição no SDK se reconectará automaticamente ao Barramento de Serviço.

Quando você usa zonas de disponibilidade, os metadados e os dados (mensagens) são replicados entre data centers na zona de disponibilidade.

Observação

O suporte a zonas de disponibilidade para a camada premium só é oferecido nas regiões do Azure em que existem zonas de disponibilidade.

Quando você cria um namespace da camada premium por meio do portal, o suporte para zonas de disponibilidade (se disponível na região selecionada) é habilitado automaticamente para o namespace. Ao criar um namespace de camada Premium por meio de outros mecanismos, como modelos do Azure Resource Manager/Bicep, CLI ou PowerShell, a propriedade zoneRedundant precisa ser definida explicitamente para true para habilitar zonas de disponibilidade (se disponível na região selecionada). Não há custo adicional para usar esse recurso e não é possível desabilitar ou habilitar esse recurso depois da criação do namespace.

Proteção contra interrupções e desastres – camada standard

Para obter resiliência contra interrupções de datacenter com o tipo de preço de mensagens padrão, você pode usar replicação ativa ou passiva. Para cada abordagem, se um determinado tópico ou fila deve permanecer acessível em caso de falha do datacenter, você poderá criá-lo em ambos os namespaces. Ambas as entidades podem ter o mesmo nome. Por exemplo, uma fila primária pode ser acessada em contosoPrimario.servicebus.windows.net/minhaFila, enquanto a sua equivalente secundária pode ser acessada em contosoSecundario.servicebus.windows.net/minhaFila.

Observação

As configurações da replicação ativa e da replicação passiva são soluções de uso geral e recursos não específicos do Barramento de Serviço. A lógica de replicação (enviando para dois namespaces diferentes) está nos aplicativos remetentes e o receptor deve ter a lógica personalizada para detecção de duplicidades.

Se o aplicativo não exigir comunicação permanente do remetente para receptor, o aplicativo poderá implementar uma fila durável do lado do cliente para evitar a perda de mensagens e proteger o remetente de erros transitórios do Barramento de Serviço.

Replicação ativa

A replicação ativa usa entidades em ambos os namespaces para todas as operações. Qualquer cliente que enviar uma mensagem enviará duas cópias da mesma mensagem. A primeira cópia é enviada para a entidade primária (por exemplo, contosoPrimario.servicebus.windows.net/vendas) e a segunda cópia da mensagem é enviada para a entidade secundária (por exemplo, contosoSecundario.servicebus.windows.net/vendas).

Um cliente recebe mensagens de ambas as filas. O receptor processa a primeira cópia de uma mensagem e a segunda cópia é suprimida. Para suprimir mensagens duplicadas, o remetente deverá marcar cada mensagem com um identificador exclusivo. Ambas as cópias da mensagem devem ser marcadas com o mesmo identificador. Você pode usar as propriedades ServiceBusMessage.MessageId ou ServiceBusMessage.Subject ou uma propriedade personalizada para marcar a mensagem. O receptor deve manter uma lista de mensagens que já recebeu.

O exemplo de [replicação geográfica com camada standard do Barramento de Serviço][Replicação geográfica com Camada Standard do Barramento de Serviço] demonstra a replicação ativa de entidades de mensagens.

Observação

A abordagem de replicação ativa dobra o número de operações e, portanto, essa abordagem pode gerar custos mais altos.

Replicação passiva

No caso sem falhas, a replicação passiva usará apenas uma das duas entidades de mensagens. Um cliente envia a mensagem para a entidade ativa. Se a operação na entidade ativa falhar com um código de erro que indique que o datacenter que hospeda a entidade ativa pode estar indisponível, o cliente enviará uma cópia da mensagem para a entidade de backup. Nesse momento, as entidades ativas e de backup alternam as funções. O cliente remetente considera que a antiga entidade ativa é a nova entidade de backup e a antiga entidade de backup é a nova entidade ativa. Se ambas as operações de envio falharem, as funções das duas entidades permanecerão inalteradas e um erro será retornado.

Um cliente recebe mensagens de ambas as filas. Como há uma chance de que o receptor receba duas cópias da mesma mensagem, o receptor deverá suprimir mensagens duplicadas. Você pode suprimir duplicatas da mesma maneira como descrito para a replicação ativa.

Em geral, a replicação passiva é mais econômica do que a replicação ativa porque, na maioria dos casos, somente uma operação é executada. A latência, a taxa de transferência e o custo monetário são idênticos aos do cenário não replicado.

Quando a replicação passiva for usada, as seguintes mensagens de cenário poderão ser perdidas ou recebidas duas vezes:

  • Perda ou atraso de mensagens: suponha que o remetente tenha enviado com êxito uma mensagem m1 para a fila primária e então a fila ficou indisponível antes do destinatário receber m1. O remetente envia uma mensagem subsequente m2 para a fila secundária. Se a fila primária estiver temporariamente indisponível, o destinatário receberá m1 depois que a fila ficar disponível novamente. Quando ocorre um desastre, o receptor pode nunca receber m1.
  • Recebimento duplicado: suponha que o remetente enviar uma mensagem m para a fila primária. O Barramento de Serviço processa m com êxito, mas falha ao enviar uma resposta. Depois que a operação de envio atingir o tempo limite, o remetente enviará uma cópia idêntica de m para a fila secundária. Se o receptor for capaz de receber a primeira cópia de m antes da fila primária ficar indisponível, o receptor receberá ambas as cópias de m aproximadamente ao mesmo tempo. Se o receptor não for capaz de receber a primeira cópia de m antes da fila primária ficar indisponível, inicialmente o destinatário receberá somente a segunda cópia de m, mas depois receberá uma segunda cópia de m quando a fila primária ficar disponível.

O exemplo de Tarefas de Replicação de Mensagens do Azure com o .NET Core demonstram a replicação de mensagens entre namespaces.

Próximas etapas

Para saber mais sobre a recuperação de desastres, confira estes artigos: