Миграция системы электронного документооборота «Дело» на импортонезависимую СУБД Postgres Pro Enterprise

Заказчик:
АО «НИКИЭТ»
Руководитель проекта со стороны заказчика
Поставщик
РДТЕХ, Электронные офисные системы
Год завершения проекта
2024
Сроки выполнения проекта
ноябрь, 2023 — май, 2024
Масштаб проекта
1000 автоматизированных рабочих мест
Цели

Миграция системы электронного документооборота (СЭД) «Дело», разработанной компанией «Электронные Офисные Системы», с инфраструктуры на базе СУБД Oracle на СУБД Postgres Pro.

Проект является частью стратегии  обеспечения технологической независимости АО «НИКИЭТ» в условиях прекращения технической поддержки со стороны иностранных производителей ПО. Его реализация направлена на соблюдение требований указа президента РФ «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации», а также реализации программы по импортозамещению в области ИКТ. 

Ключевые задачи проекта:

  • Обеспечение миграции СЭД «Дело» на Postgres Pro с сохранением функциональности системы.

  • Минимизация рисков остановок и сбоев в работе критически важных систем.

  • Поддержка непрерывности бизнеса и эффективности деятельности компании после перехода на отечественную систему.

Результаты

Успешная миграция с сохранением всех функций и данных. 

  • Реализован отказоустойчивый кластер на Postgres Pro, полностью отвечающий требованиям заказчика к надежности системы с высоким уровнем бизнес-критичности.

  • Документы в объеме 2 ТБ успешно перенесены в СУБД Postgres Pro Enterprise.

  • Пользователи СЭД «Дело» работают в системе и отмечают её производительность и удобство работы с привычным интерфейсом и функциями.

Уникальность проекта

Стратегическая важность: миграция на новую платформу производится для обеспечения непрерывной работы критически важной системы, независимо от внешних ограничений

Технологическая независимость: переход на импортонезависимую СУБД (Postgres Pro) позволяет не зависеть от иностранных производителей

Большие объемы специфических данных: с помощью специально разработанной утилиты выгружены и перенесены 2 ТБ документов

Глубокая проработка инфраструктуры: создан экспериментальный стенд и проведено предварительное тестирование подхода и тестовая миграция, разработан подход к резервированию СУБД, настроен мониторинг

Отказоустойчивость и защита данных: создан кластер с механизмами физической репликации, резервного копирования, обеспечивающий высокую степень отказоустойчивости, возможность синхронизации с резервным сервером и минимизации временной потери данных.

Проект решает задачи импортозамещения
Да
Использованное ПО

Система электронного документооборота «Дело», СУБД Oracle (предыдущая), СУБД Postgres Pro Enterprise (новая).

Сложность реализации

Реализация проекта миграции системы электронного документооборота (СЭД) «Дело» на импортонезависимую СУБД Postgres Pro потребовала всестороннего анализа и тщательной подготовки. 

Техническая сложность:

Миграция: Переход с Oracle на Postgres Pro требует глубокого понимания различий между двумя СУБД, включая SQL-синтаксис, архитектуру хранения данных и механизмы управления.

Отказоустойчивость: Необходимо разработать надежную систему резервирования и синхронизации данных.

Организационная сложность:

Координация команды: Участие нескольких компаний (ЭОС, РДТЕХ и НИКИЭТ) подразумевает необходимость четкой координации действий.

Информационная безопасность:

Защита данных: Обеспечение безопасности и конфиденциальности данных в ходе миграции и после неё является критически важным задачей. 

Описание проекта

Миграция СЭД «Дело» на импортонезависимую СУБД, перенос данных, сохранение функционала и бизнес-логики системы. 

Одной из главных задач проекта миграции был перенос данных из старой СУБД в новую в полном объеме и сохранение всего набора инструментов и функций в бизнес-логике системы.

Специалисты РДТЕХ обеспечили необходимую инфраструктуру со стороны СУБД — подготовили базы данных требуемой конфигурации, настроили мониторинг и резервирование. На подготовительной стадии проекта был создан экспериментальный стенд и проведено предварительное тестирование предложенного подхода.

Основные трудности при миграции с Oracle на Postgres Pro вызвала выгрузка 2 ТБ документов, хранящихся в СЭД, из БД Oracle во внешнее хранилище. Проблема была успешно решена специалистами ЭОС: они разработали утилиту, которая позволила выполнить выгрузку за приемлемое время и без потери данных.

Особое внимание в ходе проекта уделялось обеспечению отказоустойчивости работы СЭД на новой СУБД и минимизации рисков утраты данных. Реализованный на Postgres Pro кластер с механизмами резервного копирования продемонстрировал необходимую степень отказоустойчивости и требуемую работоспособность. БД СЭД «Дело» на резервном сервере регулярно синхронизируется с актуальной базой данных системы на основном сервере. Максимально допустимый временной промежуток, за который возможна потеря данных (в маловероятном случае критичных сбоев в работе основного сервера), составляет не более 15 минут.

География проекта

Москва

Коментарии: 4

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Максим Часовиков
    Рейтинг: 6272
    МГУ имени М.В.Ломоносова
    Руководитель цифровизации образовательных процессов
    01.01.2025 20:27

    Спасибо большое за подробное описание представленного на конкурс проекта, Как вы считаете, что в наибольшей степени, из того, что удалось реализовать в рамках этого проекта, положительно повлияет на развитие компании в долгосрочной перспективе?

    • Илларион Линде Максим
      Рейтинг: 66
      АО «НИКИЭТ»
      Начальник отдела информационных систем
      17.01.2025 15:52

      Добрый день! Спасибо за вопрос.С учетом требований Правительства РФ и регуляторов о необходимости импортозамещения программного обеспечения, мне кажется, что основное преимущество нашего проекта это неизменность одного из основных инструментов в постоянной работе сотрудников. В случае, если продукт частично остается зависим от зарубежных технологий, в час Х может наступить требование о запрете эксплуатации для объектов КИИ и так далее. Следовательно, данный риск был проанализирован и упразднен. Да, можно было воспользоваться уже готовым решением (программным продуктов), но на это ушли бы годы (миграция данных, проведение аттестационных мероприятий для обработки конфиденциальной информации в системе, переобучение тысячи сотрудников и так далее), а так же немалая сумма денег из бюджета организации.Также однозначным плюсом я бы отметил возможность работать с сертифицированными по требованиям ФСТЭК стеком технологий (СУБД, ОС), что позволяет расширить обработку данных в системе (на самом деле что уже и произошло в организации).Резюмируя, для сотрудников организации все произошло "прозрачно", отсутствие избыточных финансовых растрат, надежность в части информационной безопасности и возможность строить планы на развитие системы, в условиях постоянно меняющегося информационного поля.

  • Вячеслав Чупраков
    Рейтинг: 1724
    Прагматика Эксперт
    Заместитель ИТ директора по инфраструктуре и сервисам
    06.01.2025 03:07

    Расскажите подробнее как тестировали СУБД на отказоустойчивость и проводили нагрузочное тестирование, сколько серверов в кластере?

    • Ольга Горохова Вячеслав
      Рейтинг: 15
      РДТЕХ
      директор по маркетингу
      09.01.2025 17:00

      Спасибо за вопрос! С учётом окружения и особенностей работы ПО СЭД "Дело" в качестве отказоустойчивой СУБД была выбрана конфигурация физической репликации Master - Slave с ручным переключением роли узла.Для тестирования отказоустойчивости СУБД заказчику была предоставлена инструкция по переводу узла с ролью Slave в состояние Master и наоборот. На уровне сервера приложений предполагалось в момент переключения изменение IP-адреса алиаса имени БД.Проверка выполнялась следующим образом:

      1. Добавление новой записи и изменение существующей не функциональном уровне.
      2. Имитация падения основного узла СУБД.
      3. Изменение роли узла Slave в Master.
      4. Изменение записи ДНС для приложения.
      5. Проверка измененных в п.1 данных.
      Проверка прошла успешно. Время простоя - в пределах 5ти минут.После этого выполнено обратное переключение.Нагрузочное тестирование не проводилось - такой задачи со стороны заказчика не ставилось.

Год
Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.