Изменить

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

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

Подписки Azure

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

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

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

  • Рабочая среда SAP: рабочая подписка 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 Central Services (ASCS), службами репликации SAP Enqueue (ERS) и экземплярами веб-диспетчера SAP. Подсеть также содержит частную конечную точку для Файлы 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 Приватный канал поддерживает подключения из SAP BTP, среды выполнения Cloud Foundry и других служб. Примеры сценариев включают SAP S/4HANA или SAP ERP, работающие на виртуальной машине. Они могут подключаться к собственным службам Azure, таким как База данных Azure для MariaDB и База данных Azure для MySQL.

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

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

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

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

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

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

Имя общей папки Использование Рекомендация
sapmnt Распределенная система SAP, профиль и глобальные каталоги Выделенная общая папка для каждой системы SAP, не используется повторно
cluster Общие папки с высоким уровнем доступности для ASCS, ERS и базы данных на соответствующую структуру Выделенная общая папка для каждой системы SAP, не используется повторно
saptrans Каталог транспорта SAP Одна общая папка для одного или нескольких ландшафтов SAP (ERP, бизнес-склад)
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 между различными системами SAP. Сохранение их отдельных позволяет масштабировать виртуальные машины веб-диспетчера в соответствии с потребностями каждой системы SAP. Для небольших решений SAP рекомендуется внедрить службы веб-диспетчера в экземпляр ASCS.

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

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

Аварийное восстановление (АВАРИЙНОе восстановление) устраняет требование обеспечения непрерывности бизнес-процессов в случае, если основной регион 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.

Соавторы

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

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

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