Прочитать на английском

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


Развертывание СУБД 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 в области, описанной в настоящем документе:

Номер примечания Заголовок
1928533 Приложения SAP в Azure: поддерживаемые продукты и типы виртуальных машин Azure
2015553 SAP в Microsoft Azure: требования
1999351 Устранение неполадок, связанных с расширенным мониторингом Azure для SAP
2178632 Ключевые метрики мониторинга для SAP в Microsoft Azure
1409604 Виртуализация в Windows: расширенный мониторинг
2191498 SAP на платформе Linux в Azure: расширенный мониторинг
2233094 DB6: приложения SAP в Azure с использованием IBM DB2 для Linux, UNIX и Windows — дополнительные сведения
2243692 Linux на виртуальной машине Microsoft Azure (IaaS): проблемы с лицензированием SAP
1984787 SUSE LINUX Enterprise Server 12: примечания к установке
2002167 Red Hat Enterprise Linux 7.x: установка и обновление
1597355 Рекомендация по области буфера для Linux

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

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

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

Сведения о поддерживаемых продуктах SAP и типах виртуальных машин Azure (Виртуальные машины) см. в 1928533 заметки SAP.

Рекомендации по конфигурации 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 (система управления базами данных).

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

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

Рекомендации по повышению производительности можно также найти в руководствах по установке 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, как описано в следующих разделах:

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

В Windows с помощью пулов носителей для пути хранилища Db2 для log_dirsapdata 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 от малого до x-большого размера.

Важно!

Типы виртуальных машин, перечисленные ниже, являются примерами, которые соответствуют виртуальным ЦП и критире памяти каждой из категорий. Конфигурация хранилища основана на хранилище Azure уровня "Премиум" версии 1. Диск SSD уровня Premium версии 2 и Azure Ultra полностью поддерживается с IBM Db2 и может использоваться для развертываний. Используйте значения для емкости, скоростной пропускной способности и операций ввода-вывода в секунду, чтобы определить конфигурацию диска "Ультра" или SSD уровня "Премиум" версии 2. Число операций ввода-вывода в секунду для каталога /db2/<SID>/log_dir можно ограничить величиной примерно 5000 операций ввода/вывода. Настройте пропускную способность и операции ввода-вывода в секунду для конкретной рабочей нагрузки, если эти базовые рекомендации не соответствуют требованиям.

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

Размер виртуальной машины и примеры Точка подключения Db2 Диск Azure (цен. категория "Премиум") Число дисков ОПЕРАЦИЙ ВВОДА-ВЫВОДА Пропускная
способность [МБ/с]
Размер [ГБ] Пиковое число операций ввода-вывода в секунду Максимальная пропускная способность
при ускорении диска [ГБ]
Размер полосы Кэширование
Число виртуальных ЦП: 4 /db2 P6 1 240 50 64 3500 170
ОЗУ: ~32 ГиБ /db2/<SID>/sapdata P10 2 1,000 200 256 7000 340 256
КБ
ReadOnly
E4(d)s_v5 /db2/<SID>/saptmp P6 1 240 50 128 3500 170
E4(d)as_v5 /db2/<SID>/log_dir P6 2 480 100 128 7000 340 64
КБ
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3500 170

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

Размер виртуальной машины и примеры Точка подключения Db2 Диск Azure (цен. категория "Премиум") Число дисков ОПЕРАЦИЙ ВВОДА-ВЫВОДА Пропускная
способность [МБ/с]
Размер [ГБ] Пиковое число операций ввода-вывода в секунду Максимальная пропускная способность
при ускорении диска [ГБ]
Размер полосы Кэширование
виртуальных ЦП: 16 /db2 P6 1 240 50 64 3500 170
ОЗУ: ~128 ГиБ /db2/<SID>/sapdata P15 4 4400 500 1,024 14 000 680 256 КБ ReadOnly
E16(d)s_v5 /db2/<SID>/saptmp P6 2 480 100 128 7000 340 128 КБ
E16(d)as_v5 /db2/<SID>/log_dir P15 2 2 200 250 512 7000 340 64
КБ
... /db2/<SID>/offline_log_dir P10 1 500 100 128 3500 170

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

