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

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

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

Исходные данные

• Компания: Крупная производственно-розничная компания в России.

• Технологическое окно: есть, 2-3 часа.

• Платформа: 1С:8.2 в режиме совместимости 8.1(!). То есть, фактически – это 8.1, поэтому дальше по тексту буду ее называть 8.1. Из-за устаревшей версии платформы переход назревал очень давно, но заказчик долго не решался из-за рисков.

• Размер БД: 2,5 Тб. Это уже тот объем, когда размера технологического окна просто недостаточно для обновлений ИС. А для многих манипуляций с системой нужно либо замораживать деятельность в ИТ-системе на бо́льший срок, либо придумывать алгоритмы и механизмы, которые позволят осуществлять гарантированный перенос данных, их проверку, консистентность и переключение пользователей в рамках имеющегося тех. окна.

• Цель: перевести систему на платформу 8.3.22 без режима совместимости, уложиться в технологическое окно, подготовить обратный мост на случай, если переход будет признан неудачным. Наличие обратного моста – это было одним из ключевых требований на проекте. Забегая вперед, скажу, что оно было не зря добавлено и таки пригодилось.

Предпосылки к миграции

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

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

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

В таком деле без помощи не обойтись, а коллеги из SOFTPOINT помогли не только с технической частью, но и с анализом, подготовкой и ведением проекта.

Заказчик

Исходная инфраструктура

Сервер СУБД представляет из себя отказоустойчивый кластер AlwaysOn с дополнительной балансировкой запросов между двумя нодами кластера. Балансировка осуществляется внешней программой Data Cluster. Первая нода кластера работает в режиме чтение/запись, вторая нода – только в режиме чтения.

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

Этапы миграции в общем виде

Если бы база была маленькая и типовая, а технологическое окно большим, чтобы успеть не только сконвертировать, но и провести все необходимые тесты, то…

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

Укрупненно этапы выглядят так:

1. На стенде сконвертировали базу в формат 8.3.22. Передали Заказчику на функциональную адаптацию.

   Такая первоначальная конвертация из 8.1 в 8.3 разбивается, в свою очередь, на два шага. Нельзя сразу режим совместимости поменять на 8.3, точнее убрать совсем. Необходима промежуточная остановка в виде режима совместимости 8.2.13:

   а) Изменение режима совместимости из 8.1 в 8.2.13. Обновление конфигурации при этом длится лишь пару минут.

   б) Изменение режима совместимости из 8.2.13 в режим «Не использовать».  Обновление конфигурации при этом длится порядка 7 часов.

   Итого вся первоначальная конвертация занимает около 8 часов.

2. Заказчик выполнил функциональную адаптацию и тестирование конфигурации 1С под платформу 8.3.22. Тут необходимо помнить, что чем старше система, чем больше в ней уникального функционала, тем тщательнее и ответственнее нужно подойти к этим работам. В нашем примере база активно используется и дорабатывается в течение 15 лет.

   Длительность этапа 2 месяца.

3. Внедрили репликацию DB Replication, способную передавать данные 1С из базы данных формата 1С:Предприятие 8.2.19.130 (режим совместимости конфигурации 1С 8.1) в базу данных формата 1С:Предприятие 8.3.22 (без режима совместимости).

   Этот этап появился в проекте потому, что суммарная длительность конвертации, а также длительность проверок и прочих сопутствующих мероприятий в разы превышают технологическое окно, имеющееся у заказчика. Поэтому задача решалась по методике, использующей репликацию DB Replication, способную передавать данные из базы данных формата 1С 8.1 в формат 1С 8.3 в режиме онлайн. Таким образом, разработчики и тестировщики не ограничены по времени проверки системы на новой платформе, а данные в базе всегда актуальны.

   Итого, имеем одностороннюю онлайн репликацию из 8.1 в 8.3. Пользователи продолжают работать в 1С: 8.1, но при этом база данных 1С 8.3 полностью актуальна, и разработчики имеют возможность проводить сколь угодно длительные проверки в базе.

   Схематично архитектура работы обеих систем представлен на рисунке ниже.

Репликация настроена между основными нодами кластеров СУБД, т.к. вторичные ноды работают только на чтение.

4.  Заказчик выполнил серию функциональных тестов в 1С 8.3.

Это тестирование отличалось от первоначального стендового (п.2) тем, что тут в тестируемую базу 8.3 в режиме реального времени из БД 8.1 стали поступать оперативные изменения данных. Были выявлены новые ошибки, внесены изменения в конфигурацию. Длительность этапа 3-4 недели, задействовано более 50 бизнес-пользователей.

5.   Заказчик выполнил в 1С 8.3 нагрузочное тестирование. Софтпоинт с помощью мониторинга производительности PerfExpert контролировали показатели. Результат отличный – база 8.3 по скорости работает, как минимум, не хуже, чем 1С 8.1, а в ряде аспектов лучше.

Концептуально методика тестирования:

• Выделены профили нагрузки, замеры выполняли через APDEX. Основная цель – не медленнее, чем есть.

• Обработки в фоновых заданиях генерировали нагрузку (документы, запросы и т.п.).

• Сотрудники из всех отделов и нескольких сотен салонов продаж были подключены к тестированию со специально проработанными сценариями. (Интерактивное тестирование).

• Имитировалась работа сотрудников всех салонов при помощи открытия дополнительной копии 1С в формате 8.3 при входе сотрудников в 8.1. Вторая сессия 1С открывалась в свернутом виде и в ней выполнялись сценарии работы в автоматическом режиме. (Пассивное участие в тестах)

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

Заключение: база готова к переводу пользователей.

6.  Совместно составили детальный пошаговый План переключения пользователей в день (точнее, в ночь) Х, в котором максимально подробно были расписаны действия каждого участника. План предусматривал и запасной вариант на случай возврата в исходную систему на том или ином этапе перехода. Имеется в виду ситуация, когда в новой базе уже пошли транзакции (пользователи + интернет-магазин + фоновые задания и т.п.), обнаружилась ошибка, не позволяющая работать в системе дальше, и принимается решение «откатиться» на старую платформу. Для этого использовалась та же DB Replication с зеркальными правилами обмена:

 7.  Повторно сконвертировали актуальную копию БД в формат 8.3. Это потребовалось потому, что в ходе функционального и нагрузочного тестирования данные в базе 8.3 были неизбежно искажены относительно продуктива и подключили к DB Replication.

8.  Согласно детальному Плану, выполнили переключение системы на платформу 8.3. Для переключения использовалось технологическое окно длительностью около 2х часов.

Это я вот написал так просто «выполнили переключение», а на самом деле было 4 (четыре!) попытки в течение 8 дней - об этом чуть ниже.

 9.   Одновременно с переключением работы пользователей включили обратную репликацию (из 8.3 в 8.1). В течение 2х недель репликацию поддерживали ради подстраховки на случай какого-либо форс-мажора, неучтенных факторов и т.п. Но когда окончательно убедились, что ИС формате 8.3 нормально живет, имеет ожидаемое быстродействие, репликацию отключили. На этом проект перехода завершен.

Общая длительность проекта 6 месяцев в комфортном для обеих команд темпе.  

Особенности онлайн репликации

Поскольку целевая и исходная базы не являются в полной степени гомогенными (различаются версии платформы 1С, различается структура части таблиц и их индексов), то программный комплекс DB Replication требовал адаптации для работы в такой среде, в частности, потребовались специальные правила конвертации для некоторых таблиц. В рамках статьи хочу рассказать о трех таких особенностях.

Поле _SIMPLEKEY

В платформе 1С 8.1 в некоторых регистрах сведений присутствует специальное служебное поле _SimpleKey (binary(16)), а в платформе 8.3 этого поля нет.

Для прямой репликации из 8.1 в 8.3 было реализовано игнорирование этого поля.

А для обратной репликации из 8.3 в 8.1 была реализована следующая логика для обновления и для добавления новых строк:

• При обновлении существующей строки в базе 1С 8.1 поле _SimpleKey игнорируется (остается имеющееся значение).

• При добавлении в базу 1С 8.1 новой строки, пришедшей по репликации из базы 1С 8.3, для поля _SimpleKey генерируется значение GUID binary(16).

Предопределенные элементы в НСИ

В платформах 8.1 и 8.3 принципиально отличается механизм предопределенных элементов в справочниках, ПВХ и пр.

В 1С 8.1 свойство предопределенности – это простой бинарный признак ДА/НЕТ, реализованный в виде поля _IsMetadata.

А в 1С 8.3 механизм предопределённых элементов сильно эволюционировал, это уже довольно сложная взаимосвязанная структура в БД, в рамках которой поле [_IsMetada] заменилось на ссылочное поле [_PredefinedID] и появились дополнительные служебные таблицы _RefSinf%% и _RefOpt – это маски имени для справочников. Для ПВХ и прочих типов маски имен таблиц будут другими. Кроме того, с точки зрения прикладной логики функционирования этой подсистемы тоже всё сильно усложнилось.

Чтобы обеспечить корректную репликацию данных по предопределенным элементам потребовались две меры:

а)  адаптация механизма передачи данных;

б)  введение моратория на добавление новых предопределенных элементов на финальном этапе проекта.

 Адаптация передачи данных заключалась в следующем. При передаче предопределенного элемента из 8.1 в 8.3 следует игнорировать поля _IsMetadata и _PredefinedID соответственно, поскольку их значения нельзя непосредственно писать друг в друга в силу совершенно разного формата и "физического смысла".

Теперь про мораторий на добавление новых предопределенных элементов. Когда в конфигурацию добавляется новый предопределенный элемент, то на уровне таблицы БД вставляется соответствующая новая строка. И для этой строки генерируется новое значение ссылки (поле _IDRREF), далее добавляется признак предопределенности (в 8.1 это значение 0x01 в поле _IsMetadat, а в 8.3 это специальная ссылка в поле _PredefinedID), плюс еще некоторые тонкости. Т.е. механика в 8.1 и 8.3 абсолютно разная и при онлайн синхронизации данных нужно эти нюансы учитывать. Технически это реализуемо, но довольно накладно. Поэтому встаёт вопрос целесообразности. А надо ли реализовывать эти сложности, если они будут востребованы лишь на довольно коротком отрезке времени в конце проекта? Обсудили, что 2-3 недели запрета на добавление новых предопределенных элементов – это для Заказчика вполне приемлемый срок. Было принято решение в пользу моратория. А если бы, несмотря на мораторий, всё же срочно потребовалось добавить новые предопределенные элементы, то можно этот сценарий отработать в ручном режиме.

Пользователи ИБ

Аналогично предопределенным элементам, структура пользователей в БД 1С 8.3 кардинально отличается от 1С 8.1. Поэтому настройка репликации была бы достаточно трудозатратой, проще оказалось сделать обмен новыми пользователями средствами 1С.

В связи с этим хочется отметить один важный аспект. Многие операции можно реализовать альтернативными путями. Если существует возможность выполнить одно и то же действие несколькими инструментами, один из которых проще, быстрее и дешевле, то не бойтесь рассматривать его в «ущерб» какой-то унификации.

В нашем случае использовалась проброска пользователей по COM-соединению с установкой такого же GUID у нового пользователя в БД 8.3, как и в 8.1. Для этого после подключения к базе-получателю (8.3) в ней создавался объект из строкового системного представления, в шаблон которого подставлялся GUID пользователя из базы источника (8.1).

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

Попытки перехода

Как было сказано выше, попыток было четыре. И подстраховка в виде обратной репликации (из 8.3 в 8.1) как раз пригодилась.

Попытка №1:

1. Проблема в параметре MS SQL сервера Cost threshold for parallelism. Оказалось, что в момент перехода он имел значении 0, что приводило к ошибкам в работе некоторых хранимых процедур. То, что не работали некоторые хранимки – это аномалия MS SQL Server. А то, что параметр был установлен в значение 0, то это недочет, вызванный скриптом обслуживания индексов, запущенным накануне. Скрипт подправили, проблема ушла.

