Огляд системи зберігання IBM FlashSystem 900

Огляд і тестування флеш сховища від IBM FlashSystem 900. Фото, базові принципи і трохи синтетичних тестів всередині.

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

Технічні характеристики

Базові принципи

Дана система зберігання є флеш масивом зі збільшеною швидкодією за рахунок використання модулів MicroLatency і оптимізації технології MLC.

Коли я запитав нашого пресейла, які технології використовуються для забезпечення відмовостійкості і скільки ж насправді гігабайтів заховано всередині (IBM заявляє 11,4 Тб чистого простору), він відповів ухильно.

Як виявилося, все не так просто. Всередині кожного модуля розташовуються чіпи пам'яті і 4 FPGA контролера на них побудований Raid c змінним страйпом (Variable Stripe RAID, VSR).

Внутрішності модуля, дві двобудронні плати

У кожен чіп модуля ділять на так звані шари. На кожному N-шарі всіх чіпів, всередині модуля будується Raid5 змінної довжини.

При виході з ладу одного шару на чіпі довга страйпа зменшується, і бита комірка пам'яті перестає використовуватися. За рахунок надлишкової кількості комірок пам'яті корисний обсяг зберігається. Як з'ясувалося, на системі набагато більше 20 Тб сирого флешу, тобто майже на рівні Raid10, і за рахунок надлишковості ми обходимося без перебудови всього масиву при виході з ладу одного чіпа.

Отримавши Raid на рівні модуля FlashSystem об'єднує модулі в стандартний Raid5 (якщо цей пост набере 20 лайків до 1 січня домовлюся з усіма про проведення випробування з примусовим вилученням модуля при максимальному навантаженні)).

Таким чином, для досягнення потрібного рівня відмовостійкості, з системи з 12 модулями по 1,2 Тб (маркування на модулі) ми отримуємо трохи більше 10 Тб.

Веб-інтерфейс системи

Так, виявився старим знайомим (привіт кластерам v7k) з моторошною функцією витягування локалі з браузера. У FlashSystem інтерфейс управління схожий з Storwize, але вони істотно відрізняється за функціоналом. У FlashSystem софт служить для налаштування і моніторингу, а прошарок софтверний (віртуалізатор) як у сторвайзу відсутній, оскільки системи призначені для різних завдань.

Тестування

Після отримання системи від партнера, виробляємо установку системи в стійку і підключення в поточну інфраструктуру. Чесно кажучи, коли тримаєш в руках дану залізку, висотою в 2 юніта і розумієш, що всередині помістилося 1 100 000 іопсів і, одночасно, пачка кілозеленого паперу, висотою в ті ж 2 юніта, інстинктивно закликаєш колегу для надання допомоги в її переміщенні.

Підключаємо СГД відповідно до заздалегідь узгодженої схеми, налаштовуємо зонінг і перевіряємо доступність з середовища віртуалізації. Дале- готуємо лабораторний стенд. Стенд складається з 4х блейд серверів, підключеними до тестованого СГД двома незалежними 16 Гбітними оптичними фабриками.

Схема з "єднання

Оскільки моя організація здає в оренду віртуальні машини, то в тесті буде оцінюватися продуктивність однієї віртуальної машини і цілого кластера віртуалок під керуванням vSphere 5.5.

Трохи оптимізуємо наші хости: налаштуємо багатопоточність (roundrobin і ліміт кількості запитів), також збільшимо глибину черги на драйвері FC HBA.

Параметри ESXi

Наші налаштування можуть відрізнятися від ваших!

На кожному блейд сервері створюємо по одній віртуальній машині (16ГГц, 8 Гб RAM, системний диск 50 Гб). До кожної машини підключимо 4 жорстких диска (кожен на своєму Flash місяці і на своєму Paravirtual контролері).

Параметри ВМ

У тестуванні розглянемо синтетичне тестування малим блоком 4К (читання/запис) і великим блоком 256К (читання/запис). СГД стабільно віддавала 750к IOPS, що для мене виглядало дуже непогано, незважаючи, на заявлену виробником космічну цифру в 1,1М IOPS. Не забуваємо, що все прокачується через гіпервізор і драйвера ОС.

Графіки IOPS, затримок і, як мені здається notrim

1 ВМ, Блок 4к, 100% читання, 100% випадково. При наданні всіх ресурсів з однієї віртуальної машини, графік продуктивності вів себе нелінійно і стрибав в межах від 300к до 400к IOPS. В середньому, ми отримали близько 400k IOPS:

4 ВМ, Блок 4к, 100% читання, 100% випадково:

4 ВМ, Блок 4к, 0% читання, 100% випадково:

4 ВМ, Блок 4к, 0% читання, 100% випадково, через 12 годин. Просадки в продуктивності я не побачив.

1 ВМ, блок 256к, 0% читання, 0% випадково:

4 ВМ, Блок 256к, 100% читання, 0% випадково:

4 ВМ, Блок 256к, 0% читання, 0% випадково:

Максимальна пропускна здатність системи (4 ВМ, Блок 256к, 100% читання, 0% випадково):

Так само зазначу, що, як і у всіх відомих вендорів заявлена продуктивність досягається тільки в тепличних лаборатоних умовах (величезна кількість SAN аплінків, специфічна розбивка LUN, використання виділених серверів з RISK архітектурою і спеціально сконфігурованими програмами - генераторами навантаження).

Висновки

Плюси: величезна продуктивність, простота налаштування, доброзичливий інтерфейс.

Мінуси: За межами ємності однієї системи, масштабування здійснюється додатковими полицями. «Просунута» функціональність (знімки, реплікація, компресія) винесена в шар віртуалізації зберігання. IBM побудував чітку ієрархію СГД, на чолі якої віртуалізатор зберігання (SAN Volume Controller або Storwize v7000), який забезпечить багаторівневість, віртуалізацію і централізоване управління вашої мережі зберігання.

Підсумок: IBM Flashsystem 900 виконує свої завдання з обробки сотень тисяч IO. У поточній тестовій інфраструктурі вдалося отримати 68% продуктивності, заявленої виробником, що дає вражаючу щільність продуктивності на ТБ.