systemd não desmonta compartilhamentos NFS antes de parar a rede

3

Contexto:

  • RHEL 7.2 até dia como para outubro de 2016
  • Sistema físico
  • NetworkManager desativado
  • Rede configurada através do agrupamento de NICs 2x10G (eth0 & eth1) como lacp0
  • (irrelevantes) os endereços IP são configurados nas subinterfaces VLAN lacp0.XXX e lacp0.YYY
  • (também irrelevantes) Esses sistemas são destinados a serem nós do Oracle 12c

A conectividade de rede é 100% OK, os benchmarks confirmam que o LACP é totalmente funcional e se aproxima do máximo teórico de 20 GBps.

Problema:

O systemd não detecta que a pilha de rede é interrompida durante o desligamento e espera até muito tarde para desmontar compartilhamentos NFS e, portanto, falha em desmontá-los, o que leva a uma interrupção indefinida para o servidor NFS responder.

Sintoma (s):

Depois de executar "systemctl stop network.service", tanto network.target quanto network-online.target ainda são considerados ativos .

O que eu vim até agora:

As montagens do NFS adicionadas por meio do arquivo /etc/fstab são convertidas em *.mount systemd units. Essas unidades dependem automaticamente de remote-fs.target , que depende de 'network-online.target'.

De a documentação , parece rede *. target depende de uma ferramenta de gerenciamento de rede para detectar se a rede está ativa e tal. Isso pode ser NetworkManager , systemd-nerworkd ou qualquer outra coisa (mas o quê?). Eu acho que o meu problema pode estar aqui, pois parece que o nosso modelo de jumpstart depende dos antigos scripts init para gerenciar as interfaces. E duvido que o systemd possa interagir com ele para ser informado de que a rede está ativa ou inativa (apesar de ter sido usada para parar a pilha da rede com systemctl stop network )

Minha segunda hipótese é que a formação de equipes de rede usando libteam / teamd, mesmo através de arquivos ifcfg- *, está fora do escopo systemd network.target. Parece não haver dependência entre as unidades do sistema (incluindo [email protected]) e as unidades de rede. Isso explicaria por que os únicos sistemas que exibem esse problema são aqueles sistemas habilitados para LACP e não tivemos o problema antes quando usamos bonding típico.

Então, minha pergunta: qual solução devo ter para garantir que meus compartilhamentos NFS sejam desmontados antes que minha pilha de rede seja desativada, normalmente ao reinicializar o sistema?

PS: seria melhor se a dita solução não viesse do caminho para criar montagens NFS, de modo que alguém que tivesse que adicionar uma parte a esse servidor não precisasse ser informado das etapas especiais a serem tomadas. Isso parece quase impossível, considerando o nosso processo de produção.

    
por mveroone 11.10.2016 / 17:12

1 resposta

0
Infelizmente, a única resposta "certa" para este problema parece estar usando uma ferramenta de gerenciamento de rede que, por enquanto, é NetworkManager (melhor prática do Red Hat) ou systemd-networkd .

A solução alternativa que usamos para evitar o uso do NetworkManager é esta:

Edite o /etc/systemd/system/[email protected]/override.conf

[Unit]
Before=remote-fs.target

[Install]
WantedBy=network-online.target

[Service]
ExecStop=/bin/bash -c "while grep ' nfs ' /proc/mounts; do sleep 5; done"
TimeoutStopSec=30

Este arquivo será concatenado ao modelo do sistema de qualquer arquivo teamd@<teamname>.service as /etc/systemd/system/* tem precedência sobre /usr/lib/systemd/system/

Ao parar, o systemd iniciará as desmontagens do NFS primeiro, mas, por padrão, não esperará que elas sejam concluídas. Em seguida, forçamos o teamd @ .service, que é responsável pela conectividade de rede, a esperar no máximo 30 segundos para que os compartilhamentos do NFS sejam desmontados antes de matar daemons do teamd e continuar com o processo de desligamento.

Referências:

por 20.10.2016 / 14:46