O que são failover e failback?

Este artigo fornece uma visão geral de como o failover e o failback operam em um ambiente de nuvem. No entanto, para entender o failover, você deve primeiro entender a redundância e a replicação. Para saber mais sobre esses conceitos antes de continuar com este artigo, consulte Redunância, replicação e backup.

Um motivo comum para manter cópias redundantes de aplicativos e réplicas de dados é ser capaz de executar um failover. Com o failover, pode-se redirecionar o tráfego e as solicitações de instâncias com problemas para instâncias saudáveis. Em seguida, quando as instâncias originais se tornarem íntegras novamente, você poderá executar um failback para retornar à configuração original.

Funções de instância ativa e passiva

No contexto de failover, uma instância pode ser um único componente, como um banco de dados, ou uma coleção de vários componentes que compõem uma implantação de serviço em uma região. Ao longo de uma solução inteira, você pode fazer failover de diferentes partes dessa solução de maneiras diferentes e em situações diferentes.

Um componente, ou um conjunto de componentes configurado para failover e failback, requer várias instâncias. Cada uma dessas instâncias assume um papel específico:

• As instâncias primárias ou ativas funcionam ativamente, como atender solicitações de entrada de clientes. Normalmente, há uma instância primária de cada vez.
• As instâncias secundárias ou passivas estão inativas, mas estão prontas para serem trocadas para se tornarem as principais, se necessário. Pode haver várias instâncias secundárias.

Há várias maneiras de configurar instâncias passivas. Cada maneira envolve compensações entre o tempo de recuperação e outros fatores, como custo e complexidade operacional:

• Hot standbys, que são projetados para estarem prontos para aceitar tráfego de produção a qualquer momento.
• Esperas quentes, que são projetadas para estarem quase prontas para aceitar tráfego de produção, mas que podem exigir algumas alterações de configuração ou operações de dimensionamento para serem concluídas antes que possam aceitar tráfego.
• Standbys de luz piloto, que são parcialmente implantados em uma configuração mínima e exigem uma preparação significativa para serem concluídos antes de poderem aceitar o tráfego de produção.
• Cold standbys, que podem não ser implantados, e dependem de componentes a serem implantados antes de poderem aceitar o tráfego de produção.

Sugestão

Algumas soluções são criadas para usar uma abordagem ativo-ativo , o que significa que várias instâncias atendem solicitações. Um sistema ativo-ativo não requer failover, porque todas as instâncias estão atendendo ativamente às solicitações o tempo todo.

Escopos de failover

Situações diferentes exigem diferentes estratégias de failover. Para ilustrar essas possíveis estratégias, considere uma solução de exemplo que consiste em um aplicativo que acessa dados de um banco de dados. Configure a solução para failover criando cópias redundantes do servidor de aplicativos e várias réplicas do banco de dados. Em seguida, você configura:

• Redundância de zona colocando cópias e réplicas em diferentes zonas de disponibilidade dentro de uma região do Azure.
• Redundância geográfica usando um balanceador de carga global para failover entre regiões.

Aqui está um diagrama simplificado que ilustra a arquitetura geral em operações normais:

Situações diferentes podem desencadear eventos de failover diferentes nesta solução. Cada um deles corresponde a um escopo de failover, que representa a granularidade dos componentes que fazem failover:

• Um failover de réplica de banco de dados pode ocorrer quando a réplica de banco de dados ativa fica indisponível. A réplica passiva é promovida para se tornar a réplica ativa. Normalmente, os aplicativos podem redirecionar rapidamente suas solicitações para a nova réplica ativa:

  

• Um failover de zona de disponibilidade pode ocorrer se uma zona de disponibilidade completa sofrer uma interrupção. Esse tipo de interrupção requer que todo o tráfego seja roteado para o servidor Web na zona restante e também garante que a réplica do banco de dados na zona sobrevivente se torne a réplica ativa se ainda não estiver:

  

• Um failover regional pode ocorrer se ocorrer uma perda catastrófica de toda a região principal do Azure.

  

Embora cada um desses âmbitos forneça um tipo de failover, eles podem ter requisitos e processos de failover distintos. Além disso, a Microsoft pode ser responsável por alguns âmbitos de ativação de contingência, como quando se usam serviços com redundância de zona, enquanto você pode ser responsável por ativação de contingência em âmbitos mais amplos, como ativação de contingência entre regiões do Azure.

Planejamento de failover e continuidade de negócios

Parte da planificação de continuidade de negócios é projetar as estratégias de failover, incluindo os diferentes escopos em que a sua empresa pode fazer failover.

