Il Fornitore Cloud deve dimostrare di essere in grado di erogare i servizi proposti dal punto di vista tecnologico, rispettando i requisiti specifici concernenti le seguenti tematiche:
- sicurezza, privacy e protezione dei dati (RSI)
- performance (RPE),
- interoperabilità e portabilità (RIP),
- conformità legislativa (RCL).
Continua a leggere su: http://cloud-pa.readthedocs.io/it/latest/circolari/CSP/allegato_docs/requisiti-specifici.html
Commenti da Enter Cloud Suite
RPE1 – In questo requisito non è chiaro il significato di fruibilità “nella sua interezza”. Chiediamo pertanto di riformulare in maniera più chiara il requisito. Sembrerebbe, da quanto scritto, che l’indisponibilità di un solo servizio (ad es. API Telemetria o Automation) dia luogo al conteggio di indisponibilità anche per tutti gli altri servizi, nonostante i due servizi non si limitino a vicenda (ad es. con Computing o Networking). Parrebbe poi in conflitto con RPE3, RPE4, RPE5 dove invece si analizzano gli SLI per singolo servizio.
Inoltre non sono definiti gli SLI02 e SLI03. É un refuso?
RPE2 – Cosa si intende per “tempi di risposta del servizio”? Da quale punto di osservazione e con quali metriche va misurato? Il requisito è posto forse in modo troppo generico e interpretabile. Non è inoltre possibile trovare l’indice SLI04.
RPE3 – Nel bando “Cloud I” della DIGIT le finestre di manutenzione non erano computate, mentre la ISO19086-1 recita: “Availability may be calculated as the total time over a set of defined intervals less the total downtime during each interval, and may exclude allowable downtime”. Non è chiaro se le manutenzioni programmate rientrino o meno nei periodi di indisponibilità del servizio. Potete chiarirlo?
RPE4 – Gli indicatori citati a che tratta di rete si riferiscono precisamente? Si suggerisce di identificare un endpoint assoluto o relativo al provider da cui è possibile effettuare una misurazione condivisa.
RPE5 – Nella descrizione del requisito si parla di bandwidth ma non di IOPS (Input/Outpu Operations per Second). Il tempo di lettura/scrittura dipende da fattori sotto il controllo del provider (ad es. bandwidth, IOPS, tecnologia dischi, repliche e RAID) ma anche da fattori dipendenti dal Cliente (ad es. block size del filesystem). Il tempo di restore dipende significativamente da entrambi. Non è dunque chiara la modalità con cui vanno rappresentati i dati.
Non è poi chiara la distinzione tra block e object storage, se c’è.
RPE6 – Non è chiaro cosa si intenda per “tempi massimi di risposta delle componenti PaaS”. Ad esempio, nel caso di database e load balancer può essere dedotto (pur con alcune precisazioni necessarie), ma nel caso di “DevOps” e “middleware” risulta difficile definire un tempo di risposta senza definire nel dettaglio il tipo di servizio offerto. Il requisito risulta troppo generico
RPE7- L’attivazione della scalabilità automatica e i criteri del servizio vengono sempre definiti dall’acquirente. Pertanto si richiede di riformulare o eliminare questo requisito in accordo con le prassi comuni.
RIP2 – E’possibile fare riferimento alla documentazione ufficiale mantenuta dalla community Openstack per la documentazione generale delle API?
RIP3 – Per quanto tempo e a che condizioni viene richiesta la retrocompatibilità delle API? Quante versioni precedenti?
RIP4 – Come si identifica la classe di utilizzatori? Si chiede di riformulare il requisito in modo che risulti più specifico.
RIP5 – Con quali modalità e per quanto tempo devono essere gestiti e conservati i log centralizzati?
RIP7 – Nel caso in cui l’utente dovesse terminare un’istanza o una risorsa, la stessa non può essere recuperabile, in nessun modo se l’utente non ha preventivamente disposto una copia in locale o su altro supporto, dei dati cancellati. Inoltre, i costi delle risorse impegnate nei due mesi di Phase Out non dovrebbero essere a carico del Cloud Provider. Forse sarebbe utile spiegare meglio la finalità di questo provvedimento, al fine di trovare soluzioni e compromessi adeguati a tutelare la persistenza dei dati del cliente, e la prestazione di servizio del Provider.
RIP9 – Non è indicato il tempo massimo definito per la conservazione maggiore di 60 giorni. Si propone di definire un tempo massimo di 90 giorni di calendario
SLI (tutti) - Manca la definizione degli SLI02, SLI03 e SLI04, che sono però richiamati. Si richiede di pubblicare un elenco di SLI completo ed allineato
SLI01 – La percentuale di disponibilità del servizio su che intervallo è misurata? Mese o anno?
SLI12 – Quale provider è in grado di dare un tempo massimo di risoluzione per un evento non verificato/codificato senza essere inattendibile?
RPE2 - RPE4 - SLI05
I tempi di risposta sono fortemente dipendenti dalla rete o, in caso di servizi mobile, dalla copertura di rete dell’operatore mobile. In particolare il cliente può scegliere tra:
Inoltre i tempi di risposta sono fortemente dipendenti dal carico applicativo, carico per sua natura dipendente dal cliente.
Si suggerisce quindi:
NOTA: lo SLI04 citato nel RPE4 non è presente nel testo disponibile sul sito
RPE07/SLI06: elasticity
L’elasticità è una delle caratteristiche fondamentali dei servizi Cloud. Ciononostante al momento non esistono ne una metrica ne un benchmark definito. Relativamente alle soluzioni PaaS i tempi di attivazione di istanze aggiuntive dipendono dal tipo di servizio e possono variare da pochi secondi fino all’ordine dei minuti.
Si suggerisce quindi di eliminare questo requisito oppure di renderlo opzionale.
Retention Period SLI07:
I servizi Iaas/Paas sono per loro natura dinamici; il loro provisioning è inoltre guidato dal cliente. Il CSP fornisce a catalogo tool per la gestione dei dati e dei backup mentre il provisoning e la gestione dello storage per la gestione dei dati è di responsabilità del cliente. Ne consegue che il periodo di “retention” dei dati è definito dal cliente che in caso di phase out dovrà allocare lo storage per la retention dei dati.
Si suggerisce di eliminare lo SLI o di sostituirlo con un requisito che indichi la possibilità per il Cliente di acquistare i soli servizi di storage e backup all’atto della terminazione delle attività elaborative.
NOTA1: di norma il CSP non notifica la terminazione del servizio, essendo questo sempre attivo.
NOTA2: per quanto riguarda i dati relativi alle configurazioni dell’utente (macchine virtuali, storage e quant’altro) questi, di norma, vengono conservate per un periodo di 12 mesi
Tempi di disponibilità del servizio vs tempi di interruzione dello stesso (SLI14, SLI15, SLI16)
Gli SLI in oggetto sono tutti dati derivati dai parametri di Disponibilità e dai tempi di fermo. Disponibilità e tempi di fermo che generano i valori dei Crediti dovuti ai clienti. Data la loro scarsa rilevanza si consiglia di eliminare tali metriche derivate
Maximum Incident Resolution Time (SLI12) e Recovery Time Objective (SLI20)
Il periodo di risoluzione di un incidente non è predeterminabile a priori a causa della variabilità delle possibili tipologie di incidente. Inoltre le tempistiche di una risoluzione sono fortemente dipendenti dalla disponibilità o meno dei servizi di backup e/o di Disaster Recovery
Data la flessibilità fornita ai Clienti di approvigionarsi o meno dei servizi accessori di backup e di DR si suggerisce di eliminare il requisito. In alternativa si suggerisce di normare la possibilità di approvigionarsi di servizi opzionali di backup e Disaster recovery con i relativi SLI dei servizi
Monitoring e disponibilità Log (RIP7-RO11 e CL4)
IL NIST definisce l’”on-.demand self-service” come una delle caratteristiche distintive del paradigma del cloud computing. Su tale base Il CSP fornisce a catalogo strumenti per il monitoring delle risorse che il cliente può acquisire in modalità self-service e su richiesta e di cui avrà la responsabilità della gestione. Inoltre il CSP rende disponibili a portale dati sugli accessi, sul deploy delle risorse, sulle API.
A rinforzo del concetto di self-service il Cliente ha privilegi di tipo “root” sui propri server; questo permette al Cliente, in caso sia necessario, di implementare i propri strumenti di logging/monitoring.
In conclusione il logging per le risorse acquisite è responsabilità del cliente per tale motivo è responsabilità del cliente prevedere una soluzione per il mantenimento dei log durante tutte le fasi del servizio, inclusa quella di phase out.
Si consiglia quindi di eliminare lo SLI oppure di correlarlo alla disponibilità di un servizio opzionale Monitoring che includa la raccolta e la gestione dei dati di Log. La clausola contrattuale CL4 andrebbe eliminata/modificata in accordo
Migrazione dei Dati verso un altro gestore (RIP8)
L’affermazione che “Deve essere sempre possibile la migrazione dei dati del servizio verso un altro Fornitore Cloud” risulta fuorviante. Infatti un CSP non può conoscere i formati necessari all’ambiente Target. Un CSP può unicamente garantire l’aderenza dei dati ai principali standard di mercato in merito all’export dei dati.
Si consiglia quindi di riformulare il requisito richiedendo “la disponibilità all’export dei dati secondo i principali standard di mercato”.
RPE1: si richiede se il requisito possa essere riformulato in forma di SLA. Eventi catastrofici e non prevedibili a priori possono, seppure con probabilità molto bassa, rendere indisponibili interi servizi.
RPE2: sebbene il cloud provider si sforzi al massimo per offrire tempi risposte bassi, ci sono componenti che non sono prevedibili a priori e non dipendono dal cloud provider stesso (latenza/congestione della rete Internet, latenza introdotta dall’architettura applicativa etc). Si richiede di rivalutare la presenza del requisito “massimo tempo di risposta”.
RPE3: si applica la medesima osservazione di cui sopra, il massimo tempo di reboot potrebbe essere indefinito nel caso di eventi imprevedibili o catastrofici.
RPE4: il packet loss non dipende solo dal cloud provider, ma alla rete che separa il cliente dal Cloud provider, che non ricade sotto il controllo del Cloud Provider stesso. Il Cloud Provider può difficilmente determinare un valore massimo o medio. Stessa considerazione vale per latenza e jitter (variazione di banda)
RPE5: i servizi di storage hanno normalmente un valore si SLA e durabilità al fine di indicare l’affidabilità media del servizio. Valori come latenza che separa storage dalla risorsa compute dipende fortemente da fattori applicativi e dalla dislocazione delle risorse stesse. Il max restore time dipende dalla catastroficità dell’evento che ha causato il downtime, ed è difficilmente determinabile e/o garantibile a priori
RPE6: tempi massimi di risposta/ripristino potrebbero non essere garantibili in presenza di situazioni catastrofiche. Il cloud provider si impegna sempre e comunque a fornire una risposta il più veloce ed efficace possibile