Zo schaal je jouw On-Prem Elastic Observability cluster - deel 1
Vragen over het schalen van Elasticsearch worden meestal beantwoord met: “It depends”. En de waarheid is dat het ook echt afhangt van de situatie. Er zijn meerdere opties om met Elasticsearch op te schalen en uit te schalen, en weten wanneer je welke optie moet gebruiken is geen eenvoudige taak.
In twee blogposts probeer ik meer duidelijkheid te geven over de complexiteit van het schalen van een Elasticsearch cluster dat primair wordt gebruikt voor observability, simpelweg omdat dit de use case is waar ik het grootste deel van mijn carrière aan heb gewerkt.
Welke Elasticsearch hostingopties heb je?
Laten we eerst dieper ingaan op de verschillende Elasticsearch hostingopties die beschikbaar zijn: host-based, ECE, ECK en Elastic Cloud.
Self-hosted
Een self-hosted cluster draaien klinkt ingewikkeld, maar is minder moeilijk dan je misschien denkt. Er zijn meerdere opties waaruit je kunt kiezen voor het opzetten van je infrastructuur.
Host-based
Dit is de klassieke setup. Je bouwt je Elastic Stack op (gevirtualiseerde) hardware. Ik raad af om dit handmatig te doen, omdat dat foutgevoelig is. Ik adviseer om een automatiseringstaal te gebruiken, zoals Ansible, om je nodes in te richten voor Elasticsearch, Kibana, Fleet Server en alle andere componenten.
Je kunt een virtualisatieplatform gebruiken om je Elasticsearch nodes op te draaien, of kiezen voor bare metal. Het grootste nadeel van bare metal is dat opschalen niet mogelijk is. Bij gebruik van een virtualisatieplatform moet je ervoor zorgen dat het platform locatiebewust is, zodat je anti-affinity rules kunt toepassen. Zo voorkom je dat nodes met primary en replica shards voor dezelfde index op dezelfde hypervisor draaien.
ECE
ECE staat voor Elastic Cloud Enterprise en is de Elastic Stack gebouwd op Docker of, in nieuwere versies van ECE, Podman. ECE vormt de basis van het door Elastic gehoste cloudaanbod. De ECE-engine automatiseert de deployment van je Elastic Stack-instances en kan meerdere Elastic deployments beheren. Daarnaast regelt de engine de networking tussen de Docker/Podman-nodes, mits de juiste poorten beschikbaar zijn.
ECK
ECK staat voor Elastic Cloud on Kubernetes en wordt, zoals de naam al aangeeft, gebruikt om Elastic deployments op Kubernetes te beheren. ECK is nieuwer dan ECE en biedt geen uitgebreide UI om je deployments te beheren. ECK is vooral gericht op automatisering en configuration as code.
Elastic Cloud
Elastic biedt ook een managed oplossing met gehoste Elasticsearch, Kibana en andere Elastic Stack-componenten op grote cloudproviders zoals AWS, Google Cloud en Microsoft Azure. Hiermee kunnen organisaties systemen monitoren, dreigingen detecteren en snelle search experiences bouwen. Elastic Cloud biedt automatische updates, security patches en backups, wat zorgt voor betrouwbaarheid en veiligheid. Hoewel deze optie de complexiteit en kosten van het beheren van je eigen infrastructuur wegneemt, ben je nog steeds niet volledig verlost van beheertaken.
Overwegingen voor het bouwen en configureren van je self-hosted Elastic platform
De scaling-opties zijn grotendeels van toepassing op alle hostingopties, met een kleine uitzondering voor ECE, tenzij je bepaalde beschermingen uitschakelt.
In het algemeen
JVM heap size
Zet de JVM heap size niet tussen 32GB en 48GB. Java schakelt Compressed OOPs uit voor application heaps groter dan 32GB, waardoor de memory-allocatie verandert van 4 naar 8 bytes. Dit vermindert het aantal objecten dat in de heap kan worden opgeslagen. Dat betekent dat het verhogen van de maximale heap naar een waarde dicht bij 32GB en tot 47GB er juist voor zorgt dat er minder effectief geheugen beschikbaar is, wat kan leiden tot OutOfMemoryErrors.
Elasticsearch is veel beter geschikt om uit te schalen dan om op te schalen. Je bent dus beter af met meer, kleinere nodes dan met slechts een paar hele grote nodes.
CPU
Omdat Elasticsearch meerdere operaties gelijktijdig moet uitvoeren, moet je niet minder dan 2,5 vCPUs gebruiken.
Storage
Elasticsearch adviseert 45GB storage per GB RAM voor hot data nodes. In mijn ervaring kun je dit enigszins oprekken en veilig richting 60GB per GB RAM gaan, of zelfs 90GB/GB RAM. Zoals altijd geldt: it depends.
Deze ratio’s worden hoger naarmate je naar warm, cold en frozen data tiers gaat. Cold en frozen data tiers vereisen searchable snapshots, die beschikbaar zijn met Enterprise-subscriptions. Voor de warm storage tier geldt een aanbevolen ratio van 160GB/GB RAM, maar dit kan nog hoger uitvallen. Ik heb configuraties gezien tot 250GB/GB RAM.
Voor de cold data tier gebruik je een vergelijkbare configuratie als voor warm, maar omdat je slechts 1 shard en geen replicas nodig hebt, kun je het dubbele aantal shards kwijt. De frozen data tier bestaat alleen uit caching nodes; alle data wordt on demand uit snapshots opgehaald. Deze nodes zijn doorgaans groot, met veel storagecapaciteit. Meestal zie je hier een beperkt aantal nodes met 64GB RAM en veel beschikbare storage voor het cachen van snapshotdata.
Sharding
Elasticsearch wordt geleverd met grotendeels verstandige defaults. Voor de meeste observability-oplossingen werken 1 primary shard en 1 replica prima. Houd de maximale shard size onder de 50GB en onder de 200 miljoen documenten per shard. Gebruik datastreams met een ILM policy om indices automatisch te laten rollen.
Datacenter-overwegingen
Als het kan, kies voor 3 datacenters, mits latency en beschikbare bandbreedte dit toelaten. Verkeer en latency tussen de datacenters zijn hierbij een belangrijke factor voor Elasticsearch. Als 3 datacenters niet mogelijk zijn, probeer er dan 2 te gebruiken, met een derde locatie (bijvoorbeeld een colocatie) voor een voting-only master node.
Heeft je organisatie slechts 1 datacenter, zorg dan voor zoveel mogelijk scheiding: 2 verschillende ruimtes, 2 verschillende rijen, 2 verschillende racks, 2 verschillende power feeds en 2 verschillende switches. Probeer twee stacks te creëren, zodat primary en replica shards niet op hetzelfde kritieke pad draaien.
Monitoring
Zet een aparte cluster op voor het monitoren van je Elasticsearch cluster(s). Als je primaire cluster uitvalt terwijl je monitoring op dezelfde instance draait, ben je vrijwel blind en wordt het vinden van de oorzaak van de storing een orde van grootte lastiger.
Follow-up: deel twee van deze blog serie
Nu heb je een goed beeld van de verschillende hostingopties en waar je rekening mee moet houden bij het schalen van je self-hosted Elastic platform. In deel twee van deze blogserie ga ik dieper in op het bouwen van een cluster, het opzetten van de infrastructuur en hoe je schaalt om performance te optimaliseren. Lees meer.
