SlideShare ist ein Scribd-Unternehmen logo
1 von 24
Downloaden Sie, um offline zu lesen
Considerazioni per la tipologia di Dischi da Utilizzare
Considerazioni di Base
• Dischi e LUN
• Livelli di Raid
• Path
• Mirroring Sincrono
Considerazioni per la tipologia di Dischi da Utilizzare
• Average Seek Time : The time the read/write head needs to physically move to the
correct place.
• IOs per Second : The amount of operations a disk can handle per second.
• MBs per Second :The amount of data a disk can transfer per second.
In qualsiasi soluzione di Storage è necessario avere particolare attenzione nella scelta del
layout dei dischi.
Tipiche indicazioni di classificazione delle tipologie di Dischi
Considerazioni per la tipologia di Dischi da Utilizzare
Tipiche indicazioni di classificazione delle tipologie di Dischi
Performance dei dischi SSD
Specifications
•Up to 550MB/s Sequential Read
•Up to 500MB/s Sequential Write
•Up to 55,000 IOPS 4k Random Read
•Up to 75,000 IOPS 4k Random Write
Normale disco da 2’’ per server fino d 512GByte
Considerazioni per la tipologia di Dischi da Utilizzare
Nuove Soluzioni in tecnologia FLASH
Performance Board Flash
Specifications
Up to 1800 MB/s Sequential Read
Up to 1700 MB/s Sequential Write
Up to 140,000 IOPS 4k Random Write
Available in 240GB, 480GB, 960GB
Considerazioni per la tipologia di Dischi da Utilizzare
Performance dei dischi SSD
Considerazioni per la tipologia di Dischi da Utilizzare
Performance Board Flash
Considerazioni per la tipologia di Dischi da Utilizzare
Layout di utilizzo delle varie tipologie di Raid in funzione del Tier di utilizzo
Le nuove Tecnologie SSD e Flash possono essere integrate nei Tier
Fino a 4 livelli di Tier SSD + SAS (15K) + SAS (10K) + SATA
Considerazioni per la tipologia di Dischi da Utilizzare
Tanti dischi, meno capienti ma più veloci ….
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array
Example 1 – 15 Disks in 1 RAID Set, 1 LUN
exported to the pool
Pro:
• Good performance due to striping across 15 physical
spindles
• Small storage loss for RAID overhead (depending on chosen
RAID level)
Contro:
• DataCore has just a single I/O queue to the disks which may
result in congestion
• If one physical disk fails, the whole LUN is affected by RAID
rebuild
• RAID rebuild may take a long time on large RAID sets and
degrade performance
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array
Example 2 -- 15 Disks in 1 RAID Set, 3 LUNs created from RAID set and exported to the pool:
Pro:
• Small storage loss for RAID overhead
(depending on chosen RAID level)
Contro:
• If one physical disk fails, all three LUNs are
affected by RAID rebuild
• RAID rebuild may take a long time on large
RAID sets and degrades performance
• The DataCore pool concept of distributing
allocated blocks conflicts with the RAID layout
– creates additional seek and rotational
latency on the physical disks, thus degrading
performance
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array
Example 4 - No RAID level – “just a bunch of disks” (JBOD)
Pro:
• Full use of capacity
• Many I/O queues to disks
• Pool spreads loads across spindles
• Contro:
• One failed disk will affect the entire pool(s)
• Disk failure may cause long recovery time
• Bad blocks on disks are not recognized
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array
Example 3 – 15 Disks in 3 RAID Sets, 1 LUN for each RAID Set exported to the pool:
Pro:
DataCore has three I/O queues to the disks.
The distribution algorithm spreads out the load across
LUNs and increase performance
A failed physical disk affects just one LUN
RAID rebuild is quicker with fewer disks.
Contro:
Greater storage loss for RAID overhead (depending
on RAID level)
Pro superano i contro, buon bilanciamento tra
costi e prestazioni e disponibilità.
Configurazione consigliata in questo tipo di
situazione.
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array e tipologia di Raid
RAID 0 – Striping:
Pro:
• Full use of capacity
• Highest write performance
• Highest read performance
Contro:
• Highest risk potential
• DataCore has just a single I/O queue to the disks
which may result in congestion
• One failed disk destroys all data in the pool
• Disk failure may cause long recovery time
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array e tipologia di Raid
RAID 1 – Mirroring:
Pro:
• High security level
• High sequential read/write performance
• High random read/write performance
• DataCore spreads load across all RAID1 sets
• Failed disk doesn’t significantly affect
performance
• Quick recovery from disk failure
Contro:
• 50% capacity loss
Recommended for non-mirrored volumes and
applications which cause lots of small random I/Os (like database and email applications). Pools
which contain numerous volumes accessed by many Hosts may experience highly random I/O too.
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array e tipologia di Raid
RAID 10 – Mirroring e Striping:
Pro
• High security level
• High sequential read/write performance
• Highest random read/write performance
Contro
• 50% capacity loss
• Less I/O queues compared to multiple RAID1
Considerazioni per la tipologia di Dischi da Utilizzare
Distribuzione dei Lun nei vari array e tipologia di Raid
RAID 5 – Striping with Parity:
Pro:
• Moderate capacity loss
• High sequential read/write performance
• High random read performance
Contro:
• Low random write performance
• Moderate security level
• Failed disk / rebuild impacts performance
RAID 5 sets are good for applications with mainly
sequential I/O or highly random reads like file server, average loaded databases and so on.
Creating multiple, smaller RAID5 sets are preferred over fewer large ones
Considerazioni per la tipologia di Dischi da Utilizzare
Pool Disk
L'algoritmo di piscina DataCore distribuisce i blocchi di dati allocati in tutti i dischi in una
pool.
Non ha poco senso avere più lento e più veloce o più grandi e più piccoli all'interno di un
livello. Se una capacità del Pool è destinata ad essere ampliata e non sono disponibili risorse
tipo dischi/tipo/capacità ecc, può essere utile creare un nuovo pool con migrazione di
dischi virtuali.
Scenari di implementazione della soluzione DataCore
Host Ridondati, Path Ridondati
Front-end Port Front-end Port
Mirroring Port
Back-end Port Back-end Port
Path
Scenari di implementazione della soluzione DataCore
Esempio di utilizzo di DataCore con due Host di Virtualizzazione VMware
Scenari di implementazione della soluzione DataCore
Autotiering
Scenari di implementazione della soluzione DataCore
Autotiering – Come funziona
Scenari di implementazione della soluzione DataCore
Autotiering e la distribuzione disco virtuale
Scenari di implementazione della soluzione DataCore
Layout di un Mirroring Sincrono
Scenari di implementazione della soluzione DataCore
Considerazioni per l’utilizzo un Mirroring Sincrono
Dark fibre links can be stretched up to 10 km (with 1300 nm laser) or 35 km (with 1550 nm laser). A
dark fibre link of 35 km adds a latency of around 5 micro seconds per km. A microsecond (µs) is equal to one millionth of a second or
one thousandth of a millisecond (ms).
This means a dark fibre link of 35 km adds a latency of 5 µs * 35km * 8(trips)= 1400 micro seconds(µs) = 1.4 milliseconds (ms)
Degradation of the signal along the cable; this tends to increase the longer the link and brings down
reliability without extra hardware to correct the degradation.
If the link (HBAs and FC switches, link hardware) has not enough FC Buffer Credit, latency can
increase. The faster FC speed you want to use (2Gbps, 4Gbps, 8Gbps etc.) and the longer the link the more FC Buffer Credits you will
need to fully utilize the link.

Weitere ähnliche Inhalte

Ähnlich wie Presentazione storage concetti base pdf

Hadoop
HadoopHadoop
Hadoop
Reply
 
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terraPresentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
Andrea Mauro
 

Ähnlich wie Presentazione storage concetti base pdf (20)

Seminario Antonio Concas, 8-11-2012
Seminario Antonio Concas, 8-11-2012Seminario Antonio Concas, 8-11-2012
Seminario Antonio Concas, 8-11-2012
 
VMUGIT UC 2013 - 09b VMUGIT SMB
VMUGIT UC 2013 - 09b VMUGIT SMB VMUGIT UC 2013 - 09b VMUGIT SMB
VMUGIT UC 2013 - 09b VMUGIT SMB
 
Thread
ThreadThread
Thread
 
Hadoop
HadoopHadoop
Hadoop
 
Thread
ThreadThread
Thread
 
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDBPolyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB
Polyglot Persistance con PostgreSQL, CouchDB, MongoDB, Redis e OrientDB
 
Cesvip 20110127
Cesvip 20110127Cesvip 20110127
Cesvip 20110127
 
Virtualizzare Nanosoft
Virtualizzare   NanosoftVirtualizzare   Nanosoft
Virtualizzare Nanosoft
 
Cloud storage in azienda: perche` Riak ci e` piaciuto
Cloud storage in azienda: perche` Riak ci e` piaciutoCloud storage in azienda: perche` Riak ci e` piaciuto
Cloud storage in azienda: perche` Riak ci e` piaciuto
 
Lezioni 2009
Lezioni 2009Lezioni 2009
Lezioni 2009
 
MongoDB Atlas: il modo migliore per eseguire MongoDB in ambiente cloud 1
MongoDB Atlas: il modo migliore per eseguire MongoDB in ambiente cloud 1MongoDB Atlas: il modo migliore per eseguire MongoDB in ambiente cloud 1
MongoDB Atlas: il modo migliore per eseguire MongoDB in ambiente cloud 1
 
Data grid
Data gridData grid
Data grid
 
Azure PaaS databases
Azure PaaS databasesAzure PaaS databases
Azure PaaS databases
 
VMUGIT - Virtualizzare con i piedi per terra
VMUGIT - Virtualizzare con i piedi per terraVMUGIT - Virtualizzare con i piedi per terra
VMUGIT - Virtualizzare con i piedi per terra
 
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terraPresentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
Presentazione al VMUGIT UC 2014 - Virtualizzare con i piedi per terra
 
SQL Server Failover Cluster Instances con Amazon FSx in AWS
SQL Server Failover Cluster Instances con Amazon FSx in AWSSQL Server Failover Cluster Instances con Amazon FSx in AWS
SQL Server Failover Cluster Instances con Amazon FSx in AWS
 
IBM FlashSystem 820 e 720
IBM FlashSystem 820 e 720IBM FlashSystem 820 e 720
IBM FlashSystem 820 e 720
 
Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Dat...
Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Dat...Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Dat...
Soluzioni distribuite per l’analisi di dati biomedici in ambiente Virtual Dat...
 
Assemblare un pc
Assemblare un pcAssemblare un pc
Assemblare un pc
 
SDS,la pietra d’angolo dell SDDC
SDS,la pietra d’angolo dell SDDC SDS,la pietra d’angolo dell SDDC
SDS,la pietra d’angolo dell SDDC
 

Mehr von AFB Net

Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
AFB Net
 

Mehr von AFB Net (11)

IBM - Silverpop
IBM - SilverpopIBM - Silverpop
IBM - Silverpop
 
Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
Data Core e Virtualizzazione dello Storage - Evento Firenze 17 giugno 2014
 
Project Management 2.0 i vantaggi della Collaboration
Project Management 2.0 i vantaggi della CollaborationProject Management 2.0 i vantaggi della Collaboration
Project Management 2.0 i vantaggi della Collaboration
 
Un nuovo modo di fare eCommerce
Un nuovo modo di fare eCommerceUn nuovo modo di fare eCommerce
Un nuovo modo di fare eCommerce
 
Social Business - Un'azienda che cresce!
Social Business - Un'azienda che cresce!Social Business - Un'azienda che cresce!
Social Business - Un'azienda che cresce!
 
Customer experience - un nuovo modo di fare web!
Customer experience - un nuovo modo di fare web!Customer experience - un nuovo modo di fare web!
Customer experience - un nuovo modo di fare web!
 
Go2Tec - Stonesoft augmented vpn
Go2Tec - Stonesoft augmented vpnGo2Tec - Stonesoft augmented vpn
Go2Tec - Stonesoft augmented vpn
 
Go2Tec - Sicurezza e protezione dei dati aziendali - Riccardo Barghini
Go2Tec - Sicurezza e protezione dei dati aziendali - Riccardo BarghiniGo2Tec - Sicurezza e protezione dei dati aziendali - Riccardo Barghini
Go2Tec - Sicurezza e protezione dei dati aziendali - Riccardo Barghini
 
Go2Tec - Security assessment e normative - Riccardo Barghini
Go2Tec - Security assessment e normative - Riccardo BarghiniGo2Tec - Security assessment e normative - Riccardo Barghini
Go2Tec - Security assessment e normative - Riccardo Barghini
 
Un sito eCommerce per incrementare le vendite: il caso SCAI
Un sito eCommerce per incrementare le vendite: il caso SCAIUn sito eCommerce per incrementare le vendite: il caso SCAI
Un sito eCommerce per incrementare le vendite: il caso SCAI
 
Web: da necessità ad opportunità
Web: da necessità ad opportunitàWeb: da necessità ad opportunità
Web: da necessità ad opportunità
 

Presentazione storage concetti base pdf

  • 1. Considerazioni per la tipologia di Dischi da Utilizzare Considerazioni di Base • Dischi e LUN • Livelli di Raid • Path • Mirroring Sincrono
  • 2. Considerazioni per la tipologia di Dischi da Utilizzare • Average Seek Time : The time the read/write head needs to physically move to the correct place. • IOs per Second : The amount of operations a disk can handle per second. • MBs per Second :The amount of data a disk can transfer per second. In qualsiasi soluzione di Storage è necessario avere particolare attenzione nella scelta del layout dei dischi. Tipiche indicazioni di classificazione delle tipologie di Dischi
  • 3. Considerazioni per la tipologia di Dischi da Utilizzare Tipiche indicazioni di classificazione delle tipologie di Dischi Performance dei dischi SSD Specifications •Up to 550MB/s Sequential Read •Up to 500MB/s Sequential Write •Up to 55,000 IOPS 4k Random Read •Up to 75,000 IOPS 4k Random Write Normale disco da 2’’ per server fino d 512GByte
  • 4. Considerazioni per la tipologia di Dischi da Utilizzare Nuove Soluzioni in tecnologia FLASH Performance Board Flash Specifications Up to 1800 MB/s Sequential Read Up to 1700 MB/s Sequential Write Up to 140,000 IOPS 4k Random Write Available in 240GB, 480GB, 960GB
  • 5. Considerazioni per la tipologia di Dischi da Utilizzare Performance dei dischi SSD
  • 6. Considerazioni per la tipologia di Dischi da Utilizzare Performance Board Flash
  • 7. Considerazioni per la tipologia di Dischi da Utilizzare Layout di utilizzo delle varie tipologie di Raid in funzione del Tier di utilizzo Le nuove Tecnologie SSD e Flash possono essere integrate nei Tier Fino a 4 livelli di Tier SSD + SAS (15K) + SAS (10K) + SATA
  • 8. Considerazioni per la tipologia di Dischi da Utilizzare Tanti dischi, meno capienti ma più veloci ….
  • 9. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array Example 1 – 15 Disks in 1 RAID Set, 1 LUN exported to the pool Pro: • Good performance due to striping across 15 physical spindles • Small storage loss for RAID overhead (depending on chosen RAID level) Contro: • DataCore has just a single I/O queue to the disks which may result in congestion • If one physical disk fails, the whole LUN is affected by RAID rebuild • RAID rebuild may take a long time on large RAID sets and degrade performance
  • 10. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array Example 2 -- 15 Disks in 1 RAID Set, 3 LUNs created from RAID set and exported to the pool: Pro: • Small storage loss for RAID overhead (depending on chosen RAID level) Contro: • If one physical disk fails, all three LUNs are affected by RAID rebuild • RAID rebuild may take a long time on large RAID sets and degrades performance • The DataCore pool concept of distributing allocated blocks conflicts with the RAID layout – creates additional seek and rotational latency on the physical disks, thus degrading performance
  • 11. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array Example 4 - No RAID level – “just a bunch of disks” (JBOD) Pro: • Full use of capacity • Many I/O queues to disks • Pool spreads loads across spindles • Contro: • One failed disk will affect the entire pool(s) • Disk failure may cause long recovery time • Bad blocks on disks are not recognized
  • 12. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array Example 3 – 15 Disks in 3 RAID Sets, 1 LUN for each RAID Set exported to the pool: Pro: DataCore has three I/O queues to the disks. The distribution algorithm spreads out the load across LUNs and increase performance A failed physical disk affects just one LUN RAID rebuild is quicker with fewer disks. Contro: Greater storage loss for RAID overhead (depending on RAID level) Pro superano i contro, buon bilanciamento tra costi e prestazioni e disponibilità. Configurazione consigliata in questo tipo di situazione.
  • 13. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array e tipologia di Raid RAID 0 – Striping: Pro: • Full use of capacity • Highest write performance • Highest read performance Contro: • Highest risk potential • DataCore has just a single I/O queue to the disks which may result in congestion • One failed disk destroys all data in the pool • Disk failure may cause long recovery time
  • 14. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array e tipologia di Raid RAID 1 – Mirroring: Pro: • High security level • High sequential read/write performance • High random read/write performance • DataCore spreads load across all RAID1 sets • Failed disk doesn’t significantly affect performance • Quick recovery from disk failure Contro: • 50% capacity loss Recommended for non-mirrored volumes and applications which cause lots of small random I/Os (like database and email applications). Pools which contain numerous volumes accessed by many Hosts may experience highly random I/O too.
  • 15. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array e tipologia di Raid RAID 10 – Mirroring e Striping: Pro • High security level • High sequential read/write performance • Highest random read/write performance Contro • 50% capacity loss • Less I/O queues compared to multiple RAID1
  • 16. Considerazioni per la tipologia di Dischi da Utilizzare Distribuzione dei Lun nei vari array e tipologia di Raid RAID 5 – Striping with Parity: Pro: • Moderate capacity loss • High sequential read/write performance • High random read performance Contro: • Low random write performance • Moderate security level • Failed disk / rebuild impacts performance RAID 5 sets are good for applications with mainly sequential I/O or highly random reads like file server, average loaded databases and so on. Creating multiple, smaller RAID5 sets are preferred over fewer large ones
  • 17. Considerazioni per la tipologia di Dischi da Utilizzare Pool Disk L'algoritmo di piscina DataCore distribuisce i blocchi di dati allocati in tutti i dischi in una pool. Non ha poco senso avere più lento e più veloce o più grandi e più piccoli all'interno di un livello. Se una capacità del Pool è destinata ad essere ampliata e non sono disponibili risorse tipo dischi/tipo/capacità ecc, può essere utile creare un nuovo pool con migrazione di dischi virtuali.
  • 18. Scenari di implementazione della soluzione DataCore Host Ridondati, Path Ridondati Front-end Port Front-end Port Mirroring Port Back-end Port Back-end Port Path
  • 19. Scenari di implementazione della soluzione DataCore Esempio di utilizzo di DataCore con due Host di Virtualizzazione VMware
  • 20. Scenari di implementazione della soluzione DataCore Autotiering
  • 21. Scenari di implementazione della soluzione DataCore Autotiering – Come funziona
  • 22. Scenari di implementazione della soluzione DataCore Autotiering e la distribuzione disco virtuale
  • 23. Scenari di implementazione della soluzione DataCore Layout di un Mirroring Sincrono
  • 24. Scenari di implementazione della soluzione DataCore Considerazioni per l’utilizzo un Mirroring Sincrono Dark fibre links can be stretched up to 10 km (with 1300 nm laser) or 35 km (with 1550 nm laser). A dark fibre link of 35 km adds a latency of around 5 micro seconds per km. A microsecond (µs) is equal to one millionth of a second or one thousandth of a millisecond (ms). This means a dark fibre link of 35 km adds a latency of 5 µs * 35km * 8(trips)= 1400 micro seconds(µs) = 1.4 milliseconds (ms) Degradation of the signal along the cable; this tends to increase the longer the link and brings down reliability without extra hardware to correct the degradation. If the link (HBAs and FC switches, link hardware) has not enough FC Buffer Credit, latency can increase. The faster FC speed you want to use (2Gbps, 4Gbps, 8Gbps etc.) and the longer the link the more FC Buffer Credits you will need to fully utilize the link.