Вот как все начиналось. К 2013 году у нас на сопровождении накопилось несколько десятков всяких баз данных, работающих на Oracle. Некоторые были небольшими, но с тяжелыми запросами — например, хранилища нормативных документов или коллекторская система. Некоторые можно было отнести к OLTP, с огромным количеством маленьких запросов — риск-мониторинг, sms-движок и другие. Были системы, которые становились очень активными только к платежным датам или к закрытию месяца. В общем, задачи у всех разные и профили нагрузки, соответственно, тоже. Чтобы перестраховаться, для каждой системы мы держали серьезный запас вычислительных мощностей для пиковых нагрузок, а также запас дисковых ресурсов на случай внезапного роста. На поддержку всего этого уходило много времени и сил.
Чтобы сократить затраты на оборудование, мы решили объединить базы данных Oracle всех midrange-систем в одном сервере. У нас был хороший опыт с Oracle Exadata: реплика на этой системе закрыла проблему с построением отчетности процессинга. Но базы данных в Exadata работают в Real Application Cluster'е, что накладывает некоторые ограничения на приложения и требует тщательного тестирования. Да и стороннее ПО комплекс Exadata ставить поверх себя не позволяет, что сужает количество переносимых ИТ-систем.
Какие есть варианты? К классу инженерных систем Oracle также относится Supercluster. У него в дополнение к преимуществам Exadata есть возможность использовать базы в режиме RAC one node, по сути stand-alone, что минимизирует риски миграции. Мы рассчитали экономический эффект от перехода на Supercluster: получалось, что за стоимость дополнительного оборудования, обеспечивающего поддержку натурального роста систем на следующий год, мы можем приобрести 2 новых Supercluster’а. Мы успешно защитили это решение перед бизнесом и в 2014 году приобрели две половинки Supercluster T5-8 для основного и резервного комплексов.
Каждая половинка Supercluster содержала два вычислительных узла с четырьмя 16-ядерными процессорами и 1 ТБ памяти. На первые узлы двух суперкластеров мы положили критичные для бизнеса базы, на вторые узлы — все остальные, standby-базы. Их сконфигурировали с меньшим объемом памяти, чтобы при возникновении проблем на основном узле clusterware автоматически подняла ресурсы на другом, живом узле. На случай выхода из строя всего узла настроили failover switch средствами Data Guard. И чтобы упростить резервирование, добавили на узлы дополнительные FC-карты и медиа-сервера Veritas Netbackup. Таким образом мы максимально использовали ресурсы и обеспечили отказо- и катастрофоустойчивость.
Перенос систем сопровождало разностороннее тестирование. У нас были опасения, что конкуренция за ресурсы множества баз может привести к деградации сервисов, но после переноса более 30 систем поняли, что скорость работы только выросла. Причем даже в тех системах, которым не помогало ни добавление процессоров с памятью, ни перенос баз на full-flash массивы. Например, в нашей основной антифрод-системой Risk Monitoring, которая до этого стала сдавать из-за роста нагрузки от систем-источников. Очевидно, дело не только в самом оборудовании, но и в «математике» инженерных систем Oracle, которая ускоряет запросы.
На сегодняшний день Supercluster работает у нас более четырех лет. Вот что нам нравится помимо производительности:
- Затраты на ИТ-инфраструктуру снизились, как мы и хотели.
- Уменьшились затраты и на администрирование. Раньше для поддержки баз данных нужны были не только администраторы СУБД, но и unix-администраторы, администраторы СХД и SAN. Теперь все поддерживает один человек, и 90% администрирования осуществляется через Oracle Cloud Control.
- Сократился срок внедрения новых информационных систем, т.к. больше не требуется ожидать приобретения и поставки оборудования для баз данных.
- Помимо полезных штук Exadata вроде smart scan’ов, storage index’ов и гибридного сжатия, мы использовали очень полезный для консолидации баз инструмент Exadata — IO Resource Manager. С помощью него мы расставляем приоритеты использования дисковых ресурсов.
Отдельно стоит упомянуть разностороннюю техническую поддержку Oracle. Для программно-аппаратных комплексов в дополнение к стандартной Premier Support и партнерской поддержке мы получили бесплатную поддержку Platinum Service, которая включает:
- Услугу «call home» — автоматический мониторинг оборудования вендором: например, в случае выхода из строя диска вендор узнает об этом первым и организует процедуру замены.
- Регулярные бесплатные обновления системного ПО.
- Гораздо более быстрое восстановление работоспособности комплекса через систему Advanced Platinum Support Gateway.
Мы развиваем платформу консолидации СУБД Oracle на базе Supercluster и в конце 2017 года к нам приехали три первых проданных в мире Supercluster M8:
Если у вас есть какие-либо вопросы о наших сценариях использования Supercluster, будем рады ответить на них в комментариях.
Комментарии (11)
fivehouse
28.08.2018 19:52-1Bla bla blaaa bla bla blaaa,
bla bla blaaa bla bla blaaa!
Bla-bla bla-bla,
bla-bla bla-bla blaaa bla!
(на мелодию «Прокатись на нашей карусели»)
Расходы на инфраструкутуру врядли уменьшатся, особенно с учетом требования к 3х кратному дубливанию дискового пространства. А вот расходы на лицензии вырастут в несколько раз. Особенно учитывая требования оракл консолидации всех лицензий. И требования оплаты поддержки всех когда либо приобретенных лицензий. Сначала реально посчитайте стоимость лицензий. Это для оракла очень поучительная и реально сложная наука. Ораклоиды обычно сами не заморачиваются чтением собственных правил лицензирования. Просто говорят — купите у нас вот эту законченную порнографию. Зачтем вам недоплату по лицензиям. Вы ш банк! С вас столько-то! Бабло в кассу!
firedragon
28.08.2018 22:27Как насчет ситуаций попадания под санкции?
mspain
29.08.2018 18:11Втб уже давно под санкциями ес и сша :) что кстати интересно, Оракле им не следует
pomme
29.08.2018 03:50Огласите стоимость решений, пожалуйста.
Можно с учетом скидок, чтоб людей не сильно пугать.
Ну и, чтобы иметь возможность сравнить с аналогами, какие-нибудь технические параметры нагрузки. Кол-во запросов/с, объемы БД и т.п.
Berkof
29.08.2018 12:58А не было желания как в Сбере попробывать Apache Ignite? Я понимаю, что там очень очень очень много проблем, просто интересует процесс выбора? Или даже речи с Oracle уйти не было?
OlehR
29.08.2018 16:12Если расматривать базу для OLTP то Oracle БД №1.
1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
2) Простое маштабирование из коробки.
3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
Для DW можно использовать и MySQL и PostgreSQL.
Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.kruftik
29.08.2018 19:081) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
Вы по маркетинговым треш-страницам «вендоров» сравниваете? Или как оцениваете степень отставания и ее производную?
2) Простое маштабирование из коробки.
И что, горизонтальное масштабирование уже завезли и автоматический шардинг и по вертикали по горизонтали?
Для DW можно использовать и MySQL и PostgreSQL.
Озеро данных на SQL-базах, серьезно? :) Особенно на MySQL — без шуток, верный выбор!
Yo1
30.08.2018 09:15маркетниг тут не причем, отставание у мсскл и постгрес от оракла 8 вышедшего лет 20 назад все еще огромно. ни у того ни у другого нет даже примитивных пакетов, нет отслеживания зависимостей, нет кластера, у постгреса нет даже партишенинга нормального или многоболочного чтения под капотом. мсскл прилепили версионность сбоку, но в таком виде (версии в темпдб) это скорее пародия, чем конкурент, хотя в зазуре это уже дефолтный уровень изолированности.
шардинг в 12ю версию оракла завезли.
дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.OlehR
30.08.2018 14:39А от себя еще добавлю
1) RESULT_CACHE
2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
Все ето дает прирост быстродействия в на некоторих участках в десятки раз.
Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
А Переход на новие сервера без остановки работи БД?
От таки «маркетинговие» фичи позволяют БД бить в Online годами.
pupsegadm
29.08.2018 13:48Подобных систем в России единицы.
Коллеги, это именно в ВТБ? Или в намертво приклееной к ВТБ процессинговой компании «мультикарта»?
PS: в банках безраздельно властвует Oracle. Очень плотно. Так сложилось исторически.
Бывают потуги PostgreSQL, встречаются проекты на MS SQL. Но высоконагруженные системы, например карточный процессинг — только Oracle без вариантов. Смена Oracle на что-то другое, как правило, даже не рассматривается.
kruftik
отвратительный маркетинговый буллшит-материал, вероятно достойный продажников «вендора», но не достойный тех. специалистов и других приличных людей из штата крупного банка.