Конфигурации хранилища виртуальных машин SAP HANA в Azure

  • Статья

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

Дополнительные сведения об этих типах дисков см. в статье Типы Службы хранилища Azure для рабочей нагрузки SAP и Выбор типа диска

Azure предлагает два метода развертывания для виртуальных жестких дисков в Azure Standard и хранилище класса Premium версии 1/v2. Воспользуйтесь преимуществами управляемого диска Azure для развертывания блочного хранилища Azure.

Список типов хранилища и их соглашения об уровне обслуживания в отношении операций ввода-вывода в секунду (IOPS) и пропускной способности хранилища см. на странице Цены на управляемые диски.

Внимание

Вне зависимости от выбранного типа хранилища Azure, файловая система, используемая в этом хранилище, должна поддерживаться SAP для конкретной операционной системы и СУБД. Примечание о поддержке SAP #2972496 содержит список поддерживаемых файловых систем для различных операционных систем и баз данных, включая SAP HANA. Это относится ко всем томам, к которым SAP HANA может получать доступ для чтения и записи, для любой задачи. В частности, при использовании NFS в Azure для SAP HANA дополнительные ограничения версий NFS будут применяться, как указано далее в этой статье.

Далее представлены минимальные сертифицированные SAP HANA условия для разных типов хранилищ.

  • Хранилище Azure уровня "Премиум" версии 1 — /hana/log требуется для поддержки ускорителя записи Azure. Том /hana/data можно поместить в хранилище класса Premium версии 1 без ускорителя записи Azure или на диске "Ультра". Хранилище Azure уровня "Премиум" версии 2 или SSD Azure уровня "Премиум" версии 2 не поддерживает использование акселератора записи Azure
  • По крайней мере для тома /hana/log следует использовать диск категории "Ультра". Том /hana/data можно поместить в хранилище класса Premium версии 1/v2 без ускорителя записи Azure или для ускорения перезапуска диска "Ультра"
  • Тома формата NFS версии 4.1 поверх Azure NetApp Files для /hana/log и /hana/data. Том /hana/shared может использовать протоколы NFS версии 3 или NFS версии 4.1

На основе опыта работы с клиентами мы изменили поддержку объединения различных типов хранилища между /hana/data и /hana/log. Она поддерживается для объединения использования различных хранилищ блоков Azure, сертифицированных для общих папок HANA AND NFS на основе Azure NetApp Files. Например, можно поместить /hana/data в хранилище класса Premium версии 1 или версии 2 и /hana/log , чтобы получить необходимую низкую задержку. Если вы используете том на основе ANF для /hana/data, том /hana/log можно поместить на один из сертифицированных типов хранилища блоков Azure HANA. Использование NFS на вершине ANF для одного из томов (например, /hana/data) и хранилища Azure premium версии 1/v2 или Ultra для другого тома (например, /hana/log) поддерживается.

До сего дня вам не нужно было беспокоиться о подсистемах ввода-вывода и их возможностях. Это связано с тем, что поставщику оборудования необходимо было убедиться в том, что для SAP HANA соблюдены минимальные требования к хранению. При самостоятельном создании инфраструктуры Azure вам следует знать некоторые из этих требований. Ниже перечислены некоторые минимальные характеристики пропускной способности, рекомендуемые SAP:

  • Чтение/запись для /hana/log с пропускной способностью 250 МБ/с для размера операций ввода-вывода 1 МБ
  • Чтение с пропускной способностью не менее 400 МБ/с для /hana/data для размеров операций ввода-вывода 16 МБ и 64 МБ
  • Запись с пропускной способностью не менее 250 МБ/с для /hana/data для размеров операций ввода-вывода 16 МБ и 64 МБ

Так как небольшая задержка хранилища для систем СУБД является критической, даже такие системы, как SAP HANA, хранят данные в памяти. Критический путь в хранилище обычно находится рядом с записями журналов транзакций систем СУБД. Кроме того, такие операции, как запись точек сохранения или загрузка данных в памяти после восстановления из-за сбоя, могут быть критическими. Поэтому необходимо использовать хранилище Azure уровня "Премиум" версии 1/2, диск "Ультра" или ANF для томов /hana/data и /hana/log.

Принципы выбора конфигурации хранилища для HANA:

  • Определитесь с типом хранилища на основе документации Типы Службы хранилища Azure для рабочей нагрузки SAP и Выбор типа диска
  • При выборе виртуальной машины или изменении ее размера учитывайте пропускную способность ввода-вывода. Общие сведения о пропускной способности хранилища виртуальной машины см. в статье Размеры виртуальных машин, оптимизированных для операций в памяти
  • При выборе конфигурации хранилища попробуйте использовать конфигурацию тома /hana/Data с пропускной способностью ниже общей пропускной способности виртуальной машины. SAP HANA, записывая точки сохранения, HANA может быть агрессивным выдачой ввода-вывода. При написании точки сохранения можно легко подтолкнуть к ограничениям пропускной способности тома /hana/data . Если диски, создающие том /hana/data, имеют более высокую пропускную способность, чем позволяет виртуальная машина, можно столкнуться с ситуацией, когда пропускная способность, используемая записью точки сохранения, мешает пропускной способности записи журнала повторов. Ситуация, которая может повлиять на пропускную способность приложения
  • Если вы планируете использовать репликацию системы HANA, хранилище, используемое для /hana/data для каждой реплика, должно быть одинаковым, а тип хранилища, используемый для /hana/log в каждой реплика, должен быть одинаковым. Например, использование хранилища Azure класса Premium версии 1 для /hana/data с одной виртуальной машиной и диском Azure Ultra для /hana/data в другой виртуальной машине с реплика той же конфигурации системы HANA реплика tion, не поддерживается.

Внимание

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

Чередующиеся наборы и секционирование томов данных SAP HANA

Используя хранилище Azure уровня "Премиум" версии 1, вы можете получить оптимальное соотношение цен и производительности при чередовке тома /hana/data и/или /hana/log на нескольких дисках Azure. Вместо развертывания более крупных томов диска с увеличенной пропускной способности или большим объемом операций ввода-вывода в секунду. Создание одного тома на нескольких дисках Azure можно выполнить с помощью диспетчеров томов LVM и MDADM, которые являются частью Linux. Метод чередования дисков известен уже десятки лет. Сложность управления чередующимися томами может возрасти из-за их использования для достижения необходимых объемов операций ввода-вывода в секунду или требуемой пропускной способности увеличивает. Особенно в случаях применения расширенных возможностей томов. По крайней мере для /hana/data в SAP появился альтернативный метод, достигающий ту же цель, что и чередование на нескольких дисках Azure. Начиная с SAP HANA 2.0 SPS03 сервер индексирования HANA может выполнять чередование операций ввода-вывода с несколькими файлами данных HANA, расположенными на разных дисках Azure. Преимущество заключается в том, что создавать чередующиеся тома и управлять ими на разных дисках Azure не требуется. Функциональные возможности SAP HANA в области секционирования тома данных подробно описаны в следующих разделах:

Считывая подробные сведения, очевидно, что применение этой функции отнимает сложности наборов полос на основе диспетчера томов. Кроме того, вы понимаете, что секционирование томов данных HANA не только работает для хранилища блоков Azure, например хранилища Azure класса Premium версии 1/v2. Данные функциональные возможности можно также использовать для чередования общих папок NFS, если эти папки имеют ограничения, связанные с операциями ввода-вывода в секунду или пропускной способностью.

Режим планировщика операций ввода–вывода для Linux

Linux имеет несколько разных режимов планирования операций ввода-вывода. Распространенная рекомендация поставщиков Linux и SAP предполагает перенастройку режима планировщика ввода-вывода для томов диска с mq-deadline или kyber на режимы noop (без нескольких очередей) или none (с несколькими очередями), если это еще не выполнено профилями Saptune SLES. Дополнительные сведения см. в следующих разделах:

На Red Hat оставьте параметры, установленные конкретными профилями настройки для различных приложений SAP.

Чередуйте размеры при использовании диспетчеров логических томов

Если вы используете LVM или mdadm для создания наборов полос на нескольких дисках Azure уровня "Премиум", необходимо определить размеры полосы. Для /hana/data и /hana/log применяются разные размеры. Рекомендуется использовать следующие размеры блоков чередования:

  • 256 КБ для /hana/data
  • 64 KБ для /hana/log

Примечание.

Размер блока чередования для /hana/data был изменен со времени предыдущих рекомендаций (64 КБ или 128 КБ) до 256 КБ на основе опыта пользователей с более поздними версиями Linux. Размер 256 КБ обеспечивает немного более высокую производительность. Кроме того, изменились рекомендации по размерам блоков чередования /hana/log с 32 КБ до 64 КБ, которые позволяют обеспечить достаточную пропускную способность с большим объемом операций ввода-вывода.

Примечание.

Настраивать уровень избыточности с помощью томов RAID не требуется, так как блочные хранилища Azure хранят три образа виртуального жесткого диска. Использование чередующегося набора с дисками Azure уровня "Премиум" заключается в настройке томов, обеспечивающих достаточную пропускную способность операций ввода-вывода и (или) объем операций ввода-вывода в секунду.

Накопление нескольких дисков Azure под набором полосовых модулей накапливается с стороны операций ввода-вывода в секунду и пропускной способности хранилища. Таким образом, если вы помещаете полосу на более чем 3 x P30 дисков хранилища Azure уровня "Премиум" версии 1, она должна дать вам три раза больше операций ввода-вывода в секунду и три раза пропускную способность хранилища одного диска Azure уровня "Премиум" служба хранилища версии 1 P30.

Внимание

Если вы используете LVM или mdadm в качестве диспетчера томов для создания наборов полос на нескольких дисках Azure premium, три файловых системы SAP HANA /data, /log и /shared не должны быть помещены в группу томов по умолчанию или корневой тома. Настоятельно рекомендуется следовать рекомендациям поставщиков Linux, которые обычно создают отдельные группы томов для /data, /log и /shared.

Рекомендации по ОБЩЕЙ файловой системе HANA

При изменении размера файловой системы HANA большинство внимания уделяется системам данных и файлов журнала HANA. Однако /hana/shared также играет важную роль в работе стабильной системы HANA, так как она размещает важные компоненты, такие как двоичные файлы HANA.
Если операции чтения и записи недостаточно, /hana/shared могут стать насыщенными из-за чрезмерных операций чтения и записи, например при записи большого дампа или во время интенсивной трассировки, или при записи резервного копирования в файловую систему /hana/shared . Задержка также может увеличиться.

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

Рекомендации ПО SAP для рекомендуемых размеров /hana/shared будут выглядеть следующим образом:

Громкость Рекомендуемый размер
/hana/shared с вертикальным увеличением масштаба Мин. (1 ТБ, 1 x ОЗУ)
/hana/shared с горизонтальным увеличением масштаба 1 x ОЗУ на рабочий узел
на четыре рабочих узла

Дополнительные сведения см. в следующих заметках SAP:
3288971. Вопросы и ответы: SUSE HAE/RedHat HAA Pacemaker Cluster Manager в средах репликации системы SAP HANA
1999930. Вопросы и ответы: анализ операций ввода-вывода SAP HANA

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

Конфигурации Azure хранилище класса Premium версии 1 для HANA

Подробные рекомендации по настройке хранилища HANA с помощью хранилища Azure уровня "Премиум" версии 1 см. в документе конфигурации хранилища SSD sap HANA Azure уровня "Премиум".

Конфигурации SSD уровня "Премиум Azure" версии 2 для HANA

Подробные рекомендации по настройке хранилища HANA с помощью хранилища ssd azure уровня "Премиум" версии 2 см. в документе конфигурации хранилища SSD версии 2 для SAP HANA Azure уровня "Премиум".

Конфигурации хранилища Azure категории "Ультра" для SAP HANA

Подробные рекомендации по настройке хранилища HANA с помощью диска Azure "Ультра" см. в документе конфигурации хранилища виртуальных машин SAP HANA Azure "Ультра".

Тома NFS версии 4.1 на Azure NetApp Files

Дополнительные сведения о ANF для HANA см. в томах документа NFS версии 4.1 в Azure NetApp Files для SAP HANA.

Дальнейшие действия

Дополнительные сведения см. в разделе: