domingo, 1 de julio de 2018

Por qué falló la web de la Universidad de Córdobael día de Selectividad

Ayer comenté que, tal y como predije, la web de la Universidad de Córdoba iba a fallar el día de las notas.Realmente, la solución o soluciones son sencillas y no vale la excusa de "es que es mucho tráfico", no, ya que Amazon por ejemplo, aguanta el tirón en cada Black Friday y es tráfico internacional.


Alguno puede decir que Amazon y la UCO son distintas ya que la UCO no tiene la pasta que tiene Amazon para garantizar la disponibilidad de sus sistemas, y eso es cierto, pero en parte.



Es cierto en parte ya que aunque la Universidad no vaya a registrar esas 640 visitas por segundo tal y como alcanzó Amazon en el Black Friday 2016 a las 10:47, sí que se puede mejorar la disponibilidad de los sistemas para ofrecer los servicios a los usuarios sin necesidad de gastar mucha pasta.


Primero tenemos que averiguar qué tipo de servidor web están utilizando, y vemos que están utilizando un servidor nginx en su versión 1.8.


Si nos vamos a los CHANGES de su versión stable más moderna {la 1.14.0} vemos que pegan un salto entre la 1.7.12 que va a la 1.9.0 olvidando a la versión 1.8.0 que es la versión del servidor web. No obstante, en la versión 1.9.0 vemos que se han realizado bastantes cambios, cambios y mejorías que el servidor web de la UCO no tiene implementados, por lo que ya vamos mal.

Pero si nos paramos a pensar la intención con la que se creó nginx y vemos lo que sucede, no tiene mucho sentido. Nginx fue creado sobre todo para webs que ofreciesen contenido dinámico y está listo para soportor una gran cantidad de tráfico, y es aquí donde ya tenemos la primera incoherencia.

En el post sobre Hardening de servidores GNU/Linux en entornos GLAMP ya dije que una web es mucho más que el servidor web en sí. Una página web es código PHP, una base de datos, el servidor web, el hosting y con quién lo tienes contratado, el sistema sobre el que lo has montado y un largo etc.

Sobre el sistema podemos comentar que está montado sobre un CentOS, pero poco más sabemos de cómo se instaló y con qué particiones tiene, así que no puedo decir mucho.

Con la extensión Wappalyzer también pude ver que la versión de PHP es la 5.4.16 cuando sabemos que la release más actual es la 7.2.6. La versión 7 de PHP trae importante mejoras con respecto a la versión 5.X, en este artículo se exponen 10 de las mejores, entre la que está que es mucho más rápido optimizando el uso de memoria, mejorando la capacidad de manejar los fatal errors que no eran fáciles de manejar previamente con PHP y que ahora con el nuevo motor de excepciones {Engine Exceptions} facilitará el trabajo o que  con una funcionalidad que a mí me atrae mucho que es el three-way comparison operator y que se usa para comprobar si algo existe o no. Aquí una foto del benchmark de PHP7.


Insisto mucho aquí ya que es de las pocas cosas de las que más información puedes sacar tras una ojeada rápida de la web de la UCO.

Otra parte importante sería saber qué gestor de bases de datos se está utilizando. Aquí no lo puedo saber, no he sacado esa información y sería interesante conocer si se está utilizando MySQL o MariaDB y qué versión de cada, ya que MariaDB10 en rendimiento es un 11 sobre 10.

Tendríamos que mirar también la configuración de Nginx y de la base de datos y que el número de clientes que se permite en un lado sea igual que en la configuración del otro servicio, esto es importante para no crear cuellos de botella.

Hay muchas cuestiones a tener en cuenta y sin ver nada del servidor es complicado tomar una decisión realmente, aunque con lo expuesto en este post, si la UCO realizase esos cambios de, por ejemplo, migrar de PHP 5.X a PHP 7, actualizase Nginx y mirase bien los archivos de configuración de sus servicios web y de bases de datos.

Al fin y al cabo la UCO recibió matrículas de 4122 alumnas y alumnos y eso es algo que se puede contener con relativa facilidad ya que en pruebas con servidores que yo mismo me he montado en VM con pocos recursos he llegado a hacer pruebas de stressing con la herramienta ab de Apache-utils y llegar sin problemas a más de 1500 conexiones simultáneas, que parece poco en comparación, pero es más de un 1/3 de las conexiones como máximo que ha podido soportar la UCO.

También es un poco iluso que me digan que las 4000 personas que se examinaron accedieron a la web a las 12:01 minuto. A esa hora accederían muchas de ellas, pero 4000 no. Aún así, si con una máquina con recursos bajos-medios en una VM y bien optimizada en un proceso de Hardening ha soportado más de 1/3 de conexiones ¡coño, seamos inteligentes! Divide la web tal y como lo hizo la Universidad de Cádiz.


La Universidad de Cádiz dividió la web en 2, y es que puedes tener una web incluso en una red, y otra web en otra, al fin y al cabo te llevas la base de datos en un .sql y con source [nombre base de datos].sql importas la misma en un momento. Así hasta que ahorras posibles saturaciones en la red. Se me ocurre incluso que entre esas redes, pongas ACLs que permitan el tráfico desde 0.0.0.0 pero no desde esas redes en las que están los distintos servidores.

También intuyo que posiblemente tengan la base de datos y el servidor web en distintas máquinas. Si es así, las cosas como son ¡Ole! Pienso así porque la web no se caía y es muy posible que lo que se estaba cayendo fuese la base de datos. No obstante, en caso de ser así, al menos que la tuviesen en la misma red para que a la hora de realizar la consulta de base de datos pase por el switch en lugar del router, que es el que tiene la IP pública y el que puede estar saturado de consultas.

Hay muchas cuestiones a tener en cuenta y que no son complicadas de revisar, que es lo que más rabía te puede dar. Ves a gente con doctorado mirando por encima del hombro a gente como yo de Grado Superior pero que no tienen ni idea de administrar un sistema.

Ya he dicho que la excusa de "son muchas consultas" no vale, ya que 4000 conexiones se pueden controlar sin mayores problemas. Aún así, quiero ver cómo reacciona la web de la Universidad en septiembre, donde tendrán menos participación ya que el examen de junio lo han aprobado un 94.5% de los alumnos y en septiembre, por lo general se suelen presentar menos personas. Una prueba es esta noticia de la propia Universidad de Córdoba donde dijeron que en septiembre del 2017 se presentaron 914 estudiantes a las pruebas de Selectividad. Quiero ver en septiembre cómo se comporta el servidor, y si aún así se cae, eso ya no es fallo del número de conexiones, es porque se han podido dejar todos los valores por defecto en los archivos de configuración de todos los servicios.

En septiembre veremos qué pasa, hasta entonces toca esperar y de paso lo dejo por escrito para que si alguien de la Universidad me lee-que sé que me leen- lo cambie antes de las pruebas de septiembre.

¿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...