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

  • Статья

Разработка архитектуры систем SAP NetWeaver, Business 1, Hybris или S/4HANA в Azure открывает множество различных возможностей для использования различных архитектур и инструментов с целью получения масштабируемого и эффективного развертывания с высокой доступностью. При наличии зависимости от используемой операционной системы или СУБД существуют и другие ограничения. Кроме того, не все сценарии, которые поддерживаются в локальной среде, поддерживаются аналогичным образом и в Azure. В этом документе приводится пошаговое описание поддерживаемых конфигураций с невысокой доступностью, а также конфигураций и архитектур с высокой доступностью при использовании исключительно виртуальных машин Azure.

Примечание.

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

Общие ограничения платформы

Azure имеет различные платформы, помимо так называемых собственных виртуальных машин Azure, которые предлагаются в качестве первой службы. Крупные экземпляры HANA, которые в режиме заката являются одной из этих платформ. Службы Azure VMware — это еще одна из этих сторонних служб. Службы Azure VMware в целом не поддерживаются SAP для размещения рабочей нагрузки SAP. Дополнительные сведения о поддержке VMware на разных платформах см. в примечание о поддержке SAP #2138865 . Приложения SAP в VMware Cloud: поддерживаемые продукты и конфигурации виртуальных машин.

Помимо локальная служба Active Directory Azure предлагает управляемую службу SaaS Active Directory с доменными службами Microsoft Entra (традиционными службами AD, управляемыми корпорацией Майкрософт), и идентификатором Microsoft Entra. Компоненты SAP, размещенные в ОС Windows, часто полагаются на использование Windows Active Directory. В этом случае традиционный Active Directory, размещенный локально, или доменные службы Microsoft Entra (по-прежнему в тестировании). Но эти компоненты SAP не могут работать с собственным идентификатором Microsoft Entra. Причина в том, что между Active Directory в локальной форме или в ее форме SaaS (доменные службы Microsoft Entra) и собственным идентификатором Microsoft Entra Entra по-прежнему существует больше пробелов в функциональных возможностях. Эта зависимость является причиной, по которой учетные записи Microsoft Entra не поддерживаются для приложений на основе SAP NetWeaver и S/4 HANA в ОС Windows. В таких сценариях необходимо использовать традиционные учетные записи Active Directory.

Служба AD Поддерживаемые приложения на основе SAP NetWeaver и S/4 HANA в ОС Windows
Локальная среда Windows Active Directory Поддерживается
Доменные службы Microsoft Entra Поддерживается
Microsoft Entra ID Не поддерживается

Приведенный выше вариант не влияет на использование учетных записей Microsoft Entra для сценариев единого входа (SSO) с приложениями SAP.

Конфигурация с двумя уровнями

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

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

Simple 2-Tier configuration

Такие конфигурации поддерживаются в ОС Windows, Red Hat, SUSE и Oracle Linux для систем СУБД сервера SQL, Oracle, DB2, maxDB и SAP ASE в случаях производственного и непроизводственного использования. Для SAP HANA как СУБД SAP поддерживает такой сценарий, как указано в примечании SAP #1953429. До сих пор ни одна из дистрибутивов Linux не предоставила достаточной документации по высокой доступности для настройки и эксплуатации кластера Pacemaker в такой конфигурации. В результате такие конфигурации поддерживаются только в Azure для нерабочих случаев, для которых не требуется отказоустойчивый кластер высокой доступности.

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

Примечание.

Для производственных систем SAP рекомендуется применять дополнительные конфигурации с высокой доступностью и возможностью аварийного восстановления, как описано далее в этом документе

Конфигурация с тремя уровнями

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

Графическое представление этого варианта выглядит следующим образом.

Diagram that shows a simple 3-Tier configuration.

Такой тип конфигурации поддерживается в ОС Windows, Red Hat, SUSE и Oracle Linux для систем СУБД сервера SQL, Oracle, DB2, maxDB и SAP ASE в случаях производственной и непроизводственной эксплуатации. Для упрощения мы не различались между экземплярами sap Central Services и SAP в уровне приложений SAP. В этой простой трехуровневой конфигурации для центральных служб SAP не обеспечивается защита с высокой доступностью.

Примечание.

Для производственных систем SAP рекомендуется применять дополнительные конфигурации с высокой доступностью и возможностью аварийного восстановления, как описано далее в этом документе

Несколько экземпляров СУБД на виртуальную машину

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

Такая конфигурация может выглядеть следующим образом:

Multiple DBMS instances in one unit

Этот тип развертывания СУБД поддерживается в следующих случаях:

Выполнение нескольких экземпляров базы данных на одном узле необходимо убедиться, что разные экземпляры не конкурируют за ресурсы и тем самым превышают ограничения физического ресурса виртуальной машины. Это особенно важно для оперативной памяти, где необходимо предусмотреть ограничение на ее объем, который может зарезервировать любой экземпляр из категории совместно использующих виртуальную машину. Это также справедливо для ресурсов ЦП, которые могут потреблять разные экземпляры базы данных. Все системы баз данных, упоминание имеют конфигурации, позволяющие ограничить выделение памяти и ресурсы ЦП на уровне экземпляра. Чтобы обеспечить поддержку такой конфигурации для виртуальных машин Azure, ожидается, что диски или тома, используемые для файлов данных и журналов и журналов, управляемых различными экземплярами, разделены. Или другими словами, файлы журналов или журналов журнала, управляемые разными экземплярами СУБД, не должны совместно использовать одни и те же диски или тома.

Примечание.

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

Несколько диалоговых экземпляров SAP на одной виртуальной машине

В большинстве случаев развертывание нескольких диалоговых экземпляров выполняется на серверах без операционной системы или даже на виртуальных машинах, работающих в частных облаках. Основанием для таких конфигураций является необходимость адаптации некоторых диалоговых экземпляров SAP к определенной рабочей нагрузке, бизнес-функции или типам рабочих нагрузок. Причиной, по которой эти экземпляры не изолируются на отдельных виртуальных машинах, являются затраты на обслуживание и эксплуатацию операционной системы. Во многих случаях поставщик услуг размещения или оператор виртуальной машины взимает ежемесячную плату за каждую эксплуатируемую и администрируемую виртуальную машину. В Azure сценарий размещения нескольких диалоговых экземпляров SAP на одной виртуальной машине поддерживается в производственных и непроизводственных средах на основе операционных систем Windows, Red Hat, SUSE и Oracle Linux. Параметр ядра SAP PHYS_MEMSIZE, доступный в ядрах Windows и современных ядрах Linux, следует задать, если на одной виртуальной машине запущено несколько экземпляров сервера приложений SAP. Также рекомендуется ограничить расширение расширенной памяти SAP на операционных системах, таких как Windows, где реализован автоматический рост расширенной памяти SAP. Это можно сделать с помощью соответствующего параметра профиля SAP em/max_size_MB.

3-уровневая конфигурация, когда несколько диалоговых экземпляров SAP работает на основе виртуальных машинах Azure, может выглядеть следующим образом:

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

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

Защита с высокой доступностью для уровня СУБД SAP

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

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

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

Для виртуальных машин Azure на уровне СУБД поддерживаются следующие конфигурации с высоким уровнем доступности:

Важно!

Ни для какого из выше описанных сценариев мы не поддерживаем конфигурации из нескольких экземпляров СУБД на одной виртуальной машине. В каждом из этих вариантов можно развернуть только один экземпляр базы данных на виртуальной машине и обеспечить защиту с помощью описанных методов с высоким уровнем доступности. В настоящее время защита нескольких экземпляров СУБД в одном отказоустойчивом кластере Windows или Pacemaker НЕ поддерживается. Кроме того, Oracle Data Guard поддерживается только для развертываний с одним экземпляром на одной виртуальной машине.

Различные системы баз данных позволяют размещать несколько баз данных в одном экземпляре СУБД. Как и в SAP HANA, несколько баз данных могут размещаться в нескольких контейнерах баз данных (MDC). Такие конфигурации поддерживаются для случаев, когда эти конфигурации с несколькими базами данных работают в пределах одного ресурса отказоустойчивого кластера. Конфигурации, которые не поддерживаются, являются случаями, когда потребуется несколько ресурсов кластера. Как в конфигурациях, в которых нужно определить несколько групп доступности SQL Server в одном экземпляре SQL Server.

DBMS HA configuration

Наличие такие компонентов, как балансировщик нагрузки Azure, в составе архитектуры решения может потребоваться или не потребоваться в зависимости от СУБД и (или) операционных систем.

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

Существуют и другие платформы, обеспечивающие высокий уровень доступности, которые гарантированно работают на основе Microsoft Azure. Однако корпорация Майкрософт не тестирует эти платформы. Если вы хотите создать конфигурацию высокого уровня доступности с помощью этих платформ, необходимо работать с поставщиком этого программного обеспечения:

  • Разработка архитектуры развертывания
  • Развертывание архитектуры
  • Поддержка архитектуры

Важно!

Microsoft Azure Marketplace предлагает разнообразные программные устройства, которые предоставляют решения по хранению данных на основе собственного хранилища Azure. Эти программные устройства можно использовать для создания общедоступных папок NFS, и теоретически эти устройства можно применять в масштабируемых развертываниях SAP HANA, где требуется резервный узел. По различным причинам ни одно из этих программных устройств хранения не поддерживается продуктами Майкрософт и решением SAP в Azure ни при каких вариантах развертывания СУБД. Развертывание СУБД на общих ресурсах S МБ на данный момент времени не поддерживается. Развертывания СУБД на совместно используемых ресурсах NFS ограничиваются общими папками NFS версии 4.1, реализованными на основе Azure NetApp Files.

Высокий уровень доступности для центральной службы SAP

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

В перечисленных решениях требуется связь поддержки с SIOS для поддержки Datakeeper продукта и взаимодействия с SIOS непосредственно в случае возникновения проблем. В зависимости от способа лицензирования ОС Windows, Red Hat и (или) SUSE может потребоваться контракт на поддержку от поставщика ОС, чтобы обеспечить полную поддержку перечисленных конфигураций с высоким уровнем доступности.

Эта конфигурация также может выглядеть следующим образом:

DBMS and ASCS HA configuration

В правой части рисунка отображены Центральные службы SAP с высоким уровнем доступности. Помимо защиты служб SAP Central с помощью платформы отказоустойчивого кластера, которая может выполнить отработку отказа в сценариях сбоя. Существует необходимость в высокодоступном общем ресурсе NFS или S МБ или общем диске Windows, чтобы убедиться, что sapmnt и глобальный каталог транспорта доступны независимо от наличия одной виртуальной машины. Дополнительные решения, такие как сервер отказоустойчивого кластера Windows и Pacemaker, требуют подсистемы балансировки нагрузки Azure направлять или перенаправлять трафик на здоровый узел.

В приведенном списке нет упоминание операционной системы Oracle Linux. Oracle Linux не поддерживает Pacemaker в качестве платформы кластера. Если вы хотите развернуть систему SAP на Oracle Linux и вам нужна платформа с высоким уровнем доступности для Oracle Linux, следует обращаться к сторонним поставщикам. Одним из таких поставщиков является SIOS с пакетом защиты для Linux, который поддерживается SAP в Azure. Дополнительную информацию см. в примечании SAP #1662610 — сведения о поддержке пакета защиты SIOS для Linux.

Поддерживаемое хранилище со сценариями Центральных служб SAP указано выше

Так как только часть из всего количества типов хранилища Azure обеспечивает высокий уровень доступности для общих папок NFS или SMB, которые подходят для использования в кластере центральных служб SAP, далее приводится список поддерживаемых типов хранилищ

  • Сервер отказоустойчивого кластера Windows с масштабируемым файловым сервером Windows можно развернуть на всех собственных типах хранилища Azure, кроме Azure NetApp Files. Однако рекомендуется использовать хранилище класса Premium, так как соглашения об уровне обслуживания для пропускной способности и операций ввода-вывода имеют более высокий приоритет.
  • Сервер отказоустойчивого кластера Windows с SMB на Azure NetApp Files поддерживается на основе Azure NetApp Files. S МБ общие папки, размещенные в службах файлов Azure Premium, также поддерживаются для этого сценария. Стандартные файлы Azure не поддерживаются
  • Сервер отказоустойчивого кластера Windows с общим диском Windows на основе SIOS Datakeeper можно развернуть на всех собственных типах хранилища Azure, кроме Azure NetApp Files. Однако рекомендуется использовать хранилище класса Premium, так как соглашения об уровне обслуживания для пропускной способности и операций ввода-вывода имеют более высокий приоритет.
  • Поддерживается SUSE или Red Hat Pacemaker с помощью общих папок NFS в Azure NetApp Files.
  • SUSE или Red Hat Pacemaker с помощью общих папок NFS в azure Premium Files с помощью поддерживаемых LRS или ZRS. Стандартные файлы Azure не поддерживаются
  • SUSE Pacemaker при использовании конфигурации drdb между двумя виртуальными машинами поддерживается с помощью собственных типов хранилища Azure, за исключением Azure NetApp Files. Однако мы рекомендуем использовать одну из первых служб с файлами Azure Premium или Azure NetApp Files.
  • Red Hat Pacemaker с использованием glusterfs для предоставления общего ресурса NFS поддерживается с помощью собственных типов хранилища Azure, за исключением Azure NetApp Files. Однако мы рекомендуем использовать одну из первых служб с файлами Azure Premium или Azure NetApp Files.

Важно!

Microsoft Azure Marketplace предлагает разнообразные программные устройства, которые предоставляют решения по хранению данных на основе собственного хранилища Azure. Эти мягкие (модуль) хранилища можно использовать для создания общих папок NFS или S МБ а также, что теоретически можно использовать в отказоустойчивых кластеризованных службах SAP Central Services. Эти решения не поддерживаются непосредственно для рабочей нагрузки SAP корпорацией Майкрософт. Если вы намерены использовать такое решение для создания общего ресурса NFS или SMB, поддержка конфигурации Центральной службы SAP должна предоставляться сторонним поставщиком, являющимся владельцем программного обеспечения в программном устройстве хранения.

Отказоустойчивые кластеры Центральных служб SAP с несколькими идентификаторами безопасности

Чтобы сократить количество виртуальных машин, необходимых для крупномасштабных развертываний SAP, в SAP имеется возможность запускать экземпляры центральных служб SAP, относящихся к нескольким разным системам SAP, в конфигурации отказоустойчивого кластера. Представьте себе случаи, когда у вас есть 30 или более производственных систем NetWeaver или S/4HANA. Без кластеризации с несколькими идентификаторами безопасности для таких конфигураций потребуется 60 или больше виртуальных машин в 30 или больше конфигурациях отказоустойчивого кластера Windows или Pacemaker. Развертывание нескольких центральных служб SAP на двух узлах в конфигурации отказоустойчивого кластера может значительно сократить число виртуальных машин. Однако развертывание нескольких экземпляров центральных служб SAP на одном кластере с двумя узлами также имеет некоторые недостатки. Проблемы, характерные для конфигурации кластера с одной виртуальной машиной, распространяются и на варианты с несколькими системами SAP. Для выполнения обслуживания в гостевой ОС, работающей в конфигурации кластера, требуется более высокий уровень координирования, поскольку при этом затрагивается несколько производственных систем SAP. Такие инструменты, как SAP LaMa, не поддерживают много sid кластеризация в процессе клонирования системы.

В Azure конфигурация кластера с несколькими идентификаторами безопасности поддерживается для операционной системы Windows с архитектурами ENSA1 и ENSA2. Рекомендуется не объединить старую архитектуру службы репликации Enqueue (ENSA1) с новой архитектурой (ENSA2) в одном кластере с несколькими идентификаторами БЕЗОПАСНОСТИ. Сведения об этой архитектуре приводятся в следующих статьях

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

  • Не более пяти экземпляров SAP ASCS/SCS
  • Старая архитектура сервера репликации в очереди (ENSA1)
  • Конфигурации кластера Pacemaker с двумя узлами

Эта конфигурация описана в Руководстве по обеспечению высокого уровня доступности виртуальных машин Azure для SAP NetWeaver на SUSE Linux Enterprise Server для приложений SAP в случае использования нескольких идентификаторов безопасности

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

Diagram that shows a multi-SID cluster with Enqueue Replication server.

Сценарии горизонтального масштабирования SAP HANA

Сценарии горизонтального масштабирования SAP HANA поддерживаются для некоторой части виртуальных машин Azure, сертифицированных HANA, как указано в Каталоге оборудования SAP HANA. Все виртуальные машины с пометкой "Да" в столбце "Кластеризация" можно использовать для горизонтального масштабирования OLAP или S/4HANA. Конфигурации без резервирования поддерживаются в следующих типах хранилища Azure:

Конфигурации SAP HANA с горизонтальным масштабированием для OLAP или S/4HANA с резервными узлами поддерживаются только в варианте с общими ресурсами NFS, размещенными на Azure NetApp Files.

Дополнительные сведения о точной конфигурации хранилища с резервным узлом или без него приводятся в статьях:

Сценарий аварийного восстановления

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

Уровень СУБД

Для уровня СУБД поддерживаются конфигурации, в которых используются собственные механизмы репликации СУБД, такие как Always On, Oracle Data Guard, DB2 HADR, SAP ASE Always-on или репликация системы HANA. В таких случаях поток реплика tion является асинхронным, а не синхронным, как в типичных сценариях высокой доступности, развернутых в одном регионе Azure. Типичный пример такой поддерживаемой конфигурации аварийного восстановления СУБД описывается в статье Доступность SAP HANA в регионах Azure. На втором рисунке в этом разделе в качестве примера описывается сценарий с решением HANA. В таком сценарии можно развернуть основные базы данных, поддерживаемые приложениями SAP.

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

  • Небольшие типы виртуальных машин не позволяют подключить много дисков, чем небольшие виртуальные машины.
  • У небольших виртуальных машин более низкая пропускная способность сети и хранилища
  • Изменение размера между семействами виртуальных машин может быть проблемой при сборе разных виртуальных машин в одной группе доступности Azure или при изменении размера между семейством виртуальных машин серии M и семейством виртуальных машин Mv2
  • Доступность экземпляра базы данных потребления ресурсов ЦП и памяти для получения потока изменений с минимальной задержкой и достаточность ресурсов ЦП и памяти для применения этих изменения с минимальной задержкой к данным

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

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

Примечание.

Использование Azure Site Recovery не тестировалось для развертываний СУБД при рабочей нагрузке SAP. В результате это не поддерживается для уровня СУБД систем SAP на данный момент времени. Другие методы реплика от Корпорации Майкрософт и SAP, которые не перечислены, не поддерживаются. Использование программного обеспечения от сторонних разработчиков для репликации уровня СУБД систем SAP между различными регионами Azure должно поддерживаться поставщиком программного обеспечения и не будет поддерживаться по каналам предоставления поддержки Майкрософт и SAP.

Уровень, не относящийся к СУБД

Для уровня приложений SAP и необходимых общих папок или расположений хранилища два основных сценария используются клиентами:

  • Целевые показатели аварийного восстановления во втором регионе Azure не используются для производственных или нерабовременных целей. В этом сценарии виртуальные машины, функционирующие в качестве цели аварийного восстановления, в идеальном случае не разворачиваются, а образ и изменения в образах производственного уровня приложений SAP реплицируются в регион аварийного восстановления. Такую задачу может выполнить функция Azure Site Recovery. Azure Site Recovery поддерживает такой сценарий репликации из Azure в Azure.
  • Целевые объекты аварийного восстановления — это виртуальные машины, которые фактически используются непроизводственными системами. Весь ландшафт SAP распределяется между двумя разными регионами Azure, при этом производственные системы обычно находятся в одном регионе, а непроизводственные системы — в другом регионе. Во многих клиентских развертываниях у клиента имеется непроизводственная система, эквивалентная производственной системе. У клиента есть экземпляры приложений, предварительно установленные на непроизводственных системах уровня приложения. В случае отработки отказа экземпляры, не являющиеся рабочими, будут завершены, виртуальные имена рабочих виртуальных машин перемещены на нерабопроизводительные виртуальные машины (после назначения новых IP-адресов в DNS), а предварительно установленные рабочие экземпляры начинаются.

Кластеры центральных служб SAP

Кластеры центральных служб SAP, которые используют общие диски (Windows), общие ресурсы SMB (Windows) или общие ресурсы NFS, реплицировать сложнее. На стороне Windows возможным решением является репликация хранилища Windows. В Linux rsync — это жизнеспособное решение. Кроме того, реплика между регионами Azure NetApp Files является жизнеспособным решением.

