Минимизация Downtime при обновлении SAP систем и конвертации в S/4HANA. Методы и сценарии

17 августа 2020

Статья будет полезна администраторам базиса, ABAP разработчикам и руководителям проектов до и во время проекта обновления (update/upgrade) системы SAP или конвертации в SAP S/4HANA.

1. Введение

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

Для обновления систем SAP, построенных на основе SAP NetWeaver. используется инструмент SAP SUM (SAP Software Update Manager), который выполняет установку пакетов поддержки (Support package), обновление (Update и Upgrade), конвертацию в S/4HANA, а с опцией DMO (Database Migration Option) миграцию и Unicode конвертацию. SUM c DMO может быть использован для миграции и Unicode конвертации SAP систем на основе NetWeaver ABAP AS без обновления.

2. Сценарии обновления SUM

SUM предлагает несколько сценариев выполнения обновления, с разными подходами к простою системы (Рисунок 1), каждый имеет свои преимущества, недостатки и ограничения. Длительность необходимой остановки системы различна. Выбор сценария зависит, прежде всего от допустимого времени простоя продуктивной системы. Уменьшение downtime влечёт за собой дополнительные затраты на подготовительную работу. Увеличивается не только время проекта, но и проектная команда, вычислительные ресурсы, появляются дополнительные инструменты, в некоторых случаях обязательно привлечение консультантов SAP SE. Не стоит забывать о квалификации членов проектной команды и их доступности для проекта.

Рисунок 1. Сценарии обновления SUM

2.1 “Single system”

Сценарий с самым большим временем простоя, система останавливается на всё время обновления. Копия репозитория и теневая инстанция в этом случаи не создаются, операции выполняются в основных таблицах БД. За счёт этого сокращается общее время обновления. Рекомендуется использовать вместо транзакций SPAM/SAINT при установке большого количества пакетов поддержки. Опция DMO не применима в сценарии.

Стоит отметить, что при обновлении (upgrade), когда при обновлении требуются инсталляционные DVD (например, при обновлении до ERP 6.0 EHP8), теневая копия создаётся.

С версии SUM 2.0 SP07 сценарий “Single system” применим только для установки пакетов поддержки (SP Support Package) и стека пакетов поддержки (SPS Support package stack).

2.2 “Standard”

Самый часто используемый сценарий SUM. Сценарий может быть использован для обновления системы, конвертации в SAP S/4HANA, при использовании опции DMO для миграции и Unicode конвертации.

Во время продуктивной работы создаётся теневая копия системы, в которой выполняется операции обновления репозитория, активация словаря, распределение, импорт языковых пакетов, урегулирование модификаций словаря SPDD и т.д. В downtime происходит переключение репозитория, конвертация таблиц приложений, адаптация данных в новую версию, выполнение урегулирования модификаций SPAU... При использовании опции DMO, процессы R3load копируют таблицы в целевую БД, в uptime репозиторий, а в downtime - остальные таблицы.

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

2.3 Near-Zero Downtime Maintenance (nZDM) (ABAP)

Сценарий применяется при обновлении (update/upgrade) ABAP систем, и не применим при использовании DMO. При конвертации в S/4HANA, текущая система должна использовать SAP HANA как СУБД. Активация сценария доступна в SUM 1.0 c SP07 и SUM 2.0 до SP05 при выборе стратегии Advanced (Рисунок 2 и Рисунок 3).

Рисунок 2. Выбор стратегии SUM. В SUM 1.0 c SP07 и в SUM 2.0 до SP05.

Рисунок 3. Активация опции NZDM.

В SUM 2.0 SP06 и выше, стратегия Advanced исключена, и выбор сценария nZDM стал доступен на экране выбора стратегии как отдельная стратегия (Рисунок 4).

Рисунок 4. Выбор стратегии обновления с опцией nZDM, в SUM 2.0 SP06 и выше

Сценарий сокращает время простоя системы, за счёт переноса части операций на время, продуктивной работы пользователей в системе.

Механизм следующий: в БД создаётся теневая копия системы с таблицами репозитория; далее готовится список таблиц, которые меняются в новой версии, для этих таблиц в БД создаются триггеры для операций insert, delete и update, триггеры фиксируют изменения в журнальных таблицах; таблицы копируются в теневую копию уже с изменённой структурой; по завершению копирования таблиц и до остановки системы на основании журнальных таблиц изменения реплицируются в таблицы теневой копии; после остановки системы, репликация запускается в последний раз и обновление продолжается без необходимости адаптации таблиц которые были скопированы.

CRR Control Center позволяет контролировать процесс репликации, останавливать и запускать процесс, изменять количество фоновых заданий.

В БД требуется дополнительное свободное пространство для теневой копии репозитория и копий таблиц.

Ограничения при использовании сценария в SAP Note 1678564.

2.4 Zero Downtime Option (ZDO)

Сценарий SUM ZDO выполняет обновление с минимальным downtime, который сокращён до времени рестарта сервера приложений, при этом с минимальными требованиями к дополнительному пространству в БД. К сожалению, сценарий накладывает жёсткие ограничения к типу и версии системы. Для систем SAP Business Suite сценарий доступен по запросу, для S/4HANA пока находится в пилоте и его использование доступно как сервис. Полные ограничения и требования для S/4HANA в SAP Note 2707731, для SAP Business Suite в SAP Note 2163060.

Нулевой downtime достигается за счёт переноса действий, выполняемых в период простоя системы в особую фазу «Uptime on Bridge». Мост (Bridge) является по сути клоном системы, но в отличии от знакомой теневой инстанции, его создании копируются только таблицы, которые будут затронуты обновлением. После того как SUM создал мост все пользователи работают через мост, операция выполняется фоновыми процессами и остаётся не заметной для пользователей.

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

Сложные структурные преобразования таблиц, (Например: изменение типа поля с целого в символьное) не могут быть реализованы стандартными триггерами. Такие таблицы после клонирования для пользователей становятся доступны только для чтения. Чтобы понять, как повлияет не возможность записи таблицу на бизнес операции, SAP разработал инструмент SUM Impact Analysis. Подробнее познакомится с SUM Impact Analysis можете в блоге Йенса Фигера (https://blogs.sap.com/2018/03/08/impact-analysis-as-part-of-software-update-manager-2.0/ ) и в SAP Note 2471883.

2.5 Downtime Optimized Conversion (DOC)

Сейчас это - пилотный проект и предоставляется как сервис с привлечением консультантов SAP. Сценарий сокращает время простоя при конвертации в S/4HANA. В отличии от сценария nZDM, здесь разные БД у системы источника и целевой системы. Ниже представлены два рисунка (Рисунок 5 и Рисунок 6) из "Downtime-Optimized Conversion Improving the System Conversion to SAP S/4HANA (pilot program)", приложенного к SAP Note 2293733.

На первом рисунке (Рисунок 5), высокоуровневый план downtime при стандартной конвертации:

Рисунок 5. Стандартный план конвертации в SAP S/4HANA.

При использовании оптимизации, в uptime (Рисунок 6) выносится: конвертация таблиц FIN и MM-ML (при стандартном подходе это ручная операция), конвертация таблиц MM-IM, конвертация полей в таблицах KONV и VBFA, и миграция отдельных больших таблиц, которые не затрагивает конвертация.

Рисунок 6. Изменения стандартного плана при оптимизации.

На рисунке (Рисунок 7) основные компоненты (инстанции, процессы, данные) при конвертации с использованием опции Downtime-Optimized Conversion. Элементы начальной версии обозначены зелёным цветом, конечной версии S/4HANA выделены синим.

Механизм

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти