Escalamiento horizontal en Podcastvery

 Hola buenas, ¿qué tal? Aquí otra semana más en Drupalizate, el podcast donde yo, Robert Menetray, te cuento mis peripecias con proyectos Drupal. En este caso sigo con el proyecto podcastvery, que es un proyecto personal mío, donde tengo millones de nodos de datos, y la base de datos me ocupa una burrada, me quedé sin un disco en el servidor, y cómo he solucionado esto y por qué lo estoy haciendo de esta forma. Primero de todo, esto es la segunda vez que grabo este episodio, la primera me quedó muy largo, de casi una hora, así que como quiero que los episodios sean cortitos y un poco más a grano, porque últimamente me voy por las ramas, lo he vuelto a grabar. Y seguramente lo parta en dos episodios, uno hablando más de servidores, que es el que voy a hacer hoy, y otro hablando más ya de eliminación de contenidos, con gran volumen de datos, que es el que haré la semana que viene. O esa es mi idea. Así que primero de todo, para poner un poco de contexto para la gente que no haya escuchado episodios pasados, tengo una web con una base de datos de 270 GB. Por eso el servidor se quedó sin espacio, el servidor tenía unos 300 y pico gigas, no sé si eran 350 o así, no me acuerdo, pero claro, era un servidor monolito con todo. Por cierto, lo tengo todo montado con doques, tenía un docker de frontend, engines, PHP, otro docker de PHP que es para tallas Chrome, uno de Redis para el tema de las cachés, el docker de MayaDB, que es el MySQL, y otro docker de Elasticsearch. ¿Qué me ocupaba espacio en servidor? Pues el docker, o sea, los datos de MayaDB, después los datos de Elasticsearch, y después lo que eran ficheros de, propiamente, el Drupal. O sea, no solo el código, que es muy poco, sino lo que es el site de four files, que es donde se guardan todas las imágenes. Y en este proyecto en concreto se guardan las imágenes de las portadas de los podcasts, lo cual eran unos pocos gigas. No era mucho comparado con la base de datos, que eran 270, pero claro, si de 270, perdón, de 300 y pico, tengo 270 ocupados, más unos gigas de imágenes, más unos gigas en Elasticsearch, pues el servidor estaba al 90 y pico por ciento de capacidad. O sea, llegó a tal punto de que Elasticsearch no tenía espacio para escribir, con lo cual me daba errores Elasticsearch al intentar indexar contenido. Mi solución rápida fue triplico el servidor, o sea, cojo un backup del servidor que tengo, lo duplicó en dos más, y tengo tres servidores idénticos, cambio la configuración de... a ver, cómo me explico. En Hezner, en el VPS que yo estoy usando, o sea, mi proveedor de VPS, el backup es a nivel de máquina, con lo cual puedo coger un backup y duplicar una máquina y tener un clone exacto de cómo es la máquina. Pues en cada uno de esos clones, que en este momento tenía tres máquinas, pues modifique la configuración y eliminé datos que no me servían. O sea, en la máquina de MayaDB, o sea, el servidor que ya dedica solo a base de datos, eliminé todo lo que no fuera base de datos, eliminé Elastic y sus datos, eliminé Drupal y su size default files, y dejé solo MayaDB. Seguí teniendo un servidor de 300 y pico y 270 ocupados, pero ahora menos me quedaban un poco de gigas de espacio, y me daba unos días o semanas de margen. Después, el servidor de Elasticsearch, pues similar, dejé solo Elastic y eliminé los 270 de MayaDB y los size default files de Drupal. Y después, en el servidor de, digamos, de Frontend, de NGINX y PHP, solo dejé el código de Drupal y el size default files. Con lo cual, me sobraban muchos gigas. Con esto aguanté unas semanas, básicamente porque por aquí en medio estaba a tope de trabajo, o sea, es julio-agosto, hice expecta de un cliente, y como podcastvery, o sea, el proyecto este de los problemas, no lo monetizo, no lo estoy cobrando, lo hago porque quiero, pues tenía que dedicar tiempo a clientes que sí que me pagan. Así que esto fue una solución temporal, que ya sabía yo que iba a prengar 150 euros mensuales, porque si tenía un servidor de 50 euros y lo he triplicado, pues ahora tengo tres servidores de 150 en total. Y bueno, pues dije, me vale la pena, o sea, arreglo la papeleta, la web no se cae, y cuando tenga tiempo, ya iré arreglando, pues, cada semana un poco vaciando datos y después redimensionando los servidores a la baja, o sea, creando servidores nuevos, más pequeños, y optimizándolos aún más, para tener un menor coste. Vale, para hacer todo esto, lo primero fue, tengo un problema con la base de datos, me ocupa demasiado, tengo que hacer que ocupe mucho menos. Una opción es mover esto a otra base de datos, puede ser MySQL o Postgres, o lo que sea, pero que sea totalmente custom, que no dependa de Drupal, con lo cual puedo controlar exactamente qué tablas tiene que tener y con qué estructura, porque un problema de Drupal es que las tablas de las entidades, en este caso nodos, tienen su duplicado como tabla de revisión de ese campo. O sea, si tengo cuatro campos, esto ya lo comenté en episodios pasados, si tengo cuatro campos en un nodo, para cada campo también tengo su correspondiente tabla de revisiones, con lo cual tengo tablas duplicadas que pesan básicamente lo mismo, y si tengo tablas que me pesan varios gigas, las tengo por duplicado, así que de 270 gigas, la mitad eran duplicados, cosa que no veo sentido en Drupal, pero bueno, funciona así. Yo jugué que en Drupal 7 esto no iba así, pero bueno, en Drupal 8, 9 sí. Bueno, total, que tenía que mover los datos. Hice un script, o sea, en mi caso decidí moverlos a un motor de búsqueda, en este caso Elasticsearch, porque ya lo estoy usando para el tema de search API, pues aprovecho y lo uso para esto también. ¿Por qué? Porque como en este caso los datos son para temas de búsqueda, desde mi punto de vista tiene más sentido usar un motor de búsqueda especializado para temas de texto y no meterlo en una tabla gigante en una base de datos, porque sí, si lo muevo en una base de datos custom, supongamos que es un MySQL, conseguiría optimizar y que me empezase por decir algo a la mitad o un poco menos de la mitad, de las 270 gigas, pero seguiría teniendo el problema de tener una base de datos muy grande con muchos gigas. Y en este caso un motor de búsqueda como Solar o Elastic creo que está mejor pensado para tener tal volumen de datos y sobre todo para que el rendimiento en sus búsquedas sea lo mejor posible. Total, que yo me decidí por un motor de búsqueda. Hice un pequeño script que lo que me hacía es una consulta base de datos y obtienes el id y los textos que quiero meter y haces la consulta en batch a Elastic y vas moviéndolos, pues no sé si puse de 50 en 50 o de 100 en 100, va cogiendo los datos de base de datos y me los mueve, me los copia mejor dicho a Elasticsearch y justo después lo elimina o intenta, perdón, elimina el nodo, elimina de la base de datos en Drupal, elimina la entidad una vez ya sea migrador contenido a Elastic. Eso lo voy a comentar mejor la semana que viene, pero que sepáis de que tuve que desactivar el código, o sea comentar el código que eliminaba porque me daba problemas graves de rendimiento y me bloqueaba la base de datos. O sea, estuve investigando y básicamente es cuando se elimina una entidad en Drupal, digamos que es una tarea muy pesada que hacen muchas consultas a base de datos y si en mi caso estoy teniendo varias tallas cron que están eliminando en paralelo muchos, pero muchos nodos al mismo tiempo, esto lleva a un bloqueo de base de datos básicamente y es por la eliminación, no por la query del select que coge los datos y después me los mueve Elastic. Así que la opción rápida fue modificar el código para evitar que el siguiente en bucle, o sea, lo que hacía yo es una vez se elimina, hace otra vez la siguiente, si vuelvo a correr el script y como se han eliminado los antiguos, pues coge ordenado por id o ordenado por fecha, no me acuerdo como lo hice, creo que fue por id, pues coge los siguientes, porque claro, si ya no los elimino, pues el código entra en bucle, así que modifique el código para que no entres en bucle, no eliminase los nodos y que los fue moviendo todos. Trado unos días y estuvo todo movido, tuve que hacer código, que es el que voy a comentar la semana que viene, que es cómo eliminar tal cantidad de nodos, pero bueno, eso como digo la semana que viene. Llegados a este punto, tenía un Elasticsearch que pasó de unos 18 GB que tenía antes a 70. Y me digas, coño, pero si antes has dicho que tenías 270 GB, si lo has movido todo, ¿cómo puede ser que sólo tenga 70? Pues como he dicho antes, la mitad, más o menos, es contenido duplicado, así que en verdad no son 270, son bastante menos. Después aproveché este movimiento de contenido y el script lo que hacía también era limpiar un poco, había campos que no moví y los que sí que se movían los limpié de HTML para asegurarme que no había ninguno con HTML, porque habían campos que se habían importado, o sea, valores que se habían importado hace mucho tiempo que en las primeras versiones sí que se importaban con HTML y también se importaban todo el texto lo que hubiera, no se cortaba por número de caracteres. Y ahora mismo lo que hice fue, pues, limpiéme todo el HTML para que tenga menos, el valor sea más corto y después además cortamelo a partir de no me acuerdo qué cantidad de caracteres, no sé si le puse mil caracteres o algo así. Basicamente es que yo tengo el texto, pero tampoco quiero tener la biblia en verso para cada episodio que esté poniendo, porque hay gente que pone mucho texto en los episodios, así que, por esto, hice una limpieza general del contenido que tenía que estar en Elasticsearch, con lo cual, al final, conseguí tener de cuarenta y pico millones de nodos, 46 millones de nodos, sólo 70 GB en Elasticsearch, o sea, la mejora fue, bueno, contundente, digamoslo así. Cuando ya tuve movido todo esto y lo que comento la semana que viene que es eliminar los nodos en Drupal, en MySQL, en MayaDB, conseguí tener, después de la eliminación, 23 GB de base de datos, según phpMyAdmin. Si mirabas en disco, decía que tenía 70 GB, con lo cual, ¿qué está pasando? Dice que en el directorio de MayaDB, en disco, tengo 70 GB, pero php me dice que la base de datos pesa 23, aquí hay algo raro. Básicamente, después de eliminar, de hacer un node de delete, eliminar nodos, tienes el problema de que, bueno, la tabla se tiene que optimizar, digamos, ha quedado fragmentada, es como lo de antaño que se fragmentaron los discos, pues muy similar. Tenemos tablas que se tienen que optimizar para que ocupen lo que realmente deberían ocupar. Esto es muy simple, vas en phpMyAdmin y le marcas de que optimiza tablas, o haces directamente la consulta, lo puedes poner también en un juego de update en Drupal, y me suena que en Drupal hay módulos que te permiten tener una talla de cron que va optimizando las tablas también, esto ten en cuenta. Pero bueno, esto, que yo en mi caso entré en phpMyAdmin y le di a optimizar tablas. Tardo un rato, pero lo hizo. En mi caso en concreto, no lo hice de la base de los entera en general, sino que lo hice agrupando campos, pues los que pesaban menos, o sea, campos, perdón, tablas. Las tablas que pesaban menos, pues 10 o 20 tablas de golpe para optimizar, pero las tablas que sí que pesaban varios gigas, que además justamente eran las que estaban más fragmentadas, como puede ser la tabla de node, que es donde se guardan los IDs de todos los nodos, o el node.fillData, que se guardan algunos campos allí, algunos valores allí, pues esas tablas pesaban pues unos gigas. Creo que la que pesaba más de memoria eran unos 5 o 6 gigas, creo, quiero recordar que eran esto. Bueno, total, de estas pues ejecutaba el optimize de MySQL solo para esa tabla en concreto. Trataba unos segundos o algún minuto, pero la acababa haciendo. Cuando tuve ya todas las tablas de MySQL optimizadas, pasó a pesar todo esto 12 gigas en disco y en Pachib Miami pesaban lo mismo, cosa que es lo correcto. Así que, digamos que después de mover todos los datos y eliminarlos y optimizar la base de datos, pasé de tener 270 gigas en MayaDB a solo 12. Para que os imaginéis la tontería esta de meter muchos nodos, lo que ha involucrado. Así que ahora mismo tenía una base de datos que sigue pesando mucho para ser una base de datos, o sea, para mí 12 gigas en MySQL lo sigo encontrando, bueno, un poco demasiado, pero bueno, pensemos de que sigo teniendo millón y medio de nodos dentro, que son los podcasts que tienen también sus propios campos. Así que sigo teniendo una cantidad relevante de datos, no tanto como antes, que eran 46 millones más un millón y medio, ahora solo tengo un millón y medio. Con todo esto, ya puedo redimensionar a la baja los servidores. Redimensionar a la baja los servidores, en el caso de Hezner, como el disco en servidor tenía 300 y pico en cada uno de los tres servidores, Hezner no me deja redimensionar a un servidor más pequeño en disco, con lo cual lo que se tendría que hacer es crear un servidor nuevo, configurarlo todo con los docks y la misma configuración que tocaría para cada uno de ellos, o sea, el servidor de MayaDB tenía que tener el mismo docker MayaDB, y después yo hacía un rsync, que es el comando de Linux para sincronizar directorios, y lo puedo usar entre servidores distintos conectando por SSH, pues usaba esto para copiar los contenidos de un directorio a otro, con lo cual tuve que apagar momentáneamente el servidor, o sea, los dockers, para que no hubieran escrituras en los ficheros de base de datos, en este caso, o de las ticserts, y hice un rsync para sincronizar los datos. Aquí un truco, puedes hacer un primer rsync, aunque la web está encendida, o sea, que el Drupal está escribiendo en base de datos, se van a sincronizar, pues pongamos por el hecho de 12 gigas, después en un momento, cuando ya esté todo esto hecho, apagas un momento la web, o sea, no el servidor, sino los dockers, para que el docker, o sea, no se escriban base de datos, no se escriban el astics, y vuelvas a hacer el rsync. El rsync no va a copiar todo otra vez, va a comparar qué fichos han cambiado y va a sobreescribir solo esos fragmentos que han cambiado, no todo el fichero, lo cual es bueno, porque si ya has copiado 12 gigas y solo se han modificado, pues, 200 megas, el rsync va a ir muy rápido y solo va a copiar esos 200 megas. Es una opción muy rápida para hacer sincronización pues de bases de datos, o de ficheros, o de elastics search, por ejemplo. Y es como lo he hecho yo, al final es que tres servidores mucho más pequeños, en uno de ellos puse un volumen, que es el caso de elastics search, para que si tengo un elastics search que me pesa 70 y algo gigas, y hay previsión de que en un futuro pueda crecer, pues tengo que tener un servidor mínimo con 70 gigas en disco, o un servidor muy pequeño de 20 gigas y un volumen, aquí sí, más grande. Y escalar un servidor es más caro que escalar un volumen de disco. Por eso el caso de elastics search lo he hecho como un volumen de disco. Una cosa ten en cuenta de los volúmenes, al menos en gessner, es que no se contemplan para el tema de los backups. Los backups que me hace gessner no se hacen con los volúmenes. O sea, si pasa algo, los datos que tengo en el volumen se pierden. En este caso en concreto, en mi caso, lo que tengo en elastics son datos que puedo recuperar, aunque no tenga backup, son datos, digamos, open data. Cojo los feeds y cojo datos que están en los feeds de los podcasts. Así que si llegase a pasar algo, puedo reindexar los feeds, tardaría un tiempo, pero volvería a reindexar otra vez los contenidos que tenía antes en elastics. Así que, entre comillas, no me hace falta un backup o no me preocupa mucho que se me rompa el volumen de elastics. Lo puedo regenerar siempre que yo quiera. Como digo, tardará unos días, pero bueno, en mi caso es factible. Hay proyectos, por ejemplo, tener un volumen solo para MayaDB, para la base de datos, sí que no lo veo factible justamente por este motivo, que si pasase algo no tendría un backup de la base de datos. Con lo cual, en mi caso, prefiero tener un backup del servidor entero de la base de datos y que esté todo incluido, no tener un volumen suelto por ahí y montarme un sistema de backups, porque para un side project no le veo sentido. Si fuera un proyecto mucho más grande donde si quería cobrarse, pues ya me lo miraría, pero para este caso en concreto, en mi caso, no le veo sentido. Vale, dicho esto, ¿qué me cuesta la broma? Pasé de tener antes un servidor de 50 euros mensuales a tener tres idénticos de 50 euros, con lo cual estará pagando 150 al mes. Ahora tengo tres servidores mucho más pequeños, uno de 6.40 euros, otro de 6.40, que son el de Elastic y el de MayaDB, son idénticos en potencia, y después el servidor más pequeño, que es el de PHP, que es el que tiene pues PHP, el cron y el que tiene pues en Jinx, al final digamos el de Frontend, también tiene Redis, o sea, al final es todo lo que no sea ni Elastic ni MayaDB. Este cuesta 4.40, con lo cual tenemos 6.40, 6.40, 4.40. Aquí se le suma un volumen de Elastic de 4 euros al mes, que son 100 gigas de disco, y lo puedo ampliar fácilmente, y es mucho más barato que ampliar un servidor, o sea, pues lo he puesto como un volumen. Con lo cual, en total, y incluyendo los backups, me sale más o menos unos 24 euros al mes. Recordemos, venía de un único servidor de 50 al mes, ahora tengo 3 por 24 al mes, y con mucho más disco que antes, y más optimizado, pero esto ya no es por temas de servidor, esto es por temas del código. Pero esto, que al final es, por eso hay mucho más la cuenta, en vez de tener un monolito en un único servidor, digamos, sobredimensionado, en potencia, o sea, en CPU, RAM y disco, por eso hay más la cuenta, tener varios servidores bien equilibrados, y que la infraestructura esté mejor pensada, como en este caso, que al final me sale más la cuenta, y es más flexible, y tengo más disco, y lo puedo escalar más fácil que antes. Esto al final es lo de escalamiento horizontal, tener varios servidores al mismo tiempo, con distintos servicios, y hasta por 10, si es que me interesa, sé que ahora mismo no, pero podría tener, por ejemplo, pues dos servidores de baseados, para hacer, por ejemplo, tener un maestro y un esclavo, o por ejemplo tener varios de frontend con Apache, o que manía con Apache, con NGINX, y si tuviesen muchas visitas, equilibrar la carga en varios servidores de frontend al mismo tiempo. Esto ya depende del proyecto, de si tienen muchas visitas, si la carga de trabajo son las visitas, o si la carga de trabajo, por ejemplo, en mi caso, puede ser las tallas cron, que están indexando contenido, pues podría tener otro servidor solo para tallas cron. En mi caso no lo he hecho así, porque ahora mismo no llegó a que me haga falta, y por tema de costes, he decidido agarrarme 6 euros al mes, y tener un único servidor con todo lo que es PHP y NGINX. Pero bueno, esto sería muy fácil, ahora que está todo esto ya montado de esta forma, bueno, pues moverlo, y tener un servidor más, solo con tallas cron, por ejemplo. Vale, y ¿qué más? Ah, y otra cosa más que no he comentado. Otra optimización que he hecho es eliminar las imágenes, o sea, los side default files que tenía en Drupal. Los podcasts, cada uno tiene su portada, su imagen, que son portadas de 3000x3000, que es el tamaño que recomienda Apple Podcast. Eso significa que tenía imágenes, no de 3000x3000, porque cuando yo la copiaba en mi servidor, la escalaba a, creo que eran 400x400, o algo así. Pero bueno, seguí teniendo muchas imágenes, con lo cual eran varios gigas. Viendo de que estaba optimizando temas de disco, me puse, modifique el código, y aunque, digamos, a ver cómo lo explico, en vez de que Drupal muestre una imagen ya del mismo servidor, con lo cual es muy rápido mostrar una imagen de 400, o sea, una imagen optimizada a un menor tamaño, y además que viene del mismo servidor, se muestra mucho más rápido esto, que no decirle que te coja una imagen de un servidor externo, que vete a saber tú cuál es, porque cada podcast tiene el suyo, y además que es una imagen que no está optimizada y que pesa, pues, 3000x3000 píxeles de ancho y de alto. Pero bueno, a finales optimizo mis costes y mi espacio en disco, y que la web vaya un poco más lenta en el front-end, pues, entre comillas, es aceptable. ¿Qué implica esto? Pues que si tengo usuarios que lo ven desde el móvil, se van a estar descargando imágenes mucho más grandes de lo que realmente me hace falta. Pero bueno, a finales, para este tipo de proyecto, he optado por dejar de usar el sistema de fichados en Drupal y solo usar imágenes externas. Una cosa, que lo puse que usar las imágenes lazy, o sea, lazy-loat, o sea, las cargas que han diferido, para intentar que afecten lo menos posible a la experiencia de usuario. Aún así, la experiencia es peor que lo que había antes, pero tampoco es tan mala. Y como digo, en mi caso, he optimizado, en este caso en concreto, por el tema de costes y de mi espacio en disco. En un futuro puedo volver a cambiar, si es que veo que el proyecto este tiene mucho éxito, y que me lo vuelva a guardar todo en disco. Pero bueno, no creo que pase. Dale, cosas a comentar, que ya llevo 20 minutos hablando, para acabar con el tema de servidores. El escalamiento horizontal es muy interesante. Da más trabajo para configurar todo, pero una vez lo tienes hecho, puedes adirte más a cuenta que un único servidor con todo. Después, rectificar una cosa con Hearthner. Comenté que sí que te cobran lo que es el tráfico entrante. O sea, mi web o mi servidor hace una consulta a un feed de un podcast, obtiene los valores del feed y los guarda en base de datos o en Elastic. Ese obtener datos de servidor externo, ese tráfico entrante, no me lo cobra. Yo pensaba que sí, y Hearthner no me cobra. Sólo me cobra el saliente. O sea, cuando alguien navega por mi web y mi servidor le está enviando la respuesta HTML, el CSS, las imágenes etc. Ese sí que me lo cobra. Bueno, está incluido dentro del precio, pero si me pasasen de los 20 teras, que no me los paso, me lo cobran. Lo recalco porque esto lo comenté en episodios pasados y dije que sí que me lo cobraban y no, es mentira, no me lo cobran. Después, tema de que Hearthner va a subir precios, me enviaron un mail justamente de que ahora en septiembre, por temas de la inflación y de que la electricidad es más cara, bla bla bla, el coste del servidor va a subir. O sea, si lo creas antes de septiembre, vas a tener menor coste que si los creas después de septiembre. Van a mantener el precio durante creo que hasta enero. Es una cosa a comentar, supongo que otros VPS van a acabar subiendo costes. Recordemos que al final en Europa sobre todo el cambio de la moneda, el euro-dólar, y después la inflación, y después el coste de la luz, se ha disparado todo. Así que lo encuentro relativamente normal que se tenga que subir precios, por desgracia. ¿Qué más? Temas de límite de cuentas. En Hearthner, con todo este movimiento que tuve que hacer de duplicar servidores, tuve el problema de que la cuenta que tenía yo, que es la que viene por efecto las tantas, tiene un límite de 10 servidores. Yo tenía que hacer todo esto un sábado, o sea, el de duplicar servidores y estas cosas, y como tengo otras webs, tengo otros servidores en mi cuenta, me salió el aviso que yo no sabía que existía, de que no puedo porque tengo ya 10 servidores. Y fue un ¡ah, mierda! Tuve que ponerme en contacto con Hearthner, estos me respondieron con un mail el lunes, con lo cual el fin de semana estuve parado, y me preguntaron de por qué, yo por qué quiero crear más webs. Me dijeron ¡ah, vale, perdón! Me ampliaron el límite, ahora tengo para 20 servidores, y ya está. Y el sábado siguiente volví a intentar el tema de escalamiento horizontal y ya pues ya pude. Lo comento porque si tienes previsto hacer x día un escalamiento horizontal, sé previsor y revisa de que no tengas un límite en la creación de servidores en tu proveedor, como es mi caso. Basicamente porque me jodió una semana de trabajo, entre comillas, o sea, yo tengo el fin de semana para trabajar en un proyecto personal, y lo pensaba hacer el sábado, y como no pude hasta el lunes y me contestaron, pues solo pude el sábado siguiente. Es una excusa más para estar dando más de la cuenta por esto. Lo comento porque supongo que en digital a mí no me suena, digital o sea, no me suena que estuviera en ese límite, pero creo que tampoco llegué a tener más de 10 servidores, creo recordar, pero bueno, esto te lo comento para que lo tengas en cuenta. Después, temas de volúmenes, también tuve problemas de que me estuve como 4 o 5 horas peleándome con el servidor de Elasticsearch para añadirle un volumen, y al final fue, creo, porque coger un backup de un servidor existente, duplicarlo, y después meterlo en volumen, no sé por qué volumen no lo reconocía. Yo pensaba que era la configuración mía mala, y no. Al final fue crear un servidor nuevo desde cero y añadirle un volumen, y ahí sí que funciona todo bien. Creo que al hacer un backup de uno usando un backup externo, creo que se quedó tonto y no me reconocía que ese volumen podía estar dentro de ese servidor. Lo comento porque estuve unas cuantas horas hasta que dije, vísteme despacio que tengo prisa, lo hacemos todo desde cero, a mano, y funciona bien. Así que bueno, otra cosa a tener en cuenta, al menos en Hexner, que el tema de volúmenes no va siempre como, no va bien a la primera, al menos. Y ya para acabar, el tema de monitoraje o, si no sé cómo es la palabra, gestión de infraestructura, de servidores. En mi caso yo uso New Relic, hasta hace poco tenía la versión gratuita, por temas varios me he puesto la de pago, pero la gratuita te sirve de que puedes tener, instalar un Docker, en mi caso lo uso con Docker, un Docker de infraestructura de New Relic, y se enviará datos de CPU, de RAM, de disco, y hasta de tráfico saliente, o de, por ejemplo, SQL Actual en disco, y esto se envía a New Relic. Con lo cual puedes tener un panel de control donde ves todos tus servidores, con el nombre que le hayas puesto, pues en mi caso en el contenido Docker, yo le pongo el nombre de dominio, y puedo ver si una web se está quedando sin disco, si una web tiene un consumo de CPU muy alto o muy bajo, con lo cual me permite ver si vale la pena redimensionar a la baja, porque por ejemplo hay muy pocas visitas y no hay apenas consumo de CPU y RAM, y puedo ahorrarme la mitad del coste y redimensionar la máquina a la mitad, por ejemplo, o al revés, si tengo un consumo de CPU muy alto, de normal, pues la máquina se está quedando corta, la tengo que aumentar. Y además, New Relic permite enviar mensajes automáticos, en mi caso a Slack, con lo cual cuando la máquina se queda sin disco, o la CPU se dispara, o la RAM se dispara, me envía una notificación a Slack de, ¡ey!, que esta máquina se está quedando sin disco. Otro tema es que yo le haga caso, porque por lo que me pasó de que me quedé sin disco, y las alertas me fueron saliendo a 80, a 85, a 90 y a 95, pero así iba ignorando, porque bueno, mañana ya me pongo, y al final no me puse, y fue un, bueno, tengo que arreglar esto triplicando los servidores y evitando de esta forma que unas semanas, o sea, obteniendo unas semanas de margen para arreglar el problema. Pero esto, que recomiendo mucho tener un sistema de monitoraje de servidores, porque me sorprende que con algunos clientes no lo tienen y después no saben de que la web se ha caído y ni se enteran, ni por cuál es el motivo, ni si está caída o no, hasta que tienen que editar algo, entran a la web, ¡ay!, que la web no me responde, ¿cuánto lleva caída?, no lo sé, quizá lleva una semana, a saber, porque tenemos un ataque de negación de servicios, por decir algo, o sea, puede ser. Bueno, nada más, que como siempre me arraso. La semana que viene hablo del tema de eliminación de mucha cantidad de nodos, qué problemas hay y cómo los he solucionado yo, ¿vale? Y también, si me da tiempo, hablar de soluciones que me dieron la audiencia de este podcast, que hubieron tres personas que me comentaron cosas que creo que es bueno que la audiencia sepa, pero como hoy no me da tiempo, ya la semana que viene. Chao.