Картинка

БЛОГ про

все цікаве у світі телекомунікацій

Навіщо потрібна гіперконвергенція? Огляд і тести Cisco HyperFlex

2020-04-26
Автор: Телесфера

В ІТ головне - це три букви

Завдання будь-якої ІТ-інфраструктури зводиться до забезпечення надійної платформи для бізнес-процесів компанії. Традиційно вважається, що якість інформаційно-технологічної інфраструктури оцінюється за трьома основними параметрами: доступність, безпека, надійність. Однак оцінка по даній трійці ніяк не пов'язана з бізнесом і прямими доходами/втратами компанії.

В ІТ правлять три головні букви. Якщо на чолі ієрархії ІТ не стоять літери «RUB», значить ви будуєте свою ІТ-інфраструктуру неправильно. Звичайно, будувати безпосередньо ІТ, відштовхуючись лише від доходів/витрат, складно, тому існує ієрархія «трьох букв» - від найважливіших до більш приватним. SLA, RPO, RTO, GRC - все це фахівці в індустрії знають і давно використовують в побудові інфраструктур. На жаль, не завжди пов'язуючи ці показники в наскрізну ієрархію.

Багато компаній сьогодні будують інфраструктуру для майбутнього використовуючи вчорашні технології на позавчорашній архітектурі. І разом з тим, що прискорюється розвиток ІТ показує, що сучасні сервіси кардинально змінюють не тільки бізнес, а й суспільство - люди цифрової епохи звикли, що для доступу до будь-якої інформації достатньо кількох секунд. ІТ з незрозумілою Техномагия стало буденністю для широких мас, такий же як Бургерная або кав'ярня. Це додало нові надзвичайно важливі три букви в ІТ. Ці літери - TTM (Time to market) - час до запуску продуктивного сервісу на ринок.

SDS

З іншого боку, з глибин технологій піднімався кракен, який перевертає традиційні ІТ і уклад життя. У міру зростання обчислювальної потужності процесорів x86 першим щупальцем стали програмні системи зберігання даних. Класичні системи зберігання були дуже специфічним залізяччям, наповненим "замовленим кремнієм", різними апаратними пропрієтарними прискорювачами і спеціалізованим софтом. А адмініструвала її спеціально навчена людина, якій в компанії практично поклонялися як жерцеві темного культу. Розширити працюючу в компанії систему зберігання даних був цілий проект, з масою розрахунків і погоджень - адже дорого ж!

Дорожнеча і складність підстьобнули на створення програмних систем зберігання даних поверх звичайного x86 заліза зі звичайною ОС загального призначення - Windows, Linux, FreeBSD або Solaris. Від складної замовленої залізяки залишився тільки софт, який працює навіть не в ядрі, а на призначеному для користувача рівні. Перші програмні системи були звичайно досить прості і обмежені у функціональності, часто представляли собою спеціалізовані нішеві рішення, але час ішов. І ось вже навіть великі вендори систем зберігання почали відмовлятися від спеціалізованих апаратних рішень - TTM для таких систем вже не витримував конкуренції, а ціна помилки стала дуже висока. Фактично, за рідкісним винятком, навіть класичні системи зберігання до 2020 року стали самими звичайними x86 серверами, просто з красивими пластиковими мордочками і купою поличок з дисками.

Друге щупальце кракена, що  насувається - це поява і масове прийняття ринком технології флеш-пам'яті, яка і стала бетонним стовпом, що ламає спину слону.
Продуктивність магнітних дисків не змінювалася вже багато років і процесори контролерів СЗД цілком справлялися з сотнями дисків. Але на жаль, кількість рано чи пізно переходить в якість - і СЗД вже середнього рівня, не кажучи вже про початковий, має обмеження зверху по осмисленню кількості флеш-дисків. З певної кількості (буквально від десяти дисків) продуктивність системи не те що перестає рости, а ще може почати знижуватися через необхідність обробляти все більший обсяг. Адже обчислювальна потужність і пропускна здатність контролерів не змінюється зі зростанням міцності. Рішенням, по ідеї, стала поява scale-out систем, здатних збирати безліч незалежних полиць з дисками і процесорними ресурсами в єдиний кластер, що виглядає зовні як єдина багатоконтролерна СЗД. Залишався всього один крок.

Гіперконвергенція

Найочевиднішим кроком в майбутнє стало об'єднання до того розрізнених точок зберігання даних і їх обробки. Іншими словами, чому б не реалізувати розподілену СЗД не на окремих серверах, а прямо на хостах віртуалізації, відмовившись тим самим від спеціальної мережі зберігання і виділеного заліза, і поєднавши таким чином функції. Кракен прокинувся.
Але дозвольте, скажете ви, адже поєднання - це конвергенція. Звідки взялася ця дурна приставка гіпер?

Вперше з терміном конвергентні системи на ринок вриваються маркетологи. Під конвергентною системою продавалися звичайні класичні сервери + СЗД + комутатори. Просто під одним партномером. Або навіть не продавалися, а випускався папір під назвою "референсна архітектура".
...
Конвергентна архітектура, іншими словами, має на увазі використання одних і тих же апаратних сервісів як для виконання ВМ, так і для їх зберігання на локальних дисках. Ну а оскільки повинна бути відмовостійкість - в конвергентный архітектурі є шар розподіленої SDS.

Отримуємо:

  • Класична система - софт, СЗД, комутація та сервери йдуть з різних місць, поєднуються руками замовника/інтегратора. Окремі контракти на підтримку.
  • Конвергентна система - все з одних рук, єдина підтримка, єдиний партномер. Не плутати з самосбором від одного вендора.

І, виходить, що термін під нашу конвергентну архітектуру вже зайнятий. Рівно та ж ситуація, що з супервізором.

Гіперконвергентна система - конвергентна система з конвергентною архітектурою.

Визначення взяті зі статті "Загальна теорія і археологія віртуалізації".

Що ж дає гіперконвергентний підхід в додатку до згаданих трьох літер?

  • Старт з мінімального обсягу (і мінімальних витрат)
  • Об'єм зберігання зростає разом з обчислювальною потужністю
  • Кожен вузол системи є її контролером - і знімається проблема "скляної стелі" (диски можуть, а контролер уже ні)
  • Різко спрощується управління підсистемою зберігання

За останній пункт гіперконвергентні системи дуже не люблять старорежимні адміністратори систем зберігання даних, які звикли адмініструвати черги на портах Fibre Channel. Виділення простору відбувається буквально в кілька кліків миші з консолі управління віртуальною інфраструктурою.

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

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

Cisco Hyperflex

Чому Cisco

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

Дивно, але до 2020 року все ще знаходяться люди: "Сервери Cisco? А у кого вона їх бере? "
Серверами Cisco почала займатися аж у 2009 році, вибравши шлях блейд-рішень, що активно росли в той час. Ідея Cisco полягала в тому, щоб реалізувати підхід анонімних обчислювачів. В результаті вийшла система UCS (Unified Computing System), що складається з двох спеціалізованих комутаторів (їх назвали Fabric Interconnect), і від 1 до 20 шасі (8 лез половинного розміру) або до 160 серверів. Шасі при цьому стало взагалі тупо залізякою з живленням, вся логіка і комутація винесена в Fabric Interconnect; шасі - просто спосіб розмістити сервери і підключити їх до системи. Fabric Interconnect відповідає повністю за всю взаємодію серверів із зовнішнім світом - і Ethernet, і FC, і управління. Здавалося б, блейд і блейд, що тут такого, крім зовнішньої комутації, а не як у всіх в рамках шасі.

