Решение KunLun SAP HANA: вертикальное масштабирование в первую очередь

Просмотров: 2488
Автор:
Редакция Global CIO

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

Один из основателей корпорации SAP Хассо Платтнер, большой поклонник технического прогресса, в 1998 году лично профинансировал создание Института имени Хассо Платтнера, главной деятельностью которого стало проведение исследований и разработка программного обеспечения как в учебных, так и промышленных целях. За почти 20 лет, прошедших со дня основания, крупнейшим достижением института стала разработка и успешное применение базы данных в оперативной памяти SAP HANA.

В 2009 году на организованной институтом конференции SIGMOD Хассо опубликовал документ A Common Database Approach for OLTP and OLAP Using an In-Memory Column Database (Общий подход к реализации OLTP и OLAP с использованием базы данных в оперативной памяти). Основным содержанием документы были базы данных в оперативной памяти, колоночное хранение и гибридные приложения OLTP/OLAP. Это фундаментальные теории БД в оперативной памяти SAP HANA. Впоследствии Хассо, возглавивший институт и компанию SAP, способствовал воплощению в жизнь задуманных идей и успешному запуску продуктов под брендом HANA в 2011 году. Продукты в очень короткий срок завоевали популярность и признание на рынке. На сегодняшний день вся линейка приложений SAP поддерживает SAP HANA.

В чем уникальные преимущества SAP HANA?

Основные технические особенности SAP HANA:

  • Данные хранятся максимально близко к вычислительным ресурсам, а данные БД полностью хранятся в оперативной памяти. Это позволяет избежать частого перемещения информации с жестких дисков или других устройств хранения в область памяти. Помимо операций, связанных с постоянным сохранением данных, центральный процессор по мере возможности не взаимодействует с системой хранения.
  • Использование поколоночного хранения данных повышает производительность сервисов OLAP, большей частью представляющих собой оперативные запросы и отчеты в реальном времени. Также повышается эффективность сжатия.
  • В области памяти Delta используется смешанный режим хранения данных — поколоночный и построчный. Это обеспечивает производительность, требуемую приложениями OLTP.

Итак, каким же образом решение SAP HANA хранит данные как можно ближе к вычислительным ресурсам, поддерживает высокую производительность вычислительных операций и при этом следует правилу расширения сервера «вертикальное масштабирование в первую очередь»?

С технической стороны, использование компьютерной архитектуры фон Неймана привело к развитию иерархических систем хранения (англ. наименование Memory Hierarchy). Идея обработки данных в оперативной памяти широко признана, поскольку демонстрирует более высокую производительность по сравнению с методом обработки на жестких дисках (или других внешних устройствах хранения). Однако точка зрения, что благодаря организации вычислений в оперативной памяти обеспечивается поддержка гибридных приложений OLAP/OLTP без ущерба производительности, долго ставилась под сомнение. Проанализировав ряд сценариев, реально реализованных у клиентов SAP, Хассо сделал вывод, что характер операций чтения/записи данных в OLTP и OLAP не сильно отличаются — в OLTP доминируют операции чтения, тогда как в OLAP чаще выполняются операции записи. Такая статистика позволят Хассо утверждать, что базы данных в оперативной памяти способны поддерживать высокопроизводительную работу гибридных приложений OLTP и OLAP.

Рис. 1 Характер распределения рабочей нагрузки в приложениях OLTP и OLAP, полученный специалистами SAP в ходе анализа

С момента выхода база данных в оперативной памяти SAP HANA блестяще зарекомендовала себя на рынке благодаря выдающимся показателям производительности, особенно в приложениях OLAP. Завоевав признание клиентов, данный продукт быстро занял внушительную долю рынка. Вот некоторые цифры для примера. Одна из компаний заменила свою старую базу данных решением Huawei SAP HANA. По результату измерений реальных данных выявлено снижение среднего показателя отклика сервера с 800 мс до 370 мс. По сути время отклика было уменьшено во многих стандартных приложениях. Например, скорость запроса на отправку короткого сообщения с уведомлением о переводе денег была увеличена в 100 раз. Можно привести еще много примеров из реальной практики применения решения в мировом масштабе, и все они получили высокую оценку клиентов.

В действительности базы данных в оперативной памяти имеют абсолютное преимущество перед традиционными БД в среде постоянного хранения (на внутренних жестких дисках серверов или внешних СХД) и технологически это совершенно новое поколение продуктов. В настоящее время, задержка доступа процессоров Intel (Xeon E7 v4) к локальной оперативной памяти составляет 110 нс, в то время как задержка чтения данных объемом 4 КБ с локального жесткого диска (SAS SSD) составляет порядка 130 мкс. Демонстрируя низкую задержку, режим доступа в оперативной памяти имеет очевидное преимущество.

При разработке HANA, как первой успешной реализации базы данных в оперативной памяти, были использованы такие технические достижения, как полупроводниковые интегрированные схемы и вычислительная аппаратная платформа. К примеру, увеличена плотность DRAM, емкость DIMM и число каналов памяти центрального процессора. Компания Intel добилась емкости оперативной памяти в 1 ТБ с одним процессором на платформе Brickland (процессор Broadwell). (В компании SAP действует правило сертификациидо  1 ТБ оперативной памяти на один процессор Broadwell E7-8890. ).

Huawei KunLun: оптимальное аппаратное решение для продукта SAP HANA

Решение Huawei KunLun было сертифицировано компанией SAP для работы с полной линейкой HANA. Созданное на базе сервера поддержки критически важных приложений KunLun, решение KunLun SAP HANA предназначено для работы с корпоративными базами данных, поддержки процессов принятия решений и обработки коммерческих операций. Данный сервер с 4, 8, 16 или 32 процессорами Intel® и сверхбольшой оперативной памятью в 32 ТБ способен обрабатывать без усилий огромные объемы данных даже в крупномасштабных системах вычислений . Высочайшая производительность достигается благодаря передовой архитектуре KunLun. В сравнении с восьмисокетными серверами x86, всего лишь один сервер KunLun способен поддержать работу in-memory базы данных большей, емкости, демонстрируя высокую эффективность использования ИТ-ресурсов и низкие затраты на управление.

Если ранее производительность процессора увеличивалась только за счет повышения тактовой частоты, то сейчас для этого увеличивается число ядер и задействуются технологии параллельной обработки. Например, процессор Intel Broadwell поддерживает 24 ядра и 48 потоков, тогда как вычислительная мощность Huawei KunLun обеспечивается 768 ядрами и 1536 потоками. Благодаря реализации главной идеи — хранение данных максимально близко к вычислительным ресурсам — сервер критически важных приложений KunLun отлично подходит к SAP HANA и отвечает запросам клиентов в отношении высокой производительности баз данных.

Компания SAP придерживается принципа выбора оборудования, обладающего лучшей в своем классе производительностью. Поэтому своим клиентам SAP советует в первую очередь акцентировать внимание на вертикальном масштабировании. Если требуемая емкость оперативной памяти достигнута, лучше использовать конфигурацию из одного узла, а не кластерную, поскольку, как показали результаты, кластерная конфигурация не демонстрирует самую высокую производительность. Если при обсуждении с клиентом вопроса выбора оборудования выяснится, что обеспечить запрашиваемую им оперативную память одним сервером невозможно (например, клиент запросил емкость в 100 ТБ, достичь которой использованием одного сервера x86 в настоящий момент невозможно), и систему клиента необходимо развернуть в кластере, то это как раз тот случай, когда необходимо привлекать специалистов по базам данных и корпоративным приложениям. Здесь имеет смысл распределить базы данных или таблицы по кластерным узлам, используя встроенные алгоритмы БД.

Существенная разница между односерверной и кластерной конфигурациями заключается в  том, что в первом случае используется простой доступ к памяти, а во втором — межсерверные (между операционными системами) операции ввода-вывода или удаленный доступ к памяти (Remote Direct Memory Access; RDMA) (в настоящий момент SAP HANA не поддерживает технологии InfiniBand и удаленного доступа к памяти RoCE, но в перспективе это планируется реализовать). Разница в методах доступа приводит к значительной разнице в производительности. Если взять в качестве примера процессор Intel E7 v4, то здесь мы имеем задержку чтения блока данных 64 КБ из оперативной памяти, равной 110 нс. Однако при использовании технологии InfiniBand с поддержкой RDMA стандартное значение задержки чтения 64 КБ из памяти другого сервера составляет 1,5 мкс (согласно результатам тестирования, линейная скорость InfiniBand QDR составляет 40 Гбит/с). Разница в задержке между двумя методами доступа — 15-кратная. При использовании интерфейса 10GE (линейная скорость 10 Гбит/с, эффективная пропускная способность — около 1 Гбит/с и выше) разница составит минимум 60 раз.

Рис. 2 Сравнение NUMA-доступа в большом одноузловом сервере HANA с методом доступа к данным в горизонтально масштабируемой системе

Таким образом, по возможности, необходимо избегать межузловых операций чтения данных, а для этого требуется хорошее распределение баз данных или таблиц между узлами. Однако в реальности межузловая передача данных в корпоративных приложениях — это обычная практика, а операций чтения данных между узлами и вовсе не избежать. Как правило, разница в производительности между одноузловой конфигурацией и кластерной всегда огромна.

На сегодняшний день решение Huawei SAP HANA на базе KunLun в односерверной конфигурации обеспечивает максимально 32 процессора и 32 ТБ емкости (сертифицирована модель на 16 TB, запланирована сертификация модели на 20 ТБ, спецификации для емкости более 20 ТБ постепенно проходят сертификацию). Односерверные решения поддерживают расширение емкости с 4 до 32 процессоров. Приобретенный однажды сервер в дальнейшем расширяется с ростом потребностей клиента. То есть постепенно наращивается емкость памяти и увеличивается производительность решения SAP HANA. Обеспечиваемая односерверной конфигурацией KunLun память емкостью 32 ТБ отвечает запросам большинства клиентов. Для работы сверхмощных корпоративных приложений, требующих более 32 ТБ оперативной памяти, компания Huawei предлагает в настоящий момент кластерные решения и в перспективе готовит серверное решение следующего поколения для критически важных приложений KunLun и платформы SAP HANA, поддерживающее более масштабные расширения и более высокую производительность.

Лучший эксперт и партнер в проектах цифровой трансформации предприятий

Решения Huawei SAP HANA, признанные многими клиентами из разных стран, массово развертываются в Китае, странах Европы, Ближнего Востока, Америки и Африки. Более 10000 клиентов из 40 стран используют данное решение. Среди них China National Petroleum Corporation (CNPC), CEPSA (испанская нефтяная компания), Hillarys Blinds в Соединенных Штатах, Fonterra в Новой Зеландии и BYD Auto в Китае. На платформе Huawei SAP HANA функционирует основная производственная система ERP компании CEPSA, которая высоко оценила это решение за высочайшую производительность и надежность. Оперативная память емкостью 13 ТБ, реализованная в фазе 1 проекта, была расширена до 30 ТБ в фазе 2.

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

Комментарии (0)

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.