Melhores práticas para proteger aplicações de indisponibilidades e de desastres do Service Bus
Os aplicativos de missão crítica devem operar continuamente, mesmo na presença de interrupções ou 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 exigido pelas regulamentações do setor. Este artigo descreve técnicas que você pode usar para proteger os aplicativos do Service Bus contra uma possível interrupção de serviço ou desastre.
O Barramento de Serviço do Azure já espalha o risco de falhas catastróficas de máquinas individuais ou até mesmo racks completos entre clusters que abrangem vários domínios de falha em um datacenter e implementa mecanismos transparentes de deteção de falhas e failover, de modo que o serviço continue a operar dentro dos níveis de serviço garantidos e, normalmente, sem interrupções percetíveis quando tais falhas ocorrem.
Além disso, o risco de interrupção é ainda mais espalhado por três instalações fisicamente separadas (zonas de disponibilidade), e o serviço tem 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 de agente de mensagens local em termos de resiliência contra falhas graves de hardware e até mesmo perda catastrófica de instalações inteiras do datacenter. Ainda assim, pode haver situações graves com destruição física generalizada contra as quais mesmo essas medidas não conseguem se defender suficientemente.
Os recursos de Recuperação de Desastres Geográficos e Replicação Geográfica do Service Bus foram projetados para facilitar a recuperação de um desastre dessa magnitude e abandonar definitivamente uma região do Azure com falha e sem a necessidade de alterar as configurações do aplicativo.
Interrupções e desastres
É importante notar a distinção entre "interrupções" e "desastres".
Uma interrupção é a indisponibilidade temporária do Barramento de Serviço do Azure e pode afetar alguns componentes do serviço, como um armazenamento de mensagens ou até mesmo todo o datacenter. No entanto, depois que o problema é corrigido, o Service Bus fica disponível novamente. Normalmente, uma interrupção não causa a perda de mensagens ou outros dados. Um exemplo de falha de componente é a indisponibilidade de um armazenamento de mensagens específico. Um exemplo de uma interrupção em todo o datacenter é uma falha de energia do datacenter ou um switch de rede de datacenter defeituoso. Uma interrupção pode durar de alguns minutos a alguns dias. Algumas interrupções são apenas perdas de conexão curtas devido a problemas transitórios ou de rede.
Um desastre é definido como a perda permanente ou de longo prazo de um cluster do Service Bus, região do Azure ou datacenter. A região ou o datacenter pode ou não ficar disponível novamente ou pode ficar inativo por horas ou dias. Exemplos de tais desastres são incêndios, inundações ou terremotos. Um desastre que se torna permanente pode causar a perda de algumas mensagens, eventos ou outros dados. No entanto, na maioria dos casos, não deve haver perda de dados e as mensagens podem ser recuperadas assim que o data center voltar a funcionar.
Proteção contra interrupções e desastres
Há dois recursos que fornecem a Recuperação de Desastres Geográficos no Barramento de Serviço do Azure para a camada Premium. Primeiro, há o Geo-Disaster Recovery (Metadata DR) que fornece replicação de metadados (entidades, configuração, propriedades). Em segundo lugar, há a Geo-Replication, que está atualmente em visualização pública, fornecendo replicação de metadados e dados (dados da mensagem e propriedades da mensagem / alterações de estado) em si. Nenhum recurso de recuperação de desastres geográficos 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 fornecem resiliência entre regiões do Azure, como Leste dos EUA e Oeste dos EUA.
As Zonas de Disponibilidade estão disponíveis em todas as camadas do Service Bus, e o suporte fornece resiliência dentro de uma região geográfica específica, como o Leste dos EUA. Para obter uma discussão detalhada sobre recuperação de desastres no Microsoft Azure, consulte este artigo.
Os conceitos de alta disponibilidade e recuperação de desastres são incorporados diretamente na camada premium do Barramento de Serviço do Azure, tanto na mesma região (por meio de zonas de disponibilidade) quanto em diferentes regiões (por meio de Recuperação de Desastres Geográficos e Replicação Geográfica).
Opções de Recuperação de Desastres Geográficos
Recuperação de desastres geográficos
A camada premium do Service Bus oferece suporte à Geo-Disaster Recovery, no nível do namespace. Para obter mais informações, consulte Recuperação de desastres geográficos do Barramento de Serviço do Azure. O recurso Geo-Disaster Recovery, disponível apenas para a camada Premium, implementa a recuperação de desastres de metadados e depende de namespaces primários e secundários. Com o Geo-Disaster Recovery, apenas metadados para entidades são replicados entre namespaces primários e secundários.
Georreplicação
A camada premium do Service Bus 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 (Visualização pública). O recurso de replicação geográfica, disponível apenas para a camada Premium e atualmente em visualização pública, implementa metadados e recuperação de desastres de dados e depende de regiões primárias e secundárias. Com a replicação geográfica, os metadados e os dados de entidades são replicados entre regiões primárias e secundárias.
Diferenças de recursos de alto nível
O recurso Geo-Disaster Recovery (Metadata DR) replica metadados para um namespace de um namespace primário para um namespace secundário. Ele suporta 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 é quebrado. 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 torna-se o primário e o primário anterior torna-se secundário. Os usuários podem executar um failover de volta ao primário original quando desejado.
Zonas de disponibilidade
Todas as camadas do Barramento de Serviço oferecem suporte a zonas de disponibilidade, fornecendo locais isolados por falhas dentro da mesma região do Azure. O Service Bus gerencia três cópias do armazenamento de mensagens (1 primária e 2 secundárias). O Service Bus mantém as três cópias sincronizadas para dados e operações de gerenciamento. Se a cópia principal falhar, uma das cópias secundárias será promovida para principal sem tempo de inatividade percebido. Se os aplicativos virem desconexões transitórias do Service Bus, a lógica de repetição no SDK se reconectará automaticamente ao Service Bus.
Quando você usa zonas de disponibilidade, metadados e dados (mensagens) são replicados entre data centers na zona de disponibilidade.
Nota
O suporte a zonas de disponibilidade só está disponível em regiões do Azure onde as zonas de disponibilidade estão presentes.
Quando você cria um namespace, o suporte para zonas de disponibilidade (se disponível na região selecionada) é automaticamente habilitado para o namespace. Não há custo extra para usar esse recurso e você não pode desabilitar ou habilitar esse recurso após a criação do namespace.
Nota
Anteriormente, era necessário definir a propriedade zoneRedundant para true habilitar zonas de disponibilidade, no entanto, esse comportamento foi alterado 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 preterida. A propriedade zoneRedundant ainda pode ser exibida como false, mesmo quando as zonas de disponibilidade foram habilitadas.
Namespaces existentes que estão sendo migrados:
- Atualmente não tem zonas de disponibilidade habilitadas.
- A região suporta zonas de disponibilidade.
- A região tem capacidade suficiente na zona de disponibilidade.
Proteção contra desastres - nível padrão
Para obter resiliência contra desastres com a camada Padrão do Service Bus, você pode usar a replicação ativa ou passiva . Para cada abordagem, se uma determinada fila ou tópico precisar permanecer acessível na presença de uma interrupção 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 alcançada em contosoPrimary.servicebus.windows.net/myQueue, enquanto sua contraparte secundária pode ser alcançada em contosoSecondary.servicebus.windows.net/myQueue.
Nota
A replicação ativa e a configuração da replicação passiva são soluções de uso geral e não recursos específicos do Service Bus. A lógica de replicação (envio para 2 namespaces diferentes) está nos aplicativos remetentes e o recetor deve ter lógica personalizada para deteção de duplicados.
Se o aplicativo não exigir comunicação permanente entre remetente e recetor, o aplicativo poderá implementar uma fila durável do lado do cliente para evitar a perda de mensagens e proteger o remetente de quaisquer erros transitórios do Service Bus.
Replicação ativa
A replicação ativa usa entidades em ambos os namespaces para cada operação. Qualquer cliente que envie uma mensagem envia duas cópias da mesma mensagem. A primeira cópia é enviada para a entidade primária (por exemplo, contosoPrimary.servicebus.windows.net/sales) e a segunda cópia da mensagem é enviada para a entidade secundária (por exemplo, contosoSecondary.servicebus.windows.net/sales).
Um cliente recebe mensagens de ambas as filas. O recetor processa a primeira cópia de uma mensagem e a segunda cópia é suprimida. Para suprimir mensagens duplicadas, o remetente deve 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 destinatário deve manter uma lista de mensagens que já recebeu.
Nota
A abordagem de replicação ativa dobra o número de operações, portanto, essa abordagem pode levar a custos mais altos.
Replicação passiva
No caso sem falhas, a replicação passiva usa 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 indica que o datacenter que hospeda a entidade ativa pode estar indisponível, o cliente envia uma cópia da mensagem para a entidade de backup. Nesse ponto, as entidades ativas e de backup alternam de função. O cliente de envio considera a entidade ativa antiga como a nova entidade de backup e a entidade de backup antiga é 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 recetor receba duas cópias da mesma mensagem, o recetor deve suprimir mensagens duplicadas. Você pode suprimir duplicatas da mesma maneira descrita 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, apenas uma operação é executada. A latência, a taxa de transferência e o custo monetário são idênticos ao cenário não replicado.
Quando você usa a replicação passiva, nos seguintes cenários, as mensagens podem ser perdidas ou recebidas duas vezes:
- Atraso ou perda de mensagem: Suponha que o remetente enviou com êxito uma mensagem m1 para a fila principal e, em seguida, a fila fica indisponível antes que o recetor receba m1. O remetente envia uma mensagem subsequente m2 para a fila secundária. Se a fila principal estiver temporariamente indisponível, o recetor receberá m1 depois que a fila ficar disponível novamente. Quando um desastre acontece, o recetor pode nunca receber m1.
- Receção duplicada: Suponha que o remetente envia uma mensagem m para a fila principal. O Service Bus processa m com êxito, mas não envia uma resposta. Após o tempo limite da operação de envio, o remetente envia uma cópia idêntica de m para a fila secundária. Se o recetor é capaz de receber a primeira cópia de m antes que a fila primária se torne indisponível, o recetor recebe ambas as cópias de m aproximadamente ao mesmo tempo. Se o recetor não for capaz de receber a primeira cópia de m antes que a fila principal se torne indisponível, o recetor inicialmente recebe apenas a segunda cópia de m, mas depois recebe uma segunda cópia de m quando a fila primária se torna disponível.
O exemplo de Tarefas de Replicação de Mensagens do Azure com .NET Core demonstra a replicação de mensagens entre namespaces.
Próximos passos
Para saber mais sobre a recuperação de desastres, consulte estes artigos: