История одной миграции SAP системы или Век живи, век учись! - III

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

Сегодня рассказ будет не очень кратким. Дело в том, что вторую половину прошлого года я занимался большим проектом по миграции ландшафта из систем SAP на новую платформу и хочу об этом рассказать. Я долго думал, как назвать этот пост. Но, в итоге, всё таки решил отнести его к этой серии. Почему я так поступил, вы поймёте по ходу рассказа. :)

Исходная ситуация - мрак

У заказчика старенькие системы SAP R/3 4.6C работали на уже давно морально устаревшем оборудовании. Когда-то очень хорошее оборудование HP на платформе PA-RISC давно выработало свой ресурс и требовало замены. Ситуация осложнялась тем, что компания HP прекратила разработку и поставку серверов не только на платформе PA-RISC, но и даже на когда-то перспективных процессорах Itanium (всю печальную историю этого процессора можно прочитать тут). Используя сервера на платформе Itanium можно было бы остаться в рамках операционной системы HP-UX и почти бинарной совместимости со старыми серверами. Но поезд ушёл, оборудование полностью морально и физически устарело и ситуация была катастрофическая. SAP системы, как вы поняли, работали на платформе с операционной системой HP-UX, а в качестве базы данных использовалась Oracle 8i. Поддержки со стороны ни одного из производителей программного обеспечения таких старых версий, как вы догадываетесь, тоже уже не было. 

Свет в конце туннеля 

Апгрейд версии SAP системы в рамках данного проекта не планировался. Поэтому анализ Product Availability Matrix для текущей версии системы показал, что, если выбрать платформу x86_64, на которую сейчас переходит большинство вендоров серверного оборудования, то перенос на неё  системы возможен. Правда придётся в качестве целевой операционной системы использовать SUSE Linux Enterprise Server версии 11 с последним SP4, а базу данных обновить до Oracle 10g. Ну и ядро SAP системы необходимо подтянуть до максимального уровня - 46D_EX2 (рис. 1).

Рис. 1. Матрица совместимости для исходной версии системы.

Подготовка - тяжело в учении...

"Тяжело в учении, легко в бою" говорил А.В. Суворов. В проекте миграции так же: самое главное подготовка и тестовая миграция. Чем больше итераций миграции с максимально приближёнными к боевым условиями удастся провести перед самой процедурой, тем легче и чётче пройдёт сам процесс переезда на новое оборудование. 

В связи с тем, что в данном случае планировалось полностью изменить платформу, было принято решение проводить процедуру миграции по схеме Heterogeneous System Copy.
Напомню, что процедура состоит из 3 крупных этапов:

1. EXPORT - выгрузка базы данных исходной системы в файлы универсального экспортного формата SAP.
2. MOVE - перенос экспортных файлов на новый сервер.
3. IMPORT - установка новой версии системы с последующим импортом данных из полученных экспортных файлов.

Сначала я разбирался с экспортом. Оборудование, как я уже говорил, морально устарело, производительность для текущей системы была очень низкая. Но стоит отметить - было и 2 положительных момента:
- относительно небольшой объём базы данных - 2,4 Тб;
- хорошая производительность дискового массива (HP EVA8400).

При экспорте базы данных SAP системы строго рекомендуется останавливать сервер приложений, не останавливая при этом СУБД. Экспериментов в данном случае требовалось много, а тестовой среды у заказчика на момент старта этого проекта не было. Поэтому приходилось всё делать на продуктивной системе. С одной стороны это большой плюс: я проводил тестовые выгрузки на реальном сервере, который будет участвовать в финальной выгрузке. С другой стороны, останавливать продуктивную систему постоянно никто не даст.
В процессе работы в голову пришло решение - делать выгрузки на работающей системе. В выходные дни у заказчика нагрузка со стороны пользователей минимальна, поэтому я по-тихому проводил тестовые выгрузки, нащупывая оптимальные параметры Oracle и количество параллельных потоков. А проблемы возникали. Например, когда при использовании ряда рекомендуемых в SAP notes параметрах Oracle, выгрузка некоторых таблиц зависала, как будто происходили какие-то блокировки на уровне базы данных. Поэтому оптимальные параметры пришлось нащупывать экспериментально. Выгрузки при работающей системе получались не 100% консистентными, но цель была не в этом. За подготовительный период удалось провести 2 или 3 продуктивные выгрузки с остановом сервера приложений SAP и полной загрузкой существующего оборудования.

В итоге, я добился отлаженного процесса экспорта базы данных, который занимал в общей сложности 21 час. Процесс шёл в 7 потоков при 8 процессорных ядрах. Больше потоков запускать не было смысла. Дело в том, что используя старые версии утилит выгрузки можно полу-скриптовыми методами выделить крупные таблицы в отдельные потоки. Но утилиты не позволяют разбивать таблицы на части при выгрузке, как, например, более свежие версии инсталляторов SAP. Ну вы догадались, что выгрузка пары самых крупных таблиц как раз и длилась эти самые 21 час. Дисковый массив был загружен в среднем на 65%, а потоки упирались в производительность по процессорам.

Экспортные файлы заняли около 500 Гб. Это 1/5 от объёма исходной базы данных. При экспорте данных используется сжатие и стоит учесть тот факт, что при этой процедуре не происходит выгрузки табличных пространств PSAPTEMP и PSAPROLL/PSAPUNDO, а также индексов. Индексы генерируются заново на этапе IMPORT. Поэтому объём файлов в экспорте меньше объёма исходной базы данных.

С этапом переноса файлов больших проблем не было. SAP не рекомендует использовать для переноса файлов по сети NFS, поэтому была отработана процедура переноса по протоколу FTP. Старые сервера имели на борту сетевые адаптеры на 1 Гбит/сек, поэтому перенос на новое оборудование 500 Гб требовал 2,5 часа времени. При копировании использовалась утилита wget, которая позволяет одной командой легко инициировать копирование структуры директорий с файлами. Информацию про неё нашёл тут.

Дополнительные затраты по времени занял процесс проверки контрольных сумм (CRC) файлов после переноса. На исходном сервере процесс сбора контрольных сумм утилитой cksum, работая в один поток, занимал 2 часа. Благо этот процесс можно было совместить с этапом самого копирования файлов по сети. А на новом оборудовании утилита cksum отрабатывала за 30 минут. Для сравнения файлов с контрольными суммами использовалась утилита diff. В итоге, расчётное время для данного этапа составило - 3 - 3,5 часа. 

Для тестирования третьего шага миграции (IMPORT) компанией HP был предоставлен во временное пользование сервер с целевой архитектурой. Это был сервер начального уровня HPE ProLiant DL380 Gen10 с процессорами Intel Xeon Gold 6136 и внутренним RAID контроллером, где 12 SAS дисков, объединённые в RAID уровня 6, образовывали единое дисковое пространство. И до поставки и настройки основного аппаратного комплекса я использовал данный сервер.

Разговор про процесс установки очень старой системы SAP R/3 4.6C на относительно современную платформу из SLES 11 и Oracle 10g я даже начинать не буду. Установочные файлы и сам процесс пришлось буквально собирать по крупицам из десятков SAP notes и других источников. Версия системы старая, вряд ли кому-то сейчас это будет интересно.

Поэтому сразу перейду к одному из самых затратных по времени процессов установки системы - импорту данных в новую копию системы. Напоминаю ещё раз: версии системы SAP и всех утилит установки очень старые. Гибкости совершенно никакой. Скрипты берут экспортные файлы с данными исходной базы и загружают их в новую базу. Если при экспорте последовательность файлов легко прослеживалась - файлы (потоки) шли по алфавитному порядку. То при процессе импорта утилита не использовала порядок ни по алфавиту, ни по времени создания файлов. Последовательность при этом была, причём для каждого сервера своя! То есть утилита для каждого сервера определяла свой порядок и уже не меняла его при повторных попытках установки и импорта целевой системы. Но от чего зависит этот порядок для конкретного сервера мне понять так и не удалось! Поэтому повозившись пару недель с этим моментом, я смирился.
При импорте также можно поиграться с параметрами Oracle, выставив их в оптимальные значения для загрузки данных и массовой генерации индексов. 

Аналогичным образом утилиты позволяют поиграться с параллелизмом. Современные процессоры семейства Intel Xeon имеют много физических и логических ядер, поэтому даже при ограничении количества процессорных сокетов в одном сервере дают хорошее общее количество процессорных ядер. В общем, не буду долго ходить вокруг да около, результаты моих экспериментов на тестовом сервере приведены в таблице (рис. 2).

Рис. 2. Затраты времени на этап IMPORT на тестовом сервере DL380.

Помимо разного количества потоков прогоны отличались еще последовательностью загружаемых таблиц (процесс не контролируемый, как я писал выше) и параметрами Oracle. По процессорам ресурсов было достаточно, но всё упиралось в дисковую подсистему. Я пробовал и больше потоков (16), но процесс только растягивался во времени. Задержки (latency) на дисковом массиве подсказывали, что больше выдавать он не может. Я смирился с данными временными параметрами для этого этапа. Была надежда (даже уверенность) что дисковый массив продуктивного комплекса уровня Enterprise, да ещё и полностью на SSD дисках, даст процессу импорта развернуться и покажет сокращение временных затрат. 

И вот настал тот день, когда целевой аппаратный комплекс был инсталлирован, настроен и передан в мои руки. Ну сейчас я развернусь, подумал я. :)

Знаете сколько импортировались данные на сервере, расположенном на новом комплексе? С учётом больших объёмов физической памяти и щедро настроенных буферов Oracle. С учётом дискового массива HPE 3PAR StoreServ 8440 полностью на SSD дисках. С учётом RAID 1 массива, собранного для максимального быстродействия не только по чтению, но и по записи. 12 потоков импорта данных и итоговое время 38 часов! Сказать, что я был разочарован, ошарашен или взволнован, это совсем никак не выразить гамму моих чувств. Я не был совершенно похож на довольных инженеров со страницы с описанием дискового массива. Я был просто раздавлен этими цифрами. Время на тестирование процесса еще оставалось, поэтому я перепроверил цифры, перезапустив процесс копирования системы ещё пару раз. Результат с учётом погрешности был примерно один и тот же. Даже 16 потоков дали 33,5 часа общего времени на этап IMPORT.

К задаче были подключены инженеры HP, отвечающие за подготовку железа, дискового массива и оптической сети. Было перечитаны ещё раз все Best Practics. Переведены виртуальные диски, созданные на 3PAR, с "тонких" на "толстые". Включена балансировка на всех уровнях оптической сети и коммутаторов, перепроверены параметры на всех уровнях системы. Но результат был всё тот же. 

Инженеры по оборудованию даже организовали мне показательное выступление с синтетическими тестами максимальной скорости по Мб/сек и IOPS, которые может максимально выдавать дисковый массив при сохранении низких значений latency и Service Time со стороны 3PAR. Таким образом, доказав мне, что на уровне оборудования всё прекрасно. Но почему процесс импорта не укладывался в меньший интервал? Процессорных ресурсов достаточно. Дисковый массив явно одной левой отрабатывает запросы от систем. Кто же тогда виноват?

Немало часов и дней я провёл в размышлениях и экспериментах. И неожиданно нащупал "узкое место". Если вы спросите меня "Как?", то могу только предположить. Однажды, отчаявшись, я просматривал журнал Oracle и увидел ошибку "Chekpoint not complete", в которой, в принципе, нет чего-то удивительного при массовых операциях загрузки в базу данных. Но это меня зацепило. Нашёл и перечитал SAP note 79341 - Checkpoint not complete. Одна из причин в журнальных файлах, говорилось в ней. Я вспомнил, что что-то про это было в, много раз перечитанной вдоль и поперёк, SAP note 806554 - FAQ: I/O-intensive database operations. Потом посмотрел SAP note 936441 - Oracle settings for R3load based system copy. И начал эксперименты. Результаты вы можете видеть в таблице (рис. 3).

Рис. 3. Затраты времени на этап IMPORT на целевом оборудовании.

Вы уже догадались, что проблема была в журнальных файлах (Redo Logs)! Инсталлятор  R3SETUP для системы SAP R/3 4.6C был спроектирован для установки системы на базу данных Oracle версии 8i. При установке системы автоматически создаются журнальные файлы в 4 группах, в каждой по 2 копии, размером 20 Мб! Для пустой начальной базы системы SAP R/3 в 20 Гб это нормальный размер. Но для загрузки продуктивных данных, накопленных за много лет (2 Тб), этого размера явно недостаточно. В SAP notes упоминали, что надо бы отключить зеркалирование журналов, оставив только одну копию в группе. Но я решил, что заодно, можно сразу поиграться и с размером. Всё равно его после разворачивания системы надо было увеличивать. Сконфигурировал останов скрипта установки системы R3SETUP и пересоздал группы журналов с одной копией нужного мне размера. Результатом стал взрывной рост скорости загрузки и уменьшение итогового времени. Изначально, понадеявшись, на производительность оборудования, я не подумал, что частое переключение между маленькими файлами журналов будет тормозить весь процесс. Век живи, век учись! В результате дальнейших экспериментов остановился на журналах по 1024 Мб (без копии) и 12 потоках. При этом процесс импорта ощутимо сильнее нагрузил процессоры и дисковую подсистему. А то до этого момента складывалась парадоксальная ситуация: ресурсов много, а процесс импорта их не использует.

Любопытства ради, я увеличил размер журналов и прогнал импорт и на тестовом сервере DL380. Выжал в итоге всё из внутреннего дискового массива, получив 12,5 часов итогового времени! 

Процесс переезда - легко в бою

Ну а сам процесс переезда прошёл легко и скучно. :) Перед последним прыжком был создан финальный план, куда я включил все полученные временные интервалы с запасом 15-20%. Были выделены выходные. И за два дня, в спокойном режиме, уложившись во все предыдущие измерения, был выполнен перенос системы на новое оборудование.
Итоговое время получилось: 21 + 3 + 6 = 30 часов. Плюс время на донастройку системы, подключение дополнительных инстанций SAP, тестирование.
Начальная цель выполнить переезд за выходные была достигнута.

А у меня от этого проекта осталась борода и стало может быть чуть-чуть побольше опыта. :)

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

Век живи, век учись!

Предыдущие выпуски:

• Век живи, век учись! - I
• Век живи, век учись! - II

Автор: Шиболов Вячеслав Анатольевич

Тестовая система в SAP ландшафте

Не так давно в посте "Почему SAP рекомендует 3-х системный ландшафт?" я описывал односистемный, двухсистемный и трёхсистемные ландшафты. В посте я показал, что трёхсистемный ландшафт является минимально достаточным для организации корректной разработки и контроля качества в SAP системе.

Таким образом, типовой SAP ландшафт (рис. 1) состоит из 3-х систем:

• система разработки и настройки (DEV),
• тестовая система или система контроля качества (QAS),
• продуктивная система или система промышленной эксплуатации (PRD).

Рис. 1. Трёхсистемный ландшафт.

Остановимся на тестовой системе.

Тестовая система выполняет следующие основные функции:

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

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

Способы обновления могут быть следующими:

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

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

Итак, при создании тестовой системы смотрим на архитектуру оборудования, которое выделено под эти цели. Если архитектура отличается от продуктивной системы, то при создании тестовой системы придётся использовать процедуру гетерогенного копирования систем. Процедура длительная: требуется останов продуктивной системы и создание экспорта базы данных. Также в такой тестовой системе ограничен набор сценариев тестирования. Если в тестовой системе будет использоваться другая база данных, то тестирование разработок, в которых используется NativeSQL, вызывает большой вопрос. Тест производительности так же будет носить очень отдалённый характер, в силу больших различий со средой промышленной эксплуатации.

Если же архитектура идентична, то вопрос создания тестовой системы решается через гомогенное копирование. В качестве источника данных в данном случае отлично подойдёт существующая резервная копия продуктивной базы данных (offline или online + redo logs).

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

• копирование содержимого отдельных таблиц: позволяет обновить только один функциональный модуль или его часть. Очень медленный способ. Перенос данных выполняется через транспортный запрос. Как включить содержимое таблицы в транспортный запрос я описывал в этом посте. При повторном переносе можно воспользоваться советом из поста "Саповские секретики - III (секретик 2)" и, создавать новый запрос через копию содержимого старого запроса. Процедура возможна только в крайнем случае и только при контроле и управлении со стороны опытного функционального консультанта. Результат не всегда гарантирован. Но в практике иногда применяется.
• копирование манданта системы: возможно использование процедуры удаленного копирования манданта или экспорта/импорта манданта. Все способы описаны в этом посте. Процедура очень сильно нагружает обе системы (продуктивную и тестовую), работа в продуктивной системе должна быть минимальна, иначе высока вероятность возникновения проблем с целостностью данных. 
• гетерогенное копирование системы - фактически полное удаление и установка тестовой системы по новой. Требует останова продуктивной системы на момент создания экспорта данных. Длительные временные затраты на создание копии в целом.

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

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

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

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

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


Автор: Шиболов Вячеслав Анатольевич

 

Копирование SAP систем - III. Гетерогенное копирование.

Итак, как вы уже знаете, есть 3 варианта создания копии SAP системы:

• Перенос системы с сохранением SID на новый сервер в рамках той же платформы (Disaster system recovery),
• Гомогенное копирование системы (Homogeneous system copy),
• Гетерогенное копирование системы (Heterogeneous system copy).

В рамках данной темы нам осталось рассмотреть последний тип процедуры - гетерогенное копирование системы (heterogeneous system copy) или, как ее еще называют, database independent system copy. Данный метод предполагает, что при копировании изменится платформа, на которой работает система SAP. Под платформой понимается определенный тип операционной системы, работающей на определённом оборудовании (тип и разрядность процессора) и база данных (производитель, версия, разрядность). Например, мы должны перенести/скопировать систему с сервера под управлением Windows с базой данных Oracle на платформу AIX/DB2.

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

1. Собрать информацию об исходной системе: версии операционной системы, SAP-системы, базы данных, SAP компонент, SAP ядра. Рассчитать необходимые требования к аппаратному обеспечению, размеру дискового пространства на целевом сервере.
    
2. Подготовить целевую систему: установка операционной системы, обновление, настройка и подготовка к установке SAP системы (как и при обычной установке). Примеры подготовки операционных систем можно найти на странице моих инструкций.
    
3. Подготовить установочные диски на целевой системе. Скачать последнюю версию утилиты установки SAP системы (SAP SWPM).
    
4. Создать экспорт базы данных исходной системы. Выполняется с помощью той же утилиты установки системы (SAP SWPM) путем выбора специального раздела "Тип исходной системы -> Software Life-Cycle Options -> System Copy -> Тип базы данных исходной системы -> Source System Export" (рис. 1).
   
   

   

   Рис. 1. Экспорт базы данных.

   
   Таким образом, для установки системы мы создаем собственный срез экспортных дисков.
    
5. Скопировать экспорт исходной базы данных на целевую систему.
    
6. Начать установку SAP системы, выбрав специальный пункт меню на начальном экране (рис. 2).
   
   

   

   Рис. 2. Начальный экран SAP SWPM при гетерогенном копировании SAP системы.

    
7. На одном из этапов установки система спросит Migration Key, который можно получить на SAP Support Portal по ссылке http://service.sap.com/migrationkey. Либо, если в исходной системе во время экспорта была установлена лицензия нового образца (с цифровой подписью), то можно воспользоваться универсальным ключом из SAP ноты 1768158 - System Copy of Systems Based on SAP NW 7.0 / 7.0 EHP 1-3.
    
8. Выполнить дополнительные шаги после копирования системы. Если необходимо, то обновить/откатить SAP kernel до версии исходной системы.
    
9. Запросить и установить постоянную лицензию в транзакции SLICENSE.

Для примера предлагаю рассмотреть процедуру создания гетерогенной копии системы SAP ERP 6.0 SR3. Исходная платформа MS Windows 2003/Oracle 10g, целевая - ORACLE Linux/ORACLE 11g.  

Инструкцию можно скачать тут (zip-архив, 1900 Кб).

Дополнительные SAP ноты:

- SAP note # 1768158 - System Copy of Systems Based on SAP NW 7.0 / 7.0 EHP 1-3,

- SAP note # 715701 - Migration to SAP DB/MaxDB,

- SAP note # 82478 - SAP system OS/DB migration,

- SAP note # 813964 - Migration Key Wrong - Release 4.7 and Web AS 6.x.

Автор: Шиболов Вячеслав Анатольевич