Як змінюються IOPS для зберігання у відповідь на ємність диска?

За інших рівних умов, як змінилася продуктивність IOPS масиву зберігання, якби використовували більші диски.

Наприклад, візьміть масив з 10 X 100GB дисками.

Виміряйте IOPS для послідовного запису блоком 256 кб (або будь-якого показника IOPS)

Припустимо, отриманий вимірюваний показник IOPS становить 1000 IOPS.

Змініть масив на один з 10 X 200GB дисками. Формат з однаковою конфігурацією RAID, однаковим розміром блоку тощо

Чи можна було б очікувати, що IOPS залишиться колишнім, збільшиться чи зменшиться? Чи буде зміна приблизно лінійною? тобто збільшити на 2 рази або зменшити на 2 рази (оскільки я збільшив ємність диска на 2 рази)

Повторіть ці запитання на 10 X 50GB дисках.

Редагувати: Більше контексту

Це запитання виникла як розмова моєї команди Sysadmin, яка недостатньо добре розбирається у сховищах. (Зручно з багатьма аспектами зберігання даних, але не з деталями управління SAN або будь-яким іншим). Ми отримуємо велику купу нових лотків Netapp, які мають більшу ємність диска на диск - подвійну ємність - ніж наші існуючі лотки. У коментарі з’явилося, що IOPS нових лотків буде нижчим лише тому, що диски були більшими. Потім пояснив це аналогією автомобіля. Жоден коментар не сидів зі мною, тому я хотів запустити його до команди, тобто Stack-Exchange-land.

Аналогія автомобіля була дещо про два автомобілі, з різним прискоренням, однаковою максимальною швидкістю та пробігом чверті милі. Потім змініть відстань на півмилі. Насправді я не можу пригадати точну аналогію, але, оскільки я знайшов ще одну аналогічну інтервебз, я зрозумів, що це, мабуть, загальна аналогія IOPS.

У чомусь, відповідь на це питання для мене не має великого значення, оскільки ми не використовуємо цю інформацію для оцінки покупки. Але нам потрібно оцінити найкращий спосіб прикріпити лотки до існуючої головки та найкращий спосіб вирізати агрегати та обсяги.

Щоб відповісти на ваше запитання безпосередньо - всі інші рівні речі = нічого не змінюйте, коли змінюється GB.

Ви не вимірюєте IOPS з GB. Ви використовуєте час пошуку та затримку.

Я міг би переписати це все тут, але ці приклади нижче роблять все це вже, і я просто повторюю це:

https://ryanfrantz.com/posts/calculating-disk-iops.html

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

Я знаю, що це, мабуть, гіпотетичне питання ... Але ІТ-світ насправді не працює так. Є реальні обмеження, які слід враховувати, а також інші речі, які можуть впливати на IOPS ...

• Диски розміром 50 ГБ та 100 ГБ насправді вже не існують. Подумайте більше: 72, 146, 300, 450, 600, 900, 1200 Гб на корпоративних дисках та 500, 1000, 2000, 3000, 4000, 6000 ГБ у близько- середній / середній лінії масового зберігання.

• У сучасному сховищі стільки абстракції; кешування диска, кешування керування, завантаження SSD тощо, що будь-які відмінності важко було б помітити.

• У вас є різні фактори приводу, інтерфейси та швидкості обертання. Диски SATA мають інший профіль продуктивності, ніж SAS або ближній лінії SAS . 7200RPM диски поводяться інакше, ніж 10 000RPM або 15 000RPM. А наявність різних швидкостей обертання обмежена певними можливостями.

• Макет фізичного контролера. Розширювачі SAS, контролери RAID / SAS можуть впливати на IOPS, залежно від компонування диска, швидкості переписки, незалежності від внутрішнього зв’язку із сервером чи у зовнішньому корпусі. Велика кількість дисків SATA погано спрацьовує на розширювачах та під час помилок накопичувача .

• На деяке з цього може вплинути фрагментація, використана ємність на масиві дисків.

• Ви коли-небудь чули про короткочасне погладжування ?

• Програмне забезпечення проти апаратного RAID, попереднє завантаження, адаптивне профілювання ...

Що змушує вас вірити , що потенціал матиме ніякого впливу на продуктивність в першу чергу? Чи можете ви надати більше контексту?

Редагувати:

Якщо тип диска, форм-фактор, інтерфейс та використана ємність однакові, то в IOPS не повинно бути помітної різниці. Скажімо, ви збиралися від 300 Гб до 600 Гб корпоративних дисках SAS 10k. З тим же числом шпинделя ви не повинні бачити різниці в продуктивності ...

Однак, якщо на згадуваних вами дисках NetApp використовуються 6Gbps або 12Gbps SAS задні плати порівняно зі застарілими 3Gbps, ви можете побачити зміну пропускної здатності для переходу на нове обладнання.

Одне місце , де знаходиться прямий зв'язок між розміром диска і IOPS знаходиться в Amazon AWS Cloud і інших «хмарних послуг». Два типи послуг AWS ( Elastic Block Store і Relational Database Service ) забезпечують більш високі IOPS для великих розмірів дисків.

Зауважте, що це штучне обмеження, поставлене Amazon на їхні послуги. Немає жодних апаратних причин для цього. Однак я бачив типи девепсів, які не знайомі з невіртуалізованим обладнанням, вважаючи, що це обмеження є відповідним також для настільних систем тощо. Співвідношення розміру диска / IOPS є обмеженням хмарного маркетингу, а не апаратним обмеженням.

Я мушу зазначити, що IOPS не є великим вимірюванням швидкості у послідовних записах, але давайте просто переходимо до цього.

Я підозрюю, що час пошуку та запису головок дисків є цілком послідовним, незважаючи на розмір дисків. 20 років тому ми всі використовуємо диски розміром 60 Гб із (приблизно - звичайно не лінійно) однаковими швидкостями читання / запису.

Я роблю освіту здогадуюсь, але не думаю, що щільність диска лінійно залежить від продуктивності диска.

Наприклад, візьміть масив з 10 X 100GB дисками.

Виміряйте IOPS для послідовного запису блоком 256 кб (або будь-якого показника IOPS)

Припустимо, отриманий вимірюваний показник IOPS становить 1000 IOPS.

гаразд

Змініть масив на один з 10 X 200GB дисками. Формат з однаковою конфігурацією RAID, однаковим розміром блоку тощо

Чи можна було б очікувати, що IOPS залишиться колишнім, збільшиться чи зменшиться?

Ймовірно, залишаються приблизно рівнозначними один одному.

Чи буде зміна приблизно лінійною?

Історія прядильних ЗМІ говорить про те, що, мабуть, стосунків немає.

Повторіть ці запитання на 10 X 50GB дисках

Знову ж таки, приблизно рівнозначно.

Ваша швидкість у всіх цих випадках пов'язана з тим, що RAID діє як один диск з десятьма записами, тому ви можете відправляти 1/10 роботи паралельно кожному диску.

Хоча у мене немає важких цифр, щоб показати вам, мій досвід минулого показує мені, що збільшити продуктивність ваших дисків не так просто, як отримати більшу ємність.

Незважаючи на те , що маркетингові люди говорять вам , це інновація, перед початком дешевого (ер) твердотільні дисків досягнуто незначний значний розвиток у виконанні спінінга засобів масової інформації протягом останніх 20 років, ймовірно , Theres тільки так багато ви можете отримати з іржі і тільки настільки швидко ми можемо запустити наші діючі моделі головки дисків.

Продуктивність додається до масштабів зберігання з кожним доданим шпинделем. Швидкість обертання накопичувача є найбільшим фактором, тому додавання накопичувача в 10 кП / м дасть більшу продуктивність (з точки зору IO / s у випадковому IO або MB / s при потоковому введенні IO), ніж приводом 7,2k RPM. Розмір накопичувача практично не впливає.

Люди кажуть, що невеликі накопичувачі працюють швидше просто тому, що вам потрібно більше шпинделів на одну туберкульозну кількість. Збільшення розміру приводу цих шпинделів не призведе до зниження продуктивності, але це дозволить помістити більше даних на диски, що може призвести до збільшення завантаженості.

Якщо ви вважаєте, що все інше однакове, експлуатаційні характеристики дисків більшої ємності не сильно змінюються. Привід FC 10K RPM має дуже схожі характеристики незалежно від того, чи є це 300 Гб або 3 ТБ. Блюдо обертається з однаковою швидкістю, а голови шукають з однаковою швидкістю.

Підтримана пропускна здатність також - не велика різниця. Це корінь багатьох проблем із продуктивністю, хоча, як і у багатьох випадках, люди купують терабайти, вони не купують IOP або MB / sec.

І для відновлення / копіювання накопичувача 3 ТБ як накопичувача на 300 ГБ знадобиться 10 разів.

Ми насправді мусили розглянути значну перевищення місткості проектів для зберігання даних, як результат - розміри накопичувачів все ще зростають, але їх продуктивність не дуже велика. Так що принаймні в одному випадку ми купили ~ 400 ТБ пам’яті, щоб заповнити потребу в 100 ТБ, оскільки нам потрібні шпинделі.

Якщо ви обертаєте диски (не SSD), то при всіх інших рівнях швидкість передачі вища, якщо ви використовуєте зовнішні доріжки диска. Це станеться автоматично, якщо ви будете використовувати диск, який лише частково заповнений. У той же час, якщо диск буде заповнений лише частково, ваш середній рух головою був би меншим, а кількість рухів головою було б меншим, оскільки на трек є більше даних.

Це правда, чи використовуєте ви один диск або привід RAID.

Тепер, якщо ви порівнюєте диски розміром 100 ГБ і 2000 ГБ, ви можете бути впевнені, що все інше не дорівнює. Але якщо той самий виробник пропонує накопичувачі 500 ГБ, 1 ТБ, 1,5 ТБ і 2 ТБ з однією, двома, трьома і чотирма пластинами, то все інше, швидше за все, буде рівним, і 10 х 500 ГБ буде повільніше, ніж 10 х 2 ТБ для зберігання 4 ТБ даних (різниці не буде, якщо ви будете зберігати лише 100 ГБ, оскільки накопичувачі на 500 ГБ також будуть майже порожніми).

Але для RAID-накопичувачів ви будете обмежені не швидкістю передачі, а затримкою обертання. Тож більш високі RPM будуть важливішими. І ви часто знайдете більш високий об / хв разом із меншою ємністю. З іншого боку, якщо ви працюєте з високою частотою обертів / малою ємністю, ви також можете подивитися на SSD-накопичувачі.