Поделиться через

Конфигурации рабочих нагрузок 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 Load Balancer (цен. категория "Базовый") для создания отказоустойчивых кластерных решений, основанных на службах отказоустойчивого кластера Windows Server или Linux Pacemaker. Вместо этого необходимо использовать номер SKU Azure 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 на одну, две или все три зоны.
  • Определите, нужно ли развертывать конфигурацию "активный — пассивный" или "активный — активный" с точки зрения приложения. (Эти конфигурации описаны далее в статье.)

Внимание

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

Внимание

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

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

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

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

Зональное развертывание архитектуры

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

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

Внимание

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

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

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

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

Зональное развертывание архитектуры

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

  • Группы доступности невозможно развернуть в Зонах доступности Azure. Чтобы устранить проблему, можно использовать группы размещения близкого взаимодействия Azure, как описано в статье Группы размещения близкого взаимодействия Azure для оптимальной задержки сети с приложениями SAP.
  • При использовании этой архитектуры необходимо внимательно отслеживать состояние и пытаться сохранить активный экземпляр базы данных и экземпляры SAP Central Services в той же зоне, что и развернутый уровень приложений. Если произошел отработка отказа sap Central Service или экземпляр базы данных, необходимо убедиться, что вы можете вручную вернуться в зону с помощью уровня приложений SAP, развернутого как можно быстрее.
  • Для подсистем балансировки нагрузки отказоустойчивых кластеров служб SAP Central и уровня базы данных необходимо использовать SKU Azure Load Balancer уровня "Стандартный". Базовая подсистема балансировки нагрузки не работает в разных зонах.
  • Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.
  • Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
  • Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
  • Ssd Azure premium версии 2, хранилище SSD ценовой категории "Ультра" или Azure NetApp Files не поддерживают синхронизацию репликации хранилища между зонами. Для развертываний баз данных мы будем полагаться на методы базы данных для репликации данных между зонами.
  • SSD класса Premium версии 1, которая поддерживает синхронную зональную репликацию в Зоны доступности, не была протестирована с рабочей нагрузкой базы данных SAP. Поэтому настраиваемая зональная синхронная репликация SSD Azure Premium версии 1 должна рассматриваться как не поддерживаемая для рабочих нагрузок базы данных SAP.
  • Для общих папок SMB и NFS на основе файлов Azure Premium предлагается зональная избыточность с синхронной репликацией. Проверьте этот документ для доступности ZRS для файлов Azure Premium в регионе, в который вы хотите развернуть. Использование зональных реплицированных общих папок NFS и SMB полностью поддерживается при развертывании уровня приложений SAP и отказоустойчивых кластерах высокой доступности для служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Третья зона используется для размещения устройства 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 и уровня базы данных необходимо использовать SKU Azure Load Balancer уровня "Стандартный". Базовая подсистема балансировки нагрузки не работает в разных зонах.
  • Для получения зональной защиты необходимо развернуть зональную версию шлюза ExpressRoute, VPN-шлюз и стандартных общедоступных IP-адресов.
  • Виртуальная сеть Azure и все подсети, развернутые для размещения системы SAP, распределяются по нескольким зонам. Нет необходимости выделять виртуальные сети для каждой зоны.
  • Для всех развернутых виртуальных машин необходимо использовать Управляемые диски Azure. Неуправляемые диски не поддерживаются для зональных развертываний.
  • Ssd Azure premium версии 2, хранилище SSD ценовой категории "Ультра" или Azure NetApp Files не поддерживают синхронизацию репликации хранилища между зонами. Для развертываний баз данных мы будем полагаться на методы базы данных для репликации данных между зонами.
  • SSD класса Premium версии 1, которая поддерживает синхронную зональную репликацию в Зоны доступности, не была протестирована с рабочей нагрузкой базы данных SAP. Поэтому настраиваемая зональная синхронная репликация SSD Azure Premium версии 1 должна рассматриваться как не поддерживаемая для рабочих нагрузок базы данных SAP.
  • Для общих папок SMB и NFS на основе файлов Azure Premium предлагается зональная избыточность с синхронной репликацией. Проверьте этот документ для доступности ZRS для файлов Azure Premium в регионе, в который вы хотите развернуть. Использование зональных реплицированных общих папок NFS и SMB полностью поддерживается при развертывании уровня приложений SAP и отказоустойчивых кластерах высокой доступности для служб NetWeaver или S/4HANA. Документы, охватывающие эти случаи, являются следующими:
  • Третья зона используется для размещения устройства SBD в случае, когда создается кластер Pacemaker SUSE Linux и устройства SBD используются вместо агента разграничения Azure.

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

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