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

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

  • Статья

Внимание

В ноябре 2021 года мы внесли существенные изменения в способ использования групп размещения близкого взаимодействия с рабочей нагрузки 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 или основную сеть. Дополнительные сведения об этом случае см. в разделе Группы размещения близкого взаимодействия.

Внимание

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

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

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

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

Что касается сценария развертывания #2, во многих регионах, особенно без зон доступности и большинства регионов с зонами доступности, задержка сети не зависит от того, где виртуальные машины могут быть приемлемыми. Хотя есть некоторые регионы Azure, которые не могут обеспечить достаточно хороший интерфейс без сортировки трех разных групп доступности без использования групп размещения близкого взаимодействия.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

Важно понимать, что диски виртуальных машин уровня приложений не будут выделены в той же зоне доступности, что и виртуальные машины, направленные на использование группы размещения близкого взаимодействия. Результат развертывания, показанного на следующих шагах, может быть, что виртуальные машины выделяются в том же сетевом позвоночнике и с той же зоной доступности, что и виртуальная машина привязки. Но не могут быть выделены диски с повтором (базовый VHD и подключенные диски хранилища блоков 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 Central Services (ASCS/SCS).

Примечание.

Поскольку одна виртуальная машина СУБД и ASCS/SCS развертывается в одной зоне, а вторая виртуальная машина СУБД и ASCS/SCS — в другой, для создания конфигураций с высоким уровнем доступности для каждой зоны нужна другая группа размещения близкого взаимодействия. Это требование справедливо для любой используемой группы доступности.

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

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

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

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

Чтобы избежать ограничений, связанных с группой размещения близкого взаимодействия, рекомендуется развернуть рабочую нагрузку SAP в зонах доступности с помощью гибкого масштабируемого набора с FD=1. Эта стратегия развертывания гарантирует, что виртуальные машины, развернутые в каждой зоне, не ограничены одним центром обработки данных или сетевым позвоночником, а все компоненты системы SAP, такие как базы данных, ASCS/ERS и уровень приложений, находятся в пределах зоны. При использовании всех системных компонентов SAP на зональном уровне задержка сети между разными компонентами одной системы SAP должна быть достаточной, чтобы обеспечить удовлетворительную производительность и пропускную способность. Ключевое преимущество этого нового варианта развертывания с гибким масштабируемым набором с FD=1 заключается в том, что она обеспечивает большую гибкость при изменении размера виртуальных машин или переключении на новые типы виртуальных машин для всех уровней системы SAP. Кроме того, масштабируемый набор выделяет виртуальные машины в нескольких доменах сбоя в одной зоне, что идеально подходит для запуска нескольких виртуальных машин уровня приложений в каждой зоне. Дополнительные сведения см. в статье о масштабируемом наборе виртуальных машин для документа рабочей нагрузки 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, можно также определить имя группы размещения близкого взаимодействия, так как оно было создано при развертывании единицы крупных экземпляров HANA. Имя, отображаемое в разделе атрибутов "Общие сведения" — это имя группы размещения близкого взаимодействия, в которую следует разворачивать виртуальные машины уровня приложений.

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

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

Схема групп размещения близкого взаимодействия и крупных экземпляров HANA.

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

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