SAP Software Provisioning Manager 1.0. Обновление.

Весной 2013 года в посте "SAP Software Provisioning Manager 1.0" я описывал довольно новый на тот момент инструмент с одноимённым названием (кратко SWPM 1.0). Он используется для установки SAP систем.

Время не стоит на месте. Практика создания отдельных дисков с программой установки конкретной SAP системы, о которой я вспоминал в прошлый раз, ушла в прошлое окончательно. Подробности можно найти в SAP ноте 1825724 - SAP Software Provisioning Manager has replaced the SAP Installation Master Media as of SAP Netweaver 7.0 SR3 or greater. Теперь утилита установки системы единая для всех систем и скачивается отдельно от установочных дисков SAP системы.

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

Первое, на чём я хотел бы остановиться, это интеграция инструмента установки системы с SUM. Об этом инструменте я писал тут. Интеграция позволяет до установки системы  через Maintenance Planner сгенерировать stack generation file, в котором сформировать целевой стек пакетов поддержки (SPS) для устанавливаемой системы. А после окончания установки, запустится утилита SUM и можно будет провести обновление системы до необходимого SPS. Эта возможность впервые появилась в версии SWPM 1.0 SP07, а в последующих обновлениях доводилась "до ума". Например, в версии SWPM 1.0 SP19 стало возможным добавлять сюда же языковые пакеты для импорта их сразу после установки системы.

Второй момент. Начиная с версии SWPM 1.0 SP17, появилась возможность программе установки вместо диска с SAP Kernel указывать отдельные архивы с ядром SAP системы с самым свежим уровнем пакетов поддержки. Причём иной раз, SWPM не принимает диск, а требует именно архивы (рис. 1). С версии SWPM 1.0 SP22 утилита автоматически проверяет корректность архивов с SAP Kernel (рис. 2).

Рис. 1. Экран утилиты SWPM, на котором задаётся путь до диска с SAP Kernel.

Рис. 2. Экран утилиты SWPM, на котором программа определяет отдельные архивы с частями SAP Kernel.

Еще один момент. В версии SWPM 1.0 SP21 утилиты для импорта информации в базу данных (например, R3load) были интегрированы прямо в архив с SWPM. И теперь, если есть проблемы с используемой версией, то нет необходимости их скачивать отдельно. Правда, это только при установке  систем, основанных на SAP NetWeaver 7.40 и новее.

Ну и самое главное нововведение, которое появилось с версии SWPM 1.0 SP20, это новый переработанный интерфейс программы установки. Теперь это не Java-приложение, которое запускается на сервере, где производится установка системы. А основанный на SAPUI5 графический интерфейс (SL Commin GUI), который представляет собой (барабанная дробь...) Web-приложение! :) К одному из постов с моими инструкциями был комментарий на эту тему.

Так вот, при запуске утилиты происходит запуск серверной части, в которой есть встроенный Web-сервер. А далее программа установки предлагает отрыть в Web-браузере URL для запуска вышеуказанного SL Common GUI (рис. 3).

Рис. 3. Запуск серверной части утилиты SWPM 1.0.

Для работы с утилитой подходят Web-браузеры (рекомендуется наиболее последние версии):

• Google Chrome (рекомендуется использовать именно его), 
• Mozilla Firefox, 
• Microsoft Edge, 
• Microsoft Internet Explorer 11 и выше.

Основной экран утилиты функционально похож на предыдущую оффлайн-версию (рис. 4).

Рис. 4. Начальный экран утилиты SWPM 1.0 с версии SP20.

Можно запускать, как локально с сервера, так и удаленно, с клиентской станции. Что может быть очень полезно, когда на сервере не установлено X-window окружение или канал связи между компьютером администратора и сервером не обладает достаточной шириной для передачи экранов через X-ы.

SAP рекомендует Web-браузер запускать в режиме "Инкогнито", чтобы плагины браузера не вмешивались в работу.

Основная SAP нота по SWPM 1.0 осталась прежней - 1680045 - Release Note for Software Provisioning Manager 1.0.

На данный момент текущая версия: SWPM 1.0 SP24. SAP, как всегда, рекомендует каждый раз использовать самую свежую версию.

Скачать её можно на странице - https://support.sap.com/en/tools/software-logistics-tools.html, где необходимо в разделе "System Provisioning" нажать соответствующую кнопку (рис. 5).

Рис. 5. Раздел на SAP Support Portal, где можно скачать SWPM.

Далее, как обычно, переходим в раздел "SOFTWARE PROVISIONING MGR 1.0", выбираем операционную систему и скачиваем нужный архив (рис. 6).

Рис. 6. Страница с архивами с SWPM 1.0.

Какой архив использовать для установки целевой системы описано в приложенном файле к вышеуказанной SAP ноте 1680045. Если кратко, то:

• SWPM*.SAR - для систем, основанных на SAP NetWeaver 7.1 и выше, включая SAP S/4HANA,
• 70SWPM*.SAR - для систем более старых - основанных на SAP NetWeaver 7.0, включая EHP 1-3.

В том же файле можно найти название ветки на начальном экране SWPM 1.0, где искать необходимую вам систему. 

С помощью данного инструмента можно не только установить систему, но и скопировать системы из одной в другую, переименовать SAP систему, разделить систему ABAP+Java на две отдельные инстанции, так как Dual-stack со стороны SAP больше не поддерживается. По каждой операции есть отдельная SAP нота, например, по гомогенному и гетерогенному копированию - 1738258 - System Copy for Systems Based on SAP NetWeaver - Using Software Provisioning Manager 1.0.

Основная программа утилиты так и осталась SAPinst. По последней версии есть отдельная SAP нота 2393060 - SAPinst Framework 749 Central Note. В ней описаны версии этой программы и исправления.

Так же есть еще одна версия SAP Software Provisioning Manager 2.0, которая используется пока только для установки системы SAP BW4/HANA. Подробности в SAP ноте 2568783 - Release Note for Software Provisioning Manager 2.0.


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

Сервера Fujitsu PRIMEQUEST для SAP HANA

1 ноября 2018 года российское представительство компании Fujitsu в лице Николая Гришина проводило небольшой вебинар на тему "Серверы Fujitsu PRIMEQUEST, и не только серверы, для приложений SAP".

Материал вебинара отлично дополняет мастер-класс по SAP HANA, на котором я был в октябре. Про него я делал 2 поста: 1 часть, 2 часть.

Компания более 40 лет разрабатывает аппаратную и программную инфраструктуру для приложений SAP. Имеет собственные компетенции и тесные контакты с SAP. Про их решения я уже писал.

На данный момент основной тренд производителей оборудования уровня Enterprise - это концентрация усилий на архитектуре x86. Все отходят от своих разработок, оптимизируют затраты, смещают фокус на другие направления. Например, компания Hewlett Packard Enterprise, которая "забросила" свои RISC-процессоры (PA-RISC, Itanium) и операционную систему HP-UX, сконцентрировавшись на серверах архитектуры x86.

Fujitsu в этом плане не исключение. Хотя они и производят, одни из немногих, мейнфреймы (серии M10/M12) на собственных процессорах RISC-архитектуры - SPARC64, но большой упор делают на сервера серии PRIMEQUEST. А это архитектура - x86 от Intel.

И мне кажется, что SAP со своей поддержкой, фактически, только архитектуры x86 в своих новых продуктах на SAP HANA, не последний фактор в этом общем тренде производителей.

Новые времена требуют новых решений. Fujitsu создаёт на базе x86 сервера с повышенной отказоустойчивостью, уровня Enterprise. Позиционирует их как более идеальное решение, по сравнению с обычными x86 серверами и серверами архитектуры RISC. Так как оно и дешевое, и надежное (рис. 1). :)

Рис. 1. Позиционирование серверов PRIMEQUEST.

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

Рис. 2. Слайд из презентации с дизайном серверов серии PRIMEQUEST.

"Горячую замену" и безостановочный ремонт поддерживают почти все компоненты: блоки питания, вентиляторы, PCI-карты и платы ввода-вывода. Но при выходе из строя системной платы или процессора сервер уйдёт в перезагрузку. Уменьшить грусть от этого факта поможет резервная системная плата, которую можно сконфигурировать. Она автоматически после старта сервера заменит, вышедшую из строя системную плату. Все процессоры и системные платы идентичны, то есть нет какого-то центрального модуля, выход из строя которого, "уронит" весь сервер. Flexible I/O switch позволяет отвязать модули ввода-вывода от процессоров, что так же повышает отказоустойчивость.

На данный момент компания Fujitsu в серии PRIMEQUEST предлагает 2 сервера:

• PQ 2800E3 - более старая модель, но позволяет получить конфигурацию до 8 процессоров Intel Xeon E7-8800 v4 (192 ядра) и 24 Тб оперативной памяти,
• PQ 3800E - последняя модель. Можно собрать сервер до 8 процессоров Intel Xeon Platinum (224 ядра) и 12 Тб оперативной памяти.

Сервера сертифицированы под решения SAP HANA, правда модель PQ 2800E3 максимально только в 8 Тб конфигурации (презентация, стр. 14).

Сервера можно разделять на физические партиции (PPAR) - до 4-х на один сервер. Организация партиций не несёт накладных расходов в плане производительности, как, например, виртуализация. Партиции на аппаратном уровне полностью независимы друг от друга: при выходе из строя одной, остальные продолжают работать.

8-ми процессорные сервера это максимально допустимые конфигурации, поддерживаемые со стороны Intel. Всё что выше этого требует отдельной разработки модулей сопряжения/интеграции со стороны производителя серверов. Так же при увеличении количества процессоров производительность растёт не линейно, так как увеличиваются задержки при синхронизации работы между процессорами.

HPE единственный производитель, кто смело берётся за разработку таких конфигураций и кто позволяет проводить открытое тестирование своих решений. В вебинаре представлен слайд с измеренной производительностью в SAPS (рис. 3). Сервера HPE SUPERDOME Flex в той же конфигурации, что и PQ 3800E имеют на 7% меньшую производительность. Это, как раз и есть плата за большую масштабируемость решения (до 30 Тб). Об этом я уже писал в посте про мастер-класс. 

Рис. 3. Сравнение производительности серверов в SAPS.

В вебинаре затронуты вопросы СХД. У Fujitsu есть 2 класса систем:

• гибридные (серия DX),
• all-flash (серия AF).

И те, и другие сертифицированы под SAP HANA. Которая, к слову, жестких требований к СХД не проявляет. Но при старте/останове базы данных скорость работы с СХД играет ключевую роль, так как обмен данными идёт колоссальный. Да и запись журналов SAP HANA никто не отменял.

Камень скептицизма был "в огород" и другого вендора оборудования - IBM. Специалисты Fujitsu сомневаются, что поддержка процессоров IBM Power решениями SAP HANA, это надолго. А, соответственно, недальновидно строить инфраструктуру на них. 

Последние требования по конфигурации оборудования со стороны SAP HANA (TDI Phase 5):

• позволяют проводить обычный sizing, считая в SAPS, 
• количество памяти не привязано к CPU,
• максимальное ограничение - 16 процессоров и 24 Тб оперативной памяти.

Автор вебинара не рекомендует использовать системы виртуализации при построении инфраструктуры для SAP HANA. Минусы:

• максимально рекомендуемый со стороны SAP объем оперативной памяти - 6 Тб на виртуальную машину,
• высокие накладные расходы (до 30%) с точки зрения производительности.

В конце вебинара приводится небольшой пример построения решения на базе оборудования Fujitsu из "реальной" жизни.

Презентация доступна по ссылке (1 Мб).

Видео-запись вебинара выложил тут (38 Мб). В начале видео есть проблемы со звуком, который начинается с отметки 1:40. 

Рекомендую потратить 40 минут своего времени и посмотреть запись, даже если вы в данный момент не работаете с оборудованием от Fujitsu.

HPE, конечно, впереди всех, но Fujitsu тоже молодцы: третье место по количеству установок SAP HANA (ссылка).

К тому же, Enterprise решения на базе архитектуры x86 от разных производителей имеют общие черты в проектировании и построении.


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

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. Всем спасибо за "подарки"! Очень приятно, когда делаешь то, что кому-то оказывается полезным. :)


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