Повний переклад хмари КРОК на All-Flash сховища даних Violin Memory, або як ми вирішили проблеми з нестачею продуктивності СГД





Ми КРОК запустили власну публічну хмарну платформу в Росії одними з перших, ще в кінці 2009 року. Нам потрібен був зростання в геометричній прогресії з року в рік. Щоб забезпечити таку динаміку, архітектура хмарної платформи повинна була бути надгнучкої і масштабованої, а сама платформа — добре керованою. В якийсь момент ми почали упиратися в архітектурні обмеження, закладені ще на зорі розвитку хмари, а саме підсистему зберігання даних.

Одна з найважливіших завдань зростання — забезпечення потреб замовників не тільки в частині обсягів дискової ємності, але і в частині гарантованої продуктивності використовуваних дисків. Потрібно було уникнути взаємного впливу сусідів по СГД, зробити ситуацію повністю керованою, дати гарантії по продуктивності дисків у рамках SLA в межах від 400 IOPS до 100 000 IOPS на диск.

До всього іншого тема з гарантованими дисками в хмарі була підігріта і законом про персональних даних", який набирає чинності з 1 вересня 2015 року. Багато замовників розміщували і розміщують свої ІТ-сервіси за кордоном, найчастіше — на виділеному фізичному високопродуктивному обладнанні в Цоді провайдерів. Дані тепер потрібно перенести на територію Росії, але від гарантованої високої продуктивності дисків відмовлятися зовсім замовникам не хочеться або зовсім не можна, а чекати поставки обладнання в РФ вже немає можливості. Хмара у цьому випадку є, мабуть, одним і, можливо, єдиним способом встигнути перенести дані в РФ і отримати аналогічні технічні параметри продуктивності, як на використовуваному раніше фізичному обладнанні провайдера.

Хмара КРОК зараз — це понад 500 фізичних серверів і 12 сховищ даних, розподілених між двома віддаленими майданчиками. Близько 70% розміщених в хмарі віртуальних серверів — це продуктивні середовища великих корпоративних клієнтів і компаній середньої величини. Тестових середовищ та середовищ розробки усього близько 30%. У нас розміщений ряд досить важких інсталяцій Oracle, SAP і різних високонавантажених OLAP-систем замовників.

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

Другою серйозною проблемою архітектурної стала жорстка прив'язка параметрів ємності і продуктивності дискових масивів. Простіше кажучи, є 8 фізичних дисків по 150 ГБ зі швидкістю обертання 15k. Ми хочемо зібрати з них RAID10. Ефективна ємність логічного диска вийде на рівні 600 ГБ. Сам по собі кожен диск окремо видає до 150 IOPS, а значить, логічний диск видасть близько 1000 IOPS. В результаті отримуємо ситуацію: на кожен ТБ ефективної ємності дискової доводиться около1500 IOPS продуктивності.

Тепер подивимося на найбільш поширені завдання замовників: хочемо базу на 2 ТБ розмістити в хмарі і отримати продуктивність 10 000-50 000 IOPS. Виходить, щоб отримати таку продуктивність, потрібно взяти набагато більше дискової ємності, ніж насправді необхідно (10-50 ТБ). Ви можете заперечити мені, що на масивах є контролерна пара з кешом і що можна додати полку з твердотільними дисками і т. д. Кеш контролерів на випадковому читанні/запису сильно ситуацію не поліпшить. Твердотільні диски лише частково рятують ситуацію з продуктивністю, а рішення проблеми з керованістю лише відсувають в майбутнє. До того ж, класичний контролер не може розкрити всю продуктивність твердотільного диска.

Ситуація з продуктивністю дисків в хмарі КРОК ставала критичною, замовники починали скаржитися на непередбачувані осідання по продуктивності дискової підсистеми. Потрібно було приймати рішення про подальший розвиток хмари. Розглядали різні рішення, в тому числі і перехід на High-End масиви. Але усвідомлювали, що це не вирішення проблеми, а просто дорогий «милиця», який дозволить прожити ще пару років, поки ми не прийдемо до аналогічної ситуації. Про «некерованість» подібних рішень я вже писав вище. Також Hi-End масиви не призначені для дуже частого створення і видалення дискових лунов — дані операції займають багато часу і перетворюються на довгі черги запитів, що не підходить для роботи в хмарі. Загалом, завдання не бралася малою кров'ю, і ми були змушені почати все з чистого аркуша, провести локальну революцію в частині збереження даних у хмарі.

З чистого аркуша — так з чистого аркуша. Вирішили відштовхуватися від потреб замовників. Чого ж хочуть замовники?
  1. Диски з гарантованою продуктивністю без можливості взаємного впливу сусідів по масиву один на одного. Гарантії повинні бути зафіксовані в SLA або договорі.
  2. Прозорого нарощування і зменшення продуктивності дискових ресурсів на льоту зі зміною тарифів за використання різних дисків.
  3. Можливість розміщення високонавантажених БД в хмарі (20 000-100 000 IOPS на диск).
  4. Надання потужностей на території РФ (затримки і політичні фактори). Закон про перенесення персональних даних в РФ до 1 вересня 2015 року тільки підстьобував.
  5. Високу доступність зберігання даних.


Ми давно дивилися в бік використання All-Flash масивів. Так склалося, що саме на базі даного класу рішень наша хмарна завдання з зберіганням даних вирішувалася найбільш красиво, а що найцікавіше — фінансово виправдано. Ми протестували практично всі наявні на ринку рішення корпоративного рівня, а також попрацювали з найбільш помітними стартапами. При виборі рішення основними критеріями були:
  • All-Flash — висока продуктивність і відсутність залежності ємності дискової від кількості IOPS.
  • IOPS'ів повинно бути настільки багато, щоб, по-перше, всім вистачило, а по-друге, щоб можна було гарантувати їх виділення в будь-який момент часу.
  • Масиви повинні мати Infiniband адаптери для підключення до існуючої SAN. Справа в тому, що в якості SAN мережі і транспорту для віртуальних мереж замовників у хмарній платформі ми використовуємо 56GB Infiniband. Підключення масивів за тією ж технологією допомогло б зберегти одноманітність SAN і спростило б управління платформою в цілому. Не треба було б будувати складні в налаштуванні і експлуатації фабрики, як у випадку з FC SAN, так як при використанні Infiniband всі ці питання вже автоматично закриті.
  • Документовані і зрозумілі засоби керування масивами допомогою API. Це вимога допомогло б підступитися до задачі керованості.


Зупинилися в підсумку на масивах Violin Memory 6264. Вони повністю відповідали нашим вимогам. У підсумку сумарно на 8 придбаних масивів отримали 0.56 ПБ сирої / 0.32 ПБ корисної флеш-ємності з сумарною продуктивністю 8 000 000 IOPS.

Гарантії продуктивності здійснюються шляхом виставлення обмежень на рівні гіпервізора на кожен диск окремо. Програмне забезпечення по управлінню масивами в автоматичному режимі визначає поточну утилізацію кожного з них і вибирає найменш зайняті масиви для розміщення нових дисків. Масив зовсім компактний. Подумати тільки: 1 000 000 IOPS всього в 3 юніти!

Це був безпечний вибір, враховуючи, що Violin Memory створила All-Flash ринок в 2007 році і найдалі просунулася вдосконалення продукту. Компанія розробила систему з нуля спільно з Toshiba — винахідником NAND-Flash — і володіє ключовими патентами на роботу з флешом. В масиві немає ніяких SAS-петель, батарей та інших успадкованих від дискових систем архаїзмів, без компромісів у вигляді SSD. Замість цього — сучасна архітектура FFA на шині PCI, використовуються носії власної розробки VIMM ємністю 1.1 ТБ. На виході — номінальний час відгуку 250 мкс, 7-значні IOPS, десятки ТБ в 3 юніти. За заявами виробника, наздогнати Violin Memory неможливо: не потрібна переробка існуючого продукту, а роки розробок з нуля і доступ до незадокументированным функцій NAND-Flash.

Зізнаємося чесно: при міграції не все пішло гладко, і ми зіткнулися з інтеграційними проблемами нашого хмари і масивів. Суть їх полягала в тому, що ми могли реалізувати потенціал масивів приблизно на 10% від їх можливостей, а саме вперлися в максимальну кількість створюваних дисків на один масив. В хмарі КРОК ми використовуємо Infiniband як для мережі зберігання даних, так і для зв'язку між віртуальними машинами. В масивах Violin Memory використовується протокол SRP (SCSI over RDMA) для підключення LUN'ів до серверами по Infiniband. Цей протокол має наступною особливістю: контрольні команди використовують subnet manager мережі Infiniband. У звичайній ситуації, коли кількість LUN'ів і серверів не дуже велике, як і зв'язків між ними, це не є проблемою. Але не у випадку хмари. З-за того, що підключень, тобто шляхів між серверами і LUN'ами, дуже багато, subnet мападег'и мережі Inifiniband йшли в себе при перестроюванні топології мережі. Просто не вистачало процесорної потужності. Велика кількість шляхів також створювало складнощі на контролерах доступу СГД — вони починали працювати дуже повільно, викликаючи помилки в драйверах, які вважали, що шлях відвалився.

Як ми вирішили проблему? Разом з вендором провели велику роботу з оптимізації кількості шляхів: кожен окремий LUN ми почали підключати, тобто експортувати, до окремого фізичного сервера. Складність полягала в тому, що це потрібно було робити за допомогою ReST API масиву, що теж проходило нелегко. Якщо LUN експортований на всі хости і на ще один конкретний хост, то він експортується і з цього конкретного LUN'а. Це вимагає виконання живої міграції всіх LUN'ів, щоб у підсумку позбутися від експорту на всі хости. Так як при кожному включенні/виключенні сервера проходив новий запит на API масиву, у нас підвищилися вимоги до продуктивності цього API. Тут без вендора ми ніяк не могли обійтися. Треба було ініціювати випуск нових версій прошивок для обладнання.

З нашої сторони у вирішенні цього питання протягом понад півроку було зайнято три програміста і три DEVOPS'а. Ми написали величезну кількість тестів (unit-test'ів) для нашого програмного коду, оптимізували систему автоматизованого складання і тестування. Цим завданням займалася інша команда. В результаті у нас додалися тисячі рядків оттестированного програмного коду. Може здатися, ніби оптимізація кількості шляхів — це проста задача, але насправді нічого простого в ній немає: на її виконання нам потрібні серйозні трудовитрати і більше десяти місяців.


VIMM (Violin Intelligent Memory Module) — флеш-носій, основний компонент All Flash системи

Отже, діапазон доступною продуктивності дисків, які можна створити на масивах, — до 100 000 IOPS на диск. Причому продуктивність ця гарантована, а не плаваюча, як зазвичай прийнято на ринку публічних хмарних платформ.
Ми надаємо замовникам за замовчуванням диски з наступною продуктивністю: 400, 1000, 3000, 5000, 10000 IOPS відповідно. Замовники через портал самообслуговування мають можливість запуску дисків різної продуктивності, а також зміни параметрів їх кількості IOPS на льоту. А диски продуктивністю від 10 000 IOPS до 100 000 IOPS додаються на портал самообслуговування запит у службу технічної підтримки. Як правило, це індивідуальні рівні зберігання, параметри яких визначаються для кожного замовника окремо за результатами навантажувального тестування. Ми їх не приховуємо, просто дійсно далеко не всім потрібні такі високопродуктивні рівні зберігання. Нам не шкода, адже середня кількість IOPS на 1ТБ ємності в нашому хмарі — 25 000. Це дійсно фантастичний показник.

Масиви розподілені між двома хмарними платформами КРОК в розподілених дата-центрах на території Москви: в одному 5 сховищ, в іншому — 3. Це дозволяє замовникам будувати Disaster recovery рішення з використанням високонавантажених систем як на одному майданчику, так і на інший. Причому управління масивами на обох майданчиках виконується за допомогою єдиного порталу самообслуговування.

Багато можуть зауважити: «А ось інші провайдери зв'язку говорять, що у них теж канали гарантовані, а як справа доходить до SLA, опускають очі». Так от у КРОК є абсолютно окремий SLA на продуктивність дисків, крім стандартного SLA на доступність віртуальних серверів. Наведу нижче невелику витяг з нього, а саме визначення недоступності продуктивності гарантованих дисків. «Недоступність продуктивності флеш-диска — стан флеш-диска, коли протягом п'яти хвилин процесор віртуальної машини, до якої він підключений, очікує дані від дискової підсистеми більше 10% часу, або затримка отримання даних від дискової підсистеми більш 5мс і при цьому кількість запитів вводу-виводу (IOPS) на флеш-диск менші, ніж заявлена продуктивність флеш-диска на 3%».

Під заявленої продуктивністю флеш-диска тут маються на увазі як раз стандартні рівні зберігання 400, 1000, 3000, 5000, 10000 IOPS відповідно або індивідуальні рівні зберігання від 10 000 IOPS до 100 000 IOPS. Як тільки ми вилітаємо за заявлені параметри продуктивності, починають капати хвилини недоступності. Як тільки ми вилітаємо за SLA 99,9, то відразу ж потрапляємо на штрафи. Так що ми самі себе заганяємо в ситуацію, коли погано працювати зовсім не в наших інтересах.

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

До речі, можу додати від себе, що послуга виявилася настільки потрібною і своєчасною, що ми розпродали наші вісім флешових масивів на 60% за 4 місяці і тільки що замовили ще вісім таких же. Це буде перша хмара в Росії з > 1 ПБ правильного флеша. Так що будемо готові прийняти і новий потік замовників, який хлине ближче до середини і кінця літа напередодні Дня знань про персональних даних. Багато замовників, до речі, вже своєчасно без особливих складнощів переїхали до нас. Особливо зручно тим, хто раніше використовував потужності Amazon — у нас схожа архітектура, сумісний API і близький підхід до побудови публічного хмари.

Якщо у вас є питання по організації дискових ресурсів для навантажених ІТ-систем в РФ, я готовий відповісти в коментарях або ж детально з прорахунком вашої задачі поштою: MBerezin@croc.ru

Посилання:

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

0 коментарів

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