WORKSHOP GARR 2019
8-10 ottobre 2019

Aula magna della Scuola Lettere, Filosofia, Lingue dell'Università Roma TRE

9 ottobre 2019

Damiano Verzulli

Università di Chieti
https://www.unich.it/

9 ottobre 2019 - SESSIONE: Infrastruttura di rete: monitoring e servizi

NET/SYS/APP monitoring in un medio Ateneo Italiano (nel 2019)

Slide

Damiano Verzulli

NET/SYS/APP monitoring in un medio Ateneo Italiano (nel 2019)

Classe 1971, nel 95 si laurea in Scienze dell’Informazione e nel 1996 inizia ad occuparsi di tecnologie Internet, in CINECA, nell’allora gruppo CSD/Nettuno. Nel periodo 1999-2002, in piena “Dot-Com Bubble”, transita in Nextra – multinazionale norvegese a caccia del mercato ISP Europeo – dove coordina il gruppo italiano di web-development. Dal 2003 è referente tecnico GARR (APM) per l’Università “G. d’Annunzio” di Chieti-Pescara, dove supporta gran parte dei processi di gestione dell’infrastruttura di Rete d’Ateneo e dei sistemi ospitati nel relativo Datacenter. Dal 2013 è anche APM di ICRANET. In un macro-contesto in costante e rapida evoluzione, cerca di garantire il miglior funzionamento possibile di tutta l’infrastruttura gestita, impiegando al meglio le tecnologie di “monitoring” e di “analitica”. Convinto sostenitore della cultura “Open Source” spende gran parte del proprio tempo a (cercare di) aggiornarsi su tutto quello che è l’Internet “moderna” e sulle tecnologie software che vi ruotano attorno

Born on 1971, after a Computer Science degree (1995), he joined CINECA on 1996 as "Internet Developer". During the "DotCom-Bubble era", 1999-2002, he lead the "Web Development" team of Nextra, a Norway-based corporation approaching the european ISP market. Since 2003 is Access-Port-Manager (APM) for the University "G. d'Annunzio", supporting operations of local infrastructure and datacenter. Since 2013 is APM also for ICRANET. Strongly technical, Open Source addicted, he spend lots of time trying to stay aligned with current Internet technologies development.

 

NET/SYS/APP monitoring in un medio Ateneo Italiano (nel 2019)

Le problematiche tecniche che insorgono nel corso delle normali attività di gestione di una infrastruttura di rete estesa –quale quella di un medio Ateneo Italiano--, non rappresentano una particolare novità: l'analisi near-real-time del regolare funzionamento dell'infrastruttura è ormai resa possibile da una molteplicità di strumenti software in grado anche di supportare agevolmente i successivi processi di gestione degli incidenti (allarmistica e trouble-ticketing). Lo scenario cambia nel momento in cui allarghiamo l'angolo di visuale: se la detection di un fault e del relativo disservizio è banale tanto quanto un PING oppure una richiesta cURL/WGET, misurare la “Qualità” della propria infrastruttura wireless –così come percepita dai propri utenti-- è decisamente più complesso. Ed è altrettanto complesso “osservare” il comportamento delle macro-componenti applicative (Firewalling, Posta Elettronica, Servizi WEB, Traffico Ethernet/IP solo per fare qualche esempio) con il triplice obiettivo di: 1) individuare quelle problematiche che, pur presenti, non generano disservizi; 2) aumentare il livello di security garantito dalla propria infrastruttura; 3) supportare adeguatamente i processi evolutivi dell’infrastruttura, a medio/lungo termine. Nei campi di battaglia degli uffici “Reti e Sistemi” di moltissimi Atenei si combatte quotidianamente fra utenti che lamentano mancata connettività (salvo poi scoprire che il proprio client fa 10 richieste DHCP-DISCOVER al secondo; oppure è (mis)configurato con i DNS non ufficiali), scarse prestazioni wireless (salvo scoprire che stanno utilizzando un SSID non ufficiale), impossibilità di telefonare (salvo poi scoprire che –courtesy del servizio di pulizia-- l’interfaccia dello switch a cui è connesso il telefono è andata DOWN alle 19:30 della sera precedente). Storage, potenza di calcolo e capacità trasmissiva sono ampiamente accessibili e non rappresentano più un problema economico. È quindi certamente possibile ipotizzare l’implementazione di strumenti di telemetria in grado di raccogliere una notevole mole di dati relativi all’”utilizzo” delle varie componenti infrastrutturali (hardware e software) per poi archiviarli e processarli –anche in modo “distribuito”–, adeguatamente. Elemento trasversale e, soprattutto, fondamentale rispetto a tale attività è il software: un PING non è più sufficiente, così come una chiamata SNMP oppure un DB RRD. Servono strumenti “nuovi”. Meglio: serve un nuovo approccio. Un approccio che nella maggior parte dei casi, il singolo Ateneo non è in grado di perseguire autonomamente. Di questi aspetti e dell’effettiva necessità di questo nuovo approccio si discuterà nel corso della presentazione.


NET/SYS/APP monitoring in a Campus Network (on 2019) Biografia IT:

Technical issues encountered during day-by-day operations of a Campus Network are not big news: a wide set of software suites are available, providing an effective "near-real-time" picture of the status as well as supporting related incident management (notifications/alarming and trouble-ticketing) Things gets a bit trickier if we need a larger overview: while checking the availability of simple services can be easily achieved by simple tools (PING, cURL/WGET, etc.), to properly observe the current "Quality level" of complex infrastructures a more complex approach is required. The whole wireless infrastructure, the firewalling service, the whole e-mail infrastructure, web services and, in general, the routing and forwarding of Ethernet/IP network traffic (just to name a few) need to be "monitored" in order to: 1) detect anomalies that might exist, but are not disruptive of the whole service; 2) increase the "security level" offered by the infrastructure; 3) provide key-data to top/middle management to better define an evolution strategy. System and network departments are fighting on a daily basis with end-users complaining about connectivity issues (and discovering, afterwards, that related notebook is firing tens DHCP-DISCOVER requests per second; or that such notebook have been configured to point to unofficial DNS), users complaining about poor performance of wireless connection (and later discovering that they are NOT associated to official SSID), users complaining about VOIP service disruption (and later discovering that someone mistakenly unplugged the ethernet cable from the wall socket --generally, courtesy of the cleaning service--). Nowaday storage, computing power and network bandwidth are widely available and relatively cheap. Thanks to this, the implementation of a telemetry system being able to collect massive amount of data to be further processed searching for "hidden" elements, is definitely feasible. "Software" is a key factor for the succesfullness of such an approach. Employing simple/standard tools is not enough. A new set of software need to be developed, designed and built around the specific needs of each organization. Unfortunately this is a complex task, not being able to be fulfilled by single university, alone. How to step further?

 

 

Il workshop è sponsorizzato da:

DELL
juniper networks
INTEL
jAmazon Web Services

GARR | TelegramGARR | Telegram

Consortium GARR - La Rete Italiana dell'Università e della Ricerca