SUSE Linux Enterprise Server как платформа для SAP системы. Обновление

Ровно 2 года назад я опубликовал пост "SUSE Linux Enterprise Server как платформа для SAP системы", в котором рассказал об одном из самых популярных дистрибутивов Linux для разворачивания SAP систем.

К двум веткам серверных дистрибутивов этим летом добавилась новая версия - SLES 15.
Таким образом, на данный момент поддерживаются 3 ветки версий SLES (рис. 1)

Рис. 1. Поддерживаемые версии SUSE Linux Enterprise Server.

Подробности по датам окончания поддержки можно найти по ссылке на официальном сайте или в SAP note # 936887 - End of maintenance for Linux distributions. SAP рекомендует устанавливать максимальный SP на операционную систему, а SUSE, в свою очередь, активно поддерживает только 2 последних SP.

Со стороны продуктов компании SAP SE версии операционной системы SLES 11 и 12 поддерживаются практически на равных. Для примера я взял несколько свежих версий систем SAP и прошёлся по PAM (рис. 2).

Рис. 2. Поддержка SLES в некоторых системах SAP.

Поддержка использования SLES 15 пока есть только для SAP HANA 2.0 (начиная с SP03 rev.34 и выше) (рис. 3).

Рис. 3. Поддержка SLES для SAP HANA 2.0.

Думаю, что поддержка  SLES 15 со стороны других продуктов компании SAP это только вопрос времени. По SAP HANA 2.0 и SLES 15 можно посмотреть SAP notes:

• 2235581 - SAP HANA: Supported Operating Systems.
• 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15.

Для тех, кто выбирает Linux, основной нотой была SAP note # 171356 - SAP Software on Linux: General information. Осенью 2016 года нота была закрыта (доступна только, как архив со старыми версиями), а за свежими данными надо обращаться к SAP note # 2369910 - SAP Software on Linux: General information.


Помните, я писал пост "SAP на Linux: на какой дистрибутив можно поставить систему?", в котором я спрашивал про некоммерческие дистрибутивы, на которые у вас был опыт установки SAP систем. По данному вопросу нашел SAP note # 815368 - SAP products: Compatible Linux versions, в которой SAP говорит следующее:

Для продуктивной эксплуатации настоятельно рекомендуется использовать дистрибутивы Linux Enterprise версий с купленной поддержкой со стороны производителей дистрибутивов или "железа". Но технически допускается замена Red Hat Enterprise Linux 7.x на CentOS 7.x или Fedora 20, Red Hat Enterprise Linux 6.x на CentOS 6.x или Fedora 13, а SUSE Linux Enterprise Server 12 на openSUSE 42.1 или 42.2. 

Со своей стороны, я знаю успешный опыт установки SAP системы на CentOS. А вот по этой ссылке для установки SAP NetWeaver 7.51 SP02 Development Edition рекомендуют использовать openSUSE 42.3, не отрицая возможности использования даже Ubuntu. Конечно, Development Edition это в какой-то мере ограниченный продукт, но всё же.


Ну и напоследок хочу сообщить, что я обновил свою инструкцию по разворачиванию SUSE Linux Enterprise Server 12 for SAP Applications в виртуальную машину VirtualBox и подготовки её к установке SAP системы. Версия дистрибутива используется самая последняя в этой ветке - SLES 12 SP3.
Инструкция доступна по этой ссылке (zip-архив, 2076 Кб).


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

Мастер-класс по архитектуре SAP HANA 2.0. День 2

В первой части статьи я рассказал про первый день мастер-класса по SAP HANA, который проводил Михаил Вронский во время осенней сессии от SAPLand.

Второй день проходил там же и почти в том же составе. Вторая часть мастер-класса носила более технический характер, то есть целевая аудитория: BASIS консультанты, архитекторы.

Материалы этого дня были опять же переработаны и дополнены. Много времени было уделено следующим вопросам:

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

Мои записи с этого дня.

Сервер для работы с SAP HANA должен быть сертифицирован для продуктивного использования.

Поставка оборудования может осуществляться по двум моделям (рис. 1):

• Appliance - полный набор оборудования (сервер, СХД, сеть) + OS для запуска SAP HANA. Часто и SAP HANA уже предустановлена. В начале был только этот способ. Минус: дорого и невозможность в будущем расширять или менять конфигурацию.
• TDI - компоненты подбираются по отдельности, но обязательно в соответствии со строгими требованиям. В результате решение получается дешевле и гибче. Сейчас разрешено даже изменять количество памяти (память изменяется с шагом 64 Гб).

Рис. 1. Две модели поставки оборудования для SAP HANA.

Количество внедрений SAP HANA на 2018 год по производителям оборудования можно посмотреть вот по этой ссылке. Например, по Appliance и TDI (рис. 2). HPE, конечно, тут всех обходит. У них есть самое крупное решение для SCALE-UP внедрений - SuperDome Flex. Позволяет собрать сервер с 30 Тб оперативной памяти!

Рис. 2. Статистика внедрений на 2018 год.

Факторы, позволяющие уменьшить объем базы данных при переходе на SAP HANA:
- удаление индексов,
- использование сжатия данных при поколоночном хранении, которое в этом случае выше, чем при построчном.

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

На практике максимальное уменьшение не более, чем в 2 раза.

При планировании перевода решения на базу данных SAP HANA для сайзинга можно использовать отчёт в SAP системе. Подробности в SAP notes:

• 1793345 - Sizing for SAP Suite on HANA,
• 1872170 - Business Suite on HANA and S/4HANA sizing report.

Варианты установки (рис. 3):
- SCALE-OUT - несколько серверов, объединенных в одну базу данных. Желательно избегать, если требования к памяти до 25 Тб. Минусы: снижение производительности из-за больших задержек между узлами и повышенные риски.
- SCALE-UP - одна база данных на одном сервере.

Можно делать преобразование SCALE-OUT в SCALE-UP и обратно, используя утилиту hdblcm.

Рис. 3. SCALE-UP и SCALE-OUT.

Скорость старта базы данных SAP HANA - 0,5 Тб/час. Использование энергонезависимой памяти, о которой я рассказывал в первой части поста, в будущем позволит сократить это время.

В качестве операционной системы рекомендуется SLES, так как разработка SAP NetWeaver и SAP HANA в SAPLabs ведется на ней. Она раньше проходит сертификацию. На ней больше внедрений.

Альтернатива: RedHat Linux.

Файловая система рекомендуется - XFS.

Для разворачивание кластерных решений в SAP HANA есть интерфейсы для сторонних производителей. В самом SAP SE используется бесплатное решение - SUSE Linux Enterprise High Availability Extension (SUSE HAE).

Backup/restore зависит от количества узлов. Если backup был сделан с 4 узлов, то его можно развернуть только на 4 узла.

Не все таблицы хранятся в поколоночном виде, в SAP ERP Rowstore часть порядка 1,5 тыс. таблиц или 150 Гб. Rowstore всегда хранится "In memory".

Все установки, начиная с SAP HANA 2.0 SPS01, только Multitenant, но можно устанавливать Singletenant system (SCOS).

Ограничений на установку SAP HANA + SAP NW на один сервер нет, а есть плюсы и минусы такого решения (рис. 4).

Рис. 4. Плюсы и минусы установки SAP HANA и SAP NW.

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

• SAP HANA Express edition (в виде установщика или образа виртуальной машины),
• SAP Solution Manager 7.2 on SAP HANA (при наличии активного договора поддержки с SAP).

В первом случае надо иметь 32 Гб оперативной памяти, во втором - 64 Гб.


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


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

Мастер-класс по архитектуре SAP HANA 2.0. День 1

Похоже, что посещение мастер-классов от портала SAPLand входит у меня в привычку. Год назад я был на мастер-классе по SAP HANA от Михаила Вронского, весной этого год побывал на Read ABAP от Олега Башкатова.

В эту осеннюю сессию я долго думал, к кому сходить. По администрированию мастер-классов очень мало. Решил снова сходить на "Архитектура решений на SAP HANA" от Михаила Вронского. Мастер-класс сделали 2-х дневным (помните, я писал, что на один день информации очень много) и Михаил обещал, что материал полностью переработан и обновлён. Я ему поверил и не разочаровался. Но обо всём по порядку.

Итак, мастер-класс стал 2-х дневным. День первый посвящён общим вопросам по SAP HANA:

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

Информация первого дня больше предназначена для консультантов любых модулей/решений и руководителей проектов. День был заполнен полностью. 

Материал этой части (по сравнению с прошлым годом) был расширен:

• больше рассказывалось про облачные технологии, 
• новшества и планы и по развитию платформы SAP HANA 2.0,
• новое решение SAP S/4HANA,
• лицензирование.

В конце было упражнение по расчёту стоимости владения решением на SAP HANA, с которым почти все справились. :)

Мои заметки по первому дню (пишу только отличия от прошлогоднего мастер-класса, тот материал в большинстве своём не утратил актуальности).

В концепции SAP Strategy: SAP HANA - это Digital Platform, которая является не только и не просто базой данных, а комплексом: база данных + сервер приложений (XS) + отдельные технологии. Сервер приложений имеет встроенные возможности для интеграции (рис. 1).

Рис. 1. Платформа SAP HANA.

Основной тренд со стороны SAP: отход от кросс-платформенности, поддержка только "своих" СУБД решений. А это - SAP HANA везде где можно, иначе SAP ASE for Business Suite или MaxDB. Это тренд на будущее и никак пока не касается текущих решений.

"In memory", как уже все поняли, больше маркетинговый слоган, так как любая база данных работает с данными только из оперативной памяти (решения "in memory" или просто кэш/буфер для данных). 

Инновационными моментами же являются:

- поколоночное хранение данных (нет индексов),

- распараллеливание обработки,

- сжатие данных.

При внедрении систем SAP ERP S/4HANA, BW4/HANA - SAP HANA используется только как база данных. 

SAP S/4HANA - развитие платформы SAP ERP. Технически это SAP NetWeaver + SAP HANA. Большее использование возможностей SAP HANA. Включение начальных функциональностей от BW и других SAP Business Suite приложений. Возможность использования простых сценариев этих решений прямо в ERP. Стоимость идентичная SAP ERP.

SAP Fiori UX - ABAP add-on на уровне SAP NetWeaver.

При уже внедрённом решении SAP ERP возможна установка базы данных SAP HANA в режиме SAP HANA Accelerator для выборки данных из любой базы данных ERP и построения отчётов (рис. 2).

Рис. 2. Пример применения SAP HANA Accelerator.

Еще один тренд: использование облачных вычислений. Например, для SAP SRM объявлена поддержка до 2025 года, а потом только облачное решение.

Перевод бизнес-фокуса в SAP SE в сторону облачных решений. Продажи стандартных решений (On Promise) последние 10 лет стоят на месте, а облачные (подписки и сервисы) растут.

В договоре при использовании облачных технологий от SAP указано, что данные принадлежат вендору (SAP). 

История из жизни: при введении санкций к компании "Силовые машины" за поставку турбин Siemens в Крым, SAP закрыл доступ компании к своему облаку, которым они пользовались.

Варианты развёртывания облачных решений:

• Public Cloud - использование оборудования (Amazon Web Services, Microsoft Azure и т.п.) для разворачивания своих серверов с SAP системами.
• SAP HEC (SAP HANA Enterprise Cloud) - оборудование, ОС, уровень серверов приложений - контроллируются вендором облачных технологий. Установка NW, резервное копирование - через заявки в SAP. Есть дата-центры в России.
• SAP Cloud Platform - платформа как сервис, можно делать свои Z-разработки.

По отзывам SAP BW4/HANA явных преимуществ (функциональных новшеств) перед решением SAP BW on HANA не имеет. При этом BW on HANA при покупке с существующей ERP идёт бесплатно, так как пользователи те же. А BW4/HANA лицензируется по размеру памяти, используемой базой данных, и оплачивается в любом случае.

Виды поставок SAP HANA:

• Express Edition - бесплатная версия SAP HANA (до 32 Гб памяти). Для разработчиков. Можно использовать как продуктивную для своих разработок. Будет запускаться на 16 ГБ, но работать нестабильно. Можно расширить до 128 Гб за отдельную доплату. Поддержка осуществляется не SAP, а SAP Community.
• Standartd Edition - можно покупать отдельные add-ons.
• Enterprise Edition - самая полная.

Active/Active Read-enabled можно докупать к обоим редакциям. Позволяет использовать 2 узла SAP HANA на чтение, когда запись ведется только на один. Должно поддерживаться на уровне решения, которое работает на SAP HANA.

Ошибка "Out of memory", если MaxUse, который SAP HANA постоянно отслеживает, становится больше, чем установленная лицензия. При этом, в начале даётся временная лицензия на 90 дней, по которой нет ограничений по памяти.

Основные используемые версии:

• SAP HANA 1.0 (выпущена в 2011 году) - использовать только последнюю версию SPS12 (от 06.2016), поддерживаться будет до 05.2021 года.
• SAP HANA 2.0 (выпущена в 2016 году) - выход SPS один раз в год (апрель). Поддержка 2 года, до появления SPS+2. Последний выпущенный пакет будет поддерживаться 5 лет.

Почти все продукты на данный момент перешли на SAP HANA 2.0. 

В SAP HANA 2.0 SPS03 заявлена поддержка энергонезависимой памяти (SAP HANA Persistent Memory), но оборудования пока нет. Планируются первые поставки в конце 2018 года с выходом нового поколения процессоров Intel.

Для администрирования и разработки используется 2 инструмента:

• SAP HANA Studio - тренд на сворачивание разработки и поддержки.
• SAP HANA Cockpit (фактически отдельная установка SAP HANA Express Edition + доп. софт). Версия всегда выравнивается по версии (SPS) SAP HANA 2.0 (рис. 3). Рекомендуется установку делать на основные сервера SAP HANA, так как они в отказоустойчивом кластере.

Рис. 3. Стратегия выхода SAP HANA Cockpit.

Версии SAP S4/HANA выпускаются ежегодно (версия - год+месяц, например, 1709, 1809).

Версии SAP S4/HANA Cloud выпускаются ежеквартально так, чтобы не путать с версиями SAP S/4HANA.

По стоимости на данный момент - SAP HANA дешевле, чем Oracle (при лицензировании через SAP SE), но дороже остальных поддерживаемых SAP баз данных. При этом по состоянию на 2014-2015 год - 70 % установок SAP систем выполнены на Oracle.

Основной риск перехода на SAP HANA - операции записи, которые могут замедлить бизнес-процессы (транзакции). Например, при реальном внедрении SAP HANA скорость где-то вырастает в 4,8 раза (чтение), а где-то наблюдается снижение скорости на 40 % (запись).

Поэтому рекомендации остались старые: SAP BW - однозначно на HANA, а ERP решения - только в случае нового решения (SAP S4/HANA). Смена базы данных на текущем решении  на SAP HANA надо просчитывать.

Лицензирование:

• Runtime - % от стоимости основного решения (по этой схеме производится лицензирование решений SAP SE на базе SAP NW). Не позволяет делать интеграцию SAP HANA вовне, работа с базой данных только через NW.
• Full Use - по ГБ памяти, используемой SAP HANA. Для сторонних приложений, своих разработок на SAP HANA.

BW/4 HANA лицензируется по Full Use. Если один tenant базы данных лицензируется по Full Use, то всю базу данных надо лицензировать по Full Use.

Продолжение тут.

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

Многотомный самораспаковывающийся RAR-архив от SAP

Я настолько стар, что помню времена, когда компания SAP присылала заказчику большую красивую коробку с компакт-дисками (сначала это были CD-ROM, потом DVD), с которых можно было установить все купленные системы. Сейчас, вполне возможно, диски тоже можно заказать. Но, с развитием скоростей сети Интернет и уходом DVD-приводов в прошлое, они мало кому нужны.

Достаточно установить SAP Download Manager, указать в настройках S-user своего договора и можно смело закачивать дистрибутивы, которые входят в договор, сколько угодно раз.

Образы установочных дисков, которые раньше тоже были размером с CD-ROM, теперь ограничены размером 4 Гб. Большинство образов идёт в виде ZIP-архивов. Данный формат я считаю универсальным форматом для распространяемых по сети архивов. К тому же, современные версии Windows (начиная с Windows XP) умеют работать с этим форматом "из коробки".
Но особо большие образы, а сюда относятся файлы экспорта базы данных, исполняемые файлы СУБД Oracle, часто идут в "многотомных самораспаковывающихся RAR архивах". И если в Windows открыть такой архив не проблема - двойной клик левой клавиши мыши на первый файл с расширением exe и можно идти пить кофе. Распаковка выполнится без стороннего ПО и займёт немного времени. :) То в Unix системах не всё так просто.

Меня удивляет еще такой момент. Даже образы дистрибутива СУБД Oracle для Linux идут в таком же "многотомном самораспаковывающемся RAR архиве"! Почему!? Как?! Зачем?! :)

Часть вопросов я опущу и спишу на "так сложилось исторически" или "так им там удобнее", а попробую ответить на один вопрос - "Как?".

В Unix системах для распаковки таких архивов надо установить unrar (freeware). Где-то он обычно уже есть. Например, в Suse Linux его можно установить соответствующей командой (рис. 1).

Рис. 1. Установка пакета unrar в Suse Linux.

После этого для распаковки нашего "многотомного самораспаковывающегося RAR архива" достаточно дать команду вида: unrar x и указать имя первого файла с расширением exe (рис. 2).

Рис. 2. Распаковка много-томного RAR архива в Linux.

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

Стоит еще добавить, что файлы распакуются в текущую директорию.

Подробности можно найти в SAP note 886535 - Downloading multispanning archives (RAR archive).


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

10 лет

Сегодня осознал, что блогу-то уже 10 лет.

Так что поздравления и пожелания принимаются в виде комментариев к этому посту.
Подарки можно высылать на Yandex.кошелёк - 410015988352987. :)

Спасибо всем, кто читает, комментирует и остаётся со мной.

P.S. Всем спасибо за "подарки"! Очень приятно, когда делаешь то, что кому-то оказывается полезным. :)


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