Планирование и реализация развертывания SAP в Azure

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

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

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

Определения

В этой статье мы используем следующие термины:

• Компонент SAP: отдельное приложение SAP, например SAP S/4HANA, SAP ECC, SAP BW или SAP Solution Manager. Компонент SAP может быть основан на традиционных технологиях расширенного бизнес-приложения (ABAP) или Java, или это может быть приложение, которое не основано на SAP NetWeaver, например SAP BusinessObjects.
• Среда SAP: несколько компонентов SAP, которые логически группируются для выполнения бизнес-функции, например разработки, обеспечения качества, обучения, аварийного восстановления или рабочей среды.
• Ландшафт SAP: весь набор ресурсов SAP в ИТ-ландшафте организации. Ландшафт SAP включает все рабочие и нерабочие среды.
• Система SAP: сочетание уровня системы управления базами данных (СУБД) и уровня приложения. Два примера — это система разработки SAP ERP и тестовая система SAP BW. В развертывании Azure эти два уровня не могут быть распределены между локальной средой и Azure. Система SAP должна быть развернута локально или развернута в Azure. Однако вы можете работать с различными системами в ландшафте SAP в Azure или локальной среде.

Ресурсы

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

• Сведения о рабочей нагрузке SAP для хранения, сети и поддерживаемых параметров.
• Руководства по СУБД SAP для различных систем СУБД в Azure.
• Руководства по развертыванию SAP, как вручную, так и автоматизированные.
• Сведения о высокой доступности и аварийном восстановлении рабочей нагрузки SAP в Azure.
• Интеграция с SAP в Azure с другими службами и сторонними приложениями.

Следующие заметки SAP формируют базу рекомендаций Azure для развертываний SAP:

Номер примечания	Заголовок
1928533	Приложения SAP в Azure: поддерживаемые продукты и размеры
2015553	SAP в Azure: предварительные требования для поддержки
2039619	Приложения SAP в Azure с помощью базы данных Oracle
2233094	DB6: приложения SAP в Azure с помощью IBM Db2 для Linux, UNIX и Windows
1999351	Устранение неполадок, связанных с расширенным мониторингом Azure для SAP
1409604	Виртуализация в Windows: расширенный мониторинг
2191498	SAP на платформе Linux в Azure: расширенный мониторинг
2731110	Поддержка сетевых виртуальных устройств (NVA) для SAP в Azure

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

Сценарии

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

Azure — это идеальная общедоступная облачная платформа для критически важных для бизнеса приложений и бизнес-процессов SAP. Большинство современных программ SAP, включая системы SAP NetWeaver и SAP S/4HANA, можно разместить в инфраструктуре Azure сегодня. Azure предлагает более 800 типов ЦП и виртуальных машин с большим количеством терабайтов памяти.

Описание поддерживаемых сценариев и некоторых сценариев, которые не поддерживаются, см . в поддерживаемых сценариях SAP на виртуальных машинах Azure. Проверьте эти сценарии и условия, которые не поддерживаются при планировании архитектуры, которую вы хотите развернуть в Azure.

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

Чтобы собрать данные для планирования развертывания в Azure, важно:

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

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

Первые шаги по планированию развертывания

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

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

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

Планирование обеспечения соответствия требованиям

Список предложений по соответствию требованиям Майкрософт, которые помогут вам спланировать требования соответствия требованиям, см . в предложениях майкрософт по соответствию требованиям.

Планирование безопасности

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

Организация ресурсов Azure

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

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

Чтобы помочь вам принять правильные решения, многие сведения об архитектуре предприятия описаны в Azure Cloud Adoption Framework.

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

Далее необходимо планировать географическое размещение и сетевую архитектуру, развернутую в Azure.

Географические области и регионы Azure

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

Список регионов Azure см. в географических регионах Azure. Интерактивная карта см. в статье о глобальной инфраструктуре Azure.

Не все регионы Azure предлагают одни и те же службы. В зависимости от продукта SAP, необходимого для выполнения, требований к размеру и операционной системы и СУБД, возможно, что определенный регион не предлагает типы виртуальных машин, необходимые для вашего сценария. Например, если вы используете SAP HANA, обычно требуются виртуальные машины различных семейств виртуальных машин серии M. Эти семейства виртуальных машин развертываются только в подмножестве регионов Azure.

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

Пары регионов Azure

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

Репликация данных в паре регионов привязана к типам хранилища Azure, которые можно настроить для репликации в парный регион. Дополнительные сведения см. в разделе "Избыточность хранилища" в дополнительном регионе.

Типы хранилища, поддерживающие репликацию данных в парном регионе, — это типы хранилища, которые не подходят для компонентов SAP и рабочей нагрузки СУБД. Возможность использования репликации хранилища Azure ограничена Хранилище BLOB-объектов Azure (в целях резервного копирования), общими папками и томами и другими сценариями хранения с высокой задержкой.

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

Зоны доступности

Многие регионы Azure используют зоны доступности для физически отдельных расположений в регионе Azure. Каждая зона доступности состоит из одного или нескольких центров обработки данных, которые оснащены независимым питанием, охлаждением и сетями. Пример использования зоны доступности для повышения устойчивости — развертывание двух виртуальных машин в двух отдельных зонах доступности в Azure. Еще одним примером является реализация платформы высокой доступности для системы СУБД SAP в одной зоне доступности и развертывание SAP (A)SCS в другой зоне доступности, поэтому вы получите лучшее соглашение об уровне обслуживания в Azure.

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

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

Домены сбоя

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

При развертывании нескольких виртуальных машин в рамках одной системы SAP можно косвенно повлиять на контроллер структуры Azure для развертывания виртуальных машин в разных доменах сбоя, чтобы обеспечить соответствие требованиям к уровням обслуживания доступности. Однако у вас нет прямого контроля над распределением доменов сбоя по единице масштабирования Azure (коллекция сотен вычислительных узлов или узлов хранилища и сети) или назначение виртуальных машин определенному домену сбоя. Чтобы маневрировать контроллером структуры Azure для развертывания набора виртуальных машин в разных доменах сбоя, необходимо назначить группе доступности Azure виртуальным машинам во время развертывания. Дополнительные сведения см. в разделе "Группы доступности".

Домены обновления

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

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

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

Дополнительные сведения о группах доступности Azure и о том, как группы доступности связаны с доменами сбоя, см. в статье "Группы доступности Azure".

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

Например, вы создаете группу доступности и развертываете первую виртуальную машину в группе доступности. Первая виртуальная машина, добавляемая в группу доступности, находится в семействе виртуальных машин Edsv5. При попытке развернуть вторую виртуальную машину виртуальную машину, которая находится в семействе M, это развертывание завершается сбоем. Причина в том, что виртуальные машины семейства Edsv5 не выполняются на том же оборудовании узла, что и виртуальные машины в семействе M.

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

Масштабируемые наборы виртуальных машин с гибкой оркестрацией

Масштабируемые наборы виртуальных машин с гибкой оркестрацией обеспечивают логическую группирование управляемых платформой виртуальных машин. У вас есть возможность создавать масштабируемый набор в пределах региона или охватывать его между зонами доступности. При создании гибкого масштабируемого набора в регионе с платформойFaultDomainCount>1 (FD>1) виртуальные машины, развернутые в масштабируемом наборе, будут распределены по указанному количеству доменов сбоя в одном регионе. С другой стороны, создание гибкого масштабируемого набора между зонами доступности с помощью platformFaultDomainCount=1 (FD=1) будет распределять виртуальные машины по указанной зоне, а масштабируемый набор также распределяет виртуальные машины между различными доменами сбоя в пределах зоны на основе наилучших усилий.

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

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

Группы размещения близкого взаимодействия

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

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

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

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

Сети Azure

В Azure есть сетевая инфраструктура, которая сопоставляется со всеми сценариями, которые может потребоваться реализовать в развертывании SAP. В Azure доступны следующие возможности:

• Доступ к службам Azure и доступ к определенным портам на виртуальных машинах, используемых приложениями.
• Прямой доступ к виртуальным машинам через Secure Shell (SSH) или удаленный рабочий стол Windows (RDP) для управления и администрирования.
• Внутреннее разрешение связи и имен между виртуальными машинами и службами Azure.
• Локальное подключение между локальной сетью и сетями Azure.
• Обмен данными между службами, развернутыми в разных регионах Azure.

Подробные сведения о сети см. в виртуальная сеть Azure.

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

Виртуальные сети Azure

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

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

Проектирование сети должно соответствовать нескольким требованиям к развертыванию SAP:

• Сетевые виртуальные устройства, такие как брандмауэр, не помещаются в путь связи между приложением SAP и уровнем СУБД продуктов SAP через ядро SAP, например S/4HANA или SAP NetWeaver.
• Ограничения маршрутизации сети применяются группами безопасности сети (NSG) на уровне подсети. Группировать IP-адреса виртуальных машин в группы безопасности приложений (ASG), которые хранятся в правилах NSG, а также предоставляют группы разрешений, уровней и идентификаторов безопасности.
• Виртуальные машины приложения SAP и базы данных выполняются в одной виртуальной сети в одной или разных подсетях одной виртуальной сети. Используйте разные подсети для виртуальных машин приложений и баз данных. Кроме того, используйте выделенные приложения и ASGS СУБД для группирования правил, применимых к каждому типу рабочей нагрузки в одной подсети.
• Ускоренная сеть включена на всех сетевых картах всех виртуальных машин для рабочих нагрузок SAP, где это возможно.
• Обеспечение безопасного доступа для зависимостей от центральных служб, включая разрешение имен (DNS), управление удостоверениями (домены Windows Server Active Directory/ идентификатор Microsoft Entra ID) и административный доступ.
• Предоставление доступа к общедоступным конечным точкам и по мере необходимости. Примеры включают управление Azure для операций ClusterLabs Pacemaker в высокой доступности или для служб Azure, таких как Azure Backup.
• Используйте несколько сетевых адаптеров, только если они необходимы для создания назначенных подсетей с собственными маршрутами и правилами NSG.

Примеры сетевой архитектуры для развертывания SAP см. в следующих статьях:

• SAP S/4HANA в Linux в Azure
• SAP NetWeaver в Windows в Azure
• Входящий и исходящий интернет-обмен данными для SAP в Azure

Рекомендации по виртуальным сетям

Некоторые конфигурации виртуальных сетей должны учитывать конкретные аспекты.

• Настройка виртуальных сетевых устройств в пути связи между уровнем приложений SAP и уровнем СУБД компонентов SAP с помощью ядра SAP, например S/4HANA или SAP NetWeaver, не поддерживается.

  Сетевые виртуальные модули в путях взаимодействия данными могут легко удвоить задержку сети между двумя сторонами. Они могут также ограничить пропускную способность в критических путях между уровнем приложений SAP и уровнем СУБД. В некоторых сценариях виртуальные сетевые устройства могут привести к сбою кластеров Pacemaker Linux.

  Путь связи между уровнем приложений SAP и уровнем СУБД должен быть прямым путем. Ограничение не включает правила ASG и NSG, если правила ASG и NSG разрешают прямой обмен данными.

  Другие сценарии, в которых виртуальные сетевые устройства не поддерживаются:

  • Пути обмена данными между виртуальными машинами Azure, представляющими узлы кластера Pacemaker Linux и устройства SBD, как описано в статье "Высокий уровень доступности для SAP NetWeaver на виртуальных машинах Azure на SUSE Linux Enterprise Server для приложений SAP".
  • Пути к обмену данными между виртуальными машинами Azure и общей папкой Windows Server, настроенной как описано в кластере экземпляра SAP ASCS/SCS в отказоустойчивом кластере Windows с помощью общей папки в Azure.

• Разделение уровня приложений SAP и уровня СУБД на разные виртуальные сети Azure не поддерживается. Рекомендуется разделить уровень приложений SAP и уровень СУБД с помощью подсетей в одной виртуальной сети Azure вместо использования разных виртуальных сетей Azure.

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

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

Разрешение имен и доменные службы

Разрешение имени узла на IP-адрес через DNS часто является важным элементом для сети SAP. У вас есть множество вариантов настройки имени и разрешения IP-адресов в Azure.

Часто предприятие имеет централизованное решение DNS, которое является частью общей архитектуры. Несколько вариантов реализации разрешения имен в Azure в собственном коде вместо настройки собственных DNS-серверов описаны в разделе "Разрешение имен для ресурсов в виртуальных сетях Azure".

Как и в службах DNS, может потребоваться доступ к Windows Server Active Directory виртуальными машинами или службами SAP.

Назначение IP-адресов

IP-адрес сетевой карты по-прежнему утверждается и используется на протяжении всего существования сетевой карты виртуальной машины. Правило применяется как к динамическому, так и к статическому назначению IP-адресов. Она остается верной, работает ли виртуальная машина или завершает работу. Динамическое назначение IP-адресов освобождается, если сетевой адаптер удаляется, если подсеть изменяется или если метод выделения изменяется на статический.

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

Дополнительные сведения см. в статье "Создание виртуальной машины с статическим частным IP-адресом".

Вторичные IP-адреса для виртуализации имени узла SAP

Для каждой сетевой карты виртуальной машины Azure может быть назначено несколько IP-адресов. Вторичный IP-адрес можно использовать для имени виртуального узла SAP, сопоставленного с записью DNS A или записью DNS PTR. Дополнительный IP-адрес должен быть назначен ip-конфигурации сетевого адаптера Azure. Вторичный IP-адрес также должен быть настроен в операционной системе статически, так как вторичные IP-адреса часто не назначаются через DHCP. Каждый вторичный IP-адрес должен быть из одной подсети, к которому привязан сетевой адаптер. Дополнительный IP-адрес можно добавить и удалить из сетевой карты Azure без остановки или освобождения виртуальной машины. Чтобы добавить или удалить первичный IP-адрес сетевой карты, виртуальная машина должна быть освобождена.

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

Azure Load Balancer с виртуальными машинами под управлением SAP

Подсистема балансировки нагрузки обычно используется в архитектуре высокой доступности для предоставления плавающих IP-адресов между активными и пассивными узлами кластера. Вы также можете использовать подсистему балансировки нагрузки для одной виртуальной машины для хранения виртуального IP-адреса для имени виртуального узла SAP. Использование подсистемы балансировки нагрузки для одной виртуальной машины является альтернативой использованию вторичного IP-адреса в сетевом адаптере или использовании нескольких сетевых адаптеров в одной подсети.

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

Несколько виртуальных СЕТЕЙ на виртуальную машину

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

Тип и размер виртуальной машины определяет, сколько виртуальных СЕТЕЙ может быть назначено виртуальной машине. Сведения о функциональных возможностях и ограничениях см. в разделе "Назначение нескольких IP-адресов виртуальным машинам с помощью портал Azure".

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

Ускорение работы в сети

Чтобы уменьшить задержку сети между виртуальными машинами Azure, рекомендуется убедиться, что на каждой виртуальной машине, выполняющей рабочую нагрузку SAP, включена ускоренная сеть Azure. Хотя ускоренная сеть включена по умолчанию для новых виртуальных машин, для каждого контрольного списка развертывания необходимо проверить состояние. Преимущества ускорения сети значительно повышают производительность сети и задержки. Используйте его при развертывании виртуальных машин Azure для рабочих нагрузок SAP на всех поддерживаемых виртуальных машинах, особенно для уровня приложений SAP и уровня СУБД SAP. Связанная документация содержит зависимости поддержки версий операционной системы и экземпляров виртуальных машин.

Возможность подключения к локальной среде

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

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

Для локальных развертываний SAP рекомендуется использовать частное подключение через Azure ExpressRoute. Для небольших рабочих нагрузок SAP, удаленных регионов или небольших офисов доступна локальная сеть VPN. Использование ExpressRoute с VPN-подключением типа "сеть — сеть" в качестве пути отработки отказа — это возможное сочетание обоих служб.

Исходящее и входящее подключение к Интернету

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

Защита виртуальной сети с помощью правил NSG с помощью тегов сетевой службы для известных служб, а также путем установления маршрутизации и IP-адресации брандмауэра или другого сетевого виртуального устройства. Все эти задачи или рекомендации являются частью архитектуры. Ресурсы в частных сетях должны быть защищены брандмауэрами сетевого уровня 4 и уровня 7.

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

Виртуальные машины Azure для рабочих нагрузок SAP

Некоторые семейства виртуальных машин Azure особенно подходят для рабочих нагрузок SAP и более конкретно для рабочей нагрузки SAP HANA. Способ поиска правильного типа виртуальной машины и его возможности поддержки рабочей нагрузки SAP описаны в статье "Что программное обеспечение SAP поддерживается для развертываний Azure". Кроме того, в примечании к SAP 1928533 перечислены все сертифицированные виртуальные машины Azure и их возможности производительности, измеряемые тестом производительности приложений SAP (SAPS), если они применяются. Типы виртуальных машин, сертифицированные для рабочей нагрузки SAP, не используют чрезмерной подготовки для ресурсов ЦП и памяти.

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

• ресурсы ЦП и памяти;
• Пропускная способность операций ввода-вывода в секунду (IOPS)
• Сетевые возможности
• количество подключаемых дисков;
• Возможность использования определенных типов хранилища Azure

Чтобы получить эти сведения для определенного семейства и типа FM, см. статью "Размеры" для виртуальных машин в Azure.

Модели ценообразования для виртуальных машин Azure

Для модели ценообразования на виртуальные машины можно выбрать вариант, который вы хотите использовать:

• Модель ценообразования по мере использования
• Годовой зарезервированный или сберегательный план
• Трехлетний зарезервированный или сберегательный план
• Модель ценообразования на месте

Дополнительные сведения о ценах на виртуальные машины для разных служб Azure, операционных систем и регионов см. в разделе о ценах на виртуальные машины.

Сведения о ценах и гибкости планов экономии за один и три года и зарезервированных экземплярах см. в следующих статьях:

• Что такое планы экономии Azure для вычислений?
• Основные сведения о резервировании в Azure
• Гибкость размеров виртуальных машин при использовании зарезервированных экземпляров виртуальных машин
• Применения скидки на резервирование Azure к виртуальным машинам

Дополнительные сведения о ценах на месте см. в Виртуальные машины Azure Spot.

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

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

Использование выделенного узла Azure поддерживается для рабочей нагрузки SAP. Несколько клиентов SAP, которым требуется больше контроля над исправлениями инфраструктуры и планами обслуживания, используют выделенные узлы Azure. Дополнительные сведения о том, как корпорация Майкрософт поддерживает и исправляет инфраструктуру Azure, на котором размещены виртуальные машины, см. в статье "Обслуживание виртуальных машин в Azure".

Операционная система для виртуальных машин

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

Дополнительные сведения и сведения о доступных параметрах:

• Найдите образы Azure Marketplace с помощью Azure CLI или Azure PowerShell.
• Создание пользовательских образов для Linux или Windows.
• Используйте построитель образов виртуальных машин.

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

Виртуальные машины поколения 1 и поколения 2

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

При развертывании виртуальной машины образ операционной системы, который вы выбираете, определяет, будет ли виртуальная машина поколения 1 или виртуальной машиной поколения 2. Последние версии всех образов операционной системы для SAP, доступных в Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux и Windows или Oracle Enterprise Linux), доступны как в поколении 1, так и в поколении 2. Важно тщательно выбрать образ на основе описания образа, чтобы развернуть правильное поколение виртуальной машины. Аналогичным образом можно создать пользовательские образы операционной системы в качестве поколения 1 или поколения 2, и они влияют на создание виртуальной машины при развертывании виртуальной машины.

Изменение развернутой виртуальной машины с поколения 1 на поколение 2 невозможно в Azure. Чтобы изменить поколение виртуальных машин, необходимо развернуть новую виртуальную машину, которая является нужным поколением и переустановить программное обеспечение на новой виртуальной машине. Это изменение влияет только на базовый образ VHD виртуальной машины и не влияет на диски данных или подключенные сетевые файловые системы (NFS) или общие папки "Блок сообщений сервера" (SMB). Диски данных, общие папки NFS или общие папки SMB, которые первоначально были назначены виртуальной машине поколения 1, можно подключить к новой виртуальной машине поколения 2.

Некоторые семейства виртуальных машин, такие как серия Mv2, поддерживают только поколение 2. Это же требование может быть верным для новых семейств виртуальных машин в будущем. В этом сценарии существующую виртуальную машину поколения 1 нельзя изменить для работы с новым семейством виртуальных машин. Помимо требований поколения 2 платформы Azure, компоненты SAP могут иметь требования, связанные с созданием виртуальной машины. Дополнительные сведения о любых требованиях поколения 2 для выбранного семейства виртуальных машин см. в заметках SAP 1928533.

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

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

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

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

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

• Начните с требований к памяти и ЦП. Разделите требования SAPS для ЦП к части СУБД и частям приложения SAP. Для существующих систем SAPS, связанных с оборудованием, которое часто используется, можно определить или оценить на основе существующих тестов приложений SAP Standard. Для недавно развернутых систем SAP выполните упражнение по размеру, чтобы определить требования SAPS для системы.

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

• Сравните требование SAPS для сервера СУБД с SAPS, которое может предоставлять различные типы виртуальных машин Azure. Сведения о SAPS различных типов виртуальных машин Azure описаны в заметке SAP 1928533. Фокус должен быть на виртуальной машине СУБД, так как уровень базы данных является слоем в системе SAP NetWeaver, которая не масштабируется в большинстве развертываний. В отличие от этого, уровень приложений SAP можно масштабировать. Отдельные руководства по СУБД описывают рекомендуемые конфигурации хранилища.

• Сводка результатов для:

  • Количество используемых виртуальных машин Azure.
  • Отдельные семейства виртуальных машин и номера SKU виртуальных машин для каждого уровня SAP: СУБД, (A)SCS и сервера приложений.
  • Показатели пропускной способности ввода-вывода или вычисляемые требования к емкости хранилища.

Служба крупных экземпляров HANA

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

Хранилище для SAP в Azure

Виртуальные машины Azure используют различные варианты хранения для сохраняемости. С помощью простых терминов виртуальные машины можно разделить на постоянные и временные или не постоянные типы хранилища.

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

Временный диск на виртуальных машинах

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

Данные операционной системы приложения или неизменяемых операционных систем не должны храниться на временном диске. В средах Windows временный диск обычно обращается как диск D. В системах Linux точка подключения часто — устройство /dev/sdb, /mnt или /mnt/resource.

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

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

Сетевые ресурсы и тома для SAP

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

• Каталог транспорта SAP (/usr/sap/trans или TRANSDIR).
• Тома SAP или общие тома sapmnt или saploc для развертывания нескольких серверов приложений.
• Тома архитектуры высокой доступности для SAP (A)SCS, SAP ERS или базы данных (/hana/shared).
• Интерфейсы файлов, которые выполняют сторонние приложения для импорта и экспорта файлов.

