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

Microsoft Azure позволяет переносить существующие приложения SAP, работающие в IBM Db2 для Linux, UNIX и Windows (LUW), на виртуальные машины Azure. Для решений SAP на базе IBM Db2 для LUW администраторы и разработчики могут по-прежнему использовать те же средства разработки и администрирования, которые доступны локально. Общую информацию о работе SAP Business Suite в IBM Db2 для LUW можно найти на сайте SAP Community Network (SCN) в SAP в IBM Db2 для Linux, UNIX и Windows.

Дополнительные сведения и обновления о SAP на Db2 для LUW в Azure см. в примечании к SAP 2233094.

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

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

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

Поддерживаемые версии IBM Db2 для Linux, UNIX и Windows

SAP в IBM Db2 для LUW поддерживается в службах виртуальных машин Microsoft Azure начиная с версии Db2 10.5.

Для получения информации о поддерживаемых продуктах SAP и типах виртуальных машин Azure обратитесь к SAP-записке 1928533.

Рекомендации по конфигурации IBM Db2 для Linux, UNIX и Windows для установки SAP на виртуальные машины Azure

Конфигурация хранилища

Общие сведения о типах хранилища Azure для рабочей нагрузки SAP см. в статье Типы хранилища Azure для рабочей нагрузки SAP. Все файлы базы данных должны храниться на подключенных дисках блочного хранилища Azure (Windows: NTFS, Linux: xfs, поддерживается с версии Db2 11.1 или ext3).

Удаленные общие тома, такие как службы Azure в перечисленных сценариях, НЕ поддерживаются для файлов базы данных Db2:

• Файловая служба Microsoft Azure для всех гостевых операционных систем.

• Azure NetApp Files для Db2, работающее в гостевой ОС Windows.

Удаленные общие тома, такие как службы Azure в перечисленных сценариях, поддерживаются для файлов базы данных Db2:

• Поддерживается размещение файлов данных и журналов Db2 на базе гостевой ОС Linux на общих ресурсах NFS, размещенных в Azure NetApp Files!

Если вы используете диски на основе хранилища BLOB-объектов Azure или менеджируемые диски, инструкции из раздела рекомендации по развертыванию СУБД для виртуальных машин Azure для рабочей нагрузки SAP применяются также к развертываниям с помощью СУБД Db2 (система управления базами данных).

Как описано ранее в общей части документа, существуют квоты на IOPS (операции ввода-вывода в секунду) для дисков Azure. Квоты зависят от типа используемой виртуальной машины. Список типов виртуальных машин с соответствующими квотами приведен здесь (Linux) и здесь (Windows).

Если для каждого диска достаточно текущей квоты IOPS, можно хранить все файлы базы данных на одном смонтированном диске. В то время как файлы данных и файлы журналов транзакций всегда следует размещать на разных дисках или виртуальных жестких дисках.

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

Кроме того, можно использовать пулы хранилища Windows, которые доступны только в Windows Server 2012 и более поздних версиях, как описано в разделе "Рекомендации по развертыванию СУБД на виртуальных машинах Azure для нагрузки SAP". В Linux можно использовать LVM или mdadm для создания одного большого логического устройства на нескольких дисках.

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

В IBM Db2 LUW 11.5 добавлена поддержка секторов размером 4 КБ. При этом для использования размера сектора 4 КБ в версии 11.5 необходимо использовать настройку конфигурации db2set DB2_4K_DEVICE_SUPPORT=ON, как описано в следующих разделах:

• Переменная, влияющая на производительность Db1 11.5
• Реестр DB2 и переменные среды

Для более старых версий Db2 необходимо использовать размер сектора 512 байтов. Премиум SSD диски являются 4-КБ собственными и имеют эмуляцию 512 байт. Диски ценовой категории "Ультра"по умолчанию используют сектор размером 4 КБ. Вы можете включить размер сектора 512 байтов во время создания диска Ultra. Дополнительные сведения см. в статье Использование дисков Azure ценовой категории "Ультра". Этот размер сектора байтов 512 является обязательным условием для версий IBM Db2 LUW ниже 11,5.

В Windows при использовании пулов хранилища для путей хранения Db2 в директориях log_dir, sapdata и saptmp необходимо указать размер физического сектора диска 512 байт. При использовании пулов носителей Windows эти пулы необходимо создать вручную через интерфейс командной строки, используя параметр -LogicalSectorSizeDefault. Дополнительные сведения см. в разделе New-StoragePool.

Рекомендации по структуре виртуальных машин и дисков для развертывания IBM DB2

IBM DB2 для приложений SAP NetWeaver поддерживается на всех типах виртуальных машин, перечисленных в примечании о поддержке SAP 1928533. Для работы с базой данных IBM DB2 рекомендуются семейства виртуальных машин Esd_v4 или Eas_v4/Es_v3, а для больших баз данных объемом несколько терабайт — семейство M/M_v2. Производительность записи на диск с журналом транзакций IBM Db2 можно улучшить, включив функцию "Ускоритель записи", реализованную в серии M.

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

