Итак, произошло то, что произошло, сегодня невозможно сделать сет Directum на MS SQL. Microsoft перестал отгружать лицензии в России. Для многих это стало неожиданностью, а для нас — нет. Задолго до введения санкционных ограничений мы позаботились о переходе на PostgreSQL и Linux. Причины были банальны — хотелось сократить расходы на лицензию. 

Также хотелось научиться переводить системы Directum на PostgreSQL, предполагая, что слонёнок будет востребован у наших заказчиков по той же финансовой причине. Для нас отказ от баз Microsoft был плановым. Кроме того, мы перевели инфраструктуры вместе с Directum на Linux. Сегодня оцениваем эту попытку “переехать” с сокращением затрат как отчасти удачную. 

Я, Виталий Волнянский, руководитель практики технологических решений (CTO), директор по продажам (VPS) ООО “ЕАЕ-Консалт”, под катом расскажу о том, как проходила миграция и с какими проблемами нам пришлось столкнуться.

Предыстория: ещё пару слов о мотивах

Как вы, вероятно, поняли, основным мотивом переезда на PostgreSQL было то, что не нужно платить за лицензию MS SQL. Для PostgreSQL можно купить поддержку, но обязательной опцией она не является, да и цена саппорта не сравнима со стоимостью лицензии Microsoft.

Directum мы эксплуатируем с 2017 года. В тот период предложения от вендора было сложно назвать оптимальными, проявлялись несовместимости внутренней инфраструктуры с MS SQL 14. Кроме того, вендор настоятельно рекомендовал использовать в инсталляции ARR Server с устаревшей аутентификацией NTP Authentication, которая применялась в настольном клиенте и не работала с протоколом HTTPS.

Единственным балансировщиком, который нормально поддерживал это решение, был ARR, но у него всё совсем печально с механизмами балансировки. Когда ложился основной сервер, балансировщик не мог эффективно перераспределить новые запросы на резервный. Это и явилось одним из триггерных факторов, которые мотивировали нас усовершенствовать платформу.

Мы осознали, что текущий стек не позволяет добиться высокой доступности, а в нагрузку получаем ещё рутинное избыточное администрирование и отладку систем Directum. При использовании балансировки (т.е. при применении нескольких компонентов резервирования) время администрирования увеличивается, приходится отслеживать работоспособность компонентов, следить за тем, куда уходят запросы.

В 2018 году мы решили избавиться от избыточности, поставили один Application Server, одну базу данных. Система была оптимизирована и развивалась, но проблемы продолжали возникать. С выходом третьей версии Directum появился web-клиент, в связи с чем произошел переход на новые механизмы аутентификации OpenID и мы поняли, что ARR можно заменить на более эффективный балансировщик, т.е. на Nginx.

Более оптимальный алгоритм и наличие здорового Health Check серьёзно упростили нам жизнь. После замены балансировщика попробовали развернуть второй сервер, что в полной мере не удалось. Поэтому до выхода четвертой версии Directum мы вернулись к использованию ARR. Но ещё на версии 3.4 было принято решение о миграции с MS SQL в PostgreSQL как способе сократить лицензионные расходы.

Последовательность действий

Для того, чтобы мигрировать, была определена последовательность этапов:

1. Обследовать систему.

2. Подготовить новую систему в Yandex Cloud: установить ВМ, серверы, установить приложения.

3. Конвертировать данные из MS SQL в PostgreSQL.

4. Мигрировать в Яндекс.Облако, предоставляемое ЕАЕ-Консалт, обеспечить миграцию Hystax.

5. Осуществить миграцию стандартного ландшафта.

6. Поднять ВМ.

7. Установить Directum.

8. Настроить канал связи между площадками.

9. Провести синк документов, копирование БД и тестирование в рамках предпродуктивной миграции.

10. Осуществить продуктивную миграцию.

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

Обследование системы

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

Что мы делали:

• проверили объемы баз данных;

• проанализировали аппаратные требования к миграции, оценили совместимость, и, поняв на какой из версий Linux-систем будет работать Directum, выбрали Ubuntu 20.04;

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

На этом подготовительный этап был завершен и можно было перейти к инструменту миграции баз.

Изучение и доработка инструмента миграции из MS SQL в PostgreSQL

Задача конвертации данных из MS SQL в PostgreSQL не далась быстро. Мы были первыми, кто проводил такую миграцию. В то время мы использовали версию Directum RX 3.8, к которой вендор представил специальный инструмент для переноса данных из одной базы в другую. В связи с кастомным расширением нашей системы и использованием модуля CRM, инструмент работал исключительно с “родной” структурой, таблицами и дефолтным внутренним взаимодействием.

