Software Defined Storage

Disaster recovery &

Business Continuity

Raffaello PoltronieriData Center Engineering Manager

Software Defined Storage: Evoluzione dello Storage

Necessità Aziendali

Offerta di mercato

Soluzione adottata

Risultato

Futuro

Soluzione DR/BC: Perché Zerto

Hypervisor-based

Application protection

DRaaS e In-Cloud

Migrazione a tempo “near 0”

DEMO

Agenda

Software defined Storage

2012

Datacenters: basati su NFS, solido ma tradizionale. Un mix di

dischi SAS, SATA e Flash (dedicato alla cache).

Performances ed affidabilità .

2012….

Mese dopo mese, con la crescita dei clienti e in numero e in

dimensioni ma soprattutto nuove esigenze prestazionali hanno

richiesto un’evoluzione tecnologica

L’architettura in essere non era in grado di rispondere a tutte le

esigenze in termini di performances, sebbene ancora affidabile.

Evoluzione dello Storage (1/2)

0

20

40

60

80

100

120

10 2012 03 2013 08 2013 01 2014 06 2014 11 2014 04 2015 8 2015

Performances

Clienti

TB

Evoluzione dello Storage (2/2)

Necessità Aziendali

Evoluzione del cliente con spostamento su

cloud di applicazioni tipo SAP e SQL:

necessità di PERFORMANCES.

La nostra infrastruttura virtuale richiedeva

Storage vmotion quotidiano.

Causa principale: dischi SATA

Nuove applicazioni e maggior confidenza

nel concetto di cloud hanno permesso lo

spostamento di maggiori quantità di dati

nei nostri datastores: SCARSA CAPACITA’

Tutte queste operazioni richiedevano

tempo e skill dedicate: necessità di

SEMPLIFICAZIONE

Backup basati su snapshots: LENTI e

GRAVOSI per VM in produzione

Necessità Aziendali

Datacenters ad alta densità dispongono di

POCO SPAZIO, ogni singolo cm cubo nel

rack è oro!

COSTI diretti e indiretti per l’energia, oltre

a quello per il rinnovo della manutenzione.

ANALISI DEI VENDORStrategia di sviluppo (1/2)

Tre scenari possibili:

• Tradizionale (Rinnovo/Espansione dell’esistente)

• Tradizionale (Nuovo)

• SDS (che fosse All Flash o Ibrido)

Analizzando l’ambiente altamente dinamico di noi come CSP, ci

accorgemmo che la scelta obbligata doveva avvenire

all’interno degli SDSs.

ANALISI DEI VENDORStrategia di sviluppo (2/2)

Tintri ci consente gestione delle performance, mostra grafici di

analisi e riordina il flusso di IOPS, tutto questo in modalità

“per-VM”.

La maggior parte delle SAN Ibride scrivono prima su dischi

meccanici lasciando gli SSD come cache di lettura, in gran

parte senza alcuna protezione.

TINTRI usa prima la Flash, scrivendo su SSD in modalità

protetta. Inoltre effettua deduplica e compressione on the fly

Percorso di adozione

Recupero del “Tradizionale”: accelerazione degli arrays

esistenti applicando la tecnologia PernixData.

No All Flash: troppo costosi per sostenere business model di

mercato e non adatti ad ambienti altamente dinamici.

SDS Tintri: rappresenta un ottimo mix di performances grazie

agli SSD e di costi grazie ai dischi SAS.

Inoltre, il concetto di “Zero touch IT” ci ha permesso di

migliorare in maniera “SENSIBILE” il nostro TIME TO MARKET

Risultati• Semplicità e rapidità di installazione e messa in esercizio

• Veloce spostamento delle VM tra gli storage

• Spazio fisico x 1,7 grazie a deduplica e compressione

• Riduzione drastica della latenza in “ms” per volume

• Quality of Service

• “High Performance Storage”

• TGC (a.k.a. Tintri Global Center): pannello unico di gestione

e analisi• Comparazione non più in termini di €/TB

• Keep it simple!

Evoluzione della nostra soluzione

Evoluzione dell’architettura di Storage

per rispondere a tre requisiti

di offerta:

- Prestazioni

- “Self Operations Automation”

- SLA Monitoring

Soluzione di DR/BC

Perché Zert0Anche il DR è entrato nell’ “Era Professionale”. IL DR

Tradizionale ha dinamiche e costi non adeguati al Business per

cui è pensato

Zerto è la prima piattaforma BC/DR hypervisor-based per

cloud, a protezione di applicazioni “in” cloud e “verso il” cloud.

RTO di minuti, RPO di secondi

Architettura nativa multi-tenant

Repliche HW-agnostic

Piena integrazione con vCloud

Director

Impatto nullo su VM in produzione

Possibilità di clonare VM in produzione

per test (“sand box”)

Automazione di failover, failback e test

Recupero parziale o totale delle VM

protette

Hypervisor based

Replica non a livello di storage, ma di singola VM

Application protection

DRaaS e In-Cloud

DRaaS: vCenter cliente,

DR presso Cloud, o

viceversa.

In-Cloud: Cliente in cloud che

vuole proteggere le sue VM

sempre in cloud, ma in un

differente vDC

Migrazione a tempo «near-zero»