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

  • Статья

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

Причины выполнения развертывания в нескольких регионах 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 не зависит от настройки предварительной загрузки данных.

Diagram of two VMs over two regions.

Примечание.

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

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

Объединение доступности в пределах одного или нескольких регионов

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

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

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

Diagram of three VMs over two regions.

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

Diagram of three VMs over two regions multi-target.

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

Diagram that shows an organization that has requirements for high availability readiness in the second (DR) Azure region.

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

Важно!

Режимы работы на различных уровнях должны быть одинаковыми. Вы не можете использовать logreplay в качестве режима работы между уровнем 1 и уровнем 2 и delta_datashipping для предоставления уровня 3. Можно выбрать только один режим работы для всех уровней. Поскольку delta_datashipping не обеспечивает показатель RPO, равный 0, для многоуровневой конфигурации следует использовать только режим работы logreplay. Подробные сведения о режимах работы при репликации системы SAP HANA и некоторые ограничения см. в этой статье.

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

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