Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Даже в технологически продвинутых компаниях могут быть не просто старые базы данных, а очень старые. Они продолжают работать, но их древность однажды может создать массу проблем. И хорошо, если эти проблемы удается разрешить заранее, пока экосистема из уже неподдерживаемого ПО не начала сыпаться. Расскажем, как команда «Инфосистемы Джет» обновляла более 50 устаревших СУБД Oracle одного своего клиента, чтобы избежать катастрофических последствий.
Если хорошо постараться, то в крупных компаниях можно найти СУБД эпохи палеолита. У ИТ-персонала полно других задач, а базы данных... они работают и работают, технический долг копится годами. Используемые «старушки» СУБД оказываются без поддержки производителя, с ними нельзя использовать современные решения, подключать дополнительный функционал и пр. И однажды обновление все-таки наступает.
Похожий сценарий разыгрался у нашего клиента. В организации насчитывалось более 50 СУБД Oracle разных версий. Они работали на выделенных серверах, давно снятых с поддержки вендора, в разных гипервизорах, включая откровенно устаревшие версии. Одни жили на Oracle VM, другие — на VMware, третьи — на Hyper-V.
БД были не слишком сильно нагружены, но работали в тесной связке друг с другом, а значительная часть оборудования «под» ними трудилась на пределе своих возможностей. Реальные бизнес-процессы охватывают сразу несколько направлений деятельности компании, и, чтобы отразить их, между базами данных были выстроены зависимости и налажен постоянный обмен информацией. Поэтому в случае (не дай бог!) падения одной базы нарушилась бы работа еще нескольких.
Предыстория
Эта история разворачивалась в 2019 году, когда Oracle объявил об автоматическом изменении исходного кода. В результате этого мог остановиться обмен данными между СУБД разных версий по Database Link. А Database Link широко использовался у нашего клиента как раз для взаимодействия между СУБД, связывая разные наборы данных. В общем, гигант решил обновить версии СУБД до наиболее оптимальных и актуальных на тот момент, чтобы гарантировать работу Database Link после обновления кода Oracle.
Анализ сложившейся ситуации добавил нам дополнительных задач. Во-первых, оказалось, что существовавшая конфигурация не была полноценно отказоустойчивой. Случись неприятность — и проблема восстановления работы СУБД и системы в целом могла бы стать невыполнимой миссией. А во-вторых, параллельно с миграцией БД заказчик предложил обновить ПО Oracle Forms and Reports, тем самым существенно усложнив общую архитектуру слоя приложений.
Переносим СУБД на новую инфраструктуру
Впрочем, миграция СУБД тоже не была простой. Подход «обновить до новейшей версии» здесь не работал, так как не учитывал много важных факторов. Вместе со специалистами клиента мы пришли к выводу, что необходимо обновить СУБД до версий 11.2.0.4 и 12.2.0.1, хотя на момент ведения проекта была доступна уже 18-я версия. Именно версии 11.2.0.4 и 12.2.0.1 оказались наиболее знакомы и понятны заказчику, в них точно работало все используемое прикладное ПО.
Размещать СУБД решили в единой виртуальной среде, чтобы обеспечить нужный уровень гибкости и отказоустойчивости. С переходом на общую гиперконвергентную инфраструктуру мы вывели из эксплуатации несколько десяятков устаревших серверов x86. А поскольку транзакционная нагрузка на СУБД у клиента была не такая уж большая, базы данных удалось разместить на пятиузловом кластере виртуализации VMware/vSAN.
Миграция выдалась трудоемкой. Мы имели дело с базами данных не только разного возраста, но и с различной функциональностью (например, для авторизации пользователей). Их нельзя было просто перенести на новую версию СУБД — часто приходилось все настраивать с нуля, изобретая велосипед заново.
Сначала, проанализировав все входящие данные, нам удалось «потом и кровью» согласовать золотой образ ОС, на которой могли работать нужные версии СУБД Oracle. Это был SUSE Linux Enterprise Server 12.3 с предустановленными бинарниками, необходимыми для работы Oracle пакетами, а также используемыми в компании агентами Enterprise Manager и NetBackup. Далее процесс повторялся для каждой БД по следующему сценарию:
Мы создавали новую виртуальную машину под каждую БД. По итогам предварительного сайзинга для нее выбиралось нужное число виртуальных процессоров и объем памяти.
«Заливали» копию базы данных. Учитывая, что приходилось иметь дело с самыми разными версиями СУБД (от 8 до 12), «заливать» их нужно было по-разному. В одних случаях работала схема «экспорт-импорт», в других мы восстанавливали базу из бэкапа на новой ВМ, а иногда даже копировали с продуктива.
После проверки работоспособности к тестированию подключались разработчики, и мы создавали несколько клонов базы данных, обновляли до требуемых версий и проводили тестирование работы новой СУБД уже с реальными данными.
К тестированию подключались обычные пользователи, которые проверяли работу СУБД «в бою», на тех функциях, к которым они привыкли.
В итоге, только пройдя все предыдущие шаги (иногда не по одному разу), мы наконец мигрировали продуктивную базу — после такой серьезной подготовки мы работали по детально проработанному плану.
В результате время миграции для каждой СУБД не превышало 2-4 часа. Важно, что все базы были мигрированы по графику, который учитывал изменения исходного кода Oracle. Таким образом, мы успели перенести критичные с точки зрения Database Link базы данных в первую очередь — проблем с обменом данных удалось избежать.
Отказоустойчивая конфигурация
На новой платформе для СУБД мы достигли нового уровня отказоустойчивости:
Базы данных категории Business Critical защищались при помощи Oracle Data Guard (Physical Standby). А самые-самые критичные СУБД получили дополнительно защиту с использованием Veritas HA Cluster.
Наименее критичные базы данных класса Office Productivity получили защиту на уровне резервного копирования с возможностью оперативного восстановления в случае сбоя на новой ВМ.
В качестве системы хранения данных использовали отдельный массив и гиперконвергентную среду VMware/vSAN. В итоге работающие СУБД и резервные копии были разделены между vSAN и массивом так, чтобы распределить нагрузку, но при этом исключить возможность выхода из строя обеих копий одновременно.
Единственной проблемой на этом этапе стало использование Veritas HA Cluster на платформе VMware. Чтобы кластер заработал под VMware, необходимо выделить виртуальным машинам разделяемые диски (в VMware они называются Multi-Writer). Это приводит к тому, что все прекрасные возможности VMware, к которым привыкли администраторы, — динамическое изменение ресурсов ВМ, клонирование и миграция, даже просто резервное копирование — перестают работать. Но эта история заслуживает отдельного поста.
Имеем дело с Middleware: ожидание/реальность
Проект был бы намного проще, если бы не обновления Middleware. Дело в том, что старая версия Oracle Forms and Reports использовала двухзвенную архитектуру с клиент-серверным взаимодействием, а новая версия этого ПО требовала внедрения трехзвенной архитектуры и установки сервера приложений.
Мы придумали «красивое» решение: запустить сервер приложений в режиме Active-Active, задействуя имевшееся у заказчика оборудование — NetScaler. Помучавшись с настройками какое-то время, мы на практике воплотили идею такой балансировки. Но в последний момент отказались от задуманного: хотя решение успешно прошло тестирование, с ростом пользовательской нагрузки оно начало выдавать «плавающие» баги, тормозя некоторые сессии. В общем, для кластеризации сервера приложений пришлось использовать более тривиальное решение. Для серверов приложений мы обеспечили отказоустойчивость с применением Open Source решения кластеризации keepalived (рис. 2).
Выводы
В ходе проекта мы еще раз убедились в том, что обновление устаревшего и неподдерживаемого ПО (в этом случае Oracle Forms and Reports) может стать самой проблемной частью проекта — трудности миграции БД были понятными, и мы оказались к ним готовы, потому что регулярно делаем подобные проекты.
Чтобы перенести свыше 50 (а с учетом всех копий и клонов — более сотни) баз данных на единую платформу и унифицированную версию, пришлось провести огромную подготовительную работу. Резервирование в виртуальной среде стало фундаментом для нужного уровня доступности для каждой СУБД, а главное — получилось вернуть управляемость критически важной инфраструктуре. «Старушки» БД благополучно пережили переселение в «новое тело» и теперь полны сил: могут похвастаться отказоустойчивостью и правильным резервным копированием.
Теперь, глядя на показатели доступности более 99%, становится жутко от того, что работавшие до этого СУБД были на грани фола. В случае любого сбоя восстановление заняло бы несколько дней, и никто не смог бы гарантировать его полноту. Конечно, лучше запускать проекты модернизации версий инфраструктурного ПО заранее, пока небо не рухнуло на землю. В данном случае триггером для этого стало обновление исходного кода Oracle Database. И очень хорошо, что перенос БД на новую платформу произошел без реальных инцидентов с потерей данных.
Авторы:
Алексей Струченко, руководитель направления БД «Инфосистемы Джет»
Ксения Александрова, менеджер проектов «Инфосистемы Джет»
