Salve, nel caso di Enti di Ricerca o Centri Universitari si applicano le stesse regole di migrazione degli altri enti pubblici?
In particolare nei casi, come il mio Istituto o l’ispra ecc., che forniscono anche attività di protezione civile e analisi real-time per le emergenze, su grossi quantitativi di dati dell’ordine di decine di GB o TB, come sarà possibile garantire questi servizi (elaborazioni con limiti di tempo sotto ai 5 minuti) tramite applicativi/dati delocalizzati?
Il risparmio della struttura CED non verrà divorata dalla spesa per il trasferimento bidirezionale giornaliero dei dati dalle postazioni di lavoro (es. post-elaborazioni con matlab ecc) ai servizi cloud?
Come bisognerà muoversi per rispettare le disposizioni nel caso di dati e servizi legati a progetti europei che prevedono la creazione di strutture fisiche dedicate e appositamente finanziate?
Da un punto di vista esclusivamente “tecnico”, dovrebbe essere possibile trasferire, oltre ai dati, anche le applicazioni. Cosa impedisce di effettuare il 100% dell’elaborazione in remoto, e trasferire solo “la console di visualizzazione”?
inoltre
Sono convinto che nel nostro Paese, se c’e’ un problema RISOLTO, è quello della “Banda / Capacità Trasmissiva” fra gli Enti di Ricerca (e fra questi e Internet). Sia INGV che INFN sono capillarmente connessi a GARR e nell’ipotesi che i relativi link siano “saturi”, non ci vorrà piu’ di una telefonata (e zero euro) per “upgradarli”. Parlo per esperienza diretta (seppure nel caso di un Ateneo), dove i miei sforzi --ormai da anni-- sono tesi ad “arginare” l’OFFERTA di banda (da GARR verso l’Ateneo), e non il contrario.
Cio’ non toglie che se hai necessità di trasferire 1TB di dati ogni giorno… ti consiglierei di valutare l’opzione 1.
Se tale necessità, però, fosse “spot” (e magari anche non-prevedibile), GARR e GEANT sono certamente già pronti per darti una mano: da tempo, ormai, l’infrastruttura e’ tale da potersi rapidamente adattare alle esigenze dei singoli (es.: l’attivazione di un bond di 8 link da 1 Tbps , nel 2013, si e’ fatta in 20 minuti). Insomma: parliamo di tecnologie, capacità trasmissive e livelli di supporto di almeno due ordini di grandezza superiori agli standard di mercato (mi riferisco ad SPC[1|2]). Tra l’altro, dal 29 al 31/05/2018, a Roma ci sarà il WorkShop GARR 2018: un’ottima occasione per riflettere sul da farsi
Come tutto questo si incastri “giuridicamente” con i temi di questo thread, non mi è chiaro. Però mi è cristallino che, in ambito Ricerca, grazie a GARR, la “banda” semplicemente NON è un problema. Da tempo.
Da un lato mi è chiara la volontà del legislatore di “classificare” i vari contesti e, per farlo, cercare di partire dal “ferro” (hai un NAS sulla scrivania? Non va migrato! Hai un dispositivo che definiresti SOHO? Non va migrato! Hai un NAS con 8 bay da 3,5" in un RACK? => va migrato! Hai un vecchio tower sotto la scrivania, che fa da web-server? => va migrato! etc.) o dalle “applicazioni” (web dell’Ente? Via! Posta elettronica? Via! Domain-controller? Uhm… lascialo! Firewall? e’ rete: lascialo; etc.).
Dall’altro, però, ho la sensazione che si sottovalutino gli aspetti legati alle DIMENSIONI dei contesti coinvolti. Dimensioni che possono cambiare, anche radicalmente, gli scenari.
Cerco di spiegarmi attraverso un esempio.
In un qualunque Ateneo è evidente che qualche ufficio (Settore Reti e Sistemi?) debba necessariamente avere a che fare con:
dispositivi di switching Layer2 (o superiori);
wireless access-points
cito solo questi perchè sono gli unici (gli UNICI) di cui non ci si può liberare.
In un caso che mi vede coinvolto, il 05/04/2017 contavo:
(a) 251 switch
(b) 138 access-point
Ora, a meno che l’Ente non decida di “chiudere” l’Ufficio Reti e Sistemi delegando il 100% (il 100%; non il 99%) delle funzioni IT all’esterno, quegli apparati vanno “gestiti”.
Tale “gestione” --come sanno tutti quelli che fanno tale lavoro-- comporta:
la presenza di un numero più o meno elevato (>0) di dispositivi di routing (segmentazione in VLAN e relativa rotazione del traffico) e di dispositivi di firewalling (per l’enforcement delle policy inter-VLAN e da queste verso l’esterno);
la presenza di un sistema di monitoraggio (>= 1 server + relativa applicazione - Alzi la mano chi sarebbe disposto a “gestire” il tutto SENZA monitoraggio);
la presenza di un sistema di backup (alzi la mano chi gestirebbe 251 switch+138 AP + 1 server di monitoraggio SENZA avere una qualche forma di backup delle configurazioni);
la presenza di un sistema di raccolta dei LOG (che può spaziare dall’entry-level [relativo al solo server di monitoraggio], all’iper-dettagliato [flussi NetFlow in transito fra le VLAN e fra queste e l’esterno]
Aggiungerei che, anche se non tecnicamente necessari, e’ fortemente consigliabile adottare:
un sistema di Trouble-Ticketing (per gestire i rapporti con l’utenza finale);
un sistema (anche solo “accrocchiato”) di trend-analysis (perchè se vedo che un tratto di backbone a 100Mbps mostra un trend di incremento del traffico, nell’ultimo anno, tale da farmi capire che fra 6 mesi si saturerà… l’upgrade del link devo pianificalo ORA, e non allora).
A catena, accade che:
essendo il 2018 (e non il 1998), non ci sogniamo nemmendo di avere macchine “fisiche” per ospitare le nostre applicazioni (fossero anche solo il Trouble-Ticketing ed il monitoring): andiamo di “virtualizzazione”. Quindi, al “set” di tecnologie che mi servono, va aggiunto anche l’hypervisor.
Poi, a seconda del rapporto che si ha con le tecnologie Open-Source, potrebbe anche accadere che:
un firewall (quello di cui al punto 1) che per molti è costituito da un “ferro” che si “acquista” (da un vendor proprietario), è in realtà un box Linux/BSD [open-source] con sopra delle piattaforme open-source [PFsense, VyOS, etc.], deployabile sia “fisicamente” (con aumento della quantità di “ferro” da gestire) sia “virtualmente” (con aumento della capacità elaborativa dell’infrastruttura di virtualizzazione)
(…mi fermo qui, con l’elenco… anche se potrei continuare con Hot-Spot, Radius, DB di backend, etc. etc.)
Detto tutto questo… tornando al problema principale… mi è chiaro che “qualcosa bisogna fare” perchè --come le cronache ogni tanto ci ricordano-- accade che le infrastrutture come quelle sopra descritte NON vengono gestite come si dovrebbe e, in caso di problemi, accadono disastri.
Però mi è altrettanto chiaro che li dove l’infrastruttura viene gestita, fosse anche solo una “normale” infrastruttura di SOLO NETWORKING (quand’anche “estesa”), le indicazioni che arrivano dal centro… non risultano particolarmente chiare e si fa fatica a calarle nel contesto esistente.
La mia idea è che le tre componenti seguenti:
volontà politica “centrale” di accentrare il più possibile la gestione ICT di tutta la PA Italiana;
volontà “periferica” di mantenere attivi i locali “Uffici Reti e Sistemi”;
necessità di gestire l’infrastruttura fisica “locale” affinché offra all’utenza finale un servizio in linea con le attese (dell’utenza finale)
sono INCOMPATIBILI. Bisogna rinunciare ad almeno uno dei tre.
La mia sensazione è che si sia scelto di aggredire il terzo punto. È ragionevole; ma senza contestualmente aggredire anche il secondo, si fa fatica. Dal mio personalissimo punto di vista --nei contesti “medio/grandi” (come quello da me descritto), “infrastruttura” e “persone che la gestiscono” non possono essere fortemente disgiunti (come, invece, possono esserlo nei contesti “piccoli”). Se strategicamente si ritiene di dover acquisire il controllo dell’infrastruttura, a quel punto non si può prescindere dalla chiusura TOTALE del CED.
Lasciando in periferia SOLTANTO switch e access-point. Nulla di più.
In questo modo “cade” tutto il castello da me disegnato (punti da 1 a 8) e… si puo’ ragionevolmente assumere che, localmente, non serve alcunche’. (router, firewall, server, controller di dominio, etc.).
Se, viceversa, si lascia anche solo un cacciavite dentro la sala server… il gioco non funziona più, e ci si avvia verso uno stallo (le cui “tracce”, in parte, si intravedono in questo thread).
Un caro saluto,
DV
P.S.: ovviamente il mio e’ un discorso che esula dall’effettiva capacità degli attuali “vendor” che sono chiamati a gestire (in forza delle convenzioni CONSIP) parte dei servizi sopra accennati. Valutare la loro capacità (e “guidarli” verso il raggiungimento di obiettivi di qualità “adeguati”) spetta ad altri: io mi limito ad assumere che siano “adatti”
la parte di acquisizione dei segnali non può essere migrata in quanto basata su reti a tecnologie miste comprese reti a ponte radio e segnali passanti su reti PtP, quindi raccolta del dato e ulteriore trasferimento al centro di elaborazione remoto comportano un rallentamento di un segnale elaborato in real-time (parliamo di dati che devono essere temporalmente allineati durante tutta la fase di elaborazione).
La console non è di mera visualizzazione ma di elaborazione interattiva parallela alle procedure automatiche, il turnista deve analizzare il dato e fornire conferma della risposta automatica in tempi stringenti, analizzando il segnale ed rielaborandolo manualmente.
Il GARR non è gratis il costo che non viene semplicemente percepito, dagli atenei in quanto pagato dal MIUR, dagli enti fondatori perché integrati della rete stessa, mentre enti come il nostro pagano un esborso non indifferente.
In questo ambito il GARR è comunque completamente inapplicabile in quanto i livelli di affidabilità e sicurezza richiesti non sono assolutamente forniti, tanto che il GARR stesso si rifiuta anche di fornire un eventuale servizio come backup di terzo livello della linea per applicazioni del genere.
Rimane l’unica strada percorribile quella di SPC ma con costi impossibili soprattutto dopo i risultati dell’ultima gara.
Buongiorno Paolo,
il nostro Ente sta procedendo alla compilazione del censimento, in quanto rientravamo nella fase 2.
Purtroppo abbiamo un sistema di backup a nastro piuttosto obsoleto che sta evidenziando delle criticità.
Abbiamo chiesto dei preventivi per backup cloud, ma per abbattere i costi abbiamo bisogno di ridurre le retension via cloud e tenere gli storici mensili e annuali su qualche altra piattaforma. Come possiamo procedere? E’ pensabile adottare un NAS per i server con un sw di gestione tipo Veeam e contestualmente approntare anche un sistema di BaaS? o dobbiamo esclusivamente affidarci al cloud?
Grazie
Sabrina
Ciao Sabrina,
la risposta corretta si trova cercando di calcolare il TCO correttamente su un periodo di medio-lungo termine per entrambe le soluzioni sulla infrastruttura in questione.
Generalmente nel contesto della PA la soluzione cloud risulta più conveniente da quello che abbiamo potuto riscontrare, ma è necessario valutare correttamente tutte le condizioni a contorno per poter dare una risposta puntuale.
La scelta del cloud non è dogmatica si basa principalmente su valutazioni economiche, di affidabilità e facilità d’uso. Sicuramente l’indicazione Cloud First vale per la maggior parte dei casi nella PA, ma non per tutti, per poter dare una risposta più precisa andrebbe analizzata più dettagliatamente la situazione specifica.
Scusa la domanda, ma tra mille domande e mille risposte, ho perso un po’ il punto della situazione e ora non capisco una cosa: domanda: oltre a tutti i servizi applicativi, sia interni che per il cittadino inclusi servizi di posta e backup, che devono essere migrati verso il Cloud nelle modalità che abbiamo già citato (anche se non capisco il criterio di scelta del cloud tra PSN, SPC o CSP, e chi fa questa scelta e in base a cosa), cos’altro va migrato?
alcune risposte relative ai criteri di scelta dovresti trovarle su cloud.italia.it in particolare al punto “I criteri di scelta dei servizi cloud”, mentre non mi è chiaro cosa intendi per "altro:. Il punto di partenza della migrazione al cloud è il consolidamento dei Data Center e dei servizi applicativi che dovrà avvenire secondo quanto indicato dal “Programma di Abilitazione al Cloud della PA.” Tale programma è stato definito a grandi linee dal Team per la Trasformazione Digitale e da AgID ma verrà dettagliato e pubblicato successivamente come previsto dal Piano Triennale sotto forma di Linee Guida.
Saluti
Paolo de Rosa
Team per la Trasformazione Digitale
Ti ringrazio per la risposta.
Per altro intendo dire: supponendo di aver già pianificato la migrazione, e che i fornitori di servizi del mio comune siano già stati qualificati da agid per i propri servizi SaaS e che dunque il comune si appoggerà a tali SaaS, dovremmo comunque aspettare il 20 Novembre per vedere i servizi sul Marketplace. Quindi cos’altro deve fare il comune? per quei applicativi sviluppati internamente, deve qualificarli come SaaS, visto che dovrà comunque migrarli verso il cloud?
La domanda corretta sarebbe stata:
come deve procedere il comune per quei servizi sviluppati internamente?
e per quelli che non sono qualificati, ma che il comune comunque usa? vanno anche essi qualificati o vanno sostituiti (ex novo o SaaS analoghi)?
Il dubbio sta qui. Per quelli che non sono stati qualificati da agid, mi conviene sostituirli, non cloudizzarli?, qualificarli?
Qua dice che la scelta del servizio va fatta prima con il paradigma SaaS First il che significa (se ho capito bene) che se esiste un medesimo servizio come SaaS (possibile che sia disponibile tramite il mio fornitore?) è opportuno (rispettando sempre la disponibilità economica del comune) consolidare tale servizio dal datacenter e migrarlo in modalità SaaS, acquistando tale servizio dal Market place (attualmente VUOTO), altrimenti se non disponibile, si procede con l’acquisto di IaaS o PaaS semrpe dal market place (VUOTO) e lo si implementa in proprio. Corretto?
Un’altra cosa che non è per niente chiara è " Nella maggior parte dei casi in cui il servizio richiesto non gestisce dati di particolare rilevanza per la sicurezza nazionale la PA potrà ricorrere all’utilizzo di servizi commerciali o pubblici ( public cloud CSP o community cloud SPC ) dove la scelta sarà guidata esclusivamente dalle caratteristiche di qualità e prezzo offerte dai fornitori CSP o SPC, nel rispetto della normativa vigente in ambito di acquisizione di beni e servizi. "- cosa significa? Comunque valuto prima il servizio fornito dal mio attuale fornitore e lo confronto con altri fornitori del medesimo servizio (sbaglio?).
Un’altra cosa che non mi è chiara e che probabilmente non ha nulla a che fare con il mio comune di 15 mila abitanti è riferita a quanto citato “Nel caso dei PSN, vista la rilevanza e i costi correlati di tali infrastrutture sarà cura del Governo e delle Regioni valutare e disporre quali servizi considerati asset strategici nazionali dovranno essere erogati per mezzo degli stessi.” ???
Ultima domanda fa riferimento a tale citazione " Il processo di migrazione del gruppo B non può avvenire senza la partecipazione attiva di tutte le componenti della PA. Per garantire la continuità di servizio, durante la fase di migrazione, si rende necessaria una fase di studio partecipata in cui PAL, PAC e fornitori dovranno collaborare per selezionare le soluzioni più adatte a soddisfare tale requisito. " in che modo il mio comune deve interagire con le PAC (Regione immagino), a che scopo?
NB tutte le domande sono mirate ad una comune osservazione: Prima di migrare tutti i servizi nel cloud, dobbiamo comunque prestare attenzione alle risorse che abbiamo.
si le domande sono un po’ troppe proviamo a scindere i temi e iniziamo rispetto al primo punto.
SaaS First non è un paradigma bensì una strategia che suggerisce di dare priorità alle soluzioni applicative erogate in modalità SaaS, qualora sia necessario effettuare una scelta rispetto ad altre opzioni (IaaS e deployment della soluzione in proprio, ecc. ). In alternativa il criterio di scelta dovrebbe sempre tenere in considerazione la valutazione del Total Cost of Ownership (TCO).
AgID sta lavorando al popolamento del Marketplace.
