Synology VMM Pro: Dimensionando corretamente uma VM de produção com IA (2026)

A máquina virtual que executava este site passou meses com o dobro do hardware necessário. Oito CPUs virtuais, dezesseis gigabytes de memória e uma carga de trabalho real que nunca utilizou mais de um quarto de nenhum dos dois. Isso não é incomum. Você dimensiona generosamente uma máquina virtual no primeiro dia porque não tem ideia do que ela precisará, o site funciona e ninguém nunca mais volta atrás. Este artigo é o relato de como voltamos atrás. Reduzimos essa máquina virtual para quatro vCPUs e oito gigabytes usando o Synology. VMM Pro, Com um assistente de IA controlando o shell, o armazenamento ficou inacessível por dois minutos e sete segundos. O redimensionamento em si é a parte tediosa — são apenas dois campos em uma caixa de diálogo. As partes interessantes são a medição que comprovou que oito gigabytes eram suficientes, a ordem das operações que impede que o sistema convidado fique sem memória na primeira inicialização e o snapshot que tornou tudo reversível. O VMM Pro torna cada um desses recursos barato, e esse é o argumento principal a seu favor.

Ponto SynoPower Club:O redimensionamento correto é a tarefa menos glamorosa em auto-hospedagem, mas também a que oferece o melhor retorno. Ninguém escreve um post no blog sobre os oito gigabytes que recuperou. A memória ociosa dentro de uma máquina virtual superdimensionada não economiza nada — em um Synology, ela é fixa, então não pode ser usada por nenhum outro sistema. Recuperamos oito gigabytes em um host que já estava começando a ficar cheio, o que significa que não precisamos mais comprar hardware para duas máquinas virtuais. O que tornou tudo mais seguro, em vez de assustador, foi o VMM Pro subjacente: um snapshot bloqueado antes do primeiro comando e uma máquina que eu poderia restaurar ao estado original em noventa segundos caso algo desse errado. E não deu errado. Mas eu não teria começado sem ele.

O que é Synology e VMM Pro?

O Virtual Machine Manager é o pacote de hipervisor do Synology. Ele é instalado a partir da Central de Pacotes, é gratuito e, em um único NAS, executará sem problemas sistemas operacionais convidados Linux, Windows e Virtual DSM com snapshots locais. VMM Pro É a atualização paga que transforma esse hipervisor de caixa única em um pequeno cluster: várias unidades NAS gerenciadas como um único pool, máquinas virtuais que podem se mover entre elas, alta disponibilidade e replicação de snapshots de um host para outro.

Essa distinção é importante para este artigo porque o dimensionamento correto é uma decisão de capacidade, e a capacidade só se torna relevante quando você tem mais de uma máquina no cluster. Em um único NAS, a memória liberada é memória que fica ociosa nesse NAS. Em um cluster VMM Pro, é memória que outro host pode utilizar durante um failover, ou na qual uma nova máquina virtual pode ser instalada sem custos adicionais.

A Virtual DSM A carga de trabalho que redimensionamos aqui é a instalação completa do DSM executada como uma máquina virtual. Ela executa o Container Manager, que por sua vez executa os dois contêineres Docker por trás deste armazenamento. Essa estrutura em camadas é intencional e foi o que tornou a tarefa segura. Já abordamos a migração de uma pilha Docker entre máquinas virtuais em [referência omitida]. nosso guia passo a passo para migração do VDSM para o Docker; Este artigo trata de como fazer com que o convidado embaixo dele tenha o tamanho certo.

VMM Pro vs. Edição Gratuita: O que a Atualização Realmente Oferece

A versão gratuita não é uma demonstração limitada. Ela executa máquinas virtuais de produção, tira snapshots e, para um único NAS, é realmente tudo o que a maioria das pessoas precisa. O que você está comprando com VMM Pro Não se trata de funcionalidades exclusivas de um convidado, mas sim de funcionalidades comuns a todos os hosts.

Capacidade	Edição gratuita	VMM Pro
Execute máquinas virtuais em um único NAS.	Sim	Sim
instantâneos locais	Sim	Sim
Várias unidades NAS como um cluster	Não	Sim
Transferir um hóspede entre anfitriões	Não	Sim
Failover de alta disponibilidade	Não	Sim
Replicar snapshots para outro host	Não	Sim

Antes de comprar, verifique a página oficial de recursos, cujo link está nas referências, pois a versão Synology revisa a divisão de edições entre as versões do DSM. O teste prático é mais simples do que a tabela: se você possui um NAS e está satisfeito em restaurar manualmente a partir de um snapshot, a edição gratuita é suficiente. No entanto, se você tiver um segundo NAS e quiser que as máquinas virtuais do primeiro sobrevivam a uma falha, você precisará da versão paga. Licença VMM Pro.

Nosso cluster possui três nós, e apenas dois deles permanecem ligados na maior parte do tempo. O terceiro é um servidor de espera a frio que é ativado periodicamente para receber snapshots replicados e retorna ao estado de repouso. Esse padrão — pagar pela energia elétrica somente quando a redundância é necessária — é um padrão VMM Pro, e é por isso que o console exibe um aviso permanente sobre um host ao qual não consegue se conectar. O aviso é o funcionamento correto do projeto, não uma falha.

Como um convidado de produção acaba com o dobro do tamanho necessário

Três coisas fazem com que os hóspedes aumentem o tamanho da memória e nada os faça diminuir. A primeira é que o tamanho inicial é um palpite, e um palpite generoso não custa nada no primeiro dia. A segunda é que todo incidente termina com alguém aumentando o limite. O nosso teve dois incidentes de memória em uma semana; ambos foram resolvidos dando mais espaço a algum item, e nenhum deles voltou a acontecer. A terceira é que um painel mostrando 80% de uso de memória parece alarmante, então ninguém se oferece para liberar memória. Nada disso é um problema do VMM Pro. É um problema humano, e é por isso que hóspedes com tamanho acima do permitido são a norma.

Essa última é a armadilha, e vale a pena dizer claramente: o número que a maioria das pessoas usa para decidir se um contêiner tem espaço é o número errado. O nosso indicava que o contêiner do banco de dados estava com 81% da sua capacidade. Não estava. A seção cinco explica exatamente o porquê, e a medição que transformou o redimensionamento do VMM Pro em uma decisão segura, em vez de uma decisão otimista.

Dimensionando corretamente uma conexão ao vivo com o VMM Pro em 4 etapas

Todo o processo consiste em quatro etapas, e apenas a terceira tira o site do ar. O tempo total de inatividade para nós foi de dois minutos e sete segundos, medido desde o momento em que os contêineres foram interrompidos até o primeiro HTTP 200 após o retorno da máquina virtual. VMM Pro Está envolvido nas etapas um e três; a etapa intermediária ocorre dentro do hóspede.

Por que o comando `docker stats` pode te levar a uma resposta errada?

Antes da redimensionamento, o painel de controle do contêiner parecia uma máquina sem espaço para mais nada:

docker stats WordPress 2,51 GiB / 7 GiB (35,9%) WordPress-DB 3,25 GiB / 4 GiB (81,1%) <-- parece quase cheio

Ao ler isso, você conclui que o banco de dados precisa de seus quatro gigabytes e que a máquina virtual não pode ficar com menos de doze. Ambas as conclusões estão erradas, porque o uso de memória relatado por essas ferramentas inclui o cache de páginas, e o cache de páginas é liberado automaticamente assim que qualquer outra coisa precisa da memória. O número que determina se você receberá um erro de falta de memória é a memória anônima. Leia-a diretamente:

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 cache 1609 MB WordPress-DB rss 2553 MB cache 1543 MB

Agora o cenário se inverte. O contêiner da aplicação está realmente usando 1,3 GB, e não 2,5 GB. E desses 1,3 GB, 768 MB correspondem a um único cache de opcode compartilhado que cada processo de trabalho mapeia em vez de copiar — portanto, vinte processos de trabalho consumiam aproximadamente 27 megabytes cada, e não os 250 megabytes que uma soma ingênua da memória dos processos sugere. Os 2,5 GB do banco de dados eram quase inteiramente um pool de buffers com três gigabytes para um banco de dados de 663 MB.

Mais uma armadilha da mesma família: o contador de picos históricos exibirá com prazer um contêiner que atingiu seu limite, porque esse contador também inclui o cache de páginas. Os nossos dois tinham atingido. Nenhum deles jamais havia sido encerrado por falta de memória. Verifique o contador de falta de memória, não o contador de pico.

Com esses dois fatos em mãos, oito gigabytes deixaram de ser um número arriscado. Reduzir o buffer pool para um gigabyte — ainda consideravelmente maior que todo o banco de dados — liberou mais memória real do que o necessário para o redimensionamento. O número que finalmente digitamos em VMM Pro já havia sido comprovado antes do desligamento da máquina virtual.

Como uma pequena equipe usa o VMM Pro para recuperar um servidor inteiro.

A memória em uma máquina virtual Synology é fixa. O hipervisor a bloqueia e pré-aloca, o que significa que você não pode sobrecarregá-la como em algumas outras plataformas. Dezesseis gigabytes atribuídos a uma máquina virtual são dezesseis gigabytes que nenhuma outra máquina virtual pode usar, esteja ela ocupada ou ociosa. Essa restrição é o que torna o dimensionamento correto importante. VMM Pro Especificamente: liberar memória é a única maneira de criar capacidade sem comprar um NAS.

Oito gigabytes foram recuperados em um host com um total de 46,83 GB. A memória disponível passou de aproximadamente 22 gigabytes para 30,29 GB. Na prática, isso equivale a duas máquinas virtuais adicionais do tamanho que realmente executamos, criadas do zero, apenas por medição. Em um cluster de três nós, isso também significa que os hosts sobreviventes têm mais espaço para absorver as máquinas virtuais de um nó que falha, que é o principal motivo para pagar pelo VMM Pro.

O lado da CPU contou a mesma história de forma mais direta. O sistema convidado tinha oito CPUs virtuais e estava usando cerca de um sexto de um núcleo em repouso. Quatro não era um compromisso; quatro ainda é um valor generoso, e o VMM Pro o aplicou em um único campo. Desde o redimensionamento, o sistema convidado apresenta uma carga média de 1,36 contra quatro vCPUs, o que representa aproximadamente um terço de utilização no período de maior movimento do dia.

A ordem das operações que impede um loop de falta de memória durante a inicialização.

Esta é a parte que é fácil de errar e cara de errar. Os limites de memória do contêiner e a memória do convidado que você definiu em VMM Pro são dois limites distintos, e se a soma dos limites do contêiner exceder a memória do convidado, você terá dito aos contêineres que eles podem usar mais memória do que a máquina possui. Sob carga, o kernel resolve essa discrepância encerrando algum processo.

Antes da mudança, nossos limites eram de sete gigabytes para o contêiner da aplicação e quatro para o banco de dados — onze gigabytes em uma máquina virtual de dezesseis gigabytes, o que era aceitável. Em uma máquina virtual de oito gigabytes, teria sido um incidente assim que o primeiro pico de tráfego acontecesse. Portanto, os contêineres tiveram que ser desligados primeiro.

Contexto	Antes	Depois
Convidado	8 vCPUs / 16 GB	4 vCPUs / 8 GB
Limite do contêiner de aplicativos	7168 MB	4096 MB
limite do contêiner de banco de dados	4096 MB	2048 MB
pool de buffers do banco de dados	3 GB	1 GB
conexões máximas do banco de dados	300	100
teto do trabalhador Apache	50	35

Existe uma regra de segunda ordem oculta nessa tabela. Você não pode reduzir o limite de memória de um contêiner abaixo do que ele está usando atualmente e esperar que o kernel se comporte de forma adequada. O contêiner do aplicativo estava usando menos do que seu novo limite, então seu uso foi limitado em tempo real, sem reinicialização e sem tempo de inatividade. O contêiner do banco de dados estava usando mais, então seu pool de buffers teve que ser reconfigurado e o contêiner reiniciado primeiro; somente então o limite inferior pôde ser aplicado. Nenhuma dessas etapas ocorre no VMM Pro — ambas precisam ser concluídas antes de você abrir a caixa de diálogo de redimensionamento.

O limite de workers é o único custo real de todo o projeto e merece ser mencionado, em vez de omitido. Reduzir o contêiner da aplicação de sete gigabytes para quatro significa que menos requisições simultâneas podem ser executadas: de cinquenta para trinta e cinco, uma redução de trinta por cento na concorrência máxima. No dia a dia, o site utiliza onze workers, então nada mudou. Durante um pico de tráfego publicitário, isso pode mudar. Essa é uma troca que fizemos conscientemente e que está documentada para que a próxima pessoa não a descubra durante uma interrupção.

O que o assistente de IA realmente fez e onde errou.

O assistente realizou as tarefas que recompensam a paciência: tirou o snapshot VMM Pro antes de fazer qualquer alteração, leu as estatísticas do cgroup em vez de confiar no painel de controle, calculou a restrição de ordenação nos limites do contêiner e verificou o resultado buscando páginas reais e conferindo se os preços ainda eram exibidos na moeda correta. Isso representa talvez quarenta minutos de trabalho cuidadoso comprimidos em poucos minutos, e é realmente útil.

Também errou três vezes em uma única sessão, o que é a parte mais útil da história.

• O sistema recomendou dez gigabytes quando o usuário solicitou oito. O usuário estava certo — mas apenas porque o buffer pool superdimensionado foi corrigido ao mesmo tempo. O assistente tinha a medida em mãos e ainda assim insistiu no número mais seguro.
• Renomeou o convidado, leia sucesso: verdadeiro A API retornou o erro e informou que a renomeação havia sido concluída. No entanto, o nome não havia sido alterado. O campo de renomeação utilizado foi o que identifica o convidado, não o que altera o nome, e a API retorna sucesso de qualquer forma.
• O sistema detectou um alerta de cluster VMM Pro sobre um host inacessível e o sinalizou como um caminho de failover degradado. O host era um servidor de espera a frio, desligado propositalmente. O alerta estava presente há meses, conforme o esperado.

O padrão nos três casos é o mesmo: um resultado confiável a partir de uma verificação plausível. As salvaguardas que realmente importam, portanto, são pouco glamorosas. Tire um instantâneo primeiro, sempre, antes do primeiro comando, e não antes do comando arriscado. Nunca aceite um valor de retorno como prova — leia o estado de volta e observe o campo que você pretendia alterar. E verifique o comportamento, não as configurações: uma página que carrega e um preço correto são mais importantes do que qualquer número de confirmações de que um comando retornou zero.

Nada disso é específico da IA. É a mesma disciplina que você esperaria de um novo colega com acesso root, que seja rápido, incansável e, ocasionalmente, tenha certeza de algo que não é verdade.

Onde encontrar mais recursos oficiais

Três vídeos que valem a pena assistir antes de redimensionar qualquer coisa com o VMM Pro. O primeiro oferece a melhor visão geral do pacote; os outros dois abordam a criação e o licenciamento de convidados, que é onde a maioria das pessoas encontra dificuldades na primeira tentativa.

Limitações a conhecer antes de confiar a produção ao modelo VMM Pro

A memória não pode ser sobrecarregada. Cada gigabyte alocado fica isolado de todo o resto no NAS, esteja ele ocupado ou não. Essa restrição é o que torna o dimensionamento correto valioso, e também o motivo pelo qual uma estimativa generosa no primeiro dia é mais cara aqui do que em plataformas que permitem sobrealocação.

Reduzir a memória requer uma reinicialização, pois o VMM Pro não remove memória de uma máquina virtual em execução. Aumentar o tamanho do disco virtual e o número de recursos é feito em tempo real, mas remover memória significa desligar a máquina virtual. Reserve um curto período para a interrupção e agende-a; dois minutos são possíveis, mas não é zero.

Discos virtuais crescem e nunca diminuem. Se você alocou armazenamento em excesso em vez de memória, VMM Pro Não vou devolver. A única solução é criar um novo servidor para convidados e migrar para ele, o que levaria muito mais tempo do que esta tarde.

Os limites de CPU dentro de contêineres podem não funcionar de forma alguma. Neste sistema operacional convidado, o kernel não possui controle de largura de banda CFS, portanto, as cotas de CPU do contêiner são rejeitadas imediatamente — e pior, tentar definir uma cota no mesmo comando que um limite de memória faz com que todo o comando falhe silenciosamente. Os limites de memória e o limite máximo de processos do próprio aplicativo são a única proteção de CPU disponível.

Um snapshot não é um backup. Ele reside no mesmo host e no mesmo pool de armazenamento que a máquina virtual que protege. O VMM Pro pode replicar snapshots para outro host mais próximo, mas o que realmente sobrevive a um incêndio é o backup externo dos dados em si.

Por fim, observe o que o console exibe. As páginas de detalhes do contêiner mostram as variáveis de ambiente em texto simples, incluindo as senhas do banco de dados. Isso demonstra a honestidade do Docker, e não uma falha no pacote, mas significa que uma única captura de tela da página errada pode expor uma credencial. Se isso lhe incomoda — e deveria —, mova os segredos para um arquivo que o contêiner lê, em vez de passá-los como variáveis.

Referências

• SynoPower Club, nossos guias para o NAS Synology e análises de câmeras
• Synology — Virtual Machine Manager, a comparação oficial de recursos e edições
• Centro de Conhecimento Synology — Ajuda Virtual Machine Manager, configurações do convidado e configuração do cluster
• Docker — atualização de contêiner do Docker, alterando o limite de memória de um contêiner em execução
• Apache — MaxRequestWorkers, o limite de trabalhadores discutido na seção sete

Perguntas frequentes