Тестування флеш СГД. Violin 6232 Series Flash Memory Array

    Продовжуємо тему, розпочату в статтях " Тестування флеш СГД. Теоретична частина " і " Тестування флеш СГД. IBM RamSan FlashSystem 820 " . Сьогодні ми розглянемо можливості однієї з найбільш «масових» моделей компанії Violin Memory. Стартап, заснований вихідцями з Fusion-io , став першопрохідцем і духовним лідером ідеології побудови систем зберігання даних виключно на основі флеш-пам'яті. Масив Violin 6232 був випущений у вересні 2011 року і пробув флагманом аж до виходу моделі 6264 в серпні 2013 року.
 
 
 
Нас, як технічних фахівців, в більшій мірі, зацікавила архітектура масивів Violin Memory, що є їх характерною особливістю і безперечною перевагою в порівнянні з конкурентами. Кожен компонент — це власна розробка компанії :
 
     
  • Власні flash модулі (VIMM);
  •  
  • Власна операційна система VMOS, оптимізована для роботи з flash;
  •  
  • Власний запатентований RAID (vRAID), позбавлений недоліків стандартних RAID 5,6.
  •  
Система без єдиної точки відмови, де всі компоненти продубльовані. Де заміна компонентів або оновлення прошивки ні тільки не вимагають зупинки роботи, але і не знижують продуктивності: 4 контролера, відсутність внутрішнього кеша, запис повними «страйп», оптимальні алгоритми «збору сміття». Така архітектура дозволяє отримати найвищу продуктивність, мінімізувати затримки і побічні явища (Write Cliff), забезпечує доступність даних рівня 99,9999 і нівелює втрати продуктивності при можливому виході компонентів з ладу. Багатий, продуманий інтерфейс управління гармонійно додає зручності роботи.
 
 Методика тестування
У ході тестування вирішувалися такі завдання:
 
     
  • досліджувати процес деградації продуктивності СГД при тривалому навантаженні на запис (Write Cliff) і читання;
  •  
  • досліджувати продуктивність СГД Violin 6232 при різних профілях навантаження;
  •  
  • дослідження впливу розміру блоку LUN на продуктивність.
  •  
<habracut/>
 

Конфігурація тестового стенда

     
   
  
Малюнок 1. Структурна схема тестового стенда
Тестовий стенд складається з сервера, підключеного через FC фабрику чотирма сполуками 8Gb FC до СГД Violin 6232. Характеристики сервера і масиву наступні: Сервер IBM 3630 M4 (7158-AC1) ; <Abbr title = "Сира ємність: 32TiB
Форматована ємність: 18,56 TiB
Інтерфейси підключення: 8x FC 4-8Gb
Кількість флеш-модулів (дані + HS): 60 +4
Версія мікропрограми: G5.6.0 "> СГД Violin Memory 6232
В якості додаткового програмного забезпечення на тестовий сервер встановлений Symantec Storage Foundation 6.1, який реалізує:
 
     
  • функціонал логічного менеджера томів (Veritas Volume Manager);
  •  
  • функціонал отказоустойчивого підключення до дискових масивів (Dynamic Multi Pathing). (Для тестів групи 1 і 2. Для тестів групи 3 використовується нативний Linux DMP)
  •  
 Подивитися виснажливі подробиці і всякі розумні слова. На тестовому сервері виконані настройки, спрямовані на зниження латентності дискового введення-виведення:
 
     
  • змінений планувальник вводу-виводу з
    cfq
    на
    noop
    через привласнення значення noop параметру
    /sys/<путь_к_устройству_Symantec_VxVM>/queue/scheduler
  •  
  • доданий параметр в
    /etc/sysctl.conf
    минимизирующий розмір черги на рівні логічного менеджера томів Symantec:
    vxvm.vxio.vol_use_rq = 0
    ;
  •  
  • збільшено межу одночасних запитів вводу-виводу на пристрій до 1024 через привласнення значення 1024 параметру
    /sys/<путь_к_устройству_Symantec_VxVM>/queue/nr_requests
  •  
  • відключена перевірка можливості злиття операцій в / в (iomerge) через привласнення значення 1 параметру
    /sys/<путь_к_устройству_Symantec_VxVM>/queue/nomerges
  •  
  • збільшено розмір черги на FC адаптерах шляхом додавання в конфігураційний файл
    /etc/modprobe.d/modprobe.conf
    опції
    ql2xmaxqdepth=64 (options qla2xxx ql2xmaxqdepth=64)
    ;
  •  