Geralmente, seus planos de continuidade de negócios devem incluir procedimentos de failover automatizados dentro ou entre zonas de disponibilidade. Esse tipo de failover faz parte da sua estratégia de alta disponibilidade. Por exemplo, se a réplica ativa de um banco de dados falhar, um processo automatizado poderá promover uma réplica passiva para se tornar a réplica ativa. Em seguida, os servidores Web se comunicam com a nova réplica ativa. Da mesma forma, se uma zona de disponibilidade falhar, muitas soluções serão criadas para recuperação automática usando as zonas restantes.

Diferentes procedimentos de "failover" são utilizados para cenários de desastre, como no improvável caso de uma interrupção total da região. No caso de uma interrupção de região, pode alternar as solicitações Web recebidas para usar a outra região, bem como efetuar um failover do banco de dados para uma réplica na região secundária.

Lembre-se de que incluir procedimentos de failover em seu planejamento de continuidade de negócios exige que você faça um projeto e testes mais detalhados. Para obter mais informações, consulte O que são continuidade de negócios, alta disponibilidade e recuperação de desastres?.

Failovers planeados e não planeados

Failovers não planejados são aqueles que são executados durante uma interrupção de um componente, para que você possa restaurar o serviço usando outra instância. Failovers não planejados às vezes resultam em tempo de inatividade ou perda de dados, dependendo de como uma solução é projetada. Failovers não planejados exigem algo para detetar a falha e tomar uma decisão sobre quando acionar o failover.

Por outro lado, os failovers planejados são aqueles que você aciona proativamente. Você pode fazer isso antes de algo acontecer, como uma máquina virtual que será corrigida e reinicializada. Os failovers planeados podem ter menor tolerância a tempo de paragem e perda de dados, porque fazem parte de procedimentos de manutenção regulares.

Como funciona o failover

O failover geralmente consiste nas seguintes etapas, que podem ser executadas manualmente ou por um sistema automatizado. Os detalhes específicos para cada uma dessas etapas dependem do sistema específico.

1. Detetar uma falha (somente failovers não planejados). Um failover automatizado requer que algo detete quando uma instância está indisponível, o que normalmente se baseia em algum tipo de verificação de saúde. Diferentes serviços definem a sua saúde de formas diferentes. Por exemplo, alguns serviços enviam proativamente eventos de batimento entre instâncias. Outros exigem um componente separado para sondar cada instância em um intervalo regular. Muitas vezes, demora algum tempo para os monitores de saúde detetarem que uma instância falhou e, muitas vezes, é importante dar um período de carência caso a instância esteja simplesmente ocupada e não possa responder.

2. Escolha fazer failover. Em algum momento será tomada a decisão de realizar um failover. A decisão pode ser tomada por uma ferramenta automatizada ou manualmente. A tolerância ao risco da sua organização pode afetar a rapidez com que essa decisão é tomada. Se você tem uma baixa tolerância ao risco, você pode optar por fazer failover rapidamente se houver qualquer indicação de um problema. Se você tiver uma tolerância ao risco mais alta, poderá optar por aguardar para ver se o problema pode ser resolvido antes de fazer failover.

3. Selecione uma nova instância primária. Uma das instâncias restantes deverá tornar-se a nova instância primária.

   Em algumas situações, você pode ter predefinido qual instância deve se tornar a nova principal ou pode ter apenas uma instância para a qual alternar.

   Em outras situações, há um processo automatizado pelo qual o sistema seleciona uma nova instância primária. Há uma série de algoritmos de consenso usados na computação distribuída, inclusive para a eleição de líderes. Estes algoritmos são implementados nos serviços relevantes, tais como bases de dados. Em alguns sistemas, é importante que cada instância esteja ciente da nova réplica primária e, assim, os resultados da seleção são anunciados para cada réplica automaticamente.

4. Solicitações de redirecionamento. Configure o seu ambiente para que as solicitações sejam direcionadas para as instâncias saudáveis ou para a nova instância principal.

   Para conseguir isso, talvez seja necessário atualizar outros sistemas para que eles saibam para onde enviar solicitações. Isso pode envolver a atualização de um sistema de balanceamento de carga para excluir a instância com problemas de saúde. Em outras situações, o sistema de nomes de domínio (DNS) é comumente usado como uma maneira de enviar solicitações para uma instância ativa de um sistema. Como parte do processo de failover, você normalmente precisa atualizar os registros DNS para que as solicitações sejam roteadas para a nova instância primária. O DNS tem o conceito de tempo de vida (TTL), que instrui os clientes sobre a frequência com que devem verificar se há registros DNS atualizados. Se o TTL estiver definido para um valor longo, pode levar tempo para que os clientes recebam informações sobre o failover e eles podem continuar a enviar solicitações para o primário antigo.

