Як розгорнути 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 має серйозні обмеження:

• масштабування Scale-out не підтримується – віртуалізація може використовуватися тільки з системами Scale-Up, чи то BwoH/DM/SoH, чи «чиста» SoH;
• віртуалізація повинна проводитись у рамках правил, встановлених для пристроїв Appliance або TDI;
• у General Availability (GA) може бути лише одна віртуальна машина - компанії, які бажають використовувати віртуалізацію з продуктивними середовищами HANA, повинні брати участь у програмі Controlled Availability із SAP.

У непродуктивних середовищах, де перелічені обмеження відсутні, віртуалізація може бути використана для оптимізації використання обладнання.

Топології SAP HANA

Перейдемо до розгортання SAP HANA. Тут визначено дві топології.

• Scale-up – один великий сервер. У міру зростання бази HANA росте і сам сервер: збільшується кількість CPU та обсяг пам'яті. У рішеннях з High Availability (HA) і Disaster Recovery (DR) резервні або стійкі до відмови сервери повинні відповідати продуктивним серверам за характеристиками.
• Scale-out – весь об'єм системи SAP HANA розподілено на декілька ідентичних серверів. Master-сервер містить інформацію для Index Server та Name Server. Сервери Slave цих даних не містять - крім сервера, який бере на себе функції Master у разі збою у основного сервера. Робочі сервери (Index Servers) управляють сегментами даних, які приписуються до них, і навіть відповідають запити. Name Server'и знають, як дані розподіляються між робочими серверами. У разі зростання HANA до поточної конфігурації сервера додається ще одна нода. У такій топології достатньо мати одну резервну ноду для забезпечення безпеки всього сервера.

Вимоги SAP до заліза

До апаратного забезпечення для HANA SAP має обов'язкові вимоги. Вони стосуються продуктивних середовищ – для non-prod достатньо мінімальних характеристик. Отже, ось вимоги для продуктивних середовищ:

• CPU Intel Xeon v5 (SkyLake) / 8880/90/94 v4 (Broadwell)
• від 128 ГБ RAM для програм BW з 2 CPU, 256 ГБ з 4+ CPU;

Розгортаємо 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 – передналаштоване рішення, що включає сервер, СГД та пакет ПЗ для впровадження «під ключ», з централізованою службою підтримки та обумовленим рівнем продуктивності. Тут HANA поставляється у вигляді попередньо налаштованого апаратного та програмного забезпечення, повністю інтегрованого та сертифікованого. Пристрій в режимі Appliance готовий до встановлення в ЦОД, а операційна система, SAP HANA і (якщо необхідний) додатковий інстанс VMWare вже налаштовані та встановлені.

Сертифікація SAP визначає гарантований рівень продуктивності, а також модель CPU, обсяг RAM та СГД. Після сертифікації змінити конфігурацію без втрати гарантії не можна. Для масштабування платформи HANA SAP пропонує три варіанти.

• Scale-Up BWoH/DM/SoH – вертикальне масштабування, що підходить для єдиних систем (один SID). Зростання пристроїв Appliance відбувається по 256/384 ГБ, починаючи з версії SAP HANA SPS 11. Це співвідношення показує максимальний об'єм, який підтримує один CPU, і є загальним для всього списку сертифікованих Appliance-пристроїв. Appliance BWoH/DM/SoH з вертикальним масштабуванням оптимально підходить для додатків BW on HANA (BWoH), Data Mart (DM) та додатків SAP Suite on HANA (SoH).
• Scale-Up SoH - Це полегшений варіант попередньої моделі, з меншою кількістю обмежень за обсягом ОЗП. Це все ще вертикально-масштабований сервер, але максимальний об'єм ОЗУ на 2 процесори складає вже 1536 ГБ (до версії SPS11) та 3 ТБ (SPS12+). Підходить лише для SoH.
• Scale-Out – це варіант із горизонтальним масштабуванням, системою, що підтримує багатосерверні конфігурації. Горизонтальне масштабування оптимально підходить для BW та – з деякими обмеженнями – для SoH.

У серверах BullSequana S і Bullion S вертикальне масштабування є основним, оскільки має менше операційних обмежень і вимагає менше адміністрування. Для Appliance є велика лінійка різних пристроїв.

Рішення BullSequana S для SAP HANA у режимі Appliance

*Optional E7-8890/94v4
Рішення Bullion S для SAP HANA у режимі Appliance

Всі рішення Bull в режимі Appliance із версією SAP HANA SPS 12 сертифіковані. Обладнання встановлюється у стандартну 19-дюймову стійку 42U, з двома джерелами живлення – внутрішніми PDU. Сертифікацію SAP мають сервери:

• BullSequana S з Intel Xeon Skylake 8176, 8176M, 8180, 8180М (процесори з літерою "M" підтримують роботу з модулями пам'яті по 128 ГБ). За співвідношенням ціни та якості найкраще виглядають варіанти з Intel 8176
• Bullion S з Intel Xeon E7-8880 v4, 8890 та 8894.

СГД з'єднується із сервером безпосередньо через порти FC, так що комутатори SAN тут не потрібні. Вони можуть стати в нагоді для доступу до систем, підключених до LAN або SAN.

Ось приклад конфігурації СГД EMC Unity 450F у нашому сетапі:

• Висота: 5U (DPE 3U (25×2,5″ HDD/SSD) + DAE 2U (25×2,5″ HDD/SSD))
• Контролери: 2
• Диски: від 6 до 250 SAS SSD, від 600 ГБ до 15.36 ТБ кожен
• RAID: level 5 (8+1), 4 RAID-групи
• Інтерфейс: 4 FC на контролер, по 8 чи 16 Гбіт/с
• Софт: Unisphere Block Suite

Appliance — надійний варіант розгортання, але має великий недолік: мало свободи у конфігуруванні заліза. Крім того, такий варіант може вимагати змін у процесах роботи ІТ-підрозділу.

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), які дозволяють перевірити дотримання певних SAP KPI. І є вимога, не пов'язана із залізом: 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: розповімо багато цікавого, а також розіграємо безліч призів.

До зустрічі на форумі!

Джерело: habr.com