SAN con alcune unità SSD o un sacco di HDD vecchio stile?

La mia azienda sta cercando di capire quale tipo di SAN acquistare. Questo è specifico per i server di database che stanno diventando vincolati all'IO (lo storage è DAS in questo momento, ma stiamo raggiungendo il limite di un singolo server e vorremmo aggiungere anche il clustering).

Abbiamo bisogno di una soluzione che produca circa 3000 IOPS a lungo termine (attualmente raggiungiamo il picco di circa 1000 IOPS). La maggior parte delle operazioni del nostro database sono letture / scritture di piccole dimensioni. Sulla base delle discussioni con gli ingegneri HP e altri online, un HP P2000 con 24 unità SAS SAS in una configurazione RAID 10 garantirà una tale velocità per ~ $ 20K. Aggiungi controller e altri elementi per costruire la SAN ci mette esattamente intorno al nostro budget massimo di $ 30.000.

Ma online, vedo che molti SSD SAS offrono velocità di 80.000 IOPS +. È realistico aspettarselo? In tal caso, sarebbe realistico ottenere un P2000 o una SAN entry-level simile e lanciare alcuni SSD? I nostri database sono piccoli, solo un paio di TB in totale. Se lo facessimo, avremmo i soldi rimanenti per acquistare una seconda SAN per il mirroring / failover, il che sembra prudente.

Posso parlare dei dettagli di ciò che stai cercando di realizzare. Onestamente, non prenderei in considerazione un HP P2000 / MSA2000 entry-level per il tuo scopo.

Questi dispositivi hanno molti limiti e, dal punto di vista del set di funzionalità SAN, non sono altro che una scatola di dischi. Nessuna suddivisione in livelli, nessuna memorizzazione nella cache intelligente, un massimo di 16 dischi in un gruppo di dischi virtuali , basse funzionalità IOPS, scarso supporto SSD, (specialmente sull'unità selezionata).

Dovresti passare a HP MSA2040 per vedere qualsiasi vantaggio in termini di prestazioni o supporto ufficiale con SSD. Inoltre, vuoi davvero usare iSCSI?

DAS può essere l'opzione migliore se è possibile tollerare l'archiviazione locale. L'archiviazione flash PCIe rientra nel budget, ma è necessario pianificare attentamente la capacità.

Puoi approfondire le specifiche dei tuoi server attuali? Marca / modello, ecc.

Se il clustering è un must, un'altra opzione è fare l'unità HP MSA2040, ma utilizzare un'unità SAS anziché iSCSI. Questo è meno costoso rispetto agli altri modelli, consente di collegare 4-8 server, offre bassa latenza e grande throughput e può ancora supportare SSD. Anche con i modelli Fibre o iSCSI, questa unità offre una maggiore flessibilità rispetto a quella collegata.

La regola empirica che uso per l'IO del disco è:

• 75 IOP per mandrino per SATA.

• 150 IOP per mandrino per FC / SAS

• 1500 IOP per mandrino per SSD.

Oltre agli IOP per array, vengono considerati anche gli IOP per terabyte. Non è raro finire con un pessimo rapporto IOP per TB se si fa SATA + RAID6. Questo potrebbe non sembrare troppo, ma spesso finirai con qualcuno che individua "spazio libero" su un array e vuoi usarlo. È comune per le persone acquistare concerti e ignorare gli iop, quando è vero il contrario nella maggior parte dei sistemi aziendali.

Quindi aggiungere il costo della penalità di scrittura per RAID:

• 2 per RAID1, RAID1 + 0
• 4 per RAID5 (o 4)
• 6 per RAID6.

La penalità di scrittura può essere parzialmente mitigata dalle grandi cache di scrittura e nelle giuste circostanze. Se hai un sacco di I / O di scrittura sequenziale (come i registri DB) puoi ridurre in modo significativo tali penali di scrittura su RAID 5 e 6. Se riesci a scrivere una riga intera (ad esempio un blocco per mandrino) non devi leggere per calcolare la parità.

Assumi un set RAID 6 8 + 2. Nel normale funzionamento per un singolo IO di scrittura è necessario:

• Leggi il blocco 'aggiornato'.
• Leggi il primo blocco di parità
• Leggi il secondo blocco di parità
• Ricalcola la parità.
• scrivere tutti 3. (6 IO).

Con una scrittura nella striscia intera memorizzata nella cache, ad esempio 8 "blocchi" consecutivi delle dimensioni della striscia RAID, è possibile calcolare la parità sull'intero lotto, senza bisogno di una lettura. Quindi hai solo bisogno di 10 scritture: una per ogni dato e due parità.

Questo rende la tua penalità di scrittura 1.2.

È inoltre necessario tenere presente che scrivere IO è facile da memorizzare nella cache, non è necessario scaricarlo immediatamente sul disco. Funziona con un limite di tempo morbido - fintanto che in media le scritture in entrata non superano la velocità del mandrino, sarà tutto in grado di funzionare alla "velocità della cache".

D'altra parte, l'IO di lettura presenta un vincolo di difficoltà: non è possibile completare una lettura fino a quando i dati non sono stati recuperati. Gli algoritmi di cache di lettura e caricamento della cache diventano importanti a quel punto: i modelli di lettura prevedibili (ad es. Sequenziali, come si otterrebbe dal backup) possono essere previsti e precaricati, ma i modelli di lettura casuali non possono.

Per i database, in genere suggerirei di presumere che:

• la maggior parte dell'IO del "database" è una lettura casuale. (ad es. non valido per l'accesso casuale). Se puoi permetterti il ​​sovraccarico, RAID1 + 0 è buono, perché i dischi con mirroring danno due fonti di letture.

• la maggior parte dell'IO 'log' è in scrittura sequenziale. (ad es. buono per la memorizzazione nella cache e contrariamente a quanto suggeriranno molti DBA, probabilmente si desidera RAID50 anziché RAID10).

Il rapporto tra i due è difficile è difficile da dire. Dipende da cosa fa il DB.

Poiché l'IO di lettura casuale è il caso peggiore per la memorizzazione nella cache, è dove l'SSD fa davvero la sua parte - molti produttori non si preoccupano della memorizzazione nella cache dell'SSD perché si tratta comunque della stessa velocità. Quindi, specialmente per database e indici temporanei, SSD offre un buon ritorno sugli investimenti.

La tua analisi è abbastanza corretta.

Usa alcuni HDD per molti GB e molti HDD a pochi IOps.
Usa alcuni SSD per molti IOP e molti SSD per pochi GB

Qual è più importante per te? Lo spazio è il grande fattore di costo per le soluzioni SSD, poiché il prezzo per GB è molto più elevato. Se stai parlando di un database da 200 GB necessario IOP 4K, un paio di SSD ti porteranno lì. O un array di 24 dischi di unità da 15K, che lascia molto spazio per l'archiviazione di massa.

Quanti IOps uscirai effettivamente da questi SSD varia molto in base all'infrastruttura di archiviazione (ewwhite lo elaborerà), ma è ragionevole ottenere quel tipo di velocità. Soprattutto con Raid10, dove la parità non viene calcolata.

Di recente ho creato un paio di server di archiviazione per il mio datore di lavoro, utilizzando lo chassis Dell C2100, eseguendo FreeBSD 10.1 con dodici unità SATA enterprise "SE" Western Digital da 2 TB 7200rpm. Le unità si trovano in un unico pool ZFS costituito da due dispositivi virtuali RAIDZ-2 a 6 unità (vdevs). Allegati al pool sono una coppia di SSD Intel DC S3500 che sono supercap protetti contro la perdita di potenza, sono usati sia come SLOG che L2ARC. Carico test questo server su iSCSI, sono stato in grado di colpire 7500-8200 IOPS. Il nostro costo totale inclusi i dischi rigidi era di circa $ 2700 per server.

Nel tempo in cui questi sistemi basati su BSD sono stati in esecuzione, una delle nostre unità SAN HP MSA2012i ha riscontrato due errori del controller e l'altra unità MSA2012i ha corrotto un grande volume NTFS che richiedeva 12 ore di inattività per la riparazione.

Dell e HP vendono il 10% di hardware e il 90% promettono di supporto che non finirai mai per essere in grado di utilizzare.