SAP S/4HANA в Linux в Azure

В этом руководстве представлен набор проверенных рекомендаций по запуску S/4HANA и Suite для HANA в среде с высокой доступностью (HA), поддерживающей аварийное восстановление (DR) в 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 Files, Azure NetApp Files, кластеризованные серверы NFS или SIOS Protection Suite для 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 или с помощью собственного клиента Secure Shell (SSH) или клиента протокола удаленного рабочего стола (RDP), установленного на локальном компьютере. Если для администрирования используются только протоколы RDP и SSH, рассмотрите возможность использования Бастиона Azure. Если вы используете другие средства управления, такие как SQL Server Management Studio или интерфейс SAP, воспользуйтесь традиционным самостоятельно развертываемым шлюзом доступа.

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

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

• Тип трафика, например HTTP или SAP с графическим пользовательским интерфейсом (GUI).
• Необходимые сетевые функции, такие как завершение сеансов SSL.

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

• Расширенное программирование бизнес-приложений (ABAP) SAP Central Services (ASCS)
• Поставить в очередь сервер репликации

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения о поддержке SAP для типов виртуальных машин Azure и метрик пропускной способности см. в заметке SAP 1928533. Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace. Список сертифицированных виртуальных машин Azure для базы данных HANA см. в сертифицированном и поддерживаемом каталоге оборудования 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 с ha NFS для общего хранилища и по крайней мере два сервера приложений. Трафик распределяется по паре экземпляров Web Dispatcher, которые могут быть кластеризованы или работать параллельно. Для приложений Fiori, подключенных к Интернету , рекомендуется развертывание концентратора FES в сети периметра. Используйте брандмауэр веб-приложений Azure в шлюзе приложений в качестве критического компонента для отклонения угроз. Используйте идентификатор Microsoft Entra с языком разметки утверждений безопасности для проверки подлинности пользователей и единого входа в SAP Fiori.

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

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

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

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

• SMLG: Балансировка загрузки пользователей при входе в систему.
• SM61: Управление группами серверов для пакетной обработки.
• RZ12: Управление группами функций удаленного вызова (RFC).

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

Кластер служб SAP Central Services

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

Сети

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

Сетевые адаптеры

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

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

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

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

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

ExpressRoute Global Reach

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

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

FastPath

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

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

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

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

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

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

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

Хранение

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

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

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

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

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

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

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

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

Вопросы, связанные с производительностью

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

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

Дополнительные сведения о производительности SAP HANA см. в заметке SAP 1943937.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недавно добавленная поддержка и упрощенная конфигурация Pacemaker в SLES 15 и более поздних версиях — это HA SAP NetWeaver с простым монтированием и NFS на виртуальных машинах SLES для приложений SAP. В этой конфигурации общие папки SAP удаляются из управления кластером, что упрощает работу. Используйте эту конфигурацию высокого уровня доступности для всех новых развертываний.

Для дальнейшего управления затратами на большую инфраструктуру SAP кластер Linux поддерживает установку ASCS с несколькими SID в Azure. Совместное использование кластера доступности между несколькими системами SAP упрощает ландшафт SAP и сокращает затраты на операции.

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

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

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

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

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

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

• Для отработки отказа вручную разверните несколько экземпляров HANA и используйте HSR.

• Для автоматического переключения при отказе используйте как расширение HSR, так и расширение Linux HA (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.

Дополнительные сведения см. в статье по оптимизации затрат Azure Well-Architected Framework.

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

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

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

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

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

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

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

  • Тестовые среды, включая рабочие нагрузки для непрерывной интеграции и доставки

  • Крупномасштабные приложения без отслеживания состояния

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

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

Балансировщик нагрузки

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

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

ExpressRoute

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

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

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

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

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

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

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

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

Управление идентичностью

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

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

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

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

Контроль

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

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

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

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

Для обеспечения безопасности инфраструктуры данные шифруются при передаче и во время хранения. Сведения о безопасности сети, которая применяется к S/4HANA, см. в статье "Безопасность" для ландшафта SAP.

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

Сообщества

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

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

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

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

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

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

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

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