Salta ai contenuti

Nucleus — Control Plane

Nucleus è il Control Plane: dove vive la logica di prodotto. Riceve le richieste da Meridian, le esegue, coordina gli altri servizi e mantiene lo stato.

Se Lumina è quello che vedete e Meridian è la porta, Nucleus è quello che effettivamente fa le cose.

Correlazione. Costruisce e mantiene il grafo unificato che alimenta Core 360°: prende gli oggetti che Beacon raccoglie da piattaforme diverse e ne ricostruisce le relazioni — quale VM è quale VDA, su quale host, su quale datastore, dentro quale policy di backup.

Allarmi. Valuta regole, soglie e condizioni sui dati correlati, aggrega gli eventi in incidenti e applica le finestre di manutenzione.

Sessioni e utenti. Unifica le sessioni delle piattaforme EUC in un modello comune e ricostruisce l’identità degli utenti fra sistemi diversi.

Automazioni. Libreria di script, pianificazioni, esecuzioni e loro storico. Delegando l’esecuzione a Vanguard dove serve un agent.

Provisioning. Le operazioni di creazione e gestione dei cataloghi Citrix e Horizon.

PAM. Account privilegiati, policy, approvazioni, rotazione delle credenziali e registrazione delle sessioni — con i segreti custoditi da Arcanum.

Service Desk. Ticket, change, problem, knowledge base e CMDB, agganciati agli oggetti reali dell’infrastruttura.

Multi-tenancy. Isolamento dei dati fra tenant, con un database globale e uno per tenant.

Console web. Il proxy che permette di aprire dentro il portale le console web degli appliance (Prism, vCenter, NetScaler…), validando il token monouso e inoltrando a Vanguard.

PostgreSQLConfigurazione, inventario, storico. Un database globale, uno per tenant
RedisCache, sessioni, code di eventi, coordinamento fra repliche
ArcanumSegreti e credenziali; le credenziali PAM sono cifrate con il motore transit

Nucleus è senza stato: lo stato è nel database e nella cache. Scala orizzontalmente e su CorellixOS ha un autoscaler attivo che porta le repliche da 1 a 3 in base al carico di CPU.

Nucleus non può servire richieste senza PostgreSQL. Dopo il riavvio dell’intero cluster, il database può impiegare qualche minuto a tornare disponibile: nel frattempo Nucleus attende invece di fallire, e il cluster lo lascia fare sospendendo i controlli di salute fino a cinque minuti.

Se un pod di Nucleus resta in avvio più a lungo, la causa è quasi sempre a valle: verificate PostgreSQL prima di Nucleus. Vedi Diagnostica.