¿Con qué frecuencia debo reiniciar los servidores Linux?

Tengo muchos servidores Linux (SUSE 9 y 10) utilizados para ejecutar servicios web que proporcionan datos a grandes cuadrículas de cálculo. Recientemente, hemos tenido algunas interrupciones difíciles de explicar (es decir, los registros de hardware y software no muestran errores obvios) y estamos empezando a preguntarnos si el tiempo de funcionamiento prolongado (generalmente 200-300 días) es el problema. Dado que estos servidores son muy utilizados, ¿debería considerar un ciclo de reinicio regular?

Debe reiniciar después de una actualización del kernel (a menos que esté usando KSplice), cualquier otra cosa es opcional. Personalmente, reinicio en un ciclo mensual durante una ventana de mantenimiento para asegurarme de que el servidor y todos los servicios vuelvan como se esperaba. De esta manera, puedo estar razonablemente seguro si tengo que hacer un reinicio fuera de horario (es decir, una actualización crítica del núcleo) de que el sistema volverá a funcionar correctamente. El monitoreo automatizado de servidores y servicios (es decir, Nagios) también ayuda en gran medida a este proceso (reiniciar, ver que las luces se vuelven rojas y luego esperamos que todo vuelva a verde).

PD: si reinicia regularmente, querrá asegurarse de ajustar sus comprobaciones de fsck (es decir, el recuento de montaje máximo entre las comprobaciones de manera adecuada; de lo contrario, un reinicio rápido de 2 minutos podría tomar 30 minutos si el servidor comienza a fsck'ing un par de terabytes de datos. Por lo general, configuro mi recuento de monturas en 0 (tune2fs -c 0) y el intervalo entre verificaciones en 6 meses más o menos, y luego fuerzo manualmente un fsck de vez en cuando y restablezco el recuento.

De hecho, reinicio mis servidores de forma bastante regular, cada vez que se realizan cambios importantes en la configuración. Es importante saber que en caso de una emergencia, el software del servidor aparecerá sin problemas. Lo último que desea es estar en una posición en la que esté tratando de recuperarse de una interrupción del servicio, pero tenga que meterse con la configuración de su servidor porque no lo probó a fondo cuando lo configuró.

Los servidores Linux nunca necesitan reiniciarse a menos que sea absolutamente necesario cambiar la versión del kernel en ejecución. La mayoría de los problemas se pueden resolver cambiando un archivo de configuración y reiniciando un servicio con un script de inicio.

Debe tener cuidado con los reinicios ... si cambió algo "sobre la marcha" sin reflejar sus cambios en el archivo de configuración de un servicio, esos cambios no se aplicarán después de un reinicio.

Aunque generalmente reinicio después de las actualizaciones programadas del sistema. Generalmente no es necesario, pero los hago cuando no hay nadie en la oficina, entonces ¿por qué no? A menudo hay actualizaciones de kernel cuando llego a hacer la actualización, de todos modos.

No es realmente necesario, el manejo de la memoria de Linux es excelente. Pero si tiene tiempos de actividad de esa longitud, probablemente esté ejecutando núcleos que tienen vulnerabilidades conocidas, es posible que desee ver eso.

Creo que deberías reiniciar si ha habido una actualización reciente del kernel O una actualización de libc. Muchas cosas están vinculadas con libc y realmente no es posible descargar esa lib de la memoria por completo y reemplazarla con la nueva versión a menos que reinicie.

Por ejemplo, incluso cosas básicas como / bin / ls y otras cosas en / bin usan libc. Si solo está ejecutando una consola y está usando bash, está usando 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)

Y sí, si cambia los archivos en /etc/init.d que afectan el inicio de alguna manera, recomendaría reiniciar. No desea descubrir que cometió un pequeño error en un archivo de inicio cuando necesita que las cosas vuelvan a funcionar rápidamente.

