Сайзинг СХД для SAP HANA

s4 hana

С завидной периодичностью получая запросы на сайзинг СХД для SAP HANA, я вижу больше разнообразие подходов в составлении требований к производиельности. Тема эта сейчас очень актуальна, так что давно нужно внести в нее больше понимания.  Ведь дело в том, что хотя это и высокоскоростная среда, но от требований в 100500 тысяч IOPS под SAP HANA до реальных потребностей заказчика — как до Юпитера  При этом найти что-то внятное про сайзинг для SAP HANA на просторах даже англоязычного интернета сложновато.

Сама архитектура SAP HANA достаточно неплохо описана в сети. Почитать о ней можно здесь, или здесь.

Те, кто с данной областью в общих чертах знаком, знают, что SAP HANA – это платформа In-Memory обработки данных в реальном времени.  Весь рабочий объем данных хранится и обрабатывается исключительно в памяти рабочих узлов (worker nodes) SAP HANA.  Вам кажется, что БД не может вся уместиться в памяти? «Может!», скажут продавцы SAP. «Может, если это HANA, которая специально разработана для высококомпатного хранения данных с поколоночным сжатием и scale-out масштабированием». Я сейчас не буду погружаться в эту полемику, но могу сказать, вопрос поизучал, и технологии интересные там действительно есть, а архитектура БД позволяет полноценно гонять по ней одному экземпляру и аналитику, и транзакционные задачи, снижая таким образом требования к СХД. Поэтому, кстати, всякие попытки раздуть требования к объемам за счет многочисленных копий для аналитиков здесь не играют, и ни дедупликация, ни компрессия в среде HANA выстреливать особенно не будет. Но я большой не гуру в этой теме, поэтому перейдем побыстрее к СХД.

Из того, что HANA — in-memory следует, что нагрузка на подсистему хранения (СХД) в данном случае минимальна. Это один из основополагающих принципов In-Memory (иллюстрация ниже).

SAP-HANA-In-Memory-Computing

 

Благодаря этому, в ряде случаев HANA не нуждается во внешней СХД, пользуясь при этом внутренними дисками серверов. Это относится, как правило, к внедрениям начального уровня.

Однако, нагрузка на дисковую подсистему все-таки не равна нулю и HANA без СХД пока обойтись не может. «Пока» — значит, что память в серверах энергозависимая.

Система хранения (DAS или SAN) выполняет задачи

  • энергонезависимого хранения на случай сбоя/замены узлов, отказов питания
  • для scale-out кластеризации
  • тиерингового хранения, в случае, когда данные не вмещаются в основную память рабочих узлов

Третий случай- единственный из всего многообразия, когда требования к производительности СХД сколь либо заметны. Во всех остальных случаях нагрузка на дисковую подсистему близка к минимальной.

По большому счету, пик обращений к дисковой подсистеме имеет место только в случае бэкапа, старта БД, или начального импорта данных. Ни один из этих процессов, как правило, не является критичным для регулярной продуктивности пользователей. То есть, понятное дело, что из бэкапа нужно восстанавливаться в сжатые сроки, база должна стартовать быстро, а данные импортироваться моментально. Но эти вещи происходят, как правило, даже не каждый день. Хорошо, импорт данных – чаще, но объем импортируемых данных редко бывает значительным.

Во время своей обычной работы СУБД HANA так же обращается к дисковой системе в следующих случаях:

Запись Redo Log-ов. Это единственный процесс, являющийся синхронным. Т.е. транзакция не подтверждается приложением до тех пор, пока не придёт подтверждение от СХД. Запись и подтверждение делаются в реальном времени, а поэтому время отклика для LUN-ов хранящих redo-logs крайне критично для производительности всего приложения. Запись логов – последовательная, а значит великолепно кэшируется. То есть время отклика даже на механических дисках будет хорошее (если в СХД есть кэш, который работает и не переполнен).

Запись savepoint-ов.  Это инкрементальный сброс содержания памяти в data-тома. Запись savepoint делается каждые 5 минут и процесс происходит асинхронно. То есть на скорость выполнения пользовательских транзакций оказывает минимальное влияние. Дословно это звучит так – «Database update transactions only wait at the critical phase of the savepoint, which is taking a few microseconds».

Иллюстрация активности обращений к СХД со стороны SAP HANA приведена на иллюстрации ниже.

SAP HANA disk IO

 

Обратите внимание, что самые большие объемы обращений это бэкапы, восстановления и перезапуски, которые происходят лишь в случае сбоев.

Вернемся к вопросу сайзинга архитектуры хранения. Общие требования достаточно подробно описаны в официальном документе SAP HANA TDI Storage Requirements.

Но если вы хотите увидеть в документе конкретные указания на количество IOPS – вас ждет разочарование. Их там нет. Обработка происходит в памяти. Вместо требований к IOPS в документе приведены формулы расчета полезной емкости СХД для «персистентного» (постоянного) хранения.

Кратко требования к объему можно сформулировать так:

  • Data = 1.2x net disk space (“net disk space“ это общий размер БД в памяти)
  • Log = 0.5TB RAM (для всех узлов, у которых более 512GB RAM)
  • /hana/shared = 1x RAM на каждые 4 узла
  • OS: ~100GB загрузочная область на узел

Для scale out кластера из 4х узлов (3 рабочих и 1 мастер), каждый с 2Тбайт RAM.

Net disk space составляет 3 узла *2ТБ * 50% = 3ТБ

То есть Data Volume Size = 3.6TB

Log Volume = 512GB

/hana/shared = 2TB

OS = 400GB

Итого: 7.5TB

 

/hana/shared это, как нетрудно понять, общая кластерная область, где хранятся инсталляционные бинарники, и куда сохраняются сервисные трейсы и журналы. Ничего с важного точки зрения производительности эта область не представляет.

Таким образом, получаем, что для 4х-узлового кластера с базой 3ТБ нужно 7.5ТБ хранилище, которое для полноценных продуктивных сред должно обладать функциями надежности уровня enterprise. Чтобы не утруждать своих заказчиков вопросами отбора конкретных «энтерпрайз фич» инженеры SAP вместе с ведущими вендорами провели отбор и сертификацию платформ хранения по программе TDI (Tailored Data Center Integration, что по-русски означает «сборка ЦОД-а сделанного по мерке»).

Описание программы TDI приведено здесь.

С перечнем сертифицированных по ней СХД можно ознакомиться тут.

Внимательный читатель при изучении таблиц сертифицированных СХД заметит, что для большего количества узлов рекомендуются более мощные СХД, что находится в некотором противоречии с низкими требованиями к производительности самих «дисков». Я полностью соглашусь с вами, но в оправдание такого подхода могу сказать следующее:

Tailored Datacenter программа – это сведенная до максимальной простоты квинтэссенция best practice-s, которая позволяет с минимальным риском для любого проекта SAP HANA выбрать правильную инфраструктуру.

Мы ничего не знаем на данном этапе об абсолютных значениях нагрузки на СХД, кроме того, что она «будет маленькой». В большинстве ситуаций данных по конкретной нагрузке до момента пилотного проекта SAP HANA мы и не получим, а планировать инфраструктуру нужно заранее. В этом плане нам ничего не остается, кроме как планировать инфраструктуру без узких мест.

Если мы будем исходить из этой концепции, то количество узлов HANA определяет уровень рабочей нагрузки, который комплекс в целом сможет вытянуть.  Количество узлов рассчитывается исходя из числа пользователей, задач, и других бизнес-параметров. Чем больше всего на кластере будет работать, тем больше и узлов. Соответственно, чем больше узлов, тем больше нагрузка на систему ввода-вывода.  Таким образом, под размер кластера и выбирается соразмерная СХД, делающая аппаратный комплекс вертикально сбалансированным.

Например, для приведенного выше примера с 4-узловым кластером подойдет 1 X-Brick XtremIO X1, Unity 300/350 или SC 4020 на 7.5 ТБ полезных.

Это слайд-шоу требует JavaScript.

Что из этих 3х массивов подходит больше для ваших конкретных задач – тема отдельного обсуждения, требующая погружения в проект. Есть, например, перечень аргументов в пользу ни больше, ни меньше, как «идеальности All Flash СХД для HANA», который стоит критически рассмотреть в отдельной публикации.

У меня же на сегодня всё. Спасибо за внимание.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s