SAP S/4HANA в Linux в Azure

В этом руководстве представлен набор проверенных рекомендаций по запуску S/4HANA и Suite в HANA в среде высокой доступности, поддерживающей аварийное восстановление (АВАРИЙНОе восстановление) в Azure. Сведения о Fiori применимы только к приложениям S/4HANA.

Архитектура

Скачайте файл Visio для этой архитектуры.

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

В этом руководстве макет сети значительно упрощен для демонстрации принципов архитектуры. Она не предназначена для описания полной корпоративной сети.

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

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

Пиринг между виртуальными сетями. Эта архитектура использует несколько виртуальных сетей, одноранговых. Эта топология предлагает сегментацию сети и изоляцию для служб, развернутых в Azure. Пиринг подключает сети прозрачно через магистральную сеть Майкрософт и не несет штрафа на производительность при реализации в одном регионе. Отдельные подсети используются для каждого приложения уровня (SAP NetWeaver), базы данных и для общих служб, таких как поле перехода и Windows Server Active Directory.

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

• Уровень приложения. Этот архитектурный уровень включает в себя пул серверов внешнего интерфейса Fiori, пул веб-диспетчера SAP, пул серверов приложений и кластер SAP Central Services. Для обеспечения высокой доступности центральных служб в Azure, работающей на виртуальных машинах Linux, требуется высокодоступная сетевая служба общего файлового ресурса, например общие папки NFS в Файлы Azure, Azure NetApp Files, кластеризованные серверы сетевой файловой системы (NFS) или пакет защиты SIOS для Linux. Чтобы настроить высокодоступную общую папку для кластера Центральных служб в Red Hat Enterprise Linux (RHEL), можно настроить GlusterFS на виртуальных машинах Azure, работающих под управлением RHEL. В SUSE Linux Enterprise Server (SLES) 15 с пакетом обновления 1 (SP1) и более поздних версиях или SLES для приложений SAP можно использовать общие диски Azure в кластере Pacemaker для обеспечения высокой доступности.

• SAP HANA. Уровень базы данных использует две или более виртуальных машин Linux в кластере для обеспечения высокой доступности в развертывании масштабирования. Репликация системы HANA (HSR) используется для репликации содержимого между основными и вторичными системами HANA. Кластеризация Linux применяется для обнаружения сбоев системы и упрощения автоматического перехода на другой ресурс. Механизм ограждения на основе хранилища или облачного ограждения должен использоваться, чтобы обеспечить изоляцию или завершение работы системы, чтобы избежать состояния разбиения мозга в кластере. В развертываниях горизонтального масштабирования HANA можно обеспечить высокий уровень доступности базы данных с помощью одного из следующих вариантов:

  • Настройте резервные узлы HANA с помощью Azure NetApp Files без компонента кластеризации Linux.
  • Горизонтальное масштабирование без резервных узлов с помощью хранилища Azure класса Premium. Используйте кластеризацию Linux для отработки отказа.

• Бастион Azure. Эта служба позволяет подключаться к виртуальной машине с помощью браузера и портал Azure или через собственный клиент SSH или RDP, который уже установлен на локальном компьютере. Если для администрирования используются только протоколы RDP и SSH, Бастион Azure — это отличное решение. Если вы используете другие средства управления, такие как SQL Server Management Studio или интерфейс SAP, используйте традиционное саморазверяемое поле перехода.

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

Подсистемы балансировки нагрузки. Чтобы распространить трафик на виртуальные машины в подсети уровня приложений SAP для обеспечения высокой доступности, рекомендуется использовать Azure Load Balancer (цен. категория . Обратите внимание, что Load Balancer (цен. категория предоставляет уровень безопасности по умолчанию. Виртуальные машины, которые находятся за Load Balancer (цен. категория , не имеют исходящего подключения к Интернету. Чтобы включить исходящий интернет на виртуальных машинах, необходимо обновить конфигурацию Load Balancer (цен. категория . Шлюз NAT Azure также можно использовать для получения исходящего подключения. Для высокодоступного веб-приложения SAP используйте встроенный веб-диспетчер SAP или другой коммерчески доступный балансировщик нагрузки. В зависимости от выбранного варианта:

• Тип трафика, например HTTP или SAP GUI.
• Необходимые сетевые службы, такие как завершение протокола SSL.

Load Balancer (цен. категория поддерживает несколько внешних виртуальных IP-адресов. Эта поддержка идеально подходит для реализаций кластера, которые включают следующие компоненты:

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Сервер постановки в очередь для репликации (ERS)

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

Load Balancer (цен. категория также поддерживает кластеры SAP с несколькими идентификаторами (multi-SID). Другими словами, несколько систем SAP в SLES или RHEL могут совместно использовать общую инфраструктуру высокого уровня доступности для снижения затрат. Рекомендуется оценить экономию затрат и избежать размещения слишком большого количества систем в одном кластере. поддержка Azure не более пяти идентификаторов SID на кластер.

Шлюз приложений. Шлюз приложений Azure — это подсистема балансировки нагрузки веб-трафика, которую можно использовать для управления трафиком в веб-приложениях. Традиционные подсистемы балансировки нагрузки работают на транспортном уровне (уровень 4 OSI — TCP и UDP). Они направляют трафик на основе исходного IP-адреса и порта в конечный IP-адрес и порт. Шлюз приложений может принимать решения о маршрутизации на основе дополнительных атрибутов HTTP-запроса, таких как путь URI или заголовки узла. Этот тип маршрутизации называется балансировкой нагрузки на уровне приложения (уровень 7 OSI). S/4HANA предлагает службы веб-приложений через Fiori. Вы можете сбалансировать эту интерфейсную часть Fiori, состоящую из веб-приложений, с помощью Шлюз приложений.

Шлюз Шлюз подключает отдельные сети и расширяет локальную сеть к виртуальной сети Azure. Azure ExpressRoute — это рекомендуемая служба Azure для создания частных подключений, которые не проходят через общедоступный Интернет, но вы также можете использовать подключение типа "сеть — сеть ". Чтобы уменьшить задержку, ExpressRoute Global Reach и ExpressRoute FastPath — это параметры подключения, которые рассматриваются далее в этой статье.

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

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

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

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

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

Рекомендации

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

Виртуальные машины

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

Дополнительные сведения о поддержке SAP для типов виртуальных машин Azure и метрик пропускной способности (SAPS) см. в 1928533 заметки SAP. Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace. Список сертифицированных виртуальных машин Azure для базы данных HANA см. в каталоге оборудования SAP Certified и Support SAP HANA.

Веб-диспетчер SAP

Компонент веб-диспетчера используется для балансировки трафика SAP между серверами приложений SAP. Чтобы обеспечить высокий уровень доступности веб-диспетчера SAP, Azure Load Balancer реализует отказоустойчивый кластер или параллельную настройку веб-диспетчера. Для связи с Интернетом автономное решение в сети периметра является рекомендуемой архитектурой для удовлетворения проблем безопасности. Внедренный веб-диспетчер в ASCS — это специальный параметр. Если этот параметр используется, рассмотрите правильный размер из-за дополнительной рабочей нагрузки в ASCS.

Внешний сервер Fiori (FES)

Эта архитектура отвечает многим требованиям и предполагает, что используется внедренная модель Fiori FES. Все компоненты технологии устанавливаются в самой системе S/4, что означает, что каждая система S/4 имеет собственную панель запуска Fiori. Настройка высокой доступности для этой модели развертывания заключается в том, что система S/4 не требует дополнительной кластеризации или виртуальных машин. По этой причине схема архитектуры не отображает компонент FES.

Описание основных вариантов развертывания (внедренных или центральных) в зависимости от сценариев см. в разделе "Варианты развертывания SAP Fiori" и системные рекомендации. Для простоты и производительности выпуски программного обеспечения между компонентами технологии Fiori и приложениями S/4 тесно связаны. Эта настройка делает развертывание концентратора, которое подходит только для нескольких узких вариантов использования.

Если вы используете развертывание центра FES, FES является компонентом надстройки для классического стека SAP NetWeaver ABAP. Настройте высокий уровень доступности так же, как вы защищаете стек приложений ABAP с тремя уровнями, которые имеют кластеризованную или многоузловую возможность: используйте резервный уровень базы данных сервера, кластеризованный уровень ASCS с высоким уровнем доступности NFS для общего хранилища и по крайней мере два сервера приложений. Трафик распределяется по паре экземпляров веб-диспетчера, которые могут быть кластеризованы или параллельны. Для приложений Fiori, подключенных к Интернету , рекомендуется развертывание концентратора FES в сети периметра. Используйте Azure Брандмауэр веб-приложений в Шлюз приложений в качестве критического компонента для отклонения угроз. Используйте идентификатор Microsoft Entra с SAML для проверки подлинности пользователей и единого входа для SAP Fiori.

В некоторых примерах проектирования входящих и исходящих подключений к Интернету см . сведения о входящих и исходящих подключениях к Интернету для SAP в Azure.

Пул серверов приложений

Для управления группами входа для серверов приложений ABAP обычно используется транзакция SMLG для балансировки нагрузки пользователей входа, чтобы использовать SM61 для групп серверов пакетной службы, использовать RZ12 для групп удаленных вызовов функций (RFC) и т. д. Эти транзакции используют функцию балансировки нагрузки, которая находится на сервере сообщений Центра служб для распределения входящих сеансов или рабочих нагрузок между пулом серверов приложений SAP, обрабатывающих ИНТЕРФЕЙСы API SAP и трафик RFC.

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

Центральные службы можно развернуть на одной виртуальной машине, если соглашение об уровне обслуживания на уровне обслуживания (SLA) azure с одним экземпляром соответствует вашему требованию. Однако виртуальная машина становится потенциальной точкой сбоя (SPOF) для среды SAP. Для развертывания высокодоступных центральных служб используйте NFS через Файлы Azure или службу Azure NetApp Files и кластер центральных служб.

Другим вариантом является использование общих дисков Azure для обеспечения высокой доступности. В SLES 15 с пакетом обновления 1 (SP1) и более поздней версии или SLES для приложений SAP вы можете настроить кластер Pacemaker с помощью общих дисков Azure для Linux.

Кроме того, можно использовать общую папку NFS для общего хранилища кластера Linux.

При развертывании Azure серверы приложений подключаются к центральным службам с высокой доступностью через имена виртуальных узлов центральных служб или служб ERS Services. Эти имена узлов назначаются интерфейсной IP-конфигурации интерфейса кластера подсистемы балансировки нагрузки. Load Balancer поддерживает несколько интерфейсных IP-адресов, поэтому для центральных служб и виртуальных IP-адресов ERS можно настроить одну подсистему балансировки нагрузки.

Поддержка кластера Linux для установки с несколькими идентификаторами безопасности ASCS в Azure теперь общедоступна. Совместное использование кластера доступности между несколькими системами SAP упрощает ландшафт SAP.

Сеть

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

Сетевые карты (NIC)

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

Сетевые карты Azure поддерживают несколько IP-адресов. Эта поддержка соответствует практике, которую SAP рекомендует использовать имена виртуальных узлов для установки, как описано в заметке SAP 962955. Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace.

Подсети и группы безопасности сети

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

При связывании группы безопасности сети с подсетью группа безопасности сети применяется ко всем серверам в подсети и обеспечивает точный контроль над серверами. Настройте группы безопасности сети с помощью портал Azure, PowerShell или Azure CLI.

Global Reach ExpressRoute

Если сетевая среда включает два или более каналов ExpressRoute, ExpressRoute Global Reach может помочь сократить сетевые прыжки и снизить задержку. Эта технология представляет собой пиринг маршрутизации протокола BGP, который настраивается между двумя или несколькими каналами ExpressRoute для моста двух доменов маршрутизации ExpressRoute. Global Reach снижает задержку, когда сетевой трафик проходит более одного канала ExpressRoute. В настоящее время он доступен только для частного пиринга в каналах ExpressRoute.

В настоящее время нет списков управления доступом к сети или других атрибутов, которые можно изменить в Global Reach. Поэтому все маршруты, полученные заданным каналом ExpressRoute (из локальной среды и Azure), объявляются через пиринг канала в другом канале ExpressRoute. Рекомендуется установить фильтрацию сетевого трафика локально, чтобы ограничить доступ к ресурсам.

Сведения об ExpressRoute FastPath

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

Для существующих каналов ExpressRoute обратитесь к поддержка Azure для активации FastPath.

FastPath не поддерживает пиринг между виртуальными сетями. Если другие виртуальные сети подключены к ExpressRoute, сетевой трафик из локальной сети в другие периферийные виртуальные сети отправляется в шлюз виртуальной сети. Обходной путь — подключение всех виртуальных сетей к каналу ExpressRoute напрямую.

Подсистемы балансировки нагрузки

Веб-диспетчер SAP обрабатывает балансировку нагрузки трафика HTTP(S) к пулу серверов приложений SAP. Эта подсистема балансировки нагрузки программного обеспечения предлагает службы уровня приложений (которые называются уровнем 7 в сетевой модели ISO), которые могут выполнять завершение SSL и другие функции разгрузки.

Load Balancer — это служба уровня передачи сети (уровень 4), которая балансирует трафик с помощью хэша пяти кортежей из потоков данных. Хэш основан на исходном IP-адресе, исходном порту, целевом IP-адресе, целевом порту и типе протокола. Load Balancer используется в настройках кластера для перенаправления трафика к основному экземпляру службы или работоспособному узлу в случае сбоя. Мы рекомендуем использовать Azure Load Balancer (цен. категория для всех сценариев SAP. Важно отметить, что Load Balancer (цен. категория по умолчанию безопасна, а виртуальные машины за Load Balancer (цен. категория не имеют исходящего подключения к Интернету. Чтобы включить исходящий интернет в виртуальных машинах, необходимо настроить конфигурацию Load Balancer (цен. категория .

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

Хранилище

Некоторые клиенты используют хранилище уровня "Стандартный" для своих серверов приложений. Так как стандартные управляемые диски не поддерживаются, как указано в заметке SAP 1928533, мы рекомендуем использовать управляемые диски Azure уровня "Премиум" или Azure NetApp Files во всех случаях. Недавнее обновление примечания к SAP 2015553 исключает использование стандартного хранилища HDD и хранилища SSD уровня "Стандартный" для нескольких конкретных вариантов использования.

Так как серверы приложений не размещают бизнес-данные, вы также можете использовать меньшие диски P4 и P6 класса Premium для управления затратами. Сведения о том, как тип хранилища влияет на соглашение об уровне обслуживания для виртуальной машины, см. в разделе об уровне обслуживания для Виртуальные машины. Для сценариев высокой доступности общие возможности дисков Azure доступны в SSD Azure уровня "Премиум" и в хранилище дисков Azure Ценовой категории "Ультра". Дополнительные сведения см. в статье об управляемых дисках Azure.

Общие диски Azure можно использовать с Windows Server, SLES 15 с пакетом обновления 1 (SP 1) и более поздней версии или SLES для SAP. При использовании общего диска Azure в кластерах Linux общий диск Azure выступает в качестве блочного устройства STONITH (SBD). Он предлагает голосование кворума в ситуации секционирования сети кластера. Этот общий диск не имеет файловой системы и не поддерживает одновременную запись из нескольких виртуальных машин-членов кластера.

Azure NetApp Files имеет встроенные функции общего доступа к файлам для NFS и SMB.

В сценариях общего доступа NFS Azure NetApp Files предоставляет доступность для общих папок NFS, которые можно использовать для /hana/sharedтомов, и /hana/log для них/hana/data. Сведения о гарантии доступности см. в статье об уровне обслуживания для Azure NetApp Files. При использовании общих папок NFS на основе Azure NetApp Files для /hana/data и /hana/log томов необходимо использовать протокол NFS версии 4.1. Для тома /hana/shared поддерживается протокол NFS версии 3.

Для хранилища данных резервного копирования рекомендуется использовать уровни доступа Azure cool и archive. Эти уровни хранилища являются экономичными способами хранения долговременных данных, которые редко обращаются. Вы также можете использовать стандартный уровень Azure NetApp Files в качестве целевого объекта резервного копирования или резервного копирования Azure NetApp Files. Для управляемого диска рекомендуемый уровень данных резервного копирования — это холодный или архивный уровень доступа Azure.

Хранилище дисков ценовой категории "Ультра" и "Ультра производительность Azure NetApp Files" значительно снижают задержку диска и критически важные для производительности приложения и серверы баз данных SAP.

Ssd Azure premium версии 2 предназначен для критически важных для производительности рабочих нагрузок, таких как SAP. Сведения о преимуществах решения хранилища и его текущих ограничениях см. в статье "Развертывание SSD уровня "Премиум" версии 2 .

Замечания, связанные с быстродействием

Серверы приложений SAP постоянно взаимодействуют с серверами баз данных. Для критически важных для производительности приложений, работающих на любой платформе базы данных, включая SAP HANA, включите ускоритель записи для тома журнала, если вы используете SSD класса Premium версии 1. Это позволяет улучшить задержку записи журналов. Ssd уровня "Премиум" версии 2 не использует ускоритель записи. Ускоритель записи доступен для виртуальных машин серии M.

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

Дополнительные сведения о требованиях к производительности SAP HANA см . в заметке SAP 1943937 — средство проверки конфигурации оборудования. Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace.

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

Ssd Azure premium версии 2 предназначен для критически важных для производительности рабочих нагрузок, таких как SAP. Ознакомьтесь с типами управляемых дисков Azure, чтобы узнать о своих преимуществах и ограничениях и оптимальных сценариях использования.

Хранилище дисков категории "Ультра" — это новое поколение хранилища , которое соответствует интенсивному ввод-выводам в секунду и требованиям пропускной способности передачи приложений, таких как SAP HANA. Вы можете динамически изменять производительность дисков ультра и независимо настраивать такие метрики, как операции ввода-вывода в секунду и МБ/с без перезагрузки виртуальной машины. Если доступно хранилище дисков ценовой категории "Ультра", рекомендуется вместо акселератора записи.

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

Размещение сетевого виртуального устройства (NVA) между приложением и уровнями базы данных любого стека приложений SAP не поддерживается. NVA требует значительного времени для обработки пакетов данных. В результате это неприемлемо замедляет производительность приложения.

Мы также рекомендуем учитывать производительность при развертывании ресурсов с зонами доступности, которые могут повысить доступность служб, как описано далее в этой статье. Рассмотрите возможность создания четкого профиля задержки сети между всеми зонами целевого региона. Этот подход поможет вам решить вопрос о размещении ресурсов для минимальной задержки между зонами. Чтобы создать этот профиль, запустите тест, развернув небольшие виртуальные машины в каждой зоне. Рекомендуемые средства для тестирования включают PsPing и Iperf. После тестирования удалите эти виртуальные машины. Для средства тестирования задержки сети общедоступного домена, которое можно использовать вместо этого, см . тест задержки зоны доступности.

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

Вопросы масштабируемости

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

На уровне базы данных эта архитектура выполняет приложения SAP HANA S/4 на виртуальных машинах Azure, которые могут масштабировать до 24 терабайтов (ТБ) в одном экземпляре. Если ваша рабочая нагрузка превышает максимальный размер виртуальной машины, можно использовать конфигурацию с несколькими узлами на 96 тб (4 x 24) для приложений для обработки транзакций в сети (OLTP). Дополнительные сведения см. в разделе "Сертифицированный и поддерживаемый каталог оборудования SAP HANA".

Вопросы доступности

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

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

Подходы к развертыванию

В Azure развертывание рабочей нагрузки SAP может быть региональным или зональным в зависимости от требований к доступности и устойчивости приложений SAP. Azure предоставляет различные варианты развертывания, такие как Масштабируемые наборы виртуальных машин с гибкой оркестрацией (FD=1), зонами доступности и группами доступности, чтобы повысить доступность ресурсов. Чтобы получить полное представление о доступных вариантах развертывания и их применимости в разных регионах Azure (включая между зонами, в пределах одной зоны или в регионе без зон), см . архитектуру и сценарии высокой доступности для SAP NetWeaver.

Веб-диспетчер на уровне серверов приложений

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

Центральные службы на уровне серверов приложений

Для обеспечения высокой доступности центральных служб на виртуальных машинах Linux Azure используйте соответствующее расширение высокой доступности для выбранного дистрибутива Linux. Обычно общие файловые системы помещают в хранилище NFS с высоким уровнем доступности с помощью SUSE DRBD или Red Hat GlusterFS. Чтобы обеспечить высокодоступную NFS и устранить необходимость в кластере NFS, можно использовать другие экономичные или надежные решения, такие как NFS через Файлы Azure или Azure NetApp Files. В качестве боковой заметки общие папки Azure NetApp Files могут размещать файлы данных и журналов SAP HANA. Эта настройка позволяет модели развертывания HANA масштабироваться с резервными узлами, а NFS по Файлы Azure хорошо подходит для высокодоступного общего доступа к файлам, отличным от базы данных.

NFS более Файлы Azure теперь поддерживает высокодоступные общие папки как для SLES, так и для RHEL. Это решение хорошо подходит для высокодоступных общих папок, /saptrans таких /sapmntкак в установках SAP.

Azure NetApp Files поддерживает высокий уровень доступности ASCS в SLES. Подробные сведения об ASCS в RHEL высокой доступности см. в разделе SIOS Protection Suite для Linux.

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

Другим вариантом является использование общих дисков Azure для обеспечения высокой доступности. В SLES 15 с пакетом обновления 1 (SP 1) и более поздней версии или SLES для SAP можно настроить кластер Pacemaker с помощью общих дисков Azure для обеспечения высокой доступности.

В Azure Load Balancer (цен. категория можно включить порт высокой доступности и избежать необходимости настраивать правила балансировки нагрузки для многих портов SAP. Как правило, если включить функцию возврата прямого сервера (DSR) при настройке подсистемы балансировки нагрузки, ответы сервера на запросы клиентов могут обойти подсистему балансировки нагрузки. Эта функция также называется плавающим IP-адресом. Подсистема балансировки нагрузки может быть локальной или в Azure. Это прямое подключение позволяет подсистеме балансировки нагрузки становиться узким местом в пути передачи данных. Для кластеров ASCS и HANA DB рекомендуется включить DSR. Если виртуальные машины в серверном пуле требуют общедоступного исходящего подключения, требуется дополнительная конфигурация .

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

Серверы приложений на уровне серверов приложений

Высокий уровень доступности можно достичь путем балансировки трафика в пуле серверов приложений.

Уровень ASCS

Как и в случае с уровнем серверов приложений, часто развернутое решение HANA с высоким уровнем доступности для Linux — Pacemaker.

Уровень базы данных

Архитектура в этом руководстве описывает высокодоступную систему базы данных SAP HANA, состоящую из двух виртуальных машин Azure. Функция репликации собственной системы уровня базы данных обеспечивает ручную или автоматическую отработку отказа между реплицированными узлами:

• Для отработки отказа вручную разверните несколько экземпляров HANA и используйте HSR.
• Для автоматической отработки отказа используйте расширение HSR и Linux с высоким уровнем доступности (HAE) для дистрибутива Linux. Linux HAE предоставляет кластерные службы для ресурсов HANA, обнаруживает события сбоя и оркеструет отработку отказа неисправных служб с переносом на работоспособный узел.

Развертывание виртуальных машин в зонах доступности

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

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

Учитывайте эти рекомендации при выборе развертывания ресурсов в зонах доступности:

• Задержка между виртуальными машинами в одной зоне
• Задержка между виртуальными машинами в выбранных зонах
• Доступность одинаковых служб Azure (типов виртуальных машин) в выбранных зонах

Пример активного и пассивного развертывания

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

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

Пример активного и активного развертывания

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

Службы ASCS и базы данных выполняются в зоне 1. Серверы приложений в зоне 2 могут иметь большую задержку сети при подключении к службам ASCS и баз данных из-за физического расстояния между зонами.

Если зона 1 переходит в автономный режим, службы ASCS и службы баз данных отработки отказа в зону 2. Неактивные серверы приложений можно использовать в сети, чтобы обеспечить полную емкость обработки приложений.

Рекомендации по аварийному использованию

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

Рекомендации по затратам

Для оценки затрат используйте калькулятор цен Azure.

См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.

Виртуальные машины

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

Существует несколько вариантов оплаты виртуальных машин в целом:

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

• Рекомендуется использовать резервирования Azure, если вы можете зафиксировать использование виртуальной машины в течение одного или трехлетнего срока. Резервирования виртуальных машин могут значительно сократить затраты. Вы можете заплатить не более 72 процентов от стоимости услуги по мере использования.

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

  • Сценарии высокопроизводительных вычислений, задания пакетной обработки или визуальные приложения отрисовки
  • Тестовые среды, включая непрерывную интеграцию и рабочие нагрузки непрерывной доставки
  • Крупномасштабные приложения без отслеживания состояния

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

Общие сведения о ценах см. в разделе о ценах на Linux Виртуальные машины.

Load Balancer

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

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

ExpressRoute

В этой архитектуре ExpressRoute — это сетевая служба, используемая для создания частных подключений между локальной сетью и виртуальными сетями Azure.

Все входящие данные передаются бесплатно. Плата за передачу исходящих данных взимается на основе предварительно определенной скорости. Дополнительные сведения см. в техническом обзоре ExpressRoute.

Рекомендации по управлению и операциям

Чтобы обеспечить работу системы в рабочей среде, рассмотрим следующие моменты.

Центр Azure для решений SAP

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

Резервное копирование

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

Управление удостоверениями

Используйте централизованную систему управления удостоверениями для управления доступом к ресурсам на всех уровнях:

• Предоставление доступа к ресурсам Azure с помощью управления доступом на основе ролей Azure (Azure RBAC).

• Предоставление доступа к виртуальным машинам Azure с помощью протокола LDAP, идентификатора Microsoft Entra, Kerberos или другой системы.

• Поддержка доступа в приложениях через службы, предоставляемые SAP, или используйте идентификатор OAuth 2.0 и Microsoft Entra ID.

Наблюдение

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

Вопросы безопасности

SAP имеет собственный модуль управления пользователями (UME) для управления доступом на основе ролей и авторизацией в приложении и базах данных SAP. Дополнительные сведения см. в разделе "Безопасность SAP HANA: обзор".

Чтобы повысить безопасность сети, рекомендуется использовать сеть периметра, которая использует NVA для создания брандмауэра перед подсетью для веб-диспетчера и пулов внешних серверов Fiori. Стоимость передачи данных является причиной размещения активных внешних серверов, которые запускают приложения Fiori в той же виртуальной сети, что и системы S/4. Альтернативой является размещение их в сети периметра и подключение их к S/4 через пиринг виртуальной сети.

Для обеспечения безопасности инфраструктуры данные шифруются при передаче и во время хранения. В разделе "Рекомендации по безопасности" SAP NetWeaver в Azure Виртуальные машины–планирование и реализация содержатся сведения о сетевой безопасности, которая применяется к S/4HANA. Это руководство также указывает сетевые порты, которые будут открываться на брандмауэрах, чтобы разрешить связь с приложением.

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

Для шифрования неактивных данных SAP HANA рекомендуется использовать собственную технологию шифрования SAP HANA.

Сообщества

Участники сообществ отвечают на вопросы и помогают настроить успешное развертывание. Рассмотрим следующие ресурсы:

• Запись блога по запуску приложений SAP на платформе Майкрософт
• Поддержка сообщества Azure
• Сообщество SAP
• Stack Overflow для SAP

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующим участником.

Автор субъекта:

• Бен Трин | Главный архитектор

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

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

• Развертывание SAP S/4HANA или BW/4HANA в Azure
• SAP NetWeaver на виртуальных машинах Windows. Руководство по планированию и внедрению
• Использование Azure для размещения и запуска сценариев рабочей нагрузки SAP

Связанные ресурсы

• Запуск рабочих нагрузок SAP с помощью базы данных Oracle в Azure