Изменить

Поделиться через

Ландшафтная архитектура SAP

Виртуальные машины Azure
Виртуальная сеть Azure
Файлы Azure
Azure Load Balancer

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

Архитектура

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

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

Рабочий процесс

  1. Локальная сеть. Подключение ExpressRoute из локальной сети к подключенным регионам Azure.
  2. Региональные центры подписки Azure: подписка Azure, содержащая центральные службы для всего предприятия, а не только SAP. Подписка концентратора обеспечивает подключение путем пиринга к периферийным виртуальным сетям, содержащим рабочие нагрузки SAP.
  3. Виртуальная сеть концентратора. Виртуальная сеть, периферийная для центрального концентратора в основном регионе или регионе A.
  4. Виртуальная сеть аварийного восстановления (DR) концентратора. Виртуальная сеть периферийной для центрального концентратора в регионе аварийного восстановления. Он отражает структуру подсети рабочей виртуальной сети в основном регионе.
  5. Подписка Azure SAP непроизводственная. Подписка Azure для всех непроизводственных рабочих нагрузок SAP. Она включает в себя предварительную среду, среду контроля качества, разработку и песочницу.
  6. Периферийные виртуальные сети SAP: отдельные виртуальные сети для непроизводственных рабочих нагрузок SAP в основном регионе. Каждая среда SAP имеет собственную виртуальную сеть и подсети.
  7. Подписка Azure SAP production— подписка Azure для всех рабочих нагрузок SAP.
  8. Периферийная виртуальная сеть SAP: виртуальная сеть для рабочей среды SAP с несколькими подсетями. Эта виртуальная сеть находится в основном регионе.
  9. Периферийная виртуальная сеть sap production disaster recovery (DR) — виртуальная сеть для рабочей среды SAP в дополнительном регионе аварийного восстановления. Он отражает структуру подсети рабочей виртуальной сети в основном регионе.
  10. Службы Azure. Выборка служб Azure, которые можно подключить к ландшафту SAP.
  11. Платформа бизнес-технологий SAP (BTP): среда SAP обращается к платформе SAP Business Technology Platform через Приватный канал Azure.

Подписки Azure

Рекомендуется использовать звездообразную сеть. Благодаря звездообразной структуре вам потребуется по крайней мере три подписки для разделения сред SAP. У вас должна быть подписка на (1) виртуальные сети регионального концентратора, (2) нерабочие виртуальные сети и (3) рабочие виртуальные сети. Подписки предоставляют границы выставления счетов, политики и безопасности. Правильное количество подписок отсутствует. Количество используемых подписок зависит от требований к выставлению счетов, политике и безопасности. Как правило, вы хотите избежать использования слишком большого количества подписок. Слишком большое количество подписок может привести к лишним затратам на управление и сложности сети. Например, вам не требуется подписка для каждой системы SAP. В нашей архитектуре используются три подписки:

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

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

  • SAP production : рабочая подписка Azure SAP, в которой мы настроили системы рабочего и аварийного восстановления.

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

Проектирование сети

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

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

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

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

Используйте центральный брандмауэр. Весь сетевой трафик к периферийным виртуальным сетям, включая подключения к удаленному вызову функций (RFC), должен проходить через центральный брандмауэр в виртуальной сети концентратора. Сетевое взаимодействие между периферийными виртуальными сетями (периферийное взаимодействие) проходит через брандмауэр виртуальной сети концентратора в подсети Брандмауэр Azure виртуальной сети концентратора. Аналогичным образом сетевой обмен данными между периферийными виртуальными сетями и локальной сетью также проходит через брандмауэр виртуальной сети концентратора. Мы использовали пиринг между виртуальными сетями для подключения различных периферийных виртуальных сетей к виртуальной сети концентратора. Весь обмен данными между периферийными виртуальными сетями проходит через брандмауэр виртуальной сети концентратора. Вместо брандмауэра можно также использовать виртуальную сетевую (модуль). Дополнительные сведения см. в статье Сетевые виртуальные (модуль).

Сетевой трафик, который остается в виртуальной сети, не должен проходить через брандмауэр. Например, не размещайте брандмауэр между подсетью приложения SAP и подсетью базы данных SAP. Невозможно разместить брандмауэр или сетевые виртуальные модули (NVA) между приложением SAP и уровнем системы управления базами данных (СУБД) систем SAP, на которых выполняется ядро SAP.

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

подсети;

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

Количество подсетей

Рабочая виртуальная сеть в архитектуре имеет пять подсетей. Эта конструкция идеально подходит для крупных корпоративных решений. Количество подсетей может быть меньше или больше. Количество ресурсов в виртуальной сети должно определять количество подсетей в виртуальной сети.

Изменение размера подсети

Убедитесь, что подсети имеют достаточное сетевое адресное пространство. Если вы используете имена виртуальных узлов SAP, вам потребуется больше адресного пространства в подсетях SAP. Часто каждому экземпляру SAP требуется 2–3 IP-адреса и один IP-адрес для имени узла виртуальной машины. Другим службам Azure может потребоваться собственная выделенная подсеть при развертывании в виртуальных сетях рабочей нагрузки SAP.

Подсеть приложения

Подсеть приложения содержит виртуальные машины с серверами приложений SAP, центральными службами SAP (ASCS), службами репликации sap enqueue (ERS) и экземплярами SAP Web Dispatcher. Подсеть также содержит частную конечную точку для Файлы Azure. На схеме мы сгруппировали виртуальные машины по роли. Для устойчивого развертывания рекомендуется использовать масштабируемые наборы виртуальных машин с гибкой оркестрацией, зонами доступности или группами доступности. Дополнительные сведения см. в разделе Дальнейшие действия.

Подсеть базы данных

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

Подсети периметра

Подсети периметра имеют доступ к Интернету и включают подсеть периметра SAP и подсеть Шлюз приложений. Ниже приведены рекомендации по проектированию этих двух подсетей.

Подсеть периметра SAP. Подсеть периметра SAP — это сеть периметра, которая содержит приложения с выходом в Интернет, такие как SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent и Шлюз приложений. Эти службы зависят от систем SAP, которые команда SAP должна развертывать, администрировать и настраивать. Центральная ИТ-команда не должна управлять службами в подсети периметра SAP. По этой причине эти службы следует размещать в периферийной виртуальной сети SAP, а не в виртуальной сети концентратора. На схеме архитектуры показана только рабочая сеть периметра SAP. У него нет подсети периметра SAP в непроизводственных виртуальных сетях. Рабочие нагрузки в нерабочей подписке SAP используют службы в подсети периметра SAP.

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

Шлюз приложений подсеть: Шлюз приложений Azure требуется собственная подсеть. Используйте его, чтобы разрешить трафик из Интернета, который могут использовать службы SAP, такие как SAP Fiori. Рекомендуемая архитектура размещает Шлюз приложений Azure вместе с внешним общедоступным IP-адресом в виртуальной сети концентратора. Для Шлюз приложений Azure требуется по крайней мере подсеть размера /29. Рекомендуется размер /27 или больше. Нельзя использовать обе версии Шлюз приложений (версии 1 и 2) в одной подсети. Дополнительные сведения см. в разделе Подсеть для Шлюз приложений Azure.

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

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

Скачайте файл Visio с этой альтернативной архитектурой.

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

Более эффективное реагирование на инциденты. Периферийная виртуальная сеть SAP позволяет быстро изолировать скомпрометированные службы при обнаружении брейка. Вы можете удалить пиринг виртуальных сетей из периферийной виртуальной сети SAP периметра к концентратору и немедленно изолировать рабочие нагрузки периметра SAP и приложения виртуальной сети приложений SAP из Интернета. Вы не хотите полагаться на изменения правил группы безопасности сети (NSG) для реагирования на инциденты. Изменение или удаление правила NSG влияет только на новые подключения и не разорвет существующие вредоносные подключения.

Детализированное управление доступом к сети. Виртуальная сеть периметра SAP обеспечивает более строгий контроль доступа к виртуальной сети в рабочей периферийной виртуальной сети SAP и из нее.

Повышенная сложность, задержка и затраты. Архитектура повышает сложность, затраты и задержки управления. Обмен данными с подключением к Интернету из рабочей виртуальной сети SAP выполняется дважды: один раз к центральной виртуальной сети, а затем к виртуальной сети периметра SAP через Интернет. Брандмауэр в виртуальной сети концентратора оказывает наибольшее влияние на задержку. Мы рекомендуем измерить задержку, чтобы узнать, поддерживает ли ваш вариант использования.

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

Azure NetApp Files подсеть

Если вы используете NetApp Files, у вас должна быть делегированная подсеть для предоставления файловых ресурсов сетевой файловой системы (NFS) или SMB для различных сценариев SAP в Azure. Подсеть /24 — это размер по умолчанию для подсети NetApp Files, но размер можно изменить в соответствии со своими потребностями. Используйте собственные требования, чтобы определить правильный размер. Дополнительные сведения см. в разделе Делегированная подсеть.

Безопасность подсети

Использование подсетей для группировки ресурсов SAP с одинаковыми требованиями к правилам безопасности упрощает управление безопасностью.

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

Группы безопасности приложений (ASG). Мы рекомендуем использовать группы безопасности приложений для группирования сетевых интерфейсов виртуальных машин и ссылок на группы безопасности приложений в правилах группы безопасности сети. Такая конфигурация упрощает создание правил и управление ими для развертываний SAP. Каждый сетевой интерфейс может принадлежать нескольким группам безопасности приложений с разными правилами группы безопасности сети. Дополнительные сведения см. в разделе Группы безопасности приложений.

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

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

Использование Приватный канал Azure для платформы бизнес-технологий SAP (BTP): Приватный канал Azure для платформы бизнес-технологий SAP (BTP) теперь общедоступна. SAP Приватный канал Service поддерживает подключения из SAP BTP, среды выполнения Cloud Foundry и других служб. Примеры сценариев включают SAP S/4HANA или SAP ERP, запущенные на виртуальной машине. Они могут подключаться к собственным службам Azure, таким как База данных Azure для MariaDB и База данных Azure для MySQL.

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

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

Общие папки сетевой файловой системы (NFS) и SMB

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

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

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

Имя общей папки Использование Рекомендация
sapmnt Распределенные системные, профильные и глобальные каталоги SAP Выделенная общая папка для каждой системы SAP без повторного использования
cluster Общие папки с высоким уровнем доступности для ASCS, ERS и базы данных в зависимости от проекта Выделенная общая папка для каждой системы SAP без повторного использования
saptrans Каталог транспорта SAP Одна доля для одного или нескольких ландшафтов SAP (ERP, Business Warehouse)
interface Обмен файлами с приложениями, не относящиеся к SAP Требования клиента, отдельные общие папки для каждой среды (рабочая, непроизводственная)

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

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

Службы данных

Архитектура содержит службы данных Azure, которые помогают расширить и улучшить платформу данных SAP. Чтобы помочь разблокировать бизнес-аналитику, мы рекомендуем использовать такие службы, как Azure Synapse Analytics, Фабрика данных Azure и Azure Data Lake Storage. Эти службы данных помогают анализировать и визуализировать данные SAP и данные, не относящиеся к SAP.

Для многих сценариев интеграции данных требуется среда выполнения интеграции. Среда выполнения интеграции Azure — это инфраструктура вычислений, которую Фабрика данных Azure и конвейеры Azure Synapse Analytics используют для предоставления возможностей интеграции данных. Мы рекомендуем развертывать виртуальные машины среды выполнения для этих служб отдельно для каждой среды. Дополнительные сведения см. в разделе:

Общие службы

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

Подсистемы балансировки нагрузки. Мы рекомендуем использовать одну подсистему балансировки нагрузки для каждой системы SAP. Такая конфигурация помогает свести к минимуму сложность. Вы хотите избежать слишком большого количества пулов и правил в одной подсистеме балансировки нагрузки. Эта конфигурация также гарантирует соответствие именования и размещения системе SAP и группе ресурсов. Каждая система SAP с кластеризованной архитектурой высокого уровня доступности (HA) должна иметь по крайней мере одну подсистему балансировки нагрузки. Архитектура использует одну подсистему балансировки нагрузки для виртуальных машин ASCS и вторую подсистему балансировки нагрузки для виртуальных машин базы данных. Для создания высокодоступного развертывания для некоторых баз данных может не потребоваться подсистемы балансировки нагрузки. SAP HANA делает. Дополнительные сведения см. в документации по конкретной базе данных.

Шлюз приложений. Мы рекомендуем использовать по крайней мере один шлюз приложений для каждой среды SAP (рабочая, непроизводственная и песочница), если только сложность и количество подключенных систем не слишком высоки. Шлюз приложений можно использовать для нескольких систем SAP, чтобы снизить сложность, так как не всем системам SAP в среде требуется общий доступ. Один шлюз приложений может обслуживать несколько портов веб-диспетчера для одной системы SAP S/4HANA или использоваться различными системами SAP.

Виртуальные машины ВЕБ-диспетчера SAP. Архитектура показывает пул из двух или более виртуальных машин веб-диспетчера SAP. Мы не рекомендуем повторно использовать виртуальные машины SAP Web Dispatcher между разными системами SAP. Их разделение позволяет размеру виртуальных машин веб-диспетчера в соответствии с потребностями каждой системы SAP. Для небольших решений SAP рекомендуется внедрить службы веб-диспетчера в экземпляр ASCS.

Службы SAP. Службы SAP, такие как SAProuter, Cloud Connector и Analytics Cloud Agent, развертываются в соответствии с требованиями приложения, централизованно или разделенными. Нет рекомендаций по повторному использованию между системами SAP из-за различных требований клиентов. Основное решение, которое необходимо принять, упоминается в разделе о сети, если и когда следует использовать подсеть периметра SAP для непроизводственной среды. В противном случае с только рабочей подсетью периметра для SAP службы периметра SAP будут потребляться всей ландшафтной средой SAP.

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

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

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

Центральные службы и подключение к локальной среде. Подключение к локальным и ключевым центральным службам (DNS или брандмауэрам) должно быть доступно в регионе аварийного восстановления. Доступность и изменение конфигурации центральных ИТ-служб должны быть частью плана аварийного восстановления. Центральные ИТ-службы являются ключевыми компонентами работающей среды SAP.

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

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

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

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

Архитектура SAP меньшего размера

Для небольших решений SAP может быть полезно упростить проектирование сети. Затем виртуальная сеть каждой среды SAP будет подсетями в такой объединенной виртуальной сети. Любое упрощение требований к проектированию сети и подписки может повлиять на безопасность. Необходимо повторно оценить сетевую маршрутизацию, доступ к общедоступным сетям и из нее, доступ к общим службам (общим папкам) и доступ к другим службам Azure. Ниже приведены некоторые варианты сжатия архитектуры в соответствии с потребностями организации.

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

Объединение подсети периметра SAP и подсети приложения. Вы можете объединить подсеть периметра и подсеть приложения SAP. Необходимо уделять повышенное внимание правилам группы безопасности сети и использованию группы безопасности приложений. Мы рекомендуем использовать этот упрощенный подход только для небольших объектов SAP.

Объединение периферийных виртуальных сетей SAP между разными средами SAP Архитектура использует разные виртуальные сети для каждой среды SAP (центральная, рабочая, непроизводственная и аварийное восстановление). В зависимости от размера ландшафта SAP вы можете объединить периферийные виртуальные сети SAP в меньшее или даже только одну периферийную сеть SAP. По-прежнему необходимо разделить рабочую и нерабочую среды. Каждая рабочая среда SAP становится подсетью в одной рабочей виртуальной сети SAP. Каждая непроизводственная среда SAP становится подсетью в одной непроизводственной виртуальной сети SAP.

Соавторы

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

Основные авторы:

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