Тома 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.

Внимание

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

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

При выборе Azure NetApp Files для SAP NetWeaver и SAP HANA стоит учитывать следующие важные моменты.

  • Минимальный размер пула емкости равен 4 ТиБ

  • Минимальный размер тома составляет 100 ГиБ.

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

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

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

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

  • Убедитесь, что задержка от сервера базы данных до тома ANF измеряется и меньше 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.

Внимание

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

Внимание

В случае несоответствия между идентификатором пользователя sidadm и идентификатором группы для sapsys между виртуальной машиной и конфигурацией Azure NetApp, разрешения для файлов на томах NetApp в Azure, подключенных к виртуальным машинам, будут отображаться как nobody. Убедитесь, что указали правильный идентификатор пользователя для sidadm и правильный идентификатор группы для sapsys во время установки новой системы в среде Azure NetApp Files.

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

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

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

Для выпусков ОС 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 см. в следующих статьях:

Размер Пропускная способность (цен. категория "Стандартный") Пропускная способность (цен. категория "Премиум") Пропускная способность (цен. категория "Ультра")
1 TБ 16 Мбит/с 64 Мбит/с 128 Мбит/с
2 ТБ 32 Мбит/с 128 Мбит/с 256 Мбит/с
4 ТБ 64 Мбит/с 256 Мбит/с 512 Мбит/с
10 ТБ 160 Мбит/с 640 Мбит/с 1280 Мбит/с
15 ТБ 240 Мбит/с 960 Мбит/с 1400 Мбит/с1
20 TБ 320 Мбит/с 1280 Мбит/с 1400 Мбит/с1
40 ТБ 640 Мбит/с 1400 Мбит/с1 1400 Мбит/с1

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

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

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

Тип тома и тип ввода-вывода Минимальный ключевой показатель эффективности, требуемый SAP Уровень обслуживания (цен. категория "Премиум") Уровень обслуживания (цен. категория "Ультра")
Запись тома журнала 250 МБ/с 4 ТБ 2 ТБ
Запись тома данных 250 МБ/с 4 ТБ 2 ТБ
Чтение тома данных 400 МБ в секунду 6,3 ТБ 3,2 ТБ

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

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

Внимание

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

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

Громкость Размер
Хранилище класса "Premium"		 Размер
Хранилище класса "Ультра"		 Поддерживаемый протокол NFS
/hana/log/ 4 ТиБ 2 ТиБ Версия 4.1
/hana/data 6.3 ТиБ 3.2 ТиБ Версия 4.1
/hana/shared с вертикальным увеличением масштаба Мин. (1 ТБ, 1 x ОЗУ) Мин. (1 ТБ, 1 x ОЗУ) Версия 3 или версия 4.1
/hana/shared с горизонтальным увеличением масштаба 1 x ОЗУ на рабочий узел
на четыре рабочих узла		 1 x ОЗУ на рабочий узел
на четыре рабочих узла		 Версия 3 или версия 4.1
/hana/logbackup 3 x ОЗУ 3 x ОЗУ Версия 3 или версия 4.1
/hana/backup 2 x ОЗУ 2 x ОЗУ Версия 3 или версия 4.1

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

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

Примечание.

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

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

Совет

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

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

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

Чтобы успешно развернуть SAP HANA в ANF, необходимо реализовать параметры ядра 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)

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

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

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

Группа томов приложения Azure NetApp Files и архитектура группы размещения близкого взаимодействия.

На схеме показано, что вы будете использовать группу размещения близкого взаимодействия Azure для уровня DBMS. Таким образом, он может использоваться вместе с AVG. Лучше всего включить только виртуальные машины, которые запускают экземпляры HANA в группе размещения близкого взаимодействия. Эта группа размещения необходима, даже если используется только одна виртуальная машина с одним экземпляром HANA, чтобы AVG определял ближайшее размещение к оборудованию ANF и выделил том NFS в ANF как можно ближе к виртуальным машинам, использующим тома NFS.

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

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 (внутренний) и возобновить нормальную работу — шаг, который необходимо выполнить

Предупреждение

Отсутствие последнего шага или неуспешное выполнение последнего шага оказывает серьезное влияние на потребность в памяти SAP HANA и может привести к сбою SAP HANA

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

Резервное копирование моментальных снимков ANF для SAP HANA

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

Резервное копирование моментальных снимков ANF для SAP HANA, ч. 2

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. Это пример кода, предоставленный "как есть", без какого-либо обслуживания или поддержки.

Внимание

Моментальный снимок сам по себе не является защищенной резервной копией, пока он находится в том же физическом хранилище, что и том, на котором вы только что сделали моментальный снимок. Обязательно следует "защищать" по крайней мере один моментальный снимок в день в другом расположении. Это можно сделать в той же среде, в удаленном регионе Azure или в Хранилище BLOB-объектов Azure.

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

  • 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

Следующие шаги

См.