NFS atrás de uma VPN: montagem no arranque ou montagem automática a pedido?

Duas configurações resolvem o mesmo problema e falham em direções opostas. Montar a partilha no arranque dá a cada serviço um sistema de ficheiros que ou está lá, ou explica porque razão o arranque parou. Uma montagem automática a pedido dá à máquina um arranque rápido e passa a espera a quem tocar no caminho primeiro. Atrás de uma VPN, a segunda é normalmente a melhor troca, e a razão é que o túnel impõe uma ordem que a sequência de arranque não consegue ver.

Montagem no arranque contra montagem automática

Uma montagem no arranque é simples de raciocinar. O alvo do sistema de ficheiros espera pela montagem, os serviços que declaram uma dependência dela arrancam depois, e se o servidor estiver inacessível a máquina ou espera ou falha consoante as opções. Tudo o que vem a jusante herda essa única decisão.

Uma montagem automática inverte isso. O caminho existe de imediato, a montagem real acontece quando algo o abre, e os serviços que arrancam cedo não ficam bloqueados num túnel que ainda não subiu.

A comparação resume-se a quem deve absorver o atraso. Uma estação de trabalho que precisa da partilha antes de o utilizador poder trabalhar provavelmente deve esperar. Um portátil que arranca dentro de uma mochila, ou um servidor cuja partilha é opcional, não deve.

Nenhuma das opções corrige uma rota em falta. Ambas apenas decidem quando a falha é observada.

A linha de fstab, opção por opção

Suponha que uma instância de cliente OpenVPN existente é [email protected], que o servidor é files.corp.example e que o ponto de montagem é /mnt/work. Substitua os três pelos valores autorizados do seu próprio site. Uma linha que funciona é assim:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev marca a montagem como necessitando de rede, e não nomeia túnel nenhum. nofail mantém a partilha opcional para o alvo normal do sistema de ficheiros. x-systemd.automount cria o acionador a pedido em vez de montar de imediato.

x-systemd.requires= é a parte que liga a tentativa de montagem à unidade de VPN, e pertence à operação de montagem, não ao acionador. Pôr uma ordem ampla na própria unidade de montagem automática é a forma como as pessoas criam ciclos de que o systemd depois se queixa numa língua que ninguém lê duas vezes.

x-systemd.mount-timeout=30s limita o comando de montagem inicial. Não limita nada do que acontece depois, e esse é o mal-entendido mais comum sobre esta opção.

O que «iniciado» não significa

Verifique o que ativo significa para a unidade de VPN que indicou. Um serviço de túnel pode declarar-se iniciado antes de existir a rota para o servidor de ficheiros ou antes de o nome privado resolver, e ordenar depois disso não lhe compra nada. É nesta lacuna que vive quase todas as tentativas falhadas. Também é invisível a menos que olhe para a rota e o resolvedor em vez do estado da unidade.

Use o próprio sinal de prontidão do dono da ligação como pré-requisito adicional onde exista. Uma espera fixa é um palpite que funciona na sua secretária e falha numa rede mais lenta ou após uma reconexão.

Inspecione as unidades geradas para o caminho do exemplo: mnt-work.automount e mnt-work.mount. Após uma alteração de fstab revista, recarregue o systemd e geri essas unidades diretamente em vez de executar um comando de montagem genérico que exercita entradas não relacionadas.

Cabe aqui mais um aviso. Um serviço que toca em /mnt/work no arranque continua a acionar a montagem e continua a esperar por ela, por isso marcar a partilha como opcional não torna todas as aplicações pacientes.

Depois da montagem a falha é outra

Uma vez montado o NFS, o comportamento de repetição e recuperação do sistema de ficheiros governa o que uma falha posterior faz a uma leitura ou a uma escrita. O tempo limite de montagem que definiu não tem influência nisso.

Uma montagem suave encurta algumas esperas e altera a semântica dos erros, com consequências para a integridade dos dados fáceis de ignorar quando o objetivo é um arranque mais rápido. Escolhê-la para ganhar dois segundos de arranque raramente é uma boa troca. Se o requisito é mesmo uma operação limitada durante uma falha, isso é uma decisão ao nível da aplicação, não um indicador de fstab.

Decida o que deve acontecer a um processo que está a meio de uma escrita quando o túnel cai, e escreva-o. Essa resposta é mais útil do que qualquer cadeia de opções.

Teste quatro estados, não um

Um arranque normal com o túnel disponível é o caso fácil e não prova quase nada. Confirma que a cadeia está escrita corretamente e mais nada. Teste o primeiro acesso sem a VPN, depois a recuperação quando sobe, depois uma falha controlada após uma montagem bem-sucedida.

Quatro estados, quatro observações, e as notas vão ao lado da entrada de fstab. A pessoa seguinte herda comportamento em vez de uma configuração que tem de reconstruir.