Synology VMM Pro: Optimización del tamaño de una máquina virtual de producción con IA (2026)
La máquina virtual que ejecuta esta tienda pasó meses consumiendo el doble de hardware del que necesitaba: ocho CPU virtuales, dieciséis gigabytes de memoria y una carga de trabajo real que nunca superó la cuarta parte de ninguno de los dos. Esto no es inusual. Se dimensiona generosamente una máquina virtual el primer día porque no se sabe qué necesitará, el sitio funciona y nadie vuelve a configurarla. Este artículo narra ese proceso. Redujimos esa máquina virtual a cuatro vCPU y ocho gigabytes usando Synology. VMM Pro, Con un asistente de IA controlando la interfaz, la tienda estuvo inaccesible durante dos minutos y siete segundos. El redimensionamiento en sí es la parte aburrida: son dos campos en un cuadro de diálogo. Lo interesante es la medición que demostró que ocho gigabytes eran suficientes, el orden de las operaciones que evita que el sistema invitado se quede sin memoria en el primer arranque y la instantánea que lo hizo todo reversible. VMM Pro hace que cada una de estas operaciones sea económica, y ese es el argumento honesto a su favor.
Punto SynoPower Club:Optimizar el tamaño es la tarea menos glamurosa en el autoalojamiento, pero la que ofrece el mejor retorno. Nadie escribe una entrada de blog sobre los ocho gigabytes que devolvió. Sin embargo, la memoria inactiva en una máquina virtual sobredimensionada no ahorra nada: en un Synology está bloqueada, por lo que ningún otro programa del servidor puede usarla. Recuperamos ocho gigabytes en un host que empezaba a sentirse lleno, lo que significa que ya no tenemos que comprar hardware para dos máquinas virtuales más. Lo que hizo que la operación fuera segura, en lugar de preocupante, fue el VMM Pro subyacente: una instantánea bloqueada antes del primer comando y una máquina que podía restaurar a su estado original en noventa segundos si algo salía mal. No hubo ningún problema. Pero no habría empezado sin él.
Tabla de contenido
¿Qué es Synology VMM Pro?
Virtual Machine Manager es el paquete de hipervisor de Synology. Se instala desde el Centro de paquetes, es gratuito y, en un único NAS, puede ejecutar sin problemas sistemas operativos invitados Linux, Windows y Virtual DSM con instantáneas locales. VMM Pro Es la actualización de pago que convierte ese hipervisor de una sola caja en un pequeño clúster: varias unidades NAS gestionadas como un único grupo, máquinas virtuales que pueden moverse entre ellas, alta disponibilidad y replicación de instantáneas de un host a otro.
La distinción es importante para este artículo porque la optimización del tamaño es una decisión de capacidad, y la capacidad solo cobra relevancia cuando se cuenta con más de una máquina. En un único NAS, la memoria que se libera permanece sin usar en ese NAS. En un clúster VMM Pro, es memoria que otro host puede utilizar durante una conmutación por error, o en la que se puede instalar una nueva máquina virtual sin necesidad de adquirir recursos adicionales.
A DSM virtual El invitado —una instalación completa de DSM que se ejecuta como una máquina virtual— es la carga de trabajo que redimensionamos aquí. Ejecuta Container Manager, que a su vez ejecuta los dos contenedores Docker detrás de este almacén. Esta estructura en capas es deliberada y es lo que hizo que el trabajo fuera seguro. Ya hemos cubierto el traslado de una pila Docker entre invitados en Nuestro tutorial de migración a Docker de VDSM; este artículo trata sobre cómo hacer que el invitado que está debajo tenga el tamaño adecuado.
VMM Pro frente a la edición gratuita: ¿Qué incluye realmente la actualización?
La edición gratuita no es una demo limitada. Ejecuta máquinas virtuales de producción, toma instantáneas y, para un solo NAS, es realmente todo lo que la mayoría de la gente necesita. Lo que estás comprando con VMM Pro No se trata de características de un invitado, sino de características comunes a todos los anfitriones.
| Capacidad | Edición gratuita | VMM Pro |
|---|---|---|
| Ejecuta invitados en un NAS | Sí | Sí |
| Instantáneas locales | Sí | Sí |
| Varias unidades NAS como un clúster. | No | Sí |
| Trasladar un huésped entre anfitriones | No | Sí |
| conmutación por error de alta disponibilidad | No | Sí |
| Replicar instantáneas en otro host | No | Sí |
Consulta la página de características oficial enlazada en las referencias antes de comprar, porque Synology revisa la edición dividida entre las versiones de DSM. La prueba práctica es más sencilla que la tabla: si tienes un NAS y te sientes cómodo restaurando desde una instantánea manualmente, la edición gratuita está bien. En el momento en que tengas un segundo NAS y quieras que las máquinas virtuales del primero sobrevivan a su fallo, querrás una Licencia VMM Pro.
Nuestro clúster consta de tres nodos, de los cuales solo dos permanecen encendidos la mayor parte del tiempo. El tercero es un nodo de reserva en frío que se activa según un cronograma para recibir instantáneas replicadas y luego vuelve a entrar en modo de suspensión. Este patrón —pagar la electricidad solo cuando se necesita la redundancia— es un patrón VMM Pro, y es la razón por la que la consola muestra una advertencia permanente sobre un host al que no puede acceder. La advertencia indica que el diseño funciona correctamente, no que haya un fallo.
Cómo un invitado de producción termina siendo el doble de grande de lo que necesita.
Tres factores impulsan a los huéspedes a aumentar su capacidad y ninguno los frena. El primero es que el tamaño inicial es una estimación, y una estimación generosa no cuesta nada el primer día. El segundo es que cada incidente termina con alguien aumentando el límite. En nuestro caso, tuvimos dos incidentes de memoria en una semana; ambos se solucionaron aumentando el espacio disponible, y ninguno volvió a presentarse. El tercero es que un panel de control que muestra un 80 % de uso de memoria resulta alarmante, por lo que nadie se ofrece voluntario para reducirla. Ninguno de estos problemas es exclusivo de VMM Pro. Es un problema humano, y es la razón por la que los huéspedes con capacidad excesiva son la norma.
Esa última es la trampa, y vale la pena decirlo claramente: el número que la mayoría de la gente usa para decidir si un contenedor tiene espacio suficiente es incorrecto. El nuestro indicaba que el contenedor de la base de datos estaba al 81 % de su capacidad. No era cierto. La sección cinco trata precisamente sobre el porqué y sobre la medición que convirtió el redimensionamiento a VMM Pro en una decisión segura en lugar de una mera esperanza.
Cómo optimizar el tamaño de un invitado en directo con VMM Pro en 4 pasos
El proceso completo consta de cuatro pasos, y solo el tercero provoca la desconexión del sitio. El tiempo total de inactividad fue de dos minutos y siete segundos, medido desde el momento en que se detuvieron los contenedores hasta la primera respuesta HTTP 200 tras la reconexión del usuario. VMM Pro está involucrado en los pasos uno y tres; el paso intermedio ocurre dentro del huésped.
Toma una instantánea bloqueada antes que nada.
Crea una instantánea del sistema invitado desde VMM Pro y márcala como bloqueada para que la rotación programada de instantáneas no la elimine. Esto te permitirá deshacer todos los pasos siguientes, y capturará todo el sistema en lugar de una sola carpeta. Añade una descripción que indique lo que ibas a hacer, porque dentro de tres meses la marca de tiempo por sí sola no te servirá de nada.
Mide lo que la carga de trabajo realmente utiliza, no lo que informa el panel de control.
Lea las estadísticas de memoria del cgroup dentro de cada contenedor y separe la memoria anónima de la caché de páginas. Solo la memoria anónima no se puede recuperar, y solo ese valor debe determinar el tamaño. Mientras esté allí, compare el grupo de búferes de la base de datos con el tamaño real de la base de datos. En nuestro caso, el grupo de búferes tenía tres gigabytes delante de una base de datos de seiscientos sesenta y tres megabytes.
Reduzca el tamaño de los contenedores antes de reducir el tamaño del invitado.
Primero, reduce los límites de memoria de la aplicación y la base de datos, y sincroniza esos mismos valores en tu archivo compose para que una reconstrucción posterior no los deshaga. Un contenedor cuyo uso actual ya supera el nuevo límite no se puede limitar simplemente; cambia su configuración y reinícialo para que vuelva con un uso menor, y luego aplica el límite inferior. Si no sigues este orden correctamente, se producirá un bucle de falta de memoria en el primer arranque.
Detenga los contenedores de forma limpia, redimensione y verifique el comportamiento en lugar de la configuración.
Detenga el contenedor de la base de datos con un tiempo de espera generoso y confirme un apagado correcto en su registro, para que la máquina virtual no inicie en modo de recuperación tras un fallo. Apague la máquina virtual, configure los nuevos valores de vCPU y memoria en VMM Pro y vuelva a encenderla. A continuación, verifique que los usuarios interactúen con la aplicación: que las páginas reales devuelvan un código 200, que los precios sean correctos y que no haya errores de memoria (no solo los números que usted introdujo en el cuadro de diálogo).
Por qué las estadísticas de Docker te harán desviarte de la respuesta correcta.
Antes del redimensionamiento, el panel de control del contenedor parecía una máquina sin margen de maniobra:
Estadísticas de Docker WordPress 2,51 GiB / 7 GiB (35,9%) WordPress-DB 3,25 GiB / 4 GiB (81,1%) <-- parece casi llenoSi lees eso, concluyes que la base de datos necesita sus cuatro gigabytes y que el sistema invitado no puede usar menos de doce. Ambas conclusiones son erróneas, porque el uso de memoria que reportan esas herramientas incluye la caché de páginas, y esta se libera automáticamente en cuanto algo más necesita la memoria. El número que determina si se produce un error de falta de memoria es la memoria anónima. Léelo directamente:
docker exec sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB caché 1609 MB WordPress-DB rss 2553 MB caché 1543 MBAhora la situación se invierte. El contenedor de la aplicación utiliza realmente 1,3 GB, no 2,5 GB. De esos 1,3 GB, 768 MB corresponden a una única caché de código de operación compartida que cada proceso de trabajo mapea en lugar de copiar; por lo tanto, veinte procesos de trabajo consumían aproximadamente veintisiete megabytes cada uno, y no los doscientos cincuenta megabytes que sugiere una simple suma de la memoria del proceso. Los 2,5 GB de la base de datos eran casi en su totalidad un grupo de búferes de tres gigabytes para una base de datos de 663 MB.
Otra trampa similar: el contador de picos históricos mostrará sin problema un contenedor que alcanzó su límite, ya que este contador también incluye la caché de página. Ambos contenedores lo hicieron. Ninguno de los dos se había quedado sin memoria. Compruebe el contador de falta de memoria, no el de pico máximo.
Con esos dos datos en mente, ocho gigabytes dejaron de ser una cifra arriesgada. Reducir el grupo de búferes a un gigabyte —todavía considerablemente mayor que toda la base de datos— liberó más memoria real de la necesaria para el redimensionamiento. El número que finalmente introdujimos en VMM Pro ya estaba comprobado antes de apagar la máquina virtual.
Cómo un pequeño equipo utiliza VMM Pro para recuperar un servidor completo
La memoria en un invitado Synology está fija. El hipervisor la bloquea y la preasigna, lo que significa que no se puede sobreasignar como en otras plataformas. Dieciséis gigabytes asignados a un invitado son dieciséis gigabytes que ningún otro invitado puede tener, ya sea que el invitado esté ocupado o inactivo. Esa restricción es lo que hace que valga la pena hacer el dimensionamiento correcto en VMM Pro En concreto: liberar memoria es la única forma de crear capacidad sin tener que comprar un NAS.
Se recuperaron ocho gigabytes en un host con un total de 46,83 GB. La memoria disponible pasó de aproximadamente veintidós gigabytes a 30,29 GB. En términos prácticos, esto equivale a dos máquinas virtuales adicionales del tamaño que utilizamos habitualmente, creadas simplemente con mediciones. En un clúster de tres nodos, también significa que los hosts restantes tienen mayor capacidad para absorber las máquinas virtuales de un nodo que falle, que es precisamente el objetivo de pagar por VMM Pro.
La parte de la CPU contó la misma historia de forma más directa. El sistema invitado tenía ocho CPU virtuales y utilizaba aproximadamente una sexta parte de un núcleo en reposo. Cuatro no era una solución de compromiso; cuatro sigue siendo una cantidad generosa, y VMM Pro la aplicó en un solo campo. Desde el redimensionamiento, el sistema invitado tiene una carga promedio de 1,36 frente a cuatro vCPU, lo que representa aproximadamente un tercio utilizado en el momento de mayor actividad del día.
El orden de operaciones que evita un bucle de falta de memoria durante el arranque
Esta es la parte donde es fácil equivocarse y donde el error resulta costoso. Los límites de memoria de los contenedores y la memoria del sistema invitado que se configura en VMM Pro son dos límites distintos, y si la suma de los límites de los contenedores excede la memoria del sistema invitado, se les indica a los contenedores que pueden usar más memoria de la que tiene la máquina. Bajo carga, el kernel resuelve esta discrepancia terminando algún proceso.
Antes del cambio, nuestros límites eran de siete gigabytes para el contenedor de la aplicación y cuatro para la base de datos; once gigabytes en una máquina virtual de dieciséis gigabytes, lo cual era aceptable. En una máquina virtual de ocho gigabytes, habría sido un problema grave a la espera del primer pico de tráfico. Por lo tanto, primero hubo que detener los contenedores.
| Configuración | Antes | Después |
|---|---|---|
| Invitado | 8 vCPU / 16 GB | 4 vCPU / 8 GB |
| Límite del contenedor de la aplicación | 7168 MB | 4096 MB |
| Límite del contenedor de base de datos | 4096 MB | 2048 MB |
| grupo de búferes de la base de datos | 3 GB | 1 GB |
| Conexiones máximas de la base de datos | 300 | 100 |
| techo de trabajadores apaches | 50 | 35 |
En esa tabla se esconde una regla de segundo orden. No se puede reducir el límite de memoria de un contenedor por debajo de su uso actual y esperar que el kernel lo gestione correctamente. El contenedor de la aplicación estaba usando menos de su nuevo límite, por lo que se limitó en tiempo real sin reiniciar ni interrumpir el servicio. El contenedor de la base de datos estaba usando más, por lo que primero hubo que reconfigurar su grupo de búferes y reiniciar el contenedor; solo entonces se pudo aplicar el límite inferior. Ninguno de estos pasos se realiza en VMM Pro; ambos deben completarse antes de abrir el cuadro de diálogo de redimensionamiento.
El límite de trabajadores es el único coste real de todo el proyecto, y merece ser mencionado en lugar de ocultarse. Reducir el contenedor de la aplicación de siete a cuatro gigabytes implica que se pueden gestionar menos solicitudes simultáneas: de cincuenta a treinta y cinco, una reducción del treinta por ciento en la concurrencia máxima. En el día a día, el sitio web utiliza once trabajadores, así que no hubo cambios. Durante un periodo de alta demanda publicitaria, sí podría haberlos. Fue una decisión que tomamos conscientemente, y está documentada para que la próxima persona no la descubra durante una interrupción del servicio.
Qué hizo realmente el asistente de IA y dónde falló.
El asistente se encargó de las tareas que requieren paciencia: creó la instantánea VMM Pro antes de modificar nada, consultó las estadísticas del grupo de control en lugar de confiar en el panel de control, calculó la restricción de ordenación en los límites del contenedor y verificó el resultado obteniendo páginas reales y comprobando que los precios se seguían mostrando en la moneda correcta. Esto equivale a unos cuarenta minutos de trabajo minucioso comprimidos en tan solo unos minutos, y resulta realmente útil.
Además, se equivocó tres veces en una sola sesión, que es la parte más útil de la historia.
- Recomendó diez gigabytes cuando el propietario solicitó ocho. El propietario tenía razón, pero solo porque el tamaño excesivo del búfer se había corregido al mismo tiempo. El asistente tenía la medida a la vista y aun así optó por la opción más segura.
- Cambió el nombre del huésped, leyó
éxito: verdaderoDesde la API, se informó que el cambio de nombre se había realizado. Sin embargo, no se había cambiado el nombre. El campo de cambio de nombre que se utilizó fue el que identifica al huésped, no el que modifica su nombre, y la API devuelve éxito en ambos casos. - Se detectó una advertencia en un clúster VMM Pro sobre un host inaccesible y se lo marcó como una ruta de conmutación por error degradada. El host era un servidor en espera que se apagaba deliberadamente. La alerta llevaba meses presente por diseño.
En los tres casos, el patrón es el mismo: un resultado fiable tras una comprobación plausible. Por lo tanto, las medidas de seguridad que realmente importan no son llamativas. Primero, siempre, realiza la instantánea antes del primer comando, en lugar de antes del que conlleva riesgos. Nunca aceptes un valor de retorno como prueba; revisa el estado y comprueba el campo que pretendías modificar. Y verifica el comportamiento, no la configuración: una página que carga correctamente y un precio correcto son más fiables que cualquier número de confirmaciones de que un comando finalizó con un valor nulo.
Nada de eso es exclusivo de la IA. Es la misma disciplina que se esperaría de un nuevo colega con acceso de administrador: rápido, incansable y, ocasionalmente, convencido de algo que no es cierto.
Dónde encontrar más recursos oficiales
Tres vídeos que merece la pena ver antes de redimensionar nada con VMM Pro. El primero ofrece la mejor visión general del paquete; los otros dos tratan sobre la creación y la concesión de licencias a invitados, que es donde la mayoría de la gente se atasca en su primer intento.
Limitaciones que debe conocer antes de confiar la producción al VMM Pro
No se puede sobreasignar la memoria. Cada gigabyte que se asigna queda bloqueado y separado del resto de los dispositivos en el NAS, estén o no en uso. Esta limitación es lo que hace que dimensionar correctamente la memoria sea fundamental, y también es la razón por la que una estimación generosa desde el principio resulta más costosa aquí que en plataformas que permiten la sobreasignación.
Reducir la memoria requiere reiniciar el sistema, ya que VMM Pro no le quita memoria a una máquina virtual en ejecución. Ampliar un disco virtual se realiza en tiempo real, al igual que ampliar algunos recursos, pero quitar memoria implica apagar la máquina virtual. Prevea una breve interrupción del servicio y prográmela; dos minutos es factible, pero no es cero.
Los discos virtuales crecen y nunca se reducen. Si asignaste almacenamiento en lugar de memoria en exceso, VMM Pro No lo devolveré. La única opción es crear un nuevo huésped y migrar a él, lo cual implica una tarde mucho más larga que esta.
Es posible que los límites de CPU dentro de los contenedores no funcionen en absoluto. En este sistema invitado, el kernel no tiene control de ancho de banda de CFS, por lo que las cuotas de CPU de los contenedores se rechazan directamente; peor aún, intentar establecer una cuota de CPU en el mismo comando que un límite de memoria provoca que todo el comando falle silenciosamente. Los límites de memoria y el límite de trabajadores de la propia aplicación son la única protección de CPU disponible.
Una instantánea no es una copia de seguridad. Reside en el mismo host y en el mismo grupo de almacenamiento que la máquina virtual a la que protege. VMM Pro puede replicar instantáneas en otro host más cercano, pero lo que sobrevive a un incendio en un edificio sigue siendo una copia de seguridad externa de los datos.
Finalmente, fíjate en lo que muestra la consola. Las páginas de detalles del contenedor muestran las variables de entorno en texto plano, incluidas las contraseñas de la base de datos. Esto se debe a la honestidad de Docker, no a un fallo del paquete, pero significa que una simple captura de pantalla de la página incorrecta expone una credencial. Si esto te preocupa (y debería), guarda los secretos en un archivo que lea el contenedor en lugar de pasarlos como variables.
Referencias
- SynoPower Club, Nuestras guías y reseñas de cámaras para el NAS Synology
- Synology — Virtual Machine Manager, la comparación oficial de características y ediciones
- Centro de conocimiento Synology — Ayuda Virtual Machine Manager, Configuración de invitados y configuración del clúster
- Docker — actualización de contenedores Docker, cambiar el límite de memoria de un contenedor en ejecución
- Apache — MaxRequestWorkers, el límite salarial de los trabajadores analizado en la sección siete
Preguntas frecuentes
¿Merece la pena el VMM Pro para un único NAS?
Probablemente no. Virtual Machine Manager es gratuito y la edición gratuita ejecuta máquinas virtuales de producción con instantáneas locales en un solo servidor. VMM Pro se amortiza cuando se dispone de un segundo NAS y se desea que las máquinas virtuales se muevan entre hosts, realicen la conmutación por error automáticamente o repliquen sus instantáneas en un lugar distinto al servidor en el que se ejecutan.
¿Puedo reducir el tamaño de una máquina virtual Synology sin tiempo de inactividad?
No. La memoria está bloqueada y preasignada en un host Synology, por lo que VMM Pro no puede reducirla en tiempo real y la máquina virtual debe apagarse. La nuestra estuvo inaccesible durante dos minutos y siete segundos de extremo a extremo, incluyendo un apagado limpio de la base de datos previo. En cambio, el crecimiento de un disco virtual sí se produce mientras la máquina virtual está en funcionamiento.
¿Cómo puedo saber cuánta memoria necesita realmente un contenedor?
Lea las estadísticas de memoria del cgroup dentro del contenedor y observe la cifra de memoria anónima, no el total que informan las herramientas de monitorización. El uso total incluye la caché de páginas, que el kernel recupera bajo demanda. Nuestro contenedor de base de datos informó de 3,25 GB de un límite de 4 GB, pero solo disponía de 2,55 GB de memoria no recuperable, la mayor parte de la cual correspondía a un grupo de búferes sobredimensionado.
¿En qué orden debo cambiar los límites del contenedor y la memoria del invitado?
Primero los contenedores, después el sistema invitado: no abra el diálogo de redimensionamiento de VMM Pro hasta que los límites de los contenedores se ajusten. Si la suma de los límites de los contenedores supera la capacidad del sistema invitado, este podría quedarse sin memoria al arrancar por primera vez. Tenga en cuenta también que un contenedor que ya utiliza más memoria de la permitida no se puede limitar simplemente: reconfigúrelo y reinícielo para que vuelva a ocupar menos espacio; luego, reduzca el límite.
¿Una instantánea bloqueada en VMM Pro afecta a mi política de retención?
El bloqueo exime a una instantánea de la rotación programada, razón por la cual conviene aplicarlo antes de un cambio como este. Sin el bloqueo, un proceso de replicación intensivo puede eliminar silenciosamente el punto de restauración en el que confiabas antes de que puedas confirmar que el cambio es seguro.
¿Es seguro permitir que un asistente de IA cambie el tamaño de una máquina virtual de producción?
Con medidas de seguridad, sí, y estas no son complicadas. Toma una instantánea antes del primer comando, en lugar de antes del más arriesgado. Exige que se lea el estado en lugar de confiar en una respuesta de éxito. Verifica el comportamiento visible para el usuario en lugar de la configuración que acabas de escribir. Nuestro asistente cometió tres errores en una sesión, y todos se detectaron leyendo el estado.
¿Qué ahorros supuso realmente la optimización del tamaño de la empresa?
Se reintegraron ocho gigabytes de memoria fija y cuatro CPU virtuales al grupo de hosts VMM Pro, lo que aumentó la memoria disponible de aproximadamente veintidós gigabytes a 30,29 GB de un total de 46,83 GB. Esto proporciona espacio para dos máquinas virtuales adicionales del tamaño que utilizamos, así como mayor capacidad para que el clúster absorba un nodo fallido.
¿Puede Virtual DSM ejecutar Docker y afecta el redimensionamiento del sistema operativo invitado a los contenedores?
Sí, una máquina virtual Virtual DSM es una instalación completa de DSM, por lo que Container Manager se instala exactamente igual que en un NAS físico. Cambiar el tamaño de la máquina virtual en VMM Pro no afecta a los contenedores en sí, pero sus límites de memoria son un tope independiente que debe reducirse para que quepa la máquina virtual más pequeña antes de reducir su tamaño.