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. A resiliência contra interrupções desastrosas de recursos de processamento de dados é um requisito para muitas empresas e, em alguns casos, até mesmo exigida por regulamentos do setor. 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.

O Barramento de Serviço do Azure já espalha o risco de falhas catastróficas de computadores individuais ou até mesmo racks completos em clusters que abrangem vários domínios de falha dentro de um datacenter e implementa mecanismos transparentes de detecção e failover de falha, de modo que o serviço continue operando dentro dos níveis de serviço garantidos, normalmente sem interrupções perceptíveis quando essas falhas ocorrem.

Além disso, o risco de interrupção é ainda mais distribuído entre três instalações fisicamente separadas (zonas de disponibilidade), e o serviço possui reservas de capacidade suficientes para lidar instantaneamente com a perda completa e catastrófica de um datacenter. O modelo de cluster do Barramento de Serviço do Azure totalmente ativo dentro de um domínio de falha, juntamente com o suporte à zona de disponibilidade, é superior a qualquer produto do agente de mensagens local em termos de resiliência contra falhas graves de hardware e até mesmo perda catastrófica de instalações de datacenter inteiras. Ainda assim, pode haver grave situações com destruição física generalizada em que até mesmo essas medidas poderão não ser suficientes para garantir a proteção.

Os recursos de recuperação de desastres geográfico e replicação geográfica do Barramento de Serviço foram projetados para facilitar a recuperação de um desastre dessa magnitude e abandonar permanentemente uma região do Azure que falhou, sem precisar alterar as configurações de seu aplicativo.

Interrupções e desastres

É importante observar a diferença entre "interrupção" e "desastres".

Uma interrupção é uma indisponibilidade temporária do Barramento de Serviço do Azure e pode afetar alguns componentes do serviço, como um repositório de mensagens ou até mesmo o datacenter inteiro. No entanto, depois que o problema for corrigido, o Barramento de Serviço ficará disponível novamente. Normalmente, uma interrupção não causa a perda de mensagens ou 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. Algumas falhas são apenas perdas de conexão curtas devido a problemas de rede ou transitórios.

Um desastre é definido como a perda permanente ou de longo prazo de um cluster do Barramento de Serviço, uma região do Azure ou um datacenter. A região ou o datacenter pode ou não ficar disponível novamente ou pode ficar inativa por horas ou dias. Outros exemplos desses desastres são incêndios, enchentes ou terremoto. Um desastre que se torne permanente pode causar a perda de algumas mensagens, alguns eventos ou outros dados. No entanto, na maioria dos casos, não deve haver perda de dados e as mensagens podem ser recuperadas depois que o data center se torna disponível novamente.

Proteção contra interrupções e desastres

Há dois recursos que fornecem recuperação de desastre geográfico no Barramento de Serviço do Azure para a camada Premium. Primeiro, há a recuperação de desastre geográfico (DR de metadados) oferecendo replicação de metadados (entidades, configuração, propriedades). Em segundo lugar, há a replicação geográfica, que está atualmente em versão prévia pública, oferecendo replicação tanto dos metadados quanto dos dados (dados de mensagens e mudanças de propriedades/estados das mensagens). Nenhum recurso de recuperação de desastre geográfico deve ser confundido com Zonas de Disponibilidade. Independentemente de ser DR de metadados ou replicação geográfica, ambos os recursos de recuperação geográfica oferecem resiliência entre regiões do Azure, como Leste dos EUA e Oeste dos EUA.

As Zonas de Disponibilidade estão disponíveis em todos os níveis de serviço do Barramento de Serviço e oferecem resiliência dentro de uma região geográfica específica, como Leste dos EUA. Para uma discussão detalhada sobre a recuperação de desastre no Microsoft Azure, consulte este artigo.

Os conceitos de alta disponibilidade e recuperação de desastre estão integrados diretamente na camada premium do Barramento de Serviço do Azure, tanto dentro da mesma região (via zonas de disponibilidade) quanto entre diferentes regiões (via recuperação de desastre geográfico e replicação geográfica).

Opções de 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 geográfico do Barramento de Serviço do Azure. O recurso de recuperação de desastre geográfico, disponível apenas na camada Premium, implementa a recuperação de desastre de metadados e depende de namespaces primários e secundários. Com a recuperação de desastre geográfico, somente os metadados para entidades são replicados entre os namespaces primário e secundário.

Replicação Geográfica

A camada premium do Barramento de Serviço também oferece suporte à replicação geográfica no nível do namespace. Para obter mais informações, consulte Replicação geográfica do Barramento de Serviço do Azure (versão prévia pública). O recurso de replicação geográfica, disponível apenas na camada Premium e atualmente em visualização pública, implementa a recuperação de desastres de metadados e dados, dependendo de regiões primárias e secundárias. Com a replicação geográfica, os metadados e dados das entidades são replicados entre as regiões primárias e secundárias.

Diferenças de recursos de alto nível

O recurso de recuperação de desastre geográfico (DR de metadados) replica metadados de um namespace de um namespace primário para um namespace secundário. Ele dá suporte apenas a um failover único para a região secundária. Durante o failover iniciado pelo cliente, o nome do alias para o namespace é redirecionado para o namespace secundário e em seguida, o emparelhamento é interrompido. Nenhum dado é replicado além dos metadados, nem as atribuições RBAC são replicadas.

O recurso de replicação geográfica replica metadados e todos os dados de uma região primária para uma ou mais regiões secundárias. Quando um failover é executado pelo cliente, o secundário selecionado se torna o primário e o primário anterior se torna um secundário. Os usuários podem executar um failover de volta para o primário original quando desejado.

Zonas de disponibilidade

Todos as camadas do Barramento de Serviço dão suporte a zonas de disponibilidade, que oferecem locais isolados contra 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 só é oferecido nas regiões do Azure em que existem zonas de disponibilidade.

Quando você cria um namespace, o suporte para zonas de disponibilidade (se disponível na região selecionada) é habilitado automaticamente para o namespace. 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.

Observação

Anteriormente, era necessário configurar a propriedade zoneRedundant como true para habilitar zonas de disponibilidade, mas esse comportamento mudou para habilitar zonas de disponibilidade por padrão. Os namespaces existentes estão sendo migrados para zonas de disponibilidade sempre que possível, e a propriedade zoneRedundant está sendo descontinuada. A propriedade zoneRedundant ainda pode ser mostrada como false, mesmo quando as zonas de disponibilidade tiverem sido habilitadas. Namespaces existentes que estão sendo migrados:

  • Atualmente não há zonas de disponibilidade habilitadas.
  • A região suporta zonas de disponibilidade.
  • A região tem capacidade de zona de disponibilidade suficiente.

Proteção contra desastres – camada standard

Para alcançar resiliência contra desastres com o Barramento de Serviço na camada standard, você pode utilizar 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.

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: