O que é um servidor dedicado virtual? VDS vs VPS vs dedicado

O que é realmente um servidor dedicado virtual

Um servidor dedicado virtual (VDS) é uma máquina virtual recortada de um anfitrião físico por um hipervisor (na maioria das vezes KVM em Linux, por vezes Xen, VMware ESXi ou Hyper-V), com uma propriedade que o define: os recursos indicados na fatura estão reservados. Dois núcleos significam duas threads do anfitrião postas de parte para essa VM; 8 GB de RAM significam 8 GB que o anfitrião nunca empresta a outro inquilino. Dentro da máquina tem o seu próprio kernel, a sua própria imagem de disco, direitos totais de root ou de Administrador e qualquer sistema operativo que o hipervisor consiga arrancar: um pequeno servidor dedicado do ponto de vista do convidado, um inquilino entre vários que nunca competem pela mesma alocação do ponto de vista do anfitrião.

O termo existe porque "VPS" se tornou demasiado abrangente. Um VPS tanto pode ser um contentor OpenVZ com RAM em burst como uma máquina KVM num anfitrião que vende o mesmo núcleo físico a seis clientes. "VDS" foi adotado por fornecedores que queriam dizer "este não está sobrevendido". Não há norma alguma por trás do rótulo: no mercado de alojamento de língua russa, VDS e VPS são intermutáveis, e alguns fornecedores noutros lugares renomeiam uma gama de VPS simples porque VDS soa mais próximo de dedicado. A palavra revela a intenção; os comandos abaixo revelam a verdade.

VDS vs VPS vs servidor dedicado

Os produtos diferem em dois eixos: como a máquina é isolada (contentor, máquina virtual ou hardware físico) e se os recursos estão reservados ou partilhados. Um VDS situa-se entre um VPS partilhado e um servidor dedicado em ambos.

A coluna de preços é um intervalo aproximado de 2026 para planos de entrada, não um benchmark. Uma VM com quatro núcleos e 8 GB reservados não pode ser vendida por $3 por mês; quando um "VDS" tem preço de contentor, normalmente é isso mesmo.

Recursos reservados vs partilhados: onde está a diferença

CPU. No KVM, cada vCPU é uma thread do anfitrião que o escalonador do Linux trata como qualquer outro processo. Um anfitrião com 32 threads de hardware pode ser vendido como 32 vCPUs (1:1, reservados) ou como 128 vCPUs (4:1, partilhados). Nada dentro do convidado mostra esse rácio; ele só se torna visível sob a forma de steal time e picos de latência quando os vizinhos estão ocupados.

RAM. Os anfitriões KVM sobrecomprometem a memória de duas formas: o driver virtio balloon permite ao anfitrião reclamar páginas que um convidado não está a usar, e o KSM (kernel samepage merging) elimina páginas idênticas duplicadas entre VMs. Num plano reservado, a memória é comprometida quando a VM arranca e o balloon nunca é insuflado. Ver virtio_balloon no lsmod prova capacidade, não utilização: o driver vem em quase todas as imagens cloud.

Armazenamento. A reserva raramente se estende ao disco; quase todos os fornecedores partilham o backend de armazenamento e, no máximo, limitam as IOPS por VM. O que muda o desempenho é o nível subjacente: um disco NVMe entrega muito mais IOPS e menor latência do que um SSD SATA, e nenhuma reserva de CPU compensa um disco lento debaixo de uma base de dados.

Rede. A ligação de uplink é partilhada em tudo o que não seja um servidor dedicado com porta própria; largura de banda "ilimitada" significa ilimitada (fair-use), não 1 Gbps garantido só para si.

KVM vs virtualização por contentores (OpenVZ, LXC)

Esta divisão decide se um "VDS" pode sequer ser dedicado. KVM, Xen e ESXi são virtualização por hardware: VT-x ou AMD-V permitem que cada convidado execute o seu próprio kernel sobre hardware virtual. OpenVZ, Virtuozzo, LXC e Docker são virtualização ao nível do sistema operativo: cada inquilino é um conjunto de processos sobre o kernel do anfitrião, separados por namespaces e limitados por cgroups. O Proxmox chama-lhes "CT", e muitos alojamentos de baixo custo vendem-nos como VPS. As consequências:

• uname -r devolve o kernel do anfitrião, que não escolheu e não pode atualizar. Historicamente, os anfitriões OpenVZ corriam séries de kernel muito antigas. Se não tiver a certeza do que uma máquina executa realmente, os comandos para descobrir a versão do SO e do kernel em Linux, Windows e macOS demoram segundos.
• Não pode carregar módulos do kernel: WireGuard, ZFS e tudo o que é distribuído como .ko dependem do anfitrião.
• A virtualização aninhada é impossível, e o Docker ou o systemd dentro do contentor só funcionam se o anfitrião o permitir.

Um convidado KVM não tem nenhuma dessas limitações: arranca a partir de uma ISO, executa qualquer kernel e pode expor VT-x aos seus próprios convidados se o anfitrião permitir a virtualização aninhada. Um VDS genuíno é, portanto, sempre uma VM completa.

Vizinhos barulhentos e steal time

Um vizinho barulhento é outro inquilino no mesmo anfitrião cujo uso de CPU, disco ou rede corta no seu. Num anfitrião KVM sobrecomprometido, o escalonador põe a sua vCPU na fila atrás das dos outros, e o tempo em que a sua vCPU esteve pronta a correr mas à espera é reportado ao convidado como steal time. O Linux expõe-o como o oitavo valor da linha cpu em /proc/stat, como a coluna st do vmstat e do top, e como %steal no mpstat e no sar.

Uma VM reservada deve mostrar steal igual ou próximo de zero mesmo com os vizinhos a trabalhar a todo o gás. Alguns por cento durante picos é normal em planos partilhados; steal de dois dígitos de forma sustentada significa que o anfitrião está sobrevendido, e as únicas soluções são outro nó ou um verdadeiro plano 1:1. O fornecedor não pode esconder esta métrica: o hipervisor escreve-a na própria contabilidade do convidado. Os contentores são diferentes: dentro de LXC ou OpenVZ, a coluna st costuma ficar a zero enquanto está a ser limitado; quando o runtime a expõe, cat /sys/fs/cgroup/cpu.stat (cgroup v2) mostra nr_throttled e throttled_usec a subir em vez disso.

Quando "VDS" é só marketing

Como o rótulo não é regulado, leia a página do plano à procura dos sinais que descrevem a arquitetura:

• "vCPU" sem rácio. Um plano reservado diz "núcleos dedicados" ou "1 vCPU = 1 thread". Se o suporte não conseguir indicar o rácio vCPU/thread, assuma que é partilhado.
• "RAM garantida" ao lado de "RAM em burst". Isto é vocabulário OpenVZ para um contentor com limite flexível, não uma VM com memória comprometida.
• Sem ISO personalizada, sem escolha de kernel, sem reinstalação livre. Estas restrições vêm da partilha do kernel do anfitrião.
• "Semidedicado" ou "híbrido" no nome. Palavras honestas para um plano partilhado com menos contenção. Está bem, só não é um VDS.

Muitos fornecedores usam VDS de forma honesta; as verificações abaixo resolvem a questão em menos de um minuto.

Como verificar o que realmente recebe

1. Identificar a camada de virtualização

systemd-detect-virt
# typical answers: kvm, qemu, xen, vmware, microsoft, openvz, lxc, docker, none
systemd-detect-virt --container   # container type, or none

virt-what (executado como root) dá a mesma resposta em distribuições sem systemd. lscpu | grep -i hypervisor deve imprimir Hypervisor vendor: KVM num convidado KVM; num contentor, o lscpu mostra a contagem total de núcleos do anfitrião em vez da sua alocação, e a presença de /proc/vz ou /proc/user_beancounters é um marcador claro de OpenVZ.

2. Ler o modelo e a contagem de CPU

nproc
grep -m1 'model name' /proc/cpuinfo
lscpu | grep -E '^(Model name|Socket|Core|Thread|CPU\(s\))'

nproc deve corresponder ao que comprou. Um nome de modelo como QEMU Virtual CPU ou Common KVM processor significa que o anfitrião mascara o CPU real por trás de um modelo genérico, escondendo conjuntos de instruções recentes como AVX; um modelo real como AMD EPYC 7443P significa passthrough do anfitrião. Nenhum dos dois prova reserva, mas um CPU mascarado sugere um anfitrião afinado para densidade.

3. Medir o steal time sob carga

vmstat 1 5          # last column: st
head -1 /proc/stat  # cpu user nice system idle iowait irq softirq steal guest guest_nice
stress-ng --cpu $(nproc) --timeout 60s   # package stress-ng, then watch vmstat

Meça numa hora de ponta. Se o st se mantiver perto de zero enquanto todas as vCPUs estão no máximo, os núcleos são efetivamente seus; repita ao longo de alguns dias, já que a contenção depende de quem mais partilha o nó.

4. Verificar a virtualização aninhada

grep -cE 'vmx|svm' /proc/cpuinfo   # more than 0: the virtualisation flag is exposed
ls -l /dev/kvm                     # appears once kvm_intel or kvm_amd is loaded
kvm-ok                             # Ubuntu: package cpu-checker

Se a flag estiver ausente, o anfitrião mascara o modelo de CPU ou tem a virtualização aninhada desativada, e nada que precise de um hipervisor correrá dentro do convidado. Um contentor nunca a expõe.

5. Observar o dispositivo de disco

lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /sys/block/vda/queue/rotational   # 0 = non-rotational

vda é um dispositivo de bloco virtio, a configuração normal do KVM; sda com um modelo QEMU HARDDISK é SATA emulado, ainda assim uma VM. Dentro de um contentor, o sistema de ficheiros raiz é muitas vezes uma montagem ploop ou simfs. Em convidados Windows, systeminfo | findstr /i hyper-v indica que foi detetado um hipervisor.

Escalões de preço e casos de uso

• VPS em contentor ($2-6): sites estáticos, pequenos bots, um ponto de saída VPN, ou seja, tudo aquilo em que o kernel não importa e em que abrandamentos ocasionais são aceitáveis.
• VPS KVM partilhado ($4-12): máquinas de desenvolvimento e staging, aplicações de baixo tráfego que precisam de kernel próprio e toleram picos de steal.
• VDS com recursos KVM reservados ($8-40): bots de trading, servidores de jogos, bases de dados, runners de CI, automação 24/7 e tudo o que seja sensível à latência e corra com CPU alto durante horas.
• Servidor dedicado ($60-300+): 100% de CPU sustentado em muitos núcleos, muita RAM, GPUs, o seu próprio hipervisor, ou regras que proíbem hardware partilhado. Um servidor dedicado bare-metal com acesso IPMI é o passo seguinte quando um VDS já não chega.

Se o escalão reservado se adequa à sua carga de trabalho, é exatamente isso que a rdp.monster vende: um VPS KVM com CPU e RAM reservados, armazenamento NVMe, acesso root ou de administrador completo, largura de banda ilimitada (fair-use), sem KYC, e criptomoedas aceites a par de cartões e PayPal, a partir de $8.99/mês. A máquina é entregue cerca de 10 segundos após a confirmação do pagamento, para que possa executar systemd-detect-virt e vmstat 1 nela antes de confiar no rótulo, as mesmas verificações que este artigo recomenda para qualquer fornecedor.

Perguntas frequentes

Um VDS é o mesmo que um VPS?

Tecnicamente ambos são servidores virtuais; VDS pretende sinalizar recursos reservados, sem sobrecomprometimento.

Ambos são servidores virtuais em hardware partilhado. A diferença é uma promessa, não uma tecnologia: um VDS deve correr como uma máquina virtual completa (normalmente KVM) com núcleos de CPU e RAM reservados para si, enquanto um VPS pode partilhar esses recursos com outros inquilinos ou até ser um contentor sobre o kernel do anfitrião. Como nenhuma norma impõe o termo, alguns fornecedores usam VDS e VPS de forma intermutável. Verifique com systemd-detect-virt, nproc e o steal time em vez de confiar no nome.

Como sei se o meu VPS é KVM ou OpenVZ?

Execute systemd-detect-virt; imprime kvm, openvz, lxc ou none numa só linha.

Execute systemd-detect-virt: imprime kvm, qemu, openvz, lxc ou none. Sem systemd, instale e execute virt-what como root. Mais duas pistas: lscpu | grep -i hypervisor mostra Hypervisor vendor: KVM num convidado KVM, e a presença de /proc/vz ou /proc/user_beancounters significa OpenVZ. Num contentor, nproc e uname -r também refletem o anfitrião e não o seu plano.

Qual é um steal time de CPU aceitável num servidor virtual?

Perto de zero em planos reservados; alguns por cento em picos é tolerável, dois dígitos sustentados significam anfitrião sobrevendido.

Num VDS com núcleos reservados, a coluna st de vmstat 1 deve ficar em 0 ou perto disso, mesmo em plena carga. Em planos partilhados, valores ocasionais de um dígito durante os picos são normais. Valores sustentados de dez por cento ou mais significam que o anfitrião está sobrecomprometido e que as suas vCPUs estão à espera atrás de outros inquilinos. Não há solução a partir de dentro do convidado: peça ao fornecedor para o migrar para um nó mais calmo, ou passe para um plano com rácio vCPU/thread de 1:1.

Posso correr Docker ou uma VM aninhada num servidor dedicado virtual?

Docker sim em qualquer convidado KVM; VMs aninhadas só se o anfitrião expuser a flag de CPU vmx ou svm.

Num VDS baseado em KVM, o Docker funciona como em qualquer máquina Linux, porque executa o seu próprio kernel. A virtualização aninhada (KVM, VirtualBox, Hyper-V dentro do convidado) exige que o anfitrião faça passthrough da extensão de virtualização do CPU: verifique com grep -cE 'vmx|svm' /proc/cpuinfo e confirme que /dev/kvm aparece depois de carregar kvm_intel ou kvm_amd. Em contentores OpenVZ ou LXC, as VMs aninhadas são impossíveis e o Docker depende inteiramente do que o anfitrião permitir.