← Предыдущая статья

Миграция

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

Мы прошли такой путь:

1. Мигрировали тестовые данные.
2. Оповестили поддержку SAP о начале полной миграции.
3. Мигрировали начальные данные.
4. Мигрировали дельту.

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

О всех этих пунктах речь пойдет ниже.

1. Проверка миграции на тестовом тенанте

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

Это произошло из-за нашей уверенности в том, что скорость загрузки на тестовый тенант нерелевантна для корректных измерений и что эта скорость будет существенно выше на продуктивном тенанте. А также из-за того, что служба безопасности заказчика запретила загружать любые реальные данные на тестовый тенант, а загрузку специально сгенерированных тестовых данных мы посчитали нерепрезентативной. Кроме того, на тот момент я еще верил, что DWB – это нормальный инструмент для миграции данных, в котором определенно можно загружать файлы параллельно, стабильно и быстро.

В итоге, могу сказать, что проверять скорость загрузки данных на тестовый тенант нужно обязательно. Скорость загрузки на тестовый и продуктивный тенант по моим наблюдениям может не отличаться или отличаться в пределах 30%.

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

При тестовой загрузке данных на тестовый тенант вы должны удостовериться, что выбранный вами способ миграции (DWB/OData/SOAP) действительно является рабочим вариантом и позволит сделать миграцию вашего объема данных за нужный срок.

При проверке миграции в DWB рекомендую сначала загружать файл с включенной опцией «Режим моделирования». Таким образом можно отловить некоторые ошибки и проблемы с содержимым файлов и избежать загрузки данных, которых потом потребуется убирать (рис. 8).

Рисунок 8. Data Workbench – режим моделирования загрузки данных

2. Миграция тестовых данных

Перед полной миграцией мы с заказчиком решили провести пробную миграцию на примере небольшого объема данных для отработки выгрузок из БД Siebel заказчика, скриптов в промежуточной БД и загрузки файлов в SAP Sales Cloud. Из-за того, что эти данные уже были реальными, согласно ограничениям службы безопасности заказчика, мы могли загружать их только на продуктивный тенант SAP Sales Cloud.

Повторять такой опыт я не советую – нужно уговаривать заказчика использовать тестовый тенант или делать точку восстановления системы. Загрузка части реальных данных именно на продуктивный тенант в итоге оказалась проблемой, так как эти данные приходилось в промежуточной БД дополнительно исключать из полного объема загружаемых данных (из-за того, что в SAP Sales Cloud нельзя удалять некоторые объекты – можно только менять их статус на «Блокировано» или «Устарело»). Также сложность была с учётом ID этих тестовых данных при простановке ID SAP Sales Cloud.

Особая проблема была с сотрудниками, так как в полной выгрузке из БД Siebel от заказчика они также присутствовали, и при их загрузке в SAP Sales Cloud была ошибка о том, что данный пользователь уже присвоен сотруднику в системе. Поэтому пришлось менять пользователей на тестовых сотрудниках дополнительным действием.

3. Запрос точки восстановления системы

Советую пользоваться функционалом по созданию точки восстановления SAP Sales Cloud и откату на эту точку при необходимости.

Уже после начала миграции на продуктивную систему при коммуникации с SAP оказалось, что есть такая рекомендация по SAP Sales Cloud: перед началом миграции нужно запросить точку восстановления (подробнее в нотах 2315326 (создание точки восстановления) и 2560598 (откат на точку восстановления)). Это нужно для обеспечения возможности откатиться на шаг назад, если миграция будет неуспешной по каким-либо причинам. Нам бы такая точка помогла для устранения данных из предыдущего параграфа, что существенно облегчило бы жизнь.

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

4. Оповещение поддержки SAP о начале полной миграции

До начала миграции на продуктивный тенант поддержка SAP посоветовала нам выставить инцидент с ответами на пункты ниже для того, чтобы SAP мог отслеживать производительность серверов продуктивной системы и увеличить скорость миграции, предоставив дополнительные серверы:

1. Сведения о тенанте, в котором выполняется миграция.
2. График миграции – время и даты планируемой загрузки данных.
3. Объем мигрируемых данных.
4. Тип выполняемой миграции и какой метод или инструмент используется для загрузки данных.

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

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

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

После эскалаций инцидента SAP ответил, что производительность увеличил, но на скорость загрузки файлов в DWB это не сильно повлияло – скорость увеличилась на ~10%.

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

Также советую иметь под рукой телефон SAP Contact Interaction Center (можно найти для своей страны на сайте https://support.sap.com/en/contact-us/phone.html), куда я звонил несколько раз для поднятия приоритета инцидентов.

Для инцидентов в приоритете high и very high SAP требует прикладывать заполненный опросник по влиянию проблемы на бизнес-процессы. Опросник содержится в ноте 1281633, прикладывайте его сразу в инцидент при его создании. После момента создания продуктивного тенанта все последующие опросники (даже на тестовой системе) должны быть заполнены по шаблону «Production System».

5. Миграция начальных данных