Добавьте тома для системы SAP HANA в качестве системы аварийного восстановления, используя репликацию между регионами.

В этой статье описывается использование группы томов приложения для добавления томов в систему SAP HANA в качестве системы аварийного восстановления (DR). Эта конфигурация использует функции репликации Azure NetApp Files между регионами (CRR).

CRR между исходными и целевыми серверами HANA

Функциональность Azure NetApp Files по репликации между регионами позволяет вам реплицировать тома между поддерживаемыми парами репликации между регионами. Эта функциональность позволяет реплицировать том из исходного региона в том в целевом регионе для аварийного восстановления (DR).

Вместо использования репликации системы HANA (HSR) можно использовать репликацию между регионами для защиты базы данных без необходимости использовать сервер базы данных HANA, работающий постоянно. Необходимо создать тома назначения репликации в регионе, который поддерживает репликацию между регионами. Группа томов приложений для SAP HANA гарантирует, что конечные тома создаются с правильным типом тома, удовлетворяющим всем требованиям SAP HANA.

На следующей схеме показана межрегиональная репликация между исходными и целевыми серверами HANA. Репликация между регионами асинхронна. Таким образом, не все тома должны быть реплицированы.

Диаграмма, показывающая межрегиональную репликацию между исходным и целевым серверами HANA.

Примечание.

При использовании развертывания высокого уровня доступности с HSR на первичной стороне можно реплицировать не только основную систему HANA, как описано в этом разделе, но и вторичную систему HANA с помощью репликации между регионами. Чтобы автоматически адаптировать соглашение об именовании, выберите параметры вторичного HSR и места назначения аварийного восстановления на экране создания группы томов. Затем префикс изменится на DR2-.

Внимание

Восстановление базы данных HANA в целевом регионе требует использования снимков хранилища, согласованных на уровне приложения, для вашей резервной копии HANA. Вы можете создавать такие моментальные снимки с помощью решений для защиты данных, включая SnapCenter, средство моментальных снимков с согласованием приложений Azure (AzAcSnap) или другие проверенные партнерские решения.
Вам нужно реплицировать, по крайней мере, объем данных и объем резервного копирования журналов.
При необходимости можно реплицировать том резервного копирования данных и общий том.
Вам никогда не следует реплицировать объём журнала. Группа томов для приложений создаст том журнала как стандартный том.

Расписания репликации, RTO и RPO

В следующей таблице перечислены параметры расписания репликации. Он также описывает настройки по умолчанию, предложенные группой томов приложения:

Тип тома	Расписание репликации по умолчанию	Доступные варианты	Примечания.
Данные	Ежедневно	Ежедневно, почасово	Выбор влияет на целевое время восстановления (RTO) и объем передаваемых данных.
Лог	-	-	Журналы томов не реплицируются.
SAP поделилась	Каждые 10 минут	Каждые 10 минут, каждый час, ежедневно	Вы должны выбрать расписание на основе требований соглашения об уровне обслуживания и данных, хранящихся в общем томе.
Резервное копирование данных	Ежедневно	Ежедневно, еженедельно	Копирование томов резервного копирования данных является необязательным.
Резервное копирование журналов	Каждые 10 минут	Каждые 10 минут	Этот параметр влияет на цель точки восстановления (RPO).

Расписание частоты репликации влияет на соглашения об уровне обслуживания:

Цель восстановления времени (RTO):
Минимальное время, которое потребуется для восстановления.
Для восстановления с использованием новейшего доступного моментального снимка, совместимого с приложением, необходимо воспроизвести все доступные резервные копии журналов транзакций. RTO зависит от частоты резервного копирования и частоты репликации томов данных. Например, если частота резервного копирования составляет каждые 6 часов, а расписание репликации — "Ежедневно", то самое старое резервное копирование может быть 30 часов (24 часа + 6 часов). В этом сценарии потребуется воспроизведение резервных копий журналов данных в течение до 30 часов.
Целевая точка восстановления (RPO):
Минимальная потеря данных, которая может произойти.
Частота резервного копирования журналов SAP HANA обычно составляет 15 минут, но этот параметр можно настроить по-разному. При условии 10-минутного расписания репликации резервных копий журналов максимальная потеря транзакции составит [15+10+transfer_time] минут.

