Рефакторинг серверної страхової компанії: коли фізичного місця менше, ніж даних



Страхові — треті після банків і стільникових операторів споживачі «важкого» IT-заліза. На момент початку робіт ситуація була така: в офісі однієї компанії стояла їхня центральна серверна (нагадує невеликий машзал дата-центру), і в ній, в цілому, все чудово працювало.

Проблема була в тому, що місце під стійки (і в самих стійках) в серверній скінчилося ще 2 роки тому. В інших двох ЦОДах місце було, а ось тут — ні.

Друга проблема в тому, що основна база продакшну лежала на 149 томах, фізично — як швейцарський сир у серверах. Обумовлено це було тим, що коли вимагалося її збільшити, знаходили першу вільну дірку у фізичних дисках і пхали туди. Між томами бази могли перебувати бази інших проектів, ЗА різні тимчасові файли і так далі. Загалом, потрібно було наводити порядок.

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

Варіанти були такі:
• Апгрейд існуючих масивів (порахували: дорого і неефективно, нікуди ставити);
• Перехід на нове покоління тих же масивів (висока вартість за техобслуговування, постійний тюнінг);
• Пошук альтернативного рішення (прорахунок по flash і тести).

Зміни

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

Ми принесли 3 юніта Violin 6264 і почали шаманити. Для початку засіли з ораклистами за оптимальну фізичну структуру бази. З урахуванням здорового глузду, особливостей ОС і архітектури бази, вирішили, що потрібно 27 томів замість 149. Пізніше дорізали ще 2, вийшло 29. Заодно, до речі, оцінили, скільки порожніх місць було в DMX — адже якщо порожнього місця між томами не вистачає, щоб нарізати щось нове, воно просто пропускається. В результаті близько 15% вільного місця йшло на такі «щілини» між незалежними шматками даних.

Зрозуміло, це ще не було оптимізовано з точки зору продуктивності. На DMX один том міг лежати на 7 фізичних дисках. У Violin чинності архітектури самого контролера і алгоритмів укладання даних по фабриці, LUN «розмазується» по всьому сховищу, що дозволяє отримувати максимум продуктивності, навіть якщо сервери-«молотарки» вирішили вчепитися в один конкретний ділянку в кілька гігабайт розміром.

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

Пригасили базу глибокої ночі суботи, змінили структуру, скопіювали дані, занесли на нове залізо. Зробили заміри, все ок. Підняли в продакшн — працює, і працює, в цілому, добре, але не так швидко, як ми чекали. У сенсі, що повністю ресурси СГД не використовувалися.

Почали профілювати потоки — виявилося, вузьким місцем стали вже самі розрахункові сервери. Раніше вони чекали відповіді від сховища, а почали молотити на повну, при тому, що СГД може віддавати більше. У результаті замовник дуже вражений і купив 2 нові «коробочки» — одну під цю базу, другу — відразу «на виріст» під основну.

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

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

Чому Violin?

Улюблений питання Хабра — чому таке космічно дороге залізо. Так, Violin, як і будь-які «справжні» (в сенсі, не з полиць SSD) масиви без оверхеда HDD-технологій дуже дороги за юніт. Питання сотень тисяч доларів за всю систему. З іншого боку, тут історія така — якщо ви можете дозволити собі флеш-масив на серйозних даних, ви точно можете дозволити собі Violin, тому що в перспективі він дуже добре окупається. Встановити дорого — вигідно експлуатувати.
Природно, бувають рішення і дешевше, але для нашої задачі стояло ще кілька важливих вимог:
  • Доступність бази 24x7. Той шматок, який ми брали в тест — це первинна аналітика страхових випадків. Грубо кажучи, це оцінка коефіцієнтів, яка не потрібна в реальному часі. Отримали дані, перемололи, оновили формули. Її можна гасити і зупиняти при необхідності. Власне, у піки навантаження на основую базу пріоритет віддавався саме їй, і ця частина розрахунків гальмувалася. А ось бойову базу гасити не можна ні в якому разі, і працювати вона повинна просто завжди. Навіть пара хвилин простою може коштувати кілька мільйонів рублів. Тому — тільки хайенд.
  • Дуже потрібна правильна підтримка з хорошим SLA. У таких системах завжди використовується дублювання, і відмова другого контуру розглядається як серйозна аварія. База і сервіси перемикаються, але їхати і лагодити треба відразу, тому що якщо впаде і обладнання резерву — це фініш. Звідси — склади запчастин в Москві, грамотні інженери, гарантії того, що хтось приїде і вирішить. Загалом, як завжди. Для прикладу — ось історія моїх колег, які обслуговують сервери Dell.


Далі


Етапи були такі:
  1. Прорахунки і аналіз (особливо важливе питання був, щоб фактичні операційні витрати після впровадження були низькими).
  2. Тестування разом з нами.
  3. Купівля першого масиву для OLAP.
  4. Ого! Oracle відчуває себе мінімум в 2 рази краще, не потрібні фахівці для супроводу.
  5. Чекаємо на півроку. Протягом півроку роботи не вимагає уваги.
  6. Ще раз вважаємо кейс. Вартість за 1 ТБ нижче high-end-рішень.



Графічний інтерфейс Violin




Додаток для збору статистики продуктивності БД Oracle

Через півроку після тесту почали апгрейдити другий ділянку. Був конкурс, знову перемога нашого рішення з Violin, впровадження. Наскільки я знаю, замовнику ще вважали VNX і Хитачей, плюс були змішані системи. Violin вийшла найдешевша при тому, що вона ще й повний флеш. У серверній залишилося ще багато старих СГД, але все важливе і живе вже на флеша.



Як бачите, приклад цікавий. Якщо хочете, щоб я порахував приблизно кейс як під конкурс тільки на Violin — пишіть на VBolotnov@croc.ru скажу, має сенс пробувати так оптимізуватися у вашій ситуації.

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

0 коментарів

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