viernes, 17 de agosto de 2018

El server me sabe a poco.

Soy un fanático del Rock y de Debian. (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 conceptos y al fin, casi sin quererlo me ha salido algo interesante. Y es que ya sabéis que hace no mucho migré hacia Debian 9.5.0 y que ya os conté cómo utilizar vuestro servidor Apache en Event con libapache2_mod_fcgid y PHP_FPM. No obstante, solamente vimos cómo realizar algunas configuraciones básicas, pero no hice ninguna prueba que demuestre el tremendo potencial de esta nueva configuración.


Por supuesto el título del post viene por la canción de los grandes de Marea de "La luna me sabe a poco", pero voy a ir dejando otras canciones que, al menos su título, va genial para muchas de las partes del blog ya que es la canción que se me viene a la mente cuando me encuentro algunas configuraciones por defecto en servidores que me toca revisar.



Aunque si queréis escuchar a una gran artista interpretando canciones como esta, tenéis que escuchar a Raquel Eugenio (Xana Lavey), que además está de celebración porque hace poquito ha llegado a 100K subscriptores en Youtube. Su voz os va a conquistar, os hago spoiler. Os dejo esta misma canción pero cantada por ella. Simplemente, increíble.



Y ya entrando en materia del post, vamos con los resultados que podríamos obtener realizando configuraciones como os la que os conté en el post donde migré a Debian 9.5.0. y teniendo en cuenta las slow queries de la Base de datos y temas como el Timeout en /etc/apache2/apache2.conf. Ya sabéis que, por ejemplo, el Timeout debe estar bajo, con un valor de 15 segundos ya está bastante bien, ya que dejarlo a 300 tal y como viene por defecto es una herejía.



Aquí ocurre como dice Mägo de Oz. No podemos dejar estos valores por defecto, no podemos dejar que nuestro server de olvido viva y de olvido muera. Tenemos que tocar los archivos de configuración, no nos queda otra, para eso estamos aquí. [Aquí os dejo esta canción cantada por Raquel Eugenio y reitero, su voz es increíble].


Aquí vemos que al tratar de estresar un poco a nuestro servidor realizando 6144 requests con un nivel de concurrencia de 2000, nuestro server lo aguanta con un total de Failed requests de 100 (Al hacer esto varias veces de media he obtenido eso, 90-100 failed requests). Esto son peticiones que de no cumplirse, simplemente dan F5 y casi con total seguridad ya no tendrán problema.



¿Veis? No es tan complicado, sólo unas configuraciones básicas y ya conseguimos soportar a más de 6000 usuarios, más que los que la Universidad de Córdoba soporta (4000) cuando salen las notas de Selectividad. Si esto lo hubiese hecho la UCO, no tendríamos que estar hasta que su DoS nos separe.

Es posible que si alguien de la UCO me lee diga algo como:"Vale Manu, eso está muy bien, pero tienes una concurrencia de 2000 usuarios. Aceptas 6000 (que son más que los que se matriculan a Selectividad) pero tienes una concurrencia de 2000 y no de 4000 como nosotros".

Vale, lo primero que le diríamos es que se acueste, pues que accedan los más de 4000 alumnos matriculados a la misma hora y al mismo segundo es muy poco probable. No obstante, aceptamos el reto.


Tendremos que ir tocando el MaxRequests de /etc/apache2/mods-enabled/mpm-event.conf y cambiar el valor de ServerLimeit tal y como se comentó en el post de la migración hacia Debian 9.5. Tiramos ahora la prueba de stressing y subimos un poco. Concurrencia 3000 y número de requests a 9216. Es más del doble de requests que la UCO recibe cuando salen las notas. Como vemos, de más de 9000 requests, solamente failed 83 (ni un 1% de fallo. 0.9006% de probabilidad de fallo). Pero ¡Más madera!


Ahora sí, ahora hemos subido la concurrencia a 4000 y el número de requests a 12288 que, para que os hagáis una idea, son más de 3 veces más que requests puede recebir la web de la UCO el día de la salida de notas. Pero bueno, supongamos que cada persona hace F5 3 veces. El número de failed requests baja a 27, que es un 0.219% de probabilidad de fallo.

Y todo esto, reitero, con un Debian 9.5.0 con escritorio Gnome (con interfaz gráfica consumiendo recursos) y con configuraciones sencilla en /etc/apache2/apache2.conf y /etc/apache2/mods-enabled/mpm-event.conf por parte de Apache. Tocamos un poco también la base de datos para manejar las requests que permite la base de datos y que no haya cuellos de botella, controlamos las long y slow queries y poco más. Pero ya está, no necesitas mucho para que tu server aguante (vemos que ha aguantado a pesar de que si cae el padre, caen todos los hilos hijo y nuestro server-status sigue firme) a pesar de todas las consultas que pueda recibir.

Si Amazon aguanta cada Black Friday, cualquier server con mucho menos que la mitad de consultas, debería aguantar también, y más con configuraciones que no llevan ni 10 minutos (y le he puesto tiempo).



Si ya encima nos vamos a /var/log/apache2/access.log veremos que la gran mayoría de accesos tienen el código HTTP 200 indicando que ha ido todo bien. Importante, quedaros con la hora de las 09:33.



Si ahora nos vamos a /var/log/apache2/error.log veremos que hay algunos errores, un total de 63. Si vemos la hora vemos que ha sido a las 09:34:08, pero en /var/log/access.log vemos que a las 09:34:10 se ha producido un acceso con código de éxito 200, por lo que entendemos que ha sido por un Timeout y no por MaxRequestWorkers. Aún así nos aseguramos buscando en /var/log/access.log accesos con código 408, el relativo a Timeout, seguro que nos los encontramos.

¿Tratamos de llegar a 0 failed requests?

Para que ningún alumn@ se pueda quejar por Twitter de nuestro servidor, vamos a tratar de llegar a 0 failed requests, pero claro, puede que ya por más configuraciones que hagamos, no avancemos más. Esto puede pasar porque por más que revisemos la red ya no podamos tocar nada, la instalación del S.O. se haya realizado correctamente, configuración tal y como hemos dicho, pero nada, que no llegamos a 0 fallos de peticiones y además nuestro server empieza a tener problemas.

Eso me ha pasado a mi al llegar a 40000 requests, y es que mi Debian con 2GB de RAM no aguantaba más. No estaba nada mal para ser una máquina con 2GB, parecía que ya le había sacado todo el líquido, pero no, aún tenía guerra que dar, lo único es que nuestros servers, de vez en cuando, también Necesitan Respirar. (Ole mi Córdoba y sus grandes grupos de Rock)



Lo que vamos a hacer es dar un paso más y utilizar balanceadores de carga para dejar más desahogado a nuestro servidor principal. Yo lo que he hecho es utilizar el servidor principal y descargarle HaProxy y utilizar otros 2 Debian 9.5.0 clonados con la misma web y con la misma configuración de Apache, MariaDB,etc. Cada máquina con su propia IP por supuesto, por lo que ya podía empezar el juego. Tenemos el entorno así por tanto.


Lo que tendremos ahora es nuestra máquina principal en la que instalaremos HaProxy y dos máquinas más sobre las que replicaremos la página que teníamos en nuestro Apache. HaProxy es un balanceador de carga que lo que hará será gestionar la carga de trabajo e irá redireccionando peticiones a uno u otro servidor.

La instalación de HaProxy es muy sencilla, podéis seguir este tutorial y lo tendréis instalado y configurado en cuestión de minutos.


Y si tiramos ahora de nuevo de nuestras pruebas de stress de servidor con ab, veremos que el servidor Apache recibe 1 requests pero crea 74 hilos. Esto ya nos anticipa que se está haciendo todo el balanceo de carga correctamente.


No obstante, en nuestro HaProxy vemos que está gestionando todo el balanceo para llevar a las peticiones que van entrando a los otros servidores que hemos montado. Vemos cómo está gestionando 2000 requests por segundo.


Si os fijáis, en el Server2, recibimos muchas más peticiones. Más de 700K de peticiones. Esto es porque estaba haciendo pruebas para ver si aceptaba 100K de peticiones.


El server1 tiene más o menos la misma carga, y es que ahora son estos 2 servidores lo que gestionan casi toda la carga de trabajo dejando así al servidor principal más descansado.

Y ahora, llega ya el gran momento. Antes de utilizar HaProxy vimos que con una concurrencia de 4000 y un número de requests a recibir de más de 12K, teníamos de media, unos 30 failed requests. Pues bien, ahora, con tan sólo añadir un balanceador de carga y dos servidores, ambos de las mismas características que el servidor principal(2GB de RAM) vemos que conseguimos lo siguiente.


¡0 FAILED REQUESTS CON LA CONCURRENCIA A 5000 Y ACEPTANDO 40000 REQUESTS! Lo logramos, hemos conseguido llegar a 0 y encima aumentar la concurrencia el número de requests a recibir. Con las requests a 100000 aún obtengo algunos fallos (unos 32), pero son fallos de TimeOut que con tan sólo volver a recargar la página ya lo tendremos.



Ahora ya sí que podemos gritar lo que canta Extremoduro de "¡¿Cuánto más, necesito para ser Dios?!". Tontunas aparte, se ha comprobado como podemos aceptar perfectamente 40000 requests sin fallo o 1 como mucho con una concurrencia de 5000 (una concurrencia mayor que la que hipotéticamente recibe la UCO). Pero ya no sólo eso, podemos ampliara a 100000 requests casi sin problema y todo esto con un servidor de 2GB de RAM y dentro de un entorno de virtualización.


 Ya lo tendríamos terminado todo, pero si queremos visualizar todo esto de una forma mucho más gráfica, podemos utilizar un Log Monitor de Apache. Hay algunos como Logstach utilizando Docker que es muy interesante, no obstante tendríamos que saturar la máquina, la cuál estaría consumiendo más recursos y esto podría afectar a nuestro server.

Yo lo que he hecho es hacerme uno yo desde 0, utilizando ShellScript y generando esta web. Sí, esto está hecho con ShellScript en menos de 80 líneas de código y como vemos es algo muy simple pero que nos puede servir de ayuda y encima consumiendo pocos recursos, ya que es un sh que lanzaríamos dentro de un bucle infinito and that's all.

Se vuelve a demostrar como con configuraciones muy sencillas y una tarde, podemos sacar mucho de nuestro servidor, sólo hace falta eso, ponerse una tarde con nuestro servidor y tocar todos los archivos de configuración y probar. Es por esta sencillez, que no entiendo por qué aún muchos administradores de sistemas no tienen esto más en cuenta, pues una web no es solamente el código de la misma, una parte muy importante es el servidor, el que, como vemos, no cae.

¿Hackeamos el Mundo?

No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...