Конфигурации рабочих нагрузок SAP с использованием Зон доступности Azure

  • Статья

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

При использовании стандартной архитектуры SAP NetWeaver или S/4HANA необходимо защитить три разных уровня:

  • Уровень приложений SAP, который могут представлять от одной до нескольких десятков виртуальных машин. Необходимо максимально снизить вероятность развертывания виртуальных машин на одном и том же сервере узла. Также нужно, чтобы эти виртуальные машины находились достаточно близко к уровню СУБД, чтобы сетевая задержка оставалась в приемлемом диапазоне
  • Уровень SAP ASCS/SCS, который представляет собой единую точку отказа в архитектуре SAP NetWeaver и S/4HANA. Обычно нужно выбрать две виртуальные машины, с помощью которых планируется охватить инфраструктуру отработки отказов. Поэтому эти виртуальные машины должны быть выделены в разных доменах сбоя инфраструктуры
  • Уровень СУБД SAP, который также представляет собой единую точку отказа. Обычно он состоит из двух виртуальных машин, входящих в инфраструктуру отработки отказов. Поэтому эти виртуальные машины должны быть выделены в разных доменах сбоя инфраструктуры. Исключение составляют масштабируемые развертывания SAP HANA, где можно использовать более двух виртуальных машин

Основные различия между развертыванием критически важных виртуальных машин с помощью групп доступности или зон доступности выражаются в следующем.

  • Развертывание с помощью группы доступности — это структурирование виртуальных машин в виде набора в одной зоне или в одном центре обработки данных (что применимо для определенного региона). В результате развертывание через группу доступности не защищено питанием, охлаждением или сетевыми проблемами, влияющими на набор данных в целом. Положительным фактором является то, что для виртуальных машин выполняется согласование с доменами обновления и сбоя в пределах данной зоны или центра обработки данных. Специально для уровня SAP ASCS или СУБД, где мы защищаем две виртуальные машины для каждого набора доступности, выравнивание с доменами сбоя предотвращает, что обе виртуальные машины заканчиваются на одном оборудовании узла.
  • При развертывании виртуальных машин с помощью Azure Зоны доступности и выборе разных зон (не более трех возможных), будет развертываться виртуальные машины в разных физических расположениях и с тем, что добавляет защиту от проблем с питанием, охлаждением или сетью, которые влияют на потоки данных в целом. Однако при развертывании нескольких виртуальных машин одного семейства виртуальных машин в той же зоне доступности нет защиты от этих виртуальных машин, в конечном итоге на одном узле или в том же домене сбоя. Поэтому развертывание с помощью зон доступности идеально подходит для уровня SAP ASCS и СУБД, где обычно две виртуальные машины рассматриваются по отдельности. Для уровня приложений SAP, где может быть значительно больше двух виртуальных машин, нужно обратиться к другой модели развертывания (см. далее)

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

В качестве другой функции развертывания устойчивости Azure представила масштабируемые наборы виртуальных машин с гибкой оркестрацией для рабочей нагрузки SAP. Масштабируемый набор виртуальных машин обеспечивает логическую группирование управляемых платформой виртуальных машин. Гибкая оркестрация масштабируемого набора виртуальных машин позволяет создать масштабируемый набор в пределах региона или охватывать его между зонами доступности. При создании гибкого масштабируемого набора в регионе с платформойFaultDomainCount>1 (FD>1) виртуальные машины, развернутые в масштабируемом наборе, будут распределены по указанному количеству доменов сбоя в одном регионе. С другой стороны, создание гибкого масштабируемого набора между зонами доступности с помощью platformFaultDomainCount=1 (FD=1) будет распространять виртуальные машины по разным зонам, а масштабируемый набор также распределяет виртуальные машины между различными доменами сбоя в каждой зоне на основе наилучших усилий. Для рабочей нагрузки SAP поддерживается только гибкий масштабируемый набор с FD=1. Преимущество использования гибких масштабируемых наборов с FD=1 для межзонального развертывания вместо традиционного развертывания зон доступности заключается в том, что виртуальные машины, развернутые с масштабируемым набором, будут распределены по разным доменам сбоя в пределах зоны наилучшим образом. Дополнительные сведения см . в руководстве по развертыванию гибкого масштабируемого набора для рабочей нагрузки SAP.

Рекомендации по развертыванию в зонах доступности

При использовании зон доступности необходимо учитывать следующее.

  • Максимальная задержка круговой передачи сети между Azure Зоны доступности указывается в документах "Регионы и зоны доступности".
  • Опытная задержка круговой передачи сети не обязательно указывает на реальное географическое расстояние центров обработки данных, формающих различные зоны. Задержка круговой передачи сети также зависит от подключения кабеля и маршрутизации кабелей между этими разными центрами обработки данных.
  • Зоны доступности не следует считать идеальным решением для аварийного восстановления. Стихийное бедствие может причинить существенный ущерб мировым регионам, в том числе инфраструктуре электропитания. Расстояния между различными зонами могут быть недостаточно большими для реализации соответствующего решения аварийного восстановления.
  • Задержка в сети между зонами доступности в регионах Azure различна. В некоторых случаях вы можете развернуть прикладной уровень SAP и выполнить его в разных зонах, так как задержка в сети при обращении из какой-либо из этих зон к активной виртуальной машине СУБД остается в допустимых пределах. Но в некоторых регионах Azure будет складываться такая ситуация, в которой задержка между активной виртуальной машиной СУБД и экземпляром приложением SAP, развернутыми в разных зонах, будет неприемлемой для бизнес-процессов SAP. В таких случаях архитектуры развертывания для приложений должны различаться: архитектура типа "активный — активный" предназначается для приложений, а архитектуру типа "активный — пассивный" нужно использовать, если задержка в сети между зонами слишком высока.
  • Выбор места применения зон доступности должен исходить из задержки в сети между зонами. Задержка сети играет важную роль в двух областях:
    • Задержка между двумя экземплярами СУБД, между которыми нужно настроить синхронную репликацию. Чем выше задержка в сети, тем более вероятно, что она влияет на масштабируемость рабочей нагрузки.
    • Разница сетевой задержки между виртуальной машиной, выполняющей экземпляр диалога SAP в зоне, где расположен активный экземпляр СУБД, и аналогичной виртуальной машиной в другой зоне. Чем больше разница между ними, тем большее влияние они будут оказывать на время выполнения бизнес-процессов и пакетных заданий, в зависимости от того, находятся ли они в одной с СУБД зоне или в разных зонах.

При развертывании виртуальных машин Azure в зонах доступности или установке решений отработки отказа в одном регионе Azure накладываются некоторые ограничения.

Идеальное сочетание зон доступности

Если вы хотите развернуть систему SAP NetWeaver или S/4HANA в зонах, можно развернуть два шаблона архитектуры:

  • Активный —активный. Пара виртуальных машин с ASCS/SCS и пара VMS с уровнем СУБД распределены по двум зонам. Количество виртуальных машин, работающих на уровне приложений SAP, развертывается в четных числах в одной и той же двух зонах. В случае сбоя виртуальной машины СУБД или ASCS/SCS должен быть выполнен откат некоторых открытых и активных транзакций. Но пользователи остаются в учетной записи системы. Это не имеет значения, в каких зонах активная виртуальная машина СУБД и экземпляры приложений выполняются. Эта архитектура является предпочтительной для развертывания с использованием разных зон.
  • Активный — пассивный. Пара виртуальных машин с ASCS/SCS и пара VMS с уровнем СУБД распределены по двум зонам. Общее количество виртуальных машин, на которых выполняется уровень приложений SAP, развертывается в одной из зон доступности. Уровень приложений выполняется в той же зоне, что и активный экземпляр ASCS/SCS и СУБД. Эта архитектура развертывания используется, если сетевая задержка между разными зонами слишком высока для запуска уровня приложения при распределении по зонам. Вместо этого уровень приложений SAP должен выполняться в той же зоне, что и активный экземпляр ASCS/SCS и (или) СУБД. Если виртуальная машина ASCS/SCS или СУБД переключается из-за сбоя в дополнительную зону, может возникнуть большая задержка в сети и снижение пропускной способности. И вам потребуется выполнить отработку отказа ранее отработки отказа виртуальной машины как можно скорее, чтобы вернуться к предыдущим уровням пропускной способности. При сбое зоны необходимо выполнить отработку отказа уровня приложения в дополнительную зону. У пользователей при этом происходит полное завершение работы системы. В некоторых регионах Azure эта архитектура является единственной допустимой архитектурой, если нужно использовать зоны доступности. Если возможные последствия от отработки отказа виртуальных машин ASCS/SCS или СУБД в дополнительную зону оказываются неприемлемыми, возможно, будет удобнее работать с развертыванием группы доступности

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

  • Задержка в сети между тремя зонами в регионе Azure. Определение сетевой задержки между зонами региона позволяет выбрать зоны с наименьшей сетевой задержкой на уровне сетевого трафика между зонами.
  • Разница задержек между виртуальными машинами в пределах одной из выбранных зон и задержка в сети между двумя выбранными зонами.
  • Доступность типов виртуальных машин, которые вы намерены развернуть в соответствующих двух зонах. При использовании некоторых номеров SKU виртуальных машин могут возникнуть ситуации, в которых некоторые номера SKU доступны только в двух из трех зон.

Задержка в сети между зонами и в пределах зоны.

Чтобы определить задержку между несколькими зонами, сделайте следующее.

  • Разверните в каждой из трех зон виртуальную машину с тем номером SKU, который вы намерены использовать для экземпляра СУБД. Перед выполнением измерений убедитесь, что включено ускорение работы в сети Azure. Ускорение сети — это параметр по умолчанию с нескольких лет. Тем не менее, проверка, включена ли она и работает
  • Когда вы найдете две зоны с наименьшей задержкой в сети, разверните во всех трех зонах доступности еще три виртуальные машины с тем номером SKU, который вы планируете использовать для виртуальных машин прикладного уровня. Измерьте задержку в сети для двух виртуальных машин СУБД в двух выбранных зонах для СУБД.
  • Используйте niping в качестве измерительного инструмента. Это инструмент SAP, который описан в примечаниях по поддержке SAP № 500235 и № 1100926. Уделите внимание описанным командам для измерения задержки. Так как ping не работает с путями кода для ускорения работы в сети Azure, мы не рекомендуем использовать этот инструмент.

Эти тесты не нужно выполнять вручную. Можно воспользоваться процедурой PowerShell проверка задержки для зоны доступности, которая позволяет автоматизировать описанное тестирование задержки.

По результатам этих измерений и с учетом доступности номеров SKU виртуальных машин в зонах доступности вам следует принять следующие решения.

  • Определите оптимальные зоны для уровня СУБД.
  • Исходя из различий задержки в сети в пределах зоны и между зонами определите, нужно ли распределить активный прикладной уровень SAP на одну, две или все три зоны.
  • Определите, нужно ли развертывать конфигурацию "активный — пассивный" или "активный — активный" с точки зрения приложения. (Эти конфигурации описаны далее в статье.)

При принятии этих решений учитывайте также рекомендации компании SAP по задержкам в сети, которые описаны в примечании SAP № 1100926.

Важно!

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

Важно!

Считается нормальным, что описанные выше измерения дадут разные результаты в каждом из регионов Azure, который поддерживает Зоны доступности. Даже если требования к задержке в сети будут такими же, для разных регионов Azure могут подходить разные стратегии развертывания из-за различий в задержках между зонами. В одних регионах Azure задержка в сети между тремя разными зонами может значительно отличаться. В других регионах Azure задержка в сети между тремя разными зонами может быть более схожей. Утверждение о том, что задержка в сети всегда имеется в диапазоне от 1 до 2 миллисекунд, не является правильной. Не существует общих правил, характеризующих задержку в сети между зонами доступности в регионах Azure.

Развертывание архитектуры "активный — активный"

Такая архитектура развертывания называется "активный — активный", так как подразумевает развертывание серверов активных приложений SAP в двух или трех зонах. Экземпляр центральных служб SAP, использующий службу постановки в очередь для репликации, будет развертываться в двух зонах. Это справедливо и для уровня СУБД, который будет развертываться в тех же зонах, что и центральная служба SAP. При рассмотрении этой конфигурации необходимо найти в нужном регионе две зоны доступности, задержка в сети между которыми приемлема для используемой рабочей нагрузки и синхронной репликации СУБД. Кроме того, разница между задержками в сети в пределах выбранных зон и между ними не должна быть слишком большой.

Характерная особенность архитектуры SAP состоит в том, что пользователи и пакетные задания могут работать в разных экземплярах приложений, если это не настроено по-другому. Следствием этого обстоятельства при развертывании типа "активный/активный" является то, что пакетные задания могут выполняться любыми экземплярами приложения SAP независимо от того, работают ли они в одной и той же зоне с активной СУБД. Если разница сетевой задержки между разными зонами меньше по сравнению с сетевой задержкой в пределах зоны, то разница по времени выполнения пакетных заданий может быть незначительной. Тем не менее, большая разница в задержке сети в пределах зоны, по сравнению с сетевым трафиком зоны, может повлиять на время выполнения пакетных заданий, если задание выполнено в зоне, где экземпляр СУБД не активен. Это на вас как клиент, чтобы решить, какие допустимые различия во время выполнения. И с тем, что терпимая задержка сети для трафика между зонами для рабочей нагрузки.

Регионы Azure, где такое активное или активное развертывание может быть возможно без значительных различий во времени выполнения и пропускной способности в уровне приложений, развернутых в разных Зоны доступности, например:

  • Восточная Австралия (две из трех зон)
  • Южная Бразилия (все три зоны)
  • Центральная Индия (все три зоны)
  • Центральная часть США (все три зоны)
  • Восточная Азия (все три зоны)
  • Восточная часть США (две из трех зон)
  • Восточная часть США 2 (все три зоны)
  • Западная Германия (все три зоны)
  • Центральная Израиль (все три зоны)
  • Италия Северная (две из трех зон)
  • Центральная Корея (все три зоны)
  • Центральная Польша (все три зоны)
  • Катар Центральной (все три зоны)
  • Северная Европа (все три зоны)
  • Восточная Норвегия (два из трех зон)
  • Северная Африка (два из трех)
  • Южная центральная часть США (все три зоны)
  • Юго-Восточная Азия (все три зоны)
  • Центральная Швеция (все три зоны)
  • Северная Швейцария (все три зоны)
  • Север ОАЭ (все три зоны)
  • Южная часть Соединенного Королевства (две из трех зон)
  • Западная Европа (две из трех зон)
  • Западная часть США 2 (все три зоны)
  • Западная часть США3 (все три зоны)

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

Регионы Azure, в которых архитектура развертывания SAP в зонах активного и активного развертывания SAP может оказаться невозможной, например:

  • Центральная Канада
  • Центральная Франция
  • Восточная Япония

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

Зависит от того, что вы готовы терпеть различия во время выполнения, другие регионы, которые не указаны, также могут претендовать.

Упрощенная схема развертывания "активный — активный" в двух зонах может выглядеть примерно так:

Active/Active zone deployment

Для этой конфигурации следует принимать во внимание следующие соображения.

  • Не используя группу размещения близкого взаимодействия Azure, вы обрабатываете Azure Зоны доступности как домены сбоя для всех виртуальных машин, так как группы доступности не могут быть развернуты в Azure Зоны доступности.
  • Если вы хотите объединить развертывания зон для уровня СУБД с центральными службами и использовать группы доступности Azure для уровня приложений, вам нужно применить группы близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для обеспечения оптимальной сетевой задержки при использовании приложений SAP.
  • Подсистемы балансировки нагрузки, которые вы применяете для отказоустойчивых кластеров центральных служб SAP и для уровня СУБД, должны использовать номер SKU ценовой категории "Стандартный". Подсистема балансировки нагрузки (цен. категория "Базовый") не будет работать между зонами.
  • Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Для каждой зоны не требуются отдельные виртуальные сети и подсети.
  • Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
  • Хранилище Azure класса "Премиум", хранилище на основе SSD-накопителей класса "Ультра" или ANF не поддерживают репликацию хранилища между зонами. Для развертываний СУБД мы будем полагаться на методы базы данных для реплика te данных между зонами
  • Для общих папок S МБ и NFS на основе файлов Azure Premium предлагается зональная избыточность с синхронной реплика tion. Проверьте этот документ для доступности ZRS для файлов Azure Premium в регионе, в который вы хотите развернуть. Использование зональных реплика общих папок NFS и S МБ полностью поддерживается при развертывании уровня приложений SAP и отказоустойчивых кластерах высокого уровня доступности для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure. Или для дополнительных экземпляров приложений.
  • Чтобы обеспечить стабильное время выполнения для критически важных бизнес-процессов, можно направить конкретные пакетные задания или определенных пользователей к экземплярам приложений, которые находятся в одной зоне с активным экземпляром СУБД, используя группы серверов пакетной службы SAP, группы входа или группы RFC. Однако в зональном процессе отработки отказа необходимо вручную переместить эти группы в экземпляры, работающие на виртуальных машинах, которые находятся в зоне с активной виртуальной машиной базы данных.
  • Может потребоваться развернуть неактивные экземпляры диалога в каждой из зон.

Важно!

В этом активном или активном сценарии взимается плата за трафик между зонами. Обратитесь к документу Сведения о ценах для пропускной способности. Обмен данными между уровнем приложений SAP и уровнем СУБД SAP является очень интенсивным. Поэтому активный или активный сценарий может способствовать затратам.

Развертывание архитектуры "активный — пассивный"

Если вы не сможете найти сочетание зон с приемлемой разницей задержек в сети внутри одной зоны и между зонами, то вы можете развернуть архитектуру типа "активный — пассивный" с точки зрения прикладного уровня SAP. В ней вы определяете активную зону, в которой будет развернут весь прикладной уровень и будут выполняться активный экземпляр СУБД и экземпляр центральных служб SAP. Такая конфигурация позволяет гарантировать, что различия во времени выполнения бизнес-транзакций и пакетных заданий не будут критически большими в зависимости от того, выполняется ли задание в зоне с активным экземпляром СУБД или в другой зоне.

Регионы Azure, где этот тип архитектуры развертывания в разных зонах может быть предпочтительнее:

  • Центральная Канада
  • Центральная Франция
  • Восточная Япония
  • Восточная Норвегия;
  • Северная часть ЮАР;

Базовая схема такой архитектуры выглядит следующим образом.

Active/Passive zone deployment

