Eu gerencio um pequeno "cluster" de 4 máquinas Xeon com placas Intel no meu laboratório. Eles estão todos conectados a um switch 3-Com de 5 portas com endereços IP estáticos como 10.0.0.x .
Eles estão todos executando OpenSuse 11.4 e seus /home/ são veiculados por uma das máquinas ( node00 ) via NFS . Eles estão conectados a um no-break que pode mantê-los por cerca de 15 minutos, mas há muita escassez elétrica devido à "manutenção não programada" que é mais longa que isso. Então eles acabam sendo desligados sem aviso prévio.
Se eu configurar o BIOS para ativá-los após falta de energia, o problema é que todos eles são inicializados ao mesmo tempo e, se node00 decidir executar fsck na partição /home/ , ele não concluir a inicialização antes os outros tentam montar o NFS em /home/ .
Estou tentando fazer o wake on lan funcionar, então posso escolher inicializar os clientes NFS somente depois que o servidor inicializar com êxito. O problema é que quando eu executo ethtool eu recebo uma saída assim:
Supports Wake-on: pumbag
Wake-on: g
Teoricamente, é definido como wake on MagicPacket(tm) , de acordo com o manual. Mas o envio do pacote WOL usando wol -i 10.0.0.255 $MACADDR não ativa a caixa depois que eu a encerro com halt . O led de link ethernet pisca após eu enviar o pacote, então aparece para chegar na máquina.
No entanto, se eu configurá-lo com ethtool -s eth1 wol bag , a máquina sempre acorda logo após parar, mesmo se eu não enviar o pacote de Magic. Isso significa que o dispositivo pode ativar a atividade da LAN, mas parece estar ignorando o pacote mágico. A configuração wol ag não ativa a caixa com o MagicPacket.
Configurar wol a significa que ele deve inicializar com qualquer mensagem de broadcast?
Como posso diagnosticar o problema de a máquina não acordar com o MagicPacket mesmo que eu esteja enviando-o e ele esteja configurado para acordar com ele?
Obrigado antecipadamente!