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

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

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

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

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

• Развертывание с помощью группы доступности означает объединение виртуальных машин в наборе внутри одной зоны или одного центра обработки данных (в зависимости от конкретного региона). В результате развертывание через группу доступности не защищено от проблем с питанием, охлаждением или сетью, которые затрагивают центры обработки данных в зоне в целом. При наличии групп доступности также нет принудительного выравнивания виртуальной машины и её дисков. Это означает, что диски могут находиться в любом центре обработки данных региона Azure, независимо от зональной структуры региона. Плюсом является то, что виртуальные машины согласованы с доменами обновления и сбоя в пределах этой зоны или центра обработки данных. Специально для уровня 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 различна. Даже в пределах региона Azure задержки сети между различными зонами могут отличаться. Хотя даже в худшем случае синхронная репликация на уровне базы данных на основе репликации системы HANA или SQL Server AlwaysOn будет работать без влияния на масштабируемость рабочей нагрузки.
• Выбор места применения зон доступности должен исходить из задержки в сети между зонами. Задержка сети играет важную роль в двух областях:
  • Задержка между двумя экземплярами базы данных, которые должны иметь синхронную репликацию. Основываясь на очень успешных операциях крупнейших систем NetWeaver и S/4HANA между зонами с более высокой задержкой сети (менее 1,5 миллисекунда), это можно игнорировать.
  • Разница в задержке сети между виртуальной машиной с экземпляром диалогового окна SAP в зоне с активным экземпляром базы данных и аналогичной виртуальной машиной в другой зоне. По мере увеличения этого различия влияние на время выполнения бизнес-процессов и пакетных заданий также увеличивается, зависит от того, выполняются ли они в зоне с базой данных или в другой зоне (см. далее в этой статье).
• Задержка в сети с Azure Зоны доступности, даже в самых больших зонах, достаточно низкая для запуска бизнес-процессов SAP. До сих пор мы видели лишь несколько исключительных примеров, когда клиентам необходимо было колоцировать уровень приложений SAP и уровень базы данных в рамках единого магистрального сегмента сети центра обработки данных.

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

• При развертывании в Зонах доступности Azure необходимо использовать Управляемые диски Azure.
• Сопоставление перечислений зон с физическими зонами устанавливается на уровне подписки Azure. Если вы используете разные подписки для развертывания систем SAP, для каждой подписки следует определить оптимальные зоны. Если вы хотите сравнить логическое сопоставление различных подписок, рассмотрите скрипт Avzone-Mapping.
• Наборы доступности Azure нельзя развертывать в пределах зоны доступности Azure без использования группы размещения близкого взаимодействия Azure. Способ развертывания уровня базы данных SAP и центральных служб в разных зонах, а также одновременное развертывание уровня приложений SAP с помощью групп доступности, что позволяет поддерживать близкое расположение виртуальных машин, описаны в статье Группы размещения близкого взаимодействия Azure для оптимальной задержки сети с приложениями SAP. Если вы не используете группы проксимального размещения Azure, необходимо выбрать одну из них в качестве среды развертывания для виртуальных машин.
• Невозможно использовать Azure Basic Load Balancer для создания отказоустойчивых кластерных решений на основе Windows Server Failover Clustering или Linux Pacemaker. Вместо этого необходимо использовать SKU "Azure Standard Load Balancer".
• Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.

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

Если вы не настроите назначение бизнес-процессов с такими функциональными возможностями SAP, как группы входа, группы серверов RFC, группы серверов пакетной обработки и аналогичные, бизнес-процессы можно выполнять в разных экземплярах приложений на уровне приложений SAP. Побочным эффектом этого факта является то, что пакетные задания могут выполняться экземплярами приложений SAP независимо от того, выполняются ли они в той же зоне с активным экземпляром базы данных или нет. Если разница сетевой задержки между разными зонами меньше по сравнению с сетевой задержкой в пределах зоны, то разница по времени выполнения пакетных заданий может быть незначительной. Тем не менее, большая разница в задержке сети в пределах зоны, по сравнению с сетевым трафиком зоны, может повлиять на время выполнения пакетных заданий, если задание выполнено в зоне, где экземпляр базы данных не активен. На вас лежит ответственность как на клиенте решать, какие допустимые различия во времени выполнения задачи. Учитывая, какая допустимая задержка сети для трафика между зонами подходит для вашей рабочей нагрузки. Исключительно с технической точки зрения задержки сети между зонами доступности Azure в регионе Azure подходят для архитектуры NetWeaver, S/4HANA или других приложений SAP. Кроме того, как клиент, вы потенциально можете сыграть роль в устранении таких различий, используя концепции SAP, такие как группы входа, группы серверов RFC, группы серверов пакетов и подобные, когда вы выбираете одну из концепций развертывания, представленных в этой статье.

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

• Активный/активный: пара виртуальных машин, управляющих ASCS/SCS, и пара виртуальных машин, работающих на уровне базы данных, распределены между двумя зонами. Виртуальные машины, работающие на уровне приложений SAP, развертываются в равном количестве в двух одних зонах. Если происходит сбой базы данных или виртуальной машины ASCS/SCS, некоторые открытые и активные транзакции могут быть откатаны. Но пользователи остаются в системе. Это не имеет значения, в каких зонах активная виртуальная машина базы данных и экземпляры приложения выполняются. Эта архитектура является предпочтительной для развертывания между зонами. В случаях, когда задержки сети между зонами приводят к значительным различиям при выполнении бизнес-процессов, можно использовать такие функции, как группы входа SAP, группы серверов RFC, группы серверов пакетной обработки и аналогичные, для маршрутизации выполнения бизнес-процессов в определенные диалоговые экземпляры, которые находятся в той же зоне, что и активный экземпляр базы данных.
• Активный и пассивный: пара виртуальных машин под управлением ASCS/SCS и пара виртуальных машин, работающих на уровне базы данных, распределяются между двумя зонами. Виртуальные машины, работающие на уровне приложений SAP, развертываются в одной из зон доступности. Вы запускаете прикладной уровень в той же зоне, что и активный экземпляр ASCS/SCS и базы данных. Эту архитектуру развертывания можно использовать, если вы считаете задержку сети в разных зонах слишком высокой. И это вызывает невыносимые различия во времени выполнения ваших бизнес-процессов. Или если вы хотите использовать развертывания зоны доступности в качестве развертываний аварийного восстановления на короткие расстояния. зоны. Если виртуальная машина ASCS/SCS или базы данных переходит в режим отработки отказа в вторичной зоне, вы можете столкнуться с более высокой задержкой сети и, следовательно, снижением пропускной способности. И вам потребуется выполнить возврат виртуальной машины после отказа как можно скорее, чтобы достичь прежних уровней пропускной способности. При сбое зоны необходимо выполнить отработку отказа уровня приложения во вторичную зону. Деятельность, которую пользователи воспринимают как полное завершение работы системы.

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

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

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

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

• Разверните SKU виртуальной машины, который вы хотите использовать для экземпляра базы данных во всех трех зонах. Перед выполнением измерений убедитесь, что включено ускорение работы в сети Azure. Ускорение сети — это параметр по умолчанию с нескольких лет. Тем не менее, проверьте, включена ли она и работает
• Когда вы найдете две зоны с наименьшей задержкой в сети, разверните во всех трех зонах доступности еще три виртуальные машины с тем номером SKU, который вы планируете использовать для виртуальных машин прикладного уровня. Измеряйте задержку сети на двух виртуальных машинах базы данных в двух выбранных зонах.
• Используйте niping в качестве измерительного инструмента. Это инструмент SAP, который описан в примечаниях по поддержке SAP № 500235 и № 1100926. Рассматривайте классификацию задержки сети в заметке SAP #1100926 в качестве приблизительного руководства. Задержки сети, превышающие 0,7 миллисекунда, не означают, что система не будет работать технически или что бизнес-процессы не удовлетворяют отдельным соглашениям об уровне обслуживания. Примечание не предназначено для того, чтобы указать, что поддерживается или не поддерживается SAP и (или) Корпорацией Майкрософт. Уделите внимание описанным командам для измерения задержки. Поскольку ping не работает с ускоренными сетевыми путями Azure, мы не рекомендуем его использовать.

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

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

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

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

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

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

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

• Не используя группу близкого размещения Azure, вы рассматриваете Azure Availability Zones как домены сбоя для всех виртуальных машин, потому что группы доступности не могут быть развернуты в Azure Availability Zones.
• Если вы хотите объединить зональные развертывания для уровня базы данных и центральных служб, но хотите использовать группы доступности Azure для уровня приложений, необходимо использовать группы близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимальной задержки сети с приложениями SAP.
• Для подсистем балансировки нагрузки отказоустойчивых кластеров служб SAP Central и уровня базы данных необходимо использовать SKU Azure Load Balancer уровня "Стандартный". Базовая подсистема балансировки нагрузки не работает в разных зонах.
• Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.
• Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Для каждой зоны не требуются отдельные виртуальные сети и подсети.
• Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
• Azure Premium SSD v2, хранилище Ultra SSD или Azure NetApp Files не поддерживают синхронную репликацию хранилища между зонами. Для развертываний баз данных мы будем полагаться на методы базы данных для репликации данных между зонами.
• SSD класса Premium версии 1, поддерживающая синхронную зональную репликацию между Зонами доступности, не была протестирована с нагрузкой базы данных SAP. Поэтому зональная синхронная репликация SSD Azure Premium версии 1 должна рассматриваться как не поддерживаемая для рабочих нагрузок базы данных SAP.
• Для общих папок SMB и NFS, базирующихся на Azure Premium Files, предлагается зональная избыточность с синхронной репликацией. Проверьте этот документ, чтобы узнать, доступны ли ZRS для Azure Premium Files в регионе, в который вы планируете развертывание. Использование зональных реплицированных общих папок NFS и SMB полностью поддерживается при развертывании уровня приложений SAP, а также в кластерах высокой доступности с поддержкой отказоустойчивости для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Высокая доступность для SAP NetWeaver на виртуальных машинах Azure с SUSE Linux Enterprise Server и NFS в Azure Files
  • Высокая доступность виртуальных машин Azure для SAP NetWeaver на Red Hat Enterprise Linux с Azure NetApp Files для приложений SAP
  • Высокий уровень доступности SAP NetWeaver на виртуальных машинах Azure (в Windows) с Azure Files Premium SMB для приложений SAP
• Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure. Или для увеличения количества экземпляров приложений.
• Чтобы обеспечить согласованность времени выполнения для критически важных бизнес-процессов, можно попробовать направить определенные пакетные задания и пользователей в экземпляры приложений, которые находятся в зоне с активным экземпляром базы данных с помощью групп серверов пакетной службы SAP, групп входа в систему SAP или групп RFC. Однако в процессе зонального переключения из-за сбоя необходимо вручную переместить эти группы в экземпляры, работающие на виртуальных машинах, находящихся в той же зоне, что и активная виртуальная машина базы данных.
• Возможно, у вас возникнет необходимость развернуть неактивные экземпляры диалога в каждой из зон.

Активное/пассивное развертывание

Если вы не можете найти конфигурацию, которая снижает потенциальную разницу во времени выполнения бизнес-процессов SAP или если вы хотите развернуть конфигурацию аварийного восстановления на коротком расстоянии, можно развернуть архитектуру с активно/пассивным характером с точки зрения уровня приложений SAP. Вы определяете активную зону, которая является зоной, в которой развертывается полный уровень приложений и где вы пытаетесь запустить как активный экземпляр базы данных, так и экземпляр SAP Central Services. При такой конфигурации необходимо убедиться, что у вас нет экстремальных вариантов времени выполнения в зависимости от того, выполняется ли задание в зоне с активным экземпляром базы данных или нет, в бизнес-транзакциях и пакетных заданиях.

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

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

• Невозможно развернуть группы доступности в пределах Зон доступности Azure. Чтобы устранить проблему, можно использовать группы размещения близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимальной задержки сети с приложениями SAP.
• При использовании этой архитектуры необходимо внимательно отслеживать состояние и пытаться сохранить активный экземпляр базы данных и экземпляры SAP Central Services в той же зоне, что и развернутый уровень приложений. Если происходило переключение на резерв SAP Central Service или экземпляра базы данных, необходимо убедиться, что вы можете вручную вернуться в зону с уровнем приложений SAP как можно быстрее.
• Для балансировщиков нагрузки отказоустойчивых кластеров центральных служб SAP и уровня базы данных необходимо использовать Standard SKU Azure Load Balancer. Базовая подсистема балансировки нагрузки не работает в разных зонах.
• Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.
• Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
• Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
• Azure Premium SSD v2, хранилище Ultra SSD или Azure NetApp Files не поддерживают синхронную репликацию хранилища между зонами. Для развертываний баз данных мы будем полагаться на методы базы данных для репликации данных между зонами.
• SSD класса Premium версии 1, поддерживающая синхронную зональную репликацию между Зонами доступности, не была протестирована с нагрузкой базы данных SAP. Поэтому настраиваемая зональная синхронная репликация SSD Azure Premium версии 1 должна рассматриваться как не поддерживаемая для рабочих нагрузок базы данных SAP.
• Для общих папок SMB и NFS, базирующихся на Azure Premium Files, предлагается зональная избыточность с синхронной репликацией. Проверьте этот документ, чтобы узнать, доступны ли ZRS для Azure Premium Files в регионе, в который вы планируете развертывание. Использование зональных реплицированных общих папок NFS и SMB полностью поддерживается при развертывании уровня приложений SAP, а также в кластерах высокой доступности с поддержкой отказоустойчивости для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Высокая доступность для SAP NetWeaver на виртуальных машинах Azure с SUSE Linux Enterprise Server и NFS в Azure Files
  • Высокая доступность виртуальных машин Azure для SAP NetWeaver на Red Hat Enterprise Linux с Azure NetApp Files для приложений SAP
  • Высокий уровень доступности SAP NetWeaver на виртуальных машинах Azure (в Windows) с Azure Files Premium SMB для приложений SAP
• Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure. Или для дополнительных экземпляров приложения.
• Необходимо развернуть неактивные виртуальные машины в пассивной зоне (с точки зрения базы данных), чтобы можно было запустить ресурсы приложения в случае сбоя зоны. Еще одной возможностью может быть использование Azure Site Recovery, которая может реплицировать активные виртуальные машины в неактивные виртуальные машины между зонами.
• Следует создать средства автоматизации, которые в случае сбоя зоны позволят автоматически запускать уровень приложений SAP во второй зоне.

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

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

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

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

• Вы либо предполагаете, что между объектами, на котором размещена зона доступности, имеется значительное расстояние. Или вы вынуждены оставаться в определенном регионе Azure. Группы доступности невозможно развернуть в Зонах доступности Azure. Чтобы компенсировать это, можно использовать группы размещения близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимизации сетевой задержки при использовании приложений SAP.
• При использовании этой архитектуры необходимо внимательно отслеживать состояние и пытаться сохранить активный экземпляр базы данных и экземпляры SAP Central Services в той же зоне, что и развернутый уровень приложения. Если происходило переключение на резерв SAP Central Service или экземпляра базы данных, необходимо убедиться, что вы можете вручную вернуться в зону с уровнем приложений SAP как можно быстрее.
• Экземпляры рабочих приложений должны быть предварительно установлены на виртуальных машинах, на которых выполняются активные экземпляры приложений QA.
• В случае сбоя зоны нужно завершить работу экземпляров приложения, предназначенных для контроля качества, и вместо них запустить производственные экземпляры. Чтобы это работало, вам нужно использовать виртуальные имена для экземпляров приложения.
• Для балансировщиков нагрузки отказоустойчивых кластеров SAP Central Services и уровня базы данных необходимо использовать Standard SKU Azure Load Balancer. Базовая подсистема балансировки нагрузки не работает в разных зонах.
• Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.
• Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
• Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
• Azure Premium SSD v2, хранилище Ultra SSD или Azure NetApp Files не поддерживают синхронную репликацию хранилища между зонами. Для развертываний баз данных мы будем полагаться на методы базы данных для репликации данных между зонами.
• SSD класса Premium версии 1, поддерживающая синхронную зональную репликацию между Зонами доступности, не была протестирована с нагрузкой базы данных SAP. Поэтому настраиваемая зональная синхронная репликация SSD Azure Premium версии 1 должна рассматриваться как не поддерживаемая для рабочих нагрузок базы данных SAP.
• Для общих папок SMB и NFS, базирующихся на Azure Premium Files, предлагается зональная избыточность с синхронной репликацией. Проверьте этот документ, чтобы узнать, доступны ли ZRS для Azure Premium Files в регионе, в который вы планируете развертывание. Использование зональных реплицированных общих папок NFS и SMB полностью поддерживается при развертывании уровня приложений SAP, а также в кластерах высокой доступности с поддержкой отказоустойчивости для центральных служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Высокая доступность для SAP NetWeaver на виртуальных машинах Azure с SUSE Linux Enterprise Server и NFS в Azure Files
  • Высокая доступность виртуальных машин Azure для SAP NetWeaver на Red Hat Enterprise Linux с Azure NetApp Files для приложений SAP
  • Высокий уровень доступности SAP NetWeaver на виртуальных машинах Azure (в Windows) с Azure Files Premium SMB для приложений SAP
• Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure.

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

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

• Кластеризация экземпляра SAP ASCS/SCS в отказоустойчивом кластере Windows с помощью общего диска кластера в Azure.
• Подготовка высокодоступной инфраструктуры Azure для SAP с помощью отказоустойчивого кластера Windows и файлового ресурса для экземпляров SAP ASCS/SCS.