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

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

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

В этом документе рассматриваются вопросы запуска связанных с SAP систем СУБД на виртуальных машинах Azure. Также здесь приводятся ссылки на конкретные СУБД. Конкретные СУБД рассматриваются ниже, после этой главы.

Определения

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

  • IaaS: инфраструктура как услуга.

  • PaaS: платформа как услуга.

  • SaaS: программное обеспечение как услуга.

  • Компонент SAP: отдельное приложение SAP, например ERP Central Component (ECC), Business Warehouse (BW), Solution Manager или Enterprise Portal (EP). Компоненты SAP могут основываться на традиционной технологии ABAP или Java или быть приложениями не на основе NetWeaver, например бизнес-объектами.

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

  • Ландшафт SAP: этот термин обозначает все ресурсы SAP, доступные в клиентском ИТ-ландшафте. Ландшафт SAP включает все рабочие и нерабочие среды.

  • Система SAP: сочетание уровня СУБД и уровня приложений системы разработки SAP ERP, тестовой системы SAP Business Warehouse и рабочей системы SAP CRM. В развертываниях Azure не поддерживается разделение этих двух уровней между локальной средой и Azure. Таким образом, систему SAP необходимо развернуть полностью в локальной среде или полностью в Azure. Вы можете развертывать разные системы ландшафта SAP как в Azure, так и локально. Например, системы разработки и тестирования SAP CRM можно развернуть в Azure, а производственную систему SAP CRM — в локальной среде.

  • Распределенное развертывание: описывает сценарии, при которых в подписке Azure развернуты виртуальные машины с подключениями "сеть — сеть" или Azure ExpressRoute между локальными центрами обработки данных и Azure. В документации Azure развертывания такого рода также называются распределенными развертываниями.

    Такое подключение используется для расширения в Azure локальных доменов, локальной службы Active Directory и локальной службы DNS. Локальная среда распространяется на ресурсы Azure, входящие в подписку. При таком расширении виртуальные машины могут быть частью локального домена. Пользователи локального домена могут получать доступ к серверам и запускать службы на этих виртуальных машинах (например, службы СУБД). Возможно взаимодействие и разрешение имен между виртуальными машинами, развернутыми в локальной сети и Azure. Этот сценарий является наиболее распространенным сценарием развертывания ресурсов SAP в Azure. Дополнительные сведения см. в разделе Планирование и проектирование VPN-шлюза.

Примечание

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

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

В некоторых документах Майкрософт сценарии распределенного подключения описываются иначе. В частности, это касается высокодоступных конфигураций СУБД. В документации по SAP сценарий распределенного подключения сводится к двум моментам: к наличию подключения типа "сеть — сеть" или частного подключения ExpressRoute, а также к распределению ландшафта SAP между локальной сетью и Azure.

Ресурсы

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

Следующие примечания SAP относятся к использованию SAP в Azure в области, описанной в настоящем документе.

Номер примечания Title
1928533 Приложения SAP в Azure: поддерживаемые продукты и типы виртуальных машин Azure
2015553 SAP в Microsoft Azure: необходимые компоненты для поддержки
1999351 Устранение неполадок, связанных с расширенным мониторингом Azure для SAP
2178632 Ключевые метрики мониторинга для SAP в Microsoft Azure
1409604 Виртуализация в Windows: расширенный мониторинг
2191498 SAP на платформе Linux в Azure: расширенный мониторинг
2039619 Приложения SAP в Microsoft Azure с использованием Oracle Database: поддерживаемые продукты и версии
2233094 DB6: приложения SAP в Azure с использованием IBM DB2 для Linux, UNIX и Windows Дополнительные сведения
2243692 Linux на виртуальной машине Microsoft Azure (IaaS): проблемы с лицензированием SAP
1984787 SUSE Linux Enterprise Server 12 Замечания по установке
2002167 Red Hat Enterprise Linux 7.x: Установка и обновление
2069760 Установка и обновление Oracle Linux 7.x SAP
1597355 Рекомендация по области буфера для Linux
2171857 Oracle Database 12c: поддержка файловой системы в Linux
1114181 Oracle Database 11g: поддержка файловой системы в Linux

Сведения обо всех примечаниях по SAP для Linux см. на вики-сайте сообщества SAP.

Вы узнаете об архитектуре Microsoft Azure и о том, как развертываются и эксплуатируются виртуальные машины Microsoft Azure. См. сведения в документации по Azure.

Как правило, установка и настройка Windows, Linux и СУБД в целом выполняются так же, как и для любой локальной виртуальной машины или локального физического компьютера. Но некоторые решения, связанные с архитектурой и реализацией управления системой, в Azure IaaS все же отличаются. В этом документе объясняются конкретные различия в архитектуре и управлении системой, которые следует учитывать при использовании Azure IaaS.

Структура хранилища виртуальной машины для развертывания реляционной СУБД

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

Необходимо ознакомиться с различными сериями виртуальных машин и отличиями между хранилищами классов Standard и Premium.

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

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

  • операционной системы (базовый виртуальный жесткий диск или виртуальный жесткий диск ОС);
  • исполняемых файлов системы управления базами данных;
  • исполняемых файлов SAP, например /usr/sap.

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

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

При планировании структуры диска следует установить оптимальный баланс между этими элементами:

  • Количество файлов данных.
  • Число дисков, содержащих файлы.
  • Квоты операций ввода-вывода для одного диска или общего ресурса NFS.
  • Пропускная способность одного диска или общего ресурса NFS.
  • Количество дополнительных доступных дисков в зависимости от размера виртуальной машины.
  • Общая пропускная способность хранилища или сети, которую может предоставить виртуальная машина.
  • Задержка для различных типов хранилища Azure.
  • Соглашения об уровне обслуживания для виртуальной машины.

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

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

Примечание

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

Примечание

Чтобы воспользоваться преимуществами соглашения SLA для одной ВМ Azure, все подключенные диски должны быть хранилищем Azure уровня "Премиум" или типом дисков Azure SSD (цен. категория "Ультра"), включая базовый виртуальный жесткий диск (хранилище Azure уровня "Премиум").

Примечание

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

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

Если ваши требования к числу операций ввода-вывода в секунду превышают возможности одного виртуального жесткого диска, следует сбалансировать необходимое количество операций ввода-вывода в секунду для файлов баз данных между несколькими виртуальными жесткими дисками. Самый простой способ распределить нагрузку по числу операций ввода-вывода в секунду между дисками — создать полосу программного чередования между несколькими дисками. Затем следует поместить ряд файлов данных СУБД SAP в LUN, полученные из полосы программного чередования. Число дисков в полосе чередования определяется требованиями к операциям ввода-вывода в секунду, пропускной способности диска и размеру пространства.


Windows storage striping Windows

Мы рекомендуем использовать дисковые пространства Windows для создания чередующихся наборов между несколькими виртуальными жесткими дисками Azure. Используйте как минимум Windows Server 2012 R2 или Windows Server 2016.

Linux storage striping Linux

Для создания программного RAID-массива в Linux поддерживаются только MDADM и LVM (диспетчер логических томов). Дополнительные сведения см. в разделе:


Для Azure SSD (цен. категория "Ультра") чередование не требуется, так как можно задать количество операций ввода-вывода в секунду и пропускную способность диска независимо от размера диска.

Примечание

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

Управляемые и неуправляемые диски

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

Помните, что для хранилища класса Standard существует ограничение на количество операций ввода-вывода в секунду на учетную запись хранения. См. строку Общая частота запросов в статье Целевые показатели масштабируемости и производительности службы хранилища Azure. Кроме того, существует изначальное ограничение на количество учетных записей хранения в одной подписке Azure. Сбалансируйте виртуальные жесткие диски для более крупного ландшафта SAP между несколькими учетными записями хранения, чтобы избежать превышения ограничений этих учетных записей. Если у вас несколько сотен виртуальных машин, а количество виртуальных жестких дисков превышает тысячу, это утомительная работа.

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

Чтобы избежать административной работы, связанной с планированием и развертыванием виртуальных жестких дисков в разных учетных записях хранения Azure, корпорация Майкрософт в 2017 году представила Управляемые диски Azure. Управляемые диски доступны для хранилища классов Standard и Premium. Ниже перечислены основные преимущества управляемых дисков по сравнению с неуправляемыми дисками.

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

Важно!

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

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

Кэширование для виртуальных машин и дисков данных

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

Приведенные ниже рекомендации даны исходя из следующих характеристик ввода-вывода для СУБД уровня "Стандартный":

  • Главным образом используются рабочие нагрузки чтения для файлов данных базы данных. Производительность этих операций чтения критически важна для СУБД.
  • Запись в файлы данных происходит скачкообразно на основе контрольных точек или постоянного потока. В среднем за день выполняется меньше операций записи, чем операций чтения. В отличие от операций чтения из файлов данных эти операции записи являются асинхронными и не задерживают пользовательские транзакции.
  • Вряд ли возникнут другие ситуации, когда понадобится чтение из журнала транзакций или файлов повторных операций. Исключениями являются крупные операции ввода-вывода при резервном копировании журналов транзакций.
  • Основной нагрузкой для файлов журнала транзакций и файлов повторных операций являются операции записи. В зависимости от характера рабочей нагрузки можно иметь операции ввода-вывода размером 4 КБ, тогда как в других случаях размер может превышать 1 МБ.
  • Все операции записи должны быть сохранены на диске надежным образом

Для службы хранилища класса Standard возможны следующие типы кэша.

  • None
  • Чтение
  • Чтение/запись

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

Для хранилища Azure уровня "Премиум" существуют следующие режимы кэширования:

  • None
  • Чтение
  • Чтение/запись
  • Нет + ускоритель записи (только для виртуальных машин Azure серии M)
  • Чтение + ускоритель записи (только для виртуальных машин Azure серии M)

Для хранилища класса Premium рекомендуется использовать параметр Read caching for data files (Кэширование чтения файлов данных) базы данных SAP и выбрать No caching for the disks of log file(s) (Без кэширования дисков файлов журнала).

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

Для SSD (цен. категория "Ультра") и Azure NetApp Files варианты кэширования не предлагаются.

Временные диски Azure

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

Дополнительные сведения см. в статье Общие сведения о временном диске на виртуальных машинах Windows в Azure.


Windows nonpersisted disk Windows

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

Linuxnonpersisted disk Linux

Виртуальные машины Azure под управлением Linux автоматически подключают диск к каталогу /mnt/resource — временному диску, который поддерживается локальными дисками на вычислительном узле Azure. "Временный" обозначает, что любые изменения содержимого каталога /mnt/resource теряются при перезагрузке виртуальной машины. Изменения касаются файлов, которые были сохранены, каталогов, которые были созданы, и приложений, которые были установлены.


Устойчивость службы хранилища Microsoft Azure

Основной виртуальный жесткий диск (с ОС) и подключенные диски или BLOB-объекты размещаются в службе хранилища Microsoft Azure не менее чем на трех различных узлах хранилища. Этот тип хранилища называется локально избыточным хранилищем (LRS). LRS используется по умолчанию для всех типов хранилищ в Azure.

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

Примечание

Рекомендуемый тип хранилища для виртуальных машин и дисков СУБД, в которых хранятся файлы базы данных, журналов и обновлений — хранилище Azure уровня "Премиум", SSD (цен. категория "Ультра") и Azure NetApp Files (исключительно для SAP HANA). Единственный доступный метод резервирования для этих типов хранилищ — LRS. Поэтому необходимо настроить методы базы данных для включения репликации данных базы данных в другой регион Azure или зону доступности. Можно использовать такие методы, как SQL Server Always On, Oracle Data Guard и репликация системы HANA.

Примечание

В развертываниях СУБД не рекомендуется использовать геоизбыточное хранилище (GRS) для хранилища класса Standard. GRS серьезно влияет на производительность и не учитывает порядок записи на разных виртуальных жестких дисках, подключенных к виртуальной машине. Это может привести к несогласованности баз данных на целевой стороне репликации. Такая ситуация возникает, если файлы базы данных, файлы журнала и файлы повторных операций распределены по нескольким виртуальным жестким дискам, как это обычно бывает на стороне исходной виртуальной машины.

Устойчивость узлов виртуальной машины

Azure предоставляет несколько разных соглашений об уровне обслуживания для виртуальных машин. Дополнительные сведения см. в последнем выпуске соглашения об уровне обслуживания для виртуальных машин. Так как уровень СУБД является важнейшим компонентом доступности системы SAP, необходимо ознакомиться с понятиями группы доступности, зоны доступности и событий обслуживания. Дополнительные сведения об этих понятиях см. в статьях Управление доступностью виртуальных машин Windows в Azure и Управление доступностью виртуальных машин Linux в Azure.

Минимальная рекомендация для рабочих сценариев СУБД с рабочей нагрузкой SAP такова:

  • Разверните две виртуальные машины в отдельных группах доступности в одном регионе Azure.
  • Запустите эти две виртуальные машины в одной и той же виртуальной сети Azure, причем их сетевые адаптеры должны быть подключены к одной и той же подсети.
  • Используйте методы базы данных для сервера горячей замены на второй виртуальной машине. Можно использовать такие методы, как SQL Server AlwaysOn, Oracle Data Guard и репликация системы HANA.

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

Сведения о настройке групп доступности Azure см. в этом руководстве.

Рекомендации по сети Azure

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

Приведенные ниже рекомендации были выработаны на основе анализа множества развертываний клиентов.

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

Примечание

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

Предупреждение

Настройка виртуальных сетевых модулей Azure в пути взаимодействия между уровнем приложений SAP и уровнем СУБД SAP NetWeaver, Hybris или системами SAP на основе S/4 HANA не поддерживается. Это ограничение обусловлено вопросами функциональности и производительности. Путь взаимодействия между уровнем приложений SAP и уровнем СУБД должен быть прямым. Это ограничение не относится к правилам групп безопасности приложений (ASG) и сети (NSG), если эти правила разрешают прямой путь взаимодействия.

Ниже приведены другие сценарии, в которых виртуальные сетевые модули не поддерживаются.

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

Важно!

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

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

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

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

Diagram of two VMs in two subnets

Использование Azure Load Balancer для перенаправления трафика

Для использования частных виртуальных IP-адресов, применяемых в таких методах, как SQL Server Always On или репликация системы HANA, необходимо настроить Azure Load Balancer. Подсистема балансировки нагрузки определяет активный узел с помощью проверки портов и направляет трафик только на этот активный узел базы данных.

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

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

Пример настройки внутренней подсистемы балансировки нагрузки можно найти в руководстве по настройке группы доступности SQL Server на виртуальных машинах Azure вручную.

Примечание

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

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

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

Примечание

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


Windows accelerated networking Windows

Сведения о развертывании виртуальных машин с ускоренной сетью для Windows см. в статье Создание виртуальной машины Windows с ускоренной сетью.

Linux accelerated networking Linux

Дополнительные сведения о дистрибутиве Linux см. в статье Создание виртуальной машины Linux с ускоренной сетью.


Примечание

Для SUSE, Red Hat и Oracle Linux функция ускорения сети поддерживается в новых версиях этих дистрибутивов. В более старых версиях, таких как SLES 12 с пакетом обновления 2 (SP2) или RHEL 7.2, ускоренная сеть Azure не поддерживается.

Развертывание мониторинга узлов

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

Дополнительные сведения о развертывании компонентов, передающих данные узлов в SAPOSCOL и SAP Host Agent, и об управлении жизненным циклом этих компонентов см. в руководстве по развертыванию.

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

Дополнительные сведения о конкретных СУБД см. в следующих статьях: