Servidor cloud para Elasticsearch na Europa: hospedagem de busca EU

Servidor cloud para Elasticsearch na Europa: hospedagem de busca EU

Servidor cloud para Elasticsearch na Europa: hospedagem de busca EU

Elasticsearch e a espinha dorsal da pesquisa de texto completo, analítica de logs e stacks de observabilidade em aplicações modernas. Para empresas que lidam com dados sobre usuários europeus, onde esse índice de pesquisa vive tem implicações diretas para a conformidade com o RGPD e os tempos de resposta das consultas.

Por que a residência de dados na UE importa para Elasticsearch

Os indices do Elasticsearch geralmente contem conteúdo gerado por usuários, logs comportamentais e dados de documentos vinculados a identidades individuais - todos dados pessoais sob o RGPD. A hospedagem em um servidor EU operado por uma empresa europeia significa que seu índice de pesquisa nunca sai da jurisdição da UE.

A proximidade de rede também importa para pesquisa. Um cluster do Elasticsearch na Europa Central responde a consultas de uma aplicação em Berlim em 2-5 ms. O mesmo cluster em um data center dos EUA adiciona 80-120 ms por consulta.

Especificações mínimas para Elasticsearch

  • Pequeno (dev/logging, ate 50 GB de índice) - 4 vCPU, 16 GB RAM, 200 GB NVMe SSD
  • Médio (pesquisa de produção, 50-500 GB) - 8 vCPU, 32 GB RAM, 1 TB NVMe SSD
  • Grande (analítica, índice multi-TB) - 16+ vCPU, 64 GB RAM, 2+ TB NVMe SSD

Configuração recomendada da DCXV

Os servidores cloud da DCXV fornecem armazenamento NVMe com IOPS consistente:

  • 8 vCPU, 32 GB RAM, 1 TB NVMe - no de cluster de pesquisa de produção
  • 16 vCPU, 64 GB RAM, 2 TB NVMe - analítica de logs ou stack de observabilidade

Contate sales@dcxv.com para configuração de cluster.

Comandos de configuração rápida

# Instalar Elasticsearch 8.x no Ubuntu 22.04
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

sudo apt update && sudo apt install -y elasticsearch
sudo systemctl start elasticsearch && sudo systemctl enable elasticsearch
# Tamanho do heap JVM - 50% da RAM
-Xms16g
-Xmx16g

# Desabilitar swap
sudo swapoff -a
echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Os quatro números que decidem se fica de pé

RAM e disco são a parte fácil. Estes são os ajustes que derrubam um cluster, e três dos quatro são contraintuitivos o bastante para que mais hardware os piore:

Ajuste A regra Por quê Como parece quando dá errado
Tamanho do heap Metade da RAM, e nunca acima de 31 GB Acima de ~32 GB a JVM perde os ponteiros comprimidos Um heap de 64 GB endereça menos que um de 31 GB
Shards por nó Menos de 20 por GB de heap Cada shard custa heap, seja consultado ou não Estado do cluster lento, depois nós saindo
Tamanho do shard 10-50 GB cada Menores desperdiçam overhead, maiores não rebalanceiam A recuperação após um reinício leva horas
Swap Desligado, com memória travada Um heap de JVM em swap trava a coleta de lixo Pausas aleatórias de segundos sem carga real

O que pega as pessoas é a contagem de shards, porque o instinto diante de um cluster lento é adicionar nós e dividir mais os índices. Isso gasta ainda mais heap em contabilidade e piora o problema. Conte primeiro os shards que você tem: um índice por dia durante um ano são 365 shards onde um índice mensal teria 12.

Desempenho esperado

Em um no 8 vCPU / 32 GB RAM / NVMe com Elasticsearch 8.x:

  • Throughput de indexação (API bulk) - 15.000-30.000 docs/s
  • Consultas por segundo - 500-1.500 QPS
  • Latência P99 (consulta quente) - menos de 10 ms

Estas são expectativas para hardware desta classe, não medições do nosso próprio laboratório. Use-as como ponto de partida para o dimensionamento e meça a sua própria carga: os números reais dependem dos seus dados, das suas consultas e do seu tuning muito mais do que do fornecedor.

Conclusão

Elasticsearch em um servidor cloud da UE mantem seu índice de pesquisa sob jurisdição da UE enquanto oferece pesquisa de baixa latência e alta taxa de transferência.

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda
networkingcloudinfrastructure

Starlink Mini 2 atrás de CGNAT: como chegar a um local que muda

A Starlink Mini 2 chegou, mas os planos normais ficam atrás de CGNAT. Contámos 990.208 IPv4 para 12+ milhões de clientes e comparamos quatro formas de acesso.

Protestos contra centros de dados na Europa: o que fazer
clouddedicatedinfrastructure

Protestos contra centros de dados na Europa: o que fazer

A 6 de novembro, centenas entraram na obra da Microsoft em Amesterdão. Os números da rede neerlandesa, a latência medida a hubs da UE e o que fazer agora.

EUA rejeitam centros de dados 45 a 1: lições para clientes
clouddedicatedinfrastructure

EUA rejeitam centros de dados 45 a 1: lições para clientes

47 votações sobre centros de dados nos EUA, o lado restritivo venceu em 45. Recontamos os dados brutos e explicamos o que muda para quem aluga servidores.

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24
ipv4pricingcloud

AWS BYOIP em 2026: $43.80 por IPv4 ou o seu próprio /24

A AWS cobra $0.005 por hora por IPv4 público, $43.80 por ano. O BYOIP não paga isso: quando um /24 comprado ou alugado compensa, com uma verificação de ROA.

Sair do VMware após a Broadcom: guia de migração verificado
clouddedicatedinfrastructure

Sair do VMware após a Broadcom: guia de migração verificado

A Broadcom acabou com licenças perpétuas, cortou parceiros e escondeu o VDDK. Como mover VMs para KVM, Proxmox ou Hyper-V, com datas e uma conversão OVA testada.