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

  • Статья

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

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

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

Ресурсы

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

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

Номер примечания Заголовок
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: поддерживаемые продукты и версии
2233094 DB6: приложения SAP в Azure с помощью IBM DB2 для Linux, UNIX и Windows: дополнительные сведения
2243692 Linux на виртуальной машине Microsoft Azure (IaaS): проблемы с лицензированием SAP
2578899 SUSE Linux Enterprise Server 15: примечание по установке
1984787 SUSE LINUX Enterprise Server 12: примечания к установке
2772999 Red Hat Enterprise Linux 8.x: установка и настройка
2002167 Red Hat Enterprise Linux 7.x: установка и обновление
2069760 Установка и обновление Oracle Linux 7.x SAP
1597355 Рекомендация по области буфера для Linux
2799900 Центральное техническое примечание для Базы данных Oracle 19c
2171857 Oracle Database 12c: поддержка файловой системы в Linux
1114181 Oracle Database 11g: поддержка файловой системы в Linux
2969063 Ошибка проверки микрокода в HCMT в Azure
3246210 Azure — сбой HCMT во время некоторых тестов производительности диска

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

Примечание.

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

Примечание.

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

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

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

Чередование хранилищ Windows Windows

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

Чередование хранилищ Linux Linux

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

Для хранилища Azure уровня "Премиум" версии 2 и "Ультра" полоса может не потребоваться, так как можно определить пропускную способность операций ввода-вывода в секунду и диск независимо от размера диска.

Примечание.

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

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

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

Внимание

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

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

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

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

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

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

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

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

Для хранилища класса Premium версии 1 рекомендуется использовать кэширование чтения для файлов данных базы данных SAP и выбрать кэширование для дисков файлов журнала.

Примечание.

При использовании некоторых новых типов виртуальных машин M(b)v3 использование кэшированного хранилища SSD уровня "Премиум" версии 1 может привести к снижению скорости чтения и записи операций ввода-вывода в секунду и пропускной способности, чем при использовании кэша чтения.

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

Для хранилища ценовой категории "Премиум" версии 2, диска "Ультра" и Azure NetApp Files не предлагаются параметры кэширования.

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

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

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

Непостоянный диск Windows Windows

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

Непостоянный диск Linux Linux

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

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

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

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

Примечание.

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

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

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

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

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

Кроме того, можно развернуть третью виртуальную машину в другом регионе 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), если эти правила разрешают прямой путь взаимодействия. Это также включает трафик к общим папкам NFS, в которых размещаются данные СУБД и файлы журнала повторного входа.

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

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

Внимание

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

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

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

Использование 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.

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

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

Дополнительные сведения о развертывании компонентов, которые предоставляют данные узла в агент SAPOSCOL и агенте узла SAP и управлении жизненным циклом этих компонентов, см. в статье "Реализация расширения виртуальной машины Azure для решений SAP".

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

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