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

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



Вот как все начиналось. К 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, будем рады ответить на них в комментариях.
ВТБ
70,83
Компания
Поделиться публикацией

Комментарии 32

    +3
    отвратительный маркетинговый буллшит-материал, вероятно достойный продажников «вендора», но не достойный тех. специалистов и других приличных людей из штата крупного банка.
      +2
      Bla bla blaaa bla bla blaaa,
      bla bla blaaa bla bla blaaa!
      Bla-bla bla-bla,
      bla-bla bla-bla blaaa bla!
      (на мелодию «Прокатись на нашей карусели»)
      Расходы на инфраструкутуру врядли уменьшатся, особенно с учетом требования к 3х кратному дубливанию дискового пространства. А вот расходы на лицензии вырастут в несколько раз. Особенно учитывая требования оракл консолидации всех лицензий. И требования оплаты поддержки всех когда либо приобретенных лицензий. Сначала реально посчитайте стоимость лицензий. Это для оракла очень поучительная и реально сложная наука. Ораклоиды обычно сами не заморачиваются чтением собственных правил лицензирования. Просто говорят — купите у нас вот эту законченную порнографию. Зачтем вам недоплату по лицензиям. Вы ш банк! С вас столько-то! Бабло в кассу!
        0
        Дублирование используем двойное (normal redundancy). Расходы на лицензии могут вырасти за счет лицензирования Exadata Storage Software и если RAC на предыдущих системах не использовался. Экономия возникает за счет выноса части нагрузки на ячейки хранения и, как было написано выше, уменьшения вычислительных ресурсов под пиковые нагрузки.
        +1
        Как насчет ситуаций попадания под санкции?
          0
          Втб уже давно под санкциями ес и сша :) что кстати интересно, Оракле им не следует
            0
            Пропадет техподдержка, а в остальном будет работать. Есть чего использовать в качестве ЗИПа.
              0
              Это как? Вы работаете без ОТН и не ставите заплатки?
                0
                Сейчас, конечно же, работаем с несколькими уровнями техподдержки, но в случае отключения ОТН системы продолжат работать до миграции на импортозамещенное оборудование.
            +1
            Огласите стоимость решений, пожалуйста.
            Можно с учетом скидок, чтоб людей не сильно пугать.

            Ну и, чтобы иметь возможность сравнить с аналогами, какие-нибудь технические параметры нагрузки. Кол-во запросов/с, объемы БД и т.п.
              0
              К сожалению, указывать цены и скидки мы не можем. Работает 45 баз общим объёмом 80Тб.
              0
              А не было желания как в Сбере попробывать Apache Ignite? Я понимаю, что там очень очень очень много проблем, просто интересует процесс выбора? Или даже речи с Oracle уйти не было?
                +1
                Если расматривать базу для OLTP то Oracle БД №1.
                1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.
                2) Простое маштабирование из коробки.
                3) Удобство администрирования, отказовоустойчивость и возможность поддерживать систему Online 7*24. И очень многие вещи можно делать без остановки базы.
                И да Oracle очень догогой, но если сравнивать не просто стоимость лицензий, а реальную нагрузку, которую держит система то разныци с MsSQL практически не будет.
                Для DW можно использовать и MySQL и PostgreSQL.
                Я могу сравнивать ибо пишу под MsSQL и Oracle, писал и MySQL и баловался PostgreSQL.
                  –1
                  1) Килер фич не пересчесть (MsSQL питается копировать, иногда успешно, иногда не очень, PostgreSQL отстал такое чуство навсегда), прогнозированое быстродействие.

                  Вы по маркетинговым треш-страницам «вендоров» сравниваете? Или как оцениваете степень отставания и ее производную?

                  2) Простое маштабирование из коробки.

                  И что, горизонтальное масштабирование уже завезли и автоматический шардинг и по вертикали по горизонтали?

                  Для DW можно использовать и MySQL и PostgreSQL.

                  Озеро данных на SQL-базах, серьезно? :) Особенно на MySQL — без шуток, верный выбор!

                    +1
                    маркетниг тут не причем, отставание у мсскл и постгрес от оракла 8 вышедшего лет 20 назад все еще огромно. ни у того ни у другого нет даже примитивных пакетов, нет отслеживания зависимостей, нет кластера, у постгреса нет даже партишенинга нормального или многоболочного чтения под капотом. мсскл прилепили версионность сбоку, но в таком виде (версии в темпдб) это скорее пародия, чем конкурент, хотя в зазуре это уже дефолтный уровень изолированности.
                    шардинг в 12ю версию оракла завезли.
                    дата лейк на mysql где тоже нет ни колончатых таблиц и многоблочного чтения, да — глупость.
                      +1
                      А от себя еще добавлю
                      1) RESULT_CACHE
                      2) Разнообразие Partition, отсутствие SubPartition.(в MsSQL на уровне 8i, в PostgreSQL в десятке прикрутили но до использования в продакшене им пилять и пилять)
                      3) INMEMORY(опция) — в MsSQL мягко говоря странное, в PostgreSQL нет., Да что говорить в PostgreSQL merge до сих пор нет и не будет в 11.
                      4) PL/SQL заточен на скорость, масовие обработки, компиляция в нативний код и тд.
                      Все ето дает прирост быстродействия в на некоторих участках в десятки раз.

                      Ви можете себе представить перенос дата файла с диска на диск или востановленя «битого блока» в состоянии Online?
                      А Переход на новие сервера без остановки работи БД?
                      От таки «маркетинговие» фичи позволяют БД бить в Online годами.
                        0
                        >От таки «маркетинговие» фичи позволяют БД бить в Online годами.

                        Волшебному Ораклу не страшны даже выключения питания и сбои железа, всё равно ни одного разрыва! :)

                        Друг, если ты глаголишь про какие-то кластерные решения от Оракла, то прежде чем сравнивать с Постгресом, посчитай стоимость софта+железа+зарплату толкового Ораклиста (там ведь всё сделано максимально через задний проход, чтобы народ на курсы платные ходил). А потом уже расскажи как ПРИ ТОМ ЖЕ БЮДЖЕТЕ тормозит и не может годами работать в онлайне Постгрес.
                          0
                          да. ораклу за именно за это волшебство и платят миллиарды, что выключение питание и ни одного разрыва. а постгрес бесплатен, потому как выключение и он теряет транзакции. банку пофигу сколько там стоит постгрес и спец, если эта комбинация не способна при простом выключении пары нод клстера хоть чего либо гарантировать. у orace rac есть кэш, распределяющийся по нодам кластера, есть шаред диск, гарантирующий запись на все 100.000%. в постгресе же нет ничего похожего. потому в банке оракл, с его волшебством.
                            0
                            В банках (и других Жыр Трестъ Ынтырпрайзах) Оракл не потому, что волшебство, а потому что распилы + боятся ответственность брать на свою Ж.

                            Ну и традиционно, Ораклист тем круче, чем громче хает он Постгрес. Не первый, не последний ты…
                              0
                              только по факту на бесплатном линуксе и хадупе строить системы банк ответственности не боится. апач, томкат, гит, свн… нормальным опенсоурс системам в банке никакие распилы не мешают.
                                0
                                Ораклизы жгут. Банки хадупом и гитом транзакции обрабатывают?

                                  0
                                  нет. хадуп и гит банки используют ровно там где они лучшие и никакие распилы этому не помеха. в обработке транзакций лучший оракл, потому используют оракл. будет хадуп с kudu лучше оракла транзакции процессить, переключаться на хадуп. и никакие распилы хадуп не остановят.
                                  у постгреса просто не подходящая архитектура с уборкой мусора, не подходящая под тяжелый поток транзакций, нет настоящего кластера. у оракла же волшебный UNDO и RAC. вот причина, распилы тут не причем.
                                    0
                                    «не подходящая под тяжелый поток транзакций»

                                    Погугли для саморазвития какой поток транзакций у Яндекса, Скайпа, Авито :) Ну да, это не финансовые данные. Но нагрузка явно больше, чем у большинства банков. Итого вернулись к началу — «боятся ответственность брать на свою Ж».

                                    Кстати, волшебный RAC это тот, что который Ораклисты пишут: My general advice: DON’T USE RAC? blog.2ndquadrant.com/oracle-high-availability-concepts-postgresql
                                      0
                                      школоло, пойди сначала разберись, чем фин транкции отличаются от веба, с его примитивными инсертами на IL RC. там и мусору неоткуда взяться.
                                      по рац, блогер с бэкраундом постгреса слышал «at least qualified Oracle experts tell me so» (тм). аргумент суръезный. зачет.
                                        0
                                        «Примитивные инсерты» у всех вменяемых людей давно в носкле.

                                        А ораклизы, как вижу, в английский не умеют. На: RAC specialist gave me the usual answer “You are not confident because the previous integrators were bad but with me it will be different. I asked the customer to buy new storage, I will follow the best practices and things will run”.
                                        The previous integrators were platinum partners of Oracle and as I expected the specialist did nothing better than them. We had more incidents causing downtime with the RAC database than with the single instances databases left on the old AIX server.
                                        The reasons are easy to understand but often ignored. A single Oracle Database instance is not simple but RAC completely breaks the KISS principle, it is a complex thing to deploy and to administer. You can have as many nodes as you want, Grid Infrastructure itself will remain a logical single point of failure. Every software has bugs, especially if it is complex and Grid infrastructure is no exception.
                                          0
                                          дитетко, ни в одном банке ты не найдешь nosql процессящих транзакции. и поменьше слушай блогеров, software bug завалит все ноды nosql точно так же. я лично на хадупе проверял.
                                            0
                                              0
                                              ок, ты не врубаешься что такое банк и что такое трейдинг система. для школоло это нормально.
                                                0
                                                для нешкололо ты очень плохо читаешь. второй пример — банковская сеть по всему миру. а в трейдинге нагрузки такие, что 99% банков и не снилось, не ты ли усирался что никто кроме могучего оракла не потянет? ещё тебе домашнее задание — погуглить про банки конкретно на Постгресе, такое тоже есть. упс?
                                                  0
                                                  трейдинг это специфическая задача с одними инсертами, без надобности полноценного acid. т.е. ты по прежнему не понимаешь чем задачи процессинга банковских транзакций от второстипенных систем отличаются. в мелких банках на постгресе вполне могут быть второстепенные системы типа HR или CRM, но не процессинг банковских транзакций.
                                                  ладно, утомили школьники, по блогам RACы изучающие.
                  0
                  Мы смотрим на все современные системы управления базами данных, в том числе на российские и open source. Для «сурового прома» альтернативы Oracle пока не видим.
                  +1
                  Подобных систем в России единицы.
                  Коллеги, это именно в ВТБ? Или в намертво приклееной к ВТБ процессинговой компании «мультикарта»?

                  PS: в банках безраздельно властвует Oracle. Очень плотно. Так сложилось исторически.
                  Бывают потуги PostgreSQL, встречаются проекты на MS SQL. Но высоконагруженные системы, например карточный процессинг — только Oracle без вариантов. Смена Oracle на что-то другое, как правило, даже не рассматривается.

                    0
                    В статье речь идет про экс-ВТБ24. После объединения лучшие практики будут тиражироваться на весь объединенный банк.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое