Подключение к SAP RISE
С помощью ландшафта SAP, работающего в рамках RISE и работающей в отдельной виртуальной сети, в этой статье мы предоставляем доступные варианты подключения.
Пиринг между виртуальными сетями при использовании SAP RISE/ECS
Пиринг между виртуальными сетями — это наиболее надежный способ безопасного подключения между двумя виртуальными сетями, все в адресном пространстве частной сети. Сети, для которых настроен пиринг, для всех подключений отображаются как одна сеть, что позволяет приложениям взаимодействовать друг с другом. Приложения, работающие в разных виртуальных сетях, подписках, клиентах Или регионах Azure, могут взаимодействовать напрямую. Как и сетевой трафик в одной виртуальной сети, пиринговый трафик остается в частном адресном пространстве и не проходит через Интернет. Применяются расходы на пиринг между виртуальными сетями.
Для развертываний SAP RISE/ECS виртуальный пиринг является предпочтительным способом создания подключений к существующей клиентской среде Azure. Основные преимущества:
- Минимальная задержка сети и максимальная пропускная способность между ландшафтом SAP RISE и собственными приложениями и службами, работающими в Azure.
- Дополнительная сложность и стоимость с выделенным локальным путем обмена данными для рабочей нагрузки SAP RISE. Вместо этого используется локальный путь связи существующих сетевых концентраторов Azure.
Пиринг виртуальных сетей можно настроить в том же регионе, где находится управляемая среда SAP, но можно также использовать пиринг глобальных виртуальных сетей между любыми двумя регионами Azure. При использовании SAP RISE/ECS, доступной во многих регионах Azure, регион должен соответствовать рабочей нагрузке, работающей в виртуальных сетях клиента, из-за задержки и затрат на пиринг. Однако некоторые сценарии (например, централизованное развертывание S/4HANA для глобальной компании) также требуют одноранговых сетей глобально. Для такого глобально распределенного ландшафта SAP рекомендуется использовать сетевую архитектуру нескольких регионов в собственной среде Azure с пирингом SAP RISE локально в каждом географическом регионе в сетевых центрах.
На этой схеме показаны типичная звездообразная схема клиентских виртуальных сетей SAP. Пиринг между виртуальными сетями между клиентами подключает виртуальные сети SAP RISE и концентратор клиента.
Виртуальные сети SAP и клиента защищены с помощью групп безопасности сети (NSG), разрешая обмен данными между портами SAP и баз данных через пиринг. Обмен данными между пиринговых виртуальных сетей обеспечивается с помощью этих групп безопасности сети, ограничивающих обмен данными с средой SAP клиента и из нее.
Так как SAP RISE/ECS выполняется в клиенте и подписках SAP SAP, настройте пиринг виртуальной сети между разными клиентами. Для этого настройте пиринг с идентификатором ресурса Azure в сети SAP и утвердите пиринг. Добавьте пользователя из противоположного клиента Microsoft Entra в качестве гостевого пользователя, примите приглашение гостевого пользователя и выполните описанный процесс при создании пиринга виртуальной сети — разные подписки. Конкретный процесс для выполнения этой задачи можно получить у представителя SAP. Для быстрого выполнения оркестрируйте соответствующий процесс с рамках организации для совместной работы сетевых подразделений, администратором пользователей и архитектуры.
VPN-виртуальная сеть — виртуальная сеть
В качестве альтернативы пирингу виртуальных сетей можно установить подключение между VPN-шлюзами, развернутыми как в подписке SAP RISE/ECS, так и у клиентов. Между этими двумя VPN-шлюзами можно установить подключение между виртуальными сетями, обеспечивая быстрое взаимодействие между двумя отдельными виртуальными сетями. Соответствующие сети и шлюзы могут находиться в разных регионах Azure.
На этой схеме показаны типичная звездообразная схема клиентских виртуальных сетей SAP. VPN-шлюз, расположенный в виртуальной сети SAP RISE, подключается через подключение между виртуальной сетью и виртуальной сетью в шлюзе, содержащемся в центральной виртуальной сети клиента.
Хотя пиринг между виртуальными сетями является рекомендуемой и более типичной моделью развертывания, vpn-виртуальная сеть — виртуальная сеть может упростить сложный виртуальный пиринг между клиентами и виртуальными сетями SAP RISE/ECS. VPN-шлюз выполняет роль точки входа в клиентскую сеть. Он управляется и защищается централизованной группой обслуживания. Пропускная способность сети ограничена выбранным номером SKU шлюза на обеих сторонах. Чтобы устранить требования к устойчивости, убедитесь, что шлюзы виртуальной сети, избыточные между зонами, используются для такого подключения.
Группы безопасности сети влияют как на клиент, так и на виртуальную сеть SAP, идентичную архитектуре пиринга, что обеспечивает обмен данными с портами SAP NetWeaver и HANA по мере необходимости. Сведения о том, как настроить VPN-подключение и с какими параметрами, вы можете получить у представителя SAP.
Подключение обратно к локальной среде
При наличии у клиента существующего развертывания Azure его локальная сеть уже подключена через канал ExpressRoute или VPN. Обычно для управляемых рабочих нагрузок SAP RISE/ECS используется тот же локальный сетевой путь. Предпочтительная архитектура — использовать существующие ER/VPN-шлюз в клиенте для этой цели, при этом подключенная виртуальная сеть SAP RISE рассматривается как периферийная сеть, подключенная к концентратору виртуальной сети клиента.
На этой схеме показаны типичная звездообразная схема клиентских виртуальных сетей SAP. Подключается к локальной среде с подключением. Пиринг между виртуальными сетями клиента подключает виртуальную сеть SAP RISE к центральной сети клиента. Пиринг между виртуальными сетями включает передачу удаленного шлюза, что позволяет получить доступ к виртуальной сети SAP RISE из локальной среды.
В такой архитектуре централизованные политики и правила безопасности, которые управляют сетевым подключением к клиентским рабочим нагрузкам, в полной мере применяются и к управляемым рабочим нагрузкам SAP RISE/ECS. Один и тот же локальный сетевой путь используется как для виртуальной сети SAP RISE/ECS, так и для клиента.
Если в настоящее время нет локального подключения к Azure, обратитесь к представителю SAP, чтобы получить подробные сведения о моделях подключений для рабочей нагрузки RISE. Если SAP RISE/ECS устанавливает локальную среду в RISE напрямую, такое локальное подключение доступно только для достижения управляемой виртуальной сети SAP. Такое выделенное подключение ExpressRoute или VPN в SAP RISE нельзя использовать для доступа к собственным виртуальным сетям Azure клиента.
Примечание.
Виртуальная сеть может иметь только один шлюз, локальный или удаленный. С пирингом виртуальной сети, установленным между SAP RISE с помощью удаленного транзита шлюза, шлюзы не могут быть добавлены в виртуальную сеть SAP RISE/ECS. Сочетание пиринга виртуальной сети с удаленным транзитом шлюза вместе с другим шлюзом виртуальной сети в виртуальной сети SAP RISE/ECS невозможно.
Виртуальная глобальная сеть с управляемыми рабочими нагрузками SAP RISE
Аналогично использованию сетевой архитектуры концентратора и периферийной сети с подключением как к виртуальной сети SAP RISE/ECS, так и к локальной сети, концентратор виртуальной глобальной сети Azure можно использовать для одной и той же цели. Рабочая нагрузка RISE — это периферийная сеть, подключенная к сетевому концентратору vWAN. Оба варианта подключения к SAP RISE, описанным ранее, — пиринг между виртуальными сетями, а также VPN-виртуальная сеть — доступны с виртуальной глобальной сетью.
Сетевой концентратор vWAN развертывается и управляется клиентом в собственной подписке. Клиент также полностью управляет локальным подключением и маршрутизацией через сетевой концентратор vWAN с доступом к одноранговой виртуальной сети SAP RISE.
Подключение во время миграции в SAP RISE
Миграция ландшафта SAP в SAP RISE выполняется на нескольких этапах в течение нескольких месяцев или дольше. Некоторые среды SAP переносятся уже и используются продуктивно, при подготовке других систем SAP к миграции. В большинстве клиентских проектов самые крупные и наиболее критически важные системы переносятся в середине или в конце проекта. Необходимо рассмотреть возможность достаточной пропускной способности для миграции данных или репликации базы данных, а не влиять на сетевой путь пользователей к уже продуктивным средам RISE. Уже перенесенные системы SAP также могут потребоваться взаимодействовать с ландшафтом SAP по-прежнему локально или в существующем поставщике услуг.
Во время планирования миграции в SAP RISE спланируйте, как на каждом этапе системы SAP доступны для вашей пользовательской базы и как передавать данные в виртуальную сеть RISE/ECS. Часто участвуют несколько расположений и сторон, таких как существующий поставщик услуг и центры обработки данных с собственным подключением к корпоративной сети. Убедитесь, что временные решения с VPN-подключениями созданы без учета того, как на последующих этапах данные SAP переносятся для наиболее критически важных для бизнеса систем.
Интеграция DNS с управляемыми рабочими нагрузками SAP RISE/ECS
Интеграция клиентских сетей с облачной инфраструктурой и обеспечение простой концепции разрешения имен является жизненно важной частью успешной реализации проекта. На этой схеме описывается один из распространенных сценариев интеграции принадлежащих SAP подписок, виртуальных сетей и инфраструктуры DNS с локальной сетью и службами DNS клиента. В таких настройках концентратор Azure или локальные DNS-серверы хранят все записи DNS. Инфраструктура DNS способна разрешать запросы DNS, поступающие от всех источников (локальные клиенты, службы Azure и управляемые среды SAP).
Описание и характеристики проекта
Настраиваемая конфигурация DNS для виртуальных сетей, принадлежащих SAP
Две виртуальные машины в DNS-серверах узла виртуальной сети Azure RISE/PCE Azure
Клиенты должны предоставить и делегировать sap поддомен/зону (например, ecs.contoso.com), чтобы назначить имена и создать перенаправленные и обратные записи DNS для виртуальных машин, работающих поддоменом или зоной SAP. DNS-серверы SAP поддерживают главную роль DNS для делегированной зоны.
Передача зоны DNS с DNS-сервера SAP на DNS-серверы клиента является основным методом репликации записей DNS из среды RISE/PCE.
Виртуальные сети Azure клиента также используют настраиваемую конфигурацию DNS, ссылающуюся на DNS-серверы клиента, расположенные в виртуальной сети Центра Azure.
При необходимости клиенты могут настроить частный DNS-сервер пересылки в виртуальных сетях Azure. Затем такой сервер пересылки отправляет DNS-запросы, поступающие из служб Azure на DNS-серверы SAP, предназначенные для делегированной зоны (например, ecs.contoso.com).
Передача зоны DNS применяется для проектов, когда клиенты работают с пользовательским решением DNS (например, серверами AD DS или BIND) в своей центральной виртуальной сети.
Примечание.
Предоставляемые Azure DNS и частные зоны Azure не поддерживают возможность передачи зоны DNS, поэтому невозможно использовать для приема репликации DNS с DNS-серверов SAP RISE/PCE/ECS. Кроме того, SAP обычно не поддерживает внешних поставщиков служб DNS для делегированной зоны.
SAP опубликовал запись блога о реализации DNS с SAP RISE в Azure, см. здесь.
Дополнительные сведения об использовании Azure DNS для SAP для других целей, кроме поддержки SAP RISE/ECS, см. в следующей записи блога.
Исходящие и входящие подключения к Интернету для SAP RISE/ECS
Для рабочих нагрузок SAP, взаимодействующих с внешними приложениями и интерфейсами, может потребоваться сетевой исходящий путь к Интернету. Аналогичным образом, в пользовательской базе вашей компании (например, SAP Fiori) требуется входящий интернет-трафик или входящий трафик к ландшафту SAP. Для управляемых рабочих нагрузок SAP RISE обратитесь к представителю SAP для изучения потребностей в таких путях обмена данными https/RFC/других путей связи. Сетевое подключение к Интернету по умолчанию не включено для клиентов SAP RISE/ECS и сети по умолчанию используют только частные диапазоны IP-адресов. Для подключения к Интернету необходимо вместе с SAP спланировать оптимальную защиту клиентского ландшафта SAP.
Если вы включите подключение к Интернету или входящий трафик с помощью SAP RISE, сетевое взаимодействие защищается с помощью различных технологий Azure, таких как группы безопасности сети, ASG, Шлюз приложений с Брандмауэр веб-приложений (WAF), прокси-серверы и другие в зависимости от использования и сетевых протоколов. Эти службы полностью управляются с помощью SAP в виртуальной сети и подписке SAP RISE/ECS. Сетевой путь SAP RISE к Интернету обычно остается в виртуальной сети SAP RISE/ECS и не передается в собственную виртуальную сеть клиента или из нее.
Приложения в собственной виртуальной сети клиента подключаются к Интернету непосредственно из соответствующей виртуальной сети или через централизованно управляемые службы клиента, такие как Брандмауэр Azure, Шлюз приложений Azure, шлюз NAT и другие. Подключение к SAP BTP из приложений, отличных от SAP RISE/ECS, принимает тот же сетевой путь, привязанный к Интернету на стороне. Если для такой интеграции требуется SAP Cloud Connecter, запустите его на виртуальных машинах клиента. Другими словами, обмен данными SAP BTP или любой общедоступной конечной точки находится на сетевом пути, управляемом клиентами, если рабочая нагрузка SAP RISE не участвует.
Подключение SAP BTP
Платформа SAP Business Technology Platform (BTP) предоставляет множество приложений, обычно доступных через общедоступный IP-адрес или имя узла через Интернет. Службы клиентов, работающие в подписках Azure, получают доступ к BTP через настроенный метод исходящего доступа, например центральный брандмауэр или исходящие общедоступные IP-адреса. Однако некоторые службы SAP BTP, такие как SAP Data Intelligence, получают доступ через отдельный пиринг виртуальной сети вместо общедоступной конечной точки.
SAP предлагает Приватный канал службы для клиентов, использующих SAP BTP в Azure для однонаправленных запросов, исходящих из BTP. Служба Приватного канала SAP подключает службы SAP BTP в клиентской сети Azure через диапазон частных IP-адресов, обеспечивая приватный доступ через службу приватного канала без выхода в Интернет. О доступности этой службы для рабочих нагрузок SAP RISE/ECS можно узнать в компании SAP. Дополнительные сведения о поддержке SAP Приватный канал для RISE см. здесь.
Изучите документацию SAP и серию записей блога по архитектуре службы Приватного канала SAP и методам организации приватного подключения, работы с DNS и сертификатами: Getting Started with BTP Private Link Service for Azure (Начало работы со службой "Приватный канал" для Azure).
Сетевые порты связи с SAP RISE
Любая служба Azure с доступом к виртуальной сети клиента может взаимодействовать с ландшафтом SAP, работающим в подписке SAP RISE/ECS через доступные порты.
Схема открытых портов в системе SAP RISE/ECS. Подключения RFC для BAPI и IDoc, https для OData и Rest/SOAP. ODBC/JDBC для прямых подключений базы данных к SAP HANA. Все подключения через пиринг частной виртуальной сети. Шлюз приложений с общедоступным IP-адресом для HTTPS в качестве возможного варианта, управляемый с помощью SAP.
Доступ к системе SAP в SAP RISE можно получить через открытые сетевые порты, настроенные и открытые SAP для использования. Протоколы HTTPS, RFC и JDBC/ODBC можно использовать через диапазоны адресов частной сети. Кроме того, приложения могут получить доступ через https через общедоступный IP-адрес, предоставляемый управляемым шлюзом приложений Azure SAP RISE. Дополнительные сведения и параметры для шлюза приложений и открытых портов NSG обратитесь к SAP.
Дополнительные сведения об интеграции служб Azure с SAP RISE позволяют расширить ландшафт SAP с помощью служб Azure.
Следующие шаги
См. соответствующую документацию: