Справочник - AZ-120 Microsoft Azure for SAP Workloads Specialty

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

Используйте виртуальные машины серии Mv2 или M для больших баз данных (>4 ТБ). Используйте сертифицированные SAP виртуальные машины серии Edsv5 для небольших производственных баз данных HANA (<4 ТБ).

Почему: Серии M/Mv2 сертифицированы SAP для рабочих нагрузок с большим объемом памяти. Серия Edsv5 предлагает экономически эффективный сертифицированный вариант для небольших экземпляров HANA. Другие серии (D, F, L) не сертифицированы для производственных баз данных HANA.

Источник

Выбор виртуальной машины для сервера приложений SAP NetWeaver.

Используйте виртуальные машины серии Edsv5 или Ddsv5. Размер выбирайте на основе требований SAPS из отчетов SAP EarlyWatch Alert или SAP Quick Sizer.

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

Обеспечение минимальной задержки сети между серверами приложений SAP и сервером базы данных.

Развертывайте все связанные виртуальные машины (серверы приложений, ASCS/ERS, база данных) в рамках одной группы размещения близкого действия (PPG).

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

Предоставление общей файловой системы для тома /hana/shared в развертывании SAP HANA масштабированием (scale-out).

Используйте Azure NetApp Files (ANF) с протоколом NFS.

Почему: ANF - это сертифицированное SAP высокопроизводительное общее хранилище NFS, необходимое для конфигураций HANA с масштабированием (scale-out). Блочное хранилище, такое как Managed Disks, не может использоваться для этой цели.

Предоставление высокодоступной общей файловой системы для /sapmnt и глобального каталога транспорта (/usr/sap/trans).

Используйте Azure NetApp Files (NFS) или Azure Files Premium (NFS). Для Windows используйте Azure Files Premium (SMB) или кластер SOFS.

Почему: Эти службы предоставляют управляемые, высокодоступные файловые ресурсы с требуемой производительностью и поддержкой протоколов (NFS для Linux, SMB для Windows), устраняя необходимость в создании и управлении отдельным кластером файловых серверов.

Проектирование хранилища для производственных томов SAP HANA /hana/data и /hana/log, требующих высокой производительности операций ввода-вывода (IOPS) и задержки менее одной миллисекунды.

Используйте управляемые диски Azure Ultra Disk или Premium SSD v2. Для /hana/log на виртуальных машинах серии M Premium SSD с Write Accelerator также является допустимым вариантом.

Почему: Ultra Disk и Premium SSD v2 соответствуют строгим показателям IOPS, пропускной способности и задержки менее одной миллисекунды, определенным SAP для производственных рабочих нагрузок HANA. Стандартные уровни хранения не поддерживаются.

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

Используйте топологию "звезда". Развертывайте системы SAP в выделенных центральных виртуальных сетях (VNet) для каждой среды (Prod, QA, Dev). Используйте группы безопасности сети (NSG) для принудительного применения строгих правил трафика между подсетями.

Почему: Это обеспечивает сильную изоляцию сети на уровне VNet и детальный контроль трафика с помощью NSG, следуя лучшим практикам безопасности и концепции Azure Landing Zone.

Развертывание ландшафтов SAP в Azure с использованием подхода "Инфраструктура как код" (IaC) для обеспечения согласованности и автоматизации.

Используйте официальную платформу автоматизации развертывания SAP в Azure, которая использует Terraform и Ansible. В качестве альтернативы можно создавать пользовательские модули Bicep или Terraform.

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

Безопасная публикация SAP Fiori или других веб-приложений SAP для внешних пользователей через интернет.

Используйте Azure Application Gateway с включенным брандмауэром веб-приложений (WAF).

Почему: Application Gateway обеспечивает балансировку нагрузки на уровне 7, завершение SSL и защиту WAF от распространенных веб-уязвимостей, что делает его идеальной и безопасной точкой входа для веб-приложений SAP.

Развертывание чрезвычайно большой базы данных SAP HANA (более 12 ТБ памяти), которая превышает емкость виртуальных машин Azure.

Используйте SAP HANA на Azure Large Instances (HLI). Для подключения требуется канал ExpressRoute, соединяющий штамп HLI с Azure VNet через шлюз ExpressRoute.

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

Развертывание системы SAP в нескольких зонах доступности с минимизацией задержки внутри каждой зоны.

Создайте отдельную группу размещения близкого действия (PPG) для ресурсов в каждой зоне доступности. Привяжите каждую PPG к соответствующей зоне.

Почему: Одна PPG не может охватывать несколько зон. Этот подход обеспечивает размещение ресурсов с низкой задержкой *внутри* зоны, при этом достигая высокой доступности *между* зонами.

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

Используйте Azure Image Builder для определения повторяющегося процесса создания образов. Храните и реплицируйте полученные управляемые образы с помощью Azure Compute Gallery.

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

Обеспечение безопасного административного доступа по RDP/SSH к виртуальным машинам SAP без их раскрытия общедоступному интернету.

Разверните Azure Bastion (Standard SKU) в выделенной подсети в виртуальной сети SAP. Используйте Bastion для подключения к виртуальным машинам через портал Azure или нативные клиенты.

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

Шифрование томов данных SAP с использованием ключей шифрования, управляемых клиентом.

Используйте шифрование дисков Azure с управляемым клиентом ключом (CMK), хранящимся в Azure Key Vault. Это можно комбинировать с собственным шифрованием SAP HANA для многоуровневой защиты.

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

Миграция локальной системы SAP с базой данных, отличной от HANA (например, Oracle, Db2), в SAP HANA в Azure.

Используйте SAP Software Update Manager (SUM) с опцией миграции базы данных (DMO). Для минимизации простоя используйте опции "DMO с перемещением системы" или почти нулевого простоя (nZDT).

Почему: DMO объединяет преобразование базы данных, обновление системы и миграцию данных в единый оптимизированный процесс. Это стандартный инструмент SAP для этой задачи, минимизирующий время простоя по сравнению с классическим экспортом/импортом.

Миграция локальной системы SAP HANA в Azure с минимально возможным временем простоя.

Используйте SAP HANA System Replication (HSR) для непрерывной репликации данных на целевую виртуальную машину Azure. Выполните окончательный, короткий перенос (takeover) во время окна обслуживания.

Почему: HSR минимизирует окно простоя до минут, так как требуется только окончательная синхронизация и перенос. Методы резервного копирования/восстановления или экспорта/импорта приводят к часам простоя для больших баз данных.

Передача большого объема данных SAP (>10 ТБ) из локальной среды в Azure для начальной нагрузки миграции при недостаточной пропускной способности сети.

Используйте Azure Data Box для начальной массовой передачи данных. Используйте ExpressRoute или VPN для последующей дельта-синхронизации.

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

Развертывание и управление системами SAP S/4HANA в Azure с помощью упрощенного, пошагового интерфейса.

Используйте Azure Center для решений SAP (ACSS). Предварительные условия включают регистрацию поставщика `Microsoft.Workloads` и создание управляемого удостоверения, назначенного пользователем, с необходимыми разрешениями.

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

Определение правильных размеров виртуальных машин Azure для новой или мигрированной системы SAP.

Используйте инструмент SAP Quick Sizer для новых реализаций. Для миграций анализируйте отчеты SAP EarlyWatch Alert из существующей системы, чтобы получить текущее использование SAPS и памяти. Сопоставьте их с сертифицированными SAP виртуальными машинами Azure.

Почему: Эти собственные инструменты SAP обеспечивают наиболее точную характеристику рабочей нагрузки (SAPS, память, ввод-вывод), что крайне важно для правильного выбора ресурсов Azure и обеспечения производительности и поддержки.

Интеграция управляемой клиентом среды Azure с системой SAP S/4HANA, развернутой через RISE with SAP.

SAP управляет базовой инфраструктурой Azure в отдельной подписке. Установите подключение из вашей VNet Azure к управляемой SAP VNet с использованием пиринга VNet.

Почему: RISE - это управляемое сервисное предложение от SAP. Пиринг VNet обеспечивает стандартный, безопасный и частный путь сетевой интеграции между средой RISE и другими рабочими нагрузками клиента в Azure.

Обеспечение соблюдения корпоративных стандартов и лучших практик безопасности для всех развертываний SAP в Azure.

Используйте Azure Policy для применения правил, таких как требование определенных SKU виртуальных машин, шифрования управляемых дисков, связи с NSG или обязательной маркировки. Используйте эффект `DeployIfNotExists` для автоматической установки расширения VM для SAP.

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

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

Установите и включите расширение VM Azure для SAP (Enhanced Monitoring). Запустите инструмент SAP on Azure Quality Check из GitHub.

Почему: Расширение VM является обязательным для поддержки SAP. Инструмент Quality Check проактивно проверяет конфигурации (хранилище, сеть, настройки ОС) на соответствие списку известных лучших практик и требований.

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

Используйте Azure Backup для SAP HANA, который интегрируется через сертифицированный SAP интерфейс Backint. Настройте политику с полным/дифференциальным и частым резервным копированием журналов для восстановления на определенный момент времени.

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

Внедрение комплексного централизованного мониторинга для ландшафта SAP, работающего в Azure.

Разверните Azure Monitor для решений SAP. Настройте поставщиков для SAP HANA, NetWeaver, ОС (Linux) и телеметрии кластера высокой доступности.

Почему: Это собственная служба Azure, разработанная для SAP. Она предоставляет богатую, ориентированную на SAP телеметрию и визуализации, централизуя мониторинг всего стека SAP от инфраструктуры до приложения.

Применение исправлений ОС или ядра SAP к кластеру высокой доступности SAP с минимальным временем простоя.

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

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

Автоматизация процесса создания копий или обновления систем SAP (например, обновление системы QAS из PRD).

Используйте SAP Landscape Management (LaMa) с Azure Connector.

Почему: LaMa оркестрирует сквозной процесс, включая задачи инфраструктуры Azure (остановка/запуск виртуальных машин, снимки дисков) и автоматизацию после копирования, специфичную для SAP (BDLS), значительно сокращая ручные усилия.

Проверка плана аварийного восстановления SAP без влияния на производственную среду.

Используйте функцию "Тестовый отказ" Azure Site Recovery, которая запускает реплицированные виртуальные машины в изолированной VNet. Для HSR используйте восстановления на основе снимков в изолированную систему или выделенную третичную цель репликации.

Почему: Тестирование в изолированной сети предотвращает конфликты IP-адресов и любое вмешательство в производственные системы или текущую репликацию, позволяя безопасно и тщательно проверить руководство по аварийному восстановлению.

Планирование будущих потребностей в ресурсах (ЦП, память, хранилище) для растущей системы SAP в Azure.

Используйте метрики Azure Monitor и Log Analytics для анализа исторических тенденций использования. Используйте эти данные для прогнозирования. Для хранилища используйте возможность динамического изменения размера управляемых дисков Azure в режиме онлайн.

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

Минимизация затрат Azure на работу полного ландшафта SAP.

Для производственных рабочих нагрузок используйте зарезервированные экземпляры Azure на 1 или 3 года. Для непроизводственных систем реализуйте автоматическое расписание запуска/остановки через Azure Automation. Используйте Azure Hybrid Benefit для лицензий, где это применимо.

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

Отслеживание и распределение затрат Azure на рабочие нагрузки SAP по конкретным бизнес-подразделениям, проектам или системам SAP (SID).

Внедрите обязательную стратегию маркировки для всех ресурсов Azure. Используйте такие теги, как `CostCenter`, `Environment`, `SAP-SID` и `BusinessOwner`. Анализируйте затраты с помощью Azure Cost Management.

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

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

Используйте инструменты Azure Network Watcher, в частности Connection Monitor для проверки путей и задержки, и NSG Flow Logs для анализа и идентификации заблокированного трафика.

Почему: Network Watcher предоставляет проактивные и реактивные инструменты для выявления проблем сети на уровне платформы Azure, что часто трудно диагностировать только из гостевой ОС.

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

Используйте Azure Update Manager с пред- и пост-скриптами. Пред-скрипт останавливает приложение SAP и базу данных, а пост-скрипт перезапускает их после завершения установки исправлений.

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

Внедрение высокой доступности для центральных служб SAP (ASCS/ERS) или SAP HANA на виртуальных машинах SUSE/RHEL Linux.

Настройте кластер Pacemaker. Используйте агент `fence_azure_arm` для STONITH (fencing) для предотвращения сценариев разделения мозга (split-brain), аутентифицированный через управляемое удостоверение.

Почему: Pacemaker - это поддерживаемое SAP кластерное решение на Linux. `fence_azure_arm` - это встроенный в Azure механизм для надежной изоляции вышедшего из строя узла через API Azure, что является обязательным для стабильного кластера.

Внедрение высокой доступности для центральных служб SAP (ASCS/ERS) на виртуальных машинах Windows Server.

Настройте отказоустойчивый кластер Windows Server (WSFC). Для общего хранилища кластера используйте либо Azure Shared Disks, либо стороннее решение для репликации, такое как SIOS DataKeeper.

Почему: WSFC - это стандарт для кластеризации Windows. Azure Shared Disks предоставляют собственное общее блочное хранилище, в то время как SIOS создает кластер "без общего ресурса", оба заменяют потребность в традиционных SAN в облаке.

Разработка стратегии высокой доступности (HA) и аварийного восстановления (DR) для SAP HANA.

Для HA (в пределах региона) развертывайте виртуальные машины в нескольких зонах доступности и используйте синхронную (SYNC) репликацию системы SAP HANA (HSR). Для DR (между регионами) используйте асинхронную (ASYNC) HSR.

Почему: Синхронная репликация обеспечивает нулевую RPO, но требует низкой задержки (<2 мс), что делает ее идеальной для HA между зонами. Асинхронная репликация допускает более высокую задержку между регионами, что делает ее выбором для DR.

Настройка Azure Load Balancer для управления виртуальным IP-адресом для кластера высокой доступности SAP (ASCS/ERS или HANA).

Используйте Azure Standard Load Balancer. Включите Floating IP (Direct Server Return) в правиле балансировки нагрузки. Настройте проверку работоспособности на определенном порту, отслеживаемом кластером (например, 620xx для ASCS).

Почему: SKU Standard требуется для избыточности зон. Floating IP необходим для правильной работы виртуального IP-адреса кластера. Конкретная проверка работоспособности гарантирует, что трафик отправляется только на активный узел.

Понимание назначения Enqueue Replication Server (ERS) в кластере высокой доступности SAP ASCS.

Экземпляр ERS поддерживает реплику таблицы блокировок SAP из активного экземпляра ASCS.

Почему: При отказе экземпляра ASCS, новый запущенный экземпляр ASCS извлекает реплицированную таблицу блокировок из ERS. Это сохраняет блокировки транзакций и позволяет пользователям продолжать работу без прерывания.

Разработка полного решения для аварийного восстановления для многоуровневого ландшафта SAP.

Используйте собственную репликацию базы данных для уровня базы данных (например, асинхронную HSR для HANA). Используйте Azure Site Recovery (ASR) для уровня приложений (ASCS/ERS и серверов приложений).

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

Внедрение высокой доступности для базы данных SAP, работающей на Microsoft SQL Server в виртуальных машинах Azure.

Используйте группы доступности SQL Server Always On, как правило, в режиме синхронной фиксации для HA в пределах региона, в сочетании с WSFC.

Почему: Always On AG - это рекомендуемое и полностью поддерживаемое решение HA/DR для SQL Server, обеспечивающее репликацию на уровне базы данных и возможности автоматического переключения при отказе.

Внедрение SBD (STONITH Block Device) в качестве механизма кворума для двухузлового кластера Pacemaker.

Настройте небольшой общий диск Azure и подключите его к обоим узлам кластера. В качестве альтернативы, настройте выделенный целевой сервер iSCSI на третьей виртуальной машине.

Почему: Хотя `fence_azure_arm` является основным агентом ограждения, SBD предоставляет дополнительный механизм свидетеля/кворума для предотвращения разделения мозга, особенно в кластерах без третьего голосующего узла.