Неподдерживаемый сценарий

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

  • служба хранилища мягкие (модуль): на рынке существуют различные мягкие (модуль) хранения. Некоторые поставщики предлагают собственную документацию по использованию своих мягких (модуль) хранилища в Azure, связанной с программным обеспечением SAP. Поддержка конфигураций или развертываний, связанных с такими мягкими (модуль) хранилища, должна предоставляться поставщиком обратимой (модуль) хранилища. Этот факт также указывается в примечании о поддержке SAP #2015553
  • Платформы с высоким уровнем доступности: только Pacemaker и отказоустойчивый кластер Windows Server являются поддерживаемыми платформами с высоким уровнем доступности для рабочей нагрузки SAP в Azure. Как упоминалось ранее, решение SIOS Datakeeper описано и учтено в документах корпорации Майкрософт. Тем не менее поддержка компонентов SIOS Datakeeper должна осуществляться средствами SIOS, то есть поставщиком, предоставляющим эти компоненты. В различных примечаниях SAP также перечислены другие сертифицированные платформы с высоким уровнем доступности. Некоторые из них были также сертифицированы сторонними поставщиками для Azure. Тем не менее поддержка конфигураций, где используются эти продукты, должна предоставляться поставщиком продукта. У разных поставщиков отличается интеграция с процессами поддержки SAP. Перед решением об использовании продукта с конфигурациями SAP, развернутыми в Azure, следует уточнить, какой процесс поддержки лучше подходит для конкретного поставщика.
  • Общие кластеры дисков, в которых файлы базы данных находятся на общих дисках, не поддерживаются, за исключением maxDB. Для всех остальных баз данных поддерживается решение с отдельными местами хранения, а не с общей папкой SMB или NFS или общим диском для настройки сценариев с высоким уровнем доступности.

Другие сценарии, которые не поддерживаются, являются такими сценариями:

  • Сценарии развертывания, которые представляют большую задержку сети между уровнем приложений SAP и уровнем СУБД SAP, как в NetWeaver, S/4HANA и например. Hybris К ним относятся:
    • Развертывание одного из уровней локально, в то время как другой уровень развертывается в Azure.
    • Развертывание уровня приложений SAP системы в другом регионе Azure, отличающимся от региона с уровнем СУБД
    • Развертывание одного уровня в центрах обработки данных, которые находятся в Azure и другом уровне в Azure, за исключением случаев, когда такой шаблон архитектуры предоставляется собственной службой Azure.
    • Развертывание сетевых виртуальных модулей между уровнем приложений SAP и уровнем СУБД
    • Использование хранилища, размещенного в центрах обработки данных, расположенных в центре обработки данных Azure для уровня СУБД SAP или глобального каталога транспорта SAP
    • Развертывание двух слоев с продуктами от двух разных поставщиков облачных решений. Например, развертывание уровня СУБД в облачной инфраструктуре Oracle и уровня приложений в Azure
  • Конфигурации кластера с несколькими экземплярами HANA Pacemaker
  • Конфигурации кластера Windows с общими дисками, реализованные с помощью SOFS или SMB на основе ANF для баз данных SAP, поддерживаемых в Windows. Вместо этого варианта рекомендуется использовать собственную репликацию с высоким уровнем доступности для определенных баз данных, а также отдельные стеки хранилища
  • Развертывание баз данных SAP в Linux с файлами базы данных, расположенными в общих папках NFS на вершине ANF, за исключением SAP HANA, Oracle в Oracle Linux и Db2 в Suse и Red Hat
  • Развертывание СУБД Oracle в любой другой гостевой ОС, отличающейся от Windows и Oracle Linux. См. также Примечание о поддержке SAP #2039619

Сценарии, которые мы не проверили и поэтому не имели опыта работы со списком, например:

  • Виртуальные машины для репликации уровня СУБД с помощью Azure Site Recovery. В результате мы рекомендуем использовать собственные асинхронные функции асинхронного реплика tion базы данных для потенциальной конфигурации аварийного восстановления.

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

Со следующими шагами можно ознакомиться в статье Планирование и внедрение виртуальных машин Azure для SAP NetWeaver