View
89
Download
1
Category
Tags:
Preview:
Citation preview
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). Adark 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 downreliability 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.
Recommended