Come cambiano IOPS di storage in risposta alla capacità del disco?

Tutte le altre cose sono uguali, come cambiare la prestazione IOPS di un arrays di archiviazione se si utilizzava dischi più grandi.

Ad esempio, prendi un arrays con dischi da 10 X 100GB.

Misura IOPS per le scritture a blocchi sequenziali da 256 kb (o qualsiasi metrica IOPS)

Supponiamo che il risultato IOPS misurato sia 1000 IOPS.

Cambiare l'arrays per uno con 10 X 200GB dischi. Formato con la stessa configuration RAID, la stessa dimensione del block, ecc.

Ci si aspetterebbe che il IOPS rimanga lo stesso, aumentare o diminuire? Il cambiamento sarebbe grossolanamente lineare? vale a dire aumentare di 2X o diminuire di 2X (come ho aumentato la capacità del disco di 2X)

Ripetere queste domande con dischi da 10 X 50GB.

Modifica: più context

Questa domanda è risultata come una conversazione tra la mia squadra di Sysadmin che non è ben esperta in tutto il magazzino. (Confortevole con molti aspetti di archiviazione, ma non i dettagli della gestione di una SAN o di qualsiasi altra cosa). Stiamo ricevendo un grosso mucchio di nuovi vassoi Netapp che dispongono di una capacità di disco superiore superiore a double capacità rispetto ai nostri vassoi esistenti. Il commento è giunto che il IOPS dei nuovi vassoi sarebbe inferiore solo perché i dischi erano più grandi. Poi un'analogia automobilistica è venuta a spiegare questo. Nessun commento mi è stato bene, quindi ho voluto correre a The Team, cioè Stack-Exchange-land.

L'analogia dell'auto era qualcosa di due auto, con diverse accelerazioni, la stessa velocità massima e un quarto di chilometro. Quindi cambiare la distanza a mezzo miglio. In realtà non riesco a ricordare l'analogia esatta, ma da quando ho trovato un altro sull'interface simile, ho capito che era probabilmente un'analogia IOPS comune.

In qualche modo, la risposta effettiva alla domanda non import tanto per me, poiché non stiamo utilizzando queste informazioni per valutare un acquisto. Ma abbiamo bisogno di valutare il modo migliore per colbind i vassoi a una testa esistente e il modo migliore per eliminare gli aggregati e i volumi.

  • Utilizzo di un NAS di fascia alta come vSphere / HyperV Storage
  • Qual è la relazione tra "HP Diagnostics", "Array Config Utility" e "Gestione disco di Windows"
  • Network Filesystem non riesce durante le velocità I / O elevate
  • È ansible impostare dynamicmente il valore upload_store per la modifica di upload di nginx?
  • Vantaggi di spessori di provisioning di storage su sottili provisioning con macchine virtuali
  • Come formattare come FAT32 da Windows 7 / Vista
  • Come viene fatturato lo storage Amazon S3?
  • HP Smart arrays P812i e custodia di stoccaggio D2700 BAD PERFORMANCE
  • 7 Solutions collect form web for “Come cambiano IOPS di storage in risposta alla capacità del disco?”

    Per rispondere direttamente alla tua domanda – tutte le altre cose sono uguali = nessun cambiamento quando cambia GB.

    Non misurate IOPS con GB. Si utilizza il tempo di ricerca e la latenza.

    Potrei ri-scrivere tutto qui, ma questi esempi di seguito fanno tutto quello che già e lo ripeto semplicemente: http://www.ryanfrantz.com/posts/calculating-disk-iops/

    http://www.big-data-storage.co.uk/how-to-calculate-iops/

    http://www.wmarow.com/strcalc/

    http://www.thecloudcalculator.com/calculators/disk-raid-and-iops.html

    So che probabilmente è una questione ipotetica … Ma il mondo IT non funziona in questo modo. Ci sono vincoli realistici da considerare, oltre a altre cose che possono influenzare IOPS …

    • I dischi 50GB e 100GB non esistono più. Pensate di più: 72, 146, 300, 450, 600, 900, 1200 GB nei dischi aziendali e 500, 1000, 2000, 3000, 4000, 6000 GB nei media di storage in prossimità / midline.

    • C'è tanta astrazione nell'archivio moderno; la memorizzazione del caching del disco, la memorizzazione del controller, lo scaricamento SSD, ecc., che potrebbero essere difficili da individuare le differenze.

    • Hai diversi fattori di forma dell'unità, interfacce e velocità di rotazione da considerare. I dischi SATA hanno un profilo di performance diverso rispetto a SAS o SAS vicino . I dischi da 7.200 RPM si comportno in modo diverso da 10.000 RPM o 15.000 RPM. E la disponibilità delle varie velocità di rotazione è limitata a determinate capacità.

    • Disposizione del controller fisico. Gli espansori SAS, i controller RAID / SAS possono influenzare IOPS, a seconda del layout del disco, delle tariffe di sovraescrizione, se la connettività è interna al server o in un recinto esterno. Molti numbers di dischi SATA funzionano male sugli espansori e durante le condizioni di errore dell'azionamento .

    • Alcuni di questi possono essere influenzati dalla frammentazione, capacità utilizzata sull'arrays di dischi.

    • Hai mai sentito parlare di cortocircuito ?

    • Software contro RAID hardware, prefetching, profiling adattativo …

    Cosa ti port a credere che la capacità avrebbe avuto un impatto sulle performance in primo luogo? Puoi fornire più context?

    Edit:

    Se il tipo di disco, il fattore di forma, l'interface e la capacità utilizzata sono uguali, non ci dovrebbe essere alcuna differenza apprezzabile in IOPS. Diciamo che stavi andando da dischi SAS 10k da 300 GB a 600 GB. Con lo stesso numero di mandrini, non dovresti vedere nessuna differenza di performance …

    Tuttavia, se i dischi NetApp disporranno di utilizzare 6Gbps o 12Gbps SAS backplanes rispetto a un 3Gbps legacy, è ansible vedere un cambiamento di passaggio per andare a nuove attrezzature.

    Un luogo in cui esiste una relazione diretta tra la dimensione del disco e IOPS è nella Amazon AWS Cloud e in altri "servizi cloudy". Due tipi di servizi AWS ( Elastic Block Store e Relational Database Service ) forniscono IOPS più alti per size di disco più grandi.

    Si noti che si tratta di una restrizione artificiale posta da Amazon sui loro servizi. Non esiste alcun motivo legato all'hardware affinché questo sia il caso. Tuttavia, ho visto tipi devops che sono sconosciuti con hardware non virtualizzato credendo che questa restrizione sia appropriata anche per sisthemes desktop e simili. La dimensione del disco / rapporto IOPS è una restrizione di cloud marketing, non una restrizione hardware.

    Vorrei sottolineare che IOPS non sono una grande misura della velocità sulle scritture sequenziali, ma lascia solo andare con esso.

    Sospetto che i tempi di ricerca e scrittura delle teste di disco siano abbastanza coerenti nonostante le size dei dischi. 20 anni fa stiamo usando tutti i dischi da 60GB con (ugualmente – certamente non lineariamente) le stesse velocità di lettura / scrittura.

    Sto facendo una congettura educata, ma non penso che la densità del disco si riferisca linearmente alle performance del disco.

    Ad esempio, prendi un arrays con dischi da 10 X 100GB.

    Misura IOPS per le scritture a blocchi sequenziali da 256 kb (o qualsiasi metrica IOPS)

    Supponiamo che il risultato IOPS misurato sia 1000 IOPS.

    ok

    Cambiare l'arrays per uno con 10 X 200GB dischi. Formato con la stessa configuration RAID, la stessa dimensione del block, ecc.

    Ci si aspetterebbe che il IOPS rimanga lo stesso, aumentare o diminuire?

    Probabilmente rimangono ugualmente equivalenti l'una all'altra.

    Il cambiamento sarebbe grossolanamente lineare?

    La storia dei mezzi di filatura mi dice che probabilmente non c'è relazione.

    Ripetere queste domande con dischi da 10 X 50GB

    Ancora una volta, approssimativamente equivalente.

    La tua velocità, in tutti questi casi, deriva dal fatto che il RAID agisce come un singolo disco con dieci teste di scrittura, in modo da poter submit 1 / 10th del lavoro in parallelo a ciascun disco.

    Mentre non ho numbers difficili da mostrarvi, la mia esperienza passata mi dice che aumentare le performance dei dischi non è abbastanza semplice da get maggiori capacità.

    Nonostante ciò che le persone di marketing vi dicono è l'innovazione, prima dell'avvio di dischi a stato solido a basso costo (er), negli ultimi 20 anni non vi è stato un piccolo sviluppo significativo nella performance dei media di filatura, presumibilmente c'è solo tanto che si può uscire dalla rust e solo così velocemente possiamo get i nostri templates attuali di teste per il disco.

    La prestazione aggiunta alle scale di stoccaggio con each mandrino aggiunto. La velocità di rotazione dell'azionamento è il fattore più grande, quindi aggiungendo un drive RPM da 10k darà maggiori performance (in termini di I / O in IO random o MB / s in streaming IO) rispetto a un'azionamento RPM da 7.2k. La dimensione dell'unità non ha praticamente alcun effetto.

    La gente dice che piccoli azionamenti vanno più veloci semplicemente perché richiedono più mandrini per TB utilizzabile. Aumentando la dimensione dell'azionamento di questi mandrini, non diminuirà le performance, ma ti permetterà di accoppiare più dati sui dischi, il che può comportre un aumento del carico di lavoro.

    Se si presume che tutto il resto sia uguale, le caratteristiche di performance dei dischi di maggiore capacità non cambiano molto. Un drive RPM da 10K ha caratteristiche molto simili, indipendentemente dal fatto che sia 300GB o 3TB. I piatti ruotano allo stesso ritmo e le teste cercano la stessa velocità.

    Anche il passaggio continuo – non c'è molta differenza. Questa è la radice di molti problemi di performance, come in molti casi, le persone acquistano terabyte, non comprano IOP o MB / sec.

    E ci vorrà 10 volte più tempo per ribuild o copiare un'unità da 3 TB come unità da 300 GB.

    In realtà abbiamo dovuto considerare una sovraccapacità sostanziale per i progetti di archiviazione – i formati dell'unità sono ancora in crescita, ma la loro capacità di performance non è molto. Così in alless un caso, abbiamo comprato ~ 400TB di memory per riempire un requisito di 100TB, perché abbiamo bisogno dei mandrini.

    Se state ruotando i dischi (non SSD) e tutto il resto è uguale, la velocità di trasferimento è maggiore se si utilizzano le tracce esterne del disco. Ciò avverrebbe automaticamente se si utilizza un disco che viene solo riempito parzialmente. Allo stesso tempo, se un disco è solo parzialmente riempito, il movimento medio della testa sarebbe minore e il numero di movimenti della testa sarebbe minore perché ci sono più dati per traccia.

    È vero se si utilizza un singolo disco o un'unità RAID.

    Ora se state confrontando dischi da 100GB e 2000GB, puoi essere sicuro che tutto il resto non è uguale. Ma se lo stesso fornitore offre 500 GB, 1 TB, 1,5 TB e 2 TB con uno, due, tre e quattro piatti, allora tutto il resto è probabile che sia uguale e 10 x 500 GB sarà più lento di 10 x 2 TB per memorizzare 4 TB di dati (non ci sarà differenza se memorizzi solo 100 GB, perché i dischi da 500 GB saranno anche quasi vuoti).

    Ma per le unità RAID, non sarai tanto limitato dalla velocità di trasferimento, ma da latenza di rotazione. Quindi più alto RPM sarà più importnte. E troverai spesso un RPM superiore con una minore capacità. D'altra parte, se si va con RPM elevato / bassa capacità, allora si potrebbe anche guardare unità SSD.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.