В первой части статьи я рассказал про первый день мастер-класса по SAP HANA, который проводил Михаил Вронский во время осенней сессии от SAPLand.
Второй день проходил там же и почти в том же составе. Вторая часть мастер-класса носила более технический характер, то есть целевая аудитория: BASIS консультанты, архитекторы.
Материалы этого дня были опять же переработаны и дополнены. Много времени было уделено следующим вопросам:
Мои записи с этого дня.
Сервер для работы с SAP HANA должен быть сертифицирован для продуктивного использования.
Поставка оборудования может осуществляться по двум моделям (рис. 1):
Количество внедрений SAP HANA на 2018 год по производителям оборудования можно посмотреть вот по этой ссылке. Например, по Appliance и TDI (рис. 2). HPE, конечно, тут всех обходит. У них есть самое крупное решение для SCALE-UP внедрений - SuperDome Flex. Позволяет собрать сервер с 30 Тб оперативной памяти!
Факторы, позволяющие уменьшить объем базы данных при переходе на SAP HANA:
- удаление индексов,
- использование сжатия данных при поколоночном хранении, которое в этом случае выше, чем при построчном.
Но перед переходом обязательные декластеризация и депулинг таблиц, а эти операции увеличивают размер базы данных против первоначального.
На практике максимальное уменьшение не более, чем в 2 раза.
При планировании перевода решения на базу данных SAP HANA для сайзинга можно использовать отчёт в SAP системе. Подробности в SAP notes:
Варианты установки (рис. 3):
- SCALE-OUT - несколько серверов, объединенных в одну базу данных. Желательно избегать, если требования к памяти до 25 Тб. Минусы: снижение производительности из-за больших задержек между узлами и повышенные риски.
- SCALE-UP - одна база данных на одном сервере.
Можно делать преобразование SCALE-OUT в SCALE-UP и обратно, используя утилиту hdblcm.
Второй день проходил там же и почти в том же составе. Вторая часть мастер-класса носила более технический характер, то есть целевая аудитория: 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:
Варианты установки (рис. 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).
В целом от переработки мастер-класс выиграл. Спасибо еще раз Михаилу и SAPLand.
Претензия у меня есть только одна: печатные материалы были черно-белыми, а это на некоторых слайдах портило восприятие информации.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий