Zo schaal je jouw on-prem Elastic Observability-cluster – deel 2
Dus in mijn eerste post bespraken we de verschillende beschikbare Elasticsearch-hostingopties en de aandachtspunten bij het bouwen en configureren van je self-hosted Elastic-platform. In deze vervolgartikel duiken we dieper in het opzetten van een cluster, het uitbreiden van de infrastructuur en hoe je kunt schalen om te optimaliseren voor duurzaamheid en stabiliteit.
Tip: lees mijn eerste blog over het schalen van een on-prem Elastic Observability Cluster hier.
Begin klein
Het kleinste cluster dat je kunt opzetten met redundantie en quorum bestaat uit 3 Elasticsearch-nodes, waarbij elke node alle rollen toegewezen krijgt. Dit werkt over het algemeen goed bij een ingest van minder dan 1000 documenten per seconde. Dit hangt voornamelijk af van de beschikbare CPU-capaciteit, maar 3× 4 CPU met 16 GB heap zou dit aankunnen, mits je geen Windows-logs ingesteert, aangezien die aanzienlijk meer verwerking vereisen.
Uitbreiden van je infrastructuur
ECE en Elastic Cloud voegen automatisch 3 dedicated master-eligible nodes toe aan elk cluster met 6 of meer Elasticsearch-nodes. Persoonlijk zou ik de masters al toevoegen zodra 3 all-in-one nodes performanceproblemen beginnen te vertonen.
De volgende laag zijn ingest nodes. Voeg ingest nodes alleen toe als je gebruikmaakt van Elasticsearch ingest pipelines. Als alle binnenkomende data al het juiste formaat heeft bij binnenkomst, leveren deze nodes geen voordeel op. Naarmate je storagebehoefte groeit, zul je extra storage tiers moeten toevoegen, omdat het uitsluitend opslaan van hot data al snel onbetaalbaar wordt.
Wanneer de ingest-rate verder toeneemt, is het verstandig om na te denken over het ontkoppelen van agents van Elasticsearch en een Kafka-bufferlaag tussen agents en Elastic te plaatsen. Op het moment van schrijven (december 2024) is de Elastic Agent-output met Fleet beperkt tot Elasticsearch, Logstash en Kafka.
Wanneer je wat schaalt en in welke richting
Nu heb je een Cluster, maar de performance is in het algemeen niet wat je verwacht. Je denkt dat je moet opschalen of uitschalen, maar je weet niet zeker welke scaling-optie geschikt is. Dit is waar cluster Monitoring om de hoek komt kijken. Je moet eerst de signalen kunnen zien, om te kunnen bepalen wat je moet doen.
Cluster state issues
Cluster state is een datastructuur die een heleboel interne informatie bijhoudt, die nodig is voor elke Elasticsearch node. De gekozen master herberekent de cluster state bij elke state change en stuurt een update naar elke actieve node. Zodra genoeg master-eligible nodes de update hebben bevestigd, commit de gekozen master de wijziging en broadcast hij een bericht dat de nieuwe state moet worden toegepast. Lukt het niet om de nieuwe state volledig te publishen binnen de timeout die is ingesteld via cluster.publish.timeout, dan treedt de master terug en wordt er een herverkiezing geforceerd.
Als algemene regel geldt: meer masters toevoegen is niet de oplossing als je al dedicated master nodes gebruikt.
- Cluster state update warnings en frequente master re-elections. Als je frequente cluster state update warnings of frequente master re-elections tegenkomt, kan dat een paar dingen betekenen.
- Cluster state size, veroorzaakt door een field explosion. In dit geval groeit de cluster state omdat er te veel field definitions zijn. Hoewel dit niet de focus is van dit document, moet je kijken welke fields zijn gedefinieerd, welke dynamic zijn en welke static. Kijk ook naar het aantal shards in je Cluster. Minder shards betekent ook een kleinere cluster state. Meer memory kan helpen, maar je wil geen enorme cluster state, omdat het syncen van cluster state langer duurt naarmate je state groter wordt.
- Masters zijn te klein. Als master-eligible nodes met te weinig memory zijn geconfigureerd (of net te weinig), dan moet de JVM mogelijk Garbage collection doen. Check de GC rate en de gemiddelde tijd die een GC-run kost. De GC rate moet idealiter minder zijn dan 1/30s voor master nodes.
Oplossing: verhoog heap of RAM, of split je masters af als je meerdere rollen op de masters draait. - Masters zijn te druk. Als het gemiddelde CPU-gebruik te hoog wordt, moet je CPUs toevoegen, of splitten als je meerdere rollen draait. ECE is een special case. ECE berekent standaard de CPU quota op basis van de hoeveelheid memory die aan een container is toegewezen, om het noisy neighbour-syndroom te beperken. Voor ECE kun je de memory verhogen die aan de container is toegewezen.
Ingest
Ingest nodes zijn vooral compute-intensief, maar met 4 CPUs en 8GB RAM moet één ingest node 3000/5000 events/sec aankunnen, afhankelijk van de complexiteit van de Pipeline.
Als je Fleet of integrations gebruikt, profiteer je sterk van aparte ingest nodes, omdat alle integrations ingest pipelines gebruiken om de juiste ECS fields te vullen/hernoemen. Zo splits je de processing van documenten van indexing actions.
Bepalen wanneer je ingest nodes moet uitschalen doe je op basis van CPU-gebruik van de ingest node, gekoppeld aan de index rate en het CPU-gebruik van de hot data nodes. Zolang de hot data nodes hun limieten nog niet benaderen, kun je ingest nodes uitschalen.
Ingest buffering
Er komt een moment dat je hot data nodes je ingress data simpelweg niet meer aankunnen tijdens piekmomenten. Dan is het tijd om een buffering layer te implementeren, tenzij je je oplossing al met een buffering layer hebt ontworpen. De buffering layer zorgt ervoor dat log events zo snel mogelijk van je log producers afgaan, en kan ingest pieken richting Elasticsearch afvlakken. Zo’n buffer layer zorgt voor extra latency, en je zult met de gebruikers van je Cluster moeten afspreken wat acceptabele latency is.
Hot data nodes
De hot data nodes zijn de werkpaarden van een Elasticsearch observability Cluster. Data wordt op deze nodes geïndexeerd en de meeste queries in een observability Cluster hoeven alleen recente data te benaderen. Als je geen dedicated ingest nodes hebt, handelen ze ook een deel van de ingest pipeline processing af. Alle processing die nodig is bij ILM rollover vindt ook plaats op deze nodes.
Je scaling-beslissingen moeten gebaseerd zijn op heap usage, beschikbare storage en CPU-gebruik.
- Als je heap usage nog laag is, maar je CPU maxed out: voeg meer CPU toe. Als je geen CPU kunt toevoegen, schaal dan uit.
- Als je heap usage hoog is en je ziet frequente GC-runs: voeg heap/memory toe, maar houd rekening met de 32GB heap space. Als je geen heap kunt toevoegen aan je draaiende instances, schaal dan uit.
- Als je je storage limits nadert (maar hopelijk vóór je de high watermark raakt): je kunt de low en high watermark targets aanpassen, maar voeg storage toe (met de storage-to-memory ratio’s in gedachten), of schaal uit. Een andere optie is je ILM policies aanpassen en je data korter hot houden, of een warm datatier toevoegen.
Nog even over Data Tiers
Elasticsearch gebruikt het concept van Data Tiers, waarbij hot nodes actief bijgewerkte data bevatten. De warm nodes bevatten data die actief wordt doorzocht, maar niet meer wordt geüpdatet. De Frozen Tier wordt gebruikt voor indices die bewaard moeten blijven, maar die slechts zelden hoeven te worden geraadpleegd.
De frozen tier is afhankelijk van snapshots en gebruikt gedeeltelijk gemounte indices, waarbij alleen bepaalde metadata in het geheugen wordt gehouden. Pas wanneer een search request de data nodig heeft, wordt de volledige snapshot tijdelijk teruggelezen zodat deze doorzocht kan worden. Omdat dit afhankelijk is van snapshots, mag je verwachten dat een zoekopdracht hier minuten duurt in plaats van seconden. Het voordeel is dat je grote hoeveelheden frozen data kunt aanhouden, zonder dat je dedicated servers nodig hebt om deze data beschikbaar te houden.
Conclusie
Inmiddels zou je een behoorlijk goed beeld moeten hebben van mijn visie op hoe je jouw on-prem Elastic Observability Cluster schaalt. Met het toenemende aantal cyberaanvallen wordt Observability steeds belangrijker. Bij SUE helpen we onze klanten om meer zichtbaarheid te creëren door meerdere oplossingen te implementeren, zoals Elastic.
Heb je hulp nodig of wil je gewoon een vrijblijvend gesprek over Observability voor jouw organisatie? Neem contact op!