Como os processos de failover podem incluir atrasos, é importante planejar seus procedimentos de failover para atender aos seus requisitos de tempo de inatividade (seu objetivo de ponto de recuperação, ou RTO) e perda de dados (seu objetivo de ponto de recuperação, ou RPO). Para saber mais, consulte O que são continuidade de negócios, alta disponibilidade e recuperação de desastres?.

Retorno após falha

Failback é o processo de restabelecer e redirecionar o tráfego de volta para a instância primária original.

Em algumas situações, não é necessário fazer failback porque cada instância é igualmente capaz de atuar como a principal. No entanto, há algumas situações em que é importante fazer failback, como quando você precisa executar seus aplicativos de uma região específica do Azure e fez failover para outra região temporariamente durante uma interrupção regional.

Às vezes, o failback é tratado da mesma forma que um failover. No entanto, o failback também pode ser mais complexo do que o failover, por vários motivos:

• Problemas de sincronização de dados. Durante e mesmo depois de um failover regular, a instância primária anterior ainda pode ter executado algum trabalho ou gravado alguns dados em um armazenamento de dados. Parte do processo de failback é garantir a consistência e a integridade dos dados em toda a solução, incluindo o gerenciamento de quaisquer conflitos ou duplicações entre as instâncias primária e secundária.

  É comum que problemas de sincronização de dados exijam intervenção manual. Se você não precisar dos dados conflitantes, poderá optar por redefinir o banco de dados ou outro estado.

• Passos de remediação. Se alguma etapa de correção tiver sido tentada no primário antes do failover ocorrer, eles podem ter deixado a instância primária em um estado desconhecido.

  Se houver o risco de a instância primária estar em um estado inconsistente, talvez seja necessário destruir e reimplantar a instância primária para que ela esteja em um bom estado antes de fazer failback.

• Tempo de inatividade extra. O tempo de inatividade durante o processo de failback pode ser maior do que durante um failover devido às reconfigurações necessárias ou às operações para restaurar a consistência dos dados.

  Você pode atenuar esse problema executando processos de failback durante uma janela de manutenção ou avisando os usuários sobre a alteração com antecedência. Além disso, você pode executar algumas das operações preparatórias enquanto o sistema está on-line e minimizar o tempo de inatividade necessário.

• Tolerância ao risco. Se o failover ocorreu devido a uma interrupção, a tolerância da organização ao tempo de inatividade ou outros riscos durante o failback pode ser menor.

  As empresas interessadas devem ser mantidas informadas da situação ao longo de todo o processo e estar plenamente conscientes da necessidade de failback e das consequências dos seus procedimentos. Você pode ser capaz de negociar um momento adequado para fazer as alterações.

Mecanismos de failover e failback nos serviços do Azure

Embora seja importante entender como o failover em geral funciona, lembre-se de que cada serviço do Azure pode abordar o failover e o failback de forma diferente. Para obter informações sobre como os serviços específicos do Azure funcionam de uma perspetiva de confiabilidade, consulte o guia de confiabilidade de cada serviço.

Muitos serviços do Azure lidam com determinados tipos de failover automaticamente. Por exemplo, quando você usa serviços do Azure configurados para serem redundantes de zona, a Microsoft executa automaticamente o failover entre zonas de disponibilidade para você. Para saber mais, consulte O que são zonas de disponibilidade? e os guias de confiabilidade de serviço do Azure.

Se você usar máquinas virtuais, o Azure Site Recovery replicará máquinas virtuais e seus discos entre zonas de disponibilidade ou para outra região do Azure e poderá executar failover para você.

Quando você projeta sua própria solução que combina vários serviços do Azure juntos, seus requisitos de failover podem se tornar mais complexos. Suponha que você esteja projetando uma solução com uma camada de aplicativo e um banco de dados e queira criar uma arquitetura ativa/passiva de várias regiões. Durante uma interrupção na região primária, é importante que o aplicativo e o banco de dados façam failover para a região secundária juntos. Dependendo dos serviços exatos que você usa, talvez seja necessário planejar sua própria abordagem de failover para alternar entre as implantações em cada região. O Azure fornece roteamento de tráfego global e balanceamento de carga por meio do Azure Front Door e do Azure Traffic Manager, e você pode selecionar a tecnologia que atende aos seus requisitos de failover. Cada serviço oferece suporte ao monitoramento da integridade de cada instância regional do seu aplicativo e você pode configurá-lo para redirecionar automaticamente o tráfego para a instância íntegra.

Próximos passos

• Saiba mais sobre a responsabilidade compartilhada pela confiabilidade.
• Saiba mais sobre Recomendações para a conceção de múltiplas regiões com alta disponibilidade no Azure Well-Architected Framework.