CMDBuild Newsletter nr. 97

Entro la fine di maggio completeremo le attività di sviluppo della nuova versione CMDBuild 3.4.2.
Rispetto alla lista delle novità pubblicata nella precedente newsletter, segnaliamo tre ulteriori aree di intervento:

• possibilità di disattivare alcuni attributi dal caricamento in griglia tramite una impostazione dedicata sull’attributo e di disattivare la ricerca globale su alcuni oggetti (in entrambi i casi per migliorare le performance del sistema);
• migliorie alla dashboard iniziale nel Modulo di Amministrazione;
• revisione e completamento di ottimizzazioni per il supporto di architetture cluster (vedi approfondimento alla notizia successiva).

Il mese di giugno sarà dedicato alle attività di test, bug fix e preparazione del rilascio, fra cui:

• esecuzione finale della batteria completa dei test automatici di modulo e API lato server (JUnit), di interfaccia utente (Selenium) e di carico (JMeter) e verifiche dei risultati;
• rilascio della prima “release candidate”;
• test manuali aggiuntivi sulla piattaforma CMDBuild e sulle verticalizzazioni CMDBuild READY2USE e openMAINT aggiornate alla nuova versione della piattaforma;
• invio dei file aggiornati delle localizzazioni ai contributori e integrazione delle nuove traduzioni;
• riciclo con nuove release candidate fino a risoluzione degli eventuali problemi riscontrati;
• rilascio pubblico su SourceForge della nuova versione e della documentazione (changelog);
• aggiornamento dei siti dei prodotti e delle demo online;
• preparazione delle nuove appliance riservate ai clienti.

Il rilascio pubblico rimane pianificato per l’inizio del mese di luglio.

Già da tempo abbiamo proposto ed attivato installazioni di CMDBuild basate su un cluster di più nodi di tipo application server (Tomcat) controllati da un load balancer.

L’obiettivo è duplice: da un lato garantire il funzionamento complessivo del sistema anche in caso di guasto ad una delle istanze Tomcat (continuità operativa), dall’altro distribuire il carico di lavoro su più server (scalabilità) nel caso di numeri molto elevati di accessi concorrenti.

L’architettura può essere poi estesa ulteriormente distribuendo alcuni servizi su server dedicati (sistema documentale, portale self service, servizi GIS / BIM), fino a prevedere una replicazione del database PostgreSQL in modalità master slave (Primary-Secondary Replication).

Indipendentemente dal cluster sono poi sempre consigliate almeno due istanze, una di sviluppo / test / collaudo ed una di produzione.

Avendo seguito più recentemente installazioni con numeri di utenti molto elevati (anche oltre 1000 operatori IT di cui 500 operanti contemporaneamente con apertura e avanzamento di processi) abbiamo colto l’occasione per irrobustire ed ottimizzare i meccanismi di comunicazione fra load balancer ed application server.

Le ottimizzazioni necessarie erano state in parte già incluse in alcune patch preparate nell’ultimo anno dopo il rilascio CMDBuild 3.4.1, e sono ora disponibili per tutti nella nuova versione 3.4.2.

Per accrescerne la diffusione riprendiamo alcuni case history del CMDBuild DAY 2022 tenutosi il 30 novembre scorso.
Di seguito una sintesi del case history di Diringer & Scheidel GmbH & Co, di cui trovate qui l’intervento completo.

Diringer & Scheidel GmbH & Co è un grande gruppo tedesco; l'azienda è stata fondata nel 1921 come una classica impresa di costruzioni ma negli anni è cresciuta molto e ora è un gruppo aziendale diversificato con circa 3.800 dipendenti. Il Gruppo D&S è attivo in vari servizi: produzione, ingegneria civile, costruzione di strade, ferrovie e condotte, property management, facility management, retail management, settore alberghiero, pianificazione e project management, produzione di materiali da costruzione, ecc.

David Heiss spiega che questo ecosistema porta ad una infrastruttura molto complessa, con diversi tipi di scenari, casi aziendali, ecc. Quando è entrato a far parte dell'azienda nel 2021 non esisteva una soluzione CMDB, non c'era una corretta gestione della documentazione, non una “integrità dell'infrastruttura” (gestione del backup e monitoraggio di un nuovo sistema, ad esempio), mancanza di informazioni sugli assegnatari dei dispositivi e delle posizioni, difficoltà nella gestione delle licenze, dei dipendenti, ecc. C'era quindi un forte bisogno di una soluzione CMDB, con una flessibilità molto elevata, per poter costruire un proprio modello dati, ma anche con una buona “user experience”, senza quindi la necessità di un design avanzato dell'interfaccia utente, con funzionalità come filtri, regole di validazione, descrizione delle relazioni, accesso ad API, possibilità di interfacciamento con Microsoft Power BI (già utilizzato internamente come soluzione di business intelligence).

Si è quindi deciso di iniziare ad utilizzare CMDBuild. Esistono diverse fonti di dati (VMware Hypervisor, HPE IMC Switch Manager, Sophos Central Firewall Manager, Windows Server Active Directory, Unifi Wi-Fi Access Point, P&I Loga 3 HR Manager) che fanno discovery e alimentano CMDBuild, quindi CMDBuild si sincronizza con altre soluzioni come MS SCCM, Veeam Backup Solution, Zabbix Monitoring, Internal Ticket-system, ManageEngine Mobile Devices, MS Power BI Platform. Questo conduce a due aspetti molto importanti: c'è un'unica fonte di verità (“quello che c'è in CMDBuild è verità”) e le informazioni sono sempre aggiornate. Il data model di CMDBuild è stato costruito da David, che ha anche implementato le sincronizzazioni, utilizzando PowerShell e API rest, con un altissimo livello di soddisfazione (“è stato davvero fantastico... le API di CMDBuild funzionano proprio come pensi che dovrebbe funzionare le API rest... gli sviluppatori di CMDBuild sanno davvero come utilizzare un database nel modo corretto, ci sono molti vincoli e trigger e tutto quel genere di cose che rendono l'utilizzo del database davvero efficace... questo è uno dei migliori concetti di database CMDB che ho mai visto, semplice e potente…”).

Vengono poi anche presentati alcuni casi d'uso pratici:

• Assegnazione utenti per dispositivi mobili: i dispositivi mobili vengono rilevati automaticamente utilizzando Samsung Knox, CMDBuild ogni giorno interroga le API di Knox per ottenere automaticamente tutte le informazioni, quindi i dati dei dispositivi sono già presenti in CMDBuild ancora prima che i dispositivi arrivino fisicamente in sede; la nuova assegnazione dell'utente viene quindi eseguita in CMDBuild e al successivo intervallo di sincronizzazione viene creata la relazione con l'utente, quindi un amministratore non deve gestire la configurazione dei dispositivi mobili, assegna semplicemente il dipendente in CMDBuild e tutto viene sincronizzato automaticamente in background.
• Gestione degli indirizzi IP: quando viene creata una nuova rete, utilizzando una regola di validazione scritta in codice JavaScript, vengono convalidate le informazioni sull'ID di rete e sulla subnet mask, nonché l'indirizzo IP quando ne viene creata una nuova. Ciò garantisce che in una rete possano essere creati solo indirizzi IP validi e univoci. Lo script viene eseguito internamente utilizzando il confronto binario, quindi è senza classi e potrebbe essere utilizzato anche per IPv6.
• Assegnazione dello stato dell'asset e relative conseguenze: lo stato dell'asset non è un singolo elenco di ricerca (lookup), è un oggetto completo perché uno stato dell'asset ha attributi diversi che potrebbero essere diversi per ogni stato. Ad esempio, consideriamo i seguenti stati: Testing, Active, Removed. Per poter ottenere rapidamente tutti i sistemi che devono essere monitorati, nella classe di stato dell'asset è stato introdotto un campo “MonitoringRequired”; Testing e Removed lo hanno impostato su falso, mentre Active lo ha impostato su vero. Altri campi come fatturazione, “patching required” ecc. vengono utilizzati allo stesso modo. Con questo metodo è possibile impostare molto facilmente opzioni e comportamenti basati su uno stato.
• Sincronizzazione delle configurazioni di monitoraggio (anche con Grafo delle Relazioni): sono stati creati dei profili di monitoraggio per definire come deve essere monitorato un sistema (Windows, Linux, applicativo ecc.); sulla base di questi dati e con le informazioni aggiuntive sullo stato dell'asset, uno script PowerShell autoprodotto configura la soluzione di monitoraggio Zabbix. Nel modello dati è stata aggiunta anche la possibilità di creare relazioni di rete tra sistemi (più figli/padri); queste informazioni vengono anche sincronizzate con Zabbix per verificare le dipendenze di rete, ad esempio per evitare la creazione di centinaia di ticket quando un firewall e tutti i server dietro quel firewall sono giù.
• Definizione di business service: creazione della definizione di business service che dà la possibilità di collegare molti oggetti diversi nel CMDB (database, siti web, servizi, server, utenti ecc.) e raggrupparli in un servizio aziendale. Questo business service potrebbe quindi essere utilizzato anche in un altro servizio aziendale per creare una gerarchia. Ad esempio, Exchange dipende da server Exchange, sito Web OWA, Exchange EDB, servizi Exchange e Active Directory business service. Tutte queste informazioni sui business service sono anche sincronizzate con la soluzione di monitoraggio Zabbix, quindi è possibile, ad esempio, avere un monitoraggio completo dei servizi aziendali e avvisi con ticket ad alta priorità quando un servizio aziendale non funziona più.

Abbiamo fissato per giovedì 13 luglio, alle ore 16,00 il webinar di presentazione della nuova versione CMDBuild 3.4.2.
Rimangono a disposizione delle persone interessate le registrazioni dei webinar già svolti, qui trovate i link per accedere.