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

Принципы и процессы подготовки аварийного восстановления

  • Статья

В этой статье мы обсудим важные принципы аварийного восстановления (DR) для решения "SAP HANA на крупных экземплярах" (также известно как BareMetal Infrastructure). Мы предоставим вам пошаговые инструкции по подготовке к аварийному восстановлению. Кроме того, вы узнаете, как добиться требуемых показателей RTO (целевое время восстановления) и RPO (целевая точка восстановления) в случае аварии.

Принципы DR для крупных экземпляров HANA

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

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

Конфигурация установки аварийного восстановления с точки зрения диска

Как показано на этом изображении, вам нужно упорядочить второй набор томов диска. Целевые тома диска, сопоставленные с сервером крупных экземпляров HANA на сайте DR, имеют такой же размер, как и в рабочей среде.

Следующие тома реплицируются из рабочего региона на сайт аварийного восстановления:

  • hana/data;
  • /hana/logbackups;
  • /hana/shared (включая /usr/sap).

Том /hana/log не реплицируется. При восстановлении из этих томов журнал транзакций SAP HANA не требуется.

Репликация хранилища для крупных экземпляров HANA

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

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

В случае развертывания MCOD с несколькими независимыми экземплярами SAP HANA в одном крупном экземпляре HANA ожидается, что хранилища всех экземпляров SAP HANA реплицируются в хранилище на стороне DR.

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

Примечание

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

Подготовка сценария аварийного восстановления

В этом сценарии DR требуется система для рабочей среды, работающая на крупных экземплярах HANA в регионе Azure для рабочей среды. Чтобы применить сведения ниже, предположим, что идентификатор безопасности этой системы HANA — PRD, и вы имеете нерабочую систему, выполняющуюся на HANA (крупные экземпляры) в регионе аварийного восстановления Azure. Его идентификатор безопасности — "TST". Конфигурация будет выглядеть следующим образом:

Запуск настройки аварийного восстановления

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

Следующий шаг по настройке аварийного восстановления

Далее необходимо установить второй экземпляр SAP HANA на крупном экземпляре HANA в регионе DR Azure, где запущен экземпляр HANA "TST". Новый установленный экземпляр SAP HANA должен содержать один идентификатор безопасности. У созданных пользователей должен быть тот же идентификатор пользователя и группы, что и в экземпляре для рабочей среды. Дополнительные сведения о резервном копировании и восстановлении см. здесь. Если установка завершилась успешно, переходите к следующим действиям:

  • Выполнить шаг 2 из процесса подготовки моментального снимка хранилища, как описано в статье Архивация и восстановление.
  • Создайте открытый ключ для единицы крупного экземпляра HANA на сайте DR, если вы еще не сделали этого. См. шаг 3 процесса подготовки моментального снимка хранилища в статье Архивация и восстановление.
  • Использовать HANABackupCustomerDetails.txt с новым экземпляром HANA и проверить правильность подключения к хранилищу.
  • Остановите работу только что установленного экземпляра SAP HANA на крупном экземпляре HANA в регионе DR Azure.
  • Отключить эти тома PRD и обратиться в службу поддержки решения SAP HANA для управления службами Azure. Тома не могут оставаться подключенными к единице, так как в этом случает они будут недоступны при использовании в качестве целевого объекта репликации хранилища.

Схема отношений репликации между томами PRD в рабочем регионе Azure и томами PRD в регионе аварийного восстановления Azure.

Рабочая группа установит отношение репликации между томами PRD в регионе рабочей среды и томами PRD в регионе DR.

Важно!

Том /hana/log не будет реплицироваться, так как нет необходимости восстанавливать реплицированную базу данных SAP HANA до согласованного состояния на сайте аварийного восстановления.

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

  • Тома, охватываемые объединенным моментальным снимком (типа hana), реплицируются каждые 15 минут на эквивалентные целевые тома хранилища на сайте аварийного восстановления.
  • Тома резервных копий журналов транзакций (типа logs) реплицируются каждые 3 минуты на эквивалентные целевые тома хранилища на сайте аварийного восстановления.

Чтобы уменьшить значение RPO:

При такой конфигурации последовательность создания резервных копий журналов транзакций, моментальных снимков хранилища, а также репликации тома резервных копий журналов транзакций HANA и томов hana/data и /hana/shared (в том числе /usr/sap) может выглядеть, как показано на рисунке.

Связь между созданием и зеркальным отображением моментального снимка резервной копии журналов транзакций по оси времени

Чтобы еще больше улучшить значение целевой точки восстановления в случае аварийного восстановления, можно скопировать резервные копии журналов транзакций HANA из SAP HANA в Azure (крупные экземпляры) в другой регион Azure. Чтобы дополнительно уменьшить значение RPO, выполните следующие действия:

  1. Выполняйте резервное копирование журналов транзакций HANA на том /hana/logbackups с максимально возможной частотой.
  2. С помощью команды rsync скопируйте резервные копии журнала транзакций в общий ресурс NFS, размещенный на виртуальных машинах Azure. Виртуальные машины находятся в виртуальных сетях Azure в регионе Azure для рабочей среды и регионе DR. Подключите обе виртуальные сети Azure к каналу, соединяющему крупные экземпляры HANA для рабочей среды в Azure. Дополнительные сведения см. в статье Рекомендации по сети для аварийного восстановления с помощью крупных экземпляров HANA.
  3. Храните резервные копии журналов транзакций в том же регионе, где размещается виртуальная машина, подключенная к экспортированному хранилищу NFS.
  4. В случае аварийной отработки отказа дополните резервные копии журналов транзакций, хранящиеся на томе /hana/logbackups, более новыми резервными копиями журналов транзакций из общедоступного ресурса NFS на сайте DR.
  5. Теперь можно начать восстановление резервной копии журналов транзакций до последней резервной копии, которую удалось сохранить в регионе аварийного восстановления.

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

Шаг по настройке аварийного восстановления перед установкой репликации

В ходе репликации моментальные снимки томов PRD в регионах DR Azure только сохраняются, но не восстанавливаются. При таком подключении томов их состояние воспроизводит состояние на момент отключения этих томов после установки экземпляра SAP HANA PRD на сервере в регионе DR Azure. Кроме того, они предоставляют еще не восстановленные резервные копии хранилища.

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

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

Изучите процесс отработки отказа при аварийном восстановлении.

Процедура отработки отказа при аварийном восстановлении