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

Вопросы развертывания СУБД для рабочей нагрузки 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.

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

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

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

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

Примечание.

Для развертываний СУБД настоятельно рекомендуется использовать хранилище Azure Premium (версии 1 и 2), диск Ultra или общие папки 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. При использовании нескольких дисков создайте программный страйп на дисках, содержащих файлы данных или файлы журналов и повторных операций. В таких случаях соглашения об уровне обслуживания для параметров пропускной способности IOPS и диска премиум-уровня, а также максимальное возможное IOPS стандартных дисков хранилища суммируются для итогового набора полос.

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

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

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

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

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

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

Примечание.

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

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

Учетная запись хранения Azure является и административной конструкцией, и предметом ограничений. Дополнительные сведения о возможностях и ограничениях см. в статье Целевые показатели масштабируемости и производительности службы хранилища Azure. Помните, что для стандартного хранилища существует ограничение на количество операций ввода-вывода в секунду на учетную запись. См. строку Общая частота запросов в статье Целевые показатели масштабируемости и производительности службы хранилища 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 может привести к снижению скорости операций ввода-вывода в секунду (IOPS) и пропускной способности, чем при отсутствии использования кэша чтения.

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

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

Несохраняемые диски Azure

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

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

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

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

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

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

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

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

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

Примечание.

Хранилище Azure уровня "Премиум" версий 1 и 2, диск "Ультра" и Azure NetApp Files являются рекомендуемыми типами хранилища для виртуальных машин СУБД и дисков, в которых хранятся файлы баз данных, журналы и файлы повторов. За исключением хранилища класса 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 Standard для доступа к общедоступным IP-адресам описывается в документе Подключение к общедоступной конечной точке для виртуальных машин с помощью Azure Standard Load Balancer в сценариях высокой доступности SAP.

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

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

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

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

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