5 formas de reducir el tiempo de inactividad del servidor (y una de eliminarlas)

Reiniciar los servidores le perjudica a usted y a sus clientes. Suele hacerse fuera de las horas punta (normalmente por la noche), cuando los servidores procesan menos transacciones, pero incluso reiniciar en este momento cuesta miles de euros en tiempo de inactividad. Reiniciar un servidor puede llevar desde varios minutos hasta más de una hora, dependiendo de la configuración, y los servicios pueden tardar más tiempo en sincronizarse. De hecho, el 25% de las organizaciones informan en que el tiempo de inactividad les cuesta entre 300.000 y 400.000 dólares por cada hora que los servidores no están disponibles. El tiempo de inactividad es evitable y los reinicios debidos a la aplicación de parches pueden eliminarse por completo.

Contenido:

1. ¿Qué es el tiempo de inactividad del servidor y cuándo se produce?
2. Costes de inactividad para las organizaciones
3. Programación del tiempo de inactividad: Planificación y ejecución del mantenimiento
4. Cómo minimizar el tiempo de inactividad del servidor

¿Qué es el tiempo de inactividad del servidor y cuándo se produce?

Los servidores fallan por diversas razones, pero el fallo de un servidor no siempre significa tiempo de inactividad. El tiempo de inactividad es mucho más crítico para una organización porque significa que se ignoró o pasó por alto un único punto de fallo o que los sistemas de conmutación por error no fueron capaces de tomar el relevo sin problemas. Google presentó un vídeo sobre las diez razones principales del tiempo de inactividad del servidor. A continuación resumimos el vídeo de 50 minutos.

Sobrecarga de recursos

Cuando las solicitudes del servidor superan los recursos disponibles, el rendimiento se resiente y, finalmente, el servidor se bloquea. Los servidores en nube pueden ampliar los recursos de forma dinámica, pero los administradores locales responsables de esos servidores en nube deben asegurarse siempre de que los servidores puedan soportar las solicitudes de los clientes y las ampliaciones de recursos.

Vecino ruidoso

El problema del "mal vecindario" preocupa sobre todo a los proveedores de cloud computing con servicios de alojamiento compartido. Cuando un cliente utiliza demasiados recursos de un servidor, afecta al rendimiento de los sitios de otros clientes. La mayoría de los hosts sacarán al "vecino ruidoso" de los servicios compartidos para controlar el problema o limitar los recursos disponibles para un cliente problemático.

Picos de reintento

Ya sea por un servidor sobrecargado o por una aplicación maliciosa, cuando los usuarios no pueden conectarse a un servidor, suelen intentarlo varias veces antes de darse por vencidos. Ahora añada miles de usuarios realizando los mismos reintentos varias veces, y tendrá un servidor colapsado debido a los picos de reintentos. Los administradores pueden configurar los servidores para que rechacen las conexiones con reintentos agresivos para ayudar a reducir los picos de reintentos.

Dependencias, parches o aplicaciones con errores

Los malos hábitos de aplicación de parches, el software obsoleto, las dependencias lentas y otros muchos problemas relacionados con las aplicaciones que se ejecutan en el servidor pueden provocar tiempos de inactividad. Los administradores no pueden limitarse a instalar parches y reiniciar indiscriminadamente. Deben programar la instalación de parches y actualizaciones y reiniciar durante las horas de menor actividad. La aplicación de parches en vivo puede ser de gran ayuda (más información al respecto más adelante).

Escalado de terceros

Es posible que tus servidores sean escalables, pero las API de terceros utilizadas en el procesamiento de aplicaciones podrían no serlo. Google recomienda la "fragmentación", que consiste en dividir los procesos grandes y coherentes en trozos para reducir la sobrecarga.

Fragmentación ineficiente

La fragmentación beneficia al rendimiento, pero cuando un fragmento es demasiado grande en comparación con los demás, se produce una fragmentación desigual. Google recomienda dividir los fragmentos más grandes en fragmentos aún más pequeños para solucionar el problema.

Errores humanos

Algunos procedimientos de servidor tienen demasiada participación humana. Sin automatización, podrían introducirse errores humanos. Por ejemplo, depender del personal de TI para parchear y actualizar manualmente los servidores suele dar lugar a errores y tiempos de inactividad. La gestión de parches y la automatización reducen en gran medida los errores humanos, ya que solo requieren la intervención de los administradores cuando se detecta un problema.

Mala implantación del código

Para las organizaciones con aplicaciones internas, las pruebas son fundamentales para garantizar que el código desplegado no presenta problemas. Además de pruebas exhaustivas y procedimientos de aseguramiento de la calidad (QA), siempre debe desarrollarse un proceso de reversión. 

Control deficiente

La mayoría de los administradores saben que la supervisión es esencial. También es un componente del cumplimiento normativo. Una sola configuración o un solo servidor omitido en una estrategia de supervisión deja a la organización expuesta a lagunas de supervisión. Auditar la red para garantizar que todos los recursos se añaden a las aplicaciones de supervisión evita este problema.

Dominios e infraestructura mal configurados

La conectividad a un recurso del servidor no siempre se debe a problemas de la máquina local. Un dominio defectuoso puede provocar la inactividad del servidor, ya que los clientes no pueden conectarse a los servidores. La conmutación por error y las pruebas antes de implantar los cambios de configuración ayudarán a evitar este problema.

Costes de inactividad para las organizaciones

Sea cual sea la causa, la principal preocupación de las empresas es el dinero que se pierde durante (y después de) el tiempo de inactividad. Las transacciones no se pueden procesar y podrían perderse en el vacío si no se dispone de sistemas de conmutación por error. Las frustraciones de los clientes son otro problema primordial que podría provocar pérdidas de ingresos por pérdida de clientes y daños a la marca, ya que el tiempo de inactividad afecta a la reputación.

En un informe reciente de Ponemon informelas organizaciones experimentan un 30% más de tiempo de inactividad debido a una mala gestión de los parches y a retrasos en la aplicación de parches de vulnerabilidad. De las empresas encuestadas, el 52% afirmó que no toleraba el tiempo de inactividad, incluidos los reinicios debidos a la aplicación de parches y a las actualizaciones del sistema operativo. Las pequeñas empresas sufren más que las grandes, ya que no disponen de los recursos y la automatización necesarios para gestionar los parches de vulnerabilidad, lo que provoca un aumento del tiempo de inactividad.

De todas las causas de tiempo de inactividad mencionadas, el error humano y las malas implementaciones de parches pueden eliminarse por completo mediante la automatización de parches. Los reinicios pueden eliminarse por completo mediante la aplicación de parches en tiempo real. Las organizaciones gastan 1,4 millones de dólares anuales en gestión de vulnerabilidades, pero la gestión y automatización de parches reduce en gran medida la sobrecarga de personal, los costes de inactividad e incluso los problemas de reinicio.

Programación del tiempo de inactividad: Planificación y ejecución del mantenimiento

En algún momento de la vida de un servidor, los administradores deben programar el tiempo de inactividad. Esto podría ser para el despliegue de código, cambios en el hardware del servidor, cambios de configuración, o una conmutación entre un servidor retirado con uno nuevo. El mantenimiento programado suele ejecutarse durante las horas de menor actividad, pero hay algunas medidas que pueden tomarse para reducir el tiempo de inactividad.

• Garantizar que las copias de seguridad son recientes, funcionan y están disponibles.. En caso de que tenga que realizar algún rollback crítico que interrumpa el servicio y necesite copias de seguridad, asegúrese de que estén disponibles para poder extraerlas y desplegarlas más rápidamente.
• Comprobar el uso del disco. Para las pequeñas empresas con servidores que utilizan recursos limitados, compruebe siempre que hay almacenamiento en disco disponible para las actualizaciones. Un disco lleno tendrá resultados inesperados junto con una grave degradación del rendimiento.
• Comprobar la utilización de los recursos del servidor. Además de comprobar el espacio de almacenamiento, valide que el servidor no tenga picos de CPU o memoria que puedan interferir en el éxito de una actualización o cambio de configuración.
• Pruebe antes de desplegar cualquier cambio. Esto puede parecer de sentido común administrativo, pero muchos cambios de configuración o actualizaciones "rápidas y sencillas" provocan tiempos de inactividad y los administradores se saltan las pruebas de pequeños cambios. Los administradores piensan que un pequeño cambio no podría causar problemas, pero la posibilidad siempre está ahí. Pruebe siempre los cambios en cualquier servidor de producción en un entorno de pruebas.

5 formas de reducir el tiempo de inactividad del servidor (y una de eliminarlas)

El tiempo de inactividad inesperado del servidor es mucho más perjudicial para una organización que el mantenimiento programado. Los administradores deben contar con un plan de copias de seguridad y reversión y estar preparados para los problemas durante el mantenimiento programado, pero el tiempo de inactividad inesperado requiere un análisis de la causa raíz y los recursos necesarios para volver a poner el servidor en servicio. Los administradores deben tomar medidas preventivas para garantizar que un servidor experimente el menor tiempo de inactividad posible. Estas son algunas de las mejores prácticas para ayudar a reducir el tiempo de inactividad:

Seguridad

La ciberseguridad es insuperablemente importante para la fiabilidad y el tiempo de actividad de los servidores. Los administradores que trabajan con servidores de cara al público experimentarán numerosos escaneos de vulnerabilidades, intentos de exploits y tráfico sospechoso que deben ser monitorizados. Cualquier vulnerabilidad reportada públicamente seguirá con exploits y ataques al servidor, por lo que los administradores deben tomar medidas inmediatas y parchear el sistema. El tiempo de inactividad debido a una violación de datos conlleva muchas más pérdidas de ingresos y problemas corporativos que el mero coste del tiempo de inactividad debido a un reinicio.

Supervisión de servidores

Para las organizaciones con cientos de servidores, es fácil pasar por alto uno solo. Auditar la red e identificar cada servidor garantiza que los servidores tengan la supervisión adecuada, no sólo para detectar un fallo, sino también picos de recursos e ineficiencias (por ejemplo, refrigeración) que podrían provocar un fallo lento. Cualquier problema debe ser comunicado a los administradores, incluidos los mensajes de texto en caso de errores críticos. La supervisión proactiva alerta a los administradores de fallos pendientes, tanto virtuales como físicos, para que puedan solucionar el problema antes de que provoque tiempo de inactividad.

Retirar servidores ineficientes

Los servidores más antiguos son mucho más propensos a fallar, por lo que con el tiempo un servidor debe ser retirado. No es raro que los administradores actualicen el hardware, pero a la larga no resulta rentable actualizarlo siempre. Estos servidores pueden consumir más energía y tener un efecto cascada en el rendimiento del entorno.

Optimizar la refrigeración

El calor y la humedad destruyen lentamente los equipos de los servidores. Con la monitorización implantada, estos factores ambientales se detectarán antes de que destruyan los equipos y los servidores sufran fallos de hardware. Debe instalarse la refrigeración adecuada en todas las salas de servidores, así como un sistema de reserva por si falla la refrigeración primaria.

Realizar pruebas de carga

Utilizar un equilibrador de carga para distribuir entre varios servidores ayuda al rendimiento, pero ¿qué ocurre si falla más de un servidor? Con las pruebas de carga, se sabe cómo funcionarán los servidores después de que fallen recursos parciales. Esto podría dar lugar al aprovisionamiento de servidores adicionales o a la adición de recursos a los servidores existentes. Para cualquier servidor crítico, sobreestime siempre los límites de capacidad para asegurarse de que hay suficientes recursos disponibles para escalar y crecer.

Automatización de parches y Live Patching

La aplicación manual de parches da lugar a errores humanos y a la omisión de alertas de vulnerabilidades importantes. En su lugar, las organizaciones deberían utilizar la automatización de parches. Incluso con la automatización de parches, la actualización del kernel de Linux sigue requiriendo un reinicio, hasta ahora. Con KernelCare y KernelCare + para bibliotecas compartidas, los administradores pueden aplicar parches a sus sistemas sin reiniciar el servidor. La aplicación de parches en vivo elimina por completo la necesidad de mantenimiento programado y el tiempo de inactividad para las actualizaciones del núcleo. Por ejemplo, HostUS utiliza KernelCare y recientemente retiró un servidor que no se había reiniciado durante 5 años y medio.

Conclusión

El tiempo de inactividad del servidor es extremadamente costoso, pero puede reducirse con las mejores prácticas adecuadas. La mayor parte del tiempo de inactividad debido a errores inesperados se puede evitar, pero cualquier tiempo de inactividad debido a la aplicación de parches se puede eliminar por completo con la aplicación de parches en vivo de KernelCare. Para ver lo que KernelCare puede hacer por sus servidores, regístrese gratis y empiece.