Com que frequência devo reiniciar os servidores Linux?

Eu tenho muitos servidores Linux (SUSE 9 e 10) usados ​​para executar serviços da Web que fornecem dados para grandes grades de cálculo. Recentemente, tivemos algumas falhas difíceis de explicar (ou seja, os logs de hardware e software não mostram erros óbvios) e estamos começando a pensar se o longo tempo de atividade (normalmente de 200 a 300 dias) é o problema. Como esses servidores são muito utilizados, devo considerar um ciclo de reinicialização regular?

Você deve reiniciar após uma atualização do kernel (a menos que esteja usando o KSplice), qualquer outra coisa é opcional. Pessoalmente, reinicializo um ciclo mensal durante uma janela de manutenção para garantir que o servidor e todos os serviços retornem conforme o esperado. Dessa forma, posso estar razoavelmente certo se precisar fazer uma reinicialização fora do cronograma (isto é, atualização crítica do kernel) de que o sistema retornará corretamente. O monitoramento automatizado de servidores e serviços (ou seja, o Nagios) também ajuda bastante nesse processo (reinicialize, observe as luzes ficarem vermelhas e, espero, tudo voltar ao verde).

Se você reinicializar regularmente, certifique-se de ajustar as verificações do fsck (ou seja, a contagem máxima de montagens entre as verificações de maneira apropriada, caso contrário, uma reinicialização rápida de 2 minutos pode levar 30 minutos se o servidor começar a verificar alguns terabytes de dados. Normalmente, defino minha contagem de montagem como 0 (tune2fs -c 0) e o intervalo entre as verificações para 6 meses ou mais e forço manualmente um fsck de vez em quando e redefino a contagem.

Na verdade, reinicio meus servidores regularmente, sempre que são feitas grandes alterações na configuração. É importante saber que, em caso de emergência, o software do servidor será disponibilizado sem problemas. A última coisa que você deseja é estar em uma posição em que você está tentando se recuperar de uma interrupção, mas está tendo que mexer com a configuração do servidor, porque você não a testou completamente quando a configurou.

Os servidores Linux nunca precisam ser reinicializados, a menos que você absolutamente precise alterar a versão do kernel em execução. A maioria dos problemas pode ser resolvida alterando um arquivo de configuração e reiniciando um serviço com um script init.

Você precisa estar atento às reinicializações ... se você alterou algo "on the fly" sem refletir suas alterações no arquivo de configuração de um serviço, essas alterações não serão aplicadas após uma reinicialização.

Eu normalmente reinicio após atualizações agendadas do sistema. Geralmente não é necessário, mas eu as faço quando ninguém está no escritório, então por que não? De qualquer maneira, muitas vezes há atualizações do kernel quando eu faço a atualização.

Não é realmente necessário, o manuseio de memória linux é excelente. Mas se você está tendo tempo de atividade desse tamanho, provavelmente está executando kernels que possuem vulnerabilidades conhecidas - você pode assistir a isso.

Eu acho que você deve reiniciar se houver uma atualização recente do kernel OU uma atualização da libc. Muitas coisas estão relacionadas à libc e não é realmente possível descarregá-la completamente da memória e substituí-la pela nova versão, a menos que você reinicie.

Por exemplo, mesmo coisas básicas como / bin / ls e outras coisas em / bin usam libc. Se você está apenas executando um console e usando o bash, está usando a libc.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

E sim, se você alterar os arquivos no /etc/init.d que afetam a inicialização de alguma forma, eu recomendaria uma reinicialização. Você não deseja descobrir que cometeu um pequeno erro em um arquivo de inicialização quando precisar executar as coisas novamente e em execução rapidamente.

Se um servidor passou muitos dias sem uma reinicialização, na verdade significa que não há como ter certeza de que ele voltará a funcionar corretamente. Mais uma vez, isso ocorre porque muitos arquivos de configuração podem ter sido alterados e ninguém o reinicializou por um longo tempo para garantir que eles sejam exibidos. Além disso, se o servidor tiver muitas atualizações em atraso e você não tiver reiniciado por um longo tempo, reinicie antes de aplicá-las; caso contrário, se houver um problema, não poderá ter certeza de que foi causado por um erro de configuração. há muito tempo ou as novas atualizações que você aplicou.

Por fim, se você reiniciar um servidor crítico após um longo período de tempo, o fsck pode significar que você precisa esperar muito tempo para que ele volte a funcionar. Você pode usar o tune2fs para evitar isso, mas é uma boa ideia verificá-lo regularmente, suponho. É por isso que você não deve estar em uma posição em que depende apenas de um servidor e, se for o caso, todo o site se foi. Você deve ter outro em espera.

Outra coisa a procurar durante esse tempo de inatividade inesperado é verificar exatamente como a memória e o processador estão sendo usados ​​e por quais programas. topdeve ser capaz de determinar quais processos são os culpados pela perda de recursos e, em seguida, ser capaz de gerenciá-los diretamente. Outra idéia seria inicializar um cronjob para encerrar e reiniciar seus processos em um agendamento específico.

Não é uma má idéia reiniciar se já tiver demorado tanto para que você possa executar uma verificação de disco (fsck) na partição raiz. Seu argumento pode ser que isso ajuda a garantir a integridade dos dados.

Um servidor Linux executado corretamente deve precisar ser reiniciado apenas para atualizações do kernel. O mesmo nem sempre pode ser dito para alguns softwares - por exemplo, às vezes tenho que reiniciar o apache2 ou o mailman.

Minha infra-estrutura possui dois sites de dados, o alfa (onde as operações são realizadas diariamente) e o beta (o site de backup, no caso de algo terrivelmente errado no alfa). Embora atualmente não seja esse o caso, estou insistindo em ter um tempo de inatividade programado no site alfa a cada 6 meses, para que possamos executar todos os serviços a partir da versão beta.

Isso realizará duas coisas. Primeiro, ele provará que nosso site de recuperação de desastres é completamente viável. Segundo, me dará uma semana de tempo para remover a crosta acumulada em alfa.

Como é, não reinicializo meus servidores com a frequência que deveria. Concordo com os outros pôsteres que disseram que é importante saber que seus servidores voltarão quando você precisar. Você não quer "pensar" que sim, apenas para descobrir que você mudou alguma coisa e não a fez corretamente ou não a documentou.

Além disso, você pode escrever alguns scripts que verificarão (o máximo possível), se o estado atual da sua máquina, será o estado da máquina após a reinicialização.

O que quero dizer com isso é ...

• /etc/init.d/*
  • Verifique se todos os serviços atualmente em execução estão sinalizados para iniciar na inicialização
  • Verifique se todos os serviços que não estão em execução estão sinalizados para não iniciar na inicialização
• /etc/fstab
  • Verifique se todos os sistemas de arquivos montados (ou seja /etc/mtab) possuem uma entrada correspondente em/etc/fstab
  • Verifique se todos os sistemas de arquivos especificados para serem montados na inicialização /etc/fstabtambém estão atualmente montados.

Obviamente, essa não é uma verificação completa, mas reduz o risco de problemas após a reinicialização.

Além disso, você deve (imo) definir uma política para atualizações de pacotes de servidores, em alguma ordem sensata, digamos 1 grupo por semana ...

• Crash & Burn Servers
• Servidores de Desenvolvimento, Servidores de Treinamento
• Servidores de teste
• Servidores de pré-produção
• Servidores de produção

Também tenha um plano geral, como "Todos os servidores passarão por uma atualização completa do sistema operacional uma vez a cada 6 meses".

Depende das tarefas em execução no servidor. Para alguns servidores virtuais, geralmente usamos reinicialização em vez de apachectl restart e leva apenas de 10 a 10 segundos a mais. Mas algumas máquinas carregadas pesadas são reiniciadas várias vezes por ano, com uma equipe de administradores inteira monitorando o processo.