Высокий уровень доступности и аварийное восстановление SAP HANA в Azure (крупные экземпляры)

Важно!

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

В этой статье представлен общий обзор высокого уровня доступности (HA) и аварийного восстановления (DR) SAP HANA для крупных экземпляров Azure (т. н. инфраструктура исходного состояния системы). Мы также подробно рассмотрим некоторые требования и рекомендации, относящиеся к высокому уровню доступности и аварийному восстановлению.

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

Высокий уровень доступности и аварийное восстановление

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

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

  • Репликация хранилища — возможность системы хранения данных реплицировать все данные в другой стек крупных экземпляров HANA в другом регионе Azure. SAP HANA работает независимо от этого метода. Эта функция представляет собой механизм аварийного восстановления по умолчанию для HANA (крупные экземпляры).
  • Репликация системы HANAрепликация всех данных SAP HANA в отдельную систему SAP HANA. Репликация данных с определенными интервалами позволяет сократить до минимума целевую точку восстановления. SAP HANA поддерживает асинхронные, выполняющиеся в памяти синхронные и синхронные режимы. Мы советуем использовать синхронный режим только для систем SAP HANA, расположенных в том же центре обработки данных или на расстоянии менее 100 км от него. В текущей архитектуре стеков крупных экземпляров HANA с помощью репликации системы HANA можно обеспечить высокую доступность в одном регионе. Чтобы использовать репликацию системы HANA, нужен сторонний компонент обратного прокси-сервера или маршрутизации для конфигураций аварийного восстановления в другой регион Azure.
  • Автоматическая отработка отказа узла — решение для локального восстановления после сбоя для SAP HANA, используемое в качестве альтернативы репликации системы HANA. Если основной узел становится недоступным, вам нужно настроить один или несколько резервных узлов SAP HANA в режиме развертывания, и SAP HANA автоматически выполнит отработку отказа на резервный узел.

SAP HANA в Azure (крупные экземпляры) предлагается в двух регионах Azure, охватывающих четыре геополитических региона (США, Австралию, Европу и Японию). Два региона в пределах геополитической области, в которых размещены стеки крупных экземпляров HANA, подключены к отдельным выделенным сетевым каналам. Эти каналы используются в процессе репликации моментальных снимков хранилища и обеспечивают методы аварийного восстановления. Репликация не настроена по умолчанию, однако это касается только клиентов, которые заказывают функцию аварийного восстановления. Репликация хранилища зависит от использования моментальных снимков хранилища для крупных экземпляров HANA. Невозможно выбрать регион Azure в качестве региона аварийного восстановления, если он находится в другой геополитической области.

В настоящее время поддерживаются следующие варианты.

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

Сценарий, поддерживаемый крупными экземплярами HANA Вариант обеспечения высокого уровня доступности Вариант аварийного восстановления Комментарии
Один узел Недоступно. Конфигурация выделенного аварийного восстановления,
конфигурация многоцелевого аварийного восстановления.
Автоматическая отработка отказа узла: масштабирование (с ожиданием и без)
включая 1 + 1
Возможно, если резервный узел становится активным.
Переключением ролей управляет HANA.
Конфигурация выделенного аварийного восстановления,
конфигурация многоцелевого аварийного восстановления.
Синхронизация аварийного восстановления с помощью репликации хранилища.
Наборы томов HANA подключены ко всем узлам.
Сайт аварийного восстановления должен иметь такое же число узлов.
Репликация системы HANA Возможно в конфигурации с первичными или вторичными репликами.
В случае отработки отказа вторичная реплика выполняет роль первичной.
Отработку отказа контролируют служба репликации системы HANA и ОС.
Конфигурация выделенного аварийного восстановления,
конфигурация многоцелевого аварийного восстановления.
Синхронизация аварийного восстановления с помощью репликации хранилища.
Аварийное восстановление с помощью репликации системы HANA пока еще невозможно без использования сторонних компонентов.
Отдельный набор томов дисков подключен к каждому узлу.
Только тома дисков вторичной реплики на рабочем сайте реплицируются в расположение аварийного восстановления.
На сайте аварийного восстановления необходим один набор томов.

Под конфигурацией выделенного аварийного восстановления подразумевается конфигурация, в которой единица крупного экземпляра HANA на сайте аварийного восстановления не используется для выполнения другой рабочей нагрузки или непроизводственной системы. Единица является пассивной и развертывается только при выполнении аварийной отработки отказа. Эта настройка не является предпочтительной для большинства клиентов.

См. руководство по поддерживаемым сценариям HLI для получения сведений об Ethernet и изучения макета хранилища для вашей архитектуры.

Примечание

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

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

Дополнительные сведения о высоком уровне доступности SAP HANA см. в следующих источниках о SAP:

Рекомендации по сети для аварийного восстановления с помощью крупных экземпляров HANA

Чтобы воспользоваться преимуществами аварийного восстановления крупных экземпляров HANA, потребуется спроектировать сетевое подключение к двум регионам Azure. Нужно создать канал Azure ExpressRoute с подключением между локальной средой и основным регионом Azure и еще один канал с подключением между локальной средой и регионом аварийного восстановления. Это позволит обеспечить работоспособность в случае возникновения проблемы с регионом Azure, в том числе с расположением маршрутизатора Microsoft Enterprise Edge Router (MSEE).

Можно также подключить все виртуальные сети Azure, подключенные к SAP HANA в Azure (крупные экземпляры) в одном из регионов, к каналу ExpressRoute, который соединяет крупные экземпляры HANA в другом регионе. Благодаря такому перекрестному подключению службы, работающие в виртуальной сети Azure в регионе 1, могут подключаться к единицам крупных экземпляров HANA в регионе 2 и наоборот. Это позволит устранить проблемы при выходе из обслуживания одного из расположений MSEE, используемых для установки подключения между локальным расположением и Azure.

На рисунке ниже показаны варианты отказоустойчивой конфигурации аварийного восстановления:

Оптимальная конфигурация для аварийного восстановления

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

  • Закажите номера SKU для SAP HANA в Azure (крупные экземпляры) того же размера, что и рабочие номера SKU, и разверните их в регионе аварийного восстановления. На данный момент в клиентских развертываниях эти экземпляры используются для запуска непроизводственных экземпляров HANA. Эти конфигурации называются конфигурациями многоцелевого аварийного восстановления.
  • Закажите дополнительный объем хранилища на сайте аварийного восстановления для каждого номера SKU решения "SAP HANA в Azure (крупные экземпляры)", который вы хотите восстановить на сайте аварийного восстановления. Приобретение дополнительного объема позволит выделить тома хранилища. Вы сможете выделить тома, используемые при репликации хранилища из рабочего региона Azure в регион Azure аварийного восстановления.
  • На сайте аварийного восстановления может быть настроена репликация системы SAP HANA с сайтом аварийного восстановления на уровне основного узла и узла-реплики на основе хранилища. Затем необходимо приобрести дополнительное пространство хранилища на сайте аварийного восстановления, чтобы данные как основного, так и дополнительного узлов реплицировались на сайт аварийного восстановления.

Дальнейшие действия

Сведения о резервном копировании и восстановлении SAP HANA в крупных экземплярах HANA