Справочник

Выбор виртуальной машины для производственной базы данных 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 предоставляет дополнительный механизм свидетеля/кворума для предотвращения разделения мозга, особенно в кластерах без третьего голосующего узла.