Укрощай и консолидируй: история переезда на Oracle Supercluster

в 14:52, , рубрики: oracle, supercluster, Администрирование баз данных, Блог компании ВТБ, СУБД, хранение данных

СУБД растут и размножаются, скрипты автоматизации становятся все сложнее и многочисленнее, и времени на все это уходит все больше и больше. В таких условиях рано или поздно администратор приходит к светлой мысли: нужно что-то менять. В этом посте мы на своем примере расскажем, как решить вопрос, если вы имеете дело с базами Oracle разных мастей и расцветок.

Укрощай и консолидируй: история переезда на Oracle Supercluster - 1

Вот как все начиналось. К 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 для основного и резервного комплексов.

Укрощай и консолидируй: история переезда на Oracle Supercluster - 2

Каждая половинка Supercluster содержала два вычислительных узла с четырьмя 16-ядерными процессорами и 1 ТБ памяти. На первые узлы двух суперкластеров мы положили критичные для бизнеса базы, на вторые узлы — все остальные, standby-базы. Их сконфигурировали с меньшим объемом памяти, чтобы при возникновении проблем на основном узле clusterware автоматически подняла ресурсы на другом, живом узле. На случай выхода из строя всего узла настроили failover switch средствами Data Guard. И чтобы упростить резервирование, добавили на узлы дополнительные FC-карты и медиа-сервера Veritas Netbackup. Таким образом мы максимально использовали ресурсы и обеспечили отказо- и катастрофоустойчивость.

Укрощай и консолидируй: история переезда на Oracle Supercluster - 3

Перенос систем сопровождало разностороннее тестирование. У нас были опасения, что конкуренция за ресурсы множества баз может привести к деградации сервисов, но после переноса более 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:

Укрощай и консолидируй: история переезда на Oracle Supercluster - 4

Если у вас есть какие-либо вопросы о наших сценариях использования Supercluster, будем рады ответить на них в комментариях.

Автор: VTB

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js