Привет, Хабр! Я Сергей Маслаков из команды администраторов SAP BASIS в «Северсталь-Инфоком». Хочу рассказать о том, как мы научились управлять всеми ландшафтами SAP-систем из единого интерфейса, автоматизировали значительную часть рутинных задач и ускорили их выполнение. Под катом история о нашем опыте внедрения SAP Landscape Management (LaMa) 3.0, а также подробный гайд по оптимизации процесса обновления систем HANA продуктивными данными.
Почему мы решили завести LaMa
Задача нашей команды — обслуживать SAP-системы, базы данных (SAP HANA) и серверы, на которых всё это работает. Трудов постоянно прибавлялось: у компании появлялись новые проекты, становилось больше систем, разрастались ландшафты. К концу 2018 года мы едва успевали поддерживать всё это хозяйство в работоспособном и актуальном состоянии. К тому же в процессе обслуживания доступ к отдельным системам приходилось закрывать на несколько дней, что не особо радовало пользователей. Нужно было ускорить эти рутинные процедуры, найти максимально простое решение для их автоматизации.
Мы регулярно общались с коллегами из SAP, поэтому уже знали про Landscape Management. Решение сразу подкупило тем, что с его помощью прямо из коробки, не изобретая велосипед, можно автоматизировать самые актуальные для нас сценарии. И все системы под контролем: подключённые ландшафты, их компоненты и статусы визуализируются в LaMa в виде списков и таблиц. Ранее о такой централизации мы только мечтали, к каждой из систем приходилось подключаться по отдельности. Да и работать с графическим интерфейсом удобнее, чем с командной строкой.
LaMa — продукт, который заточен под SAP-системы, при этом можно кастомизировать его, расширить функциональность, настроить взаимодействие с другими ландшафтами. Есть API, через который с LaMa могут взаимодействовать внешние системы, и наоборот. Но для начала мы решили попробовать один из коробочных сценариев — обновление систем продуктивными данными.
Как мы приручали LaMa
Начали мы с одной из систем на HANA с объёмом данных около 5 Тб. Раньше процедура обновления тестовых систем продуктивными данными выполнялась вручную и занимала 4–5 рабочих дней. Всё это время пользователям приходилось терпеливо ждать, пока администратор:
восстанавливал систему на точную дату и время (point-in-time recovery);
отключал все продуктивные связи с другими системами (фоновые задания, RFC);
восстанавливал пользователей и их полномочия на состояние до копирования;
переименовывал все логические системы с продуктивных на тестовые;
восстанавливал интеграции с другими тестовыми системами.
И так примерно раз в квартал.
Для всего процесса разработали чёткие инструкции, расписали по шагам последовательность действий и затрачиваемое на них время — как для администратора, так и для функциональных консультантов. У нас появился вот такой чек-лист, с которым можно прогнозировать затрачиваемое на обновление время, вносить в процедуру коррективы и отслеживать прогресс:
1. Сохранить текущие настройки.
2. Сохранить всех пользователей и их полномочия (экспорт клиента с профилем SAP_USER).
3. Выполнить восстановление из продуктивного бэкапа в целевую систему.
4. Обновить систему с помощью мастера System refresh.
5. Восстановить настройки (которые мы сохранили в п. 1).
6. Выполнить остальные настройки.
7. Импортировать данные пользователей (из п. 2).
Проанализировали список и решили, что попробуем оптимизировать этапы 1, 5 и 6. Остальные шаги решили пока не трогать: участие администратора в них минимально, время выполнения — около 30 часов — зависит от производительности серверов, параметров сети, объёма БД.
В два раза быстрее с помощью коробочной утилиты
Чтобы автоматизировать действия вроде тех, что мы собрали в чек-листе, в LaMa предусмотрена очень удобная утилита — Post-Copy Automation (PCA). К ней прилагается набор таск-листов, сформированных под конкретные задачи в соответствии с лучшими практиками SAP. Нам нужно только заполнить параметры, которые соответствуют системе, — и LaMa пошагово выполняет все действия.
Для использования PCA нам потребовалось два таск-листа:
экспорт-импорт настроек и данных (SAP_BW_BASIS_COPY_REFRESH_CONFIG);
переименование всех логических систем с продуктивных на тестовые (SAP_BASIS_COPY_BDLS).
С этими пресетами мы уже значительно ускорились. Но можно и ещё лучше: таск-листы PCA легко кастомизировать, добавлять или отменять действия. Например, если шаг не нужен — убираем галочку либо удаляем всю строку. И мы выявили ряд длительных шагов, которые можно исключить за ненадобностью. Так, в целевой тестовой системе не требуется история CCMS:
За счёт сокращения шагов в таск-листах экспорт и импорт настроек удалось сократить ещё на 30–40% от полученного результата. Чтобы не удалять лишние шаги перед каждым запуском, мы сохранили обновлённый список, а вводимые параметры сохранили как вариант запуска.
Всё это сложили в запрос и протащили по всему ландшафту. Теперь при обновлении тестовой системы продуктивными данными мы не теряем ранее сконфигурированные списки и варианты их запуска.
Автоматизировав выполнение настроек и их сохранение, мы смогли обновляться в два раза быстрее, за 2–2,5 дня. Напомню, что вручную обновление делали 4–5 дней — отчасти из-за того, что приходилось прерывать процесс по окончании смены. LaMa, в отличие от живых админов, не возражает против режима 24/7 и не ставит работу на паузу.
Не собирались, но оптимизировали. Правда, пришлось написать скрипт
С PCA мы сократили время, которое затрачивалось на этапах 1, 2, 5, 6 и 7. А ведь мы даже не предполагали, что наша оптимизация затронет второй и седьмой этапы. Возможно, LaMa поможет улучшить процесс и на остальных этапах — 3 (восстановление из продуктивного бэкапа в целевую систему) и 4 (обновление системы с помощью мастера System Refresh)?
В LaMa есть стандартные функции работы с файловыми бэкапами, но готового решения для необходимого нам восстановления системы на конкретную точку во времени (point-in-time recovery) разработчики не предусмотрели.
Для автоматизации этого этапа мы использовали возможность переопределения шага. Написали простой скрипт, который запускал восстановление целевой системы HANA из систем резервного копирования (Backint), а в качестве параметра принимал дату и время, на которую требуется восстановление. Скрипт регистрируется через Host Agent.
В последующих версиях LaMa появилась поддержка восстановления HANA из систем резервного копирования, но выбирать пока что можно только из списка доступных бэкапов. Использовать бэкап-логи для восстановления на нужную точку времени по-прежнему нельзя. Ждём эту возможность в новых версиях.
Последний апгрейд и стопроцентная автоматизация процесса
Все необходимые настройки и параметры для System Refresh должны быть сконфигурированы в LaMa: настройки сети, репозитории с дистрибутивами, логины, пароли для служебных учетных записей, необходимые соединения с управляемыми системами. Помимо этого, для систем, с которыми планируется использовать сценарий System Refresh, должна быть активирована опция Copying:
При добавлении исходной и целевой системы в LaMa указываются все необходимые для управления пароли. Эти же пароли могут быть использованы и в рамках нашей задачи. Теперь наш 4-й этап, System Refresh, можно выполнить из LaMa. Большая часть параметров для запуска мастера, через который выполняется System Refresh, в LaMa уже есть. На этапе запуска достаточно подтвердить логины и пароли технических пользователей, указать дату и время восстановления, а также указать таск-листы для утилиты PCA. Итак, запускаем мастер уже внутри LaMa:
Проходим все шаги, указав точку восстановления и кастомизированные таск-листы с готовыми вариантами запуска на этапе с PCA:
Весь этот диалог можно сохранить как вариант запуска, чтобы в дальнейшем выполнять всю последовательность действий в автоматическом режиме. Используя этот шаблон, можем добавить процедуру во встроенный в LaMa календарь для запуска в пятницу вечером и получить обновленную систему к началу рабочей недели.
Так мы избавили коллег от вынужденных простоев: процедуру можно запустить на выходные, вмешательство администратора в процесс не требуется.
Что ещё умеет LaMa
Описанную выше утилиту Post-Copy Automation удалось применить для оптимизации большого числа рутинных операций — в том числе проверки состояния и перезагрузки систем, серверов приложений, баз данных и пр.
С помощью LaMa мы упростили процедуру Rolling Kernel Switch, которая обновляет ядро системы на каждом из серверов приложения, сохраняя доступность системы для пользователей в целом. Принцип состоит в том, чтобы заранее вывести один из серверов из группы и изолировать его до тех пор, пока на нём не завершатся все пользовательские сессии. Затем делается обновление ядра либо изменяются некие статические параметры, которые применяются системой только после перезапуска. Перезапускаем сервер, возвращаем его в группу — и он снова доступен для пользователей. Такая процедура повторяется по очереди для остальных серверов.
Технология не новая, но раньше мы запускали процесс через консоль. В LaMa у Rolling Kernel Switch появился графический интерфейс — для управления и мониторинга хода выполнения. Плюс теперь есть возможность запланировать процесс одновременно на нескольких системах.
Обновление с минимальной недоступностью системы (Near Zero Downtime Upgrade) — стандартная процедура для систем HANA с репликацией, но с LaMa мы смогли запускать её по готовому сценарию: обновление пассивной ноды, установка репликации — чтобы ноды снова «сдружились», перенос активной ноды на пассивную, обновление второй ноды. Ручные действия администратора не требуются, LaMa подключает систему к базе данных, указывает дистрибутив, из которого нужно выполнить компоненты, — и система обновляется самостоятельно.
Стоит отметить, что мы используем системные ландшафты на HANA с настроенной репликацией только в продуктивных системах. Дублировать «железо» такого класса — слишком дорого для систем теста и разработки, где нет высоких требований по доступности и отказоустойчивости.
Итоги и планы
Этап внедрения можно считать завершённым, инструмент перешёл в эксплуатацию, доступ к нему получили все наши администраторы. Есть написанные ранбуки по сценариям, которые мы уже протестировали. Коллеги постепенно пробуют работать с новым инструментом, применяют его в своей работе.
Но уже сейчас за счёт внедрения LaMa нам удалось:
сократить время по обновлению HANA на 20%;
обновлять тестовые системы во внерабочее время, за выходные;
исключить человеческий фактор при выполнении ручных действий;
объединить в одном интерфейсе все системы SAP;
выполнять большое число однотипных операций одновременно;
выполнять регулярные сценарии автоматически, по расписанию.
Конечно, инструмент не универсален: его достаточно сложно использовать для задач, не связанных с продуктами SAP. Но мы всё-таки попробуем: с этим связаны планы интегрировать LaMa с другими инструментами, в частности с Ansible.
Кроме того, собираемся наращивать количество используемых сценариев из коробки — мы опробовали далеко не всё. Хотим решать и инфраструктурные задачи — например, устанавливать обновления на ОС. Если у вас есть опыт подобной интеграции или другие идеи относительно использования LaMa — приглашаю обсудить это в комментариях.
