SSD + raid0 - не все так просто

Вступ
Колеги з сусіднього відділу (UCDN) звернулися з досить цікавою і несподіваною проблемою: при тестуванні raid0 на великому числі SSD, продуктивність змінювалася ось таким ось сумним чином:

По осі X — число дисків в масиві, по осі Y — мегабайт в секунду.

Я почав вивчати проблему. Первинний діагноз був простий — апаратний рейд не впорався з великим числом SSD і уперся в свій власний стеля по продуктивності.

Після того, як апаратний рейд викинули і на його місце поставили HBA, а диски зібрали в raid0 з допомогою linux-raid (його часто називають 'mdadm' за назвою) — утиліти командного рядка, ситуація покращилася. Але не пройшла повністю-цифри зросли, але все ще були нижче розрахункових. При цьому ключовим параметром були не IOPS'и, а багатопотокова лінійна запис (тобто великі шматки даних, записуваних в випадкові місця).

Ситуація для мене була незвичайною — я ніколи не ганявся за чистим bandwidth рейдів. IOPS'и — наше все. А тут — треба многомногомного в секунду і більше.

Пекельні графіки
Я почав з визначення baseline, тобто продуктивності одиничного диска. Робив я це, швидше, для очищення совісті.

Ось графік лінійного читання з одного SSD.



Побачивши результат я реально піднявся. Тому що це дуже сильно нагадувало хитрощі, на які йдуть виробники дешевих USB-флешок. Вони поміщають швидку пам'ять у райони розміщення FAT (таблиці) в FAT32 (файлової системи) і більш повільну — в район зберігання даних. Це дозволяє трохи виграти по продуктивності при роботі з дрібними операціями з метаданими, при цьому припускаючи, що користувачі, які копіюють великі файли по-перше готові почекати, а по-друге, самі операції будуть відбуватися великими блоками. Детальніше про це несамовитий явище: lwn.net/Articles/428584/

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

Хоча мене збентежила версія ядра на стенді 3.2. По своєму попередньому досвіду знаючи прикрі особливості LSI, що змінюють в драйверах (mpt2sas) від версії до версії буквально все, я подумав: «а раптом»?

Трохи передісторії. mpt2sas — драйвер LSI для HBA. Живе неймовірно бурхливим життям, почавши з версії з версії v00.100.11.15 через версії 01.100.0x.00 дійшовши аж до версії 16.100.00.00 (цікаво, що означає цифра «100»?). За цей час драйвер відзначився перестановкою букв імен дисків при оновленні мінорній версії ядра, що відрізняється від аносируемого біос порядком дисків, падіннями на «несподіваних» конфігураціях LUN'ів, на таймаутах бэкплейна, на несподіваному числі дисків, логгинг помилок в dmesg зі швидкістю нескінченного циклу в самому ядрі (де-факто це еквівалент зависання системи) і тому подібні веселі речі.

Оновилися, запустили тест. І цей «раптом» трапився. Ось як виглядає той же графік на 3.14. А адже я трохи було не забракував невинні SSD'шки.



Після того, як продуктивність дисків стабілізувалася, був проведений другий тест: на всі диски запустили незалежні тести паралельно. Мета була проста — перевірити, чи немає пляшкового горлечка десь на шині або HBA. Продуктивність дисків виявилася цілком пристойною, «затыка» по шині не було. Основна задача була вирішена. Однак, графік продуктивності все-таки відрізнявся. Не сильно, але явно з натяком на гірше ніж лінійну швидкість запису.

Чому запис так себе веде по мірі числа дисків у масиві? Графік (на початку статті) дуже сильно нагадував графік продуктивності багатопоточних додатків по мірі зростання числа потоків, на які зазвичай показують програмісти і Intel'вівці, коли говорять про проблеми у взаємних блокувань тредів…

Під час тесту blktop спостерігалося щось дивне: частина дисків завантажена в стелю, частина майже простоює. Причому завантажені в стелю ті, хто показує низьку продуктивність, а «швидкі» диски простоюють. Більш того, диски іноді міняються місцями — тобто раніше завантажений на 100% диск раптом показує велику швидкість і меншу завантаження, і навпаки, диск, який був завантажений на 50%, раптом виявляється завантажений на 100% і при цьому показує меншу швидкість. Чому?

І тут до мене дійшло.

raid0 залежить від latency гіршого з дисків
Якщо ми пишемо багато даних, то запис зазвичай йде великими шматками. Ці шматки поділяються на менші шматки драйвером raid0, який записує їх одночасно на всі диски з raid0. За рахунок цього ми отримуємо N-кратне збільшення продуктивності. (Raid0 на N дисків).

Але давайте розглянемо запис докладніше…

Припустимо, у нас raid використовує chunk'і розміром 512k. У масиві 8 дисків. Додаток хоче записати багато даних, і ми пишемо raid шматками по 4Мб.

Тепер слідкуйте за руками:
  1. raid0 отримує запит на запис, ділить дані на 8 шматків по 512кб кожен
  2. raid0 відправляє (паралельно) 8 запитів на 8 пристроїв запису 512кб (кожен свою)
  3. raid0 очікує підтвердження від всіх 8 пристроїв про завершення запису
  4. raid0 відповідає додатком «записав» (тобто повертає управління з виклику write())
Уявімо тепер, що у дисків запис відбувся за такий час (в мілісекундах):
Диск 1 Диск 2 Диск 3 Диск 4 Диск 5 Диск 6 Диск 7 Диск 8
4.1 2.2 1.9 1.4 1.0 9.7 5.4 8.6
Питання: за який час відбудеться запис блоку в 4Мб на цей масив? Відповідь: за 9.7 мс. Питання: яка буде в цей час утилізація диск №4? Відповідь: близько 10%. А диск №6? 100%. Зауважимо, для прикладу я вибрав найбільш екстремальні значення лода операцій, але і при меншому розходженні проблема буде зберігатися. Порівняйте графік читання і запису (наводжу ту ж картинку ще раз):


Бачите, як нерівно гуляє запис в порівнянні з читанням?

У SSD дисків latency на запис дуже нерівна. Пов'язано це з їх внутрішнім пристроєм (коли за раз записується блок великого розміру, при необхідності, переміщаючи і переносячи дані з місця на місце). Чим більше цей блок, тим сильніше піки latency (тобто тимчасові провали в продуктивності). У звичайних магнітних дисків графіки зовсім інші — вони нагадують рівну лінію практично без відхилень. У разі послідовного лінійного IO ця лінія проходить високо, у разі постійного випадкового IO — постійно низько, але ключове — постійно. Latency у жорстких дисків передбачувана, latency SSD — немає. Зауважимо, ця властивість є у всіх дисків. У найдорожчих latency виявляється зміщена (або дуже швидко, або дуже-дуже швидко) — але різнобій все одно зберігається.

При таких коливаннях latency продуктивність SSD, в середньому, відмінна, але в окремі моменти часу запис може зайняти трохи більше, ніж в інший час. У тестованих дисків вона падала в цей момент до ганебних величин близько 50 мб/с (що нижче, ніж лінійна запис у сучасних HDD в два рази).

Коли на пристрій запити йдуть стопкою і незалежно, це не впливає. Ну так, один запит виконався швидко, інший повільно, в середньому все добре.

Але якщо запис залежить від всіх дисків у масиві? У цьому випадку, будь-який «тормознувший» диск гальмує всю операцію повністю. В результаті, чим більше дисків масиві, тим більше ймовірність, що хоча б один диск відпрацює повільно. Чим більше дисків, тим більше крива продуктивності їх суми в raid0 починає наближатися до суми продуктивності їх мінімумів (а не середніх значень, як хотілося б).

Ось графік реальної продуктивності в залежності від числа дисків. Рожева лінія — передбачення, що базуються на середній продуктивності дисків, синя — фактичні результати.


У разі 7 дисків відмінності становили близько 10%.

Просте математичне симулирование (з даними за latency реального диска для ситуації безлічі дисків в масиві) дозволило передбачити, що в міру збільшення числа дисків деградація може дійти до 20-25%.

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

Що краще — HDD або SSD?
Відразу скажу: найгірше очікування від SSD виявляється краще, ніж постійне від HDD (якщо прозвучало занадто складно: SSD краще, ніж HDD).

Інша справа, що масив з 20-30 HDD — це нормально. 30 SSD в raid0 викличуть слинки у гиків і напад печінкової коліки у фінансового відділу. Тобто зазвичай порівнюють безліч HDD c кількома HDD. Якщо ж ми отнормируем цифри по IOPS'ам (охохо), тобто доб'ємося від HDD тих же папуг, що від SSD, то цифри стануть, раптово, іншими — масив з великого числа HDD буде сильно обганяти масив з декількох SSD по швидкості запису.

Інша справа, що великий масив з HDD — це вже екстрим іншого роду, і там чекають сюрпризи з-за загального використання шини, продуктивності HBA і особливостей поведінки бекплейнів.

А raid1/5/6?
Легко зрозуміти, що для всіх цих масивів проблема з очікуванням самого повільного» зберігається, і навіть дещо посилюється (тобто проблема виникає при меншому розмірі блоку і меншої інтенсивності навантаження).

Висновок
Админское: Не люблю LSI. При виявленні яких-небудь нарікань в роботі дисків за участю LSI в системі налагодження слід починати з версії порівняння поведінки різних версій дравйера mpt2sas. Це як раз той випадок, коли зміна версії може впливати на продуктивність і стабільність самим драматичним чином.

Академічне: При плануванні високонавантажених систем з використанням SSD в raid0 слід враховувати, що чим більше в масиві SSD, тим сильніше стає ефект від нерівномірного latency. По мірі зростання числа пристроїв в raid0 продуктивність пристрою починає прагнути до добутку числа пристроїв на мінімальну продуктивність дисків (а не середню, як хотілося б очікувати).

Рекомендації: у випадку з подібним типом навантаження слід намагатися вибирати пристрої з мінімальним розкидом по latency на запис, по можливості використовувати пристрої з більшою ємністю (для зменшення числа пристроїв).

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.