Мастер-класс по архитектуре SAP HANA

В прошлую пятницу, 27 октября, я посетил мастер-класс "Архитектура решений на SAP HANA. Рекомендации". Мастер-класс проводился в рамках осенней сессии мастер-классов SAPLAND. Попал я на него бесплатно, как автор статей на портале. За что порталу отдельная благодарность.

Сразу скажу, что я ни разу не пожалел о своём посещении. На этот мастер-класс я пытался попасть ещё весной 2017 года, но, к сожалению, его тогда отменили - в последний момент оказалось только 2 участника. В этот раз было 11 человек. Отдельно хочу отметить ребят из "М-Видео", которые активно делились опытом использования BW on SAP HANA.

Организация семинара была осуществлена на базе учебного центра "Специалист при МГУ им. Н. Э. Баумана". В целом за организацию можно поставить твёрдую четвертку. Учебные классы хорошие, хотя участие в мастер-классе было пассивное, никаких практических заданий не было. Чай-кофе, вода, раздаточные материалы. Девушки из SAPLand, я считаю, отработали на 5. Понятное дело, что сравнение с учебным центром SAP в Москве некорректно, туда вложено больше денег и уровень там другой. Ну и для однодневного семинара это всё не так принципиально.

Автору мастер-класса Михаилу Вронскому отдельное спасибо. Материал был объёмный и при этом всё крайне полезно. Работали практически без перерывов, чтобы всё успеть. Было много практических рекомендаций и обсуждения опыта автора и участников. Я бы даже сравнил количество материала с 2-3 днями хорошего семинара. Только практики не было.

Небольшие заметки по мастер-классу (это лишь 10 % того, что там было :) ).

SAP HANA - база данных с поколоночным хранением данных и обработкой в оперативной памяти. Была впервые представлена в 2011 году. После этого на работу с данной базой данных была переведена система SAP BW. Решение носило название SAP BW on (powered by) SAP HANA или BWoH. Затем решение было полностью интегрировано в платформу SAP HANA и решение стало носить название SAP BW4/HANA (рис. 1).

Рис. 1. Эволюция решений SAP BW, использующих платформу SAP HANA.

Затем пришло время другим решениям от SAP переходить на новую платформу. Сначала появились продукты SAP Business Suite on (powered by) SAP HANA, а сейчас - SAP S4/HANA (рис. 2).

Рис. 2. Эволюция решений SAP Business Suite, использующих SAP HANA.

Таким образом, решения SAP BW4/HANA и SAP S4/HANA являются продуктами, в которых интеграция с платформой SAP HANA достигла такого уровня, что эти продукты могут работать только на ней. Эти решения используют новую модель данных, оптимизированную под SAP HANA.

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

SAP заявляет, что с 2025 года он не будет поддерживать свои решения на других СУБД, кроме SAP HANA. Учитывая тот факт, что на данный момент в мире больше половины решений SAP используют в качестве базы дынных - Oracle, заявление вызывает некоторый скептицизм.

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

Соответственно, систему SAP BW проще перевести на BW4/HANA, ERP сложнее. Хороший вариант: перевнедрение - установить систему рядом и переносить данные перед стартом в промышленную эксплуатацию.

Для OLAP систем - автор рекомендует переходить на SAP HANA, для OLTP систем можно не спешить, надо взвешивать все за и против. Особенно для высоко-нагруженных систем.

Есть решение ORACLE in-memory, когда в памяти выделяется область для копирования таблиц в поколоночное хранение. Это увеличивает скорость работы. Но в SAP HANA идет изменение модели хранения и изменение кода.

На данный момент поддерживаются следующие версии SAP HANA:

• SAP HANA 1.0 SPS12 (поддержка до 2021 года),
• SAP HANA 2.0 SPS01,
• SAP HANA 2.0 SPS02.

Версию SAP HANA 2.0 пока поддерживают не все системы.
Новый график выхода версий (SPS) - раз в год (апрель).

Оборудование (для продуктивных систем): только х86_64 (для HANA 2.0 от Intel Haswell и выше) и ограниченная поддержка IBM Power (для HANA 2.0 IBM Power 8). Всё оборудование должно быть сертифицировано SAP (до конкретной модели сервера). Системы хранения данных тоже только сертифицированные.

