Evidentemente o director é um SPOF em um cluster de balanceamento de carga. É possível utilizar, ao invés de um director um cluster de alta disponibilidade. Neste caso, de maneira semelhante à recuperação de dados em disco, temos os estados de firewall que desejamos replicar.
Isto é, se o director primário cai, todas as conexões ativas estão guardadas na memória, portanto serão perdidas. Claro que dependendo do uso, ter que reiniciar a conexão após um failover não seja muito prejudicial.
Por exemplo, se um cliente estiver fazendo uma requisição de http para uma determinada página que vai ser atendida por um serviço virtual, no caso de um failover, ele pode ter que pressionar o botão ``Recarregar'' do seu navegador. Na maioria dos casos, isto não é um grande transtorno.
No entanto, a perda de uma conexão tal como uma sessão interativa de longa duração, pode causar um transtorno muito grande se ocorrer. Neste caso gostaríamos que o director secundário, ao assumir, tivesse em memória a tabela de estados de firewall, para que as conexões iniciadas se mantivessem.
Contudo, isto é uma tarefa muito árdua para o servidor. O trabalho de um NAT é muito rápido e portanto manter a tabela de conexões gera uma grande sobrecarga.
O LVS provê um método[14] para sincronizar o estado de múltiplos directors.
Para diminuir ao máximo a sobrecarga isto é implementado dentro do kernel, de modo que não é necessário fazer trocas de contexto entre kernel e user-space.