TPTito Pinardo Gutiérrez
← Volver al rack
English
1U · GAMESAMP · Velocity · ZFS en espejo En producción

Posición 11 de 25 en el rack · En producción

Unidad 1U · Comunidad

AMP · servidores de juego

Escrituras ×8,8 sin comprar hardware

Minecraft con mods, otros Minecraft detrás de un proxy y juegos de Steam para los amigos, gestionados desde un panel. Lo que se abre a internet depende de lo que está encendido: al arrancar un servidor se crean su regla en el router y su nombre en Cloudflare, y a los 3 minutos de apagarlo desaparecen.

Por qué tanto cuidado
Es lo único del homelab con puertos de juego abiertos a internet. Cuantos menos y menos tiempo, mejor.
Cómo entran los Minecraft
Todos por un mismo puerto, el de un proxy que elige el mundo según el nombre con el que entras.
Rendimiento
Los discos tenían la caché de escritura apagada de fábrica, la CPU repartida entre dos procesadores y Java mal ajustado. Todo corregido sin gastar.
  • 108 → 946escrituras por segundo con fsync
  • 1 minen abrirse router y DNS al encender
  • 3 minapagado antes de cerrarlos
  • 17 díasde copias vacías que nadie había visto

Su código, en abierto Versión pública del repositorio: sin IPs ni secretos.

Los servidores de juego por dentro

Encender un servidor en el panel abre el router y el DNS solo; apagarlo los cierra. Elige un recorrido.

Recorridos Pulsa uno y sigue el paquete.

Fuera Contenedor de AMP · Proxmox una instancia Docker por juego Entrada Servidores Rendimiento Cuidados Jugadores Router Cloudflare Publicador Discord Web pública Panel del bot Hipervisor Proxy Velocity Cortafuegos Panel AMP Bot de estado Minecraft mods Otros mundos Juegos Steam Gestor Discos SAS CPU fijada Java Caché ZFS Usuarios Copia 30 min ¿Es válida? Zabbix
Hermesde visita en la unidad

Pulsa una pieza o elige un recorrido. Si vienes de una habilidad, ya están encendidas las piezas donde la uso.

      Enciendo un servidor
      1. Panel de AMP — Enciendo un servidor desde el panel.
      2. Gestor de instancias — El gestor arranca su contenedor.
      3. Minecraft con mods — El servidor carga el mundo.
      4. Publicador automático — Al minuto, el publicador ve que está encendido.
      5. Router — Crea su regla en el router, solo con los puertos de juego: nada de consola ni administración.
      6. Publicador automático — Y su nombre…
      7. DNS en Cloudflare — …en Cloudflare.
      8. Los amigos — Un amigo escribe ese nombre en el juego.
      9. Router — Entra por el router.
      10. Proxy de Minecraft — El proxy mira el nombre y le manda a su mundo.
      11. Minecraft con mods — Está dentro.
      Lo apago
      1. Panel de AMP — Apago el servidor en el panel.
      2. Gestor de instancias — El gestor para su contenedor.
      3. Publicador automático — El publicador espera 3 minutos, por si es un reinicio.
      4. Router — Quita la regla del router.
      5. DNS en Cloudflare — Y el nombre de Cloudflare. No queda nada abierto.
      Una partida
      1. Los amigos — Un jugador se conecta.
      2. Router — Entra por el router.
      3. Cortafuegos del contenedor — Pasa el cortafuegos del contenedor, que solo admite los puertos declarados.
      4. Proxy de Minecraft — El proxy lo manda a su mundo.
      5. Minecraft con mods — El servidor guarda el mundo cada poco.
      6. Cuatro discos en espejo — Las escrituras van al espejo de discos, ahora con caché: 8,8 veces más rápidas.
      7. Caché de ZFS en RAM — Las lecturas casi siempre salen de la caché de RAM.
      8. Minecraft con mods — El servidor responde.
      9. Proxy de Minecraft — Por el proxy, que comprime una sola vez.
      10. Los amigos — Y al jugador.
      Los amigos miran qué hay en Discord
      1. Panel de AMP — El panel sabe qué servidores están encendidos y cuánta gente hay en cada uno.
      2. Bot de estado — El bot se lo pregunta cada poco, con un usuario de solo lectura y por la red interna.
      3. Discord — En el canal de Discord, cada servidor tiene su mensaje: encendido o apagado, quién está dentro, la dirección y su carátula. El bot lo edita cuando algo cambia, sin llenar el canal.
      4. Los amigos — Un amigo ve que hay gente jugando y le apetece entrar.
      5. Discord — El título del mensaje enlaza a la página del servidor para conectarse directamente o copiar la dirección; si esa página no sirve, a la web.
      6. Router — Entra por el router, que tiene abierto ese puerto porque el servidor está encendido.
      7. Proxy de Minecraft — Y el proxy le lleva a su mundo.
      Un servidor nuevo sale en la web y en Discord
      1. Panel de AMP — En el panel de AMP le pongo a un servidor su dirección pública.
      2. Bot de estado — El bot lo ve en su siguiente consulta: dirección, juego, carátula y botón de Steam salen de lo que ya sabe AMP.
      3. Web pública de los servidores — El servidor aparece solo en la web pública, en su sección (Minecraft, juegos con varios servidores, Steam u otros). Todavía sin mensaje en Discord.
      4. Panel de gestión del bot — En el panel del bot, solo desde casa o la VPN con doble factor, sale en «Publicados desde AMP» con el botón «Añadir al bot».
      5. Bot de estado — Al añadirlo, el bot lo da de alta: si le pongo dirección o carátula propias, mandan sobre las de AMP.
      6. Discord — Y empieza a publicar su mensaje de estado en el canal de Discord.
      7. Web pública de los servidores — En la web, el servidor ya tiene su ficha completa: «Copiar» la dirección y «Conectar con Steam».
      8. Los amigos — Los amigos lo encuentran en la web o en Discord, sin que tenga que avisar a nadie.
      Un corte de luz
      1. Hipervisor — Se va la luz y el servidor se apaga de golpe.
      2. Fichero de usuarios — AMP estaba escribiendo su fichero de usuarios: se queda vacío.
      3. Copia cada 30 minutos — Pero cada 30 minutos se copió desde fuera del contenedor.
      4. Comprobar la copia — La última copia válida (no vacía, JSON de verdad) se identifica sola.
      5. Fichero de usuarios — Se restaura con el panel parado.
      6. Panel de AMP — Y el panel vuelve con todas sus cuentas.

      1. Los amigos

        Desde sus casas, con el nombre del servidor.

      2. Router

        Solo tiene abiertos los puertos de los servidores encendidos, con reglas creadas por la automatización.

        • MikroTik

      3. DNS en Cloudflare

        Un nombre por servidor, que solo existe mientras está encendido. Sin proxy: los juegos no hablan HTTP.

      4. Publicador automático

        Cada minuto pregunta al panel qué está encendido y ajusta router y DNS. En el router solo puede tocar sus propias reglas.

        • Python
        • MikroTik

      5. Discord

        Un canal donde cada servidor tiene su mensaje de estado: encendido o apagado, quién está dentro, la dirección y el enlace para entrar.

      6. Web pública de los servidores

        Una sola página con los servidores en vivo, agrupados por juego, con «Copiar» y «Conectar con Steam», quién está en Discord y las normas. No enlaza al panel de AMP.

        • JavaScript / TypeScript

      7. Panel de gestión del bot

        Solo desde casa o la VPN, detrás de la puerta interna con doble factor. Desde aquí se dan de alta los servidores que AMP ya publica y se edita cómo salen.

        • Linux / SSH hardening

      8. Hipervisor

        Corte de luz incluido: sin SAI, el servidor se apaga de golpe.

        • Proxmox VE
        • ZFS

      9. Proxy de Minecraft

        Un solo puerto para todos los Minecraft: según el nombre con el que entras, te manda a un mundo u otro.

      10. Cortafuegos del contenedor

        Entrada bloqueada salvo los puertos declarados. El panel los sincroniza cada cinco minutos; el panel y SSH, solo desde casa.

        • Linux / SSH hardening

      11. Panel de AMP

        Desde donde se encienden, apagan y configuran los servidores. Ya no se publica en internet.

        • Docker

      12. Bot de estado

        Lee el panel con un usuario sin privilegios y mantiene al día los mensajes de Discord y la web pública.

        • JavaScript / TypeScript
        • Docker

      13. Minecraft con mods

        El servidor principal, con casi noventa mods, varios de ellos de rendimiento.

        • Docker

      14. Otros Minecraft

        Mundos más pequeños, detrás del mismo proxy.

        • Docker

      15. Juegos de Steam

        Servidores dedicados que se encienden cuando alguien quiere jugar.

        • Docker

      16. Gestor de instancias

        Cada servidor es un contenedor Docker propio. El gestor los arranca, los para y los actualiza.

        • Linux (Debian, Alpine, Arch)

      17. Cuatro discos en espejo

        Venían con la caché de escritura apagada. Encendida y guardada en el propio disco: las escrituras con fsync, de 108 a 946 por segundo.

        • ZFS
        • Linux (Debian, Alpine, Arch)

      18. CPU en un solo procesador

        El hipervisor daba hilos de los dos procesadores: Java tenía la memoria en uno y el trabajo en otro. Ahora el contenedor usa seis núcleos de uno solo.

        • Proxmox VE
        • LXC

      19. Java ajustado

        Memoria reservada desde el arranque, páginas grandes y sin limpiezas forzadas cada 5 segundos. La compresión, solo una vez: en el proxy.

      20. Caché de ZFS en RAM

        Ya servía más del 98 % de las lecturas: no hacía falta tocarla.

        • ZFS

      21. Fichero de usuarios

        Donde AMP guarda cuentas y permisos. Con un corte de luz a mitad de escritura, se queda vacío.

      22. Copia cada 30 minutos

        Desde el hipervisor, fuera del contenedor, las 100 últimas versiones.

        • Linux (Debian, Alpine, Arch)

      23. Comprobar la copia

        Una copia vacía o con «{}» no cuenta como copia: el script la rechaza y avisa.

        • Linux (Debian, Alpine, Arch)

      24. Monitorización

        Vigila el contenedor y los procesos de los servidores.

        • Zabbix

      Lo que uso de mi árbol

      Pulsa una habilidad: se encienden en el mapa las piezas donde la uso y te cuento para qué.

      Terraform
      Crea el contenedor de AMP; la fijación de CPU queda anotada porque Terraform no la ve.
      Proxmox VE
      CPU fijada a un procesador, más memoria en caliente y copias del fichero de usuarios desde el hipervisor.
      LXC
      AMP corre en su propio contenedor, con los datos de juego montados desde el pool de ZFS.
      ZFS
      Un espejo de cuatro discos para los mundos, compresión y caché en RAM con más del 98 % de aciertos.
      Docker
      Cada servidor de juego y el panel, en su propio contenedor, más el bot de estado.
      Linux (Debian, Alpine, Arch)
      Caché de escritura de los discos, planificador de E/S, cron con PATH correcto y copias comprobadas.
      MikroTik
      Reglas de entrada creadas y borradas por la automatización según lo encendido.
      Zabbix
      Vigila el contenedor y sus procesos.
      Linux / SSH hardening
      Cortafuegos con entrada bloqueada, panel y SSH solo desde casa, sin UPnP y puertos abiertos solo mientras hace falta.
      Python
      El publicador que sincroniza panel, router y DNS cada minuto.
      JavaScript / TypeScript
      El bot que publica el estado de los servidores, en Node.js.

      Bitácora de incidencias

      Averías reales. Lee el síntoma, elige la causa que creas y mira cómo se arregló.

      1. #1

        «No such user» después de un corte

        16-07-2026 · panel

        Tras un corte de luz, no podía entrar al panel: «No such user». El bot de estado tampoco, y reintentaba miles de veces al día.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        AMP no escribe su fichero de usuarios de forma atómica. Un apagado a mitad lo deja en «{}», y su propia copia rotativa cayó en la misma ventana. Es un fallo conocido de AMP.
        Solución
        Recrear las cuentas, y una copia cada 30 minutos desde el hipervisor, fuera del contenedor, con las últimas 100 versiones.
        Lección
        Sin SAI, todo lo que escribe sin cuidado es un riesgo. La copia tiene que vivir fuera de lo que se rompe.

      2. #2

        Una copia que nunca había copiado

        02-08-2026 · copias

        Otro corte y otra vez el fichero vacío. Fui a restaurar la copia… y las copias de 17 días eran todas de 0 bytes.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        El script usaba un comando de Proxmox que vive en una carpeta que el PATH mínimo del cron no incluye. Fallaba en cada pasada desde el primer día, en silencio, y además el script daba por buena cualquier salida.
        Solución
        Rutas absolutas, una prueba con el PATH real del cron y una comprobación de que cada copia es JSON de verdad: si sale vacía o «{}», se descarta y avisa.
        Lección
        Una copia no probada no es una copia. Se prueba como la ejecutará el sistema, no como la ejecuto yo.

      3. #3

        Discos lentos sin motivo aparente

        06-10-2026 · rendimiento

        Guardar el mundo costaba mucho y las escrituras con fsync se quedaban en 108 por segundo en un espejo de cuatro discos.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Estos discos SAS traen la caché de escritura desactivada. Cada escritura esperaba al plato.
        Solución
        Activarla y guardarla en el propio disco, con planificador «none» porque ZFS ya ordena la E/S. Es seguro con cortes: ZFS vacía la caché en cada transacción. De 108 a 946 escrituras con fsync por segundo.
        Lección
        Medir antes de comprar. Y apuntar que un disco de repuesto vendrá con la caché apagada otra vez.

      4. #4

        Sin red en cada arranque, y la copia no lo arreglaba

        17-10-2026 · AMP

        Tras un reinicio, el contenedor de los juegos arrancaba sin red. Restaurarlo de la copia de la noche anterior no cambiaba nada: volvía a arrancar sin red.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Al arrancar, el cortafuegos interno encontraba restos de una ejecución anterior, se limitaba a vaciarlos, fallaba a medias y dejaba toda la entrada en «denegar». Pasaba en cada arranque, por eso la copia no lo arreglaba.
        Solución
        Antes de arrancar, el cortafuegos se limpia del todo y, si falla, reintenta. Probado con un reinicio real.
        Lección
        Si restaurar no arregla algo, el fallo no está en los datos sino en cómo arranca.

      5. #5

        Un despliegue le quitó un tercio de la memoria

        18-10-2026 · Terraform

        Justo después de un despliegue, el panel de juegos murió por falta de memoria.

        ¿Qué crees que pasaba?

        Ver la solución
        Causa
        Había subido la memoria del contenedor a mano, en caliente, sin cambiar el código. El siguiente despliegue vio la diferencia, la deshizo y reinició el contenedor, y el panel no cabía en lo que quedaba.
        Solución
        La memoria sale de Terraform en todos los contenedores: se cambia en caliente y el código queda como registro. Ampliar disco con Terraform ya era en caliente.
        Lección
        Lo que se cambia a mano sin que el código lo sepa, el código lo deshace. O todo en código, o fuera del código a propósito.

      Contado entero en un artículo:

      Cómo se construyó

      1. Verano de 2026

        Los primeros servidores

        • AMP con una instancia Docker por juego y un proxy para todos los Minecraft.
        • Copias del fichero de usuarios tras el primer corte, y su arreglo cuando resultaron vacías.

      2. Septiembre de 2026

        Cortafuegos y migración

        • Cortafuegos del contenedor con entrada bloqueada y puertos sincronizados por el panel.
        • Contenedor nuevo gestionado con Terraform.

      3. Octubre de 2026

        Rendimiento y apertura automática

        • Caché de escritura, CPU en un solo procesador, Java y compresión ajustados.
        • Router y DNS que se abren y cierran solos según lo encendido.
        • Panel y gestión del bot fuera de internet.

      4. 17 y 18-10-2026

        Más aislado y más robusto

        • En la DMZ, aparte de la red de casa.
        • Un cortafuegos interno que arranca siempre desde cero.
        • Plugins propios para la red de servidores, con su propio CI que los prueba contra servidores de verdad. En desarrollo: aún no están en producción.

      Decisiones (y por qué)

      • Qué se abre

        Solo lo que está encendido, y solo sus puertos de juego

        Un puerto abierto para un servidor apagado no aporta nada y es superficie. La consola y la administración nunca se abren.

      • Cómo mejorar sin comprar

        Medir primero

        La CPU es la que es y un servidor de Minecraft depende de un solo hilo. Pero los discos, el reparto entre procesadores y Java tenían margen, y se midió antes y después con fio.

      • Qué toca la automatización en el router

        Solo sus propias reglas

        El usuario del router que usa el publicador solo puede crear y borrar reglas con su prefijo. Si fallara, no puede romper el resto del cortafuegos.

      Lo que aprendí

      • Probar las copias restaurándolas, y con el entorno real del cron.
      • Abrir puertos según lo que está encendido, no por si acaso.
      • Medir antes de pensar en comprar.

      Lo siguiente

      • Un SAI: es lo único que evita de raíz los apagados a mitad de escritura.
      • Un SSD para el mundo principal y pregenerar el mapa.

      ¿Hablamos?

      Puedo contar cualquiera de estas decisiones en detalle en una entrevista.

      Descargar CV Contactar ← Volver al rack

      Reconstrucción a partir de mi documentación: sin dominios, nombres de servidores, puertos ni direcciones.