Azure встречает SAP: разбираем SAP on Azure для Microsoft Teams

By Mirko Peters · 2026-11-05

Что на самом деле значит запуск SAP в Microsoft Azure: сертифицированные виртуальные машины и хранилище, посадочная зона (landing zone), которую вы строите первой, гибридное подключение, три пути развёртывания и ошибки, которые превращают поддерживаемую систему SAP в неподдерживаемую.

Automatically translated with AI from the original post. Read the English original

Как Microsoft MVP, большую часть времени я общаюсь с людьми, которые досконально знают Azure, Entra ID и Microsoft 365 и которым вдруг поручают «поддержать переезд SAP». Для многих из них SAP выглядит отдельной вселенной со своим словарём. Хорошая новость: SAP on Azure гораздо привычнее, чем кажется. Всё сводится к двум правилам. Оставайтесь в рамках сертифицированных конфигураций и создайте фундамент до того, как появится первая система SAP. В этом посте мы пройдём оба правила в том порядке, в котором вы будете с ними работать на практике.

Что на самом деле означает SAP on Azure

SAP on Azure означает, что ваши системы SAP работают в Microsoft Azure. База данных SAP HANA, серверы приложений и центральные сервисы располагаются на виртуальных машинах Azure и используют хранилище и сеть Azure. Само программное обеспечение SAP при этом не меняется: SAP S/4HANA остаётся S/4HANA, SAP NetWeaver остаётся NetWeaver. Меняется только основа, на которой всё работает.

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

Полезно отделить это от второй, похожей темы. Копирование данных SAP в Azure для отчётов в Power BI или Microsoft Fabric — это интеграция данных, полезная, но другая задача. Запуск SAP в Azure означает, что сама продуктивная система живёт там, обрабатывает транзакции там и обслуживает пользователей оттуда.

Если сначала хотите получить общую картину семейства продуктов SAP, на тематической странице SAP на M365.FM собран наш связанный материал.

Почему «сертифицировано» решает всё

В мире SAP фраза «работает в Azure» на самом деле означает «работает в сертифицированном Azure». SAP и Microsoft тестируют конкретные типы виртуальных машин и варианты хранилища для конкретных продуктов и сценариев SAP, и поддерживаются только такие комбинации. Microsoft документирует сертификаты и конфигурации SAP для Azure и программное обеспечение SAP, поддерживаемое в Azure. Для SAP HANA авторитетным списком является собственный справочник SAP — HANA Hardware Directory; для систем на основе NetWeaver типы виртуальных машин Azure, которые поддерживаются, перечислены в SAP Note 1928533.

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

Для хранилищ действует та же логика. Управляемые диски Azure (Azure managed disks) — основной строительный блок для повседневных задач. Azure NetApp Files предоставляет хранилище NFS, которое используется в нескольких архитектурах SAP. Azure Files на премиальном (SSD) хранилище может размещать общие каталоги. Более дешёвый стандартный уровень Azure Files не поддерживается для общих ресурсов высокой доступности центральных служб SAP, поэтому экономия здесь — неправильный выбор. Microsoft описывает эти ограничения в поддерживаемых сценариях для рабочих нагрузок SAP на виртуальных машинах Azure.

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

Landing zone, которую нужно построить первой

Azure landing zone — это основа, которая обеспечивает каждую рабочую нагрузку идентификацией, сетью, безопасностью и управлением до того, как в неё будет развёрнуто что-либо. Cloud Adoption Framework от Microsoft делит её на две части:

• Платформенная landing zone: общая основа с группами управления, центральным подключением, идентификацией, службами безопасности и управления.
• Landing zone приложений (рабочих нагрузок): отдельные среды, как правило, разработки, тестирования и производства, каждая из которых состоит из подписок, наследующих ограничения платформы.

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

Microsoft предлагает ускоритель landing zone для SAP на Azure с эталонными архитектурами на основе топологии hub-and-spoke или Azure Virtual WAN. Azure Policy и иерархия групп управления задают ограничения, и каждая система SAP затем размещается внутри них. Именно это позволяет второй и третьей системе SAP появляться без новых споров о наименовании, доступе и сетевых правилах.

Подключение SAP к вашему дата-центру

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

Основной приватный вариант — Azure ExpressRoute, выделенное приватное подключение между вашим дата-центром и Azure вместо трафика через публичный интернет. Если ExpressRoute недоступен, альтернативой является site-to-site VPN. В любом случае подключение обычно завершается в центральном hub или Virtual WAN, а виртуальная сеть SAP обращается к нему оттуда. Внутри Azure типичная архитектура SAP разделяет уровни приложений и баз данных на отдельные подсети, защищённые группами безопасности сети, таблицами маршрутизации и межсетевым экраном.

Идентификации стоит уделить внимание, потому что здесь команды Microsoft чаще всего делают ошибочные допущения. Microsoft Entra ID отлично подходит для единого входа (single sign-on) в приложения SAP. Но системы SAP NetWeaver и S/4HANA, работающие на Windows, не используют учётные записи Entra ID для самого приложения SAP. Им по-прежнему нужны Active Directory Domain Services — либо расширенные из локальной среды, либо предоставляемые через Microsoft Entra Domain Services. Вход в систему и каталог операционной системы — это две разные задачи.

Три варианта развёртывания

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

1. Обычные виртуальные машины Azure. Вы самостоятельно управляете операционной системой, установкой SAP, обновлениями и мониторингом. Максимум контроля и максимум работы. Хорошо подходит, если глубокие навыки работы с SAP и Azure есть в команде.
2. Azure Center for SAP solutions. Служба Azure, которая делает SAP полноценной рабочей нагрузкой. Она может создавать инфраструктуру и устанавливать ПО SAP для систем на одном сервере, распределённых систем и распределённых систем с высокой доступностью, а также регистрировать системы SAP, которые уже работают в Azure. Каждая система становится Virtual Instance for SAP solutions, логическим представлением SID, центральных служб, сервера базы данных и серверов приложений. Оттуда вы видите состояние и статус системы, запускаете и останавливаете её, выполняете проверки качества по рекомендациям и отслеживаете данные мониторинга. Подробности в обзоре Azure Center for SAP solutions.
3. SAP on Azure deployment automation framework. Открытый подход Infrastructure as Code для команд, которым нужны воспроизводимые, версионируемые развёртывания и рабочий процесс DevOps.

Простое правило выбора: полный контроль и сильные навыки команды указывают на обычные виртуальные машины; управляемая пошаговая настройка с единым местом управления системой указывает на Azure Center for SAP solutions; множество систем, развёрнутых одинаковым образом, указывает на automation framework.

Типичные ошибки

Самые болезненные первые миграции обычно объединяет один шаг, который казался необязательным.

• Отношение к сертификации как к формальности. Несертифицированная виртуальная машина или тип хранилища превращает поддерживаемую систему в неподдерживаемую, и обычно это выясняется в самый неподходящий момент.
• Пропуск landing zone. Фраза «governance добавим позже» редко выполняется, а перестраивать правила идентификации и сети вокруг работающей системы SAP медленно и рискованно.
• Предположение, что Entra ID заменяет Active Directory для систем SAP на Windows. Это не так.
• Проектирование подключения в последнюю очередь. Разделение уровня приложений SAP и уровня базы данных между локальной средой и Azure или между регионами Azure не поддерживается.
• Предположение, что всё работает в Azure. Azure VMware Solution, как правило, не является поддерживаемой платформой для размещения рабочих нагрузок SAP, а SAP HANA Large Instances больше не предлагаются новым клиентам.
• Использование Azure Site Recovery для базы данных. Azure Site Recovery не поддерживается для уровня базы данных SAP; для аварийного восстановления используйте собственную репликацию базы данных, например SAP HANA System Replication.

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

Вывод: порядок действий

Если запомнить одно, запомните последовательность. Определите, что системе SAP нужно по производительности, доступности и восстановлению. Постройте landing zone. Подключите сеть и каталог к вашему дата-центру. Выберите, сколько хотите управлять в облаке: обычные виртуальные машины, Azure Center for SAP solutions или automation framework. Выберите сертифицированные вычислительные ресурсы и хранилище. Затем спроектируйте высокую доступность и аварийное восстановление на основе собственных возможностей базы данных.

Не обязательно переносить всё сразу. Начав с одной системы, вы увидите, где landing zone слабая и где команде нужна поддержка, пока ставки ещё невысоки. Для специалистов Microsoft SAP в Azure – не чужой мир. Это набор обычных инженерных решений, где сертификация – единственное правило, которое нельзя обходить.