Для полноценной работы инструмент пришлось долго и мучительно настраивать и модифицировать SQL-скрипты. Часть модуля CRM использовал .NET Framework, и его пришлось адаптировать для корректной работы на .Net Core и Linux. Вендор оказал поддержку, дописывая решение под нас. Сейчас сложно сказать, сколько раз мы проводили миграцию в процессе отладки. Много. В 2021 году закончили переход на PostgreSQL и решили перейти к следующему этапу. С этого момента мы перестали платить за лицензии MS SQL.

Сегодня вендор усовершенствовал инструмент, который выполняет бэкап исходной базы данных MS SQL в аналогичную структуру PostgreSQL, достаточно лишь настроить аналогичный набор таблиц. В той версии, которую использовали мы, возможности быстрой миграции были не очевидны.

Критерии выбора облака и результаты миграции

Оптимизация системы предполагала миграцию из облака вендора, т.е. Directum, в облако Яндекс. Финансовая суть задачи состояла в том, чтобы сменить инвестиционные расходы на операционные, используя сервис вместо приобретения оборудования. Яндекс был выбран в силу того, что наша компания — партнёр Яндекса, и предложенное ими решение нас полностью удовлетворило.

Предпродуктивное тестирование

Тестирование проводили без автотестов, в ручном режиме. Проблема в том, что пользовательское взаимодействие с системой достаточно индивидуально, и возможные ошибки могут появляться в неочевидных случаях, которые вряд ли можно быстро заложить в автотесты. Важно отметить, что вендор не выдаёт свои автотесты партнёрам, возможно — это часть корпоративной политики по защите технологий. На этапе тестирования в компании началось внедрение веб-клиента, что осложнило задачу.

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

Значимые обновления, хранение данных и режим высокой доступности

После конвертации, возникло желание заставить платформу работать в режиме высокой доступности. Начиная с версии Directum 3.8 появилась информация о поддержке Linux-серверов, что обнадёживало. Позже нам предоставили тестовый релиз, и мы поняли, что в системе появились признаки микросервисной архитектуры.

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

До версии 3.8 весь объем данных по умолчанию записывался напрямую в базу. Это приводило к росту баз до неприличных объемов и вызывало проблемы при создании бэкапа и восстановлении системы. К томы же, для работы базы требовалось много оперативной памяти.

Как раз, когда мы конвертировались в PostgreSQL, вендор оптимизировал хранение данных и трансформировал их распределение, отправив контент в файловое хранилище, что здорово упростило бэкап. Несмотря на то, что база не выросла до чудовищных размеров, скорость её роста не предвещала ничего хорошего. Обновленное решение с хранением контента позволило нам существенно упростить задачу и снизить требования к RAM почти в 4 раза. Вместе с этим снизить стоимость виртуальной машины с СУБД. Если раньше резервное копирование базы длилось 3 часа, то сейчас стало занимать не более 20 минут и, соответственно, восстановление системы тоже происходит быстрее.

Между тем, сказать, что обновления и гипотетическая возможность создать отказоустойчивую систему обеспечивали режим высокой доступности в полной мере — преувеличить. В настоящий момент мы продолжаем работать в этом направлении.

Проблемы внедрения

После того, как было принято решение использовать Yandex Cloud, мы применили Managed PostgreSQL (чтобы частично снять с себя часть ответственности за постоянное администрирование), а также автоматизировать развертывание и внедрить контейнеры kubernetes. Проведя установку, мы поняли, что возникает проблема, инсталлятор требовал полномочий суперпользователя, уровня sys admin. Наличие полных прав на управление базы данных инсталлятору было недостаточно. Ему нужен был полный доступ к серверу Postrgre! 

Вероятно, что тот, кто сделал инсталлятор, имел такой доступ и реализовал решение по существующему шаблону. Решение спорное и не очень распространённое. Обычно в крупных компаниях, где существуют отдельные подразделения, занимающиеся администрированием баз данных, создают кластер серверов, где при необходимости заказываются БД. В данном же случае таких решений не предусмотрели. Мы решили не “ковырять” инсталлятор и отказаться от использования.

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

Сухой остаток

В силу того, что режим высокой доступности в полном смысле реализовать не получилось, возникли проблемы с Managed PostgreSQL, автоматической установкой и контейнерами, абсолютно успешным это кейс считать сложно. При этом мы решили главные задачи, а именно:

• сэкономили на лицензиях Microsoft, пока они были доступны в России;

• сократили текущие расходы, переведя их из инвестиционных в операционные, благодаря использованию Yandex Cloud и уменьшению размера виртуальных машин;

• гарантировали системе безопасность, ограничив влияние санкционных вендоров;

• научились проводить миграцию на Linux и PostgreSQL и готовы предложить её клиентам в качестве сервиса, который, по всей видимости, будет достаточно актуальным среди использующих Directum RX.

Описать всё в одном лонгриде достаточно тяжело. Возможно, у вас возникли вопросы относительно нашего опыта или конкретных проблем, с которыми мы столкнулись. Будем признательны за комменты и постараемся точно ответить на любые вопросы, касающиеся нашего опыта.