Strumentazioni di rete: mind the gap!

La rete è un sistema pensato per fornire applicazioni agli utenti in modo affidabile e tempestivo. Per mantenere la vostra rete attiva e funzionante, gestibile e supportabile, adattabile e sicura, occorre un set di strumenti per gestire la miriade di componenti e piattaforme dei diversi fornitori.

Come accertarvi che tali strumenti non siano in contrasto sui dispositivi di cui sono responsabili? Come assicurarvi che siano aggiornati e le informazioni in essi contenute accurate? Avete altre domande sulla rete ma i vostri strumenti non riescono ad aiutarvi?

IP Fabric è in grado di migliorare i vostri strumenti per le operazioni sulla rete. In questo primo articolo, daremo un’occhiata a questo ecosistema e vedremo quali lacune IP Fabric può colmare!

L’ecosistema della strumentazione

Per essere certi che la vostra rete sia mantenuta e supportata adeguatamente, necessitate di piattaforme in diversi ambiti:

• Configurazione
• Monitoraggio performance
• Event Management
• Gestione del servizio IT
• CMDB

Ognuna di queste aree può essere suddivisa in altrettanti toolset, utilizzabili da diversi operatori per la manutenzione del servizio di rete.

Configurazione

Anche attualmente, pur con l’automazione della rete ormai d’obbligo, la maggioranza dei cambi di configurazione è fatta manualmente attraverso interfacce a riga di comando (CLI). È normale però utilizzare strumenti di Configuration Management, per avere il backup della configurazione in caso di modifiche. Ciò permette la sostituzione di un dispositivo in caso di guasto e la possibilità di tracciare nel tempo l’attività di modifica.

Con il tempo, però, la configurazione dei dispositivi di rete è sempre più automatizzata, in genere attraverso l’uso di:

• Scripting – tramite shell scripts (programmi scritti in linguaggi come Python) o piattaforme come Ansible, per attuare cambiamenti nelle bulk configuration e testarli;
• Software-Defined Networking – in cui un controller si occupa della configurazione di singoli dispositivi ed è possibile amministrare, a livello centrale, la configurazione template e le variabili attraverso API o GUI;
• Policy Engines – in cui i singoli dispositivi sono configurati per recuperare informazioni sulle policy da un motore centrale, onde fare il render della configurazione attiva.
• Orchestration platforms – che permettono di combinare elementi di automazione in flussi di lavoro, per ottenere task più complessi su vari domini di configurazione.

Per ottenere una visione completa della rete possono rendersi necessari più strumenti, per via dei diversi domini e fornitori presenti. Idealmente, occorre una qualche forma di sincronizzazione per garantire una visibilità completa e una copertura end-to-end.

Monitoraggio Performance

Quando una rete è stata implementata, è necessario assicurarsi che sia monitorata, le prestazioni dei componenti tracciate e riportate, in modo che non siano raggiunti i limiti di capacità e le soglie di prestazione violate. Qui entrano in campo tre agenti primari:

• Dispositivo – in genere si rintraccia utilizzando lo SNMP. L’obiettivo è verificare lo stato di salute dei dispositivi, utilizzando misurazioni come CPU, utilizzo della memoria, temperature interna e raggiungibilità del management plane del dispositivo.
• Link – la piattaforma di monitoraggio campiona lo stato dell’interfaccia nel tempo, generando una misurazione dell’utilizzo. I dati, riportati in grafici e trend con previsioni sul lungo periodo, andranno in aiuto al capacity planning.
• Applicazione – abbiamo a disposizione due metodi. Inviare nella rete sonde sintetiche per simulare il comportamento dell’applicazione (come una richiesta http ad un URL specifico) e fare le dovute misurazioni. Oppure analizzare i flussi reali di traffico (utilizzando Netflow, S-Flow o simili) per ottenere una panoramica realistica della resa dell’applicazione.

Approcci più moderni alla raccolta dei dati sulle prestazioni includono la streaming telemetry. Una piattaforma di raccolta si associa ad alcuni dati sulle prestazioni (di solito da un dispositivo di rete o un controller). I dati sono poi inviati direttamente, il che significa che arrivano al collector quasi in tempo reale.

Il monitoraggio delle prestazioni è limitato al singolo dispositivo, al collegamento o alle applicazioni. Di nuovo, possono essere necessari più strumenti a causa del mix di fornitori e capacità e diviene difficile offrire una visione aggregata significativa. Mantenere la visibilità e la coerenza end-to-end è ancora una volta la chiave.

Event Management

Oltre al monitoraggio delle prestazioni, i sistemi per raccogliere dati sugli eventi di rete sono vitali per fornire un servizio reattivo. Tra tali meccanismi di raccolta troviamo:

• SNMP traps – un approccio “tradizionale”, secondo cui se un dispositivo rileva un evento che va notificato, invia una “trap” a un collector. La trap è registrata e visualizzata sulla dashboard.
• Syslog – un altro meccanismo molto noto, utilizzato da tutti gli elementi di una infrastruttura IT. Un sistema crea delle log entry per gli eventi di un dispositivo. Queste entry possono essere conservate localmente o inviate a un collector.
• Webhooks – un approccio nuovo, utilizzato tipicamente da infrastrutture o controller API-driven. Se in un dispositivo o in un sistema si verifica un evento, una richiesta http è inviata a un dato web server che crea una queue di notifiche. Un gestore potrà prendere le notifiche webhook dalla queue e agire di conseguenza, generalmente utilizzando uno script per ottenere maggiori dettagli sull’evento dal dispositivo o dal sistema in questione.

Da una prospettiva di rete, l’elemento chiave della gestione degli eventi è la correlazione. Un incidente nella rete può generare eventi su un certo numero di dispositivi e apparire come una serie di trap SNMP, voci di registro o webhooks nel motore di raccolta. Un motore di correlazione degli eventi (come una piattaforma SIEM – Security Incident Event Management) combinerà queste notifiche e cercherà di ricavarne una root cause.

È importante accertarsi che tutti gli elementi della rete contribuiscano ai dati degli eventi, soprattutto quando si utilizza la correlazione per determinare la causa dei problemi. Il tooling tradizionale non lo verifica, occorre perciò redigere una descrizione della rete e delle corrette configurazioni.

Gestione del servizio IT

Tanto si è scritto su questo argomento, quindi non mi addentrerò troppo in profondità, ma ci sono aree nella gestione dei servizi con un impatto importante sulle operazioni di rete quotidiane. Per esempio:

• Incident Management – l’insieme dei processi che un service desk utilizza per trattare, analizzare e risolvere i problemi. Gli strumenti di Event Management e di Performance Monitoring sono utilizzati per attivare proattivamente questi processi. Di solito gli utenti che si trovano di fronte a un problema lanciano i ticket manuali, pertanto i sistemi di ticketing guidano i processi.
• Problem Management – quando un insieme di incidenti può essere raggruppato per indicare che c’è un problema su più vasta scala o a lungo termine. Si basa sugli stessi strumenti dell’Incident Management, ma anche (e molto) sulla documentazione, sulla consegna del progetto e così via.
• Change Management – quando è necessario apportare modifiche alla rete, occorre valutarne l’impatto. In questo ci si affida molto alla documentazione, oltre che all’esperienza degli ingegneri di rete. È fondamentale anche aver chiara la dipendenza delle applicazioni dai diversi elementi della rete.

È chiaro che, per i processi ITSM, tanto migliori sono le informazioni sull’interazione del servizio applicativo con l’infrastruttura che lo supporta, meglio è. Ricavarle da semplici piattaforme di monitoraggio è difficile. La documentazione deve anche essere aggiornata per supportare la convalida pre e post-cambiamento.

CMDB

Il CMDB – o Configuration Management Database – è un termine improprio per descrivere il supporto di rete. Non si occupa di gestire le configurazioni dei dispositivi, ma funge da inventario definitivo degli elementi che compongono l’infrastruttura di rete. È utilizzato da tutte le aree del business che necessitano di accesso e visibilità a queste informazioni, e comprende:

• Physical inventory – dispositivi, moduli e parti degli stessi, numeri di serie e location.
• Software licence data – relativi a dispositivi, set di funzionalità, scadenze e costi.
• Support contract information – produttore, numeri di serie coperti, livello di copertura (es: 9×5 sostituzione nello stesso giorno lavorativo, 24×7 sostituzione in quattro ore), periodo di copertura.
• Circuit rental – service provider, location A e B end, copertura supporto, cambiamenti annuali, durata, informazioni sulla cancellazione.

Questi elementi non sono direttamente legati al funzionamento dell’infrastruttura di rete (anche se le licenze lo stanno diventando sempre di più), ma sono fondamentali per garantire che il supporto funzioni. Troppo spesso si utilizzano processi manuali per sincronizzare i dati con queste piattaforme operative.

Next time

Abbiamo visto come, per far funzionare le reti, sia necessaria una serie di strumenti per mantenere un buon livello di visibilità e controllo. Nella seconda parte di questa mini-serie, analizzeremo come IP Fabric può rispondere a quesiti che gli strumenti tradizionali appena descritti non possono risolvere. Vedremo anche come arricchire i dati di questi strumenti con informazioni integrate a IP Fabric!