Respostas>Saiba mais sobre fiabilidade e tempo de atividade>O que é o failover?
O que é failover?
// Tags
failoverfailover automático
Resumo: O failover é o processo automático de mudança de um componente com falha para um backup em bom estado, sem interromper o serviço. Na infraestrutura de blockchain, o failover garante que, quando um nó, servidor ou centro de dados fica inoperacional, os pedidos RPC da sua aplicação sejam redirecionados de forma transparente para outro endpoint em funcionamento.
O Conceito Básico
Imagina que estás a conduzir numa autoestrada e que a faixa principal fica subitamente bloqueada. Se não houver um percurso alternativo, ficas preso. Mas se o sistema da autoestrada te redirecionar automaticamente para uma faixa paralela sem que sequer te apercebas, isso é o failover em ação.
Em termos de infraestrutura, o failover é o mecanismo que deteta quando algo falha e redireciona imediatamente o tráfego para um sistema de reserva. O objetivo é uma interrupção nula (ou near ). A sua aplicação continua a efetuar pedidos, a receber respostas e a funcionar normalmente, mesmo que o componente que atende esses pedidos tenha acabado de mudar nos bastidores.
How Failover Works in Blockchain Infrastructure
Blockchain infrastructure has a specific set of components that can fail. The most common are individual nodes, entire regions or data centers, and specific blockchain client implementations. A good failover system handles all three.
At the node level, failover is relatively straightforward. A load balancer continuously monitors the health of every node in the pool, checking response times, error rates, and block height. If a node starts returning errors or falls behind on sync, the load balancer stops sending it traffic and distributes requests across the remaining healthy nodes.
At the regional level, things get more interesting. If an entire data center or cloud availability zone experiences an outage, DNS based failover kicks in. Requests that would normally route to that region are automatically redirected to the next nearest healthy region. This is why geographic distribution matters. A provider running nodes in only one region has no fallback when that region goes down.
At the client level, some providers run multiple blockchain client implementations (for example, both Geth and Erigon for Ethereum). If one client implementation has a bug or performance issue, traffic can shift to nodes running the alternative client. This layer of redundancy is less common but increasingly important.
Failover ativo vs. passivo
Existem duas abordagens gerais ao failover, e essa distinção é importante para o desempenho.
In active active configurations, all backup components are already running and handling traffic. When one fails, the others simply absorb its share of the load. There's no "cold start" delay because everything is already warm. This is the preferred model for blockchain infrastructure because nodes need to stay synced with the chain. A node that isn't actively processing blocks will be behind on block height and useless until it catches up.
In active passive configurations, backup components sit idle until needed. When the primary fails, the passive backup activates and takes over. This is cheaper to operate but introduces a delay. For blockchain nodes, this delay can be significant because the passive node may need to sync blocks before it can serve accurate data.
A maioria das infraestruturas de blockchain em produção utiliza o failover ativo-ativo precisamente por esta razão. Não se pode dar ao luxo de esperar que um nó «frio» se sincronize quando o seu protocolo DeFi necessita de precisão de dados em frações de segundo.
A tabela abaixo resume a comparação entre os dois modelos de failover para cargas de trabalho de blockchain:
Aspecto
Ativo-Ativo
Ativo-Passivo
Estado da cópia de segurança
All nodes running and serving traffic
Standby nodes idle until needed
Atraso na comutação de emergência
Near , sem arranque a frio
É importante notar que o sistema de backup tem de ser inicializado e sincronizado
Custo operacional
Acima disso, paga-se pela capacidade total
Em modo de espera, o consumo de recursos é menor.
Sincronização da altura do bloco
Sempre atualizado
Pode ficar para trás e precisar de recuperar o atraso
Ideal para
RPC de produção e dados em tempo real
Cargas de trabalho sensíveis ao custo ou não críticas
Why Failover Is Non Negotiable for Blockchain Apps
As aplicações web tradicionais conseguem, muitas vezes, tolerar breves interrupções. Basta o utilizador atualizar a página para que tudo volte a funcionar. As aplicações de blockchain não têm esse luxo, por várias razões.
As transações são sensíveis ao tempo. Se a sua aplicação enviar uma transação e o endpoint RPC endpoint a meio do pedido, essa transação poderá perder-se ou ser enviada duas vezes. Os dados desatualizados são perigosos. Um nó que esteja atrasado na altura do bloco devolve informações desatualizadas. Se a sua aplicação ler um saldo desatualizado e agir com base nele, as consequências podem ser financeiras. Os eventos são irreversíveis. Ao contrário dos sistemas tradicionais, onde é possível repetir a tentativa ou reverter a ação, as ações na chain são permanentes. Enviar fundos com base em dados incorretos provenientes de um nó com falha não é algo que se possa desfazer.
É por isso que o failover não é uma funcionalidade opcional. É um requisito fundamental para qualquer aplicação que interaja com uma blockchain em produção.
Como Quicknode a transição para o sistema de reserva
A infraestrutura Quicknode utiliza failover ativo-ativo em mais de 14 regiões e vários fornecedores de serviços na nuvem. Cada pedido é encaminhado através de uma camada global de equilíbrio de carga que avalia continuamente o estado dos nós, incluindo o estado de sincronização da altura do bloco, a latência de resposta e as taxas de erro. Se algum nó ou região apresentar uma degradação no desempenho, o tráfego é automaticamente redirecionado para a melhor opção seguinte, sem que seja necessária qualquer ação por parte do programador.
For teams that need the strongest guarantees, dedicated clusters provide isolated infrastructure with custom failover configurations and guaranteed uptime SLAs.
Qual é a diferença entre failover e balanceamento de carga?
Failover and load balancing are closely related but solve different problems. Load balancing spreads incoming requests across a pool of healthy nodes so no single node is overwhelmed. Failover is what happens when one of those nodes stops being healthy: traffic is pulled from the failed node and redistributed to the rest. In practice the two work together, and a strong high availability setup needs both running side by side.
Capacidade
Equilíbrio de carga
Failover
Função principal
Distribuir o tráfego de forma uniforme
Desviar o tráfego das falhas
Quando entra em ação
De forma contínua, em cada pedido
Apenas quando um componente se deteriora ou avaria
Objetivo principal
Desempenho e utilização uniforme
Continuidade e tempo de atividade
Trigger
Volume de pedidos
Falha na verificação de integridade
O que se considera um único ponto de falha?
Um ponto único de falha é qualquer componente que, ao avariar, provoque a paragem de todo o sistema. Um nó isolado, uma única região na nuvem ou uma implementação de cliente podem, cada um deles, tornar-se um ponto único de falha. O failover elimina estes pontos fracos, mantendo sempre uma alternativa em bom estado pronta para assumir o controlo. Analisar os modos de falha mais comuns da blockchain é a forma mais rápida de identificar os pontos únicos de falha que se escondem na sua pilha de tecnologias.
Como se verifica se o failover está a funcionar?
A failover é avaliada através de alguns indicadores concretos. O tempo de atividade mostra com que frequência o serviço esteve acessível, o tempo de recuperação indica quanto tempo demorou o tráfego a ser redirecionado após uma falha e a taxa de erros durante um incidente revela quantas solicitações foram afetadas antes de a transição estar concluída. É o monitorização contínua da sua infraestrutura de blockchain que revela estes números, para que possa confirmar se a failover está a funcionar corretamente.
Como é que se pode testar o failover antes de uma falha real?
The only way to trust failover is to rehearse it. Teams deliberately take a node or region offline in a controlled window and confirm that traffic reroutes without errors, an approach often called chaos testing. If you run your own nodes, you can stop a process and watch where requests go. If you rely on a managed provider such as the Quicknode Core API, failover is handled for you, though you can still validate it with cross region load tests.
Perguntas frequentes
O que é o failover, em termos simples?
Failover is the automatic switch from a broken component to a working backup so a service keeps running. Most of the time the user never notices the switch happened.
O failover é o mesmo que redundância?
Não. Redundância significa ter componentes de reserva prontos, enquanto o failover é o processo que redireciona o tráfego para esses componentes de reserva quando algo falha. É necessário dispor de redundância na infraestrutura para que o failover funcione.
Quanto tempo demora o failover?
Nos sistemas ativo-ativo, a transição em caso de falha é frequentemente near , uma vez que os sistemas de reserva já estão a processar o tráfego. Nos sistemas ativo-passivo, o processo pode demorar entre alguns segundos e vários minutos, enquanto o sistema em espera entra em funcionamento e se sincroniza.
O failover evita todas as interrupções de serviço?
O failover reduz drasticamente o tempo de inatividade, mas não pode garantir a ausência total de interrupções em todas as situações. Uma infraestrutura ativa-ativa bem concebida, distribuída por várias regiões, aproxima-se bastante desse objetivo, razão pela qual é o padrão para aplicações de blockchain em produção.
Why does failover matter so much for blockchain apps?
As operações em blockchain são sensíveis ao tempo e, muitas vezes, irreversíveis; por isso, uma endpoint com falha endpoint perder uma transação ou devolver dados desatualizados. O failover automático protege tanto a fiabilidade como os fundos dos utilizadores, o que é fundamental para serviços baseados em streams de dados em tempo real.