В этих сценариях рекомендуется использовать службу Azure, например Файлы Azure или Azure NetApp Files. Если эти службы недоступны в выбранных регионах или если они недоступны для архитектуры решения, альтернативные варианты — предоставить общие папки NFS или SMB из самоуправляемых приложений на основе виртуальных машин или сторонних служб. См. примечание SAP 2015553 об ограничениях поддержки SAP, если вы используете сторонние службы для слоев хранилища в системе SAP в Azure.

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

• Проектирование общих папок NFS или SMB, включая использование общих папок для каждого идентификатора системы SAP (SID), для каждого ландшафта и каждого региона.
• Размер подсети, включая требование IP для частных конечных точек или выделенных подсетей для таких служб, как Azure NetApp Files.
• Маршрутизация сети в системы SAP и подключенные приложения.
• Использование общедоступной или частной конечной точки для Файлы Azure.

Сведения о требованиях и использовании общего ресурса NFS или SMB в сценарии высокой доступности см. в статье "Высокий уровень доступности".

Безопасность для ландшафта SAP

Чтобы защитить рабочую нагрузку SAP в Azure, необходимо спланировать несколько аспектов безопасности:

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

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

• Хорошо спроектированная платформа Azure: основа безопасности
• Azure Cloud Adoption Framework: безопасность

Защита виртуальных сетей с помощью групп безопасности

Планирование ландшафта SAP в Azure должно включать некоторую степень сегментации сети с виртуальными сетями и подсетями, выделенными только для рабочих нагрузок SAP. Рекомендации по определению подсети описаны в разделе "Сеть" и в других руководствах по архитектуре Azure. Рекомендуется использовать группы безопасности сети с ASG в группах безопасности сети для разрешения входящего и исходящего подключения. При разработке ASG каждый сетевой адаптер на виртуальной машине может быть связан с несколькими ASG, чтобы создавать разные группы. Например, создайте ASG для виртуальных машин СУБД, которые содержат все серверы баз данных в ландшафте. Создайте другую ASG для всех виртуальных машин (приложений и СУБД) одного идентификатора безопасности SAP. Таким образом, можно определить одно правило NSG для общей базы данных ASG и другого, более конкретное правило только для группы безопасности безопасности.

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

Частные конечные точки для служб

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

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

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

Шифрование

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

Шифрование ресурсов инфраструктуры

По умолчанию управляемые диски и хранилище BLOB-объектов в Azure шифруются с помощью управляемого платформой ключа (PMK). Кроме того, для управляемых дисков и хранилища BLOB-объектов поддерживается шифрование собственного ключа (BYOK) для рабочих нагрузок SAP в Azure. Для шифрования управляемых дисков можно выбрать разные варианты в зависимости от требований корпоративной безопасности. Параметры шифрования Azure включают:

• Шифрование на стороне хранилища (SSE) PMK (SSE-PMK)
• Ключ, управляемый клиентом SSE (SSE-CMK)
• Двойное шифрование неактивных данных
• Шифрование на основе узла

Дополнительные сведения, включая описание Шифрование дисков Azure, см. в сравнении параметров шифрования Azure.

Для развертываний SAP в системах Linux не используйте Шифрование дисков Azure. Шифрование дисков Azure влечет за собой шифрование, работающее на виртуальных машинах SAP с помощью cmKs из Azure Key Vault. Для Linux Шифрование дисков Azure не поддерживает образы операционной системы, используемые для рабочих нагрузок SAP. Шифрование дисков Azure можно использовать в системах Windows с рабочими нагрузками SAP, но не объединять Шифрование дисков Azure с собственным шифрованием базы данных. Рекомендуется использовать собственное шифрование базы данных вместо Шифрование дисков Azure. Для получения дополнительных сведений см. следующий раздел.

Аналогично шифрованию управляемых дисков, Файлы Azure шифрование неактивных данных (SMB и NFS) доступно с помощью PMKs или CMK.

Для общих сетевых ресурсов SMB внимательно просмотрите Файлы Azure и зависимости операционной системы с версиями SMB, так как конфигурация влияет на поддержку шифрования в транзитном режиме.

Шифрование компонентов SAP

Шифрование на уровне SAP можно разделить на два уровня:

• Шифрование СУБД
• Шифрование транспорта

Для шифрования СУБД каждая база данных, поддерживаемая для SAP NetWeaver или развертывания SAP S/4HANA, поддерживает собственное шифрование. Прозрачное шифрование базы данных полностью не зависит от любого шифрования инфраструктуры, которое выполняется в Azure. Одновременно можно использовать шифрование SSE и базы данных. При использовании шифрования важно расположение, хранилище и хранение ключей шифрования. Любая потеря ключей шифрования приводит к потере данных, так как вы не сможете запустить или восстановить базу данных.

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

• Шифрование данных и тома журнала SAP HANA
• SQL Server: заметка SAP 1380493
• Oracle: sap Note 974876
• IBM Db2: sap Note 1555903
• SAP ASE: заметка SAP 1972360

Обратитесь в службу поддержки SAP или поставщика СУБД, чтобы узнать, как включить, использовать или устранять неполадки с шифрованием программного обеспечения.

Шифрование транспорта или связи может применяться к подключениям SQL Server между ядрами SAP и СУБД. Аналогичным образом можно шифровать подключения из уровня презентации SAP (безопасное сетевое подключение SAPGui или SNC) или подключение HTTPS к веб-интерфейсу. Ознакомьтесь с документацией поставщика приложений, чтобы включить и управлять шифрованием при передаче.

Мониторинг угроз и оповещения

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

Дополнительные сведения об управлении событиями безопасности (SIEM) и автоматическом реагировании системы безопасности (SOAR) см . в решениях Microsoft Sentinel для интеграции SAP.

Программное обеспечение безопасности на виртуальных машинах SAP

Примечания SAP 2808515 для Linux и SAP Note 106267 для Windows описывают требования и рекомендации при использовании сканеров вирусов или программного обеспечения безопасности на серверах SAP. Рекомендуется следовать рекомендациям SAP при развертывании компонентов SAP в Azure.

Высокая доступность

Высокий уровень доступности SAP в Azure состоит из двух компонентов:

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

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

  • Экземпляр SAP (A)SCS и SAP ERS
  • Сервер базы данных

Дополнительные сведения о высокой доступности SAP в Azure см. в следующих статьях:

• Поддерживаемые сценарии: защита высокой доступности для уровня СУБД SAP
• Поддерживаемые сценарии: высокий уровень доступности для служб SAP Central
• Поддерживаемые сценарии: поддерживаемая хранилище для сценариев SAP Central Services
• Поддерживаемые сценарии: отказоустойчивые кластеры SAP Central Services с несколькими sid
• Руководство по обеспечению высокого уровня доступности SAP NetWeaver на виртуальных машинах Azure
• Архитектура и сценарии высокой доступности для SAP NetWeaver
• Использование перезапуска виртуальной машины инфраструктуры Azure для повышения доступности системы SAP без кластеризации
• Конфигурации рабочих нагрузок SAP с зонами доступности Azure
• Подключение к общедоступной конечной точке для виртуальных машин с помощью Azure Load Balancer (цен. категория в сценариях высокой доступности SAP

Pacemaker в Linux и отказоустойчивом кластеризации Windows Server — это единственные платформы высокой доступности для рабочих нагрузок SAP, которые напрямую поддерживаются корпорацией Майкрософт в Azure. Любая другая платформа высокого уровня доступности не поддерживается корпорацией Майкрософт и будет нуждаться в разработке, сведениях о реализации и поддержке операций от поставщика. Дополнительные сведения см. в статье "Поддерживаемые сценарии для SAP в Azure".

Аварийное восстановление

Часто приложения SAP являются одними из наиболее критически важных для бизнеса процессов в организации. На основе их важности и времени, необходимого для повторной работы после непредвиденных прерываний, сценариев непрерывности бизнес-процессов и аварийного восстановления (BCDR) следует тщательно планировать.

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

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

В рамках стратегии BCDR резервное копирование рабочей нагрузки SAP должно быть неотъемлемой частью любого запланированного развертывания. Решение резервного копирования должно охватывать все слои стека решений SAP: виртуальную машину, операционную систему, уровень приложений SAP, уровень СУБД и любое общее решение для хранения. Резервное копирование для служб Azure, используемых рабочей нагрузкой SAP, и для других важных ресурсов, таких как шифрование и ключи доступа, также должны быть частью вашей структуры резервного копирования и BCDR.

Azure Backup предлагает решения PaaS для резервного копирования:

• Конфигурация виртуальных машин, операционная система и уровень приложений SAP (изменение размера данных на управляемых дисках) с помощью Azure Backup для виртуальной машины. Просмотрите матрицу поддержки, чтобы убедиться, что архитектура может использовать это решение.
• Sql Server и SAP HANA базы данных и резервное копирование журналов. Она включает поддержку технологий репликации баз данных, таких как репликация системы HANA или SQL AlwaysOn, а также поддержка между регионами для парных регионов.
• Резервное копирование файлового ресурса через Файлы Azure. Проверьте поддержку NFS или SMB и другие сведения о конфигурации.

Кроме того, при развертывании Azure NetApp Files параметры резервного копирования доступны на уровне тома, включая интеграцию SAP HANA и Oracle DBMS с запланированной резервной копией.

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

Параметры резервного копирования доступны для решения, которое вы создаете и управляете самостоятельно или используете стороннее программное обеспечение. Можно использовать службы с служба хранилища Azure, включая использование неизменяемого хранилища для данных BLOB-объектов. Этот автономный вариант в настоящее время требуется в качестве варианта резервного копирования СУБД для некоторых баз данных, таких как SAP ASE или IBM Db2.

Используйте рекомендации в рекомендациях Azure для защиты и проверки атак программ-шантажистов .

Резервное копирование между регионами

Для любого требования к резервному копированию между регионами определите целевой объект времени восстановления (RTO) и целевую точку восстановления (RPO), предлагаемую решением, и соответствует ли она проектированию и потребностям BCDR.

Миграция SAP в Azure

Невозможно описать все подходы и варианты миграции для большого количества продуктов SAP, зависимостей версий и собственных операционных систем и технологий СУБД, доступных. Команда проектов для вашей организации и представителей со стороны поставщика услуг должна рассмотреть несколько методов плавной миграции SAP в Azure.

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

• Используйте службы Azure для миграции SAP. Некоторые рабочие нагрузки на основе виртуальных машин переносятся без изменения в Azure с помощью таких служб, как миграция Azure или Azure Site Recovery, или стороннее средство. Старательно убедитесь, что версия операционной системы и выполняемая им рабочая нагрузка SAP поддерживаются службой.

  Часто любая рабочая нагрузка базы данных намеренно не поддерживается, так как служба не может гарантировать согласованность базы данных. Если тип СУБД поддерживается службой миграции, скорость изменения базы данных или оттока часто слишком высока. Большинство занятых систем SAP не соответствуют частоте изменений, которые позволяют средства миграции. Проблемы могут не быть замечены или обнаружены до миграции рабочей среды. Во многих ситуациях некоторые службы Azure не подходят для переноса систем SAP. Служба "Миграция Azure Site Recovery" и "Миграция Azure" не имеют проверки для крупномасштабной миграции SAP. Проверенная методология миграции SAP заключается в том, чтобы полагаться на репликацию СУБД или средства миграции SAP.

  Развертывание в Azure вместо простой миграции виртуальных машин предпочтительнее и проще выполнить, чем локальная миграция. Платформы автоматического развертывания, такие как Azure Center для решений SAP и платформа автоматизации развертывания Azure, позволяют быстро выполнять автоматизированные задачи. Чтобы перенести ландшафт SAP в новую развернутую инфраструктуру с помощью собственных технологий репликации СУБД, таких как репликация системы HANA, резервное копирование СУБД и восстановление, или средства миграции SAP используют установленные технические знания о системе SAP.

• Масштабирование инфраструктуры. Во время миграции SAP с большей емкостью инфраструктуры можно ускорить развертывание. Команда проектов должна рассмотреть возможность увеличения размера виртуальной машины, чтобы обеспечить больше ресурсов ЦП и памяти. Кроме того, следует рассмотреть возможность масштабирования статистического хранилища виртуальных машин и пропускной способности сети. Аналогичным образом, на уровне виртуальной машины рассмотрите такие элементы хранилища, как отдельные диски, чтобы увеличить пропускную способность с увеличением нагрузки по запросу и уровнями производительности для SSD уровня "Премиум" версии 1. Увеличьте значения операций ввода-вывода в секунду и пропускную способность, если вы используете SSD уровня "Премиум" версии 2 выше настроенных значений. Увеличьте общие папки NFS и SMB, чтобы увеличить ограничения производительности. Имейте в виду, что управление дисками Azure не может быть уменьшено в размерах, а также что уменьшение размера, уровней производительности и ключевых показателей производительности пропускной способности может иметь различные периоды охлаждения.

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

  Использование ExpressRoute или VPN может привести к узким местам:

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

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

Поддержка и операции для SAP

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

Расширение виртуальной машины Azure для SAP

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

SAProuter для поддержки SAP

Для работы с ландшафтом SAP в Azure требуется подключение к SAP и из SAP в целях поддержки. Как правило, подключение находится в виде подключения SAProuter либо через канал шифрования через Интернет, либо через частный VPN-подключение к SAP. Рекомендации и пример реализации SAProuter в Azure см. в сценарии архитектуры в входящих и исходящих подключениях к Интернету для SAP в Azure.

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

• Развертывание рабочей нагрузки SAP в Azure
• Важные аспекты развертывания СУБД для рабочих нагрузок SAP на виртуальных машинах Azure
• Рабочие нагрузки SAP в Azure: контрольный список планирования и развертывания
• Масштабируемые наборы виртуальных машин для рабочей нагрузки SAP