Развертывание СУБД 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_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 от малого до 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).
Конфигурация может выглядеть следующим образом:
Уровень производительности и размер размещенных томов 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.
- Интегрированное решение с применением Pacemaker
- Альтернативные или дополнительные конфигурации, доступные в Microsoft Azure Поддерживается аварийное восстановление Db2 с высоким уровнем доступности (HADR) с применением 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
Если для каждого диска достаточно текущей квоты операций ввода-вывода в секунду, можно хранить все файлы базы данных на одном диске. Однако файлы данных и файлы журналов транзакций всегда должны находиться на разных дисках.
Если пропускная способность ввода-вывода в секунду или ввода-вывода одного виртуального жесткого диска Azure недостаточно, можно использовать LVM (диспетчер логических томов) или MDADM, как описано в статье "Рекомендации по развертыванию СУБД Azure Виртуальные машины для рабочей нагрузки SAP для создания одного большого логического устройства на нескольких дисках".
Для дисков, на которых хранятся данные sapdata
и каталоги saptmp
, принадлежащие Db2, в качестве размера сектора физического диска необходимо указать 512 КБ.
Другие
Все остальные общие области, такие как группы доступности Azure или мониторинг SAP, применяются для развертывания виртуальных машин с базой данных IBM. Эти общие области описаны в статьях "Рекомендации по развертыванию СУБД Azure Виртуальные машины для рабочей нагрузки SAP".
Следующие шаги
См.