Очень небольшая система SAP: размер базы данных 50–200 ГБ, например, SAP Solution Manager.

Небольшая система SAP: размер базы данных 200–750 ГБ: небольшой бизнес-пакет

Средняя система SAP: размер базы данных 500–1000 ГБ: небольшой бизнес-пакет

Большая система SAP: размер базы данных 750-2000 Гб: стандартный бизнес-пакет

Большая система SAP объемом несколько терабайт: размер базы данных более 2 ТБ: глобальная система с бизнес-пакетом

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

Использование Azure NetApp Files

Тома NFS версии 4.1 на основе Azure NetApp Files (ANF) поддерживаются при использовании IBM Db2, размещенной в гостевой ОС SUSE или Red Hat Linux. Необходимо создать не менее четырех различных томов, оформленных в виде списка:

• Общий том для saptmp1, sapmnt, usr_sap, <sid>_home, db2<sid>_home, db2_software
• Один том данных от sapdata1 до sapdatan
• Один журнальный том для каталога журнала перезаписи
• Один том для архивов журналов и резервных копий

Пятый томом может быть том ANF, который используется для более долгосрочного хранения резервных копий (например, создания моментальных снимков и их сохранения в хранилище больших двоичных объектов Azure).

Конфигурация может выглядеть следующим образом:

Уровень производительности и размер размещенных томов ANF выбираются в зависимости от требований к производительности. Однако мы рекомендуем для тома данных и журнального тома использовать уровень производительности Ultra. Не поддерживается объединение блочных и общих типов хранения для тома данных и тома журнала.

Что касается параметров монтирования, монтирование этих томов может выглядеть следующим образом (необходимо заменить <SID> и <sid> на SID вашей системы SAP):

vi /etc/idmapd.conf   
 # Example
 [General]
 Domain = defaultv4iddomain.com
 [Mapping]
 Nobody-User = nobody
 Nobody-Group = nobody

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt 
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp  /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt 
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt

mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt

Резервное копирование и восстановление

Для резервного копирования и восстановления можно использовать средства IBM Db2 для LUW. Они поддерживаются так же, как в стандартных операционных системах Windows Server и Hyper-V.

Обязательно наличие надежной стратегии резервного копирования базы данных.

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

• Чем меньше дисков используется для хранения устройств базы данных, тем меньше общая пропускная способность при чтении.
• Чем меньше потоков ЦП на виртуальной машине, тем сильнее влияние сжатия резервной копии.
• Чем меньше целевых объектов (чередующиеся каталоги, диски), на которые записываются резервные копии, тем меньше пропускная способность.

Увеличить количество целевых объектов для записи можно двумя способами. Выбор того или иного варианта (и даже их сочетания) зависит от ваших потребностей.

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

Высокий уровень доступности и аварийное восстановление

Linux Pacemaker

• SLES: обеспечение высокого уровня доступности IBM DB2 LUW на виртуальных машинах Azure в SUSE Linux Enterprise Server с использованием Pacemaker
• RHEL: обеспечение высокого уровня доступности IBM DB2 LUW на виртуальных машинах Azure с ОС Red Hat Enterprise Linux Server

Сервер кластера Windows

Отказоустойчивый кластер Windows Server (WSFC), также известный как Microsoft Cluster Server (MSCS), не поддерживается.

Поддерживается аварийное восстановление высокой доступности (HADR) Db2. Если виртуальные машины конфигурации высокого уровня доступности имеют разрешение рабочих имен, программа установки в Azure не отличается от любой настройки, выполняемой локально. Не рекомендуется полагаться только на определение IP-адресов.

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

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

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

Особенности развертываний Linux

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

Если производительности ввода-вывода в секунду или пропускной способности одного виртуального жесткого диска Azure недостаточно, можно использовать LVM (диспетчер логических томов) или MDADM, как описано в документе "Рекомендации по развертыванию СУБД на виртуальных машинах Azure для рабочих нагрузок SAP", чтобы создать одно большое логическое устройство на нескольких дисках. Для дисков, содержащих пути к хранилищу Db2 для ваших sapdata и saptmp каталогов, убедитесь, что используется размер физического сектора диска размером 4 КБ. При использовании LVM или MDADM для создания полосатого тома на нескольких дисках настройте размер полосы (или размер блока) до 512 КБ для оптимизации пропускной способности ввода-вывода для больших рабочих нагрузок базы данных.

Другие

Все остальные общие области, такие как группы доступности Azure или мониторинг SAP, применяются для развертывания виртуальных машин с базой данных IBM. Эти общие области описаны в документе «Рекомендации по развертыванию СУБД на виртуальных машинах Azure для рабочих процессов SAP».

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

Прочтите статью:

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