Guida alle strategie di scaling del cluster Elasticsearch per la crescita

Lo scaling del cluster Elasticsearch diventa urgente quando le ricerche rallentano, le code di indicizzazione si accumulano o i dischi iniziano a riempirsi più velocemente del previsto. Con l'aumento dei volumi di dati e dei carichi di query, devi sapere se aggiungere risorse ai nodi esistenti, aggiungere più nodi, cambiare la strategia degli shard o riprogettare gli indici hot.

Questa guida copre lo scaling verticale e orizzontale, i ruoli dei nodi, il dimensionamento degli shard e i passaggi pratici per far crescere un cluster senza procedere per tentativi.

Comprendere i fondamenti dello scaling di Elasticsearch

Lo scaling di un cluster Elasticsearch coinvolge principalmente due strategie: Scaling Verticale (scaling up) e Scaling Orizzontale (scaling out). La strategia ottimale spesso implica un attento equilibrio di entrambe, dettato dalle caratteristiche del tuo carico di lavoro.

Scaling Verticale (Scaling Up)

Lo scaling verticale comporta l'aumento delle risorse dei nodi esistenti. Questo è l'approccio più semplice, ma raggiunge rapidamente i limiti fisici.

Quando usare lo Scaling Verticale:

• Quando la latenza è la preoccupazione principale e hai bisogno di risposte alle query più veloci dal set di dati esistente.
• Per pressioni a breve termine in cui aggiungere e ribilanciare nuovi nodi richiederebbe più tempo del sollievo di cui hai bisogno.

Aggiornamenti delle risorse primarie:

1. RAM (Memoria): Elasticsearch ha bisogno dell'heap JVM e di una grande cache del filesystem del sistema operativo. Un punto di partenza comune è impostare l'heap vicino al 50% della RAM di sistema, rimanendo al di sotto della soglia del puntatore a oggetti ordinari compressi, spesso intorno a 26-32 GB a seconda della JVM.
2. CPU: Necessaria per aggregazioni complesse, indicizzazione pesante e alta concorrenza di query.
3. Archiviazione (I/O del disco): SSD più veloci o unità NVMe migliorano significativamente la velocità effettiva di indicizzazione e la velocità di ricerca, specialmente per carichi di lavoro con I/O intensivo.

Avvertenza sullo Scaling Verticale: Heap JVM molto grandi possono perdere i vantaggi del puntatore a oggetti ordinari compresso e potrebbero subire pause di garbage collection più lunghe. La RAM extra è ancora utile per la cache del filesystem, ma spingere la dimensione dell'heap verso l'alto non è un piano di scaling a lungo termine.

Scaling Orizzontale (Scaling Out)

Lo scaling orizzontale comporta l'aggiunta di più nodi al cluster. Questo distribuisce i dati e il carico delle query su più macchine, offrendo una scalabilità quasi lineare e un'elevata disponibilità.

Quando usare lo Scaling Orizzontale:

• Quando il volume dei dati supera la capacità dei nodi esistenti.
• Quando è necessario migliorare la velocità effettiva complessiva di indicizzazione o la concorrenza delle query.
• Come strategia primaria per una crescita sostenibile a lungo termine.

Lo scaling orizzontale si ottiene aggiungendo nuovi nodi dati. È possibile aggiungere anche nodi di coordinamento, ma tipicamente, l'espansione dei nodi dati guida la crescita della capacità.

Migliori pratiche architetturali per la scalabilità

Lo scaling è più che aggiungere hardware; richiede una topologia di indici e nodi ben strutturata.

Ruoli dei nodi e specializzazione

Le distribuzioni moderne di Elasticsearch traggono grande beneficio dall'assegnazione di ruoli dedicati ai nodi, specialmente nei cluster più grandi. Questo previene la contesa di risorse tra attività pesanti (come l'indicizzazione) e attività critiche (come il coordinamento delle ricerche).

Ruolo del Nodo	Responsabilità Primaria	Considerazione sulla Migliore Pratica
Nodi Master	Gestione dello stato del cluster, stabilità.	Set dedicato di 3 o 5 nodi. Non dovrebbe gestire dati o richieste di ingest.
Nodi Dati	Memorizzazione dei dati, indicizzazione, ricerca.	Scala questi in modo aggressivo in base al volume di dati e al carico.
Nodi Ingest	Pre-elaborazione dei documenti prima dell'indicizzazione (usando pipeline di ingest).	Scarica la pre-elaborazione ad alta intensità di CPU dai nodi dati.
Nodi di Coordinamento	Gestione di grandi richieste di ricerca, raccolta dei risultati dai nodi dati.	Aggiungi questi quando le richieste di ricerca diventano complesse o sovraccaricano frequentemente i nodi dati con overhead di coordinamento.

Strategia di allocazione degli shard

Gli shard sono l'unità fondamentale di distribuzione e parallelismo in Elasticsearch. Una cattiva allocazione degli shard è la causa numero uno dei punti critici di scaling.

1. Ottimizzazione del conteggio degli shard primari

Scegliere il numero giusto di shard primari (index.number_of_shards) è fondamentale e non può essere modificato facilmente dopo la creazione dell'indice (a meno che non si utilizzino alias di indice o reindicizzazione).

• Troppi pochi shard: Limita il parallelismo durante le ricerche e impedisce uno scaling orizzontale efficace.
• Troppi shard: Aggiunge overhead allo stato del cluster, aumenta l'uso della memoria e crea il problema dello "shard piccolo" in cui i costi di coordinamento dominano il lavoro utile.

Migliore Pratica: Per molti carichi di lavoro di serie temporali e logging, punta a dimensioni degli shard nell'ordine delle decine di gigabyte, spesso approssimativamente da 10 GB a 50 GB. Tratta questo come un intervallo di partenza, poi testa con il tuo tasso di indicizzazione, finestra di conservazione e pattern di query.

2. Shard replica per alta disponibilità e throughput di lettura

Gli shard replica (index.number_of_replicas) forniscono ridondanza e aumentano la capacità di lettura.

• Impostare number_of_replicas: 1 significa che ogni shard primario ha una copia, garantendo l'alta disponibilità (HA).
• Aumentare le repliche può migliorare la capacità di lettura perché le ricerche possono essere servite da copie primarie o replica, ma aumenta anche l'uso dell'archiviazione e il lavoro di indicizzazione.

Esempio di configurazione HA: Se hai 10 shard primari e imposti number_of_replicas: 1, il cluster richiede almeno 20 copie di shard totali (10 primarie + 10 replica) distribuite tra i nodi.

PUT /my_growing_index
{
  "settings": {
    "index.number_of_shards": 20,
    "index.number_of_replicas": 1 
  }
}

Prevenire gli hotspot con la consapevolezza

Quando aggiungi nuovi nodi, assicurati che gli shard siano distribuiti tra i domini di guasto. Elasticsearch si ribilancia automaticamente, ma la consapevolezza di zona o rack funziona solo se configuri gli attributi del nodo e le impostazioni di consapevolezza dell'allocazione.

Usa l'API Cluster Allocation Explainer per diagnosticare perché gli shard potrebbero non spostarsi verso nuovi nodi o perché un nodo è sovraccarico.

Passaggi pratici di scaling: Gestire la crescita

Quando le prestazioni del tuo cluster si degradano (alta pressione dell'heap JVM, query lente, indicizzazione lenta), segui questi passaggi in ordine:

Passaggio 1: Monitora e diagnostica

Prima di apportare modifiche, diagnostica il collo di bottiglia. Indicatori comuni:

• CPU Alta/Memoria Libera Bassa: Indica carenza di calcolo o memoria (potenziale necessità di scaling verticale).
• Lunghezza eccessiva della coda del disco: Indica un collo di bottiglia I/O (necessità di dischi più veloci o aggiunta di nodi).
• Picchi di latenza di ricerca: Spesso dovuti a caching insufficiente o troppo pochi shard/repliche (necessità di più memoria o scaling orizzontale).

Passaggio 2: Affronta le esigenze immediate di risorse (modifiche verticali)

Se la pressione della memoria è alta, aumenta la dimensione dell'heap JVM entro limiti di sicurezza (massimo 32 GB) e assicurati che sia disponibile RAM adeguata per la cache del filesystem del sistema operativo.

Passaggio 3: Scala orizzontalmente (espansione orizzontale)

Se aggiungi nodi, segui questa procedura:

1. Provisiona nuovi nodi dati con hardware identico o superiore.
2. Configurali con i ruoli corretti. Per la crescita della capacità, questo di solito significa ruoli dati come data_hot, data_content o data a seconda della tua distribuzione.
3. Puntali al cluster esistente usando discovery.seed_hosts.
4. Una volta che i nuovi nodi si uniscono, Elasticsearch inizierà automaticamente a ribilanciare gli shard esistenti per utilizzare la nuova capacità.

Passaggio 4: Rendere gli indici a prova di futuro (reindicizzazione)

Se gli indici esistenti hanno conteggi di shard non ottimali, non possono utilizzare completamente i nuovi nodi. Devi ricostruirli:

1. Crea un nuovo template di indice o usa l'API Create Index con il numero desiderato di shard e repliche.
2. Usa l'API Reindex per migrare i dati dal vecchio indice con dimensioni errate a quello nuovo.
3. Una volta completata la migrazione, scambia il traffico usando un alias.

Comando di reindicizzazione di esempio:

POST _reindex
{
  "source": {
    "index": "old_index_bad_shards"
  },
  "dest": {
    "index": "new_index_optimized_shards"
  }
}

Checklist delle migliori pratiche

Lo scaling di Elasticsearch funziona meglio quando monitori prima, cambi una variabile alla volta e mantieni il layout degli shard allineato con il tuo modello di crescita.

Punti chiave:

• Dai priorità allo Scaling Orizzontale: Offre il percorso migliore per una crescita continua e resilienza.
• Nodi Master Dedicati: Mantieni stabile la gestione del cluster separando i ruoli master.
• Il dimensionamento degli shard è permanente: Punta a una dimensione dello shard primario di 10 GB-50 GB al momento della creazione dell'indice.
• Monitora l'heap JVM: Mantieni l'heap al di sotto della soglia del puntatore compresso per la tua JVM e lascia abbastanza RAM per la cache del sistema operativo.
• Usa la reindicizzazione: Ricostruisci gli indici cruciali quando lo scaling orizzontale richiede una modifica nel conteggio degli shard primari.