Como detectar automaticamente o disco SATA inserido no Solaris se o status cfgadm estiver desconectado?

5

Meu objetivo é automatizar uma rotina de backup em um pequeno NAS OpenSolaris (executando o OmniOS + napp-it em um HP Microserver N54L) em combinação com discos SATA.

Histórico:

Instalei uma dessas bandejas de HDD sem portadora de 5,25 "- > 3,5" que contêm um simples backplane SATA ou SAS / SATA com uma porta, um botão liga / desliga e alguns LEDs (energia e atividade de HDD). Para fazer backup de vários HDDs (um por semana em rotação, armazenados externamente), escrevi um script que usa zfs send/recv para despejar o conjunto principal completo, incluindo todos os instantâneos (atualizando apenas novos blocos). Este script funciona bem quando eu inicio manualmente.

Eu gostaria de automatizar ainda mais esse processo, porque o NAS não tem VGA direto ou console serial conectado e é tedioso inserir o disco, voltar ao sistema desktop, fazer logon na interface web ou SSH e iniciar o script manualmente. Início temporizado via cron job não é uma opção, porque os dias de backup podem variar um pouco (esqueci o disco, feriados, etc.). Portanto, o backup deve começar logo após a inserção do disco.

Problema:

No script eu uso cfgadm para conectar + configure e depois desconfigurar + desconectar os discos. Se eu apenas inserir o disco e ele girar, não tenho como saber se o disco está lá. Possíveis soluções que já considerei:

  1. Procurando um novo disco e zpool a cada x minutos continuamente usando cfgadm -f -c connect e verificando resultados de erro. Não é muito elegante.
  2. Verificando /var/adm/messages a cada x minutos e usando grepping para o caminho do dispositivo ou AHCI. Não é possível, porque as mensagens são gravadas apenas se o dispositivo estiver conectado manualmente.
  3. Usando iostat -En . Exibe os discos, mas eu tenho que grep para os números de série exatos, porque ele não lista informações de porta. Também precisa ser feito a cada x minutos.
  4. Usando cfgadm com a sintaxe SELECT para filtrar o status do receptáculo. Não funciona, porque a inserção não ativa nada (talvez o backplane seja muito barato para isso).
  5. Reconhecendo a energia ligada / desligada do gabinete. Tudo bem, mas não consegui descobrir como fazer isso.
  6. Remapeando o botão liga / desliga ou adicionando outro botão à máquina. Poderia funcionar, mas também não sei como fazer isso.

Acho que precisaria de duas coisas:

  • uma maneira confiável de identificar o status do disco e da porta em combinação (para que apenas o disco correto no slot correto seja detectado)
  • uma maneira de registrar essa detecção e acionar um evento (iniciar o shell script)

Isso é possível? Se não, o que você sugeriria como alternativas?

Solução final (atualizada em 2015-01-26):

Para qualquer pessoa com problemas semelhantes no futuro:

  1. Ative o hotswap do AHCI no OmniOS, conforme detalhado em a resposta aceita por gea.
  2. Use syseventadm conforme detalhado na minha própria resposta para acionar o script de backup quando o disco ficar on-line.
  3. Verifique se os cabos, controlador e discos estão livres de falhas e funcionam bem juntos (tive problemas com discos WD SE 4TB e o controlador AHCI SATA integrado, o que resultou em mensagens WARNING: ahci0: ahci_port_reset port 5 the device hardware has been initialized and the power-up diagnostics failed aleatórias nos registros do sistema). / li>
por user121391 21.01.2016 / 14:41

3 respostas

3

Onboard Sata / AHCI é compatível com hotplug, mas isso está desabilitado no OmniOS por padrão: Para ativar, inclua a seguinte linha em / etc / system

set sata: sata_auto_online = 1

    
por 22.01.2016 / 11:05
1

Pergunta interessante ... um pouco de experimento científico, já que provavelmente usaria USB ou enviaria remotamente ou teria isso em um agendamento ...

Mas no seu caso, eu não tentaria "procurar" o disco de uma forma cfgadm ou de análise de log. Isso não é escalável.

Eu simplesmente nomearia o disco removível com um nome exclusivo do pool do ZFS e uma lógica de script em torno de um zpool import periódico. No ZFS no Linux, o processo de importação do pool é um serviço / daemon de sistemas. Mas não há custo para executá-lo periodicamente. Ele detectará a unidade e o pool associado.

Espero que você esteja exportando o pool quando terminar o backup. Isso cobriria situações em que a unidade permanece no servidor por vários ciclos de backup. Como deixar uma fita de backup em sua unidade.

    
por 21.01.2016 / 14:51
1

Adicionarei essa resposta para documentar o que descobri sobre eventos de monitoramento (também pode ser útil em outros casos):

Ao tentar fazer a pergunta no unix / linux.SE, notei um tópico útil sobre o uso de udev no Linux para monitorar eventos do kernel. Como ferramentas equivalentes para o Solaris, eu deparei com a sugestão de usar syseventadm que assiste a sysevents e aciona ações / scripts definidos.

No começo eu não encontrei muito, exceto cópias da página man e algumas discussões sobre um problema com o Xen Hypervisor, mas os eventos suportados estão listados em /usr/include/sys/sysevent/eventdefs.h (ou online em /usr/src/uts/common/sys/sysevent/eventdefs.h em vários repos) e outros arquivos nesse diretório.

Usando o primeiro exemplo da manpage e syseventadm add -c EC_zfs -s ESC_ZFS_scrub_start /path/to/script.sh \$pool_name testei com êxito um evento de amostra que é acionado toda vez que uma depuração é iniciada e retorna o nome do pool como primeiro argumento.

Depois de algumas tentativas e erros, encontrei a maneira correta de monitorar discos recém-adicionados:

syseventadm add -c EC_dev_add -s disk /path/to/script.sh \$version \$dev_name \$phys_path \$driver_name \$instance
syseventadm restart

Tudo depois de disk é opcional e passou diretamente para o script como argumentos $1 to $5 .

Agora, assim que o disco recém-adicionado estiver on-line, o script será acionado e o script poderá verificar se o ID do dispositivo está correto (opcional) e, em seguida, importar o pool pelo nome.

    
por 22.01.2016 / 14:36