Ключовий момент у реалізації тих самих "анонімних обчислювачів". В рамках концепції Cisco UCS у серверів немає ніякої індивідуальності, крім серійного номера. Ні MAC, ні WWN, ні чого небудь ще. Система управління UCS, що працює на Fabric Interconnect, побудована на базі серверних профілів і шаблонів. Після підключення пачки серверів в шасі їм необхідно призначити відповідний профіль, в рамках якого і задаються всі ідентифікуючі адреси і ідентифікатори. Звичайно, якщо серверів у вас всього з десяток, то не варта була б шкурка вичинки. Але коли їх хоча б два, а то і цілих три десятки - це вже серйозна перевага. Стає просто і швидко мігрувати конфігурації, або, що набагато важливіше, тиражувати серверні конфігурації в потрібній кількості, застосовувати зміни відразу до великої кількості серверів, по суті керуючи набором серверів (наприклад, фермою віртуалізації) як одним об'єктом. Підхід, запропонований в рамках UCS-системи, дозволяє при правильному підході серйозно спростити життя адміністраторам, підвищити гнучкість і помітно знижує ризики, тому блейд UCS буквально за 2-3 роки стали найбільш продаваною блейд-платформою в Західній півкулі, а в світовому масштабі є сьогодні однією з двох домінуючих платформ, поряд з HPE.

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

Сьогодні я буду говорити про HyperFlex - гіперконвергентне рішення від Cisco, побудоване на серверах, підключених до Fabric Interconnect. Що робить HyperFlex цікавим і гідним розгляду в огляді:

  • У рішенні Cisco ми можемо спостерігати, так би мовити, «супер» гіперконвергенцію - на відміну від більшості інших рішень на ринку, мережева інфраструктура є невіддільною частиною HyperFlex; мережа налаштовується автоматично при запуску, і, поряд з серверами, гіпервізором і ПЗ зберігання потрапляє під парасольку підтримки HyperFlex як єдиного закінченого рішення;
  • Дедуплікація і компресія - на ринку гіперконвергенціі наявністю цих функцій особливо нікого не здивувати; специфікою HyperFlex є те, що вони включені постійно, в тому числі на гібридних конфігураціях; всі тести продуктивності проводяться завжди з включеними дедуплікацією і компресією, і це варто враховувати при аналізі результатів.
  • Масштабованість «в різні боки» - або просто додаванням дисків «на льоту», або додаванням в кластер вузлів з дисками, або додаванням в кластер вузлів без дисків;
  • А також інтеграція в рамках однієї і тієї ж пари Fabric Interconnect з іншими серверами Cisco в будь-яких форм-факторах, можливість інтеграції з існуючими SAN мережами, в тому числі і на базі native FC;
  • Висока доступність і катастрофостійкість "іскаропкі" - асинхронна реплікація, розтягнутий кластер, інтеграція із засобами резервного копіювання;
  • Оскільки мережеве обладнання Cisco не просто є в багатьох ЦОД, а є стандартом, використання гіперконвергенціі від того ж вендора може бути цікавим як з технічної, так і з фінансової точки зору;
  • Якщо вірити аналітикам, а ми їм звичайно ж віримо, Cisco є одним з трьох лідируючих постачальників ПО HCI, зростає швидше за всіх в процентному співвідношенні, HyperFlex досить широко поширений і в світі, і в Росії, і країнах СНД.

Принцип роботи

HyperFlex - це справжня гіперконвергентна система з виділеними контролерними ВМ. Нагадаю, що принципова перевага такої архітектури - потенційна портабельнысть під різні гіпервізори. На сьогодні у Cisco реалізована підтримка VMware ESXi і Microsoft Hyper-V, але цілком можливо що з'явиться і один з варіантів KVM у міру зростання його популярності в корпоративному сегменті.

Розглянемо механізм роботи на прикладі ESXi.

У контролерну ВМ (далі CVM) безпосередньо прокинуті пристрої за технологією VM_DIRECT_PATH - кешуючий диск і диски рівня зберігання. Тому виключаємо вплив дискового стека гипервизора на продуктивність. У сам гипервизор встановлюються додаткові VIB пакети:

  • IO Visor: забезпечує точку монтування NFS датастора для гіпервізора
  • VAAI: забезпечує інтеграцію VMware з API для «розумних СЗД»

Блоки віртуальних дисків розподіляються рівномірно по всім хостам в кластері з відносно невеликою гранулярністю. Коли ВМ на хості виробляє якісь дискові операції, через дисковий стек гіпервізора операція йде в датастор, далі в IO Visor, а він далі звертається до CVM, що відповідає за дані блоки. При цьому CVM може перебувати на будь-якому хості в кластері. В умовах дуже обмежених ресурсів IO Visor ніяких таблиць метаданих зрозуміло там немає і вибір обумовлений математично. Далі CVM, до якої прийшов запит, його обробляє. У випадку з читанням - віддає дані або з одного з рівнів кешування (оперативна пам'ять, кеш на запис, кеш на читання) або з дисків свого хоста. У випадку з записом - пише в локальний журнал, і дублює операцію на одну (RF2) або дві (RF3) CVM.

Мабуть, цього цілком достатньо для розуміння принципу роботи в рамках даної публікації, а інакше буду забирати хліб у тренерів Cisco, і буде мені соромно. Насправді ні, але все одно достатньо.

Питання про синтетичні тести

- Штурман, прилади!
- 36!
- Що 36?
- А що прилади?

Приблизно так на сьогодні виглядає більшість синтетичних тестів систем зберігання даних. Чому так?

До відносно недавнього часу більшість СЗД були плоскими з рівномірним доступом. Що це означає?

Загальне доступний дисковий простір було зібрано з дисків з однаковими характеристиками. Наприклад 300 дисків 15k. І продуктивність була однаковою по всьому простору. З появою технології багаторівневого зберігання, СЗД стали неплоскими - продуктивність розрізняється усередині одного дискового простору. Причому не просто різниться, а ще й непередбачуване, в залежності від алгоритмів і можливостей конкретної моделі СЗД.

І все було б не так цікаво, не з'явися гіперконвергентні системи з локалізацією даних. Крім нерівномірності самого дискового простору (тірінгі, флеш кеші) з'являється ще й нерівномірність доступу до нього - в залежності від того, на локальних дисках вузла лежить одна з копій даних або за нею необхідно звертатися по мережі. Все це призводить до того, що цифри синтетичних тестів можуть бути абсолютно будь-якими, і ніяк не говорити ні про що практично значуще. Як наприклад витрата палива у автомобіля по рекламній брошурі, який вам ніколи не вдасться досягти в реальному житті.

Питання про сайзінге

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

Як відомо, без виразного ТЗ - результат ХЗ.

З практичного досвіду - при сайзінгу досить важкої гіперконвергентної системи в конкурсі у одного з замовників я особисто після пілота зняв показники навантаження з системи і порівняв їх з тим, що було написано в ТЗ. Вийшло як в анекдоті:

- Рабінович, а правда, що ви таки виграли мільйон в лотерею?
- Ой ну хто вам таке сказав? Чи не мільйон, а десять рублів, не в лотерею, а в преферанс, і не виграв, а програв.

Іншими словами, класична ситуація GIGO - Garbage In Garbage Out - Сміття на вході = Сміття на виході.

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

Є ще один момент з сайзінгом і оцінкою специфікацій. Різні системи по-різному побудовані і по-різному працюють з дисками, по-різному взаємодіють їх контролери. Тому практично безглуздо порівнювати "лоб-в-лоб" по специфікаціям кількість і обсяг дисків. У вас є якесь ТЗ, в рамках якого ви розумієте рівень навантаження. І далі є деяка кількість КП, в рамках яких вам пропонують різні системи, що задовольняють вимогам по продуктивності і надійності. Яка принципова різниця, скільки саме варто дисків і якого типу в системі 1, і що в системі 2 їх більше/менше, якщо і та й інша успішно справляється із завданням.

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

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

Про снапшоти

HyperFlex вміє робити свої «нативні» снапшоти віртуальних машин за технологією Redirect-on-Write. І ось тут треба зупинитися окремо для розгляду різних технологій снапшотів.
Спочатку існували снапшоти типу Copy-on-Write (CoW), як класичний приклад можна взяти нативні снапшоти VMware vSphere. Принцип роботи, що з vmdk поверх VMFS або NFS, що з нативними файловими системами типу VSAN, один і той же. Після створення CoW снапшотів оригінальні дані (блоки або файли vmdk) заморожуються, а при спробі запису в заморожені блоки створюється їх копія і дані пишуться вже в новий блок/файл (дельта файл для vmdk). В результаті у міру зростання дерева снапшотів збільшується кількість "паразитних" звернень до диску, що не несуть ніякого продуктивного сенсу, і падає продуктивність/зростають затримки.

Потім були придумані снапшоти Redirect-on-Write (RoW), в яких замість створення копій блоків з даними створюється копія метаданих, а запис просто йде далі без затримок і додаткових читань і перевірок. При правильній реалізації RoW снапшоти мають практично нульовий вплив на продуктивність дискової системи. Другим ефектом роботи з метаданими замість самих живих даних є не тільки моментальне створення снапшотів, але і клонів ВМ, які відразу після створення взагалі не займають місця (системний оверхед на службові файли ВМ не вважаємо).

І третій, ключовий момент, радикально відрізняє RoW від CoW снапшотів для продуктивних систем - це моментальне видалення снапшотів. Здавалося б, що тут такого? Однак треба згадати як працюють CoW снапшоти і що видалення снапшотів насправді не видалення дельти, а її комміт. І ось тут час її коммітов надзвичайно залежить від розміру накопиченої дельти і продуктивності дискової системи. RoW снапшоти коммітів моментально просто тому що скільки б терабайт різниці не накопичилося, видалення (комміт) RoW снапшотів - це оновлення таблиці метаданих.

І ось тут з'являється цікаве застосування RoW снапшотів - впустити RPO до значень в десятки хвилин. Робити бекапи кожні 30 хвилин в загальному випадку практично нереально, а в більшості випадків їх роблять взагалі раз на добу, що дає RPO 24 години. Але ми при цьому можемо просто робити RoW снапшоти за розкладом, доводячи RPO до 15-30 хвилин, і зберігати їх добу-дві. Без штрафу до продуктивності, витрачаючи тільки ємність.

Але є деякі нюанси.

Для коректної роботи нативних снапшотів і інтеграції з VMware, HyperFlex вимагає наявності службового снапшоту, який називається Sentinel. Sentinel снапшот створюється автоматично при першому створенні снапшотів для даної ВМ через HXConnect, і його не варто видаляти, до нього не варто «повертатися», потрібно просто змиритися з тим, що в інтерфейсі в списку снапшотів найпершим йде цей службовий снапшот Sentinel.

Снапшоти HyperFlex можуть виконуватися в режимі «crash-consistent», або в режимі «application-consistent". Другий тип передбачає «скидання буферів» всередині ВМ, вимагає наявність VMTools, і запускається якщо в меню створення снапшотів в HXConnect поставити галочку «Quiesce».
Крім снапшотів HyperFlex, ніхто не забороняє використання «рідних» снапшотів VMware. Варто для конкретної віртуальної машини визначитися, які снапшоти ви будете використовувати, і в подальшому на цю технологію орієнтуватися, «не змішуючи» для однієї ВМ різні снапшоти.

В рамках тесту я також намагався створити снапшоти і перевіряти їх FIO. І таки да, можу підтвердити що снапшоти дійсно RoW, на продуктивність не впливають. Снапшоти дійсно створюються швидко (кілька секунд в залежності від профілю навантаження і розміру датасету), за результатами можу дати таку рекомендацію: якщо у вашому навантаженні багато випадкових операцій запису, то слід запускати створення снапшотів з інтерфейсу HXConnect, з галочкою "Quiesce" і з попередньою наявністю снапшотів Sentinel.

Тести

Тестова платформа

У цупки лапи потрапила наступна платформа:

  • 4 x C220 M4 (2630v4 10c x 2.20 GHz, 256, 800 + 6 * 960)
  • vSphere 6.7
  • HX Data Platform 4.0.2

Тест для чітких пациків

Яке ж тестування без КрісталДіску? Правильно, такого бути не може, нормальні пацани завжди крісталдиск запускають! Ну чо, раз треба - значить треба.

Для кристал диску створена спеціально ВМ з 2 vCPU 4GB і Windows 7 на борту. Ох і замучився я на неї патчі ставити, я вам скажу! Тест проведено в кращих традиціях кращих будинків Лондона і Парижу - а саме просто доданий один віртуальний диск next-next-finish без всяких думок і запущений тест. Так, і до речі, зрозуміло сам CrystalDiskMark не займається тестуванням, це просто інтерфейс, а безпосередньо навантажує дискову систему всім відомий пакет DiskSpd, включений в комплект.

Що мені буквально кинулося в очі - це вибір одиниць віміру в правому верхньому куті, який чомусь усіма пропускається. І алле-ап!

Слухайте, ну чесно скажу - взагалі не очікував від мікромашинки в режимі next-next-finish 75 тис IOPS і більше 1 гігабайта в секунду!

Подальші тести проводилися за допомогою VMware HCI Bench і Nutanix XRay, як "ідеологічно ворожі" HyperFlex'у і відповідно, очікувалося, що полонених не беремо. Цифри виявилися надзвичайно близькі, тому в якості основи взяті результати від пакета XRay просто тому що у нього більш зручна система звітності і готові шаблони навантажень.

Achtung! Uwaga! Pozor!

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

FourCorners Microbenchmark

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

Підсумкові цифри: 280k/174k IOPS, 3.77/1.72 GBps (читання/запис)

Як же поводилися наші контролери?

З чого можна помітити, що сумарне споживання ресурсів на 4 контролера і 4 ВМ навантаження склало 49 ядер по 2.2. За статистикою VMware завантаження CPU контролерів була до 80%, тобто фактично продуктивність була обмежена продуктивністю контролерів, а конкретно процесорів. Швидкість же послідовних операцій конкретно вперлася в швидкість 10G мережі.

Давайте спробую ще раз. Пікова продуктивність на маленькому 4-х вузловому кластері з не найшвидшими процесорами 2.2GHz майже 300 тис IOPS в 4U висоти.

Розмова "а ось у нас більше/менше на 10, 20 або навіть 40%" практично позбавлена сенсу через порядок цифр. Те ж саме як почати мірятися "а у мене машина може 240, у мене 280" при тому, що обмеження 80.

280k / 4 вузли дає пікову продуктивність 70k / вузол, що наприклад перевищує цифри з калькулятора VMware VSAN, який вважає, що вузол AF видає не більше 46k на дискову групу. У нашому ж випадку тут в термінології VMware якраз одна дискова група, фактично працює на швидкості x1,8.

Вплив розміру блоку датастора

При створенні датастора HyperFlex можна вибрати розмір блоку даних - 4к або 8к.

На що це вплине? Запустимо все той же чотирикутний тест.

Якщо з читанням картина практично ідентична, то ось запис навпаки, має значення. Чотирикутний тест використовує навантаження 8k.

Підсумкові цифри: 280k/280k, 172-158k/200-180k (4k 8k). При збігу розміру блоку виходить + 15% продуктивності на запис. Якщо у вас передбачається значна кількість запису малим блоком (4k) в навантаженні - створюйте датастор для саме цього навантаження з блоком 4k, інакше використовуйте 8k.

OLTP Simulator

Значно більш близьку до реальності картину дає інший тест. В рамках нього запускають два генератора з профілем, наближеним до транзакційної СУБД і рівнем навантаження 6000 + 400 IOPS. Тут вимірюється затримка, яка повинна залишатися на стабільно низькому рівні.

Затримка для ВМ навантаження становила 1.07 / 1.08 мс. В цілому відмінний результат, але давайте додамо спеки!

Database Colocation: High Intensity

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

Отже, OLTP база на вузлі 1 генерує 4200 IOPS при 0.85 мс затримки. Що ж відбувається після того як DSS система раптово починає віджирати ресурси на послідовних операціях?
Два генератора на вузлах 2 і 3 навантажують платформу на 1.18 / 1.08 GBps відповідно, ті 2.26 GBps сумарно. Затримка на OLTP звичайно росте і стає менш плоскою, але середнє значення залишається 1.85мс, і свої 4200 IOPS база отримує без будь-яких проблем.

Snapshot Impact

Система послідовно робить кілька миттєвих знімків раз на годину на OLTP базі. Нічого дивного в графіку немає, і більше того - це взагалі показник як працюють класичні снапшоти VMware, оскільки Nutanix XRay не вміє працювати з нативними снапшотами крім своїх власних. Не треба на регулярній основі користуватися снапшоами vSphere, адже не всі йогурти однаково корисні.

Нативні снапшоти HyperFlex працюють значно краще, користуйтеся ними, і ваше волосся стане м'яким і шовковистим!

Big Data Ingestion

А як HyperFlex переварить велику кількість даних, залитих послідовно? Ну скажімо 1ТБ.

Тест зайняв 27 хвилин, включаючи клонування, установлення та роботу генераторів.

Throughput Scalability

А тепер поступово завантажимо весь кластер і подивимося на цифри, що встановилися. Для початку випадковим читанням, потім записом.

Спостерігаємо стабільну картину з поступовим зниженням продуктивності на машину навантаження з 78k до 55-57k IOPS, з рівними полицями. При цьому відбувається стабільне зростання загальної продуктивності з 78 до 220k IOPS.

Запис йде трохи менш гладкими, але все ж стабільними полками від 64k до 19-21k на машину. При цьому рівень навантаження на контролери значно нижче. Якщо при читанні загальний рівень завантаження процесорів виріс з 44 до 109, то на записи з 57 до 73 GHz.

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

Ламаємо OLTP

До цього часу навіть нудно стало наскільки передбачуваний HyperFlex. Терміново треба що-небудь зламати!

Червоною крапкою відзначений момент виключення контролерної ВМ на одному з вузлів з навантаженням.

Оскільки за замовчуванням ребілд в HyperFlex починається відразу тільки при втраті диска, а при втраті вузла таймаут 2 години, то зеленою крапкою відзначений момент примусового ребілду.

login as: admin
 HyperFlex StorageController 4.0 (2a)
admin@192.168.***.***'s password:
<B> admin @ SpringpathController0VY9B6ERXT: ~ $ </ b> stcli rebalance status
rebalanceStatus:
    percentComplete: 0
    rebalanceState: cluster_rebalance_not_running
rebalanceEnabled: True
<B> admin @ SpringpathController0VY9B6ERXT: ~ $ </ b> stcli rebalance start -f
msgstr: Successfully started rebalance
params:
msgid: Successfully started rebalance
<B> admin @ SpringpathController0VY9B6ERXT: ~ $ </ b> stcli rebalance status
rebalanceStatus:
    percentComplete: 16
    rebalanceState: cluster_rebalance_ongoing
rebalanceEnabled: True
<B> admin @ SpringpathController0VY9B6ERXT: ~ $ </ b>

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

Чому 2 години на думку Cisco не проблема, хоча у конкурентів є цифри і поменше? Cisco наполегливо рекомендують використовувати RF3 в якості базового рівня захисту даних для всього, крім машин, яких особливо не шкода. Ви вирішили поставити патчі або щось зробити з хостом, вимкнули його. І є шанс, що саме в цей момент вийде з ладу ще один хост - і тоді в разі RF2 все встане колом, а при RF3 залишиться одна активна копія даних. І так, дійсно, 2 години при аварії цілком можна пережити на RF2 поки не почнеться відновлення до RF3.

Ламай мене повністю!

Ламати - так ламати. Навантажимо по повній. В даному випадку я створив тест з профілем, що більш-менш нагадує реальне навантаження (70% read, 20% random, 8k, 6d 128q).

Вгадаєте де вимикалася CVM, а де почався ребілд?

У ситуації з ребілдом HyperFlex показав себе досить добре, не викликавши катастрофічного падіння продуктивності або багаторазового збільшення кількості затримок навіть при навантаженні під самі помідори. Єдине, чого дуже б хотілося - шановна Cisco, зробіть таймаут все таки поменше 2 годин за замовчуванням.

Висновки

Для висновків нагадаю цілі проведеного тестування: дослідити систему Cisco HyperFlex на сьогоднішній день, без розгляду історії, досліджувати її продуктивність з використанням синтетики і зробити висновки про її застосованість для реального продуктиву.

Висновок 1, по продуктивності. Продуктивність досить хороша, інших коментарів тут і не даси. Оскільки на тесті у мене була система хоч і попереднього покоління, тут можна сказати рівно одне - на HyperFlex All Flash ви впретеся в ємність, в процесор, в пам'ять, але не в диски. Крім хіба що 1% понаднавантажених додатків, але з ними і так розмову треба вести персонально. Нативні RoW снапшоти працюють.

Висновок 2, по доступності. Система після виявлення збою досить добре (без падіння продуктивності в рази) відпрацьовує відновлення кількості копій даних. Є невелика претензія в 2-годинному таймауті за замовчуванням до початку відновлення (при втраті хоста), але з урахуванням RF3, що наполегливо рекомендується , це скоріше причіпка. Відновлення після виходу з ладу диска починається відразу.

Висновок 3, за ціною і порівняно з конкурентами. Ціна на систему може варіюватися в рази залежно від конфігурації під конкретний проект. Величезну частку вартості проекту складе ліцензування системного і прикладного програмного забезпечення, яке буде працювати поверх інфраструктурної платформи. Тому єдиний варіант порівняння з конкурентами - це порівняння конкретних комерційних пропозицій, які відповідають технічним вимогам, конкретно для вашої компанії під конкретний проект.

Підсумковий висновок: система робоча, цілком зріла для застосування в продуктиві на квітень 2020 року, якщо рекомендації вендора читати і застосовувати, а не курити.

Джерело: https://habr.com/ru/company/cti/blog/497024/


Про компанію Телесфера Інтеграція.

Телесфера Інтеграція заснована в 2012 році та являється інтегратором новітніх технологічних рішень для бізнесу.  Ми розробляємо рішення, що роблять Ваш бізнес успішним.

Основні напрямки роботи компанії:

  • Побудова локальних обчислювальних мереж;
  • Налаштування мережевого обладнання передових виробників (Cisco Systems, Aruba Networks та інших);
  • Продаж телекомунікаційного обладнання;
  • Аудит локальних обчислювальних мереж;

e-mail: office@telesphera.net
Телефон: (093) 198-11-82

КОММЕНТАРІ ДО СТАТТІ

Cisco представила нові рішення в області мереж на основі намірів

Cisco представила нові рішення в області мереж на основі намірів
Cisco,Cisco Wi-Fi,Cisco Network,cisco,cisco безпека,Налаштування Cisco,новини,Послуги Телесфера Інтеграція

В ході конференції Cisco Live, яка вперше пройшла в онлайн форматі, компанія Cisco представила нові рішення в області мереж на основі намірів (IBN, Intent Based Networks). Ці продукти призначені для оптимізації мережевих і бізнес-операцій, вони спрямовані на автоматизацію різних процесів і надання аналітики, яка допоможе ІТ-службам підвищити гнучкість і краще координувати свою діяльність з бізнес-цілями компаній.

Aruba Edge Services Platform (ESP)

Aruba Edge Services Platform (ESP)
Aruba Networks,IoT,Налаштування Aruba,Налаштування,Налаштування Aruba Instant,новини

10 червня 2020 року стало відомо, що компанія Hewlett Packard Enterprise представила хмарну платформу на основі технологій штучного інтелекту - Aruba ESP (Edge Services Platform), яка прогнозує і вирішує проблеми на кордоні мережі до того, як вони виникнуть. Aruba ESP являє собою автоматизовану платформу, яка побудована на базі AIOps (штучний інтелект для управління ІТ) і реалізує модель «нульової довіри» (Zero Trust) для забезпечення мережевої безпеки.

Лінійка Aruba Instant On поповнилася новими комутаторами для малого бізнесу

Лінійка Aruba Instant On поповнилася новими комутаторами для малого бізнесу
Aruba Networks,Налаштування Aruba,Налаштування Aruba Instant,новини

Aruba, компанія Hewlett Packard Enterprise, оголосила про розширення лінійки продуктів Aruba Instant On за рахунок включення в нього комутаторів нової серії, які дозволяють малим підприємствам розгорнути єдину високошвидкісну мережу, просту в налаштуванні, управлінні і обслуговуванні. Нові комутатори Aruba Instant On 1930 легко інтегруються з існуючими точками доступу Aruba Instant On і можуть централізовано управлятися за допомогою мобільного додатку Instant On, незалежно від того, чи будуть вони розгорнуті для забезпечення безперервності ведення бізнесу або проекту по модернізації мережі.