Страховые — третьи после банков и сотовых операторов потребители «тяжелого» 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.
Дальше
Этапы были такие:
- Просчёты и анализ (особенно важный вопросы был, чтобы фактические операционные затраты после внедрения были низкими).
- Тестирование вместе с нами.
- Покупка первого массива для OLAP.
- Ого! Oracle чувствует себя минимум в 2 раза лучше, не нужны специалисты для сопровождения.
- Ждём полгода. В течение полугода работы не требует внимания.
- Ещё раз считаем кейс. Стоимость за 1 ТБ ниже high-end-решений.
Графический интерфейс Violin
Приложение для сбора статистики производительности БД Oracle
Через полгода после теста начали апгрейдить второй участок. Был конкурс, опять победа нашего решения с Violin, внедрение. Насколько я знаю, заказчику ещё считали VNX и Хитачей, плюс были смешанные системы. Violin получилась самая дешёвая при том, что она ещё и полный флеш. В серверной осталось ещё много старых СХД, но всё важное и живое уже на флеше.
Как видите, пример интересный. Если хотите, чтобы я посчитал примерно кейс как под конкурс только на Violin — пишите на VBolotnov@croc.ru, скажу, имеет ли смысл пробовать так оптимизироваться в вашей ситуации.
Автор: BoVados