Добавление томов

Следующий пример добавляет тома в систему SAP HANA. Система служит в качестве системы назначения для восстановления данных (DR) с использованием межрегиональной репликации.

В учетной записи NetApp выберите томовые группы приложений и нажмите +Добавить группу. Затем в поле "Тип развертывания" выберите SAP HANA и нажмите кнопку "Далее".
На вкладке SAP HANA укажите сведения, относящиеся к HANA.

Внимание

Обязательно выберите вариант назначения аварийного восстановления, чтобы указать, что вы создаете систему HANA в качестве назначения репликации между регионами.
- ИДЕНТИФИКАТОР SAP (SID):
  трехбуквенно-цифровой идентификатор системы SAP HANA.
- Имя группы:
  Название группы томов.
- Память узла SAP:
  Это значение определяет размер базы данных SAP HANA на узле. Он используется для вычисления требуемых объемов и пропускной способности.
- Затраты на емкость (%):
  При использовании моментальных снимков для защиты данных необходимо запланировать дополнительную емкость. Это поле добавляет дополнительный размер (%) для тома данных.
  Это значение можно оценить с помощью "change rate per day" X "number of days retention".
- Единичный хост:
  Выберите этот параметр для системы SAP HANA с одним узлом или первого узла для системы с несколькими узлами. Только общие, журнальные резервные копии и резервные копии данных создаются с первым узлом.
- Несколько хостов:
  Выберите этот параметр, если вы добавляете дополнительные узлы в систему HANA с несколькими узлами.
- Цель аварийного восстановления:
  Выберите этот параметр, чтобы создать тома для системы HANA, предназначенные для использования на сайте аварийного восстановления, с помощью межрегиональной репликации.
  
  Выбор места назначения для аварийного восстановления запускает процесс использования соглашения об именовании для имени группы томов, чтобы указать, что была проведена настройка аварийного восстановления "-DR-".
Нажмите "Далее: группа томов".
На вкладке "Группа томов" укажите сведения о создании группы томов:
- Опция доступности: выберите зону доступности или группу размещения в непосредственной близости. При выборе зоны доступности необходимо выбрать соответствующую зону доступности в следующем поле.
  - Группа размещения в пределах близости (Proximity placement group, PPG)
    Указывает, что данные, журналы и общие тома должны быть созданы поблизости от виртуальных машин.
  - Зона доступности: Этот параметр позволяет развертывать тома в логической зоне доступности, которую вы указываете. Выберите зону доступности, в которой присутствуют ресурсы Azure NetApp Files. Дополнительные сведения см. в разделе Управление размещением томов в зонах доступности.
- Сетевые функции. Стандартные сетевые функции — это значение по умолчанию, однако вы по-прежнему можете использовать базовые сетевые функции. Дополнительные сведения см. в статьях «Настройка сетевых функций для тома» и «Рекомендации по планированию сети Azure NetApp Files».
- Пул емкости:
  Все тома помещены в единый пул емкости с ручным управлением QoS. Если вы хотите создать тома резервных копий журналов и данных в отдельном пуле емкости, вы можете не добавлять эти тома в группу томов.
- Виртуальная сеть.
  Укажите существующую виртуальную сеть, в которой размещаются виртуальные машины.
- Подсеть:
  Укажите делегированную подсеть, в которой создаются IP-адреса для экспорта NFS. Убедитесь, что у вас есть делегированная подсеть с достаточно бесплатными IP-адресами.
Нажмите кнопку "Далее": протоколы.
В разделе "Протоколы" на вкладке "Группа томов" можно изменить политику экспорта, которая должна быть распространена для всех томов.

Нажмите кнопку "Далее" — репликация.
В разделе Replication на вкладке Volume Group по умолчанию в поле Replication Schedule установлено значение "Multiple" (отключено). Расписания репликации по умолчанию отличаются для реплицированных томов. Таким образом, можно изменить расписания репликации только для каждого тома по отдельности на вкладке томов, а не глобально для всей группы томов.

Нажмите кнопку "Далее": теги.
В разделе "Теги" вкладки "Группа томов" можно добавлять теги по мере необходимости для томов.

Выберите Далее: Объёмы.
Вкладка Тома отображает список томов.

Конвенция наименования томов включает префикс "DR-", который указывает, что тома относятся к стороне аварийного восстановления (место назначения) конфигурации.

Вкладка «Тома» также отображает тип тома.
- DP — указывает назначение в настройках репликации между регионами. Тома этого типа не находятся в сети, а находятся в режиме репликации.
- RW — указывает, что разрешены операции чтения и записи.
Тип по умолчанию для тома журнала — RWи параметр не может быть изменен.

Тип по умолчанию для томов данных, общих томов и томов резервного копирования журналов DP, и этот параметр не подлежит изменению.

Тип по умолчанию для тома резервного копирования данных — DP, но этот параметр можно изменить на RW.
Выберите каждый том с типом DP, чтобы указать идентификатор исходного тома. Для получения дополнительной информации см. Locate the source volume resource ID.

При необходимости можно изменить расписание репликации по умолчанию тома. Посмотрите Расписания репликации, RTO и RPO для получения информации о параметрах расписания репликации.
После создания группы томов настройте репликацию, следуя инструкциям в разделе "Авторизация репликации из исходного тома".
1. Скопируйте идентификатор тома ресурса для каждого созданного тома DP.
2. Для каждого исходного тома выберите "Репликация", затем "Авторизовать". Вставьте идентификатор ресурса для каждого соответствующего тома назначения.

Параметры настройки для репликации базы данных SAP HANA с использованием системной репликации HANA для обеспечения высокой доступности

В некоторых ситуациях вы можете захотеть объединить настройку отказоустойчивости (HA) репликации системы HANA с настройкой восстановления после сбоев (DR) с использованием репликации между регионами. В зависимости от конкретного шаблона использования и соглашения об уровне обслуживания (SLA) возможны два варианта настройки репликации. В этом разделе описаны варианты.

Реплицируйте только основные тома базы данных HANA

В этом сценарии роли для первичных и вторичных систем обычно не изменяются. Захват выполняется только в случае экстренной ситуации. Таким образом, резервные копии снимков, согласованные с приложением, необходимые для межрегиональной репликации, создаются в основном на основном хосте. Это связано с тем, что для создания резервной копии можно использовать только основную базу данных HANA.

На следующей схеме описан этот сценарий:

В этом сценарии настройка DR должна включать только тома основной системы HANA. При ежедневной репликации основного тома данных и резервных копий журналов первичных и вторичных систем система может быть восстановлена на сайте аварийного восстановления. На схеме один том используется для резервного копирования журналов первичных и вторичных систем.

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

Рабочий процесс для этого сценария идентичен рабочему процессу добавления томов .

Реплицируйте как основные, так и вторичные тома базы данных HANA

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

На следующей схеме описан этот сценарий:

В этом сценарии может потребоваться реплицировать оба набора томов из основных и вторичных систем HANA, как показано на схеме.

Для создания томов для вторичной цели репликации будет адаптировано соглашение об именовании. Чтобы отличить репликацию первичной и вторичной базы данных, префикс изменяется с DR на DR2 для вторичной системы HANA. За исключением изменения имени, рабочий процесс идентичен рабочему процессу добавления томов .

Примечание.

Подробное обсуждение решения аварийного восстановления для HANA с помощью Azure NetApp Files см. в техническом отчете NetApp TR-4891: аварийное восстановление SAP HANA с помощью Azure NetApp Files. Технический отчет содержит подробные сведения и примеры использования репликации между регионами для SAP HANA в Azure NetApp Files.

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-07-11