Introdução
Estou tendo um problema com alguns servidores (CentOS 6.4) em um ambiente de produção, o problema é fazer com que os servidores travem de tempos em tempos e precisamos realmente reinicializar esses servidores para poder usá-los novamente .
O problema
O problema é que, às vezes, após a reinicialização, os servidores realizam uma verificação forçada do sistema de arquivos e, quando ele falha, alguém precisa ir fisicamente ao servidor e executar um FSCK manualmente.
A questão
Existe uma maneira de inicializar o sistema quando essas verificações forçadas não conseguem acessar os servidores por meio do SSH? Ou existe outra solução para ter uma verificação regular do sistema de arquivos e acesso SSH ao servidor.
Obrigado antecipadamente!
Primeiramente, use alguma conectividade do console remoto que não seja dependente do sistema operacional. Para a Dell é o iDRAC, para a HP é o iLO, para a IBM é o RSA2, etc. Esta é a prática padrão, porque você pode ter muitos outros erros de inicialização além do fsck.
Em segundo lugar, consulte a pergunta do fsck automatizado . Mas se você está fazendo isso "automação", verifique se você testou seus backups. Com isso, seu fsck passará e você poderá se conectar via ssh.
Eu me concentraria em encontrar a causa do problema inicial. A corrupção do sistema de arquivos é outro sintoma, juntamente com as máquinas parando de responder, ou você está executando uma reinicialização não segura (um ciclo de energia) ou ambos.
Você não diz como seus sistemas de arquivos estão organizados e quais estão ficando corrompidos. Se você tem um sistema de arquivos raiz muito pequeno com quase tudo o mais como montagens separadas ( /sbin , /etc e algumas outras coisas precisam ficar na raiz fs em geral) e as coisas que fsck está pegando estão no Se você estiver familiarizado com scripts de shell, você pode ajustar o processo de inicialização de tal forma que
/ fazem com que bloqueie / é verificado e está pronto Dessa forma, você pode usar ssh para corrigir os outros sistemas de arquivos e iniciar uma reinicialização limpa para colocar as coisas em ordem.
Existem opções para definir fsck para tentar corrigir automaticamente os problemas (a maioria não é grave se forem causados por uma reinicialização insegura, especialmente com sistemas de arquivos com journalled), mas isso geralmente não é recomendado em ambientes de produção, pois pode ocultar problema crescente. Em Debian / Ubuntu / similar procure pela opção FSCKFIX em /etc/default/rcS , os resultados são registrados em /var/log/fsck/checkfs if /var estava em um sistema de arquivos que foi montado com sucesso read-write - algo similar existirá no CentOS também. / p>
Se você realmente quiser voar pelo assento da sua calça, defina pasnum para tudo em /etc/fsck (a coluna final) como 0 e nada será verificado. Isso é claro que não é muito recomendado ... Se você optar por esta abordagem, sugiro que você defina serviços mínimos para iniciar automaticamente na inicialização, SSH imediatamente após a reinicialização, execute fsck manualmente sobre tudo enquanto montados somente leitura, remontam tudo no modo leitura + gravação e iniciam seus serviços (dessa forma, você tem acesso à máquina, mas os serviços do usuário não são iniciados até que você tenha certeza de que os sistemas de arquivos da máquina estão limpos).
Mas realmente encontrar a causa raiz deve ser sua prioridade aqui IMO, e as opções KVM remotas são uma idéia melhor do que arriscar a inicialização em um SO com sistemas de arquivos potencialmente corrompidos.
É possível instalar o servidor SSH dropbear no INITRD, em menos no Debian . Deveria ser possível fazer o mesmo no Centos, eu não tenho um tipo especifico de como posso te apontar.
De qualquer forma, é melhor obter algum tipo de configuração de gerenciamento fora de banda.
Tags linux filesystems centos6.4