xsa что это sap
SAP сейчас активно развивает Cloud Foundry (CF) и внедрила ее в SAP Cloud Platform, в качестве основного элемента облачной инфраструктуры. CF выполняет роль PaaS и позволяет запускать приложения в среде SCP. В этой статье мы расскажем каким образом подготовить CF к выходу вашего проекта в продуктив (фаза «Go Live»), а также, как разворачивать приложения в среде Cloud Foundry SCP и HANA XSA. Мы рассмотрим примеры и расскажем, как разумно управлять вычислительными серверными ресурсами, обеспечивая контролируемую среду для работы приложений.
Разработчик может использовать практически любой IDE и язык программирования, включая языки Python, Java, JavaScript, Go. CF создает изолированную среду исполнения (runtime environment) приложений и таким образом управляет отказоустойчивостью и доступностью приложений. SAP активно развивает проект CF в составе HANA Platform, который получил название HANA XSA (XS Advanced Runtime). Разработчик может легко мигрировать приложения из среды HANA XSA в среду CF в SAP SCP.
Концепция разработки приложений для SAP SCP реализована в Cloud Application Programming Model (CAP) и доступна на сайте. Приложения на базе SAP CAP легко можно перенести в среду CF.
CAP позволяет выполнять разработку приложений на локальном месте разработчика, включая пользовательский интерфейс и back-end сервисы на языках Java и JavaScript, используя БД SqlLite. Миграция готовых приложений в облако SAP SCP и HANA Cloud не требует дополнительных затрат, так как для работы с объектами в БД используется механизм CDS (Core Data Services), который позволяет абстрагироваться от конкретной СУБД.
В первую очередь следует определить среду исполнения для приложения, которая реализована в виде пакета buildpack, проверить версию компилятора, необходимых системных библиотек, а также установить переменные среды окружения. Мы не будем останавливаться на анатомии CF/XSA, но если вам интересно, то предлагаем ознакомиться с материалами по ссылке.
На опыте реализованных проектов мы создавали собственные buildpack пакеты и разрабатывали свой процесс установки и запуска приложений.
Пакет buildpack содержит необходимую логику для проверки условий компиляции и выполнения приложения, позволяет зафиксировать версию используемого компилятора и системных библиотек, необходимых для работы приложения. В рамках HANA XSA сервера приложений поставляется ряд готовых buildpack’ов, которые поддерживаются SAP, а именно: nodejs (javascript), java. Кроме этого, используются пакеты из среды CF, которые также могут работать в среде HANA XSA, а именно: php, go, dotnet_core, ruby.
Зачем создавать собственный buildpack?
· Требуется специфическая версия компилятора или среды исполнения,
· Требуется наличие определенных модулей, которые не доступны в стандартном buildpack,
· Требуется установка специальных системных библиотек, которые совместимы только с конкретной средой исполнения или компилятором определенной версии.
В любом случае для разработчика главное знать, что HANA XSA не ограничивает его в выборе компилятора и среды исполнения приложений и это важно, так как дает возможность переносить уже созданный и отлаженный код в HANA XSA без изменений.
Весь механизм установки приложений и запуска реализован в процессах execution agent и controller, которые работают на сервере XSA и управляются с рабочего места разработчика, используя инструмент cli из командной строки. Мы не будем останавливаться на деталях реализации архитектуры XSA/CF, все доступно в официальной документации на портале help.sap.com (SAP HANA Developer Guide for XS Advanced Model), вместо этого мы рассмотрим практические примеры.
Процесс разработки собственного buildpack описан в документации, и чтобы его собрать, нужно создать скрипты, реализованные на языке shell script в среде Linux, либо на языке go.
3. Подготовить необходимые скрипты на языке shell script, а именно: compile, detect, release.
4. Создать архив в формате zip (только формат zip), в который поместить архив, созданный на этапе 2, а также скрипты, созданные на этапе 3.
5. Установить созданный buildpack с помощью команды xs create-buildpack (подробное описание команды указано в документации на сайте help.sap.com->SAP HANA Developer Guide for XS Advanced Model в разделе Create a PHP Buildpack for XS Advanced)
Разрабатывая кастомизированный buildpack, важно понимать логику его работы, которая хорошо изложена в документации Cloud Foundry по ссылке. В данной статье основной упор делается на HANA XSA, где существуют незначительные отличия от среды CF, их мы рассмотрим на следующем примере.
· Сompile скрипт в среде HANA XSA выполняет задачу сборки (build) приложения из исходных кодов и также выполняет проверку условий компиляции приложения, например наличие файла appsettings.json, требуемого framework, assembly и т.д.
Важно отметить, что скрипт compile не используется в среде CF и был заменен на скрипты supply и finalize, однако для среды HANA XSA требуется использовать compile.
·Detect скрипт в среде HANA XSA выполняет задачу проверки совместимости конкретного buildpack для исполнения кода приложения.
· Release скрипт в HANA XSA выполняет задачу подготовки к запуску приложения, генерирует файл в формате yaml, в котором указывается команда для запуска приложения.
· Release скрипт в HANA XSA выполняет задачу подготовки к запуску приложения, генерирует файл в формате yaml, в котором указывается команда для запуска приложения.
В итоге получается следующая структура директории, на базе которой создается архив zip, который, по сути, и является buildpack.
Установка базы данных SAP HANA в Яндекс Облаке. Пошаговое руководство
Продолжаем эксперименты по установке различных SAP систем в Яндекс Облаке.
В первой части (статья была опубликована в блоге Яндекс Облака) был рассмотрена установка платформы SAP Netweaver ABAP AS, которая является основой для большинства SAP систем. В этой публикации мы перейдем от сервера приложений к уровню базы данных.
Изначально SAP Netweaver работал на широком спектре баз данных, среди которых были как принадлежащие компании SAP (SAP MaxDB, SAP ASE) так и базы данных от сторонних производителей (DB2, Oracle и MS SQL Server). Ситуация кардинально начала меняться в 2015 году с выходом SAP HANA (High-performance Analytic Appliance). Эта база данных позиционировалась компанией SAP как революционный для рынка продукт:
Остальные SAP ABAP и JAVA системы, например, шина данных SAP Process Orсhestration теперь могут использовать SAP HANA, как одну из доступных для установки баз данных, наряду с Oracle, DB2 и другими.
Поскольку SAP HANA является мультиконтейнерной базой данных, типичный корпоративный SAP — ландшафт выглядит следующим образом:
в этом скриношоте каждый тенант – это изолированная база данных какой-либо SAP системы (SAP Process Orсhestration, SAP EWM, SAP ATTP, SAP S/4HANA и т.д) внутри одной инсталляции SAP HANA.
Со временем у SAP появились также и коммерческие продукты которые представляют собой связку веб-приложение + база данных SAP HANA.
Например, SAP Medical Research Insights. Данная система должна помочь врачам выработать правильный план лечения, опирающийся на огромный массив данных, в том числе и о генетических исследованиях.
Еще один важный момент это наличие в архитектуре SAP HANA встроенного веб сервера (SAP HANA Extended Application Service). Данный сервер имеет привилегированный доступ к базе данных и позволяет выполнять приложения на Java, Python, Node.js и множестве других языков программирования. В версии сервиса Advanced Model (XSA) в ландшафте SAP HANA появляется такой функционал, как интегрированная среда разработки с веб-интерфейсом (SAP WEB IDE), Codereview (Gerrit) планировщик зданий (SAP XS JOB SCHEDULER) и многое другое.
Архитектура SAP HANA XSA:
Появление и постоянное развитие SAP HANA требует новых знаний у администраторов и разработчиков приложений. Возможность установить и экспериментировать со своей собственной базой и средой разработки в облаке представляется в этом случае далеко не лишней.
Однако SAP HANA будет интересна не только в Enterprise-среде, и не только среди разработчиков SAP. Благодаря гибкой лицензионной политики этот продукт можно бесплатно установить и использовать, в том числе и в коммерческих целях (размер в этом случае ограничен 32 GB) Возможно приведённый ниже пример установки и использования даст идею о том какое место может занять база данных SAP HANA и SAP HANA Extended Application Service в Вашем проекте.
Шаг 1. Скачиваем установочные файлы SAP HANA
Заходим на страницу загрузки SAP HANA, express edition и если у Вас нет учетной записи в SAP необходимо пройти простую регистрацию
Скачиваем и запускаем SAP HANA Express Edition Download Manager
В Download Manager укажем следующие варианты загрузки
Платформа – Linux/x86 – 64
Image – Binary Installer
Package – Applications*
* — Под Applications подразумевается база данных SAP HANA, сервер приложений и среда разработки SAP HANA Extended Application Services, Advanced Model (XSA)
Шаг 2. Создаём виртуальную машину в Яндекс Облаке
На этом шаге нам понадобится следующий бесплатный софт:
Регистрируемся / заходим в Яндекс Облако (https://cloud.yandex.ru/). Переходим в раздел Compute Cloud и приступаем к созданию виртуальной машины.
Имя виртуальной машины: saphana2
Зададим подходящие характеристики ВМ. В руководстве по установке для SAP HANA Express Edition (Server + Application) видим следующие рекомендуемые параметры:
Зададим их при создании нашей виртуальной машины.
vCPU — 2,
RAM – 32GB,
15 GB + 150 GB, где
15 GB (загрузочный диск — SSD)
150 GB (данные — * HDD)
* — т.к. SAP HANA все операции проводит в оперативной памяти в качестве носителя для снепшота данных мы можем выбрать более медленный HDD
В качестве операционной системы выберем последнюю стабильную ОС OpenSUSE, на момент написания статьи – это версия ОС OpenSUSE 42.3
Укажем Логин и Public SSH-ключ, сгенерированный с помощью PuTTYgen
Шаг 3. Подготавливаем виртуальную машину к установке SAP HANA XSA
Находим в настройках Публичный IPv4 адрес:
Подключаемся к созданной ВМ с помощью Putty-клиента, указав в подключении публичный IPv4, заданный логин и путь к Private – ключу
Подготовим файловую структуру к установке.
lsblk
vda – boot диск, vdb –диск, созданный под данные.
SAP рекомендует следующую файловую структуру:
/usr/sap + /usr/sap/distr – 35 GB
/hana/shared/data — 60 GB
/hana/shared/log — 10 GB
/hana/shared –40 GB
Реализуем такую структуру с помощью утилиты fdisk:
Проверим ещё раз структуру и создадим файловую систему ext4 на всех созданных разделах:
Создадим директории под дистрибутивы и базу данных SAP HANA, а также примонтируем к ним созданные на предыдущем шаге разделы. Также обновим файл /etc/fstab, чтобы монтирование восстанавливалось при перезагрузке:
Установим разрешение на папку с установочными файлами SAP:
Импортируем в WinSCP настройки из Putty. Подключимся к ВМ и загрузим в /usr/sap/distr архивы SAP HANA Server (hxe.tgz), SAP HANA Extended Application Services –XSA (hxeesa.tgz) и shine.tgz (Учебный контент)
Установим требуемые для работы библиотеки libstdc++, libnuma1, libatomic и libgcc_s1:
Шаг 4. Устанавливаем SAP HANA XS
Первое с чего стоит начать установку – это определением понятия SID
SID (SAP System Identificator) — представляет собой комбинацию трех символов и должен быть уникальным в рамках ландшафта. В рамках установки SAP HANA Express Edition значение SID по-умолчанию HXE. Предполагается, что мы не будем выбирать в качестве SID что-то другое.
Запускаем скрипт инсталляции с правами root – пользователя:
В меню установки требуется несколько раз нажать Enter.
Таким образом мы установим предложенные значения по умолчанию:
Дистрибутивы лежат в /distr/HANA_EXPRESS_20
SID – HXE
Номер инстанции – 90
Установка всех компонентов – all*
* — В данном случае это значит, что мы установим набор библиотек Application Function Library (AFL), куда входят Predictive Analysis Library (PAL), Business Function Library (BFL), Optimization Function Library (OFL).
Плагин SAP HANA EPM–MDS предназначен для получения данных из различных OLAP источников, а подсистема расширенных сервисов (Extended Services, XS) — это встроенный веб-сервер и набор различных компонентов, имеющих привилегированный доступ к базе данных.
Указываем мастер-пароль для пользователей, которые создаются во время инсталляции SAP HANA.
Поскольку мы выбрали SID – HXE, adm – пользователь на уровне операционной системы будет hxeadm. Указанный мастер-пароль также применится и к пользователю SYSTEM на уровне базы данных.
В процессе установки XSA потребуется также задать мастер-пароль от пользователей XSA_ADMIN, XSA_DEV, TEL_ADMIN
База SAP HANA Express Edition установлена.
Шаг 5. Проверка работы SAP HANA XSA
Проверим что база данных SAP HANA установлена и работает:
Пример сервисов, которые будут запущены:
Пройдём авторизацию в SAP HANA Extended Application Services, Advanced Model:
Пользователь: XSA_ADMIN
Пароль: Мастер-пароль, который мы задали при установке
Проверим версию SAP HANA Extended Application Services, Advanced Model:
Шаг 6. Пост-инсталляционные действия
Для того чтобы использовать веб-инструменты разработки и администрирования SAP HANA XSA необходимо отредактировать файл hosts на локальной Windows-мшине.
1. Открываем блокнот от имени Администратора
2. Открываем в блокноте файл C:\Windows\System32\drivers\etc\hosts
3. Вносим строку вида:
Шаг 7. Начало работы
Существует несколько способов администрирования и разработки для SAP HANA XSA
Администрирование: SAP HANA Cockpit. В настоящее время SAP позиционирует его, как основной инструмент управления базой данных. Также возможно управление базой данных из Eclipse (Перспектива – SAP HANA Administration Console)
Разработка: Через веб-интерфейс, через инструмент SAP Web IDE или через Eclipse (Перспектива – SAP HANA Development)
Поскольку HANA Cockpit и WebIDE были установлены во время процесса инсталляции именно их как средства управления и администрирования мы и будем рассматривать.
Получим url для интересующих нас приложений xsa-cockpit, webide и cockpit-web-app:
Скопируем https – адрес и откроем его в браузере для каждого из этих приложений.
XSA Cockpit
XSA Cockpit — это браузерная система управления сервером приложений SAP HANA Extended Application Services, Advanced Model.
XSA Cockpit позволяет управлять пользователями и ролями, организациями и пространствами.
В разделе User Management можно проверить, и при необходимости назначить, для пользователя XSA_DEV роли DEVX_ADMINISTRATOR, DEVX_DEVELOPER.
В разделе Tenant Databases можно расширить возможности XSA на новый тенант, в нашем случае – HXE и связать с ним пространство разработки development
HANA Cockpit
HANA Cockpit — это система управления базой данных SAP HANA.
Cockpit можно использовать для управления пользователями и ролями на уровне базы данных, для создания бекапов, мониторинга работы, диагностирования проблем с производительностью на уровне базы и множества других административных задач.
Скрипт регистрации ресурсов базы данных в HANA Cockpit выполняется при установке, если скрипт по каким-либо причинам не выполнился – его необходимо запустить вручную до первого использования Cockpit-ом.
WebIDE
WebIDE –это интегрированная с GitHub-ом браузерная среда разработки.
В разделе Development можно разрабатывать, тестировать и публиковать модули на NodeJS, Java, HTML5.
В разделе Database Explorer можно создавать и управлять объектами на уровне базы данных (таблицы, представления, хранимые процедуры и т.д).
Подключение к тенанту и обзор объектов в нём:
Шаг 8. Первое Node.js приложение
Откроем WebIDE и создадим простое UI5/Node.js приложение “Hello World!”
Для этого выберем
Workspace – Git – Clone Repository
В качестве репозитория укажем — Repository – github.com/basisteam-io/SAPHANAXS_helloworld.git
Таким образом мы получим копию простого приложения Hello world!, разобраться или модифицировать которое не составит никакого труда.
Установим пространство где будет развернуто данное приложение.
В нашем случае это пространство – development.
Последовательно сделаем Вuild приложения и проекта.
Вернёмся к командной строке и переключимся на пространство development:
Выведем список всех запущенных приложений в этом пространстве:
Отроем наше приложение в браузере:
Заключение
Установить базу данных SAP HANA с сервером приложений HANA Extended Application Services, Advanced Model и написать своё первое приложение оказалось не сложно. В следующей статье рассмотрим более сложный пример, включающий в себя взаимодействие с базой данных SAP HANA.
Роман Горбенко, консультант SAP EWM / SAP BASIS
Как развернуть SAP HANA: разбираем разные методы
SAP HANA — популярная in-memory СУБД, включающая сервисы хранилищ (Data Warehouse) и аналитики, встроенное промежуточное ПО, сервер приложений, платформу для настройки или разработки новых утилит. За счет устранения задержек традиционных СУБД с SAP HANA можно сильно увеличить производительность систем, обработку транзакции (OLTP) и бизнес-аналитику (OLAP).
Развернуть SAP HANA можно в режимах Appliance и TDI (если говорить о продуктивных средах). Для каждого варианта у производителя есть свои требования. В этом посте мы расскажем о преимуществах и недостатках разных вариантов, а также для наглядности — о наших реальных проектах с SAP HANA.
SAP HANA состоит из 3 основных компонентов – хоста, инстанса и системы.
Хост — это сервер или операционная среда для работы СУБД SAP HANA. Его обязательные компоненты — CPU, ОЗУ, СХД, сеть и ОС. Хост предоставляет ссылки на директории инсталляции, данных, логов или непосредственно на СХД. При этом СХД для инсталляции SAP HANA не обязательно должна располагаться на хосте. Если у системы несколько хостов – потребуется либо общее хранилище, либо такое, что доступно по требованию со всех хостов.
Инстанс — набор системных компонентов SAP HANA, установленных на одном хосте. Основные компоненты — это Index Server и Name Server. Первый, который называется также «рабочим сервером», обрабатывает запросы, управляет актуальными хранилищами данных и ядрами БД. Name Server хранит информацию о топологии инсталляции SAP HANA — о том, где работают компоненты и какие данные находятся на сервере.
Система – это один или несколько инстансов с одинаковым номером. По сути это отдельный элемент, который можно включить, отключить или скопировать (сделать резервную копию). Данные распространяются в памяти различных серверов, которые составляют систему SAP HANA.
Система может быть сконфигурирована как однохостовая (один инстанс на одном хосте) или мультихостовая, распределенная (несколько инстансов SAP HANA распределены по нескольким хостам, на каждый хост приходится по одному инстансу). В мультихостовых системах каждый инстанс должен иметь один и тот же номер. Система SAP HANA идентифицируется с помощью System ID (SID) – уникального номера, состоящего из трех буквенно-цифровых символов.
Виртуализация SAP HANA
Одним из главных ограничений SAP HANA является поддержка только одной системы — одного инстанса с уникальным SID сервера. Для более эффективного использования аппаратного обеспечения или уменьшения количества серверов в ЦОД можно использовать виртуализацию. Таким образом другие ландшафты могут сосуществовать на одном сервере с системами, имеющими меньшие требования (непродуктивные системы). Для резервного HA/DR-сервера виртуализация может повысить скорость переключения между продуктивными и непродуктивными виртуальными машинами.
SAP HANA включает поддержку гипервизора VMWare ESX. Это означает, что разные системы SAP HANA – инсталляции SAP HANA с различными номерами SID – могут сосуществовать на едином хосте (общем физическом сервере) в разных виртуальных машинах. Каждая виртуальная машина должна работать в поддерживаемой ОС.
Для продуктивных сред виртуализация SAP HANA имеет серьезные ограничения:
Топологии SAP HANA
Перейдем к развертыванию SAP HANA. Здесь определены две топологии.
Требования SAP к железу
К аппаратному обеспечению для HANA у SAP есть обязательные требования. Они касаются продуктивных сред — для non-prod достаточно минимальных характеристик. Итак, вот требования для продуктивных сред:
Развертываем SAP HANA в режимах Appliance и TDI
Теперь перейдем к практике и расскажем о том, как реализовать SAP HANA в режимах Appliance и TDI. Используем для этого наши платформы SAP HANA на основе серверов BullSequana S и Bullion S, которые сертифицированы SAP для работы в этих режимах.
Небольшая справка о продуктах. BullSequana S на базе Intel Xeon Scalable включает в себя различные модели, до 32 CPU в одном сервере. Сервер построен по модульной конструкции, обеспечивающей масштабируемость до 32 CPU и такого же количества графических процессоров. Оперативная память – от 64 ГБ до 48 ТБ. Среди особенностей BullSequana S – поддержка корпоративного ИИ для улучшенной производительности, ускорение аналитики данных, усовершенствование вычислений в памяти, модернизация с помощью виртуализации и облачных технологий.
Bullion S поставляются с CPU семейства Intel Xeon E7 v4 Family. Максимальное количество процессоров — 16. ОЗУ масштабируется со 128 ГБ до 24 ТБ. Большое количество функций RAS обеспечивает высокий уровень доступности для критически важных инфраструктур наподобие SAP HANA. Bullion S подходят для массовой консолидации ЦОД, работы с приложениями In-Memory, миграции мейнфреймов или устаревших систем.
SAP HANA Appliance
Appliance – преднастроенное решение, включающее сервер, СХД и пакет ПО для внедрения «под ключ», с централизованной службой поддержки и оговоренным уровнем производительности. Здесь HANA поставляется в виде предварительно настроенного аппаратного и программного обеспечения, полностью интегрированного и сертифицированного. Устройство в режиме Appliance готово к установке в ЦОД, а операционная система, SAP HANA и (если необходим) дополнительный инстанс VMWare уже сконфигурированы и установлены.
Сертификация SAP определяет гарантированный уровень производительности, а также модель CPU, объем RAM и СХД. После сертификации изменить конфигурацию без потери гарантии нельзя. Для масштабирования платформы HANA SAP предлагает три варианта.
Решения BullSequana S для SAP HANA в режиме Appliance
*Optional E7-8890/94v4
Решения Bullion S для SAP HANA в режиме Appliance
Все решения Bull в режиме Appliance с версии SAP HANA SPS 12 сертифицированы. Оборудование устанавливается в стандартную 19-дюймовую стойку 42U, с двумя источниками питания — внутренними PDU. Сертификацию SAP имеют серверы:
Вот пример конфигурации СХД EMC Unity 450F в нашем сетапе:
SAP HANA TDI
Альтернативой Appliance является режим TDI (Tailored Data center Integration), в котором можно выбирать конкретных производителей и компоненты инфраструктуры в зависимости от пожеланий заказчика – с учетом выполняемых задач и рабочей нагрузки. Например, SAN может быть повторно использован в ЦОД, при этом некоторые диски отводятся под установку HANA.
По сравнению с Appliance, в режиме TDI пользователю дается гораздо большая свобода в выполнении требований. Это значительно упрощает интеграцию HANA в ЦОД — можно выстроить собственную кастомизированную инфраструктуру. Например, варьировать тип и количество процессоров в зависимости от нагрузки.
Для расчета мощностей рекомендуется использовать SAP Quick Sizer — простой инструмент, выдающий требования к ЦП и памяти для разных рабочих нагрузок в SAP HANA. Затем для планирования IT-ландшафта можно обратиться в SAP Active Global Support. После этого аппаратный партнер SAP HANA преобразует результаты расчетов в разные возможные конфигурации системы — как на топовом, так и на более простом железе. В режиме TDI для серверов допустимо использовать CPU Intel E7, включая Intel Broadwell E7 и Skylake-SP (Platinum, Gold, Silver с 8 и более ядрами на процессор), а также IBM Power8/9.
Серверы поставляются без СХД, коммутаторов и стоек, но требования к аппаратной части остаются такими же, как в режиме Appliance — те же сингл-ноды, решения с вертикальным или горизонтальным масштабированием. SAP требует, чтобы использовались только сертифицированные серверы, СХД и коммутаторы, но это не страшно — у большинства производителей практически все оборудование сертифицировано.
Проверка производительности должна проводиться при помощи тестов HWCCT (Hardware Configuration Check Tool), которые позволяют проверить соблюдение определенных KPI SAP. И есть требование, не связанное с железом: HANA, ОС и гипервизор (опционально) должны быть инсталлированы специалистами с сертификацией SAP. Только системы, где соблюдаются все перечисленные правила, могут получать поддержку SAP, связанную с производительностью.
Линейка серверов BullSequana S в режиме TDI аналогична линейке в режиме Appliance, но без СХД, коммутаторов и стойки. К ним можно устанавливать любые СХД из списка сертифицированных SAP — VNX, XtremIO, NetApp и другие. Например, если VNX5400 соответствует требованиям к производительности SAP HANA, можно подключить СХД Dell EMC Unity 450F как часть конфигурации TDI. При необходимости инсталлируются адаптеры FC (1 или 10 Гбит/с), а также Ethernet-свитчи.
Теперь, чтобы вы наглядней представили описанные режимы, мы расскажем о нескольких наших реальных кейсах.
Appliance + TDI: HANA для интернет-магазина
Интернет-магазин Mall.cz, входящий в состав Mall Group, был основан 2000 году. Имеет филиалы в Чехии, Словакии, Польше, Венгрии, Словении, Хорватии и Румынии. Это крупнейший интернет-магазин в стране, продающий до 75 тысяч товаров в день, его выручка по итогам 2017 года составила порядка 280 миллионов евро.
Обновление инфраструктуры ЦОД требовалось в связи с миграцией на SAP HANA. Оцениваемый сайзинг составлял 2×6 ТБ для среды prod и 6 ТБ для сред test/dev. При этом требовалось решение с аварийным восстановлением для продуктивной среды SAP HANA в active-active кластере.
На момент объявления тендера у заказчика имелась система под SAP на базе стандартных стоечных и блейд-серверов. Два ЦОДа, располагавшиеся на расстоянии примерно в 10 км друг от друга, были укомплектованы различными СХД – IBM SVC, HP и Dell. Ключевые системы работали в режиме аварийного восстановления.
Сначала заказчик запросил сертифицированное решение в режиме Appliance для SAP HANA для всех систем (среды Production и test/dev) с ростом до 12 ТБ. Но из-за ограничений бюджета стали рассматривать другие варианты – например, большее количество CPU с модулями ОЗУ меньшего объема (модули по 64 ГБ вместо модулей по 128 ГБ). Кроме того, для оптимизации цены рассматривалось совместное СХД для сред Production и test/dev.
Сошлись на 4 CPU и 6 ТБ RAM для среды Production, с возможностью роста. Для сред test/dev в режиме TDI решили обойтись менее дорогостоящими CPU — получилось 8 CPU и 6 ТБ RAM. Из-за большего количества функций, запрашиваемого заказчиком, — репликация, бэкап, совместные среды Production и test/dev на второй площадке — вместо внутренних дисков задействовали СХД DellEMC Unity в конфигурации full-flash. Кроме того, заказчик запросил решение с аварийным восстановлением на базе репликации системы HANA (HSR) с кворумной нодой на третьей площадке.
Итоговая конфигурация для среды Prod состояла из сервера BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) и с 6 ТБ ОЗУ. СХД — Unity 450F 10x 3.84 ТБ. В целях disaster recovery для среды Prod использовали BullSequana S400 на Intel Xeon P8176M (28 ядер, 2.10 ГГц, 165 Вт) с 6 ТБ ОЗУ. Для среды test/dev взяли сервер BullSequana S800 с Intel Xeon P8153 (16 ядер, 2.00 ГГц, 125 Вт) и 6 ТБ ОЗУ плюс СХД Unity 450F 15x 3.84 ТБ. В качестве кворума, серверов приложений (VxRail Solution) и решения для бэкапа (DataDomain) наши специалисты установили и настроили серверы DellEMC.
Оборудование готово к будущему апгрейду. Заказчик ожидает рост сайзинга HANA в 2019 году, и ему останется только установить в стойки новые модули.
Appliance: HANA для крупного интегратора в сфере туризма
На этот раз нашим клиентом стал крупный поставщик ИТ-услуг, занимающийся разработкой технологических решений для туристических компаний. Заказчик запустил амбициозный проект SAP HANA для внедрения новой биллинговой системы. Требовалось решение в режиме Appliance с 8 ТБ ОЗУ для сред Production и PreProd. В соответствии с рекомендациями SAP, заказчик выбрал вариант с вертикальным масштабированием.
Ключевой задачей стало внедрение аппаратной инфраструктуры, основанной на сертифицированных в режиме Appliance устройствах для SAP HANA. Приоритетными критериями являлись эффективность затрат, высокая производительность, возможность масштабирования и высокая доступность данных.
Мы предложили и реализовали решение, сертифицированное SAP, включающее в себя два сервера Bullion S16 – для сред Prod и PreProd. Оборудование работает на процессорах Intel Xeon E7-v4 8890 (24 ядра, 2.20 ГГц, 165 Вт) и оснащается 16 ТБ ОЗУ. Для BW и сред Dev/Test установили девять серверов Bullion S4 (22 ядра, 2.20 ГГц, 150 Вт) по 4 ТБ ОЗУ. В качестве СХД использовалась гибридная EMC Unity.
Такое решение обеспечивает поддержку масштабирования для всех элементов устройства – например, до 16 сокетов с CPU Intel Xeon E7-v4. Администрирование в этой конфигурации упрощено – в частности, для переконфигурирования или разбиения сервера на партиции.
Appliance + TDI: HANA для металлургов
ГМК «Норильский никель» — один из крупнейших производителей никеля и палладия — решил обновить свою аппаратную платформу SAP HANA для обеспечения работы критически важных бизнес-приложений и проектов. Требовалось расширение существующего ландшафта в части вычислительных мощностей. Одним из главных условий, выдвинутых заказчиком, стала высокая доступность платформы – несмотря на аппаратные ограничения.
Для продуктивных сред мы использовали сервер Bullion S8 и СХД в режиме SAP HANA Appliance. Для HA и test/dev платформу развернули в режиме TDI. Использовали один сервер Bull Bullion S8, два Bull Bullion S6 и гибридную СХД. Такая комбинация позволила существенно увеличить скорость работы приложений ландшафта SAP, увеличить объем вычислительных мощностей и ресурсов хранения данных и минимизировать операционные расходы. Немаловажно, что у клиента осталась возможность масштабирования до 16 CPU.
Приглашаем на SAP Форум
В этом посте мы разобрали развертывание SAP HANA разными способами, постарались осветить преимущества и недостатки доступных вариантов. Если у вас появились какие-то вопросы по внедрению SAP HANA, мы будем рады ответить на них в комментариях.
Всех, кто заинтересовался решениями Bull и возможностями их внедрения под SAP HANA, приглашаем на крупнейшее SAP-событие года: 17 апреля в Москве пройдет SAP Форум 2019. Ждем вас у нашего стенда в зоне IoT: расскажем много интересного, а также разыграем множество призов.