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

Приложения SAP на основе архитектуры SAP NetWeaver или SAP S/4HANA чувствительны к сетевой задержке, существующей между уровнем приложений SAP и уровнем базы данных SAP. Эта чувствительность является следствием того, что большая часть ресурсов бизнес-логики работает на уровне приложений. Поскольку бизнес-логика реализуется на уровне приложений SAP, запросы с этого уровня на уровень базы данных отправляются с высокой частотой, измеряемой тысячами или десятками тысяч раз в секунду. В большинстве случаев характер этих запросов прост. Часто они могут выполняться на уровне базы данных за 500 микросекунд или меньше.

Время отправки запроса с уровня приложения на уровень базы данных и возвращение результата значительно влияет на производительность. Эта задержка напрямую влияет на время выполнения бизнес-процессов. Эта чувствительность к сетевой задержке служит основанием для того, чтобы в проектах развертывания SAP реализовать определенную минимальную задержку в сети. С указаниями по классификации сетевой задержки можно ознакомиться в Примечании для SAP #1100926 — вопросы и ответы: производительность сети.

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

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

• Группы ближайшего размещения
• Масштабируемый набор виртуальных машин с гибкой оркестрацией

Группы близкого размещения

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

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

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

• Сценарий 1. Необходимо развернуть критически важные ресурсы рабочей нагрузки SAP в разных зонах доступности. В то же время необходимо, чтобы виртуальные машины уровня приложений распределялись по разным доменам сбоя с помощью групп доступности в каждой зоне. В этом случае, как описано далее в документе, группы размещения близкого взаимодействия необходимы.

• Сценарий 2. Развертывание рабочей нагрузки SAP с группами доступности. Где уровень базы данных SAP, уровень приложений SAP и виртуальные машины ASCS/SCS группируются в три разных набора доступности. В этом случае необходимо убедиться, что группы доступности не распределены по всему региону Azure. В зависимости от региона Azure задержка сети негативно влияет на рабочую нагрузку SAP.

• Сценарий 3: Группы размещения по близости используются для группирования виртуальных машин с целью достижения минимальной возможной задержки сети между службами, размещенными на виртуальных машинах. Например, задержка в пределах зоны доступности не соответствует требованиям приложения.

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

Что такое группы размещения близкого взаимодействия?

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

• Первая виртуальная машина Azure была развернута в сетевом каркасе, обеспечивающем множество вычислительных мощностей Azure и низкую задержку сети. Такая основная сеть часто соответствует одному центру обработки данных Azure. Вы можете воспринимать первую виртуальную машину как "виртуальную машину в рамках", которая развертывается в единице масштабирования вычислительных ресурсов Azure на основе алгоритмов выделения ресурсов Azure, объединенных с параметрами развертывания.
• На всех последующих виртуальных машинах, ссылающихся на группу размещения с учетом близости, будет обеспечено развертывание в том же сетевом сегменте, что и первая виртуальная машина.

Чтобы снизить этот риск, рекомендуется использовать опцию Intent при создании группы проксимального размещения. Параметр намерения позволяет перечислить типы виртуальных машин, которые планируется включить в группу размещения близкого взаимодействия. Этот список типов виртуальных машин используется для поиска лучшего центра обработки данных, на котором размещаются эти типы виртуальных машин. Если такой центр обработки данных найден, создается и определяется PPG, охватывая центр обработки данных, который соответствует требованиям SKU виртуальной машины. Если такой центр обработки данных не найден, создание группы для размещения вблизи завершится ошибкой. Дополнительные сведения см. в документации PPG — Использование намерений для указания размеров виртуальных машин. Помните, что фактические ситуации с емкостью не учитываются в проверках, инициированных параметром намерения. В результате всё ещё могут возникать ошибки выделения ресурсов, вызванные недостаточной доступной емкостью.

Одна группа ресурсов Azure может иметь несколько групп близкого размещения. Но группа размещения близкого взаимодействия может быть назначена только одной группе ресурсов Azure.

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

Группы близкого размещения с зональными развертываниями

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

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

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

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

Разница в рассмотренной выше рекомендации заключается в том, что виртуальные машины базы данных в двух зонах больше не являются частью групп ближнего размещения. Группы временного размещения для каждой зоны теперь ограничены развертыванием виртуальной машины, на которой выполняются экземпляры SAP ASCS/SCS. Этот объём задачи также означает, что в регионах, где зоны доступности состоят из нескольких центров обработки данных, экземпляр ASCS/SCS и уровень приложения могут работать под одним сетевым каркасом. Виртуальные машины базы данных могут работать с другой магистралью сети. Несмотря на улучшения сети, сетевая задержка между уровнем приложения SAP и уровнем СУБД все равно должна быть достаточно низкой, чтобы обеспечить нужную производительность и пропускную способность. Преимущество этой новой конфигурации заключается в том, что вы обладаете большей гибкостью при изменении размера виртуальных машин или переходе на новые типы виртуальных машин для уровня СУБД. Вы также получаете эту гибкость для уровня приложений системы SAP.

Группы размещения близкого взаимодействия могут потребоваться при использовании Azure NetApp Files для среды СУБД, а также группы томов приложений Azure NetApp Files для функциональных возможностей SAP HANA. См. также тома NFS версии 4.1 в Azure NetApp Files для SAP HANA.

Развертывания с использованием групп проксимального размещения в сочетании с наборами доступности

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

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

Комбинирование наборов доступности и зон доступности с группами размещения на основе близости

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

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

• Создайте группу размещения близкого взаимодействия.
• Разверните опорную виртуальную машину, рекомендуется использовать виртуальную машину ASCS/SCS, указав зону доступности.
• Создайте группу доступности, которая ссылается на группу близкого размещения Azure.
• Разверните виртуальные машины уровня этих приложений, учитывая набор доступности и группу размещения по близости.

Вместо развертывания первой виртуальной машины, как показано в предыдущем разделе, при развертывании виртуальной машины вы указываете зону доступности и группу близкого размещения.

New-AzVm -ResourceGroupName "ppgexercise" -Name "centralserviceszone1" -Location "westus2" -OpenPorts 80,3389 -Zone "1" -ProximityPlacementGroup "collocate" -Size "Standard_E8s_v4"

Успешное развертывание этой виртуальной машины будет размещать экземпляр ASCS/SCS системы SAP в одной зоне доступности. В этом случае виртуальная машина, базовый виртуальный жесткий диск виртуальной машины и потенциально подключенные диски хранилища блоков Azure находятся в одной зоне доступности. Область группы близкого размещения привязана к одному из сетевых магистралей в определенной зоне доступности.

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

Определите и создайте группу близкого размещения. Команде для создания группы доступности требуется указать идентификатор группы размещения вблизи (не имя). Вы можете получить идентификатор группы близкого размещения с помощью этой команды:

Get-AzProximityPlacementGroup -ResourceGroupName "ppgexercise" -Name "collocate"

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

New-AzAvailabilitySet -ResourceGroupName "ppgexercise" -Name "ppgavset" -Location "westus2" -ProximityPlacementGroupId "/subscriptions/my very long ppg id string" -Sku "aligned" -PlatformUpdateDomainCount 3 -PlatformFaultDomainCount 2

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

New-AzVm -ResourceGroupName "ppgexercise" -Name "appinstance1" -Location "westus2" -OpenPorts 80,3389 -AvailabilitySetName "myppgavset" -ProximityPlacementGroup "collocate" -Size "Standard_E16s_v4"

Результат этого развертывания будет выглядеть следующим образом:

• Центральные службы для вашей системы SAP, располагающиеся в определённой зоне или зонах доступности.
• Уровень приложений SAP, расположенный через наборы доступности в том же сетевом каркасе, что и виртуальная машина или машины центральных служб SAP (ASCS/SCS).

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

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

• Разверните виртуальные машины в группах проксимального размещения с помощью Azure CLI.
• Развертывание виртуальных машин в группах размещения близкого взаимодействия с помощью PowerShell.

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

Масштабируемый набор виртуальных машин с гибкой оркестрацией

Чтобы избежать ограничений, связанных с группой размещения близкого взаимодействия, рекомендуется развернуть рабочую нагрузку SAP в зонах доступности с помощью гибкого масштабируемого набора FD=1. Эта стратегия развертывания гарантирует, что виртуальные машины, развернутые в каждой зоне, не ограничены одним центром обработки данных или сетевым позвоночником. Все системные компоненты SAP, такие как базы данных, ASCS/ERS и уровень приложений, находятся в пределах зоны. При использовании всех системных компонентов SAP на зональном уровне задержка сети между разными компонентами одной системы SAP должна быть достаточной, чтобы обеспечить удовлетворительную производительность и пропускную способность. Основное преимущество этого нового варианта развертывания с помощью гибкого масштабируемого набора FD=1заключается в том, что она обеспечивает большую гибкость для изменения размера виртуальных машин или переключения на новые типы виртуальных машин во всех уровнях системы SAP. Кроме того, набор для масштабирования выделяет виртуальные машины в нескольких доменах сбоя в одной зоне, что идеально подходит для запуска нескольких виртуальных машин уровня приложения в каждой зоне. Дополнительные сведения см. в статье о масштабируемом наборе виртуальных машин для рабочей нагрузки SAP.

В не рабочей или не в режиме высокой доступности среде можно развернуть все системные компоненты SAP, включая базу данных, ASCS и уровень приложений, в пределах одной зоны. В этом развертывании используется гибкий масштабируемый набор с FD=1.

Ранее рекомендуемые варианты развертывания

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

Группы близкого размещения для всей системы SAP с зональными развертываниями

Использование группы близкого размещения, которое до сих пор мы рекомендовали, выглядит, как показано на рисунке.

Схема групп старого близкого размещения с зонами.

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

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

Группы близкого размещения и крупные экземпляры HANA

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

Чтобы определить, развернута ли единица крупных экземпляров HANA в метке или строке версии 4, ознакомьтесь со статьей Управление крупными экземплярами Azure HANA с помощью портала Azure. В обзоре атрибутов вашего блока HANA Large Instances вы также можете определить имя группы размещения (proximity placement group), которое было присвоено при развертывании блока HANA Large Instances. Имя, отображаемое в общем обзоре атрибутов, — это имя группы близкого размещения, в которую следует развертывать виртуальные машины уровня приложений.

По сравнению с системами SAP, использующими только виртуальные машины Azure, крупные экземпляры HANA предоставляют меньше гибкости при выборе количества групп ресурсов Azure. Все единицы HANA Large Instances типа "HANA Large Instances tenant" объединены в одну группу ресурсов, как описано в этой статье. Если вы не развертываете в разных арендаторах отдельные, например, рабочие и нерабочие системы или другие системы, все экземпляры HANA Large Instances развертываются в одном арендаторе HANA Large Instances. Этот клиент взаимодействует с группой ресурсов по принципу "один к одному". Но для каждого из отдельных единиц определяется отдельная группа размещения близкого взаимодействия.

В результате связи между группами ресурсов Azure и группами близкого размещения для одного клиента показаны здесь:

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

См. следующую документацию:

• Контрольный список для планирования и развертывания рабочих нагрузок SAP в Azure
• Развертывание виртуальных машин в группах близко расположенного размещения средствами Azure CLI
• Развертывание виртуальных машин в группах близкого размещения с помощью PowerShell
• Важные аспекты развертывания СУБД для рабочих нагрузок SAP на виртуальных машинах Azure