Поделиться через

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

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

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

Внимание

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

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

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

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

Так как небольшая задержка хранилища для систем СУБД является критической, даже такие системы, как SAP HANA, хранят данные в памяти. Критический путь в хранилище обычно находится рядом с записями журналов транзакций систем СУБД. Кроме того, такие операции, как запись точек сохранения или загрузка данных в памяти после восстановления из-за сбоя, могут быть критическими. Поэтому для томов /hana/data и /hana/log очень важно использовать диски Azure Premium SSD версии v1/v2, Ultra Disk или Azure NetApp Files NFS.

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

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

Внимание

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

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

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

Считывая подробные сведения, очевидно, что применение этой функции отнимает сложности наборов полос на основе диспетчера томов. Вы также осознаёте, что секционирование томов данных HANA подходит не только для блочного хранилища Azure, например Azure Premium SSD версии 1/версии 2. Данные функциональные возможности можно также использовать для чередования общих папок 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 типа "Премиум" заключается в настройке томов, обеспечивающих достаточную пропускную способность операций ввода-вывода и/или IOPS.

Аккумулирование нескольких дисков Azure в наборе полос увеличивает значения операций ввода-вывода в секунду (IOPS) и пропускную способность хранилища. Таким образом, если вы создадите набор полос из 3 дисков P30 Azure Premium SSD v1, это даст вам втрое больше операций ввода-вывода в секунду и втрое больше пропускной способности хранилища по сравнению с одним диском P30.

Внимание

Если вы используете LVM или mdadm в качестве диспетчера томов для создания полосатых наборов на нескольких премиум-дисках Azure, три файловые системы 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 в средах репликации системы SAP HANA
1999930. Вопросы и ответы: анализ операций ввода-вывода SAP HANA

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

Конфигурации Azure Premium SSD v1 для HANA

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

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

Для получения подробных рекомендаций по настройке хранилища HANA с использованием хранилища Azure Premium SSD версии 2, прочтите документ Конфигурации хранилища Azure Premium SSD v2 для виртуальных машин SAP HANA.

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

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

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

Для получения подробной информации об Azure NetApp Files для HANA, прочитайте документ NFS версии 4.1 тома на Azure NetApp Files для SAP HANA.

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

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

  • Last updated on