Dois planos podem listar o mesmo número de vCPU e a mesma memória, e ainda assim um conclui a migração de um banco de dados em minutos enquanto o outro fica travado por uma hora. A diferença geralmente está no caminho de armazenamento: drives NVMe conectados via PCIe versus SSDs SATA ou SAS atrás de uma controladora tradicional.
Este guia explica o que de fato diferencia os dois, quais cargas de trabalho ganham com NVMe e quais não ganham, como medir um servidor você mesmo com fio antes de se comprometer e por que as franquias de transferência e a localização fazem parte da mesma decisão.
O que realmente difere: interface, protocolo e filas
A diferença vem da forma como o drive se comunica com a CPU. SSDs SATA usam o protocolo AHCI, projetado para discos giratórios, sobre um link que chega no máximo a 6 Gbps, o que na prática significa cerca de 550 MB/s de throughput sequencial. O SAS eleva o link para 12 Gbps e acrescenta recursos corporativos como dual porting, mas ainda passa por um host bus adapter ou por uma controladora RAID.
Os drives NVMe se conectam diretamente às lanes PCIe. A diferença mais importante para servidores está nas filas: o AHCI oferece uma única fila de comandos com 32 entradas, enquanto o NVMe permite até 64K filas com até 64K comandos cada.
Em uma VPS, o sistema convidado não enxerga o drive físico diretamente. Uma boa configuração do host preserva a maior parte da vantagem do NVMe. Uma configuração ruim, overcommit excessivo ou limites agressivos de I/O podem anulá-la.
IOPS, latência e profundidade de fila, explicados para quem compra
Três números descrevem o desempenho do armazenamento, e eles estão relacionados. IOPS é o número de operações de leitura ou escrita concluídas por segundo, geralmente medido com blocos pequenos de 4 KB. Latência é quanto tempo leva uma única operação. Profundidade de fila é quantas operações estão pendentes ao mesmo tempo.
Eles estão ligados por uma regra simples: IOPS é aproximadamente a profundidade de fila dividida pela latência. Um drive que responde em 100 microssegundos com profundidade de fila 1 entrega cerca de 10.000 IOPS. Os números de IOPS divulgados quase sempre são medidos com alta profundidade de fila, o que favorece os drives em condições que muitas aplicações nunca criam.
Um banco de dados transacional que confirma uma transação por vez, aguardando cada fsync, opera com algo próximo de profundidade de fila 1. Nesse caso, a latência importa mais do que o pico de IOPS. O NVMe normalmente reduz a latência do dispositivo em comparação com o SATA, e o caminho de software mais curto elimina overhead adicional, então a melhoria aparece mesmo quando a aplicação não está disparando muitas requisições em paralelo.
A latência de cauda merece a maior atenção. Ao comparar servidores, observe a latência de conclusão nos percentis 99 e 99,9.
Cargas de trabalho que se beneficiam do NVMe
O NVMe compensa quando a aplicação é limitada pela latência de armazenamento ou por muitas operações pequenas simultâneas. Os casos mais claros são:
- Bancos de dados relacionais. PostgreSQL, MySQL e engines semelhantes gravam em um log a cada commit e leem páginas aleatórias quando o working set excede a memória. Menor latência de escrita aumenta a taxa de commits, e leituras aleatórias mais rápidas encurtam as consultas que não encontram os dados no buffer cache.
- Índices de busca e analytics. Elasticsearch, OpenSearch e engines semelhantes fazem merge de segmentos, atualizam índices e leem muitos arquivos pequenos. O NVMe reduz o tempo de indexação e mantém a latência das consultas estável durante os merges.
- Servidores de build e CI. Compilar grandes bases de código, resolver dependências e executar suítes de testes geram milhares de pequenas leituras e escritas de arquivos. Builds que no papel são limitados por CPU muitas vezes estão, na prática, esperando pelo armazenamento.
- Armazenamentos chave-valor com persistência. Sistemas que gravam snapshots ou logs append-only em disco se beneficiam de flushes rápidos, que reduzem a pausa que os usuários sentem durante a persistência.
- Hosts de containers e virtualização. Baixar imagens, iniciar muitos containers e rodar vários serviços movimentados em uma única máquina multiplicam a concorrência de I/O, que é exatamente onde as filas do NVMe ajudam.
- Jobs de processamento de dados. Etapas de ETL que ordenam, despejam em disco ou embaralham arquivos intermediários terminam mais rápido quando o armazenamento temporário é NVMe.
Cargas de trabalho em que SSD SATA ou SAS é suficiente
Muitas cargas de trabalho apresentam pouca ou nenhuma diferença, porque o armazenamento não é o gargalo delas.
- Sites com cache eficaz. Um site de conteúdo servido principalmente a partir da memória, de um cache de páginas ou de uma CDN lê muito pouco do disco depois do aquecimento.
- Servidores de aplicação stateless. Camadas de API e web que mantêm os dados em um banco de dados separado passam o tempo em CPU e rede.
- Entrega com uso intenso de banda. Distribuição de arquivos, origens de streaming e espelhos de download leem arquivos grandes de forma sequencial. Um SSD SATA a cerca de 550 MB/s já supera o que uma porta de 1 Gbps consegue transportar (cerca de 125 MB/s).
- Destinos de backup e arquivos. Escritas sequenciais de objetos grandes favorecem capacidade por dólar em vez de latência.
- Bancos de dados pequenos que cabem na memória. Se todo o working set fica na RAM, as leituras raramente tocam o disco, e taxas modestas de commit ficam bem dentro dos limites do SATA.
- Ferramentas internas de baixo tráfego. Wikis, sistemas de chamados e dashboards de monitoramento com algumas dezenas de usuários raramente geram pressão significativa de I/O.
Aqui, o orçamento costuma render mais em capacidade de SSD SATA ou SAS corporativo, memória ou banda ilimitada.
Como medir com fio antes de se comprometer
O fio é a ferramenta de código aberto padrão para benchmarks de armazenamento no Linux e está disponível nos repositórios de pacotes de todas as principais distribuições. Execute-o em um servidor de teste ou recém-provisionado, contra um arquivo de teste no mesmo sistema de arquivos que a sua aplicação vai usar, e nunca contra um dispositivo bruto que contenha dados.
Comece com um teste de leitura aleatória com concorrência moderada, que se aproxima de um banco de dados ou nó de busca sob carga: fio --name=randread --filename=/var/tmp/fiotest --size=4G --rw=randread --bs=4k --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting.
Depois, execute um teste que reproduza commits de banco de dados: fio --name=commit --filename=/var/tmp/fiotest --size=1G --rw=randwrite --bs=4k --ioengine=libaio --direct=1 --iodepth=1 --numjobs=1 --fsync=1 --runtime=60 --time_based.
Por fim, execute um teste sequencial com --rw=read e --bs=1M para confirmar o throughput para backups e trabalho com arquivos grandes. Ao ler os resultados, registre IOPS, banda e os percentis de latência de conclusão (clat) em p50, p99 e p99.9. Em infraestrutura compartilhada, resultados consistentes entre execuções são tão importantes quanto o número de pico, porque mostram quão bem o host isola os vizinhos.
Exclua o arquivo de teste depois. Evite benchmarks pesados em produção no horário comercial: eles disputam recursos com o tráfego real.
Franquias de transferência, portas com tráfego ilimitado e custo total
Um plano só é barato se os seus termos de transferência corresponderem ao volume de dados que você realmente movimenta.
Uma porta de 1 Gbps transfere cerca de 125 MB por segundo, aproximadamente 10,8 TB por dia ou cerca de 324 TB por mês em plena carga. Uma franquia mensal de 3 TB corresponde a uma média sustentada de apenas cerca de 9 Mbps, e 16 TB a cerca de 49 Mbps.
Planos medidos com franquia atendem cargas de trabalho em que o desempenho de armazenamento é a prioridade e o tráfego é moderado e previsível. Verifique o que acontece quando a franquia é excedida: cobrança de excedente por terabyte, redução para uma velocidade menor ou upgrade obrigatório. Planos com tráfego ilimitado cobram um preço fixo pela porta e atendem cargas de trabalho com egress elevado ou imprevisível. Confirme a velocidade da porta, se ela é dedicada ou compartilhada e quaisquer termos de uso justo.
Estime o egress mensal a partir dos logs atuais ou dos dados de faturamento do provedor, acrescente folga para o crescimento e para o tráfego de backup que sai do servidor e compare o custo mensal total, incluindo excedentes, entre as opções. Às vezes, a arquitetura certa divide a carga de trabalho: NVMe para a camada de banco de dados com uma franquia modesta e servidores SSD com tráfego ilimitado para a camada de entrega.
Como escolher a localização de um VPS
A localização afeta latência, conformidade e custo. A luz na fibra óptica percorre cerca de 200 km por milissegundo, então cada 100 km de fibra acrescenta aproximadamente 1 ms ao tempo de ida e volta, antes de qualquer overhead de roteamento. Os caminhos reais são mais longos do que linhas retas, e é por isso que um servidor em outro continente costuma acrescentar de 100 a 250 ms a cada ida e volta.
- Coloque os servidores perto dos usuários. Meça o tempo de ida e volta a partir das regiões de onde vem a maior parte do tráfego, usando ping, mtr ou monitoramento sintético.
- Mantenha juntos os componentes que conversam muito. Um servidor de aplicação e seu banco de dados devem ficar no mesmo local. Armazenamento NVMe rápido é desperdiçado se cada consulta atravessa um oceano.
- Verifique a residência de dados. Regulamentações e contratos com clientes podem exigir que os dados permaneçam em um país específico. Confirme onde ficam armazenados o servidor, seus backups e quaisquer réplicas.
- Planeje para a falha de uma região. Um segundo local para backups ou um warm standby protege contra uma indisponibilidade em uma instalação.
- Compare preços regionais e condições de transferência. A mesma configuração pode ter franquias e custos diferentes em regiões diferentes.
Tabela de decisão e checklist
Tabela de decisão: cada linha associa um perfil de carga a um tipo de armazenamento e um modelo de transferência.
- Banco de dados transacional, working set maior que a memória. Escolha NVMe. Uma franquia medida costuma bastar, já que o tráfego de banco de dados fica majoritariamente interno.
- Cluster de busca ou índice de analytics. Escolha NVMe com memória suficiente para o cache do sistema de arquivos. As necessidades de transferência costumam ser moderadas.
- Servidor de build ou CI. Escolha NVMe. Considere os downloads de dependências e artefatos na estimativa de transferência.
- Site com cache ou camada de API stateless. SSD SATA ou SAS basta. Escolha tráfego ilimitado se o tráfego público for grande ou tiver picos.
- Entrega de arquivos, origem de streaming ou espelho. SSD de alta capacidade e uma porta com tráfego ilimitado. NVMe acrescenta pouco, porque a rede limita o throughput.
- Destino de backup ou arquivo. Capacidade em primeiro lugar. SSD ou armazenamento em bloco de rede, dimensionado para a retenção, com condições de transferência que cubram o tráfego de restauração.
- Carga de trabalho mista em uma única máquina. Escolha NVMe para a camada de dados ou divida as camadas entre servidores para que cada uma tenha o modelo de armazenamento e de transferência de que precisa.
Antes de assinar, percorra este checklist:
- Use o monitoramento atual para achar o limite: latência, throughput, CPU ou rede.
- Rode testes fio de leitura aleatória, fsync e sequenciais; registre a latência p99 e p99.9.
- Repita os testes em horários variados para checar hosts compartilhados.
- Estime o egress mensal pelos logs, some o crescimento e compare com a franquia ou a velocidade da porta.
- Confirme por escrito as condições de excedente, throttling ou uso justo.
- Meça o tempo de ida e volta das principais regiões de usuários a cada local.
- Confirme o país dos dados, backups e réplicas.
- Verifique hipervisor, interface de disco e limites de I/O publicados por plano.
- Planeje backups em uma segunda localidade e teste uma restauração.
Como a Vonahost pode ajudar
A linha VPS NVMe roda em KVM com até 8 vCPU, 32 GB de memória e 500 GB de NVMe, com 3 a 16 TB de transferência mensal, na região que você escolher. A linha VPS SSD usa SSD enterprise com até 12 núcleos, 64 GB de memória e 800 GB de armazenamento, tráfego ilimitado e Linux ou Windows, na região que você escolher. Para workloads que superam um VPS, os servidores dedicados single-tenant oferecem NVMe local (2 x 960 GB) com porta dedicada de 1 Gbps e tráfego ilimitado.
Toda proposta especifica a configuração, a localização, as responsabilidades e o preço mensal em dólares americanos, e você escolhe o país de cada servidor.