Доступность SAP HANA в разных регионах Azure

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

Почему развертывание в нескольких регионах Azure

Регионы Azure часто разделяются большими расстояниями. В зависимости от геополитического региона расстояние между регионами Azure может составлять сотни миль или даже несколько тысяч миль, как и в Соединенных Штатах. Из-за расстояния сетевой трафик между ресурсами, развернутыми в двух разных регионах Azure, имеет значительную задержку обхода сети. Задержка достаточно важна, чтобы исключить синхронный обмен данными между двумя экземплярами SAP HANA в типичных рабочих нагрузках SAP.

С другой стороны, организации часто имеют требование расстояния между расположением основного центра обработки данных и вторичным центром обработки данных. Требование расстояния помогает обеспечить доступность в случае стихийных бедствий в более широком географическом расположении. Примерами являются ураганы, которые обрушились на Карибский бассейн и Флориду в сентябре и октябре 2017 года. У вашей организации может быть по крайней мере минимальное требование расстояния. Для большинства клиентов Azure минимальное определение расстояния требует разработки для обеспечения доступности в разных регионах Azure. Так как расстояние между двумя регионами Azure слишком велико, чтобы использовать режим синхронной репликации HANA, требования RTO и RPO могут потребовать развертывания конфигураций доступности в одном регионе, а затем дополнить развертываниями во втором регионе.

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

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

Простая доступность между двумя регионами Azure

Вы можете не размещать конфигурацию доступности в одном регионе, но по-прежнему требовать, чтобы рабочая нагрузка обслуживалася, если происходит авария. Типичными случаями для таких сценариев являются непроизводственные системы. Хотя система может не работать полдня или даже целый день, вы не можете допустить, чтобы она была недоступной в течение 48 часов или более. Чтобы сделать настройку менее затратной, запустите другую систему, которая еще менее важна на виртуальной машине. Другая система служит в качестве пункта назначения. Вы также можете уменьшить размер виртуальной машины в дополнительном регионе и не загружать данные. Так как отработка отказа выполняется вручную и включает в себя множество дополнительных шагов для отработки отказа полного стека приложений, дополнительное время завершения работы виртуальной машины, изменение его размера, а затем перезапуск виртуальной машины является приемлемым.

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

• Существует два режима работы с delta_datashipping и logreplay, которые доступны для такого сценария.
• Оба режима операций имеют разные требования к памяти без предварительной загрузки данных
• Delta_datashipping может потребоваться значительно меньше памяти без параметра предварительной загрузки, чем может потребоваться logreplay. См. главу 4.3 документа SAP о том, как выполнять репликацию системы для SAP HANA
• Требование к памяти режима операции logreplay без предварительной загрузки не является детерминированным и зависит от загруженных структур columnstore. В крайних случаях вам может потребоваться 50% памяти основного экземпляра. Память для режима работы logreplay независима от того, выбрана ли предварительная загрузка данных или нет.

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

Объединение доступности в одном регионе и между регионами

Сочетание доступности в пределах и между регионами может быть обусловлено следующими факторами:

• Требование RPO=0 в регионе Azure.
• Организация не готова или не может иметь глобальные операции, затронутые крупной природной катастрофой, которая влияет на более крупный регион. Так было для некоторых ураганов, которые обрушились на Карибский бассейн в последние несколько лет.
• Правила, требующие расстояния между основными и вторичными сайтами, которые явно выходят за рамки того, что могут предоставлять зоны доступности Azure.

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

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

Если у организации есть требования к высокой доступности во втором регионе Azure(DR), архитектура будет выглядеть следующим образом:

Используя logreplay в качестве режима работы, эта конфигурация предоставляет RPO=0 с низким уровнем RTO в основном регионе. Конфигурация также обеспечивает достойный RPO, если предполагается переход во второй регион. Время RTO во втором регионе зависит от того, предварительно загружаются ли данные. Многие клиенты используют виртуальную машину в дополнительном регионе для запуска тестовой системы. В этом случае данные не могут быть предварительно загружены.

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

Пошаговое руководство по настройке этих конфигураций в Azure см. в следующих статьях:

• Высокий уровень доступности SAP HANA на виртуальных машинах Azure
• Your SAP on Azure – Part 4 – High Availability for SAP HANA using System Replication (SAP в Azure (часть 4). Настройка высокого уровня доступности SAP HANA путем использования репликации системы)