5 maneras de mejorar tus servidores

Introducción

Una vez que tu aplicación esté funcionando en un entorno de servidor en la nube, es posible que te estés preguntando cómo puedes mejorar tu entorno de servidor para dar el salto de “funciona” a un entorno de producción completo.

Este artículo te ayudará a comenzar a planificar e implementar un entorno de producción al crear una definición flexible de “producción”, en el contexto de una aplicación web en un entorno de servidor en la nube, y al mostrarte algunos componentes que puedes agregar a tus aplicaciones en la arquitectura existente para hacer la transición.

Para los fines de esta demostración, supongamos que estamos comenzando con una configuración similar a la descrita en 5 configuraciones comunes de servidores, como este entorno de dos servidores que simplemente muestra una aplicación web:

Tu configuración real podría ser más simple o más compleja, pero las ideas y componentes generales que se describen en este documento deberían aplicarse a cualquier entorno de servidor en cierta medida.

Comencemos por definir lo que queremos decir cuando decimos “entorno de producción”.

¿Qué es un entorno de producción?

Un entorno de servidor para una aplicación web, en un sentido general, consiste en el hardware, el software, los datos, los planes operativos y el personal que son necesarios para mantener la aplicación en funcionamiento. Un entorno de producción generalmente se refiere a un entorno de servidor que fue diseñado e implementado con la mayor consideración para los niveles aceptables de estos factores:

  • Disponibilidad: La capacidad de la aplicación para ser utilizada por sus usuarios previstos durante las horas anunciadas. La disponibilidad puede verse interrumpida por cualquier falla que afecte lo suficiente a un componente crítico (por ejemplo, la aplicación se bloquea debido a un error, el dispositivo de almacenamiento de la base de datos falla o el administrador del sistema apaga accidentalmente el servidor de la aplicación).

Una forma de promover la disponibilidad es disminuir el número de puntos únicos de falla en un entorno. Por ejemplo, el uso de una IP estática y un servicio de supervisión de conmutación por error garantizan que los usuarios solo accedan a balanceadores de carga en buen estado. Para obtener más información, lee este artículo sobre el balanceo de carga .

  • Recuperabilidad: la capacidad de recuperar un entorno de aplicación en caso de fallo del sistema o pérdida de datos. Si un componente crítico falla y no es recuperable, la disponibilidad será inexistente. La mejora de la capacidad de mantenimiento, un concepto relacionado, reduce el tiempo necesario para realizar un proceso de recuperación dado en caso de una falla, y por lo tanto puedes mejorar la disponibilidad en caso de una falla.
  • Rendimiento: la aplicación se desempeña como se espera bajo la carga promedio o máxima (por ejemplo, es razonablemente sensible). Si bien es muy importante para tus usuarios, el rendimiento solo importa si la aplicación está disponible.

Aplicando los conceptos

Tómate un tiempo para definir niveles aceptables para cada uno de los elementos que se acaban de mencionar, en el contexto de tu aplicación. Esto variará dependiendo de la importancia y la naturaleza de la aplicación en cuestión.

Por ejemplo, es probable que un blog personal que atiende a pocos visitantes sufra periodos de inactividad ocasionales o un rendimiento deficiente, siempre y cuando el blog pueda recuperarse, pero la tienda en línea de una empresa debe esforzarse mucho en lograrlo. Por supuesto, sería bueno lograr el 100% en cada categoría, para cada aplicación, pero a menudo esto no es posible debido a limitaciones de tiempo y dinero.

Ten en cuenta que no hemos mencionado (a) la confiabilidad del hardware, la probabilidad de que un componente de hardware dado funcione correctamente durante un período específico de tiempo antes del fallo, o (b) la seguridad como factores.

Esto se debe a que asumimos que (a) los servidores en la nube que estás utilizando son generalmente confiables, pero tienen el potencial de fallar (como se ejecutan en servidores físicos), y (b) están siguiendo las mejores prácticas de seguridad en la medida de sus capacidades: En pocas palabras, están fuera del alcance de este artículo. Sin embargo, debes tener en cuenta que la confiabilidad y la seguridad son factores que pueden afectar directamente la disponibilidad, y ambos pueden contribuir a la necesidad de recuperación.

En lugar de mostrarte un procedimiento paso a paso para crear un entorno de producción, que es imposible debido a las diferentes necesidades y la naturaleza de cada aplicación, presentaremos algunos componentes tangibles que se pueden utilizar para transformar tu configuración existente en un entorno de producción.

¡Echemos un vistazo a los componentes!

1. Sistema de copia de seguridad

Un sistema de copias de seguridad (backup) te otorgará la capacidad de crear respaldos periódicos de tus datos y restaurarlos a partir de dichos respaldos. Las copias de seguridad también permiten realizar reversiones en tus datos, a un estado anterior, en el caso de una eliminación accidental o una modificación no deseada, que puede ocurrir debido a una variedad de razones, incluido el error humano.

Todo el hardware de la computadora tiene la posibilidad de fallar en algún momento, lo que potencialmente puede causar la pérdida de datos. Teniendo esto en cuenta, debes mantener copias de seguridad recientes de todos tus datos importantes.

¿Es requerido para la producción? 

Sí. Un sistema de copia de seguridad (respaldo) puede mitigar los efectos de la pérdida de datos, lo cual es necesario para lograr la capacidad de recuperación y, por lo tanto, ayuda a la disponibilidad en caso de pérdida de datos, pero debe usarse junto con planes de recuperación sólidos, que se analizan en la siguiente sección.

Ten en cuenta que las copias de seguridad basadas en instantáneas pueden no ser suficientes para todas tus necesidades de copia de seguridad, ya que no son adecuadas para realizar copias de seguridad de bases de datos activas y otras aplicaciones con alta Entrada/Salida de escritura en disco, si ejecutas estos tipos de aplicaciones, o deseas más flexibilidad en la programación de copias de seguridad, asegúrate de usar otro sistema de copia de seguridad como Bacula.

El diagrama de arriba es un ejemplo de un sistema de respaldo básico. El servidor de copia de seguridad reside en el mismo centro de datos que los servidores de aplicaciones, donde se crean las copias de seguridad iniciales. Posteriormente, se realizan copias externas de las copias de seguridad a un servidor en un centro de datos diferente para garantizar que los datos se conserven en el caso de, por ejemplo, un desastre natural.

Consideraciones

  • Selección de copia de seguridad: los datos que realizará una copia de seguridad. Como mínimo, realiza una copia de seguridad de los datos que no puedas reproducir de forma confiable desde una fuente alternativa
  • Programación de copias de seguridad: cuándo y con qué frecuencia realizarás copias de seguridad completas o incrementales. Deben tomarse consideraciones especiales para las copias de seguridad de ciertos tipos de datos, como las bases de datos activas, que pueden afectar tu programación de copias de seguridad.
  • Período de retención de datos: cuánto tiempo conservarás tus copias de seguridad antes de eliminarlas
  • Espacio en disco para copias de seguridad: la combinación de tres elementos anteriores afecta la cantidad de espacio en disco que requerirá tu sistema de copia de seguridad. Aprovecha la compresión y las copias de seguridad incrementales para disminuir el espacio en disco requerido por tus copias de seguridad
  • Copias de seguridad fuera del sitio: para proteger tus copias de seguridad contra desastres locales, dentro de un centro de datos en particular, es recomendable mantener una copia de tus copias de seguridad en una ubicación geográficamente separada. En el diagrama anterior, las copias de seguridad de NYC3 se copian a SFO1 para este propósito
  • Pruebas de restauración de copia de seguridad: prueba periódicamente tu proceso de restauración de copia de seguridad para asegurarse de que tus copias de seguridad funcionan correctamente.

Tutoriales relacionados

Cómo usar Rsync para sincronizar directorios locales y remotos en un VPS

2. Planes de recuperación

Los planes de recuperación son un conjunto de procedimientos documentados para recuperarse de fallas potenciales o errores de administración dentro de tu entorno de producción.

Como mínimo, desearás un plan de recuperación para cada situación de paralización que consideres que ocurrirá inevitablemente, como un fallo del hardware del servidor o la eliminación accidental de datos.

Por ejemplo, un plan de recuperación muy básico para una falla del servidor podría consistir en una lista de los pasos que tomaste para realizar la implementación inicial del servidor, con procedimientos adicionales para restaurar los datos de la aplicación desde las copias de seguridad.

Un mejor plan de recuperación podría, además de una buena documentación, aprovechar los scripts de implementación y las herramientas de administración de la configuración, como Ansible, Chef o Puppet, para ayudarte a automatizar y acelerar el proceso de recuperación.

¿Es requerido para la producción? 

Sí. Aunque los planes de recuperación no existen como software en tu entorno de servidor, son un componente necesario para una configuración de producción. Te permiten utilizar tus copias de seguridad de manera efectiva y proporcionan un plan para reconstruir tu entorno o revertir a un estado deseado cuando surja la necesidad.

El diagrama anterior es una descripción general de un plan de recuperación para un servidor de base de datos fallido. En este caso, el servidor de la base de datos será reemplazado por uno nuevo con el mismo software instalado, y se utilizará la última copia de seguridad válida para restaurar la configuración y los datos del servidor. Por último, el servidor de aplicaciones se configurará para utilizar el nuevo servidor de bases de datos.

Consideraciones

  • Documentación del procedimiento: el conjunto de documentos que se deben seguir en un evento de falla. Un buen punto de partida es crear un documento paso a paso que puedas seguir para reconstruir un servidor fallido y luego agregar pasos para restaurar los diversos datos de la aplicación y la configuración desde las copias de seguridad.
  • Herramientas de automatización: los scripts y el software de administración de configuración proporcionan automatización, que pueden mejorar los procesos de implementación y recuperación. Si bien las guías paso a paso son a menudo adecuadas para simplemente recuperarse de una falla, deben ser ejecutadas por una persona y, por lo tanto, no son tan rápidas ni consistentes como un proceso automatizado.
  • Componentes críticos: los componentes que son necesarios para que tu aplicación funcione correctamente. En el ejemplo anterior, tanto la aplicación como los servidores de base de datos son componentes críticos porque, si alguno de los dos falla, la aplicación dejará de estar disponible.
  • Puntos únicos de falla: los componentes críticos que no tienen un mecanismo automático de conmutación por error se consideran como un solo punto de falla. Debes intentar eliminar los puntos únicos de falla, lo mejor que puedas, para mejorar la disponibilidad
  • Revisiones: actualiza tu documentación a medida que mejores tu proceso de implementación y recuperación.

3. Balanceo de carga

El balanceo de carga se puede agregar a un entorno de servidor para mejorar el rendimiento y la disponibilidad mediante la distribución de la carga de trabajo entre varios servidores.

Si uno de los servidores que tiene balanceo carga falla, los otros servidores manejarán el tráfico entrante hasta que el servidor que ha fallado vuelva a funcionar correctamente.

En un entorno de servidor en la nube, el balanceo de carga generalmente se puede implementar agregando un servidor de balanceo de carga, que ejecuta el software de balanceo de carga (proxy inverso), frente a varios servidores que ejecutan un componente particular de una aplicación.

¿Es requerido para la producción? 

No necesariamente. El balanceo de carga no siempre es necesario para un entorno de producción, pero puede ser una forma efectiva de reducir el número de puntos únicos de falla en un sistema, si se implementa correctamente. También puede mejorar el rendimiento al agregar más capacidad a través de la escala horizontal.

El diagrama anterior agrega un servidor de aplicaciones adicional para compartir la carga, y un balanceador de carga para distribuir las solicitudes de los usuarios en ambos servidores de aplicaciones.

Esta configuración puede ayudar con el rendimiento, si el único servidor de aplicaciones tiene dificultades para mantenerse al día con el tráfico, y también puede ayudar a mantener la aplicación disponible si falla uno de los servidores de la aplicación. Sin embargo, aún tienes dos puntos únicos de falla en el servidor de la base de datos y en el servidor del balanceador de carga.

Consideraciones

  • Componentes de balanceo de carga: no todos los componentes en un entorno pueden ser balanceados de carga fácilmente. Se debe prestar especial atención a ciertos tipos de software, como bases de datos o aplicaciones con estado.
  • Replicación de los datos de la aplicación: si un servidor de aplicaciones con carga balanceada almacena los datos de la aplicación localmente, como los archivos cargados, estos datos deben estar disponibles para los otros servidores de la aplicación a través de métodos como la replicación o los sistemas de archivos compartidos.

Esto es necesario para garantizar que los datos de la aplicación estarán disponibles sin importar qué servidor de aplicaciones se elija para atender una solicitud de usuario

  • Cuellos de botella en el rendimiento: si un balanceador de carga no tiene suficientes recursos o no está configurado correctamente, puede disminuir el rendimiento de tu aplicación
  • Puntos únicos de falla: mientras que un balanceo de carga se puede usar para eliminar puntos únicos de falla, el balanceo de carga mal planeado puede agregar más puntos únicos de falla. El balanceo de carga se mejora con la inclusión de un segundo balanceador de carga con una IP estática frente al par que envía el tráfico a uno u otro según la disponibilidad.

Tutoriales relacionados

4. Monitoreo

El monitoreo puede admitir un entorno de servidor mediante el seguimiento del estado de los servicios y las tendencias de utilización de los recursos de tu servidor, lo que proporciona una gran visibilidad de tu entorno.

Uno de los mayores beneficios de los sistemas de monitoreo es que pueden configurarse para desencadenar una acción, como ejecutar un script o enviar una notificación, cuando un servicio o servidor se desactiva, o si un determinado recurso, como la CPU, la memoria o almacenamiento, se vuelven sobreutilizados.

Estas notificaciones te permiten reaccionar ante cualquier problema tan pronto como ocurren, lo que puede ayudar a minimizar o prevenir el tiempo de inactividad de tu aplicación.

¿Es requerido para la producción? 

No necesariamente, pero la necesidad de monitoreo aumenta a medida que el entorno de producción crece en tamaño y complejidad. Proporciona una manera fácil de realizar un seguimiento de tus servicios críticos y recursos del servidor. A su vez, el monitoreo puede mejorar la capacidad de recuperación e informar la planificación y el mantenimiento de tu configuración.

El diagrama de arriba es un ejemplo de un sistema de monitoreo. Normalmente, el servidor de monitoreo solicitará los datos de estado del software del agente que se ejecuta en la aplicación y los servidores de base de datos, y cada agente responderá con información de estado del software y del hardware. Los administradores del sistema pueden usar la consola de monitoreo para ver el estado general de la aplicación y obtener información más detallada, según sea necesario.

Consideraciones

  • Servicios a monitorear: Los servicios y software que monitorearás. Como mínimo, debes supervisar el estado de todos los servicios que deben estar en buen estado de ejecución para que tu aplicación funcione correctamente.
  • Recursos para monitorear: Los recursos que monitorearás. Los ejemplos de recursos incluyen CPU, memoria, almacenamiento y utilización de la red, y el estado del servidor como un todo
  • Retención de datos: el período de tiempo que retienes los datos de monitoreo antes de descartarlos. Esto, junto con tu elección de elementos para monitorear, afectará la cantidad de espacio en disco que requerirá tu sistema de monitoreo
  • Reglas de detección de problemas: los umbrales y las reglas que determinan si un servicio o recurso está en un estado OK. Por ejemplo, se puede considerar que un servicio o servidor está en buen estado si se está ejecutando y atendiendo solicitudes, mientras que un recurso, como el almacenamiento, puede desencadenar una advertencia si su utilización alcanza un cierto umbral durante un cierto período de tiempo.
  • Reglas de notificación: los umbrales y reglas que determinan si se debe enviar una notificación. Si bien las notificaciones son importantes, es igualmente importante ajustar las reglas de notificación para que no recibas demasiadas; una bandeja de entrada llena de advertencias y alertas a menudo se ignorará, haciéndolas casi tan inútiles como ninguna notificación.

5. Registro centralizado

El registro centralizado puede admitir un entorno de servidor al proporcionar una manera fácil de ver y buscar tus registros, que normalmente se almacenan localmente en servidores individuales en todo tu entorno, en un solo lugar.

Además de la conveniencia de no tener que iniciar sesión en servidores individuales para leer registros, el registro centralizado también te permite identificar fácilmente los problemas que abarcan varios servidores al correlacionar sus registros y métricas durante un período de tiempo específico.

También otorga más flexibilidad en términos de retención de registros porque los registros locales pueden descargarse de los servidores de aplicaciones a un servidor de registros centralizado que tiene su propio almacenamiento independiente.

¿Es requerido para la producción? 

No, pero al igual que el monitoreo, el registro centralizado puede proporcionar una valiosa información sobre el entorno de tu servidor a medida que crece en tamaño y complejidad. Además de ser más conveniente que el registro tradicional, te permite auditar rápidamente los registros del servidor con mayor visibilidad.

El diagrama anterior es un ejemplo simplificado de un sistema de registro centralizado. Se instala un agente de envío de registros en cada servidor y se configura para enviar registros importantes de aplicaciones y bases de datos al servidor de registro centralizado. Los administradores del sistema pueden ver, filtrar y buscar todos los registros importantes desde una única consola.

Consideraciones

  • Registros para recopilar: los registros particulares que enviarás desde tus servidores al servidor de registro centralizado. Debes reunir los registros importantes de todos tus servidores
  • Retención de datos: el período de tiempo que retienes los registros antes de descartarlos. Esto, junto con la elección de los registros a recopilar, afectará la cantidad de espacio en disco que requerirá tu sistema de registro centralizado.
  • Filtros de registro: los filtros que analizan registros simples en datos de registro estructurados. El filtrado de registros mejorará tu capacidad para consultar, analizar y graficar los datos de manera significativa
  • Relojes de servidor: asegúrate de que los relojes de tus servidores estén sincronizados y se configuren en la misma zona horaria, de modo que la escala de tiempo de tu registro sea precisa en todo tu entorno.

Conclusión

Cuando pones todos los componentes juntos, tu entorno de producción puede verse algo así:

Ahora que estás familiarizado con los componentes que pueden usarse para admitir y mejorar la configuración de un servidor de producción, debes considerar cómo puedes integrarlos en tus propios entornos de servidor. Por supuesto, no cubrimos todas las posibilidades, pero esto debería darte una idea de dónde comenzar. Recuerda diseñar e implementar tu entorno de servidor basado en un balance de tus recursos disponibles y tus propios objetivos de producción.