Тома 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, но и для наиболее оптимального размещения томов NFS, поэтому данные HANA и тома журнала повторного входа обрабатываются различными контроллерами. Недостаток заключается в том, что этому методу требуется интерактивный процесс с корпорацией Майкрософт для закрепления виртуальных машин.

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

• Пропускная способность тома Azure NetApp является функцией квоты тома и уровня обслуживания, как описано в статье Уровни обслуживания для Azure NetApp Files. При определении размера томов HANA в Azure NetApp убедитесь, что полученная пропускная способность соответствует требованиям к системе HANA. В качестве альтернативы можно использовать управляемый вручную пул емкости QoS, где емкость и пропускную способность тома можно настроить и масштабировать независимо (конкретные примеры для 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

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

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

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

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

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

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

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

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

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

Документация по развертыванию конфигурации горизонтального масштабирования SAP HANA с резервным узлом с помощью томов NFS на основе Azure NetApp Files версии 4.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. Этот метод не требует интерактивной работы с Корпорацией Майкрософт для размещения и закрепления виртуальных машин в определенном центре обработки данных. В результате вы гибки с изменением размеров и семейств виртуальных машин во всех типах и семействах виртуальных машин, предлагаемых в развернутой зоне доступности. Таким образом, вы можете реагировать на гибкие условия chanign или быстрее переходить к более экономичным размерам или семействам виртуальных машин. Мы рекомендуем этот метод для непроизводственных систем и производственных систем, которые могут работать с задержками журнала повтора, которые ближе к 1 миллисекундам. Функциональная возможность сейчас доступна в режиме общедоступной предварительной версии.

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

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

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

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

На схеме показано, что вы будете использовать группу размещения близкого взаимодействия Azure для уровня DBMS. Таким образом, он может использоваться вместе с AVG. Лучше всего включить только виртуальные машины, которые запускают экземпляры HANA в группе размещения близкого взаимодействия. Группа размещения близкого взаимодействия необходима, даже если используется только одна виртуальная машина с одним экземпляром HANA, чтобы определить ближайшее расположение оборудования 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.
 

Резервное копирование

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

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

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

Создание резервных копий моментальных снимков на основе хранилища — это простая 4-шаговая процедура.

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';

Этой процедурой резервного копирования моментальных снимков можно управлять разными способами, используя разные средства. Одним из примеров является скрипт Python "ntaphana_azure.py", доступный на сайте GitHub https://github.com/netapp/ntaphana. Это пример кода, предоставленный "как есть", без какого-либо обслуживания или поддержки.

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

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

Резервное копирование моментального снимка с помощью Хранилища BLOB-объектов Azure

Резервное копирование в Хранилище BLOB-объектов Azure является экономичным и быстрым методом сохранения резервных копий моментальных снимков хранилища базы данных 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’

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

Например, если моментальный снимок ежедневно должен быть синхронизирован с контейнером больших двоичных объектов 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