Un cluster OpenSearch a tre nodi può mantenere una maggioranza disponibile dopo la perdita di un nodo eleggibile a cluster manager. Per continuare a servire le query servono però anche copie dei dati disponibili, capacità sufficiente e una distribuzione che consideri i guasti dell’infrastruttura.
Nel repository Romiltec ho un progetto Ansible per tre nodi OpenSearch e un container Dashboards su Proxmox. La configurazione esaminata usa OpenSearch 3.5.0, versione pubblicata nel febbraio 2026. È il riferimento concreto di questo articolo; non una misura del traffico editoriale servito dal cluster.
Tre container non equivalgono a tre domini di guasto
Il template assegna ai nodi i ruoli cluster_manager, data e ingest. Per un cluster contenuto può essere una soluzione da valutare, osservando la contesa tra coordinamento, indicizzazione e ricerca.
Se tutti i container dipendono dallo stesso host, il guasto di quell’host coinvolge l’intero cluster. La disponibilità richiede di ragionare anche su alimentazione, rete e storage condivisi. Il numero di processi OpenSearch da solo non descrive la ridondanza.
La configurazione iniziale del cluster va inoltre distinta dalla discovery ordinaria: i parametri di bootstrap servono alla prima formazione. Un playbook di manutenzione deve riconoscere lo stato del cluster esistente ed evitare di trattare ogni esecuzione come una nuova installazione.
Memoria e limiti del kernel vanno verificati nel guest
LXC condivide il kernel dell’host. Parametri come vm.max_map_count richiedono quindi attenzione al valore disponibile sull’host e visibile al container. La documentazione di installazione OpenSearch indica i requisiti di sistema da controllare.
Nel progetto la heap è configurata a 2 GB. È un valore del deployment, non una formula valida per qualsiasi corpus. Lascierei memoria anche a strutture esterne alla heap, cache del filesystem e processi del container, osservando limiti effettivi e pressione sulla memoria.
LimitMEMLOCK=infinity concede un limite al servizio, ma non dimostra da solo che tutta la memoria necessaria sia bloccata o che lo swap sia impossibile. Controllerei configurazione del processo, bootstrap check e comportamento sotto carico.
Ansible rende le scelte visibili, non automaticamente corrette
L’inventory alimenta indirizzi e liste dei nodi; ruoli separati gestiscono certificati, applicazione e Dashboards. Questa struttura aiuta a rivedere le differenze e ricostruire un ambiente di prova.
Nel runbook l’uso del tarball nasce da un problema di verifica della chiave del repository APT nel sistema utilizzato. È una motivazione specifica. Anche con pacchetti di distribuzione si possono controllare le versioni: il tarball non è l’unico modo per evitare aggiornamenti inattesi.
Prima di definire il deploy idempotente proverei una seconda esecuzione e una modifica controllata. Rimuovere un nodo dall’inventory non basta a evacuare i dati o spegnere correttamente il nodo esistente; queste operazioni richiedono un flusso esplicito.
Repliche, shard e query devono essere dimensionati insieme
Sceglierei shard primari e repliche osservando volume, crescita, query e capacità di recupero. Più shard possono aumentare il parallelismo ma anche il coordinamento e l’overhead. Non assegnerei tre shard primari soltanto perché ci sono tre nodi.
Verificherei dove sono allocate le copie. Una replica aggiuntiva può migliorare la tolleranza ai guasti se è collocata in un dominio indipendente, al costo di spazio e lavoro supplementare.
Nei test includerei ricerca durante indicizzazione e recupero di un nodo. Il tempo della query a cluster fermo descrive solo una parte dell’uso reale. Per il multi-tenant, filtri e autorizzazioni devono impedire risultati di altri clienti anche nelle aggregazioni.
Aggiornare richiede una strada di recupero
La guida agli aggiornamenti distingue percorsi supportati e metodi di migrazione. Cambiare un symlink verso un vecchio eseguibile non garantisce un downgrade compatibile con dati già modificati dalla nuova versione.
Prima dell’upgrade preparerei snapshot e prova di recupero su una destinazione compatibile. Le copie si gestiscono con le API snapshot di OpenSearch: cancellare direttamente oggetti del repository con una lifecycle generica può rompere riferimenti condivisi.
Controllerei infine certificati, autorizzazioni e validazione TLS lungo tutto il percorso, incluso proxy verso backend. Un pannello raggiungibile non dimostra questi requisiti. La prova di manutenzione termina quando applicazione e query di riferimento funzionano con lo stato dei dati atteso.