Размер виртуальной машины и примеры Точка подключения Db2 Диск Azure (цен. категория "Премиум") Число дисков ОПЕРАЦИЙ ВВОДА-ВЫВОДА Пропускная
способность [МБ/с]
Размер [ГБ] Пиковое число операций ввода-вывода в секунду Максимальная пропускная способность
при ускорении диска [ГБ]
Размер полосы Кэширование
Число виртуальных ЦП: 32 /db2 P6 1 240 50 64 3500 170
ОЗУ: ~256 ГиБ /db2/<SID>/sapdata P30 2 10,000 400 2,048 10,000 400 256 КБ ReadOnly
E32(d)s_v5 /db2/<SID>/saptmp P10 2 1,000 200 256 7000 340 128 КБ
E32(d)as_v5 /db2/<SID>/log_dir P20 2 4 600 300 1,024 7000 340 64
КБ
M32ls /db2/<SID>/offline_log_dir P15 1 1100 125 256 3500 170

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

Размер виртуальной машины и примеры Точка подключения Db2 Диск Azure (цен. категория "Премиум") Число дисков ОПЕРАЦИЙ ВВОДА-ВЫВОДА Пропускная
способность [МБ/с]
Размер [ГБ] Пиковое число операций ввода-вывода в секунду Максимальная пропускная способность
при ускорении диска [ГБ]
Размер полосы Кэширование
виртуальных ЦП: 64 /db2 P6 1 240 50 64 3500 170
ОЗУ: ~512 ГиБ /db2/<SID>/sapdata P30 4 20,000 800 4096 20,000 800 256 КБ ReadOnly
E64(d)s_v5 /db2/<SID>/saptmp P15 2 2 200 250 512 7000 340 128 КБ
E64(d)as_v5 /db2/<SID>/log_dir P20 4 9 200 600 2,048 14 000 680 64
КБ
M64ls /db2/<SID>/offline_log_dir P20 1 2300 150 512 3500 170

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

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

Имя/размер виртуальной машины Точка подключения Db2 Диск Azure (цен. категория "Премиум") Число дисков ОПЕРАЦИЙ ВВОДА-ВЫВОДА Пропускная
способность [МБ/с]
Размер [ГБ] Пиковое число операций ввода-вывода в секунду Максимальная пропускная способность
при ускорении диска [ГБ]
Размер полосы Кэширование
vCPU: =>128 /db2 P10 1 500 100 128 3500 170
ОЗУ: =>2048 ГиБ /db2/<SID>/sapdata P40 4 30,000 1,000 8,192 30,000 1,000 256 КБ ReadOnly
M128s_v2 /db2/<SID>/saptmp P20 2 4 600 300 1,024 7000 340 128 КБ
M176s_2_v3 /db2/<SID>/log_dir P30 4 20,000 800 4096 20,000 800 64
КБ
Write-
Accelerator
M176s_3_v3,
M176s_4_v3
/db2/<SID>/offline_log_dir P30 1 5,000 200 1,024 5,000 200

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

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

Пример конфигурации DB2 с использованием ANF

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

Что касается вариантов подключения, эти тома могут подключаться следующим образом (необходимо заменить <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

Примечание

При подключении требуется использовать опции hard и sync.

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

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

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

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

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

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

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

Примечание

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

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

Linux Pacemaker

Важно!

Для Db2 версий 11.5.6 и более поздних настоятельно рекомендуется использовать интегрированное решение с применением Pacemaker от IBM.

Сервер кластера 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 для создания одного большого логического устройства на нескольких дисках". Для дисков, на которых хранятся данные sapdata и каталоги saptmp, принадлежащие Db2, в качестве размера сектора физического диска необходимо указать 512 КБ.

Другие

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

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

См.