Слезть с IBM. Одна из критичных высоконагруженных систем РЖД переезжает на Postgres

В 2022 году Проектно-конструкторско-технологическое бюро по системам информатизации – Центр цифровых технологий филиал РЖД (ПКТБ-ЦЦТ) начал миграцию одной из высоконагруженных систем в сфере железнодорожного транспорта с IBM DB2 для z/OS на СУБД Postgres Pro. Об опыте миграции 3 апреля 2023 года на отраслевой конференции публично рассказал начальник сектора ПКТБ-ЦЦТ Василий Тимощенко.

ПКТБ-ЦЦТ занимается разработкой автоматизированных систем для РЖД, и одна из основных разрабатываемых им систем – автоматизированная система оперативного управления перевозками (АСОУП). История АСОУП насчитывает более 40 лет. Система собирает в себе информацию о всех подвижных объектах на железной дороге: поездах, вагонах, контейнерах.

В АСОУП есть линейный уровень – это то, что поставляет информацию, включая АРМ на местах, датчики и т.д. Они передают информацию на дорожный уровень, где существует 16 дорожных АСОУП (Россия организационно разделена на 16 дорог). Также есть сетевая АСОУП, которая обрабатывает данные по всей сети дорог. Затем информация отдаётся системам-потребителям, и на ней строится аналитика, отчётность.

Суммарный объём БД всех дорожных систем АСОУП составляет порядка 10 ТВ, привёл данные представитель ПКТБ-ЦЦТ. Историческая информация хранится 10 лет. В сутки обрабатывается около 30 ГБ информации, поступающей с линейного уровня на дорожный.

Василий Тимощенко уточнил, что в 2022 году в компании занимались импортозамещением сетевого уровня АСОУП, где агрегируется информация по всей сети дорог и отдаётся другим системам-потребителям. Обзор российского рынка банковской цифровизации: импортозамещение, искусственный интеллект и собственные экосистемы 6.9 т

На конец 2022 года система функционировала на двух отказоустойчивых мейнфреймах IBM Mainframe Parallel Sysplex. Начальник сектора ПКТБ-ЦЦТ говорит, что в компании понимали, что «в лоб» систему, которая построена на мейнфрейме, не получится догнать. Поэтому было решено разделить нагрузки OLTP и OLAP – обрабатывать сообщения в одной базе, а аналитические запросы выполнять на другой базе.

Требовалось также обеспечить отказоустойчивость, потому что система критичная.

История перехода с IBM началась не вчера, рассказал Василий Тимощенко. До этого предпринималось множество попыток переписать какие-то части систем на другие платформы. В какой-то момент пытались перейти на SAP Hana. Но это не было бы импортозамещением. Также пытались написать что-то на VoltDB, тестировали Tarantool. Но по тем или иным причинам это не взлетело.

Postgres компания к тому моменту уже использовала в нескольких небольших проектах. СУБД Postgres Pro Enterprise подошла, потому что есть вендорская поддержка, СУБД есть в реестре российского ПО, а также привлёк multimaster – «это означает кластер из коробки, который не требует дополнительного ПО».

Расширение multimaster превращает Postgres Pro Enterprise в синхронный кластер без разделения ресурсов, который обеспечивает расширяемость OLTP для читающих транзакций.

Проблема была в том, что система функционирует на IBM System z – мейнфрейме от IBM, на операционной системе z/OS. Это очень специфическая система. Практически весь код написан на C и ассемблере. Ничего не оставалось, как взять, и всё переписать, говорит Василий Тимощенко.

Получилось следующее. Разделили базу на OLAP и OLTP, часть OLAP предназначена для формирования оперативной аналитики о состоянии объектов движения, планирования их управлением и расчётов ключевых показателей работы, которые используются для определения эффективности функционирования железной дороги в целом. В OLTP был построен кластер multimaster с двумя нодами в архитектуре и referee – расширением Postgres Pro Enterprise.

Прикладная часть написана на Java, там Spring Boot упакован в Docker-контейнер, и всё это крутится под Kubernetes, при этом работая в виртуальных машинах. А в качестве ОС используется Red OS «Муром».

Пришлось довольно много оптимизировать производительность системы, признаётся Василий Тимощенко. Например, столкнулись с тем, что процессор много времени проводил в ожидании ввода/вывода. В ОС по умолчанию не было настроено, нужно было объяснить, что она работает с SSD дисками, а не HDD. Это сразу дало прирост производительности в 2-3 раза.

Помимо новой архитектуры, к которой разработчикам пришлось привыкать, возникли и новые ограничения. К примеру, в АСОУП бывают очень широкие таблицы, а теперь таблицы пришлось ужать – база не переносилась один в один.

Возник и организационный конфликт. Организация, которая занимается эксплуатацией системы, имеет чёткое разделение на системных и прикладных администраторов. Получилось так, что системный администратор не хочет давать права супер-пользователя прикладному администратору БД, а тот без этой роли не может настроить репликацию. Но в 16-й версии Postgres Pro появляется функция, которая позволяет делать указанное не супер-пользователю.

В числе планов на будущее по проекту – дальнейшая оптимизация производительности и наращивание функциональности архивной базы. И, скорее всего, ещё будут базы под конкретные задачи – более изолированные, но которым тоже понадобится оперативная информация из OLTP базы.