Сегодня рассказ будет не очень кратким. Дело в том, что вторую половину прошлого года я занимался большим проектом по миграции ландшафта из систем 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 и всех утилит установки очень старые. Гибкости совершенно никакой. Скрипты берут экспортные файлы с данными исходной базы и загружают их в новую базу. Если при экспорте последовательность файлов легко прослеживалась - файлы (потоки) шли по алфавитному порядку. То при процессе импорта утилита не использовала порядок ни по алфавиту, ни по времени создания файлов. Последовательность при этом была, причём для каждого сервера своя! То есть утилита для каждого сервера определяла свой порядок и уже не меняла его при повторных попытках установки и импорта целевой системы. Но от чего зависит этот порядок для конкретного сервера мне понять так и не удалось! Поэтому повозившись пару недель с этим моментом, я смирился.
При импорте также можно поиграться