I cluster Eldric sopravvivono ai guasti dei nodi, alle partizioni di rete e alla perdita di interi datacenter — in modo automatico. Dal portatile di un singolo sviluppatore a una federazione di 50+ nodi che spazia su più continenti: stesso software, stessa grammatica di configurazione, stesso pacchetto di installazione.
Lo stesso RPM eldric-aios gira su un Raspberry Pi sotto il monitor di uno sviluppatore e su un cluster bare-metal di 50 nodi dietro la rete di un ospedale. Il ruolo che ogni nodo gioca è configurazione, non codice. Inizi con uno. Cresci a tre il giorno in cui l'uptime inizia a contare. Federi tra siti il giorno in cui apri un secondo ufficio.
config.yaml diverso — il percorso di upgrade da "prova su singolo portatile" a "enterprise multi-regione" è una questione di nodi che aggiungi, non di software a cui devi migrare.
Consenso Raft multi-controller di livello produzione. Ogni nodo in un cluster Eldric mantiene un heartbeat verso i suoi peer. Quando un leader scompare — il sistema muore, la rete cade, un amministratore stacca il cavo sbagliato — i nodi rimanenti se ne accorgono in pochi secondi ed eleggono un nuovo leader. Il cluster si forma, replica, fa failover e si ripristina dopo un crash sotto test live. Il traffico di inferenza viene reinstradato automaticamente. Le sessioni di chat aperte continuano dalla richiesta successiva.
Un cluster che ha bisogno di un umano nel loop per ripristinarsi non è un cluster — è un single point of failure con qualche hop in più.
Un'impresa raramente vive in un solo edificio. La federazione permette a ciascun sito di eseguire un proprio cluster Eldric autonomo — mantenendo locale il traffico ad alto consumo di banda — mentre uno strato di federazione tiene sincronizzati directory, basi di conoscenza e policy di accesso. Una filiale resta utile anche quando il link WAN cade. La sede centrale tiene una replica calda di ogni filiale per il disaster recovery regionale.
Un cluster federato non si trasforma in thin client. La filiale mantiene i suoi modelli locali, il suo corpus RAG locale e i suoi utenti locali — e riconcilia lo stato con il resto della federazione quando il link torna.
Le policy per tenant ti permettono di marcare le basi di conoscenza come solo-UE, solo-USA o singolo-sito. Lo strato di federazione si rifiuta di replicare qualsiasi cosa taggata fuori dalle sue regioni consentite — una regola applicata dal cluster, non dall'operatore.
La replica DR calda riceve un flusso continuo di aggiornamenti di federazione. Se il datacenter primario è offline — incendio, alluvione, taglio di fibra — la replica è già aggiornata a meno di pochi minuti. Il cutover è una decisione dell'operatore, non un progetto di ripristino.
La parte più difficile di gestire un sistema distribuito di solito non è il consenso — è tenere traccia di quale macchina sta a quale indirizzo. Eldric impila quattro livelli di discovery in modo che l'operatore non mantenga una lista. Su una LAN d'ufficio tranquilla, i nodi si trovano in pochi secondi. Su una WAN ramificata, una piccola manciata di "admin hint" innesca la catena.
Una mappa a colpo d'occhio dal numero di nodi a ciò che ti restituisce. Ogni riga è lo stesso pacchetto Eldric — le differenze stanno in quanti nodi gli dai e quale ruolo assegni a ciascuno.
| Nodi | Topologia | Failover | Caso d'uso tipico |
|---|---|---|---|
| 1 | host singolo | nessuno (solo riavvio) | Portatile dello sviluppatore, prova in un singolo team, proof-of-concept su Raspberry Pi. Stesso pacchetto — solo uno. |
| 2–3 | cluster a quorum | automatico | Piccolo ufficio, deployment sempre attivo. Tre nodi è il punto dolce — sopravvive alla perdita di un singolo nodo qualsiasi con un voto di maggioranza pulito. |
| 4–10 | leader + worker | automatico | Reparto o azienda di medie dimensioni. Una manciata di nodi eleggibili a leader; il resto sono worker dedicati che eseguono modelli, indici RAG o agent specialisti. |
| 10–50 | mesh multi-ruolo | automatico + zonale | Enterprise su un singolo sito. Worker distribuiti su più rack o zone di disponibilità così la perdita a livello di rack è sopravvivibile. Il leader sta in una zona diversa. |
| 50+ | mesh federato | automatico + cross-sito | Multi-sito, multi-regione. Cluster per sito federati sopra il WAN; repliche DR calde in un'altra regione; regole di data-residency per tenant applicate allo strato di federazione. |
Un'installazione a nodo singolo è genuinamente production-grade per molti team. Il clustering si ripaga in cinque situazioni specifiche.
Un ledger a tre colonne di dove ciascun pezzo della storia di resilienza è davvero. Tutto ciò che non è nella colonna più a sinistra non è ancora in esecuzione in produzione — non fingeremo il contrario.
5.0 — in spedizione
Prossime patch 5.0.x — progettati & dispatchati
Più avanti in 5.0.x — sulla roadmap
Le scadenze della roadmap cambiano. Tutto ciò che è nelle due colonne a destra è genuinamente pianificato e a budget — ma non promettiamo un trimestre di calendario per software che non abbiamo finito. La cosa che promettiamo è che questa tabella ti dirà la verità.
Un cluster a tre nodi gira comodamente su tre box Linux commodity. Un deployment federato multi-sito gira su qualunque cosa l'IT abbia già in casa. Il download è lo stesso; cambia la configurazione.