2. Поскольку оперативно выявить и устранить проблему не удалось, муравейник закрылся и пришлось возвращаться в исходную БД 8.1. Причем к этому моменту в ИС 8.3 уже были запущены регламентные задания 1С и в новой системе формировались документы, заполнялись регистры и т.п. Обратная репликация работала, новые данные передавались из 8.3 в 8.1, поэтому при возврате на 8.1 никаких потерь по данным не было. Обратный мост успешно отработал.

Попытка №2:

1. Проблема на стороне 1С. Не работала подсистема «ОценкаПроизводительности». Проблема была решена позднее настройкой уровня изоляции при подключении внешней компоненты «ОценкаПроизводительности». Если не указан явно вариант «ТипПодключенияВнешнейКомпоненты.НеИзолированно», тогда соединения web-сервисов зависают в случае возникновения в них исключений, что замедляет работу сервера 1С до критических значений.

2. Пока разбирались с причинами технологическое окно завершилось и пришлось возвращаться в исходную БД 8.1. Обратная репликация была включена, но поскольку новые данные в систему еще не успели попасть, то этим функционалом не воспользовались.

Попытка №3:

1. В час перехода Х сервер 1С 8.3 вдруг стал себя вести непредсказуемо – не запускалась служба кластера 1С RAgent. Помогла переустановка платформы 1С. Но после этого начались проблемы с лицензиями 1С.

2. В процессе разбора причин драгоценное время технологического окна было потеряно и принято решение откатываться в исходную БД 8.1. Аналогично предыдущей попытке, новые данные в систему еще не успели попасть, обратная репликация не использовалась.

Попытка №4 (успешная!):

1. Все шаги перехода были пройдены штатно.

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

   Сразу после старта системы один запрос из фонового задания отъел почти все ресурсы CPU (до 30 ядер). Ресурсы ЦПУ оказались в дефиците, у всех начались тормоза:

Оказалось, что все дело в параметре MAXDOP, который вследствие принудительного завершения, накануне часа X, регламентного задания по пересчету индексов так и остался равен нулю. Обычно в регламентных скриптах параметр MAXDOP действительно выставляют в ноль (не ограничивают параллелизм) – это значительно ускоряет процессы пересчета индексов и статистик, а потом возвращают на исходное значение. Но аварийное завершение скрипта сыграло злую шутку, параллелизм остался неограниченным, и в какой-то момент SQL Server отдал почти все процессорные мощности одному единственному запросу.

Проблему сразу локализовали, переключили MAXDOP=1. Проблема ушла.

3. Многие показатели производительности стали лучше, чем в 8.1.

Метрики со стороны SQL-сервер (основная нода):

 Метрики по ключевым операциям (APDEX):

Другие показатели производительности:

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

Заключение

Надеюсь, статья получилось познавательной. Еще раз проговорю нюансы, на которые стоит обратить при таких вот переходах, связанных, как с изменением структуры метаданных, так и с изменением (пусть даже частичным) логики работы платформы (1С или СУБД).

Многим, наверняка, покажется, что это очевидные вещи, но от этого они не становятся менее важными:

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

2. Тщательная проверка настроек оборудования и ПО непосредственно перед моментом перехода. Выше я привел описание попыток перехода, где видно, что какие-то, казалось бы, мелочи (неучтёнки) останавливали весь процесс и все уходили на новый круг. Но уже в другой день. А другой день может быть не завтра, а через неделю, потому что технологическое окно всего полчаса по вторникам ночью.

3. Технологическое окно. Оно, как правило, очень маленькое. У некоторых его нет вообще. Соответственно нужно проработать до мельчайших шагов сценарий перехода пользователей с одной ИС на другую.

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

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

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

Заказчик

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

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

Заказчик

5. Сценарии отката пользователей на старую систему в случае форс-мажоров. Здесь нужно заложиться на допустимое время простоя системы, возможную синхронизацию данных из «новой системы» обратно в «старую» или же смириться с их потерями в случае принятия решения об откате.

Другие статьи на тему миграции:

1)  Миграция с MSSQL Server на PostgreSQL. Предпосылки

2)  Гетерогенная распределенная система как способ миграции больших и не очень баз данных с MSSQL Server на PostgreSQL