Для этой конфигурации следует принимать во внимание следующие соображения.

  • Группы доступности невозможно развернуть в Зонах доступности Azure. Чтобы устранить проблему, можно использовать группы размещения близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимальной задержки сети с приложениями SAP.
  • Применяя такую архитектуру, вам придется внимательно отслеживать состояние и стараться удерживать активные экземпляры СУБД и центральных служб SAP в той же зоне, где развернут прикладной уровень. Если произошел отработка отказа sap Central Service или экземпляр СУБД, необходимо убедиться, что вы можете вручную вернуться в зону с помощью уровня приложений SAP, развернутого как можно быстрее.
  • Подсистемы балансировки нагрузки, которые вы применяете для отказоустойчивых кластеров центральных служб SAP и для уровня СУБД, должны использовать номер SKU ценовой категории "Стандартный". Подсистема балансировки нагрузки (цен. категория "Базовый") не будет работать между зонами.
  • Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
  • Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
  • Хранилище Azure класса "Премиум", хранилище на основе SSD-накопителей класса "Ультра" или ANF не поддерживают репликацию хранилища между зонами. Для развертываний СУБД мы будем полагаться на методы базы данных для реплика te данных между зонами
  • Для общих папок S МБ и NFS на основе файлов Azure Premium предлагается зональная избыточность с синхронной реплика tion. Проверьте этот документ для доступности ZRS для файлов Azure Premium в регионе, в который вы хотите развернуть. Использование зональных реплика общих папок NFS и S МБ полностью поддерживается при развертывании уровня приложений SAP и отказоустойчивых кластерах высокого уровня доступности для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure. Или эта зона может использоваться для дополнительных экземпляров приложения.
  • Следует развернуть неактивные виртуальные машины в пассивной зоне (с точки зрения СУБД), чтобы иметь возможность запустить ресурсы приложения в случае сбоя зоны. Еще одной возможностью может быть использование Azure Site Recovery, которая может реплика активных виртуальных машин для неактивных виртуальных машин между зонами.
  • Следует создать средства автоматизации, которые в случае сбоя зоны позволят автоматически запускать уровень приложений SAP во второй зоне.

Сочетание конфигураций высокого уровня доступности и аварийного восстановления

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

Примечание.

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

Ниже приведен пример такой конфигурации.

Combined high-availability DR in zones

Для этой конфигурации следует принимать во внимание следующие соображения.

  • Вам следует предполагать, что элементы инфраструктуры, на которых размещается зона доступности, далеко расположены друг от друга, иначе вам придется остаться в пределах определенного региона Azure. Группы доступности невозможно развернуть в Зонах доступности Azure. Чтобы компенсировать это, можно использовать группы размещения близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимизации сетевой задержки при использовании приложений SAP.
  • Применяя такую архитектуру, вам придется внимательно отслеживать состояние и стараться удерживать активные экземпляры СУБД и центральных служб SAP в той же зоне, где развернут прикладной уровень. Если произошел отработка отказа sap Central Service или экземпляр СУБД, необходимо убедиться, что вы можете вручную вернуться в зону с помощью уровня приложений SAP, развернутого как можно быстрее.
  • Экземпляры рабочих приложений должны быть предварительно установлены на виртуальных машинах, на которых выполняются активные экземпляры приложений QA.
  • В случае сбоя зоны нужно завершить работу экземпляров приложения, предназначенных для контроля качества, и вместо них запустить производственные экземпляры. В этом случае для экземпляров приложения нужно использовать виртуальные имена.
  • Подсистемы балансировки нагрузки, которые вы применяете для отказоустойчивых кластеров центральных служб SAP и для уровня СУБД, должны использовать номер SKU ценовой категории "Стандартный". Подсистема балансировки нагрузки (цен. категория "Базовый") не будет работать между зонами.
  • Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
  • Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
  • Хранилище Azure класса "Премиум", хранилище на основе SSD-накопителей класса "Ультра" или ANF не поддерживают репликацию хранилища между зонами. Для развертываний СУБД мы будем полагаться на методы базы данных для реплика te данных между зонами
  • Для общих папок S МБ и NFS на основе файлов Azure Premium предлагается зональная избыточность с синхронной реплика tion. Проверьте этот документ для доступности ZRS для файлов Azure Premium в регионе, в который вы хотите развернуть. Использование зональных реплика общих папок NFS и S МБ полностью поддерживается при развертывании уровня приложений SAP и отказоустойчивых кластерах высокого уровня доступности для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure.

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

Ниже приведены дальнейшие действия по развертыванию в Зонах доступности Azure: