Изменить

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

Развертывание SAP в Azure с помощью базы данных Oracle

Azure ExpressRoute
SAP HANA на крупных экземплярах Azure
Виртуальные машины Azure
Виртуальная сеть Azure
Azure NetApp Files

В этой эталонной архитектуре показан набор проверенных методик выполнения высокодоступного SAP NetWeaver с базой данных Oracle в Azure. Принципы архитектуры не зависят от ОС, однако, если иное не указано, предполагается, что архитектура основана на Linux.

На первой схеме показана эталонная архитектура SAP в Oracle в Azure. Рекомендуется развертывать между двумя зонами доступности.

Схема архитектуры рабочей системы SAP в Oracle в Azure.

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

Примечание.

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

Компоненты

Эта эталонная архитектура описывает типичную рабочую систему SAP, запущенную в Базе данных Oracle в Azure, в высокодоступном развертывании для обеспечения максимальной доступности системы. Архитектуру и ее компоненты можно настроить на основе бизнес-требований (целевой цели восстановления (RTO), целевой точки восстановления (RPO), ожиданий времени простоя, системной роли) и потенциально сокращенной до одной виртуальной машины. Макет сети упрощен для демонстрации архитектурных субъектов такой среды SAP и не предназначен для описания полной корпоративной сети.

Сеть

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

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

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

Шлюз, избыточный между зонами. Шлюз подключает различные сети, расширяя локальную сеть к виртуальной сети Azure. Мы рекомендуем использовать ExpressRoute для создания частных подключений, которые не проходят через общедоступный Интернет, но также можно использовать подключение типа "сеть — сеть ". Используйте избыточное по зонам azure ExpressRoute или VPN-шлюзы для защиты от сбоев зоны. Сведения о различиях между зональным развертыванием и развертыванием, избыточным между зонами, см . в шлюзах виртуальной сети, избыточных между зонами. Здесь стоит упомянуть, что IP-адреса, используемые для развертывания зон шлюзов, должны иметь номер SKU уровня "Стандартный".

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

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

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

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

Сетевые карты Azure поддерживают несколько IP-адресов. Эта поддержка соответствует рекомендуемой методике SAP использовать имена виртуальных узлов для установки. Полный обзор см . в заметке SAP 962955. (Для доступа к заметкам SAP требуется учетная запись SAP Service Marketplace.)

Виртуальные машины

Эта архитектура использует виртуальные машины (виртуальная машина). Для уровня приложений SAP виртуальные машины развертываются для всех ролей экземпляров — веб-диспетчера и серверов приложений — центральных служб SAP (A)SCS и ERS, а также серверов приложений (PAS, AAS). Настройте количество виртуальных машин на основе ваших требований. Руководство по планированию и реализации Виртуальные машины Azure содержит сведения о запуске SAP NetWeaver на виртуальных машинах.

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

Группы размещения близкого взаимодействия (PPG). При развертывании виртуальных машин в зонах доступности задержка в зоне обычно идеально подходит для приложений SAP. В редких ситуациях, когда задержка между базой данных и виртуальными машинами приложений должна быть снижена, можно использовать группы размещения близкого взаимодействия. В таких ситуациях PPG обеспечивают совместное размещение, что означает, что виртуальные машины находятся в одном центре обработки данных, чтобы минимизировать задержку приложения. Из-за потенциальных ограничений с PPG добавление базы данных AvSet в PPG системы SAP должно выполняться разреженно и только при необходимости. Дополнительные сведения о сценариях использования для PPG см. в связанной документации.

Виртуальные машины поколения 2(2-го поколения). Azure предлагает выбор при развертывании виртуальных машин, если они должны быть поколения 1 или 2. Виртуальные машины поколения 2 поддерживают ключевые функции, недоступные для виртуальных машин поколения 1. Особенно для очень крупных баз данных Oracle это важно, так как некоторые семейства виртуальных машин, такие как Mv2 или Mdsv2 , поддерживаются только в качестве виртуальных машин 2-го поколения. Аналогичным образом, сертификация SAP в Azure для некоторых более новых виртуальных машин может потребовать, чтобы они были только 2-го поколения для полной поддержки, даже если Azure разрешает оба этих виртуальных машина. Дополнительные сведения см. в заметке SAP 1928533 — приложения SAP в Microsoft Azure: поддерживаемые продукты и типы виртуальных машин Azure.

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

Хранилище

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

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

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

В Azure развертывание рабочей нагрузки SAP может быть региональным или зональным в зависимости от требований к доступности и устойчивости приложений SAP и выбранного региона. Azure предоставляет различные варианты развертывания, такие как Масштабируемые наборы виртуальных машин с гибкой оркестрацией (FD=1), зонами доступности и группами доступности для повышения доступности ресурсов. Чтобы получить полное представление о вариантах развертывания и их применимости в разных регионах Azure (в том числе между зонами, в пределах одной зоны или в регионе без зон), см . архитектуру и сценарии высокой доступности для SAP NetWeaver.

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

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

Примечание.

Зоны доступности поддерживать высокий уровень доступности в пределах региона, но они не эффективны для аварийного восстановления (аварийного восстановления). Расстояние между зонами слишком короткие. Типичные регионы аварийного восстановления должны находиться по крайней мере в 100 милях от основного региона.

Компоненты, относящиеся к Oracle. Виртуальные машины Базы данных Oracle развертываются в группе доступности или в разных зонах доступности. Каждая виртуальная машина содержит собственную установку программного обеспечения базы данных и хранилища локальной базы данных виртуальной машины. Настройте синхронную репликацию баз данных с помощью Oracle Data Guard между базами данных, чтобы обеспечить согласованность и разрешить низкое время службы RTO и RPO в случае отдельных сбоев. Помимо виртуальных машин базы данных дополнительные виртуальные машины с oracle Data Guard Observer необходимы для установки отработки отказа Oracle Data Guard Fast-Start. Виртуальные машины наблюдателя Oracle отслеживают состояние базы данных и репликации и упрощают отработку отказа базы данных автоматически без необходимости в любом диспетчере кластеров. Управление репликацией баз данных может сделать ставку, а затем использовать брокер Oracle Data Guard для удобства использования.

Дополнительные сведения о развертывании Oracle Data Guard см . в документации по Oracle Data Guard в Azure.

Эта архитектура использует собственные средства Oracle без фактического программного обеспечения кластера или необходимости подсистемы балансировки нагрузки на уровне базы данных. При быстрой отработки отказа Oracle Data Guard и конфигурации SAP процесс отработки отказа автоматизирован, а приложения SAP повторно подключаются к новой базе данных-источнику, если происходит отработка отказа. Различные сторонние решения кластера существуют в качестве альтернативы, например SIOS Protection Suite или Veritas InfoScale, сведения о котором можно найти в соответствующей документации сторонних поставщиков соответственно.

Oracle RAC. Кластер приложений Oracle Real (RAC) в настоящее время не сертифицирован или поддерживается Oracle в Azure. Однако технологии и архитектура Oracle Data Guard для обеспечения высокой доступности могут обеспечить высокую устойчивость сред SAP с защитой от стойки, центра обработки данных или региональных прерываний обслуживания.

Уровень NFS. Для всех высокодоступных развертываний SAP необходимо использовать устойчивый уровень NFS, предоставляя тома NFS для каталога транспорта SAP, том sapmnt для двоичных файлов SAP, а также дополнительные тома для экземпляров SCS и ERS. Параметры предоставления уровня NFS

Кластер центральных служб SAP. Эта эталонная архитектура выполняет центральные службы на дискретных виртуальных машинах. Центральные службы — это потенциальная точка сбоя (SPOF) при развертывании на одной виртуальной машине. Для реализации высокодоступного решения требуется программное обеспечение управления кластерами, которое автоматизирует отработку отказа экземпляров SCS и ERS на соответствующую виртуальную машину. Так как это тесно связано с выбранным решением NFS

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

  • SUSE-Linux-only SBD (STONITH Block Device) — с помощью одной или трех дополнительных виртуальных машин, которые служат экспортом iSCSI небольшого блочного устройства, доступ к которому регулярно осуществляется фактическими виртуальными машинами-членами кластера, двумя (A)SCS/ERS в этом пуле кластеров. Виртуальные машины используют эти подключения SBD для приведения голосов и, следовательно, достижения кворума для решений кластера. Архитектура, содержащаяся на этой странице, не содержит 1 или 3 дополнительных виртуальных машин SBD.
  • Агент ограждения Azure. Без использования дополнительных виртуальных машин API управления Azure используется для регулярных проверок доступности виртуальных машин.

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

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

Пул веб-диспетчера SAP. Компонент "веб-диспетчер" используется как подсистема балансировки нагрузки для трафика SAP между серверами приложений SAP. Чтобы обеспечить высокий уровень доступности веб-диспетчера SAP, Azure Load Balancer реализует кластер отработки отказа или параллельную настройку веб-диспетчера.

Внедренный веб-диспетчер в (A)SCS — это специальный параметр. Следует учитывать правильный размер из-за дополнительной рабочей нагрузки в (A)SCS.

Для связи с Интернетом рекомендуется автономное решение в сети периметра (также известное как DMZ) для удовлетворения проблем безопасности.

Развертывания Windows. В этом документе, как описано в начале, основное внимание уделяется развертыванию на основе Linux. Для использования с Windows применяются одни и те же архитектурные принципы, и нет никаких архитектурных различий между Oracle и Windows.

Сведения о работе с частью приложения SAP см. в руководстве по архитектуре запуска SAP NetWeaver в Windows в Azure.

Рекомендации

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

На следующей схеме показана архитектура рабочей системы SAP в Oracle в Azure. Архитектура предоставляет аварийное восстановление и использует зоны доступности.

Схема, демонстрирующая архитектуру рабочей системы SAP в Oracle в Azure.

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

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

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

Резервное копирование для Oracle в Azure можно достичь несколькими средствами:

  • Azure Backup. Скрипты, предоставляемые и поддерживаемые Azure для базы данных Oracle и Azure Backup для решения задач резервного копирования Oracle .
  • служба хранилища Azure; Использование резервных копий базы данных на основе файлов, например запланированных с помощью средств BR SAP, для хранения и управления версиями в виде файлов и каталогов в azure BLOB-объектов NFS, BLOB-объектов Azure или служб хранилища Файлы Azure. См . сведения о том, как достичь резервных копий данных Oracle и журналов.
  • Сторонние решения для резервного копирования. См. архитектуру поставщика хранилища резервных копий, поддерживающую Oracle в Azure.

Для виртуальных машин, отличных от базы данных, azure Backup для виртуальной машины рекомендуется защитить виртуальные машины приложений SAP и окружить инфраструктуру, например SAP Web Dispatcher.

Соавторы

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

Автор субъекта:

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

Сообщества

Участники сообществ отвечают на вопросы и помогают настроить успешное развертывание. Рассмотрим следующие ресурсы:

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