Мастер-класс по архитектуре SAP HANA 2.0. День 2
В первой части статьи я рассказал про первый день мастер-класса по SAP HANA, который проводил Михаил Вронский во время осенней сессии от SAPLand.
В первой части статьи я рассказал про первый день мастер-класса по 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:
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти