Вычислительная платформа SAP HANA серьезно изменила ИТ-индустрию и принципы работы с Большими данными, в десятки раз сократив время их обработки. Высокая скорость работы объясняется тем, что SAP HANA является настоящей «in-memory» СУБД, все данные которой хранятся и обрабатываются непосредственно в оперативной памяти сервера. Такой дизайн СУБД предъявляет серьезные и специфические требования к используемому программному и аппаратному обеспечению. Сегодня мы поговорим о вариантах аппаратной поддержки платформы SAP HANA.



Самостоятельный подбор аппаратных и программных решений для работы с приложениями на платформе SAP HANA зачастую представляет собой сложную задачу для ИТ-специалистов, а разобраться в интеграционных аспектах бывает еще труднее. Поэтому компания SAP совместно с ведущими мировыми производителями ИТ-оборудования предлагает заказчикам готовые решения, максимально оптимизированные и предварительно протестированные для работы с SAP HANA и позволяющие максимально использовать все возможности данной платформы для бизнеса. Такие решения получили название appliance. Подобное готовое и сертифицированное компанией SAP решение от производителя избавит заказчиков от многих проблем и ошибок.

Технологические партнеры SAP имеют в своем продуктовом портфеле широкий набор преднастроенных решений для работы с платформой SAP HANA (appliance). Это готовые, сконфигурированные и полностью собранные по принципу “все в одном” решения. Appliance включает в себя сервер, систему хранения данных для SAP HANA, а также операционную систему. Подобные решения могут быть использованы как для продуктивных, так и для непродуктивных сред. По состоянию на март 2017 года у компании Fujitsu имеется наиболее обширный портфель appliance — 168 сертифицированных SAP решений, включая серверы на базе процессоров Intel Xeon E7-x8xxv4. Все приложения на базе HANA, работающие на appliance, обеспечиваются полноценной поддержкой со стороны SAP, в том числе и в вопросах, касающихся производительности.


Портфель решений для SAP

Если говорить о решениях класса appliance, то их можно разделить на две категории: Scale-up, рассчитанные на работу базы данных HANA на одном сервере, и Scale-out, предусматривающие работу базы на нескольких серверных узлах с общей системой хранения данных persistence layer. Помимо очевидных достоинств, у appliance есть и ряд недостатков. Во-первых, высокая стоимость для заказчика. Во-вторых, недостаточная гибкость, не позволяющая заказчику использовать уже установленную у него СХД.

Поэтому сегодня все больший интерес завоевывают другие решения — “конструкторы” из сертифицированных компонентов. Данный подход называется Tailored Datacenter Integration (TDI). Он позволяет заказчику собрать нужное решение, выбрав необходимые составляющие из списка сертифицированных продуктов. К примеру, можно приобрести только серверное оборудование, если подходящая система хранения уже имеется. Причем эта СХД может использоваться несколькими серверами HANA. Но если ответственность за работу appliance-решения целиком лежит на поставщике железа, то в случае с TDI-решением она смещается в сторону заказчика. Компания SAP никогда не проверяет и, тем более, не сертифицирует TDI-конфигурации, всю ответственность возлагая на заказчика. За дизайн такого решения отвечает он сам, либо привлеченные им консультанты. В роли последних могут выступать поставщики и разработчики аппаратного обеспечения, особенно международных компаний, поскольку последние обладают не только локальными, но и глобальными компетенциями по разработке дизайна TDI-систем. Можно сказать, что компания SAP тоже будет поддерживать TDI-конфигурацию, но при соблюдении таких условий, как использование в ее составе сертифицированных серверов, сертифицированной СХД, а также установка SAP HANA сертифицированным специалистом, либо специалистом компании-производителя данного сервера. Отклонения от рекомендованной вендором конфигурации СХД для SAP HANA допускаются, но в этом случае соответствие выдвигаемым SAP KPI по производительности находится в зоне ответственности заказчика. Конечно, достижение KPI по работе СХД не является обязательным условием для поддержки SAP HANA в целом, но может стать обязательным в случае возникновения проблем с производительностью.

Если речь идет об установке непродуктивных систем на базе HANA, то требования компании SAP будут еще мягче. Заказчик может устанавливать в сертифицированную модель сервера любые, даже младшие модели процессоров семейства Intel Xeon E7 и максимальный объем оперативной памяти. Также есть возможность использовать любую систему хранения данных со стандартной файловой системой, объем полезного пространства которой, как минимум, вдвое больше объема оперативной памяти.

Существует отдельный класс решений для SAP HANA — так называемые “поддерживаемые” серверы. В эту категорию, как правило, входят младшие модели на базе процессоров Intel Xeon E5 с объемом ОЗУ от 128 Гб до 1,5 Тб. Эти модели компания SAP не сертифицировала и не тестировала на достижение требуемого уровня производительности, однако гарантирует поддержку как непродуктивных, так и продуктивных систем на данных конфигурациях.

Насущным вопросом, особенно для продуктивных систем на платформе SAP HANA, является обеспечение отказоустойчивости. Проще всего эту задачу можно решить, используя вариант работы базы данных на нескольких серверах (Scale-out), о чем мы говорили выше. В этом случае необходимо выделить один резервный узел. В случае отказа одного из основных серверов, содержимое его памяти с общей СХД будет загружено в память резервного сервера. Если у заказчика работает Scale-up решение на базе одного сервера, рекомендуется использовать технологию HANA System Replication. Это встроенная в SAP HANA технология, предусматривающая создание копии всех данных с основного на резервном сервере. В случае отказа основного сервера возможно переключение на резервный. При этом база данных HANA может быть как уже загружена в оперативную память резервного сервера, так и быть записана на его диске. Технология HANA System Replication не обеспечивает автоматического переключения на резервный сервер. Для решения этой задачи необходимо использовать кластерный агент, который сможет реализовать автоматическое переключение в подобной ситуации. Такой кластерный агент входит в число стандартных компонентов операционной системы SUSE Linux Enterprise Server (SLES).

Резервное копирование в SAP HANA реализуется несколькими способами. Во-первых, за счет внутренних инструментов самой платформы, когда данные резервируются непосредственно на диск. Это самый недорогой и эффективный вариант. Единственный серьезный недостаток — отсутствие каких-либо средств управления жизненным циклом резервных копий. По мере потери ими актуальности администратору придется удалять устаревшие копии вручную. Второй вариант резервного копирования можно организовать с помощью специализированного ПО, в котором имеются агенты, сертифицированные для работы с SAP HANA. В этом случае резервное копирования выполняется по аналогии с бэкапом любой другой СУБД, с записью на ленточные или другие накопители, а функции управления жизненным циклом резервных копий возлагаются на специализированное ПО. Третий вариант предусматривает использование аппаратных снимков (snapshot), если оборудование их поддерживает.


Резервное копирование в SAP HANA

Системный ландшафт SAP включает в себя не только HANA, но и классические базы данных с серверами приложений. Для управления ими можно использовать решение Fujitsu FlexFrame Orchestrator, предназначенное для работы в смешанных средах, где работают продукты на SAP HANA и других платформах, таких как, например, VMware, NetApp, SUSE и другие. В состав FlexFrame Orchestrator входят аппаратные и программные компоненты, которые обеспечивают распределение ресурсов между системами и высокую доступность по целому ряду схем. Применение данного решения позволяет заказчику снизить операционные и капитальные расходы на поддержку ИТ-инфраструктуры в объеме до 50%.

Если говорить об использовании SAP HANA на виртуальных машинах, то необходимо учесть тот факт, что поддерживается только платформа виртуализации VMware vSphere, для которой также существует целый ряд ограничений. Например, для VMware vSphere 5.5 объем оперативной памяти виртуальной машины не может превышать 1 Тб, для старших версий планка выше — до 4 Тб.



Итак, при выборе решения для работы с SAP HANA заказчик не связан никакими жесткими ограничениями, как это было бы с одними лишь appliance. Существует множество способов организации инфраструктуры и множество факторов, которые можно учитывать. Ведущие мировые ИТ-компании, как правило, предлагают не только широкий выбор вариантов построения таких решений, но и экспертизу по ним. У каждого подхода имеются как свои достоинства, так и недостатки, которые необходимо учитывать. Любая задача, связанная с SAP HANA, всегда имеет не одно, а несколько решений, из которых нужно выбрать то, которое в наибольшей степени подходит заказчику.