Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA

Azure NetApp Files предоставляет собственные общие папки NFS, которые можно использовать для томов /hana/shared, /hana/data и /hana/log . Использование общих папок NFS на основе ANF для томов /hana/data и /hana/log требует использования протокола NFS версии 4.1. Протокол NFS версии 3 не поддерживается для использования томов /hana/data и /hana/log, когда их общие ресурсы основаны на ANF.

Важные замечания

При рассмотрении Azure NetApp Files для SAP Netweaver и SAP HANA следует учитывать следующие важные аспекты:

• Для получения информации об ограничениях пула томов и емкости, см. ресурсные ограничения Azure NetApp Files.

• Общие папки NFS на основе Azure NetApp Files и виртуальные машины, которые подключают эти общие папки, должны находиться в одной виртуальной сети Azure или в одноранговых виртуальных сетях в одном регионе.

• Выбранная виртуальная сеть должна содержать подсеть, делегированную Azure NetApp Files. Для рабочей нагрузки SAP настоятельно рекомендуется настроить диапазон /25 для подсети, делегированной Azure NetApp Files.

• Важно, чтобы виртуальные машины были развернуты достаточно близко к хранилищу Azure NetApp для снижения задержки, например, как требует SAP HANA для записи повторных логов.

  • Azure NetApp Files между тем имеет функциональные возможности для развертывания томов NFS в определенных зонах доступности Azure. Такая зональная близость будет достаточной в большинстве случаев для достижения задержки менее 1 миллисекунда. Эта функция доступна в общедоступной предварительной версии и описана в статье "Управление размещением томов зоны доступности" для Azure NetApp Files. Эта функция не требует интерактивного процесса с корпорацией Майкрософт для обеспечения близости между виртуальной машиной и выделенными томами NFS.
  • Для достижения наиболее оптимальной близости предоставляются функциональные возможности групп томов приложений. Эта функция не только ищет наиболее оптимальную близость, но и наиболее оптимальное размещение томов NFS, чтобы данные HANA и тома журналов повторного выполнения обрабатывались различными контроллерами. Недостаток заключается в том, что этот метод требует интерактивного процесса с корпорацией Майкрософт для закрепления ваших виртуальных машин.

• Убедитесь, что задержка от сервера базы данных до тома Azure NetApp Files измеряется и меньше 1 миллисекунды.

• Пропускная способность тома Azure NetApp — это функция квоты тома и уровня обслуживания, как описано на уровне обслуживания для Azure NetApp Files. При изменении размера томов HANA Azure NetApp убедитесь, что полученная пропускная способность соответствует требованиям к системе HANA. Кроме того, рассмотрите возможность использования руководящего пула емкости QoS, где емкость volumes и пропускную способность можно настроить и масштабировать независимо (особые примеры для SAP HANA содержатся в этом документе).

• Постарайтесь объединить тома, чтобы повысить производительность в более крупном томе, например, используйте один том для /sapmnt, /usr/sap/trans, ... Если это возможно

• Azure NetApp Files предлагает политику экспорта: можно управлять разрешенными клиентами и типом доступа (чтение и запись, только чтение и т. д.).

• Идентификатор пользователя для sidadm и идентификатор группы для sapsys на виртуальных машинах должны соответствовать конфигурации в Azure NetApp Files.

• Реализация параметров ОС Linux, упомянутых в заметке SAP 3024346

Параметр подключения NCONNECT

Nconnect — это параметр подключения томов NFS, размещенных в Azure NetApp Files, который позволяет клиенту NFS открывать несколько сеансов для одного тома NFS. Использование nconnect с значением больше 1 также активирует клиент NFS для использования нескольких сеансов RPC на стороне клиента (в гостевой ОС) для обработки трафика между гостевой ОС и подключенными томами NFS. Использование нескольких сеансов, обрабатываемых трафиком одного тома NFS, но и использование нескольких сеансов RPC может решать такие сценарии производительности и пропускной способности, как:

• Подключение нескольких томов NFS, размещенных в Azure NetApp Files, с различными уровнями обслуживания на одной виртуальной машине
• Максимальная пропускная способность записи для тома и одного сеанса Linux составляет от 1,2 до 1,4 ГБ/с. Наличие нескольких сеансов для одного тома NFS, размещенного в Azure NetApp Files, может увеличить пропускную способность.

Для выпусков ОС Linux, поддерживающих nconnect в качестве опции подключения и некоторые важные аспекты настройки nconnect, особенно с различными конечными точками сервера NFS, ознакомьтесь с документом Лучшие практики подключения Linux NFS для Azure NetApp Files.

Определение размеров базы данных HANA в Azure NetApp Files

Пропускная способность тома Azure NetApp — это функция размера тома и уровня обслуживания, как описано на уровнях обслуживания для Azure NetApp Files.

Важно понимать, как размер влияет на производительность и что существуют физические ограничения для конечной точки хранилища службы. Каждая конечная точка хранилища будет динамически внедряться в делегированную подсеть Azure NetApp Files при создании тома и получать IP-адрес. Тома Azure NetApp Files могут (в зависимости от доступной емкости и логики развертывания) совместно использовать конечную точку хранилища.

В приведенной ниже таблице показано, что можно создать большой том "Стандартный" для хранения резервных копий и что не имеет смысла создать том "Ультра" размером более 12 ТБ, так как максимальная физическая пропускная способность одного тома будет превышена.

Если требуется больше максимальной пропускной способности записи для тома /hana/data , чем один сеанс Linux, можно также использовать секционирование томов данных SAP HANA в качестве альтернативы. Секционирование тома данных SAP HANA распределяет нагрузку ввода-вывода во время перезагрузки данных или создания точек сохранения HANA по нескольким файлам данных HANA, расположенным на нескольких сетевых ресурсах NFS. Дополнительные сведения о разметке томов данных HANA см. в следующих статьях:

• Руководство администратора HANA
• Блог о SAP HANA — секционирование томов данных
• Примечание SAP #2400005
• Примечание SAP #2700123

¹: ограничения пропускной способности записи или чтения в одном сеансе (если не используется параметр nconnect для монтирования NFS)

Важно понимать, что данные записываются в те же диски SSD в серверной части хранилища. Квота производительности из пула ресурсов была создана для обеспечения возможности управления средой. Ключевые показатели эффективности хранилища равны для всех размеров базы данных HANA. В почти всех случаях это предположение не отражает реальность и ожидания клиента. Размер систем HANA не обязательно означает, что небольшая система требует низкой пропускной способности хранилища, а большая система требует высокой пропускной способности хранилища. Но как правило, мы можем ожидать более высокие требования к пропускной способности для больших экземпляров базы данных HANA. В результате применения правил определения размеров SAP для базового оборудования более крупные экземпляры HANA также обеспечивают больше ресурсов ЦП и более высокий параллелизм в задачах, таких как загрузка данных после перезапуска. В результате размеры томов должны быть адаптированы к клиентским ожиданиям и требованиям. И не только исключительно из требований к емкости.

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

Так как требуются все три ключевых показателя эффективности, объем /hana/data должен быть увеличен до большей емкости для выполнения минимальных требований для чтения. Если вы используете QoS пулы емкости, управляемые вручную, размер и пропускная способность томов могут быть определены независимо. Так как емкость и пропускная способность взяты из одного пула емкости, уровень обслуживания и размер пула должен быть достаточно большим, чтобы обеспечить общую производительность (см. пример здесь).

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

Чтобы удовлетворить минимальные требования к пропускной способности SAP для данных и журналов, и в соответствии с рекомендациями для /hana/shared рекомендуемые размеры будут выглядеть следующим образом:

Для всех томов настоятельно рекомендуется NFS v4.1.
Внимательно изучите рекомендации по размеру /hana/shared, так как правильно настроенный размер тома /hana/shared способствует стабильности системы.

Размеры томов для резервного копирования являются оценочными. Точные требования необходимо определить на основе рабочих нагрузок и процессов операций. Для резервных копий можно объединить множество томов для разных экземпляров SAP HANA до одного (или двух) больших томов, что может иметь более низкий уровень обслуживания Azure NetApp Files.

Поэтому можно рассмотреть возможность развертывания аналогичной пропускной способности для томов Azure NetApp Files, как уже указано для хранилища дисков категории "Ультра". Кроме того, учитывайте размеры, указанные для томов различных моделей SKU виртуальных машин, как уже указано в таблицах дисков категории "Ультра".

Документация о том, как развернуть конфигурацию горизонтального масштабирования SAP HANA с резервным узлом с использованием томов NFS на базе Azure NetApp Files версии NFS v4.1, публикуется в горизонтальная конфигурация SAP HANA с резервным узлом на виртуальных машинах Azure с Azure NetApp Files на SUSE Linux Enterprise Server.

Параметры ядра Linux

Чтобы успешно развернуть SAP HANA в Azure NetApp Files, необходимо реализовать параметры ядра Linux в соответствии с заметками SAP 3024346.

Для систем с высокой доступностью (HA), в которых используются pacemaker и Azure Load Balancer, необходимо реализовать следующие настройки в файле /etc/sysctl.d/91-NetApp-HANA.conf.

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1

Системы, работающие без pacemaker и Azure Load Balancer, должны реализовать эти параметры в файле /etc/sysctl.d/91-NetApp-HANA.conf

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1

Развертывание с зональной близостью

Чтобы получить зональное расположение томов и виртуальных машин NFS, выполните инструкции, описанные в разделе "Управление размещением томов зоны доступности" для Azure NetApp Files. С помощью этого метода виртуальные машины и тома NFS будут находиться в одной зоне доступности Azure. В большинстве регионов Azure этот тип близости должен быть достаточно точным, чтобы достичь задержки менее 1 миллисекунды для более мелких операций записи журнала повторов SAP HANA. Этот метод не требует интерактивной работы с Корпорацией Майкрософт для размещения и закрепления виртуальных машин в определенном центре обработки данных. В результате вы гибки с изменением размеров и семейств виртуальных машин во всех типах и семействах виртуальных машин, предлагаемых в развернутой зоне доступности. Таким образом, вы можете гибко реагировать на изменяющиеся условия или быстрее переключаться на более экономически эффективные размеры или семейства виртуальных машин. Мы рекомендуем этот метод для непроизводственных систем и производственных систем, которые могут работать с задержками журнала повтора, которые ближе к 1 миллисекундам. Функции в настоящее время находятся в общедоступной предварительной версии.

Развертывание с помощью группы томов приложений Azure NetApp Files для SAP HANA (AVG)

Чтобы развернуть тома Azure NetApp Files в непосредственной близости от вашей виртуальной машины, была разработана новая функция - группа томов приложений Azure NetApp Files для SAP HANA (AVG). Существует ряд статей, которые документирует функциональные возможности. Лучше всего начать с чтения статьи Общие сведения о группе томов приложений Azure NetApp Files для SAP HANA. Когда вы читаете статьи, становится ясно, что использование AVGs также включает использование групп близкого размещения Azure. Группы размещения в непосредственной близости используются новой функциональностью для связывания с томами, которые создаются. Чтобы гарантировать, что в течение всего времени существования системы HANA виртуальные машины не будут удалены от томов Azure NetApp Files, рекомендуется использовать сочетание Avset/PPG для каждой зоны, в которых вы развертываете. Порядок развертывания будет выглядеть следующим образом:

• Используйте форму, чтобы запросить закрепление пустого AvSet на вычислительное оборудование и убедиться, что виртуальные машины не будут перемещаться.
• Назначьте PPG набору доступности и запустите виртуальную машину, назначенную этому набору доступности.
• Использование группы томов приложений Azure NetApp Files для функциональных возможностей SAP HANA для развертывания томов HANA

Конфигурация группы размещения близкого взаимодействия для использования AVG оптимально выглядит следующим образом:

На схеме показано, что вы собираетесь использовать группу проксимального размещения Azure для уровня СУБД. Чтобы его можно было использовать вместе с AVG. Лучше всего включить только виртуальные машины, которые запускают экземпляры HANA в группе размещения близкого взаимодействия. Группа размещения близкого взаимодействия необходима, даже если используется только одна виртуальная машина с одним экземпляром HANA, чтобы AVG мог определить ближайшее расположение программного обеспечения Azure NetApp Files. И чтобы выделить том NFS в Azure NetApp Files как можно ближе к виртуальным машинам, использующим тома NFS.

Этот метод создает наиболее оптимальные результаты, так как он связан с низкой задержкой. Не только путем перемещения томов и виртуальных машин NFS максимально близко друг к другу. Однако следует учитывать рекомендации по размещению томов данных и журналов повторного входа на разных контроллерах серверной части NetApp. Однако недостатком является то, что развертывание виртуальной машины закреплено в одном центре обработки данных. При этом вы теряете гибкость в изменении типов и семейств виртуальных машин. В результате этот метод следует ограничить системами, которые абсолютно требуют такой низкой задержки хранения. Для всех других систем следует попытаться выполнить развертывание с помощью традиционного зонального развертывания виртуальной машины и Azure NetApp Files. В большинстве случаев это достаточно с точки зрения низкой задержки. Это также обеспечивает простое обслуживание и администрирование виртуальной машины и Azure NetApp Files.

Availability

Обновления и обновления системы ANF применяются без влияния на среду клиента. Определенное соглашение об уровне обслуживания равно 99,99%.

Тома, IP-адреса и пулы емкости

С помощью ANF важно понять, как создается базовая инфраструктура. Пул емкости — это всего лишь механизм, который предоставляет бюджет емкости и производительности, а также единицу выставления счетов на основе уровня обслуживания пула емкости. Пул емкости не имеет физической связи с базовой инфраструктурой. При создании тома на сервисе создается конечная точка хранилища. Один IP-адрес назначается этой конечной точке хранилища для предоставления доступа к данным на томе. При создании нескольких томов все тома распределяются по базовому пулу физической инфраструктуры, привязанному к этому конечному устройству хранения. AnF имеет логику, которая автоматически распределяет рабочие нагрузки клиентов после того, как тома или емкость настроенного хранилища достигает внутреннего предварительно определенного уровня. Вы можете заметить такие случаи, так как новая конечная точка хранилища с новым IP-адресом создается автоматически для доступа к томам. Служба ANF не предоставляет клиенту контроль над этой логикой распространения.

Том журнала и том резервного копирования журналов

Для записи журнала онлайн-переделки используется том журнала (/hana/log). Таким образом, в этом томе расположены открытые файлы, и нет смысла делать снапшот этого тома. Онлайн-журналы повторного входа архивируются или резервируются на том носителе резервного копирования журнала после заполнения онлайн-журнала повторного входа или выполнения резервного копирования журнала. Для обеспечения разумной производительности резервного копирования том журнала требует хорошей пропускной способности. Чтобы оптимизировать затраты на хранение, можно объединить объем резервного копирования лог-файлов нескольких инстансов HANA. Таким образом, несколько экземпляров HANA используют один и тот же том и записывают резервные копии в разные каталоги. С помощью такой консолидации можно добиться большей пропускной способности, так как необходимо увеличить размер тома.

Это же касается тома, на который вы записываете полные резервные копии базы данных HANA.
 

Backup

Помимо резервных копий в реальном времени и службы Azure Backup, выполняющей резервное копирование баз данных SAP HANA, как описано в руководстве по резервному копированию SAP HANA на виртуальных машинах Azure, Azure NetApp Files открывает возможность создания резервных копий моментальных снимков хранилища.

SAP HANA поддерживает:

• Поддержка резервного копирования моментальных снимков на основе хранилища для системы с одним контейнером с SAP HANA 1.0 SPS7 и выше.
• Поддержка резервного копирования моментальных снимков на основе хранилища для сред HANA с несколькими базами данных (MDC) с одним клиентом с SAP HANA 2.0 с пакетом обновления 1 (SPS1) и выше
• Поддержка резервного копирования моментальных снимков на базе хранилища для сред вашего многобазового контейнера HANA (MDC) с несколькими арендаторами с SAP HANA 2.0 SPS4 и более поздних версий.

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

1. Действие, которое необходимо выполнить — создание моментального снимка внутренней базы данных HANA, либо это нужно сделать инструментами.
2. SAP HANA записывает данные в датафайлы для создания согласованного состояния в хранилище. HANA выполняет этот шаг после создания моментального снимка HANA.
3. Создайте моментальный снимок на томе /hana/data в хранилище — шаг, который необходимо выполнить. Нет необходимости выполнять моментальный снимок для тома /hana/log
4. Удалите моментальный снимок внутренней базы данных HANA и возобновите нормальную работу — это шаг, который необходимо выполнить вами или инструментами.

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname 

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

Эта процедура резервного копирования моментальных снимков может управляться различными способами с помощью различных средств.

Доступные решения для резервного копирования, согласованного с приложениями, на основе моментальных снимков хранилища:

• Microsoft What is Azure Application Consistent Snapshot tool — это средство командной строки, которое обеспечивает защиту данных для сторонних баз данных. Он осуществляет всю оркестровку, необходимую для того, чтобы привести базы данных в согласованное с приложением состояние перед созданием снимка данных хранилища. После создания моментального снимка хранилища средство возвращает базы данных в рабочее состояние. AzAcSnap поддерживает резервное копирование на основе моментальных снимков для больших экземпляров системы HANA и файлов Azure NetApp. Дополнительные сведения см. в статье "Что такое средство моментального снимка с согласованием приложений Azure"
• Для пользователей продуктов резервного копирования Commvault можно использовать Commvault IntelliSnap V.11.21 и более поздних версий. Эта или более поздняя версия Commvault предлагает поддержку моментальных снимков Azure NetApp Files. Дополнительные сведения см. в статье Commvault IntelliSnap 11.21 .

Резервное копирование моментального снимка с использованием хранилища BLOB Azure

Резервное копирование в хранилище Azure Blob — это экономичный и быстрый способ сохранения резервных копий моментальных снимков хранилища базы данных HANA, основанного на ANF. Чтобы сохранить моментальные снимки в Blob-хранилище Azure, рекомендуется использовать средство AzCopy. Скачайте последнюю версию этого средства и установите его, например, в каталоге bin, где установлен скрипт Python из GitHub. Скачайте последнее средство AzCopy:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

Самая расширенная функция — это параметр SYNC. Если вы используете параметр SYNC, azcopy поддерживает синхронизацию между исходным и целевым каталогами. Важно использовать параметр --delete-destination . Без этого параметра azcopy не удаляет файлы на целевом сайте, а использование пространства на конечной стороне увеличится. Создайте контейнер блочных BLOB-объектов в учетной записи хранения Azure. Затем создайте ключ SAS для контейнера BLOB-объектов и синхронизируйте папку моментального снимка с контейнером BLOB-объектов Azure.

Например, если ежедневный моментальный снимок должен быть синхронизирован с контейнером BLOB Azure для защиты данных. Следует оставить только один моментальный снимок, для этого можно использовать следующую команду.

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

Дальнейшие шаги

Ознакомьтесь со статьей:

• Высокий уровень доступности SAP HANA для виртуальных машин Azure