Risposta. Si conferma 1119 All. 15 - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica QUESITO: DOMANDA: Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri par. 17.1 QUESITO: In riferimento al requisito migliorativo R9 si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Region.
Appears in 3 contracts
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud, Accordo Quadro Per La Fornitura Di Servizi Cloud, Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Non si conferma. Si conferma 1119 veda inoltre risposta al chiarimento XX 0000. 1098 All. 15 16A - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica QUESITO: DOMANDA: Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri par. 17.1 tecnico speciale Lotto 1_NEW QUESITO: In riferimento alle modifiche del paragrafo 3 del Capitolato tecnico speciale Lotto 1 e alla risposta al requisito migliorativo R9 quesito con identificativo 1012, si chiede alla SA di confermare che tale requisito sia soddisfatto per la comprova di ciascuno dei requisiti indicati è sufficiente esibire la seguente documentazione: 1. R2a: Riferimento alla documentazione del CSP che evince la presenza di Cloud Regions nelle aree offerte 2. R2b: Dichiarazione del CSP che dia evidenza dell’area (non necessariamente minima) contenente tutti i DC della Reaion, per esempio “Tutti i DC della Region italiana sono presenti nel raggio di 50 Km dal centro della città di Roma” 3. R1a: Riferimento alla documentazione del CSP che attesti il numero di AZ presenti per ciascuna Region presente nell’offerta 4. R1b: Dichiarazione del CSP che attesti il numero di DC disponibili per ogni Region e attestazione ai sensi del DPR 445/200 e smi che i DC offerti siano presenti nell’infrastruttura cloud qualificata da AgID. RISPOSTA: In relazione ai punti 1,3 e 4 si conferma. In relazione al punto 2, e quindi al criterio R2b, è richiesto che la documentazione presentata dimostri opportunamente quanto definito dal criterio ossia "misurata la distanza tra tutte le AZ di una Region con tutte le AZ di tutte le altre Region, non esistono misurazioni inferiori ai 150 Km". 1099 All. 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1_NEW" e risposte alle domande di chiarimento 72, 80, 410 e 414 QUESITO: All. 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1_NEW" e le risposte alle domande di chiarimento 72, 80, 410 e 414 riportano che per i servizi di Database, Containers e Application Platform “oltre il costo dei singoli servizi/istanza sono da fatturare in aggiunta anche il costo delle risorse computazionali e di storage”.Considerato che i suddetti servizi rientrano in una definizione di servizio PaaS - in linea con quanto richiesto nel capitolato – e del fatto che i cloud provider pubblici prevedono per tali servizi la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoriaistanze con caratteristiche computazionali predefinite, si chiede di chiarire confermare:1. che il motivo per cui il disco di boot riferimento alle risorse computazionali utilizzate (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VMeg. CPU, RAM, storage, …) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità da considerarsi applicabile unicamente in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regionconsuntivazione.
Appears in 3 contracts
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud, Accordo Quadro Per La Fornitura Di Servizi Cloud, Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si conferma 1119 AllNon si conferma. 15 - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica QUESITO: DOMANDA: Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda inoltre risposta al chiarimento ID 1075 1121 940 942 Allegato 16A - Capitolato d'Oneri par. 17.1 QUESITO: In riferimento al requisito migliorativo R9 Tecnico Speciale LOTTO 1 si chiede di confermare che tale requisito sia soddisfatto con nel caso in cui siano offerte Region composte da una singola Availability Zone distribuita tra due o più Data Center, questi non debbano rispettare la disponibilità dell'OS template distanza minima di 2,5 Km anche nella Console Nativa del CSP e consapevolezza che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalitàun’Amministrazione Contraente, per garantire un pieno restore il tramite della VM CMP, può esclusivamente scegliere la Region e l’Availability Zone in caso di completo failure di una AZcui attivare uno dei servizi richiesti ma non può assolutamente scegliere il Data Center in cui attivarlo oppure spostarlo. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni conferma 943 Capitolato tecnico speciale Lotto 1_NEW-Par.2.2; Errata corrige n 2 e nello stesso tempo consente Chiarimenti – chiarimento n. 389 e 155 In riferimento: • alla definizione della Region del Capitolato Tecnico, in cui la Region viene definita come “Insieme di Data Center che costituisce una più ampia partecipazione rispetto zona geografica ben definita e completamente isolata da altre Region”; • alla versione pubblicata definizione della AZ del Capitolato Tecnico, in fase iniziale facilmente verificabile con l’eliminazione cui una Availability Zone viene definita come “una partizione dell’infrastruttura del requisito minimo relativo CSP, costituita da uno o più Data Center, interconnessa ad altre AZ tramite una rete ad elevata larghezza di banda e bassa latenza”; • alla distanza tra le AZ.. Inoltrerisposta fornita al chiarimento ID 389, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione cui si conferma che ciascuna “Region” debba comprendere una o più “Availability zone”; • alla procedura di gara. 1125 Capitolato d'Oneri NEW e risposta fornita al quesito ID 1012 QUESITO155, come di seguito riportato: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto Per Region si identifica un insieme di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer zone interconnesse con una rete a bassa latenza. Per Availability zone, si intende un insieme di astrazione e disaccoppiamento dal layer fisico uno o più datacenter interconnessi con una rete a bassissima latenza (Data Center<1ms). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 Il vincolo geografico richiesto per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà Region è che la stessa non sia fisicamente collocata in diverse nazioni europee. Non è escluso che all'interno della stessa nazione ci siano più Region. Al fine di eliminare una interruzione di servizio possibile confusione ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) incertezza nelle diverse definizioni che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e sono succedute si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Region.che:
Appears in 2 contracts
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas, Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si Non si conferma 1119 All. 15 - ID 2213 - Gara Public Cloud - Schema 923 Capitolato Tecnico Speciale Lotto 1 Nel Capitolato Tecnico Speciale si afferma che “Ogni Fornitore dovrà, in Relazione tecnica, inserire una tabella riassuntiva dei servizi/prodotti (“Tabella A”) presenti nel loro listino pubblico utilizzati per soddisfare i requisiti di Offerta Tecnica QUESITO: DOMANDA: gara per i servizi richiesti per ogni categoria (es., lista prodotti/servizi per la categoria COMPUTE)” Si chiede alla SA di chiarire come indicare se è possibile inserire in Tabella A i servizi “IP pubblico statico” e “Traffico out-bound”, non essendo essi associati a specifici servizi qualificabili secondo quanto stabilito nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare Circolare n. 2 del 9 aprile 2018 “Criteri per la tipologia qualificazione dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri par. 17.1 QUESITO: In riferimento al requisito migliorativo R9 si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e per la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione EuropeaPA” RISPOSTA: Non si confermaE' possibile indicare il medesimo servizio già indicato per un'altra categoria. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come Se ad esempio incendionell'ambito della categoria Compute il Concorrente ha indicato il "Servizio VM", allagamentoqualora per soddisfare i requisiti della categoria Network le Amministrazioni attiveranno IP pubblici e usufruiranno del traffico outbound tramite il medesimo "Servizio VM", etc (annoverati tipicamente allora il Concorrente dovrà indicare in ambito tabella A per entrambe le categorie il "Servizio VM". 924 Allegato 16a - Appendice 1 Al Capitolato Tecnico Speciale Lotto 1 Indicatori Di Qualità Del Lotto 1 Nell’Appendice 1 al Capitolato Tecnico Speciale Lotto 1- Indicatori di Disaster Recovery). Quindi l’affermazione qualità Lotto 1 – si dice, relativamente all’indicatore di qualità RSER – Impegni Assunti in Offerta Tecnica - che “Data Center diversi proteggono L’indicatore di qualità verifica il numero di impegni assunti dal Fornitore in offerta tecnica, afferenti obbligazioni contrattuali non adempiute nei tempi e/o nei modi rappresentati nel Contratto esecutivo e relativi allegati e/o tracciati sui Piani di lavoro, siano esse presidiate da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre specifici indicatori o non presidiate.” Si chiede alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi SA di confermare che per ottenere i punteggi numero di impegni presi ci si riferisca esclusivamente ai criteri migliorativi R2 il provider debba permetteredi cui al Capitolato D’Oneri, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regional par. 17.1.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Non si conferma. Come già specificato nelle precedenti risposte a chiarimenti analoghi, i Concorrenti sono tutti chiamati a rispondere nelle metriche definite costruendo opportuni business case. Premesso che le reali metriche di costo del Sistemi Operativo (SO) "Licenced" (di fatto "Windows Server") in cloud sono facilmente verificabili presso i listini pubblici dei principali cloud vendor e che tali metriche prevedono sempre un costo orario del SO basato sulla tipologia di istanza compute (VM) su cui viene ad essere installato ed eseguito, e quindi generalemente sul numero di vCPU che caratterizzano l'istanza della VM. 865 Capitolato tecnico speciale lotto 1 Si conferma 1119 chiede quindi nuovamente alla Stazione Appaltante di chiarire come intende risolvere il problema di incompatibilità tra le metriche definite nel capitolato (istanza/ora) con quelle di mercato (vCPU/ora) per mettere i partecipanti nelle condizioni di quotare le voci relative (Sistema Operativo licensed). In particolare si chiede quindi di confermare la possibilità di quotare una istanza di taglio minimo definito (es. 2vCPU) lasciando all'ente appaltante la facoltà di richiedere, e quindi istanziare, multipli del taglio minimo. RISPOSTA: Non si conferma. Come già specificato nelle precedenti risposte a chiarimenti analoghi, i Concorrenti sono tutti chiamati a rispondere nelle metriche definite costruendo opportuni business case. Con la risposta alla domanda # 610 (di seguito riportata) viene ulteriormente modificato il requisito introdotto con la risposta # 391. Tale requisito cambia quindi da: "La distanza minima per ogni AZ è pari almeno a 2,5 Km" a: "Per ogni AZ di ogni Region esiste sempre un Data Center distante più di 2,5 Km appartenente ad altre AZ della stessa Region" 866 Capitolato tecnico speciale lotto 1 Domanda # 610 "In riferimento a quanto riportato nel documento All. 15 A - ID 2213 - Gara Public Cloud - Schema Capitolato tecnico speciale Lotto NEW nel paragrafo 2.2. Requisiti Generali, considerando che un'Availability Zone è intesa come Partizione dell'infrastruttura del CSP, costituita da uno o più Data Center (Par. 1.1 dello stesso documento), si chiede di Offerta Tecnica QUESITO: DOMANDA: confermare che il requisito è soddisfatto se per ogni Availability Zone di ogni Region parte dell'offerta, esiste sempre un Data Center distante più di 2.5 Km da un Data Center appartenente ad altre Availability Zones della stessa Region. " Risposta Si conferma. Il risultato è ovviamente totalmente differente. In questa seconda formulazione è di fatto sufficiente che, dato un AZ, esiste almeno un altro AZ della stessa region distante piu di 2,5Km dal primo. Si potrebbero avere ad esempio AZ1 e AZ2 distanti 1Km, AZ1 e AZ3 distanti 2,6Km e AZ2 e AZ3 distanti 2,9Km soddisfacendo il requisito cosi come riformulato e confermato al 2^ turno ma non soddisfacendo la formulazione precedente. Allo stesso tempo però il Capitolato Tecnico Speciale per il Lotto 1 pubblicato l'8 Aprile e quindi "teoricamente" aggiornato alle risposte fornite recita (al paragrafo 2.2): "Ogni Region sarà composta da una o più Availability Zone ciascuna ad una distanza minima dall’altra pari a 2,5km.". Quindi in linea con la risposta # 391 ma in palese contraddizione con quanto confermato alla domanda # 610. Si chiede quindi di indicare se è possibile inserire confermare quanto riportato nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziatonuova versione del capitolato tecnico speciale Lotto 1. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 940. 867 Capitolato d'Oneri partecnico speciale lotto 1 A seguito del secondo turno di risposte, il requisito minimo che prevedeva una specifica frequenza di elaborazione delle CPU per le VM appartenenti a ciascun scaglione di tipo mid, high e vhigh, viene alterato sulla base di quanto "suggerito" nella domanda # 836 dove si chiede, ai fini della rispondenza al capitolato, di escludere la capacità dei processori moderni di "gestire" in modo intelligente una CPU. 17.1 QUESITO: In riferimento Queste capacità native dei processori, oltre a garantire comunque la frequenza minima richiesta dal capitolato, rendono possibile la riduzione della stessa frequenza, quando non richiesta dai carichi di lavoro in corso, al fine di conseguire risparmi energetici, maggiore efficienza, minore dissipazione di calore e quindi una riduzione dell’impatto ambientale dei Data Centers. La modifica al requisito migliorativo R9 si suggerita e poi avvallata, oltre a non essere giustificata in quanto non comporta alcun beneficio per l'Amministrazione, risulta essere non coerente con quanto definito nella strategia di innovazione “Italia 2025” che parla di “innovazione nel rispetto della sostenibilità ambientale” e risulta penalizzante per chi investe in tema di risparmio energetico. Si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa che, per rispettare il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta delle frequenze minime previste per le VM mid, high e vhigh, sia ammissibile fornire processori che, oltre a garantire comunque la frequenza minima richiesta dal capitolato, abbiano la capacità, tramite una gestione intelligente, di ridurre la frequenza di clock, quando non richiesta dai carichi di lavoro in corso, al quesito # 1048fine di conseguire risparmi energetici, dove si afferma e ribadisce che la replica dei dischi maggiore efficienza, minore dissipazione di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (calore e quindi con replica una riduzione dell’impatto ambientale dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla RegionCenters.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Non si conferma. Come già specificato nelle precedenti risposte a chiarimenti analoghi, i Concorrenti sono tutti chiamati a rispondere nelle metriche definite costruendo opportuni business case. 865 Capitolato tecnico speciale lotto 1 Premesso che le reali metriche di costo del Sistemi Operativo (SO) "Licenced" (di fatto "Windows Server") in cloud sono facilmente verificabili presso i listini pubblici dei principali cloud vendor e che tali metriche prevedono sempre un costo orario del SO basato sulla tipologia di istanza compute (VM) su cui viene ad essere installato ed eseguito, e quindi generalemente sul numero di vCPU che caratterizzano l'istanza della VM. Si conferma 1119 chiede quindi nuovamente alla Stazione Appaltante di chiarire come intende risolvere il problema di incompatibilità tra le metriche definite nel capitolato (istanza/ora) con quelle di mercato (vCPU/ora) per mettere i partecipanti nelle condizioni di quotare le voci relative (Sistema Operativo licensed). In particolare si chiede quindi di confermare la possibilità di quotare una istanza di taglio minimo definito (es. 2vCPU) lasciando all'ente appaltante la facoltà di richiedere, e quindi istanziare, multipli del taglio minimo. RISPOSTA: Non si conferma. Come già specificato nelle precedenti risposte a chiarimenti analoghi, i Concorrenti sono tutti chiamati a rispondere nelle metriche definite costruendo opportuni business case. 866 Capitolato tecnico speciale lotto 1 Con la risposta alla domanda # 610 (di seguito riportata) viene ulteriormente modificato il requisito introdotto con la risposta # 391. Tale requisito cambia quindi da: "La distanza minima per ogni AZ è pari almeno a 2,5 Km" a: "Per ogni AZ di ogni Region esiste sempre un Data Center distante più di 2,5 Km appartenente ad altre AZ della stessa Region" Domanda # 610 "In riferimento a quanto riportato nel documento All. 15 A - ID 2213 - Gara Public Cloud - Schema Capitolato tecnico speciale Lotto NEW nel paragrafo 2.2. Requisiti Generali, considerando che un'Availability Zone è intesa come Partizione dell'infrastruttura del CSP, costituita da uno o più Data Center (Par. 1.1 dello stesso documento), si chiede di Offerta Tecnica QUESITO: DOMANDA: confermare che il requisito è soddisfatto se per ogni Availability Zone di ogni Region parte dell'offerta, esiste sempre un Data Center distante più di 2.5 Km da un Data Center appartenente ad altre Availability Zones della stessa Region. " Risposta Si conferma. Il risultato è ovviamente totalmente differente. In questa seconda formulazione è di fatto sufficiente che, dato un AZ, esiste almeno un altro AZ della stessa region distante piu di 2,5Km dal primo. Si potrebbero avere ad esempio AZ1 e AZ2 distanti 1Km, AZ1 e AZ3 distanti 2,6Km e AZ2 e AZ3 distanti 2,9Km soddisfacendo il requisito cosi come riformulato e confermato al 2^ turno ma non soddisfacendo la formulazione precedente. Allo stesso tempo però il Capitolato Tecnico Speciale per il Lotto 1 pubblicato l'8 Aprile e quindi "teoricamente" aggiornato alle risposte fornite recita (al paragrafo 2.2): "Ogni Region sarà composta da una o più Availability Zone ciascuna ad una distanza minima dall’altra pari a 2,5km.". Quindi in linea con la risposta # 391 ma in palese contraddizione con quanto confermato alla domanda # 610. Si chiede quindi di indicare se è possibile inserire confermare quanto riportato nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziatonuova versione del capitolato tecnico speciale Lotto 1. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 940. 867 Capitolato d'Oneri partecnico speciale lotto 1 A seguito del secondo turno di risposte, il requisito minimo che prevedeva una specifica frequenza di elaborazione delle CPU per le VM appartenenti a ciascun scaglione di tipo mid, high e vhigh, viene alterato sulla base di quanto "suggerito" nella domanda # 836 dove si chiede, ai fini della rispondenza al capitolato, di escludere la capacità dei processori moderni di "gestire" in modo intelligente una CPU. 17.1 QUESITO: In riferimento Queste capacità native dei processori, oltre a garantire comunque la frequenza minima richiesta dal capitolato, rendono possibile la riduzione della stessa frequenza, quando non richiesta dai carichi di lavoro in corso, al fine di conseguire risparmi energetici, maggiore efficienza, minore dissipazione di calore e quindi una riduzione dell’impatto ambientale dei Data Centers. La modifica al requisito migliorativo R9 si suggerita e poi avvallata, oltre a non essere giustificata in quanto non comporta alcun beneficio per l'Amministrazione, risulta essere non coerente con quanto definito nella strategia di innovazione “Italia 2025” che parla di “innovazione nel rispetto della sostenibilità ambientale” e risulta penalizzante per chi investe in tema di risparmio energetico. Si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa che, per rispettare il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta delle frequenze minime previste per le VM mid, high e vhigh, sia ammissibile fornire processori che, oltre a garantire comunque la frequenza minima richiesta dal capitolato, abbiano la capacità, tramite una gestione intelligente, di ridurre la frequenza di clock, quando non richiesta dai carichi di lavoro in corso, al quesito # 1048fine di conseguire risparmi energetici, dove si afferma e ribadisce che la replica dei dischi maggiore efficienza, minore dissipazione di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (calore e quindi con replica una riduzione dell’impatto ambientale dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla RegionCenters.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si conferma 1119 Allveda la risposta al chiarimento ID 940. 15 - 984 II TRANCHE Chiarimenti e Errata corrige n. 3.pdf – Lotto 1 – ID 2213 - Gara Public Cloud - Schema 752 e ID 673 Alle risposte ai quesiti ID 752 e ID 673 si legge rispettivamente: DOMANDA 752: Posto che: 1. nel Capitolato d'Oneri (pagina 10), l’unità di Offerta Tecnica QUESITOmisura per il servizio di Monitoring riporta: DOMANDA" 1000 metriche monitorate/ora". 2. nella risposta alla domanda di chiarimento ID 79 è riportato: "La base d'asta si riferisce a 1000 metriche monitorate al mese". si chiede di confermare che quanto riportato nel capitolato d'oneri sia un refuso e che l'unità di misura corretta del servizio di Monitoring sia " 1000 metriche monitorate/mese". RISPOSTA: Si conferma. DOMANDA 673: In Xxxxxx Xxxxxxx X0 e chiarimenti pag. 22 domanda ID 78 per quanto concerne i servizi di monitoring si parla di 1000 metriche / mese mentre nel Capitolato d'Oneri new §3 pag 11 Tabella prezzi unitari e quantità relative al Lotto n. 1. si fa riferimento a 1000 metriche /ora come confermato anche dalla risposta ID 506 contenuta in Errata Corrige N2 e chiarimenti pag.152. Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo chiarire quale sia la metrica da considerare e da dettagliare e cosa si intenda per metriche nell'unità di pagine della Relazione Tecnicatempo. RISPOSTA: Il Capitolato d'Oneri riporta la metrica corretta. Si faccia riferimento a metriche/ora. Si chiede di chiarire quanto segue: Con riferimento alla risposta alla domanda di chiarimento 752 e la risposta alla domanda N. 673 si chiede di chiarire quale sia la metrica corretta da considerare per il servizio di monitoring. RISPOSTA: Si conferma 1120 quanto previsto nel Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in d'oneri. La metrica è per tanto 1000 metriche/ora. 985 II TRANCHE Chiarimenti e Errata corrige n. 3.pdf – Lotto 1 – ID 677 Alla risposta al quesito # 1034 la metrica da adottare ID 677 si legge: DOMANDA: Nel Capitolato tecnico speciale Lotto 1 per la tipologia le categorie Containers, Databases ed Application Platform, relativamente alla consuntivazione, viene indicato che si terrà conto, oltre che del consumo dei servizi indicati anche del consumo di altre risorse (compute, sistema operativo, storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSPseconda dei casi) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla garadefinendo, nella sostanza, “gruppi di servizi collegati” mandatoriamente. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede alla SA di rettificare specificare se, nel caso di affidamento senza la base d'asta alla luce riapertura del confronto competitivo, anche il configuratore terrà conto di quanto evidenziatotali “gruppi di servizi collegati” (recependo i relativi punti tecnici ed economici) impedendo l’acquisto di servizi singoli facenti parte dei suddetti gruppi. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri par. 17.1 QUESITO: In riferimento al requisito migliorativo R9 Qualora non si confermasse si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa specificare le logiche del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9configuratore per tali servizi. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura Il configuratore terrà conto esclusivamente del Piano dei requisiti minimi garantisce fabbisogni definito dalle Amministrazioni anche con il supporto del fornitore dei lotti 2-6. Si chiede di chiarire quanto segue: Premesso che nel Lotto 1 non si applica il "Piano dei Fabbisogni" e che le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione Stazioni Appaltanti potrebbero procedere ad acquistare i servizi del Lotto 1 in autonomia rispetto alle scelte strategiche operate utilizzando i lotti 2-6, con riferimento alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri domanda di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e chiarimento 677 si chiede quindi di chiarire quale sarà la logica del configuratore dal momento che i servizi di Containers, Application Platform e Databases sono strettamente vincolati ai servizi compute. Specificamente si chiede di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettereall'interno del configuratore saranno implementati degli automatismi che dimensionino correttamente le risorse 'compute' necessarie al funzionamento dei servizi Containers, in fase Databases Application Platform. Esempio - Il configuratore dovrà evitare che una PA acquisti un numero di deploy/provisioning istanze DB relazionali pari a N e un numero di un servizio, la scelta esplicita risorse Compute < N e quindi non sufficienti ad ospitare tali istanze DB. RISPOSTA: Il configuratore non terrà conto di queste logiche. Il configuratore opererà sui fabbisogni espressi dall'Amministrazione calcolando una classifica come descritto nel capitolato d'oneri. Sarà responsabilità dell'Amministrazione definire tali fabbisogni affinchè siano coerenti e non violino le regole di utilizzo del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regionrisorse come descritto nel Capitolato tecnico. 986 Capitolato d’Oneri par.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si conferma. 897 requisito REQ_NRDW_05 (riportato nel Capitolato Tecnico Speciale -Lotto 1, Pag.13, Par.2.9) In riferimento al requisito REQ_NRDW_05 (riportato nel Capitolato Tecnico Speciale - Lotto 1, Pag.13, Par.2.9) e alla risposta fornita al quesito 827, si chiede di confermare che il requisito riportato possa ritenersi soddisfatto se il meccanismo di alta affidabilità viene implementato tramite una combinazione di nodi active-active e/o active-passive anche nella stessa Region. RISPOSTA: Si conferma 1119 AllIn riferimento al requisito R6 riportato nella Tabella dei criteri discrezionali (D) e tabellari (T) di valutazione dell’offerta tecnica :“Possibilità di istanziare Virtual machine custom (free CPU free RAM) nei limiti delle massime dimensioni disponibili”, riportato nel par. 15 - “16.1 Criteri di valutazione dell’offerta tecnica” del documento “ID 2213 - Gara Public Cloud - Schema CAPITOLATO D'ONERI” si chiede conferma:a) Che la granularità di Offerta Tecnica QUESITO: DOMANDA: Si chiede scelta delle CPU 898 Requisito R6 riportato nella Tabella dei criteri discrezionali (D) e tabellari (T) di indicare se è possibile inserire valutazione dell’offerta tecnica deve essere per multipli di due (come riportato nella relazione tecnica, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 817)b) Che la metrica da adottare per la tipologia dei servizi granularità minima di storage è stata modificata da scelta delle RAM deve essere pari almeno ad 1 GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP. c) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione Che dovrà essere possibile richiedere liberamente qualsiasi combinazione possibile tra i prezzi medi numero di mercato CPU e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio GB di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri par. 17.1 QUESITO: In riferimento al requisito migliorativo R9 si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP RAM nei rispettivi range minimi e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto massimi previsti da capitolato. RISPOSTA: Ogni CSP In relazione al punto a), come specificato nel Capitolato tecnico speciale Lotto 1, si conferma. In relazione al punto B, la possibilità di richiedere RAM con granularità minima pari ad 1GB soddisfa il requisito migliorativo. Tuttavia non è libero escluso che il Concorrente possa offrire anche la possibilità di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblicoscegliere RAM con granularità inferiore al GB. 1124 Capitolato d'Oneri NEW QUESITOIn quest'ultimo caso la consuntivazione sarà ovviamente riproporzionata all'effettivo consumo. In relazione al punto c), si conferma. Documento “ID 2213 - II TRANCHE Chiarimenti e Errata corrige n. 3” e Risposte alle Domanda 633 e 817. Con riferimento ai chiarimenti sui requisiti migliorativi R10 (Domanda 633) e R6 (Domanda 817) dell’ambito Compute DOMANDA: Si chiede conferma che, nel caso di ripristinare offerta che soddisfi i criteri requisiti migliorativi R6 e R10, le funzionalità necessarie per soddisfare tali requisiti migliorativi, pur essendo funzionalità disponibili senza onere addizionale a tutte le Amministrazioni richiedenti, 899 non debbano essere necessariamente attivate per quelle Amministrazioni che non abbiano necessità di valutazione relativi ad Availability zones (R1) , Regions (R2) utilizzare le caratteristiche indicate ai requisiti R6 e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” R10? RISPOSTA: Non si conferma. L'attuale struttura dei I requisiti minimi garantisce le esigenze delle Amministrazioni R6 ed R10 influenzeranno la classifica generata dal configuratore e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider conseguenza la scelta del Data CenterConcorrente/CSP da parte dell'Amministrazione. Il ProviderPer cui, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione se dichiarate, dovranno essere sempre attivate e disponibili in qualsiasi momento. Lotto 1 (App chiarimento n. 732 – Considerato 1) che: nel capitolato tecnico speciale si afferma che “per ogni DB si pensava essere stimano 5000 transazioni in alta affidabilitàscrittura ed altrettante in lettura l’ora” ed al chiarimento 192 viene affermato che “le amministrazioni ordineranno tante istanze/ora tenendo conto del numero di transazioni previste” per il servizio “NoSQL DB” 2) al chiarimento 732 si conferma che "nel caso ad esempio di un Database NON Relazionale che faccia effettivamente 20.500 transazioni/ora tra lettura e scrittura, il Fornitore possa addebitare alla PA l'equivalente importo pari a 5 istanze/ora. Quindi se 900 non ci risulta congruente quanto confermato nel chiarimento 756 dove si riporta che per "un Database NON Relazionale il cliente non ha parametro su cui riproporzionare la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si consuntivazione sia quello più elevato. Si chiede quindi pertanto di confermare che quanto riportato nel chiarimento n. 756 sia un refuso e che il numero di istanze di NoSQL database venga calcolato come effettivamente riportato nel chiarimento n. 732. RISPOSTA: Si conferma quanto indicato nel chiarimento 732. Si evidenzia tuttavia che la risposta data al chiarimento 756 mira a chiarire quei casi in cui vengano effettuate solo ad esempio operazioni di lettura, infatti, qualora un Amministrazione effettui in un'ora 20.500 transazioni di sola lettura, il parametro più alto (in questo caso la lettura) influenzerà direttamente la fatturazione portando a 5 istanze il costo da fatturare. Con riferimento alla risposta al chiarimento 677 “Il configuratore terrà conto esclusivamente del Piano dei fabbisogni definito dalle Amministrazioni anche con il supporto del fornitore dei lotti 2-6.” e tenuto conto anche dei chiarimenti 733, 809, 810 e 861 DOMANDA: Documento “ID 2213 - II TRANCHE Nell’ipotesi di una Amministrazione che desideri acquisire unicamente i servizi di Database Non Relazionale (“Data Warehouse DB” oppure “NoSQL DB”), nel caso in cui un primo fornitore “CSP 1” decida di adottare una logica di consuntivazione con componenti compute e storage pari a 0 nella relativa fatturazione, mentre un secondo fornitore “CSP Chiarimenti e 2” decida di adottare una logica di consuntivazione con componenti compute e storage 901 Errata corrige n. diverse da 0 nella relativa fatturazione, si chiede di confermare che in entrambi i casi per ottenere 3” e Xxxxxxxx alle il computo del punteggio tecnico sia di “CSP 1” che di “CSP 2” da parte del configuratore, Domande 677, 733, 809, 810 e 861. saranno sommati i punteggi migliorativi R2 tecnici relativi alle categorie “Compute”, “Storage” e “Database non relazionale". RISPOSTA: Relativamente al servizio gestito NoSQL, si conferma quanto previsto in risposta al chiarimento ID 192 e 733, pertanto il provider debba permettereCapitolato tecnico speciale Lotto 1 viene allineato a tale dichiarazione. Relativamente al funzionamento del configuratore, qualora l'amministrazione acquisti ad esempio esclusivamente DB NoSQL e storage, il configuratore computerà i punteggi tecnici della Categoria Provider, della Categoria Storage e della Categoria DB Non relazionale. Con riferimento alla risposta al chiarimento 677 “Il configuratore terrà conto esclusivamente del Piano dei fabbisogni definito dalle Amministrazioni anche con il supporto del fornitore dei lotti 2-6.” e tenuto conto anche dei chiarimenti 733, 809, 810 e 861 DOMANDA: Nell’ipotesi di una Amministrazione che desideri acquisire unicamente i servizi della categoria “Application Platform”, nel caso in fase cui un primo fornitore “CSP 1” decida di deploy/provisioning adottare una logica di consuntivazione con componenti compute e storage pari a 0 nella relativa fatturazione, mentre un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Region.secondo fornitore “CSP 2” decida di adottare una logica
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si In relazione al punto a) si conferma; In relazione al punto b), considerando le peculiarità della fornitura di logica a consumo " on demand", è evidente come il valore puntuale ad esempio della risorsa VM (tra l'altro soggetta a logiche di scale-up o scale-down di risorse nel corso di esecuzione contrattuale) non possa essere presente in un documento statico come il Contratto Esecutivo o l'ordine di acquisto; infatti sarà calcolato sulla base degli indicatori di qualità che riportano tale livello di dettaglio e la consuntivazione delle risorse come definito nel Capitolato tecnico Speciale. E' altresì evidente che il contratto prevederà dunque l'indicazione del valore massimo delle penali cui può essere soggetto il fornitore, ossia il 10% dell'importo contrattuale ipotizzando che tutte le risorse maturino la massima penale applicabile. 947 II Tranche Chiarimenti e Errata Corrige n. 3 – Chiarimenti ID 599 ed ID 817; Allegato 16A – Capitolato Tecnico Speciale Lotto 1, Paragrafo 2.3 Categoria COMPUTE Nella risposta al chiarimento ID 599 si afferma che “Qualora il fornitore dichiari il requisito R6 [ovvero: Possibilità di istanziare Virtual machine custom (free CPU free RAM) nei limiti delle massime dimensioni disponibili], le Amministrazioni dovranno essere in grado di istanziare VM di qualsiasi taglio nei limiti del xxxxxxx xxxxxxxxx previsto nel catalogo Compute”. Nella risposta al chiarimento ID 817, che fa riferimento sia al precedente chiarimento ID 575 che al requisito R6, si conferma 1119 Allche il requisito di allocazione di vCPU come numero intero arbitrario decade, e si considera un incremento esclusivamente pari di vCPU fino al massimo numero di core richiesto e disponibile per una VM. 15 - ID 2213 - Gara Public Cloud - Schema Tale risposta è anche recepita nella revisione del Capitolato Tecnico Speciale Lotto 1-new a pag. 9 dove si afferma che “Per quanto [riguarda] l’allocazione delle risorse CPU, anche qualora maturato il punteggio migliorativo di Offerta Tecnica QUESITOcui al punteggio R10 [ovvero: DOMANDA: Possibilità di modificare la configurazione della virtual machine a caldo], le stesse potranno avvenire per multipli di 2.” Si chiede quindi di indicare se confermare che il Concorrente non è possibile inserire nella relazione tecnicatenuto ad offrire VM custom con tagli di vCPU dispari, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnicaanche qualora dichiari il requisito R6. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 948 II Tranche Chiarimenti e Errata Corrige n. 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato – Chiarimento ID 733 e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda ID 810 Nella risposta al chiarimento ID 1075 1121 733 si conferma che per il servizio di Database non relazionale di tipologia NoSQL Database, a differenza dei Database relazionali, il costo totale del servizio non deve prevedere la consuntivazione dei costi relativi alla categoria compute e storage, ma l'istanza sarà consuntivata sul numero di transazioni come indicato nella domanda ID 192. Tale risposta sembra in contrasto con quella fornita al chiarimento ID 810, dove si conferma che, anche nel caso di DB non relazionale di tipo noSQL-DB il servizio verrà rendicontato dal Fornitore alle PA sommando le componenti di prezzo dovute a: 1) prezzo offerto al Concorrente Offerente nella riga “Database NON relazionale - noSqL DB”; 2) prezzi offerti dal Concorrente Offerente nelle righe “Compute STD” di tipo CPU, RAM e Sistema Operativo (per i tipi di VM usati dal servizio DB NON relazionale-noSQL DB); 3) prezzo offerto dal Concorrente Offerente nelle righe “Storage” (per lo storage usato dal servizio DB non relazionale - noSQL DB). Si chiede di chiarire se la consuntivazione del servizio DB NO SQL debba avvenire sul numero di transazioni oppure sulle componenti indicate al chiarimento ID 810. RISPOSTA: Il chiarimento ID 801 è un refuso. Si veda il chiarimento ID 901. Capitolato d'Oneri par. 17.1 QUESITO: d’Oneri, In riferimento al alla risposta di chiarimento ID 734, in cui, per il requisito migliorativo R9 R9, si chiarisce che per OS Support si intende l’impiego del relativo template sulla console nativa (o equivalente) del CSP, si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS degli OS template (cfr. requisito R9) nella Console Nativa del CSP console sviluppata e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata messa a disposizione della PA dal Concorrente soddisfa il requisito R9. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZOfferente. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica Il criterio R9 (e quindi i relativi sub-criteri) sono soddisfatti con replica dei dischi di boot non obbligatoria)la disponibilità degli OS template nella console nativa/sviluppata e messa a disposizione della PA dal Concorrente. Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere Si rappresenta la necessità che i servizi offerti per soddisfare la categoria cui afferisce il criterio R9 devono appartenere ad un Appalto Specifico mediante rilancio competitivounico stack ricondubile al CSP/CSP offerto dal Concorrente. Pertantopar. 17.1, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage "pag. Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permettere, in fase di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Region.43 Requisito
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si In relazione al punto a) si conferma; In relazione al punto b), considerando le peculiarità della fornitura di logica a consumo " on demand", è evidente come il valore puntuale ad esempio della risorsa VM (tra l'altro soggetta a logiche di scale-up o scale-down di risorse nel corso di esecuzione contrattuale) non possa essere presente in un documento statico come il Contratto Esecutivo o l'ordine di acquisto; infatti sarà calcolato sulla base degli indicatori di qualità che riportano tale livello di dettaglio e la consuntivazione delle risorse come definito nel Capitolato tecnico Speciale. E' altresì evidente che il contratto prevederà dunque l'indicazione del valore massimo delle penali cui può essere soggetto il fornitore, ossia il 10% dell'importo contrattuale ipotizzando che tutte le risorse maturino la massima penale applicabile. 947 II Tranche Chiarimenti e Errata Corrige n. 3 – Chiarimenti ID 599 ed ID 817; Allegato 16A – Capitolato Tecnico Speciale Lotto 1, Paragrafo 2.3 Categoria COMPUTE Nella risposta al chiarimento ID 599 si afferma che “Qualora il fornitore dichiari il requisito R6 [ovvero: Possibilità di istanziare Virtual machine custom (free CPU free RAM) nei limiti delle massime dimensioni disponibili], le Amministrazioni dovranno essere in grado di istanziare VM di qualsiasi taglio nei limiti del xxxxxxx xxxxxxxxx previsto nel catalogo Compute”. Nella risposta al chiarimento ID 817, che fa riferimento sia al precedente chiarimento ID 575 che al requisito R6, si conferma 1119 Allche il requisito di allocazione di vCPU come numero intero arbitrario decade, e si considera un incremento esclusivamente pari di vCPU fino al massimo numero di core richiesto e disponibile per una VM. 15 - ID 2213 - Gara Public Cloud - Schema Tale risposta è anche recepita nella revisione del Capitolato Tecnico Speciale Lotto 1-new a pag. 9 dove si afferma che “Per quanto [riguarda] l’allocazione delle risorse CPU, anche qualora maturato il punteggio migliorativo di Offerta Tecnica QUESITOcui al punteggio R10 [ovvero: DOMANDA: Possibilità di modificare la configurazione della virtual machine a caldo], le stesse potranno avvenire per multipli di 2.” Si chiede quindi di indicare se confermare che il Concorrente non è possibile inserire nella relazione tecnicatenuto ad offrire VM custom con tagli di vCPU dispari, lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnicaanche qualora dichiari il requisito R6. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 948 II Tranche Chiarimenti e Errata Corrige n. 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato – Chiarimento ID 733 e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziato. RISPOSTA: Si veda ID 810 Nella risposta al chiarimento ID 1075 1121 733 si conferma che per il servizio di Database non relazionale di tipologia NoSQL Database, a differenza dei Database relazionali, il costo totale del servizio non deve prevedere la consuntivazione dei costi relativi alla categoria compute e storage, ma l'istanza sarà consuntivata sul numero di transazioni come indicato nella domanda ID 192. Tale risposta sembra in contrasto con quella fornita al chiarimento ID 810, dove si conferma che, anche nel caso di DB non relazionale di tipo noSQL-DB il servizio verrà rendicontato dal Fornitore alle PA sommando le componenti di prezzo dovute a: 1) prezzo offerto al Concorrente Offerente nella riga “Database NON relazionale - noSqL DB”; 2) prezzi offerti dal Concorrente Offerente nelle righe “Compute STD” di tipo CPU, RAM e Sistema Operativo (per i tipi di VM usati dal servizio DB NON relazionale-noSQL DB); 3) prezzo offerto dal Concorrente Offerente nelle righe “Storage” (per lo storage usato dal servizio DB non relazionale - noSQL DB). Si chiede di chiarire se la consuntivazione del servizio DB NO SQL debba avvenire sul numero di transazioni oppure sulle componenti indicate al chiarimento ID 810. RISPOSTA: Il chiarimento ID 801 è un refuso. Si veda il chiarimento ID 901. 949 Capitolato d'Oneri d’Oneri, par. 17.1 QUESITO: 17.1, pag. 43 Requisito Migliorativo R9 - II Tranche Chiarimenti e Errata Corrige n. 3 – chiarimento ID 734 In riferimento al alla risposta di chiarimento ID 734, in cui, per il requisito migliorativo R9 R9, si chiarisce che per OS Support si intende l’impiego del relativo template sulla console nativa (o equivalente) del CSP, si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS degli OS template (cfr. requisito R9) nella console sviluppata e messa a disposizione della PA dal Concorrente Offerente. RISPOSTA: Il criterio R9 (e quindi i relativi sub-criteri) sono soddisfatti con la disponibilità degli OS template nella Console Nativa console nativa/sviluppata e messa a disposizione della PA dal Concorrente. Si rappresenta la necessità che i servizi offerti per soddisfare la categoria cui afferisce il criterio R9 devono appartenere ad un unico stack ricondubile al CSP/CSP offerto dal Concorrente. 950 Capitolato d’Oneri, par. 17.1, pag. 43, Requisito Migliorativo R9 - II Tranche Chiarimenti e Errata Corrige n. 3 – chiarimento ID 734 Si chiede di confermare, che per la comprova del requisito R9 “OS Support”, per i sistemi operativi Open, sia sufficiente dimostrare la possibilità di rendere disponibile il relativo OS Template aggiornato all’ultima release disponibile nella console nativa (o equivalente) del CSP. RISPOSTA: Xxxxx restando i poteri della Commissione giudicatrice di richiedere quanto opportuno ai fini della comprova dei requisiti, rendere disponibile il Template aggiornato all'ultima release comprova il criterio R9. 951 II Tranche Chiarimenti e Errata Corrige n. 3 – Chiarimenti ID 838 ed ID 821 Con riferimento alla risposta fornita al chiarimento ID 838 e alla luce della risposta fornita al chiarimento ID 821, si chiede di confermare che le attuali modalità di verifica dei requisiti migliorativi relativi ai sistemi operativi offerti (cfr. requisito R9) consistano in una dichiarazione di impegno da parte del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP affermi che i sistemi operativi offerti siano presenti sulla console nativa (o equivalente) del CSP. RISPOSTA: La modalità rappresentata dal Concorrente soddisfa Xxxxx restando i poteri della Commissione giudicatrice di richiedere quanto opportuno ai fini della comprova dei requisiti, una dichiarazioni di impegno ai sensi del DRP 445/2000, che affermi che i sistemi operativi offerti siano presenti sulla console nativa (o equivalente) del CSP, comprova il requisito R9. 1122 Quesito 952 Capitolato Tecnico Speciale -Lotto 1, Par. 2.2, Pag.6 e II Tranche Chiarimenti e Errata Corrige n. 3 – chiarimento ID 1048 QUESITO: 821 In risposta riferimento al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoriachiarimento ID 821, si chiede di chiarire confermare che sia possibile utilizzare servizi IaaS e PaaS di terze parti offerti tramite il motivo per cui il disco Marketplace del CSP e su cui, quest’ultimo, garantisca tutti i requisiti di boot (parte integrante dello storage di una VM gara ed in molti casi anche l’unico disco particolare: qualifica AgID, erogazione sul proprio stack infrastrutturale/applicativo, localizzazione all'interno della VM) non debba essere obbligatoriamente replicatosola Comunità Europea, cosi come gli altri dischi (volumi) di storage SLA e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZsupporto tecnico. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITODOMANDA: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente confermare la possibilità di scegliere su quale AZ distribuire utilizzare servizi IaaS e ridondare i propri workload applicativi PaaS offerti tramite il Marketplace del CSP, laddove si tratti di servizi compresi nel suo listino pubblico e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire il CSP garantisca tutti i requisiti di gara ed in particolare: qualifica AgID, erogazione sul proprio stack infrastrutturale/applicativo, localizzazione all'interno della sola Comunità Europea, SLA e ridondare i propri workload) in maniera esplicitasupporto tecnico. Scenario 1: in fase di provisioning di un servizioSi chiede, il cliente ha la possibilità di scegliere esplicitamente: Regionpertanto, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 non è possibile offrire servizi compresi nel marketplace del CSP ma che prevedano il provider debba permettere, in fase supporto di deploy/provisioning di un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regionterze parti differenti dal CSP stesso.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si conferma 1119 quanto dichiarato in risposta al chiarimento ID 465 con la precisazione che anche le modalità di invio degli ordinativi da parte delle Amministrazioni saranno definite in sede di stipula. 723 All. 15 16A - ID 2213 - Gara Public Cloud - Capitolato tecnico speciale Lotto 1.pdf – Paragrafo 3. VERIFICHE TECNICHE - Disegno di un Web Crawler – Pag. 18/19, testo Il Concorrente dovrà: 1. Fornire un disegno di alto livello che includa tutte le componenti fondamentali; 2. Disegnare a livello di codice l’ambiente infrastrutturale che invocando le API di piattaforma configura gli ambienti necessari alla definizione del crawler; 3. Definire un piano di scalabilità per superare eventuali colli di bottiglia identificando le componenti critiche; Il concorrente avrà a disposizione 7 giorni lavorativi per la preparazione del test, qualora non dovesse superare la prima verifica, verrà invitato a presentare nuovamente quanto necessario per ripetere il test dopo ulteriori 3 giorni lavorativi. DOMANDA: In riferimento a questo passo si chiede di descrivere cosa si intende per “disegno di alto livello” specificando i dettagli dell’output atteso in termini di stack software e configurazioni. Si chiede inoltre di specificare linguaggi e protocolli. RISPOSTA Fornire una architettura concettuale che descriva le componenti di quanto realizzato comprensive di una descrizione dei flussi. 724 All. 14 - ID 2213 - Gara Public Cloud - Capitolato Tecnico Generale.pdf – Par. 2.3.4. Contratto Esecutivo Premesso che: Rif. “ALLEGATO 14 CAPITOLATO TECNICO - Parte Generale” - Paragrafo “2.3.5 Contratto Esecutivo” - Pag 21., si legge: Il Fornitore inoltre dovrà produrre, entro 10 giorni lavorativi dalla firma del Contratto esecutivo, il Piano di lavoro generale, riportante la pianificazione di dettaglio di tutte le attività ed i servizi ricompresi e in conformità con il Contratto esecutivo. Rif. “ALLEGATO 16A - APPENDICE 1 AL CAPITOLATO TECNICO SPECIALE LOTTO 1 - INDICATORI DI QUALITÀ DEL LOTTO 1” - Paragrafo “3.2 RIT – Xxxxxxx nella consegna di documentazione” - Pag. 5, si legge: L’indicatore di qualità verifica il ritardo del Fornitore nel produrre e fornire all’Amministrazione i documenti contrattuali dell’Accordo Quadro nei tempi e/o nei modi rappresentati nel Contratto esecutivo e relativi allegati e/o tracciati sui Piani di lavoro, siano esse presidiate da specifici indicatori o non presidiate. In particolare la documentazione oggetto della verifica è rappresentata da: • Piano di Subentro • Piano di Trasferimento (PTF) • Piano di lavoro Generale • Obbligazioni Generali e specifiche del Fornitore • Reportistica Rif. “ALLEGATO 16A - APPENDICE 1 AL CAPITOLATO TECNICO SPECIALE LOTTO 1 - INDICATORI DI QUALITÀ DEL LOTTO 1” - Paragrafo “4.3 TEN – Attivazione del tenant” – Pag. 9, si legge: L’indicatore misura il tempo in cui sarà reso disponibile il tenant alle Amministrazioni in seguito all’Ordine di fornitura (5 giorni solari). Si chiede di confermare che il “Piano di lavoro generale” non debba essere prodotto per il Lotto 1, e che il riferimento ad esso nell’ALLEGATO 16A come documento oggetto di uno specifico Indicatore di qualità sia un refuso. Nel caso in cui il Piano di lavoro generale debba essere prodotto anche per il Lotto 1, si chiede di chiarire come la tempistica di produzione di tale documento (ossia 10 giorni lavorativi a partire dalla firma del Contratto esecutivo) si correli temporalmente alla necessità di rendere disponibile il tenant entro 5 giorni solari dalla data di invio dell’Ordine. RISPOSTA Si conferma che il piano di lavoro generale non deve essere prodotto per il Lotto 1. 725 Rif. ALLEGATO 16A CAPITOLATO TECNICO SPECIALE LOTTO 1 GARA PUBLIC CLOUD – ID 2213 – Paragrafo 2.2 Requisiti generali, pag.7 Rif. CAPITOLATO D’ONERI - Paragrafo 16.1 Criteri di valutazione dell’offerta tecnica, pag.42 Premesso che: - In “ALLEGATO 16A CAPITOLATO TECNICO SPECIALE LOTTO 1 GARA PUBLIC CLOUD – ID 2213” – Paragrafo “2.2 Requisiti generali” – Pag. 7 si legge: I servizi offerti dovranno essere fruibili tramite un Tenant registrato a nome dalla PA contraente. Alla scadenza del contratto, il Tenant verrà reso disponibile alla PA contraente per permettere la continuità dell’utilizzo dei servizi Public Cloud IaaS e PaaS. All’interno del Tenant le PA potranno utilizzare i servizi effettivamente ordinati che verranno rendicontati (fatturati) secondo le logiche esposte per ogni categoria. Alla PA contraente dovrà essere garantito accesso amministrativo al massimo livello, inteso come possibilità di configurare tutte le caratteristiche e le funzionalità previste per l’utilizzo in autonomia dei servizi cloud. - In “CAPITOLATO D’ONERI” - Paragrafo “16.1 Criteri di valutazione dell’offerta tecnica” – Pag.42 si legge: “R8 – Ambito Provider” “Modalità di istanziazione di risorse Self provisioning”. - In All. 17 - ID 2213 - Gara Public Cloud - Schema di Offerta Tecnica QUESITOAccordo quadro Lotto 1.pdf - Art.6 comma 13 Rif. Certificato di conformità, si legge: DOMANDA: Le Amministrazioni procedono ad inviare a Consip S.p.A. il certificato di verifica di conformità di cui all’art. 102 del D.Lgs. n. 50/2016 relativamente ai singoli Contratti di fornitura, anche ai fini dello svincolo della/e garanzia/e ex art. 103 del D.Lgs. n. 50/2016. Resta salva la facoltà per Consip S.p.A. di svolgere verifiche ispettive e controlli sull’esecuzione delle singole prestazioni. In considerazione inoltre delle risposte ai chiarimenti 202, 215 e 355; Si chiede di indicare se è possibile inserire nella relazione tecnica, lotti 7confermare che l’attivazione tramite self-11, una sezione Acronimi provisioning dei servizi nei limiti del perimetro dell'ordine e il conseguente utilizzo delle risorse a disposizione del tenant possa considerarsi certificazione di verifica di conformità e che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 Capitolato d'Oneri paragrafo 3 QUESITO: A il fornitore possa a seguito di quanto affermato in risposta al quesito # 1034 ciò avviare la metrica da adottare relativa fatturazione secondo le logiche esposte per la tipologia dei servizi ogni categoria di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla garaservizio. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta Si chiede di rettificare la base d'asta alla luce di quanto evidenziatoRISPOSTA Non si conferma. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 687 punto 2). 726 ID 2213 - Gara Public Cloud - CAPITOLATO D'ONERI - 17.1. Criteri di valutazione dell’offerta tecnica Tabella dei criteri discrezionali (D) e tabellari (T) di valutazione dell’offerta tecnica per il LOTTO 1. Requisito R14 - Categoria Storage - Grace period dati > 6 mesi - PT MAX = 3 DOMANDA: Si chiede di chiarire il punteggio attribuito per Il criterio tabellare R14 nel caso in cui il grace period dei dati sia esattamente pari a 6 mesi. RISPOSTA Il punteggio è pari a 3 punti. Si veda Errata corrige n.3 e nuova versione del Capitolato d'Oneri pard'Oneri. 17.1 QUESITO727 Riferimento: ID 2213 - Gara Public Cloud - CAPITOLATO D'ONERI - 3. OGGETTO DELL’ACCORDO QUADRO, IMPORTO E SUDDIVISIONE IN LOTTI – Monitoring Riferimento: Risposta di chiarimento alla Domanda 428 Monitoring/risorse blocchi di metriche 1000 metriche monitorate/ora. DOMANDA: In riferimento al requisito migliorativo R9 all'unità di misura per il servizio di Monitoraggio pari a 1000 Metriche/ora si chiede di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e risposta alla domanda di chiarimento 428 in cui si indica che la relativa versione fatturazione del servizio debba avvenire sul numero effettivo di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9metriche utilizzate/ora. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoria, caso affermativo si chiede di chiarire perché in tabella riportata al paragrafo "3. OGGETTO DELL’ACCORDO QUADRO, IMPORTO E SUDDIVISIONE IN LOTTI" del Capitolato D'Oneri per il motivo per cui il disco servizio di boot (parte integrante dello storage Monitoring sia indicata come unità di una VM ed in molti casi anche l’unico disco della VM) misura 1000 metriche/ora e non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si la singola metrica/ora RISPOSTA Si conferma quanto fornito in la risposta al chiarimento ID 1048 1123 Quesito 428. 728 ID 1055 QUESITO2213 - Gara Public Cloud - CAPITOLATO D'ONERI - 3. OGGETTO DELL’ACCORDO QUADRO, IMPORTO E SUDDIVISIONE IN LOTTI – VPN; Risposte di chiarimento alla Domande 425, 582, 77. VPN Gateway (tunnel IPSec) numero 1 tunnel VPN/ora DOMANDA: In risposta alle domande 425 e 582 e nel relativo riferimento al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, nuovo documento del Capitolato D'Oneri si definisce la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing metrica per istanza configurata con determinate capacità in termini di CPU, RAM e Storage "il servizio VPN su base oraria. Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e si chiede quindi di confermare tale unità di misura e che per ottenere i punteggi migliorativi R2 quindi quanto riportato nella risposta alla domanda di chiarimento 77 ovvero che il provider debba permettere, in fase di deploy/provisioning di prezzo è riferito ad un servizio, la scelta esplicita del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regionintervallo mensile sia un refuso.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas
Risposta. Si conferma 1119 Pur essendo previste ed obbligatorie per il fornitore, le attività di affiancamento iniziale ed acquisizione del know how funzionali alla corretta esecuzione dei servizi previsti nel capitolato, non sono soggette a valutazione tecnica da parte della commissione giudicatrice. 638 Documento All. 15 16C - ID 2213 - Gara Public Cloud cloud - Schema Appendice 3 al CT Speciale L 7-11 - Scheda Business cases_NEW Documento All. 16C - ID 2213 - Gara Public cloud - Appendice 3 al CT Speciale L 7-11 - Scheda Business cases_NEW, nella risoluzione del caso d’uso è necessario effettuare una scelta preventiva del CSP di Offerta Tecnica QUESITOdestinazione giustificandone la scelta? In caso di risposta affermativa per i BC di tipo repurchase, invece, questa scelta può essere evitata? RISPOSTA In nessuno dei due casi è necessario scegliere un CSP. 639 Risposta n.70 alle domande di chiarimento Risposta n.70 alle domande di chiarimento; al quesito n.70 si conferma che sono a carico del fornitore, le attività di configurazione e setup del servizio SaaS nel caso di strategia di migrazione Repurchase, dove l’Amministrazione scelga di acquistare una nuova versione dell’applicativo presso un fornitore di servizi qualificato ma esterno alla presente iniziativa: DOMANDA: 1. Si chiede se la richiesta non sia in contraddizione con il chiarimento 523 dove si conferma la mancanza della fase M1.2 nel caso di indicare strategia Repurchase; se è possibile inserire nella relazione tecnicail fornitore ha l’obbligo di configurare il servizio SaaS acquistato dalla PPAA, lotti questo non deve essere preliminarmente progettato e inserito un un’architettura coerente in M1.2? RISPOSTA I servizi SaaS a cui ci si riferisce con le attività di re-purchase sono servizi disponibili in commercio che non richiedono progettazione e sviluppo. 640 Capitolato Speciale Lotti 7-11, una sezione Acronimi che equiparata al sommario non concorra al numero massimo di pagine della Relazione Tecnica. RISPOSTA: Si conferma 1120 fase M4 Capitolato d'Oneri paragrafo 3 QUESITO: A seguito di quanto affermato in risposta al quesito # 1034 la metrica da adottare per la tipologia dei servizi di storage è stata modificata da GB/ora a GB/mese (allineandola alle metriche usate dai principali CSP) ma è rimasto inalterato il prezzo a base d'asta rendendo impossibile la partecipazione alla gara. E' infatti facilmente verificabile la seguente relazione tra i prezzi medi di mercato e gli attuali prezzi a base d'asta espressi in GB/mese: ·Prezzo medio di mercato Object Storage circa 4Speciale Lotti 7-5 volte la base d’asta ·Prezzo medio di mercato Block Storage Premium circa 60 volte la base d’asta ·Prezzo medio di mercato Block Storage Standard circa 120-130 volte la base d’asta ·Prezzo medio di mercato File Storage Premium circa 500-600 volte la base d’asta ·Prezzo medio di mercato File Storage Standard circa 900-1000 volte la base d’asta 11, fase M4, Si chiede di rettificare la base d'asta alla luce di quanto evidenziatochiarire i seguenti punti: 1. RISPOSTA: Si veda risposta al chiarimento ID 1075 1121 Capitolato d'Oneri Il primo capoverso del par. 17.1 QUESITO: In riferimento 6.5.1 specifica che “il Fornitore dovrà garantire un Single Point of Contact per l’Amministrazione al requisito migliorativo R9 si chiede quale verranno riportate tutte le problematiche”; a quale orario di confermare che tale requisito sia soddisfatto con la disponibilità dell'OS template nella Console Nativa del CSP e che la relativa versione di OS sia tra quelle supportate dal CSP RISPOSTA: La modalità rappresentata dal Concorrente soddisfa il requisito R9servizio deve rispondere lo SPOC? 2. 1122 Quesito ID 1048 QUESITO: In risposta al quesito # 1048, dove si afferma e ribadisce che la replica dei dischi di boot non è obbligatoriaNella fase citata, si chiede di chiarire il motivo per cui il disco di boot (parte integrante dello storage la creazione di una VM ed in molti casi anche l’unico disco della VM) non debba essere obbligatoriamente replicato, cosi come gli altri dischi (volumi) di storage e con le stesse modalità, per garantire un pieno restore della VM in caso di completo failure di una AZ. RISPOSTA: Relativamente ai Servizi di Knowledge base è richiesta questa tipologia di replica (e quindi con replica dei dischi di boot non obbligatoria). Qualora le PPAA manifestassero esigenze di modalità differenti di replica potranno ricorrere ad un Appalto Specifico mediante rilancio competitivo. Pertanto, si conferma quanto fornito in risposta al chiarimento ID 1048 1123 Quesito ID 1055 QUESITO: In risposta al quesito # 1055, relativo alla modalità di pricing della componente Compute‐Sistema Operativo Licensed, la SA giustamente afferma che ... "Tutti i listini pubblici disponibili apertamente on‐line riportano un pricing per istanza configurata con determinate capacità in termini di CPU, RAM e Storage ". Si chiede quindi di definire le determinate capacità in termini di CPU, RAM e Storage che l'istanza deve soddisfare per poter esprimere un prezzo unitario come richiesto da capitolato. RISPOSTA: Ogni CSP è libero di offrire tagli di VM secondo quanto disponibile nel proprio listino/catalogo pubblico. 1124 Capitolato d'Oneri NEW QUESITO: Si chiede di ripristinare i criteri di valutazione relativi ad Availability zones (R1) , Regions (R2) e R26 alla versione del Capitolato d’Oneri pubblicata in fase di emissione iniziale della gara per permettere a tutti i Cloud Service Provider di mettere a disposizione le proprie infrastrutture cloud disponibili all’interno dell’Europa nel pieno rispetto del principio della libera concorrenza e la pari opportunità di successo a tutti i partecipanti alla gara che è il presupposto della disciplina della concorrenza nell’ordinamento dell’Unione Europea” RISPOSTA: Non si conferma. L'attuale struttura dei requisiti minimi garantisce le esigenze delle Amministrazioni e nello stesso tempo consente una più ampia partecipazione rispetto alla versione pubblicata in fase iniziale facilmente verificabile con l’eliminazione del requisito minimo relativo alla distanza tra le AZ.. Inoltre, i criteri di valutazione premianti, assegnano punteggi in base a garanzie infrastrutturali riconosciute senza ledere in alcun modo la partecipazione alla procedura di gara. 1125 Capitolato d'Oneri NEW e quesito ID 1012 QUESITO: In risposta al quesito # 1012, mutuando quanto affermato e quindi suggerito nel quesito, la SA afferma che: “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, Si vuole fare notare che in letteratura nei public cloud il concetto di Availability Zone è stato pensato proprio per garantire alta affidabilità ai clienti come layer di astrazione e disaccoppiamento dal layer fisico (Data Center). Ciò garantisce al cliente la possibilità di scegliere su quale AZ distribuire e ridondare i propri workload applicativi e proteggersi quindi esplicitamente da eventuali failure a livello di AZ e al provider di aggiungere e bilanciare le risorse computazionali disponibili nella region senza avere impatto sul layer di Availability Zones messo a disposizione dei clienti. La SA introduce un livello gerarchico aggiuntivo (Data Center fisico) come elemento che dovrebbe influire positivamente sulla protezione da problemi legati al singolo edificio come ad esempio incendio, allagamento, etc (annoverati tipicamente in ambito di Disaster Recovery). Quindi l’affermazione “Data Center diversi proteggono da problemi legati al singolo edificio (incendio)”, è vera e condivisibile se e solo se il cliente avesse la possibilità di scegliere, oltre alla Regione e alla Availability Zone, anche il Data Center (ulteriore layer di alta affidabilità introdotto dalla SA, su cui distribuire e ridondare i propri workload) in maniera esplicita. Scenario 1: in fase di provisioning di un servizio, il cliente ha la possibilità di scegliere esplicitamente: Region, l'Availability Zone e il Data Center e ridonda la propria applicazione App 1 su DC 1.1 e DC 1.2: In caso di incendio del Data Center DC 1.1 il cliente avrà la garanzia di continuità di servizio sul DC 1.2 per la sola Applicazione 1 (App 1), distribuita e ridondata sui due DC, mentre avrà una interruzione raccolta di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4). Scenario 2: in fase di provisioning di un servizio, il cliente NON ha la possibilità di scegliere esplicitamente il Data Center ma solo la Region e l'Availability Zone, delegando al provider la scelta del Data Center. Il Provider, sulla base dei proprio capacity planning decide di effettuare il deploy sul DC 1.1 (informazione non visibile al cliente finale): In caso di incendio del Data Center DC 1.1 il cliente avrà una interruzione di servizio ed eventuale perdita di dati per l'Applicazione 4 (App 4) ma anche per l'Applicazione 1 (App 1) che si pensava essere in alta affidabilità. Quindi se il cliente non ha la possibilità di scegliere esplicitamente il DC, la numerosità dei datacenter non rappresenta nessun elemento migliorativo di affidabilità ne di protezione da problemi legati al singolo edificio e tutte le informazioni utili alla risoluzione degli incident; si chiede quindi di confermare che per ottenere i punteggi migliorativi R2 il provider debba permetterese saranno rese disponibili tutte le informazioni richieste al popolamento della KB (Incident logging, in fase di deploy/provisioning di un servizioIncident classification, la scelta esplicita Incident prioritization, Investigation e diagnosis, Incident Resolution e closure, Informazioni relative a data, workload e componenti infrastrutturali impattati) tramite accesso ai sistemi del data center fisico su cui istanziare il servizio oltre all'AZ e alla Regioncliente (Trouble ticketing, ecc) o se queste saranno disponibili tramite altra modalità.
Appears in 1 contract
Samples: Accordo Quadro Per La Fornitura Di Servizi Cloud Iaas E Paas