VPS para OpenSearch e Elasticsearch

Resposta direta

Para hospedar OpenSearch ou Elasticsearch em VPS, comece pela memória: 4 GB de RAM é o piso para testes sérios, 8 GB já permite produção pequena e 16 GB ou mais faz sentido para logs, e-commerce, catálogos e buscas com maior volume. Configure o heap da JVM em cerca de 50% da RAM disponível, mantenha espaço para cache do sistema operacional e prefira SSD rápido ou NVMe quando houver muita indexação. Uma VPS adequada também precisa de snapshots do índice, backup externo, monitoramento de heap, CPU, disco e latência de consultas. O nó único serve para baixo volume e ambientes internos, mas produção crítica pede cluster, réplicas, testes de restauração e plano de migração antes que shards, merges e retenção virem gargalo.

Resumo rápido

• OpenSearch e Elasticsearch funcionam em VPS, mas dependem muito de RAM, disco rápido e configuração correta de heap.
• Para produção pequena, use como referência 2 a 4 vCPUs, 8 GB de RAM e 80 a 160 GB em SSD ou NVMe.
• O heap da JVM costuma ficar em 50% da RAM, deixando o restante para cache de arquivos, rede, processos e sistema operacional.
• NVMe ajuda em indexação, merges e consultas pesadas, mas não corrige shards excessivos, mapeamentos ruins ou retenção longa demais.
• Snapshots do índice são obrigatórios para recuperação, enquanto snapshot da VPS sozinho pode gerar inconsistência em ambientes ativos.
• Monitoramento precisa cobrir heap, GC, uso de disco, latência p95, filas de thread pool e saúde do cluster.
• VPS de nó único é aceitável para busca interna, laboratório e logs modestos, mas não substitui cluster em produção crítica.

OpenSearch ou Elasticsearch em VPS: quando faz sentido

OpenSearch e Elasticsearch são motores de busca distribuídos baseados em índices invertidos, muito usados para busca textual, análise de logs, observabilidade, catálogos e filtros avançados. Em uma VPS, eles entregam bastante controle: você escolhe versão, plugins, política de retenção, snapshots, autenticação, heap, armazenamento e integração com aplicações. Esse controle é útil quando a equipe quer fugir das limitações de um serviço gerenciado, precisa reduzir dependências externas ou trabalha com dados que devem ficar em uma região específica.

O cenário mais comum é uma aplicação web que precisa buscar produtos, documentos, imóveis, chamados ou registros de auditoria. Um e-commerce com 50 mil produtos pode usar OpenSearch em um nó de 8 GB de RAM para autocomplete, filtros por categoria e ordenação por relevância, desde que os índices sejam bem desenhados. Já um sistema de logs que recebe 5 GB por dia exige outro raciocínio: retenção, rotação de índices e custo de disco passam a pesar mais do que a busca textual em si.

A VPS também faz sentido para ambientes de laboratório e homologação. Um time pode validar pipelines do Logstash, Beats, Fluent Bit ou OpenTelemetry antes de levar a arquitetura para produção. Nesse caso, uma máquina com 2 vCPUs, 4 GB de RAM e 60 GB de SSD já permite testar dashboards, templates de índice e políticas de ciclo de vida. Se o objetivo é aprender, não comece com cluster. Primeiro entenda heap, shards, snapshots e consultas lentas.

O cuidado está na disponibilidade. Um nó único concentra tudo: dados primários, coordenação, ingestão e busca. Se a VPS cair, a busca cai junto. Se o disco encher, o cluster pode bloquear gravações. Se o heap ficar pressionado, as consultas ficam instáveis. Para produção que impacta receita, o nó único deve ser visto como etapa inicial, não como arquitetura final. Cloud Server com upgrade rápido pode ajudar no crescimento, mas VPS tradicional bem escolhida ainda atende projetos pequenos quando há backup, monitoramento e processo de restauração documentado.

Como dimensionar CPU, RAM, heap e disco

O dimensionamento começa pela pergunta mais simples: você vai indexar mais ou consultar mais? Busca de catálogo costuma ter picos de leitura, enquanto logs e eventos têm escrita constante. Para um projeto pequeno, uma VPS com 2 vCPUs, 8 GB de RAM e 80 GB de SSD pode sustentar um índice com alguns milhões de documentos, desde que as consultas não façam agregações pesadas em campos de alta cardinalidade. Para logs de produção, pense em 4 vCPUs, 16 GB de RAM e 160 GB ou mais, principalmente se a retenção passar de 7 a 15 dias.

A RAM é o recurso mais sensível porque OpenSearch e Elasticsearch usam JVM. Uma regra prática segura é configurar o heap em até 50% da RAM, sem ocupar tudo. Em uma VPS com 8 GB, use heap de 4 GB e deixe os outros 4 GB para cache do sistema operacional, buffers, processos auxiliares e o próprio kernel. Em 16 GB, heap de 8 GB costuma ser um bom ponto de partida. Em máquinas maiores, evite subir heap sem critério, pois heaps muito grandes podem aumentar pausas de garbage collection e reduzir previsibilidade.

CPU entra forte em três momentos: indexação, consultas com agregações e merges de segmentos. Uma aplicação de busca com poucos writes pode viver bem com 2 vCPUs. Um pipeline de logs com ingestão constante, análise de campos e dashboards simultâneos se comporta melhor com 4 a 8 vCPUs. Se você usa ingest pipelines com grok, enriquecimento, normalização de IP e parsing de user-agent, reserve CPU extra. O gargalo nem sempre aparece como 100% de uso médio; às vezes ele surge como latência p95 alta e fila nos thread pools de write ou search.

Antes de contratar, compare CPU, RAM e disco como conjunto. O guia interno sobre como escolher CPU, RAM e NVMe ajuda a evitar uma compra desequilibrada, por exemplo muita CPU com pouco disco ou NVMe rápido com RAM insuficiente. Para OpenSearch e Elasticsearch, equilíbrio importa mais do que um recurso isolado. Um nó com 4 vCPUs, 16 GB de RAM e NVMe pode perder para outro com menos IOPS se o primeiro tiver shards demais, heap mal ajustado e retenção sem política de rollover.

Também configure limites do sistema operacional. Em Linux, vm.max_map_count=262144 é uma configuração comum para Elasticsearch e OpenSearch. Aumente file descriptors para algo como 65535, desative swap ou reduza sua influência com swappiness baixo, e use bootstrap.memory_lock quando a distribuição e o serviço permitirem. Esses ajustes parecem pequenos, mas reduzem falhas de bootstrap e comportamento errático sob carga.

NVMe, IOPS e desenho dos índices

NVMe é atraente para OpenSearch e Elasticsearch porque muitos gargalos passam pelo disco: escrita de segmentos, merges, leitura de postings lists, doc values, recuperação de shards e snapshots. Em workloads com muita indexação, a diferença entre SSD básico e NVMe pode aparecer em menor tempo de merge e menor latência em momentos de pico. Ainda assim, disco rápido não substitui um desenho de índice saudável. Um índice com shards minúsculos, campos desnecessários e retenção descontrolada vai desperdiçar qualquer armazenamento.

Pense em shards como unidades de trabalho e armazenamento. Shards grandes demais dificultam recuperação e movimentação. Shards pequenos demais geram overhead de metadados, heap e arquivos abertos. Para muitos ambientes pequenos, shards entre 10 GB e 30 GB são mais fáceis de operar do que centenas de shards de 200 MB. Em logs, use rollover por tamanho ou tempo. Um exemplo simples: criar índice diário para 5 GB por dia pode funcionar, mas se o volume subir para 80 GB por dia, talvez faça sentido rollover por 30 GB e retenção de 7 dias, em vez de um índice enorme por dia.

O tipo de consulta também muda o perfil do disco. Busca textual em campos bem mapeados tende a usar cache e estruturas eficientes. Agregações em campos de alta cardinalidade, como user_id, session_id ou trace_id, podem pressionar heap e doc values. Ordenações por campos não otimizados também elevam custo. Antes de culpar a VPS, revise mappings, analyzers, campos indexados, campos armazenados e queries. Muitas instalações pequenas indexam JSON completo sem necessidade, mantendo campos que nunca serão pesquisados.

Na escolha do provedor, confirme o tipo de armazenamento por plano e localidade. Alguns provedores oferecem SSD em determinadas instâncias e NVMe em outras. Em LetsCloud, por exemplo, a disponibilidade de NVMe deve ser verificada por plano e região antes de qualquer publicação ou compra, sem tratar esse recurso como universal. O mesmo cuidado vale para DigitalOcean, Vultr, Linode ou Hetzner, pois nomes comerciais e recursos mudam. Dados de provedores usados como referência editorial foram registrados em 2026-06-29 e qualquer detalhe de preço, localidade, bandwidth ou storage precisa de revisão humana no site oficial.

Um exemplo prático: para um índice de produtos com 2 milhões de documentos, 8 GB de RAM e SSD rápido podem ser suficientes se houver poucas atualizações por minuto. Para logs com 20 GB por dia e dashboards de observabilidade, prefira 16 GB de RAM, NVMe quando disponível e política de retenção curta. Para auditoria com retenção longa, talvez o primeiro gargalo seja custo de disco, não CPU.

Snapshots, backup e recuperação sem susto

Snapshots são parte central da operação de OpenSearch e Elasticsearch. Eles salvam índices, metadados e estado necessário para restaurar dados de forma consistente. Snapshot da VPS, por sua vez, captura o disco da máquina em um ponto no tempo, mas pode não respeitar o estado interno do mecanismo se houver escrita ativa. Em ambiente pequeno, muita gente confunde os dois e descobre o problema só na restauração. A pergunta correta não é apenas se existe backup, mas se você consegue restaurar um índice específico em outra instância sem corromper dados.

Para produção, use repositório de snapshot fora da VPS sempre que possível. Pode ser armazenamento compatível com S3, bucket do provedor, volume dedicado ou destino remoto. Em um ambiente de logs de 10 GB por dia, uma política simples seria snapshot a cada 6 horas, retenção de 7 a 14 dias e teste de restauração semanal em uma VPS separada. Para busca de catálogo, snapshots diários podem bastar se os dados originais existirem no banco principal e puderem reindexar. A decisão depende do RPO, o quanto você aceita perder, e do RTO, quanto tempo pode ficar sem busca.

Backups automáticos do provedor continuam úteis. Eles ajudam a recuperar configuração do sistema, certificados, arquivos de serviço, scripts, dashboards e integrações. Só não devem ser o único mecanismo de proteção dos índices. O ideal é combinar snapshot nativo do OpenSearch ou Elasticsearch com backup da VPS, documentação de restauração e exportação de configurações. O artigo sobre VPS com backup automático aprofunda essa diferença entre conveniência operacional e estratégia real de recuperação.

Faça testes com dados pequenos antes de confiar no processo. Crie um índice de teste, gere snapshot, apague o índice e restaure em outro nome. Depois repita em uma VPS nova. Esse exercício revela permissões quebradas, plugins ausentes, versões incompatíveis e problemas de rede. Também ajuda a estimar tempo de recuperação. Um snapshot de 20 GB pode parecer simples, mas restaurar 500 GB durante um incidente, com cliente esperando, muda completamente a pressão operacional.

Outro ponto é espaço livre. OpenSearch e Elasticsearch precisam de margem para merges, translogs e recuperação. Trabalhar acima de 85% de disco usado é pedir bloqueio de escrita. Acima de 90%, o risco cresce bastante. Configure alertas antes disso, por exemplo 70%, 80% e 85%. Em VPS pequena, apagar logs do sistema não resolve se o índice principal continua crescendo. A retenção precisa estar no mecanismo, não apenas no sistema operacional.

Monitoramento, segurança e rotina de operação

Um nó de OpenSearch ou Elasticsearch sem monitoramento vira caixa-preta. A aplicação começa a demorar, o time aumenta RAM no escuro e o problema real pode estar em shard allocation, garbage collection, disco cheio ou query mal escrita. O painel mínimo deve mostrar uso de heap, pausas de GC, CPU, load average, uso de disco, IOPS, latência p95 de busca, taxa de indexação, filas de thread pool, número de shards, documentos por índice e status do cluster. Se você já usa Prometheus e Grafana, a integração com exporters reduz bastante o esforço inicial. O guia de VPS para monitoramento com Grafana e Prometheus ajuda a estruturar essa camada sem misturar tudo no mesmo servidor de produção.

Em VPS pequena, evite colocar aplicação, banco de dados, Redis, OpenSearch e stack de monitoramento na mesma máquina. Funciona em laboratório, mas complica diagnóstico. Um exemplo comum é o Elasticsearch ser acusado de consumir memória, quando o problema real é o banco disputando cache de disco. Se o orçamento permitir, separe pelo menos o mecanismo de busca da aplicação principal. Para logs, separe também o coletor quando o volume crescer. Fluent Bit, Logstash e ingest pipelines podem consumir CPU relevante.

Segurança precisa ser tratada desde o primeiro dia. Não exponha a porta 9200 diretamente para a internet. Use firewall permitindo apenas IPs da aplicação, VPN, rede privada ou bastion host. Ative TLS quando houver tráfego entre serviços, use autenticação forte e crie usuários com permissões específicas. Nada de credencial única para aplicação, dashboards e administração. Em ambientes com OpenSearch Dashboards ou Kibana, proteja o acesso com HTTPS, MFA quando disponível no proxy ou provedor de identidade, e logs de auditoria.

A rotina semanal deve incluir checagem de snapshots, análise de slow logs, revisão de índices antigos, atualização de pacotes e teste de alertas. Uma rotina mensal pode revisar templates, retenção, tamanho médio de shards e crescimento de disco. Em projetos pequenos, essa disciplina parece exagero até o primeiro incidente. Depois vira economia de tempo. Um checklist simples já resolve bastante: heap abaixo de 75% na maior parte do tempo, disco abaixo de 80%, snapshots recentes, queries lentas investigadas e versões sem vulnerabilidades conhecidas.

Também cuide do sistema operacional. Use usuário sem senha para SSH com chave, desabilite login root direto quando possível, mantenha firewall ativo, instale apenas plugins necessários e documente alterações. Nunca coloque chaves de acesso em scripts versionados. Para snapshots em armazenamento externo, use variáveis de ambiente, arquivos protegidos ou mecanismo seguro do plugin, sempre com permissões mínimas.

Limites de escala e comparação prática de perfis

A VPS de nó único tem um limite natural: ela não oferece alta disponibilidade real. Você pode aumentar CPU, RAM e disco, mas continua com um único ponto de falha. Para muitos projetos, isso é aceitável no começo. Busca interna de um painel administrativo, catálogo pequeno, logs de desenvolvimento e auditoria de baixo volume não justificam cluster logo no primeiro mês. O problema aparece quando a busca passa a ser parte do caminho crítico, por exemplo checkout, atendimento, recomendação de produto ou investigação de incidentes em produção.

A tabela abaixo usa perfis técnicos, não preços. Dados de provedores e recursos variáveis devem ser confirmados nos sites oficiais, com última coleta editorial registrada em 2026-06-29. Não há recomendação absoluta de marca, porque localização, disco, suporte, painel, política de backup e rede mudam conforme plano.

Perfil de uso	Configuração inicial sugerida	Volume típico	Riscos principais	Próximo passo
Laboratório e homologação	2 vCPUs, 4 GB RAM, 60 GB SSD	até 1 milhão de docs ou logs temporários	heap apertado, disco pequeno, sem HA	testar mappings, snapshots e dashboards
Busca de aplicação pequena	2 a 4 vCPUs, 8 GB RAM, 80 a 160 GB SSD ou NVMe	alguns milhões de docs, baixa escrita	consultas lentas, shards mal definidos	separar da aplicação e criar backup externo
Logs e observabilidade interna	4 vCPUs, 16 GB RAM, 160 a 320 GB NVMe quando disponível	5 a 30 GB por dia	retenção alta, merges, disco cheio	rollover, retenção curta e monitoramento dedicado
Produção crítica	3 nós ou serviço gerenciado, 16 GB RAM por nó ou mais	busca impacta receita ou operação	indisponibilidade, recuperação lenta	cluster, réplicas, testes de failover

Um sinal claro para sair do nó único é quando a janela de manutenção passa a incomodar o negócio. Se reiniciar a VPS por 5 minutos já gera chamados, você precisa de arquitetura com réplica. Outro sinal é recuperação lenta. Se restaurar snapshot demora horas e a aplicação depende da busca para operar, o risco está alto. Também observe crescimento de shards. Quando o cluster passa a ter centenas de shards pequenos em um único nó, o overhead de heap e metadados começa a roubar estabilidade.

Há três caminhos de evolução. O primeiro é vertical: aumentar RAM, CPU e disco da VPS. É simples, mas tem teto. O segundo é criar cluster com três nós, separando funções quando o volume justificar. O terceiro é migrar para serviço gerenciado, aceitando custo maior em troca de operação simplificada. Para times pequenos, a melhor sequência costuma ser nó único bem monitorado, depois cluster pequeno, e só então serviço gerenciado se a operação interna ficar cara demais.

Recomendações por perfil

Dev solo e projeto pequeno

Se você é dev solo, comece pequeno, mas não comece no limite. Para uma API, SaaS inicial ou painel administrativo com busca textual, uma VPS com 2 vCPUs, 8 GB de RAM e 80 GB de SSD é um ponto de partida mais saudável do que 1 GB ou 2 GB de RAM. Configure heap com 4 GB, limite campos indexados, mantenha apenas um shard primário para índices pequenos e crie snapshot diário. Se os dados originais estão em PostgreSQL ou MySQL, documente um processo de reindexação. Isso reduz dependência do snapshot para cenários simples.

Nesse perfil, o maior erro é instalar tudo na mesma VPS e esquecer monitoramento. Se precisar economizar, tudo bem rodar aplicação e busca juntas por poucas semanas, mas marque uma data para separar. Quando as consultas começarem a competir com deploys, workers e banco, o diagnóstico fica ruim. Use firewall, não exponha a porta 9200 e registre métricas básicas desde o primeiro dia.

Time de produto ou observabilidade interna

Para um time que usa OpenSearch ou Elasticsearch em busca de aplicação, logs de serviço ou dashboards internos, pense em 4 vCPUs, 16 GB de RAM e disco de 160 GB ou mais. Use heap de 8 GB, retenção definida e snapshots fora da VPS. Se a ingestão passa de 5 GB por dia, crie política de rollover por tamanho e monitore merges. Também vale separar ingestão, aplicação e dashboards quando o tráfego crescer. Uma arquitetura simples com VPS dedicada para busca e outra para aplicação já evita boa parte dos conflitos.

Esse perfil costuma sofrer com crescimento silencioso. Hoje são 2 GB de logs por dia. Em três meses, viram 20 GB por dia porque novos serviços passaram a enviar payload completo. Crie padrões de logging, descarte campos inúteis e defina retenção por tipo de dado. Logs de debug não precisam viver 30 dias em SSD caro. Eventos de auditoria talvez precisem, mas podem ir para armazenamento frio depois.

Produção crítica e crescimento previsível

Quando a busca afeta receita, atendimento, antifraude, incidentes ou operação 24 horas, trate VPS de nó único como risco temporário. A configuração recomendada passa a ser cluster com pelo menos três nós, réplicas, snapshots frequentes e testes de failover. Cada nó pode começar com 4 a 8 vCPUs, 16 GB de RAM e NVMe, dependendo do volume. O heap deve ser igual entre nós de dados semelhantes, e a distribuição de shards precisa ser acompanhada após cada rollover ou aumento de carga.

Nesse cenário, avalie também serviço gerenciado. VPS entrega controle e pode ter bom custo operacional para equipes experientes, mas exige plantão, patching, restauração, segurança e ajuste de performance. Se o time não tem alguém responsável por isso, o custo escondido aparece nos incidentes. Para provedores como DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo ou LetsCloud, confirme regiões, tipo de disco, backup, snapshot, bandwidth e suporte antes da decisão. Sem benchmark próprio e metodologia clara, não assuma performance superior de um plano sobre outro.