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

Это руководство — часть документации по внедрению и развертыванию программного обеспечения 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.

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

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

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

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

Для развертываний СУБД мы настоятельно рекомендуем использовать хранилище Azure Premium Storage (v1 и v2), Ultra Disk или общие ресурсы NFS на базе Azure NetApp Files для любых данных, файлов журналов транзакций или файлов redo. Неважно, хотите ли вы развернуть производственные или непроизводственные системы. Задержка стандартного уровня HDD или SSD в Azure неприемлема для любого типа производственной системы.

Примечание.

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

Примечание.

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

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

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

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

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

Разбиение хранилища Linux Linux

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

Для Azure Premium Storage v2 и Ultra Disk стрипинг может не быть необходим, так как вы можете задавать IOPS (операции ввода-вывода в секунду) и пропускную способность диска независимо от его размера.

Примечание.

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Для Azure Premium Storage версии 2, Ultra Disk и Azure NetApp Files параметры кэширования не предлагаются.

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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-адресов, назначьте ей несколько виртуальных сетевых адаптеров.

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

Попытка использовать виртуальные сетевые устройства в пути связи между приложением SAP и уровнями СУБД системы SAP NetWeaver, Hybris или S/4HANA не поддерживается . Это ограничение обусловлено вопросами функциональности и производительности. Путь взаимодействия между уровнем приложений 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. См. Подключение к общедоступной конечной точке для виртуальных машин с использованием стандартного балансировщика нагрузки Azure в сценариях высокой доступности SAP.

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

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

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

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

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

  • Last updated on