Развертывание СУБД 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-байтовый размер сектора во время создания диска "Ультра". Дополнительные сведения доступны с помощью дисков Azure Ultra. Этот размер сектора в 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 для больших баз данных с несколькими ТБ. Включение акселератора записи серии M может повысить производительность записи на диске журнала транзакций IBM Db2.

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

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

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

• Общий том для saptmp1, sapmnt, usr_sap, _home, <sid>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

Поддерживается обеспечение высокой доступности и аварийного восстановления (HADR) Db2 и Pacemaker. Поддерживаются операционные системы SLES и RHEL. Такая конфигурация обеспечивает высокий уровень доступности IBM DB2 для SAP. Руководства по развертыванию:

• 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

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

Если IOPS или пропускная способность ввода-вывода одного виртуального жёсткого диска (VHD) Azure недостаточны, можно использовать LVM (менеджер логических томов) или MDADM. Эти средства позволяют создавать одно большое логическое устройство на нескольких дисках, как описано в разделе "Рекомендации по развертыванию СУБД виртуальных машин Azure" для рабочей нагрузки SAP.

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

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

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