Операционные системы: только Linux - SLES или RHEL и только определенных версий.
В качестве ОС, автор рекомендует SLES, так как разработка SAP NetWeaver и SAP HANA в SAPLabs ведется именно на ней.

Подробности в PAM.

Возможно 2 варианта проектирования:

• покупка готового решения (Appliance): готовый сервер+СХД+все оборудование, предустановленная SAP HANA, запуск, обучение.
• конфигурация всего по отдельности (Tailored Data Center или TDI): покупка оборудования, системы, монтаж, установка, запуск. 

Первое решение дорогое, второе дешевле и более гибкое.


Выделяют 2 архитектуры разворачивания:

• Scale-up - одна HANA нода. Рекомендуется для SAP ERP on HANA. Более производительное решение, но для апгрейда требует замену полностью всего оборудования на новый Applience. 
• Scale-out - несколько HANA нод, объединенных в одну базу. Рекомендуется для BW on HANA и BW4/HANA. Позволяет наращивать объем памяти через добавление новых нод. Так же добавляет некоторую отказоустойчивость.

Виртуализация не рекомендуется для SAP HANA, а отказоустойчивый кластер, наоборот, настойчиво рекомендуется.

В SAP HANA есть свой WebAS. Весь инструмент работы с SAP HANA переводится в Web.
Текущий инструмент, SAP HANA Studio не имеет будущего.

Примеры установки и использование SAP HANA можно посмотреть на рис. 3.

Рис. 3. Примеры разворачивания и использования платформы SAP HANA.

Есть проблема с лицензированием BW4/HANA - полностью изменена модель: с пользователей на лицензирование по объему памяти.

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

• SAP HANA Express edition (в виде самостоятельной установки или готового образа ВМ),
• SAP Solution Manager 7.2 on SAP HANA 1.0.

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

Пример проблемы при переполнении файловой системы

Хочу описать небольшую ситуацию, которая является примером проблемы администратора и её решения (troubleshooting). Утром одна из систем была обнаружена в недоступном для пользователей состоянии. Анализ показал, что инстанция SAP запущена, а база данных Oracle нет. После старта базы данных система стала доступна для работы, а последующий анализ показал, что не завершился ночной оффлайн бэкап базы данных. Про резервное копирование я писал в посте "Резервное копирование SAP системы". 

Так как при оффлайн резервировании база данных Oracle на время копирования данных останавливается, то утром она была обнаружена как раз в остановленном состоянии.

Анализ журналов копирования показал ошибку при старте базы данных после резервирования: при записи журналов не хватило места на какой-то файловой системе сервера (рис. 1).

Рис. 1. Ошибка в журнале оффлайн резервирования базы данных Oracle.

Тут стоит вспомнить один из моих недавних постов "Анализ места на диске в Unix". Вооружившись советами из статьи и командами bdf и du, можно легко обнаружить, что в домашней директории Oracle закончилось свободное пространство. Много места занимает директория с журналами (log), а именно журнал процесса Listener (рис. 2 и 3).

Рис. 2. Вывод команды bdf.

Рис. 3. Анализ размера директорий в файловой системе.

Тут опять же, стоит вспомнить пост "Старые журналы событий SAP и ORACLE", в котором я упоминал про этот журнал. Данный журнал хранит информацию о соединениях процессов SAP с Oracle. Смело очищаем и высвобождаем место (рис. 4).

Рис. 4. Удаление содержимого журнала listener.log.

После этого проблема решена. 

Стоит отметить, что при настроенном мониторинге (например, через CCMS мониторинг) такой проблемы бы не возникло. 

Первая задача администратора: сделать так, чтобы всё заработало. 

Вторая задача: разобраться в ситуации, выяснить причины ошибки и выполнить шаги, чтобы не допустить повторение ошибки в будущем. 

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

Опрос: Windows vs Unix

Предыдущий опрос про опыт администрирования SAP систем завершён. Результаты и обсуждение тут.

Предлагаю новый опрос. Представьте, что необходимо установить продуктивную SAP систему. Согласно PAM возможна установка на операционные системы семейства MS Windows и Unix-подобные (Linux, AIX, HP-UX и т.п.). Никаких особых ограничений ни в одной, ни в другой операционных системах со стороны SAP нет.
Что вы выберете для продуктивной системы? Ваше личное мнение. Анонимно. :)

Опрос завершён. В опросе приняло участие 44 человека. Всем спасибо за участие.

Итоги получились ожидаемыми: с большим отрывом победили Unix системы (рис. 1).

Рис. 1. Результаты опроса.

Моё личное мнение совпадает с мнением большинства. Я бы тоже выбрал Unix-подобную операционную систему. По объективным и субъективным причинам. Люблю я их. :)

Хотя чаще надо выбирать головой. Например, учитывать при выборе факт наличия навыков и опыта работа с операционной системой у администраторов и политики компании.

В пользу Linux стоить отметить тот факт, что база данных SAP HANA, которую компания разрабатывает уже 5 лет, работает только на Linux. На Windows они её так и не портировали.

Распределение участников опроса по странам, если кому интересно, можно найти на рис. 2.

Рис. 2. Участники опроса по странам.

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

Создание ярлыка для соединения с SAP системой без пароля

В последнем посте "Саповские секретики - V", в качестве одного из секретов, я рассказывал, как создать ярлык для соединения к SAP системе. При создании ярлыка можно было указать, помимо целевой системы, манданта и языка, транзакцию, которую необходимо запускать сразу после входа в систему. Так же можно было указать имя пользователя, из под которого будет создаваться соединение (рис. 1). Пароль же вводится при открытии соединения через ярлык. И это безопасно и правильно. В данном случае пароль хранится у вас в голове и в SAP системе.

Рис. 1. Создание ярлыка для соединения.

Но, если очень хочется, то можно указать пароль в SAP систему прямо во вновь созданном ярлыке. Для этого необходимо внести изменения в реестр Windows, открыв его командой regedit и добавив по пути HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security параметр "EnablePassword"="1" (рис. 2).

Рис. 2. Внесение изменений в реестр Windows.

Либо можно создать файл-корректировку для реестра (расширение .reg) с содержимым вида:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security]
"EnablePassword"="1"

Выполнить созданный файл, внеся изменения в реестр. И перезапустить программу SAP Logon.

После этого при создании ярлыка для соединения, поле пароля будет открыто на изменение и можно будет внести пароль пользователя, из под которого будет выполняться соединение в будущем (рис. 3).

Рис. 3. Сохранение пароля в ярлыке для соединения.

Вносим пароль пользователя и сохраняем ярлык. После этого вход в систему будет осуществляться без ввода пары пользователь/пароль.

Хотя пароль хранится в ярлыке не в явном виде, всё равно SAP не рекомендуется сохранять его там (рис. 4).

Рис. 4. Пример содержимого ярлыка для соединения с SAP системой.

Функция описана в SAP note # 146173 - SAPShortcut: Saving password in SAPShortcut - not recommended.

В SAP note указано, что, начиная с SAP GUI 7.40 (SP 01) функция была удалена. И экран создания ярлыка в версии SAP GUI 7.50 выглядит без поля пароля вообще (рис. 5).

Рис. 5. Диалоговое окно для создания ярлыка в SAP GUI 7.50.

Но, ярлык, созданный в SAP GUI 7.30 с сохранённым паролем, работает и в SAP GUI 7.50. :)

Но опять же повторюсь, SAP не рекомендует использовать эту функцию.


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

Саповские секретики - V

Секретик 1.

При работе в клиентском месте SAP GUI можно открывать несколько режимов  (окон). Про это я писал в одном из выпусков саповских секретиков. Очень часто приходится открывать несколько режимов и при этом работать в нескольких системах SAP. Иногда, может потребоваться открывать сессии под разными пользователями. Чтобы не запутаться в большом количестве окон и, при переходе к окну сразу понимать что это за система/мандант/пользователь, необходимо развернуть информационную часть строки состояния, нажав соответствующий треугольничек в правом нижнем углу окна SAP GUI (рис. 1).

Рис. 1. Активация информационной части строки состояния SAP GUI.

Правый нижний угол строки состояния SAP GUI содержит много полезной информации. Прежде всего это SID системы, номер режима и номер манданта. Так же там отображается имя хоста (hostname), на котором работает сервер приложений SAP, обслуживающий текущую сессию (рис. 2).

Рис. 2. Полезная информация в строке состояния SAP GUI.

Но это еще не всё. Информации о текущем режиме больше и получить её можно, если вызвать всплывающий список, нажав на соответствующую кнопку после номера манданта (рис. 3).

Рис. 3. Полная информация о текущем режиме SAP GUI.

Как видно из снимка экрана, присутствует информация по текущему пользователю, запущенным программе и транзакции, а также временные задержки системы. Любую из этих строк можно сделать видимой в строке состояния постоянно, вместо SID системы и номера манданта, которые отображаются по умолчанию. Достаточно выбрать их в выпавшем списке. Например, имя пользователя, из под которого вы работаете в системе (рис. 4).

Рис. 4. Полезная информация в строке состояния SAP GUI: имя текущего пользователя.

Секретик 2.

Еще один полезный совет при работе с SAP GUI. Запуск соединения с SAP системой происходит через утилиту SAP Logon, которая содержит записи о соединениях с SAP системами. Но можно ускорить вход в ваши любимые системы и любимые транзакции. Для этого необходимо войти в необходимой мандант системы, запустить нужную транзакцию (не обязательно, можно указать позже) и нажать на панели кнопку "Создать ярлык" (рис. 5).

Рис. 5. Создание ярлыка для соединения.

В появившемся диалоговом окне заполнить поля и нажать "Готово" (рис. 6).

Рис. 6. Создания ярлыка для запуска соединения.

Здесь можно указать конкретную транзакцию, которую вы хотите сразу видеть на экране, мандант системы, пользователя из под которого вы будете работать, язык входа. В зависимости от того, что вы укажете в поле "Город" (явная ошибка перевода :)), ярлык будет создан или в окне SAP Logon в разделе "Ярлыки" (рис. 7) или, например, на рабочем столе Windows (рис. 8).

Рис. 7. Вновь созданный ярлык в SAP Logon.

Рис. 8. Вход в систему через ярлык.

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


Секретик 3.

В серии постов про работу с SAP notes (часть 1, часть 2, часть 3) я рассказал про то, что SAP notes, которые содержат коррекции программного кода, часто включают в те или иные пакеты поддержки. То есть, найдя SAP note можно узнать какой пакет поддержки её содержит. Но можно решить и обратную задачу: найти все SAP notes, которые содержатся в том или ином пакете поддержки. Для этого входите на SAP Support Portal в раздел "Software Downloads", находите нужный пакет поддержки и справа от него выбираете пункт "SAP Notes & Side Effects" (рис. 9).

Рис. 9. Дополнительная информация по пакету поддержки.

В открывшемся окне будет список всех SAP notes (разбитых по компонентам), которые включены в данный пакет поддержки (рис. 10).

Рис. 10. Список SAP notes, включенных в пакет поддержки.

Ну и можно найти, например, все SAP notes с изменениями, касательными расчета заработной платы в России (рис. 11).

Рис. 11. Список SAP notes, включенных в пакет поддержки. 

Либо, если вы знаете имя пакета поддержки, можно воспользоваться быстрой ссылкой вида:

https://launchpad.support.sap.com/#/supportpackage/<SP_name>

здесь <SP_name> - имя пакета поддержки.


Предыдущие выпуски:
- Саповские секретики - I,
- Саповские секретики - II,
- Саповские секретики - III,
- Саповские секретики - IV.


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

Почему SAP рекомендует 3-х системный ландшафт?

Вот вы говорите: "Ландшафт, ландшафт... " А что такое ландшафт?

Давайте остановимся на этом понятии поподробнее.

Итак, в посте "Копирование манданта SAP системы" я приводил структуру данных SAP системы (рис. 1).

Рис. 1. Структура данных в SAP системе.

В ABAP части SAP системы выделяют автономные единицы для работы и хранения данных предприятия. Данные единицы носят название - мандант. Мандант содержит основные данные (Master Data), записи пользователей с полномочиями и манданто-зависимые настройки. Манданты идентифицируется троичным номером и их в системе может быть несколько. Теоретически 1000 штук.

Помимо манданта, в системе есть общие для всех мандантов данные: манданто-независимые настройки и репозитарий SAP системы. Репозитарий это прежде всего ABAP-программы (reports, функциональные модули, экраны и т.п.). К репозитарию так же относится и ABAP-словарь, про который я писал в посте "Транзакция SE14 : утилита базы данных".

Ландшафт, как я уже упоминал ранее, это объединение нескольких систем одного назначения/версии для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. Например, SAP ERP 6.0 EHP7 (кстати, самая распространенная версия по опросам) или SAP SRM 7.0 EHP3.

Ландшафты SAP систем могут быть:

• односистемными,
• двухсистемными,
• трёхсистемными.

Рассмотрим первый вариант - ландшафт SAP системы, состоящий из одной системы. Допустим, в одном манданте системы разработчики и консультанты производят настройки и пишут/изменяют ABAP-программы. А второй мандант системы выделен для работы пользователей (рис. 2).

Рис. 2. Односистемный SAP ландшафт.

В плане разграничения доступа - всё хорошо. Пользователи в разных мандантах разные. И консультанты и разработчики не имеют доступ к основным данным предприятия (например, заработной плате), так как работают в отдельном манданте. Но представьте, что будет, если разработчик активирует новую версию программы при работающих с ней пользователях? Будет несколько дампов (равных количеству работающим с программой пользователей) и все результаты работы пользователей будут потеряны. Так как, еще раз повторюсь, репозитарий для нескольких мандантов одной системы только один, он общий (рис. 2). 

Я в своей практике встречался с таким ландшафтом. Это был пилотный проект в одном, отдельно взятом, подразделении крупного транспортного предприятия. В день, когда на проект приходил разработчик, пользователи в системе не работали. :) То есть получалась система с разграничением времени работы: либо пользователи, либо ABAP-программист.

Второй вариант: в ландшафте SAP системы уже 2 системы. Одна играет роль системы разработки и настройки, вторая для продуктивной работы пользователей. Системы объединены транспортной системой (рис. 3). 

Рис. 3. Двухсистемный SAP ландшафт.

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

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


Поэтому переходим к последнему варианту - трёхсистемный ландшафт. Три системы (DEV, QAS, PRD) работают в связке, объединенные, корректно настроенной, транспортной системой. Такая связка обеспечивает независимость разработки и настройки в первой системе, тестирование разработанного решения и переноса транспортного запроса во второй и безопасный перенос готового, оттестированного решения в систему промышленной эксплуатации (рис. 4).

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

В данном варианте разработчик создаёт новую версию объектов репозитария (программы, экраны, таблицы словаря, элементы данных и т.п.) в системе разработки (DEV). После этого, деблокировав транспортный запрос, содержащий необходимые объекты, переносит его в систему контроля качества (QAS). В тестовой системе производятся все виды тестирования: функциональное и нагрузочное на больших объёмах данных, решаются возникающие проблемы интеграции с другими разработками и модулями. Все доработки производятся в системе разработки (DEV) и переносятся новыми транспортными запросами в систему QAS. После того, как разработка подтверждается как завершённая, принимается решение о переносе её в продуктивную систему. И тогда производится перенос всей очереди сформированных запросов в рамках данной разработки. Запомните! Всей очереди, а не только последних запросов. Только так можно гарантировать, что во время переноса вы не получите что-то другое в системе промышленной эксплуатации. Все ваши запросы в систему QAS - это проверенная очередь, при переносе которой в новую систему вы ничего не потеряете и не забудете.

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

А чтобы было меньше дампов у пользователей при переносе, осуществлять его лучше во время минимальной активности в системе. Вечер пятницы вроде бы идеально подходит, но иногда чреват незапланированной работой в выходные. :) Поэтому лучше вечер четверга.

Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.

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

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

P.S. Всё что здесь описано, касается только AS ABAP, при разработке в AS JAVA требования к ландшафту несколько другие. Подробности можно найти в курсах SAP ADM325 и SAP ADM800.

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