Actualización del servidor Hardlimit

[cobito]

Con la llegada de los fondos NextGenerationHL, el equipo de gobierno de esta, vuestra casa, ha decidido renovar las infraestructuras que vertebran estas nobles tierras.

Después de dos años con el actual servidor (el más rápido y estable hasta la fecha), será sustituido por la cuarta máquina que motoriza Hardlimit desde que me hice cargo del tinglado. Con el doble de núcleos y el doble de RAM, está previsto que sea capaz de procesar la pesada carga de trabajo que viene de la sección de videos además de brindar la posibilidad de ampliar las funcionalidades tanto del museo como de la central del banco de pruebas.

Aprovechando el cambio, se van a realizar las siguiente actualizaciones del software:
· Debian 11 desde la actual Debian 10.
· El foro se actualizará a Nodebb v1.18.5 desde la actual 1.4.
· La sección de videos se actualizará a Peertube 3.4.1 desde la actual 3.0.1.

Además queda pendiente solucionar un problema con Redis (base de datos del foro y caché de la sección de videos) que quedó pendiente hace unos meses cuando se actualizó a Debian 10 y que en estos momentos funciona chapuza mediante. Estoy en contacto con los desarrolladores a ver si encontramos la solución, lo cual simplificaría bastante las tareas de administración. Pero esto lo veo complicado en esta iteración.

Ahora estoy haciendo tests al hardware. Cuando lo vea claro (de aquí a una o dos semanas probablemente), procederé al cambio para el que avisaré con unos días de antelación.

[_Neptunno_]

Como siempre, mil gracias por tu incansable labor para mantener nuestro hogar operativo
Por curiosidad, ¿Que procesador y memoria tendrá el nuevo servidor? ¿Y el antiguo?

Saludos!!

[cobito]

@_Neptunno_ Pasamos de 16 a 32GB de RAM. La plataforma de momento prefiero no anunciarla

[Sylver]

Alcalde, es usted nuestra mayor fortuna cibernética jamás hallada (extensible en parte a los Admins Honoris Causa).

Eternas gracias por tanto, ¡y sinceras disculpas por tan poco!

Por muchísimos más años en línea, ¡salud!

[cobito]

Después de parón del puente, ya empiezo a hacerme una idea de las fechas. En principio la actualización tendrá lugar el fin de semana del 17 de diciembre. Con un poco de suerte, se va a solucionar el problema con Redis, que es a lo que estoy esperando. Si para ese día no se ha solucionado, se procederá a la actualización dejando la solución que hay ahora.

[QVENGADOR]

@cobito dijo en Actualización del servidor Hardlimit:

NextGenerationHL

Yo quiero que me financien un PC, ¿Donde lo solicito?

[cobito]

@QVENGADOR dijo en Actualización del servidor Hardlimit:

@cobito dijo en Actualización del servidor Hardlimit:

NextGenerationHL

Yo quiero que me financien un PC, ¿Donde lo solicito?

Tarde. Me he gastado la última partida en un rascador de marfil.

[QVENGADOR]

Me parto

[cobito]

Han sido una cuantas horas sudando pero ya está.

En principio parece que todo funciona correctamente. Si véis algo raro decidlo. Al foro parece que hay que darle una mano de pintura porque han puesto elementos gráficos nuevos que no quedan bien encajados con el CSS personalizado.

Bueno, para el que le interese qué se cuece entre bambalinas, explico un poco el tema.

El anterior servidor se elegió teniendo en mente sólo el foro y las páginas satélite sin la sección de videos. Pero las ampliaciones de funcionalidades de páginas como el museo junto a la aparición de la sección de videos, han hecho que esta máquina ya no cumpla.

El nuevo servidor es el PC de la firma con ampliación de RAM:
· Core i5-3570K.
· Asus P8B75-V.
· 4 x G-Skill F3-1600C9-8GXM (32GB en total).

Como véis, el PC es un pepinazo... de hace 8 años. Pero ¿por qué esta máquina? La principal razón es que es lo mejor que tengo disponible en estos momentos: tiene un rendimiento razonable y se ha mostrado completamente fiable. Venimos de otro Ivy Bridge pero con sólo dos núcleos y algo menos de frecuencia.

Estas son las otras razones que motivan el cambio:

1. Las dos instancias de Peertube hacen un uso intensivo de ffmpeg para transcodificar video. Esto implica mucha CPU. Cuando el video viene en 4K, consume 2-3GB de RAM. A eso hay que añadirle que la sección de videos de Hardlimit y TubEdu son dos instancias independientes, es decir, que cada una lanza su propio ffmpeg y no es raro que haya dos transcodificaciones haciéndose simultáneamente. Eso, en la CPU con 2 núcleos actual (aunque tenga HT) a veces resulta problemático para el tiempo de respuesta de otros servicios.

2. La base de datos del foro usa Redis, que reside completamente en memoria. Eso hace que la velocidad sea inmejorable (de hecho, ahora ha dado un paso importante en el tiempo de respuesta gracias al arreglo que me han hecho los chicos que llevan el proyecto [1]), pero a costa de que sólo la base de datos del foro consume en torno a 8GB de RAM (aunque con las actualizaciones, ahora parece que consume algo menos).

3. El buscador del museo usa un índice que, estos momentos, ocupa unos 1.5GB. La velocidad de la búsqueda depende de la velocidad de la unidad de almacenamiento. Para conseguir la mejor velocidad, se usa una unidad RAMDisk, con lo que hacen falta 1.5GB de RAM adicionales. Además, quiero ampliar las funciones de búsqueda con lo que voy a necesitar más gigas. Todo esto en realidad es optimizable, pero esa tarea no me apetece en estos momentos.

4. El sistema, las múltiples instancias de Apache, Nginx, el procesamiento de resultados del banco de pruebas, etc, etc, etc, hace que se sobrepasen los 16GB de RAM que teníamos hasta ahora. Por eso, la búsqueda del museo lleva unos meses deshabilitada. Y aún así, a veces me ha dado un poco de congoja porque se pone a tirar de paginación.

La nueva cantidad de RAM es suficiente para lo que necesitamos. Pero el Ivy Bridge no es la mejor opción. En primer lugar, tenemos la razón obvia: en la actualidad hay CPUs mucho más potentes. Y en segundo lugar, la eficiencia energética está lejos de ser óptima y más si se va a hacer un uso intesivo de ffmpeg (recordemos que Ivy Bridge todavía no tiene AVX2).

Pero hay que llegar a un compromiso. Por una parte, el contexto actual [2] hace que comprar nuevo hardware no sea la mejor decisión financiera posible y menos aún si tiene que ser un maquinote que no urge. Hardlimit está en las antípodas de ser un "recurso financiero" para mi, pero no quiero comprar algo ahora que probablemente en un año va a tener un precio bastante más reducido o gastar una cantidad por la que dentro de un año puedo conseguir algo mucho mejor (véase por ejemplo el precio absurdo de la memoria DDR5; eso es una obscenidad, hombre ya).

Por otra parte, los 4 núcleos Ivy Bridge van a permitir ejecutar ffmpeg en varios hilos, lo que, junto con el ligero aumento de la frecuencia de la CPU y la mejora en las latencias de la memoria, multiplicará la velocidad de transcodiciación por 2 o 3. Y esa mejora me parece más que razonable de momento.

Lo que más recursos consume ahora es la sección de videos y el foro. Del foro no cabe esperar un aumento considerable en las necesidades de RAM porque aunque aumentara la actividad, al final no es más que texto (las imágenes y demás van en disco). De la sección de videos, no se sabe. En estos momentos (y sobre todo los fines de semana) es muy demandante. Si de aquí a un año aproximadamente, la actividad ha aumentado sustancialmente, se sopesarán alternativas a la máquina actual.

En cuanto a los resultados del cambio, habrá que ver cómo se porta la máquina cuando lleguen trabajos de Peertube. El foro parece que responde bastante más rápido. Pero los grandes ganadores son sin duda los blogs gracias a la sustitución de un disco mecánico a una unidad SSD donde se almacena la base de datos MySQL.

Anotaciones

[1] Debido a un fallo en el código de Redis, la base de datos del foro estaba provocando un desbordamiento que daba un error "desconocido" en versiones recientes. Eso hacía que tuviera que ejecutar una versión antigua de Redis en una máquina virtual con una verisión antigua de Debian, con la merma de rendimiento y el consumo extra de RAM que ello suponía. La solución ha sido cambiar los tipo de datos de dos variables de "int" a "size_t" y ya no se produce el desbordamiento. Size_t es una variable de longitud igual al máximo tamaño de un vector que se puede almacenar en la máquina donde se compila el programa. Más detalles.

[2] El contexto actual incluye una crisis logística que ha tirantado la relación oferta-demanda aumentando precios en todo. El contexto actual también incluye la aparición de nuevas plataformas y tecnologías que han tenido un precio de salida más elevado del habitual (ej. DDR5).

[kynes]

@cobito Vaya currazo que te pegas. Gracias por mantener el orden en este antro