На СГД виконані конфігураційні налаштування за разбиению дискового простору: для всіх тестів створюється 8 LUN однакового обсягу. Їх сумарний об'ємом покриває всю корисну ємність дискового масиву. Для тестів групи 2 розмір блоку LUN встановлюється 512B, для тестів групи 3 розмір блоку LUN встановлюється 4KB. Створені LUN презентуються тестового серверу.
 

Програмне забезпечення, що використовується в процесі тестування

Для створення синтетичної навантаження (виконання синтетичних тестів) на СГД використовується утиліта Flexible IO Tester (fio) версії 2.1.4. При всіх синтетичних тестах використовуються наступні конфігураційні параметри fio секції [global]:
 
     
  • thread = 0
  •  
  • direct = 1
  •  
  • group_reporting = 1
  •  
  • norandommap = 1
  •  
  • time_based = 1
  •  
  • randrepeat = 0
  •  
  • ramp_time = 10
  •  
Для зняття показників продуктивності при синтетичної навантаженні застосовуються такі утиліти:
 
     
  • iostat, що входить до складу пакету sysstat версії 9.0.4 з ключами
    txk
    ;
  •  
  • vxstat, що входить до складу Symantec Storage Foundation 6.1 c ключами
    svd
    ;
  •  
  • vxdmpadm, що входить до складу Symantec Storage Foundation 6.1 c ключами
    -q iostat
    ;
  •  
  • fio версії 2.1.4, для формування зведеного звіту по кожному профілю навантаження.
  •  
Зняття показників продуктивності під час виконання тесту утилітами iostat, vxstat, vxdmpstat проводиться з інтервалом 5с.
 
 Програма тестування.
Тестування складалося з 3-х груп тестів. Тести виконувалися шляхом створення синтетичної навантаження програмою fio на блокове пристрій (block device), що представляє собою логічний тому типу «stripe» з розшаруванням по 8 дискам, розміром блоку даних — 1MiB, створений з використанням Veritas Volume Manager або Native Linux LVM (в 3 групі ) з 8-ми LUN, презентованих з тестованої системи.
 
 Поцікавитися подробицями
Група 1: Тести, реалізують тривале навантаження типу random write із зміною розміру блоку операцій введення / виводу (в / в).
При створенні тестового навантаження використовуються такі додаткові параметри програми fio:
 
     
  • rw = randwrite
  •  
  • blocksize = 4K
  •  
  • numjobs = 64
  •  
  • iodepth = 64
  •  
Група тестів складається з чотирьох тестів, що відрізняються сумарним обсягом LUN, презентованих з тестованої СГД, розміром блоку операцій в / в і напрямом в / в (write або read):
 
     
  • тест на запис, що виконується на повністю розміченому СГД, — сумарний обсяг презентованих LUN дорівнює корисної ємності СГД, тривалість тесту — 7.5 годин;
  •  
  • тести на запис із змінним розміром блоку (4,32,1024 K), що виконується на повністю розміченому СГД, тривалість кожного тесту — 4.5 години. Пауза між тестами — 2 години.
  •  
За результатами тестів на підставі даних виведених командою vxstat формуються графіки, що суміщають результати тестів:
 
     
  • IOPS як функція часу;
  •  
  • Latency як функція часу.
  •  
Проводиться аналіз отриманої інформації та робляться висновки про:
 
     
  • наявності деградації продуктивності при тривалому навантаженні на запис і на читання;
  •  
  • продуктивності сервісних процесів СГД (Garbage Collection), що обмежують продуктивність дискового масиву на запис при тривалій піковому навантаженні;
  •  
  • ступеня впливу розміру блоку операцій в / в на продуктивність сервісних процесів СГД;
  •  
  • обсязі простору, резервовану на СГД для нівелювання сервісних процесів СГД.
  •  
 
Група 2: Тести продуктивності дискового масиву при різних типах навантаження, виконувані на рівні блокового пристрою, створеного засобами Symantec Volume Manager (VxVM) при розмірі блоку LUN — 512байт.
У ході тестування досліджуються такі типи навантажень:
 
     
  • профілі навантаження (змінювані параметри ПО fio: randomrw, rwmixedread):
  •  
     
  1. випадкова запис 100%;
  2.  
  3. випадкова запис 30%, випадкове читання 70%;
  4.  
  5. випадкове читання 100%.
  6.  
     
  • розміри блоку: 1кб, 8Кб, 16КБ, 32КБ, 64Кб, 1МБ (змінюваний параметр ПО fio: blocksize);
  •  
  • способи обробки операцій введення-виведення: синхронний, асинхронний (змінюваний параметр ПО fio: ioengine);
  •  
  • кількість процесів, генеруючих навантаження: 1, 2, 4, 8, 16, 32, 64, 128, 160, 192 (змінюваний параметр ПО fio: numjobs);
  •  
  • глибина черги (для асинхронних операцій введення-виведення): 32, 64 (змінюваний параметр ПО fio: iodepth).
  •  