Si un servidor ha pasado muchos días sin reiniciar, en realidad significa que no hay forma de asegurarse de que vuelva a funcionar correctamente. Una vez más, esto se debe a que es posible que se hayan cambiado muchos archivos de configuración, y nadie lo ha reiniciado durante mucho tiempo para asegurarse de que aparezca. Además, si el servidor tiene muchas actualizaciones pendientes y no ha reiniciado durante mucho tiempo, reinicie antes de aplicar las actualizaciones; de lo contrario, si hay un problema, no puede estar seguro de que fue causado por un error de configuración. hace mucho tiempo o las nuevas actualizaciones que aplicó.

Por último, si reinicia un servidor crítico después de mucho tiempo, el fsck puede significar que debe esperar mucho tiempo ahora para que vuelva a funcionar. Puede usar tune2fs para evitar esto, pero es una buena idea comprobarlo regularmente, supongo. Esta es la razón por la que no debe estar en una posición en la que dependa de solo 1 servidor y, si eso sucede, todo su sitio web desaparecerá. Deberías tener otro en espera.

Otra cosa a tener en cuenta al tener este tiempo de inactividad inesperado, es observar cómo se utilizan exactamente la memoria y el procesador y qué programas. topdebería poder determinar qué procesos son los culpables de la pérdida de recursos, y luego poder administrarlos directamente. Otra idea sería inicializar un cronjob para cerrar y reiniciar sus procesos en un horario específico.

No es una mala idea reiniciar si ha pasado tanto tiempo para que pueda ejecutar una comprobación de disco (fsck) en la partición raíz. Su argumento puede ser que esto ayuda a garantizar la integridad de los datos.

Un servidor Linux correctamente ejecutado solo debería reiniciarse para las actualizaciones del kernel. No siempre se puede decir lo mismo de algunos de los programas; por ejemplo, a veces tengo que reiniciar apache2 o mailman.

Mi infraestructura tiene dos sitios de datos, el alfa (donde las operaciones se realizan a diario) y el beta (el sitio de respaldo, en caso de que las cosas salgan terriblemente mal en alfa). Aunque este no es el caso actualmente, estoy presionando para que haya un tiempo de inactividad programado en el sitio alfa cada 6 meses, para que podamos ejecutar todos los servicios desde la versión beta.

Esto logrará dos cosas. Primero, demostrará que nuestro sitio de recuperación ante desastres es completamente viable. En segundo lugar, me dará una semana de tiempo para eliminar la migaja acumulada en alfa.

Tal como están las cosas, no reinicio mis servidores con tanta frecuencia como debería. Estoy de acuerdo con los otros carteles que dijeron que es importante saber que sus servidores volverán a funcionar cuando los necesite. No quiere "pensar" que lo harán, solo para descubrir que ha cambiado algo y no lo ha hecho correctamente o no lo ha documentado.

Además, puede escribir algunos scripts que verificarán (tanto como sea posible), si el estado actual de su máquina será el estado de la máquina después del reinicio.

Lo que quiero decir con esto es ...

• /etc/init.d/*
  • Compruebe que todos los servicios que se ejecutan actualmente están marcados para iniciarse en el arranque
  • Compruebe que todos los servicios que no se ejecutan están marcados para no iniciarse en el arranque
• /etc/fstab
  • Verifique que todos los sistemas de archivos montados (es decir /etc/mtab) tengan una entrada correspondiente en/etc/fstab
  • Compruebe que todos los sistemas de archivos especificados para montarse en el arranque /etc/fstabtambién estén montados actualmente.

Por supuesto, esto no es una verificación completa de ninguna manera, pero reduce el riesgo de problemas después del reinicio.

Además de esto, debe (imo) establecer una política para las actualizaciones de paquetes del servidor, en un orden razonable, digamos 1 grupo por semana ...

• Servidores de bloqueo y grabación
• Servidores de desarrollo, Servidores de formación
• Servidores de prueba
• Servidores de preproducción
• Servidores de producción

También tenga un plan general, como "Todos los servidores pasarán por una actualización completa del sistema operativo una vez cada 6 meses".

Depende de las tareas que se ejecutan en el servidor. Para algunos servidores virtuales, a menudo usamos reiniciar en lugar de reiniciar apachectl y solo lleva de 5 a 10 segundos más. Pero algunas máquinas con carga pesada se reinician varias veces al año con un equipo administrativo completo que supervisa el proceso.