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

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

Примечание.

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

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

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

Помимо локальных служб Active Directory, Azure предлагает управляемый сервис Active Directory в форме SaaS с использованием Microsoft Entra Domain Services (традиционные службы Active Directory, управляемые Microsoft) и Microsoft Entra ID. Компоненты 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.

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

Простая 2-уровневая конфигурация

Такие конфигурации поддерживаются в ОС 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. В самой простой настройке высокая готовность гарантируется только соглашениями об уровне обслуживания Azure, применимыми к различным компонентам Azure.

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

Схема: простая 3-уровневая конфигурация.

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

Примечание.

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

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

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

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

Несколько экземпляров СУБД в одной единице

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

Для выполнения нескольких экземпляров базы данных на одном узле необходимо убедиться, что разные экземпляры не конкурируют за ресурсы и тем самым не превышают ограничения физических ресурсов виртуальной машины (ВМ). Это особенно актуально для памяти, где необходимо установить ограничение на объем памяти, который может выделить любой экземпляр, использующий общую виртуальную машину. Это также справедливо для ресурсов ЦП, которые могут потреблять разные экземпляры базы данных. Все упомянутые системы баз данных имеют конфигурации, позволяющие ограничить выделение памяти и ресурсы ЦП на уровне экземпляра. Чтобы обеспечить поддержку такой конфигурации для виртуальных машин 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, может выглядеть следующим образом:

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

Для упрощения мы не различали между SAP Central Services и SAP dialog instances в прикладном уровне 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.

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

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

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

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

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

Внимание

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

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

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

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

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

Конфигурация СУБД и ASCS для высокой доступности

В правой части рисунка отображены Центральные службы SAP с высоким уровнем доступности. Помимо защиты служб SAP Central с помощью платформы отказоустойчивого кластера, которая может выполнить отработку отказа в сценариях сбоя. Существует необходимость в высокодоступном сетевом ресурсе NFS или SMB, либо общем диске 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. Общие папки SMB, размещенные в службах файлов 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 или SMB, которые теоретически можно также использовать в кластеризованных, обеспечивающих отказоустойчивость службах SAP Central Services. Эти решения не поддерживаются непосредственно для рабочей нагрузки SAP корпорацией Майкрософт. Если вы намерены использовать такое решение для создания общего ресурса NFS или SMB, поддержка конфигурации Центральной службы SAP должна предоставляться сторонним поставщиком, являющимся владельцем программного обеспечения в программном устройстве хранения.

Кластеры отказоустойчивости для SAP Central Services с несколькими SID

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

В Azure конфигурация кластера с несколькими идентификаторами безопасности поддерживается для операционной системы Windows с архитектурами ENSA1 и ENSA2. Рекомендуется не объединять старую архитектуру службы репликации Enqueue (ENSA1) с новой архитектурой (ENSA2) на одном много-SID кластере. Сведения об этой архитектуре приводятся в следующих статьях

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

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

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

Схематическое изображение кластера с несколькими SID и сервером Enqueue Replication выглядит следующим образом

Схема, показывающая кластер с несколькими SID и сервером репликации Enqueue.

Сценарии горизонтального масштабирования 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. В таких случаях поток репликации обязательно должен быть асинхронным, а не синхронным, как в типичных сценариях высокой доступности, развернутых в одном регионе Azure. Типичный пример такой поддерживаемой конфигурации аварийного восстановления СУБД описывается в статье Доступность SAP HANA в регионах Azure. На втором рисунке в этом разделе описывается сценарий с HANA в качестве примера. В таком сценарии можно развернуть основные базы данных, поддерживаемые приложениями SAP.

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

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

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

Еще один поддерживаемый метод развертывания цели аварийного восстановления — установить второй экземпляр СУБД на виртуальной машине, на которой работает непроизводственный экземпляр СУБД для непроизводственной инсталляции 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 и Microsoft не могут предоставлять поддержку для этих конфигураций и должны полагаться на любое задействованное стороннее лицо, предоставившее программное обеспечение для таких архитектур. Двумя категориями подобного типа являются:

  • Мягкие устройства хранения: на рынке существуют различные мягкие устройства хранения. Некоторые поставщики предлагают собственную документацию по использованию своих программных устройств хранения в 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 Linux и Red Hat Linux.
  • Развертывание СУБД Oracle в любой другой гостевой ОС, отличающейся от Windows и Oracle Linux. См. также Примечание о поддержке SAP #2039619

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

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

Дальнейшие шаги

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

  • Last updated on