Depurando um problema de rede do Solaris

3

Estou executando um servidor de arquivos Solaris 11 x86. A parte do servidor de arquivos é o ZFS + Samba. Está funcionando há três ou quatro anos sem grandes problemas.

Os compartilhamentos do Samba começam visíveis para outros PCs na rede. Eu posso ler a partir do servidor de arquivos de forma confiável. Eu posso pingar o servidor. Eu posso pingar outros PCs do servidor. Eu posso pingar o gateway padrão do servidor.

A partir de algumas semanas atrás, quando tento gravar no servidor de arquivos, os compartilhamentos desaparecem após alguns segundos (ou talvez depois de algumas centenas de megabytes). A questão é aparentemente com a rede. O servidor ainda está vivo, no entanto. Se eu conectar um mouse, teclado e monitor, ainda posso interagir com o servidor.

Não parece que o problema seja com os discos rígidos ou com o Samba. Tentei:

  • zpool status
  • fmadm com defeito
  • svcadm restart samba

Sem erros. Nenhum dispositivo defeituoso. O samba não parece ser o problema.

Após o problema acontecer, não consigo mais executar ping no gateway padrão do servidor de arquivos. Não consigo mais pingar outras máquinas do servidor de arquivos. Não consigo fazer ping no servidor de outras máquinas.

Etapas de depuração de rede

Eu tentei:

  • ifconfig skge0 inoperante / ifconfig skge0 up.
  • Ligue e desligue o comutador no qual a caixa Solaris está conectada
  • Ligar e desligar o roteador no qual a caixa do Solaris está conectada

A caixa Solaris parece achar que ainda está conectada à rede. Redefinir a caixa Solaris (init 6) trará os compartilhamentos de volta, mas somente até eu tentar escrevê-los novamente.

Eu tentei netstat -rn antes e depois do problema. Tudo parece bem normal. Abaixo está "depois":

Routing Table: IPv4
Destination           Gateway           Flags  Ref     Use     Interface 
-------------------- -------------------- ----- ----- ---------- --------- 
default              10.1.10.1            UG       27        456 skge0     
10.1.10.0            10.1.10.254          U         6    2536350 skge0     
127.0.0.1            127.0.0.1            UH        2        252 lo0       

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If   
--------------------------- --------------------------- ----- --- ------- ----- 
::1                         ::1                         UH      2       4 lo0   

"Antes" tem 27 em vez de 17 na coluna "Ref" da primeira entrada. "After" tem números ligeiramente maiores para "Use" - provavelmente normal.

Eu testei o netstat -an antes e depois do problema também. Este pode ter mais de uma pista. Existem várias conexões UDP presentes antes do problema que desaparecem.

Antes:

UDP: IPv4
   Local Address        Remote Address      State
-------------------- -------------------- ----------
    --truncated entries that are present in both before/after--
10.1.10.254.40504    10.1.10.1.53         Connected
10.1.10.254.39900    10.1.10.1.53         Connected
10.1.10.254.40129    10.1.10.1.53         Connected
10.1.10.254.37892    10.1.10.1.53         Connected
10.1.10.254.61658    10.1.10.1.53         Connected

Depois, essas cinco entradas acabaram, mas uma nova está presente:

UDP: IPv4
   Local Address        Remote Address      State
-------------------- -------------------- ----------
    --Again, truncated--
10.1.10.254.53920    10.1.10.1.53         Connected

Não consigo encontrar nenhuma informação sobre o que a porta 53920 é usada. No lado do gateway, a porta 53 parece ser usada para DNS - não tenho certeza se isso é uma pista ou não. Não parece muito útil

Abaixo da porção TCP, há um monte de entradas que são "ESTABELECIDAS" antes que foram eliminadas em após ou foram transferidas para TIME_WAIT ou FIN_WAIT_1. Isso parece jiver com o que eu já sei.

Há apenas uma referência ao IP do computador que usei para travar a rede:

Antes:

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
10.1.10.254.445      10.1.10.132.53487    64512      0 128480      0 ESTABLISHED

Depois:

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
10.1.10.254.445      10.1.10.132.53487    64256      0 128480      0 ESTABLISHED

A única diferença está na coluna Swind (enviar janela?). É estranho que o estado ainda esteja listado como estabelecido.

Eu fiz o netstat - um experimento novamente

A única diferença antes e depois estava relacionada ao endereço IP do computador que usei para travar o compartilhamento.

Antes:

TCP: IPv4
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q    State
-------------------- -------------------- ----- ------ ----- ------ -----------
10.1.10.254.445      10.1.10.132.53613    380416      0 128480      0 ESTABLISHED

Depois:

10.1.10.254.445      10.1.10.132.53613    65280       0 128480      0 ESTABLISHED

Mais uma vez, a única diferença está na coluna Swind - o número ficou menor.

Cheguei ao final do que sei sobre esse tipo de coisa. O netstat parece estar me dizendo o que eu já sei. Antes de comprar outra placa de rede e apenas tentar, ou reinstalar o Solaris, não tenho ideia. Alguém pode me dar pistas sobre o próximo passo aqui?

Editar

Estou comprando outra placa de rede e apenas tentando. Vai demorar cerca de uma semana para chegar aqui, então vou continuar cutucando isso enquanto isso.

    
por Pete Baughman 27.07.2014 / 03:10

3 respostas

2

Netstat -an , netstat -rn e lsof (antes e durante o problema) podem fornecer pistas. (Eles mostram muitas conexões abertas?). tcpdump pode ajudar também: inicie-o antes de estabelecer a conexão e veja o que acontece quando as conexões começam a morrer (e também alguns minutos antes dos tempos limite).

E veja se as opções do NFS não são padrão e podem ter efeitos:

  • Tente usar configurações suaves em vez de rígidas, por exemplo.

  • Remova todas as opções "non-core" (core sendo aquelas que são necessárias para o NFS serem estabelecidas) e coloque-as de volta aos poucos, para ver qual (is) está (estão) causando questão.

Desculpe, mas não tenho acesso no momento a um Solaris para fornecer as configurações exatas. Uma pesquisa na Web incluindo as palavras-chave "Solaris" e "NFS" ajudará você a encontrá-las.

    
por 27.07.2014 / 07:30
2

Eu observei que executar o Samba em cima de conjuntos de dados ZFS exportados pode resultar em um desempenho muito ruim, incluindo até o ponto de eliminar sessões interativas no servidor ou no cliente. No entanto, usando o CIFS interno do Solaris 11 (e posterior) server é uma muito melhor solução - você está fazendo os bits de protocolo dentro do kernel ao invés de no espaço do usuário.

Eu esqueci a sintaxe exata a ser usada, você deve ler tfm para zfs (1m) e procurar por 'smb'. Também dê uma olhada no zfs_share (1m).

    
por 29.08.2014 / 06:22
0

Você tem mantido seu sistema Solaris 11? O que pkg info entire e pkg publisher mostram?

Eu também vejo você notar usando uma interface skge. Eu não sabia, então eu olhei para cima. Não foi possível encontrar um pacote no repositório do Solaris (SPARC) para ele. Mas achei que o Google encontrou blogs e discussões de pessoas tentando fazer com que o driver de rede funcionasse no Solaris. Ou usá-lo em vez de o dispositivo não ser compatível. Então você vai querer tentar uma pesquisa para aqueles que você não tenha já.

Ref: Lista de compatibilidade de hardware (HCL) do Solaris

    
por 18.01.2017 / 23:58