Це міф, який досить поширений у сфері серверного заліза. Насправді ж гіперконвергентні рішення (коли все в одному) потрібні багато для чого. Історично склалося, що перші архітектури були розроблені Amazon та Google під свої сервіси. Тоді ідея була в тому, щоб зробити обчислювальну ферму з однакових вузлів, кожен з яких має власні диски. Все це поєднувалося якимось системотворчим софтом (гіпервізором) і розбивалося вже на віртуальні машини. Головне завдання — мінімум зусиль на обслуговування одного вузла і мінімум проблем при масштабуванні: просто докупили ще тисячу-другу таких серверів і підключили поруч. На практиці це поодинокі випадки, і набагато частіше йдеться про меншу кількість вузлів та трохи іншу архітектуру.
Але плюс залишається тим самим — неймовірна простота масштабування та управління. Мінус — різні завдання по-різному споживають ресурси, і десь локальних дисків буде багато, десь мало оперативної пам'яті тощо, тобто при різному типі завдань падатиме утилізація ресурсів.
Виходило, що ви платите на 10–15% більше за зручність налаштування. Це й викликало міф із заголовка. Ми довго шукали, де ж застосовуватиметься технологія оптимально, і знайшли. Річ у тім, що Циска не мала своїх СГД, але вони хотіли повний серверний ринок. І вони зробили Cisco Hyperflex – рішення з локальними сховищами на нодах.
А з цього раптово вийшло дуже гарне рішення для резервних дата-центрів (Disaster Recovery). Чому і як зараз розповім. І покажу випробування кластера.
Де потрібно
Гіперконвергенція – це:
- Перенесення дисків до обчислювальних вузлів.
- Повноцінна інтеграція підсистеми зберігання даних із підсистемою віртуалізації.
- Перенесення/інтеграція з мережевою підсистемою.
Така зв'язка дозволяє реалізовувати багато фічі СГД на рівні віртуалізації та все з одного вікна керування.
У нашій компанії дуже затребувані проекти з проектування резервних ЦОДів, і часто вибирається саме гіперконвергентне рішення через купу опцій реплікації (аж до метрокластера) з коробки.
У разі резервних ЦОД зазвичай йдеться про віддалений об'єкт на майданчику на іншому краю міста або взагалі в іншому місті. Він дозволяє відновити критичні системи у разі часткової чи повної відмови основного ЦОДу. Туди постійно реплікуються дані з прода, і ця реплікація може бути на рівні програми або на рівні блокового пристрою (СХД).
Тому зараз я розповім про будову системи та тести, а потім про пару сценаріїв реального застосування з даними по економії.
Тести
Наш екземпляр складається з чотирьох серверів, у кожному з яких 10 SSD-дисків на 960 ГБ. Є виділений диск для кешування операцій запису та зберігання сервісної віртуальної машини. Саме рішення – четверта версія. Перша відверто сира (судячи з відгуків), друга сирувата, третя вже досить стабільна, а цю можна назвати релізом після закінчення бета-тестування на широкій публіці. За час тестування проблем я не побачив, все працює як годинник.
Зміни до v4Виправлена купа багів.
Спочатку платформа могла працювати лише з гіпервізором VMware ESXi та підтримувала невелику кількість нод. Також процес розгортання далеко не завжди закінчувався успішно, доводилося перезапускати деякі кроки, були проблеми з оновленням зі старих версій, дані в GUI відображалися не завжди коректно (хоча я і зараз не в захваті від відображення графіків продуктивності), іноді виникали проблеми на стику з віртуалізацією .
Зараз усі дитячі болячки виправлені, HyperFlex вміє і ESXi, і Hyper-V, плюс до цього можливо:
- Створення розтягнутого кластеру.
- Створення кластера для офісів без використання Fabric Interconnect від двох до чотирьох нід (купуємо тільки сервери).
- Можливість роботи із зовнішніми СГД.
- Підтримка контейнерів та Kubernetes.
- Створення зон доступності.
- Інтеграція з VMware SRM, якщо вбудований функціонал не влаштовує.
Архітектура не дуже відрізняється від рішень основних конкурентів, велосипед створювати не стали. Працює це все на платформі віртуалізації VMware чи Hyper-V. Апаратно розміщується на серверах своєї розробки Cisco UCS. Є ті, хто ненавидить платформу за відносну складність початкового налаштування, безліч кнопочок, нетривіальну систему шаблонів і залежностей, але є й ті, хто пізнав дзен, перейнявся ідеєю і більше не хоче працювати з іншими серверами.
Ми розглянемо саме рішення для VMware, тому що рішення спочатку створювалося під нього і має більший функціонал, Hyper-V допили по ходу справи, щоб не відставати від конкурентів та відповідати очікуванням ринку.
Є кластер із серверів, набитих дисками. Є диски під зберігання даних (SSD або HDD - на ваш смак та потреби), є один SSD-диск для кешування. При записі даних на датастор відбувається збереження даних на шарі, що кеширує (виділений SSD-диск і RAM сервісної ВМ). Паралельно блок даних відправляється на ноди у кластері (кількість нод залежить від фактора реплікації кластера). Після підтвердження від усіх нод про успішний запис підтвердження запису відправляється в гіпервізор і далі - до ВМ. Записані дані у фоновому режимі дедуплікуються, стискаються та записуються на диски зберігання. При цьому на диски завжди пишеться великий блок і послідовно, що знижує навантаження на диски зберігання.
Дедуплікація та компресія включені постійно, і відключити їх не можна. Читання даних відбувається безпосередньо з дисків зберігання або кешу RAM. Якщо використовується гібридна конфігурація, читання також кешується на SSD-диску.
Дані не прив'язуються до поточного розташування віртуальної машини і рівномірно розподіляються між нодами. Такий підхід дозволяє однаково навантажити всі диски та мережеві інтерфейси. Напрошується очевидний мінус: ми не можемо максимально зменшити затримку читання, оскільки немає гарантії наявності даних локально. Але я вважаю, що це незначна жертва, порівняно з отриманими плюсами. Тим більше, затримки в мережі досягли таких значень, що практично не впливають на загальний результат.
За всю логіку роботи дискової підсистеми відповідає спеціальна сервісна технологія Cisco HyperFlex Data Platform controller, яка створюється на кожній ноді зберігання. У нашій конфігурації сервісної ВМ було виділено вісім vCPU та 72 ГБ RAM, що не так вже й мало. Нагадаю, що сам хост має в наявності 28 фізичних ядер та 512 ГБ RAM.
Сервісна ВМ має доступ до фізичних дисків безпосередньо за допомогою прокидання SAS-контролера у ВМ. Спілкування з гіпервізором відбувається через спеціальний модуль IOVisor, який перехоплює операції введення-виведення, та за допомогою агента, що дозволяє передавати команди в API гіпервізора. Агент відповідає за роботу з HyperFlex-сніпшотами та клонами.
У гіпервізор дискові ресурси монтуються як NFS- або SMB-куля (залежить від типу гіпервізора, вгадайте, де). А під капотом це розподілена файлова система, яка дозволяє додати фічі дорослих повноцінних СГД: тонке виділення томів, стиснення та дедуплікація, снепшоти за технологією Redirect-on-Write, синхронна/асинхронна реплікація.
Сервісна ВМ надає доступ до WEB-інтерфейсу керування підсистеми HyperFlex. Є інтеграція з vCenter, і більшість повсякденних завдань може бути виконана з нього, але датастори, наприклад, зручніше нарізати з окремої веб-сайту, якщо ви вже перейшли на швидкий HTML5-інтерфейс, або використовувати повноцінний Flash-клієнт з повною інтеграцією. У сервісній веб-сайті можна переглянути продуктивність і докладний статус системи.
Існує й інший вид нід у кластері – обчислювальні ноди. Це можуть бути рекові або блейд-сервери без убудованих дисків. На цих серверах можна запускати ВМ, дані яких зберігаються на серверах із дисками. З погляду доступу до даних різниці між типами нід немає, адже архітектура передбачає абстрагування від фізичного розташування даних. Максимальне співвідношення обчислювальних нід та нід зберігання - 2:1.
Використання обчислювальних нод збільшує гнучкість при масштабуванні ресурсів кластера: нам не обов'язково докуповувати ноди з дисками, якщо ми потребуємо лише CPU/RAM. До того ж ми можемо додати блейд-кошик та отримати економію на розміщенні серверів у стійці.
Як результат, у нас є гіперконвергентна платформа з наступними фічами:
- До 64 нід у кластері (до 32 нід зберігання).
- Мінімальна кількість нід у кластері – три (дві – для Edge-кластера).
- Механізм надмірності даних: дзеркаловання з фактором реплікації 2 та 3.
- Metro-кластер.
- Асинхронна реплікація ВМ інший HyperFlex-кластер.
- Оркестрація перемикання ВМ у віддалений ЦОД.
- Нативні снепшоти за технологією Redirect-on-Write.
- До 1 ПБ корисного простору за фактора реплікації 3 і без урахування дедуплікації. Чинник реплікації 2 не враховуємо, тому що це не варіант для серйозного прода.
Ще один величезний плюс - простота управління та розгортання. Усі складності налаштування серверів UCS бере на себе спеціалізована ВМ, підготовлена інженерами Cisco.
Конфігурація тестового стенду:
- 2 x Cisco UCS Fabric Interconnect 6248UP як керуючий кластер та мережеві компоненти (48 портів, що працюють в режимі Ethernet 10G/FC 16G).
- Чотири сервери Cisco UCS HXAF240 M4.
Характеристики серверів:
центральний процесор
2 x Intel® Xeon® E5-2690 v4
Оперативна пам'ять
16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/dual rank/x4/1.2v
мережу
UCSC-MLOM-CSC-02 (VIC 1227). 2 порти 10G Ethernet
Storage HBA
Cisco 12G Modular SAS Pass через Controller
Storage Disks
1 x SSD Intel S3520 120 GB, 1 x SSD Samsung MZ-IES800D, 10 x SSD Samsung PM863a 960 GB
Більше варіантів конфігураційОкрім обраного заліза, на даний момент доступні такі опції:
- HXAF240c M5.
- Один або два CPU, починаючи від Intel Silver 4110 до Intel Platinum I8260Y. Доступне друге покоління.
- 24 слоти пам'яті, планки від 16 GB RDIMM 2600 до 128 GB LRDIMM 2933.
- Від 6 до 23 дисків для даних, один диск, що кешує, один системний і один бутовий диск.
Capacity Drives
- HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
- HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
- Caching Drives
- HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
- HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
- HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
- HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD 10X endurance SAS 800 GB.
- HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X endurance).
System / Log Drives
- HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Requires upgrade).
Boot Drives
- HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.
Підключення до мережі через 40G, 25G або 10G порти Ethernet.
Як FI можуть бути HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).
Сам тест
Для тестування дискової підсистеми використовував HCIBench 2.2.1. Це безкоштовна утиліта, що дозволяє автоматизувати створення навантаження з кількох віртуальних машин. Саме навантаження генерується звичайним фіо.
Наш кластер складається з чотирьох нід, фактор реплікації 3, усі диски Flash.
Для тестування я створив чотири датастори та вісім віртуальних машин. Для тестів запису передбачається варіант, коли диск, що кешує, не переповнюється.
Результати тестів такі:
100% Read 100% Random
0 % Read 100%Random
Блок/глибина черги
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 ms 213804 IOPS
0,84 ms 303540 IOPS
1,36ms 374348 IOPS
2.47 ms 414116 IOPS
4,86ms 420180 IOPS
2,22 ms 57408 IOPS
3,09 ms 82744 IOPS
5,02 ms 101824 IPOS
8,75 ms 116912 IOPS
17,2 ms 118592 IOPS
8K
0,67 ms 188416 IOPS
0,93 ms 273280 IOPS
1,7 ms 299932 IOPS
2,72 ms 376,484 IOPS
5,47 ms 373,176 IOPS
3,1 ms 41148 IOPS
4,7 ms 54396 IOPS
7,09 ms 72192 IOPS
12,77 ms 80132 IOPS
16K
0,77 ms 164116 IOPS
1,12 ms 228328 IOPS
1,9 ms 268140 IOPS
3,96 ms 258480 IOPS
3,8 ms 33640 IOPS
6,97 ms 36696 IOPS
11,35 ms 45060 IOPS
32K
1,07 ms 119292 IOPS
1,79 ms 142888 IOPS
3,56 ms 143760 IOPS
7,17 ms 17810 IOPS
11,96 ms 21396 IOPS
64K
1,84 ms 69440 IOPS
3,6 ms 71008 IOPS
7,26 ms 70404 IOPS
11,37 ms 11248 IOPS
Напівжирним відзначені значення, після яких зростання продуктивності немає, іноді навіть помітна деградація. Пов'язано з тим, що упираємося у продуктивність мережі/контролерів/дисків.
- Послідовне читання 4432 МБ/с.
- Послідовний запис 804 МБ/с.
- При відмові одного контролера (відмова віртуальної машини чи хоста) просадка за продуктивністю — удвічі.
- При відмові диска зберігання - просідання на 1/3. Ребілд диска займає 5% ресурсів кожного контролера.
На маленькому блоці ми упираємося у продуктивність контролера (віртуальна машина), її CPU завантажений на 100%, при підвищенні блоку упираємося у пропускну спроможність портів. 10 Гбіт/с недостатньо для розкриття потенціалу AllFlash-системи. На жаль, перевірити роботу на 40 Гбіт/с не дозволяють параметри наданого демостенду.
На моє враження від тестів та вивчення архітектури, за рахунок алгоритму, що розміщує дані між усіма хостами, ми отримуємо масштабовану передбачувану продуктивність, але це є обмеженням при читанні, тому що з локальних дисків можна було б вичавлювати і більше, тут може врятувати більш продуктивну мережу, наприклад, доступні FI на 40 Гбіт/с.
Також один диск на кешування та дедуплікацію може бути обмеженням, фактично в даному стенді ми можемо писати на чотири SSD-диски. Було б добре мати можливість збільшувати кількість кешуючих дисків і побачити різницю.
Реальне використання
Для організації резервного ЦОД можна використовувати два підходи (розміщення бекапу на віддаленому майданчику не розглядаємо):
- Active-Passive. Всі програми розміщуються в основному ЦОДі. Реплікація синхронна чи асинхронна. У разі падіння основного ЦОД нам потрібно активувати резервний. Робити це можна вручну/скриптами/додатками оркестрації. Тут ми отримаємо RPO, порівнянний з частотою реплікації, і RTO залежить від реакції та умінь адміністратора та якості опрацювання/налагодження плану перемикання.
- Active-Active. У цьому випадку присутня тільки синхронна реплікація, доступність ЦОД визначається кворумом/арбітром, розміщеним строго на третьому майданчику. RPO = 0, а RTO може досягати 0 (якщо програма дозволяє) або дорівнює часу на відпрацювання відмови ноди в кластері віртуалізації. На рівні віртуалізації створюється розтягнутий (Metro) кластер, що потребує Active-Active СГД.
Зазвичай ми бачимо у клієнтів вже реалізовану архітектуру з класичною СГД в основному ЦОДі, тому проектуємо ще один для реплікації. Як я й згадував, Cisco HyperFlex пропонує асинхронну реплікацію та створення розтягнутого кластера віртуалізації. При цьому нам не потрібна виділена СГД рівня Midrange та вище з недешевими функціями реплікації та Active-Active доступу до даних на двох СГД.
Сценарій 1: У нас є основний та резервний ЦОДи, платформа віртуалізації на VMware vSphere. Усі продуктивні системи розташовуються переважно ЦОД, а реплікація віртуальних машин виконується лише на рівні гіпервізора, це дозволить не тримати ВМ включеними у резервному ЦОД. Бази даних та спеціальні додатки реплікуємо вбудованими засобами та тримаємо ВМ увімкненими. У разі відмови основного ЦОД ми запускаємо системи в резервному ЦОД. Вважаємо, що у нас близько 100 віртуальних машин. Поки діє основний ЦОД, у резервному ЦОД можна запускати тестові середовища та інші системи, які можна відключити у разі перемикання основного ЦОД. Також можливий варіант, коли ми використовується двостороння реплікація. З погляду обладнання нічого не зміниться.
У разі класичної архітектури поставимо в кожен ЦОД гібридну СХД з доступом по FibreChannel, тирингом, дедуплікацією та компресією (але не онлайн), 8 серверів на кожен майданчик, по 2 комутатори FibreChannel та Ethernet 10G. Для реплікації та управління перемиканням у класичній архітектурі можемо використовувати засоби VMware (Replication + SRM) або сторонні засоби, які будуть трохи дешевшими та іноді зручнішими.
На малюнку представлена схема.
У разі використання Cisco HyperFlex виходить така архітектура:
Для HyperFlex я використовував сервери з великими ресурсами CPU/RAM, т.к. частина ресурсів піде на ВМ контролера HyperFlex, CPU і пам'яті я навіть трохи перезаклався в конфігурації HyperFlex, щоб не підігравати в бік Cisco і гарантувати ресурси для інших ВМ. Зате ми можемо відмовитися від FibreChannel комутаторів, і нам не знадобляться Ethernet-порти під кожен сервер, локальний трафік комутується всередині FI.
У результаті вийшла наступна конфігурація для кожного ЦОД:
сервери
8 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA)
8 x HX240C-M5L (512 GB RAM, 2 x Intel Gold 6150, 3,2 GB SSD, 10 x 6 TB NL-SAS)
SHD
Гібридна СХД із FC Front-End (20TB SSD, 130TB NL-SAS)
-
ЛВС
2 x Ethernet switch 10G 12 ports
-
SAN
2 x FC switch 32/16Gb 24 ports
2 x Cisco UCS FI 6332
Ліцензії
VMware Ent Plus
Реплікація та/або оркестрація перемикання ВМ
VMware Ent Plus
Для Hyperflex не закладав ліцензії ПЗ реплікації, тому що у нас це доступно з коробки.
Для класичної архітектури я взяв вендора, який зарекомендував себе як якісний та недорогий виробник. Для обох варіантів застосував стандартну для конкретного рішення знижку, на виході отримав реальні ціни.
Рішення на Cisco HyperFlex вийшло на 13% дешевшим.
Сценарій 2: створення двох активних ЦОДів. У цьому сценарії ми проектуємо розтягнутий кластер на VMware.
Класична архітектура складається з серверів віртуалізації, SAN (протокол FC) та двох СГД, які вміють читати та писати на тому, розтягнутому між ними. На кожній СГД закладаємо корисну ємність для локу.
HyperFlex просто створюємо Stretch Cluster з однаковою кількістю нод на обох майданчиках. І тут використовується чинник реплікації 2+2.
Вийшла наступна конфігурація:
Класична архітектура
HyperFlex
сервери
16 x 1U Server (384 GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)
16 x HX240C-M5L (512 ГБ RAM, 2 x Intel Gold 6132, 1,6 TB NVMe, 12 x 3,8 TB SSD, VIC 1387)
SHD
2 x AllFlash СГД (150 TB SSD)
-
ЛВС
4 x Ethernet switch 10G 24 ports
-
SAN
4 x FC switch 32/16Gb 24 ports
4 x Cisco UCS FI 6332
Ліцензії
VMware Ent Plus
VMware Ent Plus
У всіх підрахунках я не враховував мережеву інфраструктуру, витрати на ЦОД тощо: вони будуть однаковими для класичної архітектури та рішення на HyperFlex.
За вартістю HyperFlex вийшов на 5% дорожче. Тут варто відзначити, що за ресурсами CPU/RAM у мене для Cisco вийшов перекіс, тому що в конфігурації заповнював канали контролерів пам'яті поступово. Вартість трохи вища, але не на порядок, що явно вказує на те, що гіперконвергенція не обов'язково «іграшка для багатих», а може конкурувати зі стандартним підходом до побудови ЦОДу. Також це може бути цікаво тим, хто вже має сервери Cisco UCS і відповідну інфраструктуру під них.
З плюсів отримаємо відсутність витрат на адміністрування SAN та СГД, онлайн-компресію та дедуплікацію, єдину точку входу для підтримки (віртуалізація, сервера, вони ж – СГД), економія місця (але не у всіх сценаріях), спрощення експлуатації.
Що стосується підтримки, то тут ви отримуєте її від одного вендора - Cisco. Якщо судити з досвіду роботи з серверами Cisco UCS, то мені подобається, на HyperFlex відкривати так і не довелося, все і так працювало. Інженери відповідають оперативно та можуть вирішувати не лише типові проблеми, а й складні прикордонні випадки. Часом я звертаюся до них із запитаннями: «А чи можна зробити так, прикрутити це?» або «Я тут щось наконфігурував і воно не хоче працювати. Допоможіть!» — вони там терпляче знайдуть потрібний гайд і вкажуть на правильні дії, відповідатимуть: Ми вирішуємо тільки апаратні проблеми вони не стануть.
Посилання
- Моя пошта - [захищено електронною поштою]
Джерело: habr.com