Група тестів складається з набору тестів, що представляє собою всі можливі комбінації перерахованих вище типів навантаження. Для нівелювання впливу сервісних процесів СГД (Garbage Collection) на результати тестів, між тестами реалізується пауза дорівнює відношенню обсягу записаної в ході тесту інформації до продуктивності сервісних процесів СГД (визначається за результатами виконання 1-ої групи тестів).
За результатами тестів на підставі даних, що виводяться ПО fio по завершенню кожного з тестів, формуються такі графіки для кожної комбінації наступних типів навантаження: профілю навантаження, способу обробки операцій введення-виведення, глибини черги, що поєднують в собі тести з різними значеннями блоку вводу-виводу:
 
     
  • IOPS — як функція від кількості процесів, генеруючих навантаження;
  •  
  • Bandwidth — як функція від кількості процесів, генеруючих навантаження;
  •  
  • Latеncy (clat) — як функція від кількості процесів, генеруючих навантаження;
  •  
Проводиться аналіз отриманих результатів, робляться висновки про навантажувальних характеристиках дискового масиву при latency <1ms.
 
 
Група 3: тести продуктивності дискового масиву при синхронному способі в / в, різних типах навантаження, виконувані на рівні блокового пристрою, створеного засобами Linux LVM, при розмірі блоку LUN — 4KiB.
Тести проводяться аналогічно тестів групи 2, але досліджується тільки синхронний спосіб в / в через обмежений час тестування. По закінченні кожного тесту будуються графіки, що відображають різницю в% отриманих показників продуктивності (iops, latency) від показників, отриманих при тестуванні з розміром блоку LUN 512байт (група тестів 2). Робляться висновки про вплив розміру блоку LUN на продуктивність дискового масиву.
 
 
 Результати тестування
 
Група 1: Тести, реалізують тривале навантаження типу random write із зміною розміру блоку операцій введення / виводу (в / в).
1. При тривалому навантаженні на запис в певний момент часу фіксується значуща деградація продуктивності СГД. Падіння продуктивності очікувано і є особливістю роботи SSD (Write Cliff), пов'язаної з включенням процесів Garbage Collection (GC) і обмеженою продуктивністю позначених процесів. Продуктивність дискового масиву, фиксируемую при працюючих процесах GC, можна розглядати як максимальну середню продуктивність дискового масиву.
 Графіки     
   
  
Зміна швидкості операцій в / в (iops) і затримок (Latency) при тривалій записи блоком 4K
 
2. Розмір блоку при тривалому навантаженні на запис не впливає на продуктивність процесу GC. CG працює на швидкості порядку 600Mib / s.
 
3. Різниця в значеннях максимального часу роботи СГД на пікової продуктивності, що фіксується при першому тривалому тесті і наступному еквівалентному тесті з блоком 4К, обумовлена ​​не повною заполненностью СГД перед початком тестування.
 Графік     
   
  
Зміна швидкості в / в (iops) при тривалій записи блоками 4K, 32K
 
4. Максимальний час роботи СГД на пікової продуктивності значно відрізняється при блоці 4K і всіх інших блоках, що з великою ймовірністю обумовлено архітектурної оптимізації СГД під позначений блок (СГД Violin завжди пише повними stripe розміром 4K, використовуючи конфігурацію flash модулів RAID5 (4 + P), stripe unit size 1K).
 Графік і таблиця     
   
  
Зміна швидкості передачі даних (bandwidth) при тривалій запис різними розмірами блоку.
     
   
  
Залежність показників СГД від розміру блоку при тривалому навантаженні на запис.
 
 
Група 2: Тести продуктивності дискового масиву при різних типах навантаження, виконувані на рівні блокового пристрою, створеного засобами Symantec Volume Manager (VxVM) при розмірі блоку LUN — 512байт.
 Таблиці продуктивності блочного пристрою.     
   
  
Продуктивність СГД при одному процесі, генеруючому навантаження (jobs = 1)
     
   
  
Максимальна продуктивність СГД при затримках менше 1мс
     
   
  
Максимальна продуктивність СГД при різному профілі навантаження.

 Графіки продуктивності блочного пристрою. (Всі картинки клікабельні)
     
  
 
      
      
      
  
 Синхронним способом в / в асинхронним способом в / в з глибиною черги 32 асинхронним способом в / в з глибиною черги 64 При випадковому читанні
 
 

 
 

 
 
При випадкового запису
 
 

 
 

 
 
При змішаній навантаженні (70% читання, 30% запис)
 
 

 
 

 
 
 
 
     
  • Отримано приблизно однакова продуктивність масиву на читання і запис.
  •  
  • Не вдалося заявлену виробником продуктивність на операціях читання (заявляється максимально 500 000IOPS).
  •  
  • При змішаному введенні-виведенні масив показує продуктивність меншу, ніж окремо при записі і читанні практично при будь-якому профілі введення-виведення.
  •  
  • Фіксується значуще зниження продуктивності при блоці 8K на смешенном профілі навантаження при збільшенні кількості потоків введення-виведення. (Причина виявленого феномена на поточний момент не зрозуміла).
  •  
 

Максимально зафіксовані параметри продуктивності для Violin 6232

Запис:
 
     
  • 307000 IOPS при latency 0.8ms (блок 4KB async qd32)
  •  
  • Bandwidth: 2224МБ / c для великих блоків
  •  
Читання:
 
     
  • 256000 IOPS при latency 0,7 ms (блок 4KB sync);
  •  
  • 300000 IOPS при latency 6,7 ms (блок 4KB async qd 32);
  •  
  • Bandwidth: 2750МБ / с для середніх блоків (16-32K).
  •  
Змішана навантаження (70/30 rw)
 
     
  • 256000 IOPS при latency 0.7ms (блок 4KB sync);
  •  
  • 305000 IOPS при latency 6,7 ms (блок 4KB async qd 64);
  •  
  • Bandwidth 2700МБ / с для середніх блоків (16-32K)
  •  
Мінімально зафіксована latency:
 
     
  • При запису — 0,146 ms для блоку 4K jobs = 1
  •  
  • При читанні — 0,21 ms для блоку 4K jobs = 1
  •  
 
Група 3: тести продуктивності дискового масиву при синхронному способі в / в, різних типах навантаження, виконувані на рівні блокового пристрою, створеного засобами Linux LVM при розмірі блоку LUN — 4KiB.
 Графіки (Всі картинки клікабельні)
    
 
   
  
Різниця IOPS і Latency між пристроєм з розміром блоку LUN 4КБ і 512Б при випадковому читанні (показники при розмірі блоку LUN = 512Б прийняті за 0)
    
 
   
  
Різниця IOPS і Latency між пристроєм з розміром блоку LUN 4КБ і 512Б при випадкового запису (показники при розмірі блоку LUN = 512Б прийняті за 0)
    
 
   
  
Різниця IOPS і Latency між пристроєм з розміром блоку LUN 4КБ і 512Б при змішаному навантаженні (70/30 r / w) (показники при розмірі блоку LUN = 512Б прийняті за 0)
 
 
     
  1. Вплив розміру блоку LUN на продуктивність при кількості jobs до 64 відсутня.
  2.  
  3. При jobs> 64 на операціях запису спостерігається збільшення продуктивності до 20% в порівнянні з розміром блоку LUN 512B
  4.  
  5. При jobs> 64 на операціях читання середніми і великими блоками спостерігається зменшення продуктивності до 10-15%
  6.  
  7. При змішаній навантаженні дрібними і середніми блоками (до 32K) масив показує однакову продуктивність при обох розмірах блоку LUN. Але при великих блоках (64К і 1М) продуктивність поліпшується до 50% при використанні блоку LUN 4KiB
  8.  
 Висновки
В цілому, масив справив враження повноцінного пристрою high-end рівня. Нам вдалося отримати дуже непогані результати, проте, залишилося враження, що весь ресурс системи все ж вибрати не вдалося. Для створення навантаження використовувався один сервер з двома процесорами, які виявилися перевантажені в процесі тестування. З великою ймовірністю можна сказати, що ми швидше досягли межі можливостей навантажувального сервера, ніж випробовуваної системи зберігання.
 
 
 P.S. Автор висловлює сердечну подяку Павлу Катасонова, Юрію Ракітіну і всім іншим співробітникам компанії брали участь у підготовці даного матеріалу.
    
Джерело: Хабрахабр

0 коментарів

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