Sistemi di supporto.

Presentazione sul tema: "Sistemi di supporto."— Transcript della presentazione:

1 Sistemi di supporto

2 Topologie sistemi di supporto
Centralizzato Semplice da implementare e mantenere SPOF Resistente alla scalabilità ed all'interoperabilità Distribuito Difficile da implementare e mantenere Richiede accordi su standard di trasmissione Offre massima scalabilità Stella Mediamente difficile da implementare e mantenere Gli standard di trasmissione (ad es. formato e ID del ticket) sono definiti (“imposti”) dal centro stella Offre buoni livelli di scalabilità

3 Topologia di EGEE Sistema a stella: Global Grid User Support
Centro stella affidato a FZK (DE): Sistema centrale basato su istanza di Remedy Implementazione dei singoli rami demandata ai ROC con requisiti: Capacità di interfacciarsi al sistema centrale tramite messaggi 1) testo su SMTP, 2) XML su SMTP, 3) SOAP Usare definizioni di campi conformi allo “standard” definito da GGUS (livelli di prorità, stati possibili, campi opzionali per la descrizione del ticket)‏

4 Centro stella Tipologie di utenti: 1) Submitter, 2) Supporter
Spazio di utenza flat: un supporter può accedere/rispondere a qualunque ticket Disponibile sottomissione via mail Offre un unico punto di accesso per qualunque utente grid in difficoltà: filosofia top-bottom Utente sottomette ticket TPM smista richiesta al ROC competente ROC trova soluzione interna ROC fornisce soluzione esterna

5 Sistema di supporto nel ROC deve assolvere 2 funzionalità distinte:
Workflow nei ROC Sistema di supporto nel ROC deve assolvere 2 funzionalità distinte: Operare come ramo nel sistema GGUS-centrico (anche in modalità bottom-top)‏ Operare indipendentemente per problemi locali Ogni ROC ha scelto la sua implementazione UK: Footprint (commerciale)‏ CE, SWE: Sistemi sviluppati ad hoc CERN: integrazione del proprio Remedy IT, FR, (Etics?): XHelp Altri ROC usano semplicemente GGUS

6 Workflow nel ROC Italiano
Sistema di supporto basato su XHelp Requisiti di sistema “minimi” Integrato con componenti “accessori” Single sign-on (via certificato o username+password) per ticketing, wiki, calendario dei turni, FAQ, etc. Customizzazione dei campi Per aderire rapidamente alle variazioni di GGUS Gestione dello staff nei dipartimenti con ruoli differenti: filosofia gerarchica Sistema di notifiche a plugin Via SMTP, via SOAP, via Jabber Sottomissione via mail

7 Integrazione GGUS  XHelp
Un dipartimento specifico per il trasferimento dei ticket a GGUS Scelta consapevole del supporter (può decidere se inviare la sua risposta) In teoria implementa workflow con risoluzione interna + risposta finale Protocolli di trasferimento SOAP in uscita SMTP in ingresso Esiste anche SOAP in ingresso, mai in produzione per diverse ragioni Test non coordinati Responsiveness delle notifiche sincrone

8 Evoluzione topologia EGEE
Più centralizzato Più distribuito Bypass ROC per “emergenze” ai Tier-1 Automazione ticket di monitoraggio “Alleggerimento funzionalità”

9 Altre architetture XHelp in modalità distribuita (senza centro stella)
Trasferimento ticket via mail Funzione di hashing (non soddisfacente) per rendere univoco un ticket

10 Evoluzione ROC italiano
Re-ingegnerizzazione staff-dipartimenti-ruoli Reportistica (framework disponibile) Sottomissione via mail Annulla la “minimalità” dei requisiti Maggiore interattività con server di posta Cosa manca Nessun altro framework (opensource) implementa tutti i desiderata Non confondere bug tracking con helpdesk Richieste contrastanti (centralizzato vs. distribuito, utenti flat vs. utenti gerarchici) Come realizzarlo