O NFS redundante (na verdade, qualquer armazenamento redundante) não é trivial.
Planeje gastar uma boa quantidade de tempo (e capital) nisso, se você realmente quiser que ele funcione bem.
Geralmente, há duas opções disponíveis para você:
Opção 1: comprar dispositivos de armazenamento redundantes
Esta é a opção mais rápida (e geralmente mais cara). Escolha um fornecedor que cria um dispositivo de armazenamento com recursos de redundância que atendam às suas necessidades, forneça o cartão de crédito da empresa e tente não chorar na fatura.
Os dois principais benefícios dessa rota são que ela é rápida (você obtém uma solução pré-construída que pode ser implementada seguindo o manual) e ela é suportada (se você tiver um problema, chame o fornecedor e grite até corrigir isso.
Opção 2: construa você mesmo
Este site tem um bom esboço de construção de um cluster iSCSI / NFS redundante usando o Debian Linux . É de 2009, mas os princípios são sólidos.
Instruções passo a passo específicas sobre como criar esse tipo de ambiente estão além do escopo do Server Fault, mas posso fornecer um esboço do que você precisará:
-
Armazenamento compartilhado (ou replicado)
Para ter redundância em sua camada de armazenamento, você precisa ter os mesmos dados acessíveis em vários locais - replicando-os em tempo real ou conectando tudo a um conjunto compartilhado de discos. Uma SAN é a maneira usual de atender ao requisito de armazenamento compartilhado. Este ainda é um ponto único de falha, mas quando você coloca todos os ovos em uma dessas cestas, você se certifica de que é uma cesta MUITO boa.
A replicação DRBD ou ZFS pode atender ao requisito de armazenamento replicado se você optar por seguir esse caminho - provavelmente é mais barato que uma SAN, e as duas tecnologias se desenvolveram para um estado muito confiável. -
Vários sistemas "front-end"
Agora que você tem o armazenamento funcionando, você precisa torná-lo acessível através de sistemas redundantes de "front-end" - estas são as máquinas que estão executando o servidor NFS (ou o que você usa para servir o disco aos clientes). Você precisa de pelo menos dois, executando um software de alta disponibilidade / failover, portanto, se / quando você perder um, o outro poderá assumir o controle. O failover de IP é a opção "fácil" aqui (se uma caixa cair, a outra assume o endereço IP "ao vivo"). -
Vários caminhos físicos para armazenamento
Toda a redundância de armazenamento no mundo não ajuda se tudo passar por um fio.
Você precisa garantir que as máquinas clientes tenham vários caminhos físicos para retornar aos front-ends de armazenamento, caso contrário, um switch com falha deixa você com a mesma situação de ponto único de falha da qual você está tentando sair.
Construir seu próprio armazenamento redundante geralmente leva mais tempo do que uma solução de fornecedor, e você mesmo o suporta (o que significa que você precisa estar confortável com a tecnologia envolvida). As principais vantagens são o custo (muitas vezes você pode criar o ambiente mais barato do que as soluções fornecidas pelo fornecedor) e a flexibilidade (você pode adaptar a solução para atender às suas necessidades e integrar-se a outras partes do ambiente - por exemplo, seu sistema de backup).
Coisas que você precisa de qualquer forma
Você precisará de um plano de teste * antes de iniciar a produção.
Idealmente, você deve tê-lo antes mesmo de começar o seu build-out (sabendo que as falhas que você está defendendo o ajudarão a projetar seu sistema).
Seu objetivo no teste é demonstrar que a pior confluência absoluta de falhas não o deixará em uma posição em que você esteja perdendo dados (e, idealmente, não causará uma interrupção porque seu armazenamento ficou inacessível). Você não pode encontrar ou testar todos os possíveis cenários de falha, mas anote todos os que você possa imaginar e certifique-se de testá-los. Você não quer esperar até que seu primeiro dia de produção ao vivo seja usado para descobrir que perder um disco na máquina em espera pode causar a falha do primário - nesse ponto, é muito tarde para corrigir.