NFS exports e mounts que falham em segurança

O NFS é uma das ferramentas mais antigas do kit de um operador de Linux, e uma das mais fáceis de acertar quase por completo. Um share que monta não é o mesmo que um share que se comporta bem quando a rede pisca, quando um cliente se porta mal ou quando o filer reinicia. Aqui ficam as definições e as verificações que fazem a diferença, de ambos os lados do mount.

Porque é que os ficheiros partilhados correm mal

A razão habitual para o NFS é um grupo de web ou application servers que têm de ver os mesmos ficheiros: media carregados, assets gerados, uma árvore de documentos partilhada. Configura-se depressa, muitas vezes copiando um exemplo, e funciona à primeira. Os problemas aparecem mais tarde. Um export aberto a toda uma rede deixa uma máquina de testes esquecida escrever em conteúdo de produção. Um cliente montado com opções que desistem perante erros perde escritas silenciosamente. Um servidor que não consegue alcançar o seu filer no boot fica bloqueado durante minutos em vez de arrancar sem o share. Nenhum destes é visível no dia em que é configurado.

No filer: exporte para nomes, faça squash do root

Exporte cada share para os hosts que precisam dele, por nome, com os direitos mais restritos que funcionem:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

Hosts nomeados, não redes. Um wildcard ou uma subnet inteira significa que todas as máquinas que alguma vez aterrem nessa rede podem montar o share. Listar os hosts faz de cada cliente uma decisão deliberada.

root_squash. O root num cliente torna-se um utilizador sem privilégios no filer. Sem isto, qualquer pessoa com root em qualquer cliente é dona de todos os ficheiros do share.

sync. O servidor confirma uma escrita só depois de ela estar gravada em armazenamento estável. A alternativa mais rápida confirma escritas que uma falha de energia ainda pode apagar.

Aplique e verifique o que está realmente exportado, que nem sempre é o que pensa ter escrito:

exportfs -ra
exportfs -v

Depois restrinja o serviço na firewall do host aos mesmos clientes. Com o firewalld, uma zona dedicada mantém-no legível:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Os exports e as regras de firewall são duas fechaduras independentes. Use ambas.

No cliente: hard mounts que não bloqueiam o boot

O lado do cliente decide o que acontece quando o filer está lento ou brevemente inacessível:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, não soft. Um hard mount tenta de novo até o servidor responder. Um soft mount devolve um erro após um certo número de tentativas, e muitas aplicações não verificam esse erro na escrita, pelo que podem perder-se dados sem que ninguém seja avisado. Se um share contém algo que lhe importa, monte-o hard. O preço é que um processo que toque no share espera enquanto o filer está ausente, que é o comportamento honesto.

_netdev e nofail. O mount espera pela rede, e um filer em falta não impede o servidor de arrancar. Em combinação com um mount timeout, a máquina sobe, a aplicação pode reportar claramente a falta do share, e o mount completa-se quando o filer regressa.

Fixe o protocolo que testou. Clientes e servidores negoceiam uma versão de protocolo. Defina explicitamente a que testou (nfsvers= ou vers=) para que uma atualização de qualquer dos lados não possa alterar silenciosamente o comportamento de locking e de caching debaixo dos seus pés.

Verifique o que foi realmente negociado, não o que pediu:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

mountstats mostra contagens por operação, retransmissões e tempos de ida e volta. Uma contagem de retransmissões a crescer é o aviso precoce de que o caminho de rede ou o filer precisa de atenção.

Redundância no cabo, snapshots no disco

Um filer só é tão disponível quanto os seus links de rede. Ligue-o com links em bond a um par de switches, faça hash do bond em endereços e portas para que ambos os links transportem tráfego, e mantenha filer e clientes no mesmo segmento Layer 2 onde puder. Um caminho comutado tem menos peças em movimento do que um encaminhado e mantém o tráfego de ficheiros dentro da rede privada.

Do lado do storage, um filesystem com checksums e snapshots muda a forma como lida com os erros. Com ZFS, por exemplo:

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

Um snapshot antes de cada deployment ou alteração em massa torna uma má alteração reversível em segundos, e um diretório de snapshots oculto permite a um administrador copiar de volta um único ficheiro sem um trabalho de restore.

Quando um file share é a resposta errada

O NFS é excelente para conteúdo escrito ocasionalmente e lido por muitos. É uma má casa para os ficheiros de dados de uma base de dados, para cargas de trabalho que fazem locking intenso entre clientes, ou para milhões de ficheiros minúsculos reescritos constantemente. Esses pertencem a block storage. Quando uma biblioteca cresce para lá do file serving, mova-a, conte e faça checksum de cada ficheiro de ambos os lados antes do cutover, e mantenha o original como rollback até a nova cópia estar provada em uso.

Uma checklist curta para os seus próprios shares

• exportfs -v lista apenas hosts nomeados, com root_squash e sync.
• A firewall permite NFS apenas a partir desses hosts.
• Cada mount de cliente é hard, com _netdev, nofail e uma versão de protocolo fixada.
• nfsstat -m em cada cliente mostra as opções que pretendia.
• As retransmissões em mountstats estão perto de zero e não crescem.
• O filer tem links redundantes, e testou perder um.
• Existem snapshots, e os backups são puxados separadamente.

Como o fazemos

Os nossos serviços de ficheiros correm em ZFS sobre volumes da nossa SAN all-flash, ligam-se por links em bond a um par de switches no mesmo segmento privado que os seus clientes, e são atualizados para um novo boot environment para que o anterior continue arrancável até a atualização estar provada.

Se o seu storage partilhado foi configurado à pressa e nunca mais ninguém olhou para ele, teremos todo o gosto em revê-lo consigo.

CTA

Fale com um engenheiro

Related

Relacionados: Serviços de ficheiros NAS, NFS e SMB · Storage SAN enterprise em HPE 3PAR, all-flash · Disaster recovery e réplicas num segundo site