Высокая доступность масштабирования SAP HANA с помощью Azure NetApp Files в RHEL
В этой статье описывается настройка репликации системы SAP HANA в масштабируемом развертывании при подключении файловых систем HANA через NFS с помощью Azure NetApp Files. В примерах конфигураций и команд установки используются номера экземпляра 03 и HANA System ID HN1 . Репликация системы SAP HANA состоит из одного первичного узла и по крайней мере одного вторичного узла.
Префиксы, которыми отмечены некоторые шаги в этом документе, означают следующее.
- [A]: этот шаг применяется ко всем узлам.
- [1]: шаг применяется только к узлу 1.
- [2]: шаг применяется только к узлу 2.
Необходимые компоненты
Прежде всего прочитайте следующие примечания и документы SAP:
- Заметка SAP 1928533, которая имеет следующее:
- Список размеров виртуальных машин Azure, поддерживаемых для развертывания программного обеспечения SAP.
- важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
- Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
- сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
- примечание к SAP 2015553, в котором описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure;
- Примечания SAP 405827 перечислены рекомендуемые файловые системы для сред HANA.
- примечание к SAP 2002167, содержащее рекомендуемые параметры ОС для Red Hat Enterprise Linux;
- примечание к SAP 2009879, содержащее рекомендации по SAP HANA для Red Hat Enterprise Linux;
- Примечание SAP 3108302 содержит рекомендации ПО SAP HANA для Red Hat Enterprise Linux 9.x.
- примечание к SAP 2178632, содержащее подробные сведения обо всех доступных метриках мониторинга для SAP в Azure;
- примечание к SAP 2191498, содержащее сведения о необходимой версии агента SAP Host Agent для Linux в Azure;
- примечание к SAP 2243692, содержащее сведения о лицензировании SAP в Linux в Azure;
- примечание к SAP 1999351, в котором приведены дополнительные сведения об устранении неполадок, связанных с расширением для расширенного мониторинга Azure для SAP;
- вики-сайт сообщества SAP, где имеются все необходимые примечания к SAP для Linux;
- SAP NetWeaver на виртуальных машинах Linux. Руководство по планированию и внедрению
- Развертывание программного обеспечения SAP на виртуальных машинах Linux в Azure
- Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
- Репликация системы SAP HANA в кластере Pacemaker
- Общая документация По Red Hat Enterprise Linux (RHEL):
- Общие сведения о надстройке для обеспечения высокой доступности
- Администрирование надстройки для обеспечения высокой доступности
- Справочник по надстройке для обеспечения высокой доступности
- Настройка репликации системы SAP HANA в масштабировании в кластере Pacemaker, когда файловые системы HANA находятся в общих папках NFS
- Документация по RHEL для конкретной службы Azure:
- Политики поддержки для кластеров высокой доступности RHEL — виртуальные машины Microsoft Azure как члены кластера
- Установка и настройка кластера высокой доступности Red Hat Enterprise Linux 7.4 (и более поздних версий) в Microsoft Azure
- Настройка репликации системы sap HANA в кластере Pacemaker при использовании файловых систем HANA в общих папках NFS
- Тома NFS версии 4.1 в Azure NetApp Files для SAP HANA
Обзор
Традиционно в среде масштабирования все файловые системы sap HANA подключены из локального хранилища. Настройка высокой доступности (HA) репликации системы SAP HANA в Red Hat Enterprise Linux опубликована в разделе "Настройка репликации системы SAP HANA в RHEL".
Чтобы достичь высокого уровня доступности SAP HANA для масштабируемой системы в общих папках Azure NetApp Files NFS, нам нужна дополнительная конфигурация ресурсов в кластере, чтобы восстановить ресурсы HANA, когда один узел теряет доступ к общим папкам NFS в Azure NetApp Files. Кластер управляет подключениями NFS, позволяя отслеживать состояние работоспособности ресурсов. Зависимости между подключениями файловой системы и ресурсами SAP HANA применяются принудительно.
.
Файловые системы SAP HANA подключены к общим папкам NFS с помощью Azure NetApp Files на каждом узле. Файловые системы /hana/data
/hana/log
и /hana/shared
уникальны для каждого узла.
Подключено к node1 (hanadb1):
- 10.32.2.4:/hanadb1-data-mnt00001 в /hana/data
- 10.32.2.4:/hanadb1-log-mnt00001 в /hana/log
- 10.32.2.4:/hanadb1-shared-mnt00001 в /hana/shared
Подключено на узле 2 (hanadb2):
- 10.32.2.4:/hanadb2-data-mnt00001 в /hana/data
- 10.32.2.4:/hanadb2-log-mnt00001 в /hana/log
- 10.32.2.4:/hanadb2-shared-mnt00001 в /hana/shared
Примечание.
Файловые системы /hana/shared
/hana/data
и /hana/log
не используются между двумя узлами. Каждый узел кластера имеет собственные отдельные файловые системы.
Конфигурация репликации системы SAP HANA использует выделенное виртуальное имя узла и виртуальные IP-адреса. Load Balancer в Azure должен использовать виртуальный IP-адрес. В приведенной ниже конфигурации есть подсистема балансировки нагрузки:
- Интерфейсный IP-адрес: 10.32.0.10 для HN1-DB
- Порт пробы: 62503
Настройка инфраструктуры Azure NetApp Files
Прежде чем продолжить настройку инфраструктуры Azure NetApp Files, ознакомьтесь с документацией по Azure NetApp Files.
Служба Azure NetApp Files доступна в нескольких регионах Azure. Проверьте, предоставляется ли служба Azure NetApp Files в выбранном регионе Azure.
Сведения о доступности Azure NetApp Files в регионе Azure см. в статье о доступности Azure NetApp Files по регионам Azure.
Важные замечания
При создании томов Azure NetApp Files для систем масштабирования SAP HANA следует учитывать важные рекомендации, описанные в томах NFS версии 4.1 в Azure NetApp Files для SAP HANA.
Выбор размера базы данных HANA в Azure NetApp Files
Пропускная способность тома Azure NetApp Files зависит от размера тома и уровня обслуживания, как описано в разделе Уровни обслуживания для Azure NetApp Files.
При разработке инфраструктуры SAP HANA в Azure с помощью Azure NetApp Files помните о рекомендациях в томах NFS версии 4.1 в Azure NetApp Files для SAP HANA.
Конфигурация в этой статье представлена простыми томами Azure NetApp Files.
Внимание
Для рабочих систем, где производительность является ключом, рекомендуется оценить и рассмотреть возможность использования группы томов приложений Azure NetApp Files для SAP HANA.
Развертывание ресурсов Azure NetApp Files
В следующих инструкциях предполагается, что вы уже развернули виртуальную сеть Azure. Ресурсы Azure NetApp Files и виртуальные машины, к которым будут подключаться ресурсы Azure NetApp Files, должны быть развернуты в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure.
Создайте учетную запись NetApp в выбранном регионе Azure, следуя инструкциям в разделе Создание учетной записи NetApp.
Настройте пул емкости Azure NetApp Files, следуя инструкциям по настройке пула емкости Azure NetApp Files.
Архитектура HANA, показанная в этой статье, использует один пул емкости Azure NetApp Files на уровне службы "Ультра ". Для рабочих нагрузок HANA в Azure рекомендуется использовать уровень обслуживанияAzure NetApp Files Ультра или Премиум.
Делегируйте подсеть в Azure NetApp Files согласно инструкциям по делегированию подсети в Azure NetApp Files.
Разверните тома Azure NetApp Files, следуя инструкциям по созданию тома NFS для Azure NetApp Files.
При развертывании томов обязательно выберите версию NFSv4.1. Разверните тома в выделенной подсети Azure NetApp Files. IP-адреса томов Azure NetApp Files назначаются автоматически.
Учтите, что ресурсы Azure NetApp Files и виртуальные машины Azure должны находиться в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure. Например,
hanadb1-data-mnt00001
hanadb1-log-mnt00001
это имена томов иnfs://10.32.2.4/hanadb1-data-mnt00001
nfs://10.32.2.4/hanadb1-log-mnt00001
пути к файлам томов Azure NetApp Files.В hanadb1:
- Том hanadb1-data-mnt00001 (nfs://10.32.2.4:/hanadb1-data-mnt00001)
- Том hanadb1-log-mnt00001 (nfs://10.32.2.4:/hanadb1-log-mnt00001)
- Том hanadb1-shared-mnt00001 (nfs://10.32.2.4:/hanadb1-shared-mnt00001)
В hanadb2:
- Том hanadb2-data-mnt00001 (nfs://10.32.2.4:/hanadb2-data-mnt00001)
- Том hanadb2-log-mnt00001 (nfs://10.32.2.4:/hanadb2-log-mnt00001)
- Том hanadb2-shared-mnt00001 (nfs://10.32.2.4:/hanadb2-shared-mnt00001)
Примечание.
Все команды для подключения /hana/shared
в этой статье представлены для томов NFSv4.1 /hana/shared
.
Если вы развернули /hana/shared
тома как тома NFSv3, не забудьте настроить команды подключения для /hana/shared
NFSv3.
Подготовка инфраструктуры
Azure Marketplace содержит образы, квалифицированные для SAP HANA с надстройкой с высокой доступностью, которую можно использовать для развертывания новых виртуальных машин с помощью различных версий Red Hat.
Развертывание виртуальных машин Linux вручную с помощью портал Azure
В этом документе предполагается, что вы уже развернули группу ресурсов, виртуальную сеть Azure и подсеть.
Развертывание виртуальных машин для SAP HANA. Выберите подходящий образ RHEL, поддерживаемый для системы HANA. Виртуальную машину можно развернуть в любом из вариантов доступности: масштабируемый набор виртуальных машин, зона доступности или группу доступности.
Внимание
Убедитесь, что выбранная ОС сертифицирована для SAP HANA на определенных типах виртуальных машин, которые планируется использовать в развертывании. Вы можете искать типы виртуальных машин, сертифицированные SAP HANA, и их выпуски ОС на платформах IaaS, сертифицированных sap HANA. Убедитесь, что вы просматриваете сведения о типе виртуальной машины, чтобы получить полный список выпусков ОС, поддерживаемых SAP HANA, для конкретного типа виртуальной машины.
Настройка Azure Load Balancer
Во время настройки виртуальной машины можно создать или выбрать выход из подсистемы балансировки нагрузки в разделе сети. Выполните следующие действия, чтобы настроить стандартную подсистему балансировки нагрузки для установки высокой доступности базы данных HANA.
Выполните действия, описанные в статье "Создание подсистемы балансировки нагрузки", чтобы настроить стандартную подсистему балансировки нагрузки для системы SAP с высоким уровнем доступности с помощью портал Azure. Во время настройки подсистемы балансировки нагрузки рассмотрите следующие моменты:
- Конфигурация внешнего IP-адреса: создание внешнего IP-адреса. Выберите ту же виртуальную сеть и имя подсети, что и виртуальные машины базы данных.
- Серверный пул: создайте внутренний пул и добавьте виртуальные машины базы данных.
- Правила для входящего трафика: создание правила балансировки нагрузки. Выполните те же действия для обоих правил балансировки нагрузки.
- Внешний IP-адрес: выберите внешний IP-адрес.
- Внутренний пул: выберите внутренний пул.
- Порты высокой доступности: выберите этот параметр.
- Протокол. Выберите TCP.
- Проба работоспособности: создайте пробу работоспособности со следующими сведениями:
- Протокол. Выберите TCP.
- Порт: например, 625<экземпляра no.>.
- Интервал. Введите 5.
- Пороговое значение пробы: введите 2.
- Время ожидания простоя (минуты): введите 30.
- Включите плавающий IP-адрес: выберите этот параметр.
Примечание.
Свойство конфигурации пробы работоспособности , в противном случае известное как неработоспособное пороговое значение numberOfProbes
на портале, не учитывается. Чтобы управлять числом успешных или неудачных последовательных проб, задайте для свойства probeThreshold
значение 2
. В настоящее время невозможно задать это свойство с помощью портал Azure, поэтому используйте Azure CLI или команду PowerShell.
Дополнительные сведения о необходимых портах для SAP HANA см. в главе Подключения к базам данных клиента руководства Базы данных клиента SAP HANA или в примечании к SAP 2388694.
Примечание.
Если виртуальные машины без общедоступных IP-адресов помещаются в внутренний пул внутреннего экземпляра (без общедоступного IP-адреса) в Azure Load Balancer уровня "Стандартный", исходящие подключения к Интернету отсутствуют, если только не выполняется дополнительная настройка, чтобы разрешить маршрутизацию на общедоступные конечные точки. Дополнительные сведения о том, как достичь исходящего подключения, см. в статье "Подключение к общедоступной конечной точке" для виртуальных машин с помощью Azure Load Balancer уровня "Стандартный" в сценариях высокой доступности SAP.
Внимание
Не включайте метки времени TCP на виртуальных машинах Azure, размещенных за Azure Load Balancer. Включение меток времени TCP может привести к сбою проб работоспособности. Задайте параметру net.ipv4.tcp_timestamps значение 0. Дополнительные сведения см. в статье "Пробы работоспособности Load Balancer" и 2382421 заметки SAP.
Подключение тома Azure NetApp Files
[A] Создайте точки подключения для томов базы данных HANA.
sudo mkdir -p /hana/data sudo mkdir -p /hana/log sudo mkdir -p /hana/shared
[A] Проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, то есть defaultv4iddomain.com, и сопоставление не задано никому.
sudo cat /etc/idmapd.conf
Пример результата:
[General] Domain = defaultv4iddomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody
Внимание
Убедитесь, что домен NFS на
/etc/idmapd.conf
виртуальной машине соответствует конфигурации домена по умолчанию в Azure NetApp Files: defaultv4iddomain.com. Если существует несоответствие между конфигурацией домена на клиенте NFS (то есть виртуальной машине) и сервером NFS (то есть конфигурацией Azure NetApp Files), то разрешения для файлов на томах Azure NetApp Files, подключенных на виртуальных машинах, отображаются какnobody
.[1] Подключите тома, относящиеся к узлу 1 (hanadb1).
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-log-mnt00001 /hana/log sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb1-data-mnt00001 /hana/data
[2] Подключите тома, относящиеся к узлу, на узле 2 (hanadb2).
sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-shared-mnt00001 /hana/shared sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-log-mnt00001 /hana/log sudo mount -o rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys 10.32.2.4:/hanadb2-data-mnt00001 /hana/data
[A] Убедитесь, что все тома HANA подключены с помощью протокола NFS версии NFSv4.
sudo nfsstat -m
Убедитесь, что флаг
vers
имеет значение 4.1. Пример из hanadb1:/hana/log from 10.32.2.4:/hanadb1-log-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4 /hana/data from 10.32.2.4:/hanadb1-data-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4 /hana/shared from 10.32.2.4:/hanadb1-shared-mnt00001 Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.32.0.4,local_lock=none,addr=10.32.2.4
[A] Проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, в которой находится nfs4_disable_idmapping , выполните команду подключения. Невозможно вручную создать каталог
/sys/modules
, так как доступ зарезервирован для ядра и драйверов.Проверьте
nfs4_disable_idmapping
.sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
Если вам нужно задать следующее:
nfs4_disable_idmapping
sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
Создание постоянной конфигурации.
sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
Дополнительные сведения об изменении параметра см. в базе знаний
nfs_disable_idmapping
Red Hat.
Установка SAP HANA
[A] Настройте разрешение имен узлов для всех узлов.
Вы можете использовать DNS-сервер или изменить
/etc/hosts
файл на всех узлах. В этом примере показано, как использовать/etc/hosts
файл. Замените IP-адрес и имя узла в следующих командах:sudo vi /etc/hosts
Вставьте следующие строки в
/etc/hosts
файл. Измените IP-адрес и имя узла в соответствии с параметрами среды.10.32.0.4 hanadb1 10.32.0.5 hanadb2
[A] Подготовьте ОС для запуска SAP HANA в Azure NetApp с NFS, как описано в заметке SAP 3024346 — параметры ядра Linux для NetApp NFS. Создайте файл
/etc/sysctl.d/91-NetApp-HANA.conf
конфигурации для параметров конфигурации NetApp.sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
Добавьте следующие записи в файл конфигурации.
net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 131072 16777216 net.ipv4.tcp_wmem = 4096 16384 16777216 net.core.netdev_max_backlog = 300000 net.ipv4.tcp_slow_start_after_idle=0 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_sack = 1
[A] Создайте файл
/etc/sysctl.d/ms-az.conf
конфигурации с дополнительными параметрами оптимизации.sudo vi /etc/sysctl.d/ms-az.conf
Добавьте следующие записи в файл конфигурации.
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv4.tcp_max_syn_backlog = 16348 net.ipv4.conf.all.rp_filter = 0 sunrpc.tcp_slot_table_entries = 128 vm.swappiness=10
[A] Настройте
sunrpc
параметры, как рекомендуется в sap Note 3024346 — Параметры ядра Linux для NetApp NFS.sudo vi /etc/modprobe.d/sunrpc.conf
Вставьте следующую строку:
options sunrpc tcp_max_slot_table_entries=128
[A] Выполните конфигурацию ОС RHEL для HANA.
Настройте ОС, как описано в следующих заметках SAP на основе версии RHEL:
- 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7 (Примечание по поддержке SAP № 2292690. База данных SAP HANA: рекомендуемые параметры операционной системы для RHEL 7).
- 2777782. SAP HANA DB: рекомендуемые параметры ОС для RHEL 8;
- 2455582. Linux: запуск приложений SAP, скомпилированных с помощью GCC 6.x;
- 2593824. Linux: запуск приложений SAP, скомпилированных с помощью GCC 7.x;
- 2886607. Linux: запуск приложений SAP, скомпилированных с помощью GCC 9.x.
[A] Установите SAP HANA.
Начиная с HANA 2.0 SPS 01, по умолчанию используется MDC. При установке системы HANA SYSTEMDB и клиента с одинаковым идентификатором безопасности создаются вместе. В некоторых случаях клиент по умолчанию не требуется. Если вы не хотите создать начальный клиент вместе с установкой, вы можете следовать за заметками SAP 2629711.
Запустите программу hdblcm с DVD-диска HANA. Введите следующие значения на запрос в командной строке:
- Выберите установку: введите 1 (для установки).
- Выберите дополнительные компоненты для установки: введите 1.
- Введите путь установки [/hana/shared]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите имя локального узла [..]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию. "Do you want to add additional hosts to the system? (y/n)" (y/n) [n]: n.
- Введите идентификатор системы SAP HANA: введите HN1.
- Введите номер экземпляра [00]: введите 03.
- Выберите режим базы данных / Введите индекс [1]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Выберите системное использование и введите индекс [4]: введите 4 (для пользовательского).
- Введите расположение томов данных [/hana/data]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите расположение томов журналов [/hana/log]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Restrict maximum memory allocation? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите имя узла сертификата "..." [...]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите пароль пользователя агента узла SAP (sapadm): введите пароль пользователя агента узла.
- Подтвердите пароль пользователя агента узла SAP (sapadm): снова введите пароль пользователя агента узла, чтобы подтвердить.
- Введите пароль системного администратора (hn1adm): введите пароль системного администратора.
- Подтвердите пароль системного администратора (hn1adm): введите пароль системного администратора еще раз, чтобы подтвердить.
- Введите домашний каталог системного администратора [/usr/sap/HN1/home]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите оболочку входа системного администратора [/bin/sh]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите идентификатор пользователя системного администратора [1001]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите идентификатор группы пользователей (sapsys) [79]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Введите пароль пользователя базы данных (SYSTEM): введите пароль пользователя базы данных.
- Подтвердите пароль пользователя базы данных (SYSTEM): снова введите пароль пользователя базы данных, чтобы подтвердить.
- Restart system after machine reboot? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
- Вы действительно хотите продолжить? (y/n): проверьте сводку. Для продолжения введите y.
[A]. Обновите агент узла SAP.
Скачайте последний архив агента узла SAP на сайте центра программного обеспечения SAP и выполните следующую команду, чтобы обновить этот агент. Замените путь к архиву, чтобы он указывал на скачанный файл.
sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
[A] Настройка брандмауэра.
Создайте правило брандмауэра для порта пробы Azure Load Balancer.
sudo firewall-cmd --zone=public --add-port=62503/tcp sudo firewall-cmd --zone=public --add-port=62503/tcp –permanent
Настройка репликации системы SAP HANA
Чтобы настроить репликацию системы SAP HANA, выполните действия, приведенные в разделе Настройка репликации системы SAP HANA.
Конфигурация кластера
В этом разделе описаны шаги, необходимые для эффективной работы кластера при установке SAP HANA на общих ресурсах NFS с помощью Azure NetApp Files.
Создание кластера Pacemaker
Выполните действия, описанные в статье "Настройка Pacemaker на Red Hat Enterprise Linux в Azure", чтобы создать базовый кластер Pacemaker для этого сервера HANA.
Внимание
Благодаря системной платформе SAP Startup Framework экземпляры SAP HANA теперь могут управляться системой. Минимальная требуемая версия Red Hat Enterprise Linux (RHEL) — RHEL 8 для SAP. Как описано в примечании к SAP 3189534, все новые установки SAP HANA SPS07 версии 70 или более поздней версии или обновления систем HANA до версии HANA 2.0 SPS07 версии 70 или более поздней версии, платформа запуска SAP будет автоматически зарегистрирована в системном режиме.
При использовании решений высокого уровня доступности для управления репликацией системы SAP HANA в сочетании с экземплярами SAP HANA с поддержкой системы (см. примечание SAP 3189534), необходимо выполнить дополнительные действия, чтобы кластер высокого уровня доступности может управлять экземпляром SAP без системного вмешательства. Поэтому для системы SAP HANA, интегрированной с системой, необходимо выполнить дополнительные шаги, описанные в Red Hat KBA 7029705 на всех узлах кластера.
Внедрение перехватчика репликации системы Python для SAPHanaSR
Этот шаг является важным для оптимизации интеграции с кластером и улучшения обнаружения при необходимости отработки отказа кластера. Настоятельно рекомендуется настроить перехватчик Python SAPHanaSR. Выполните действия, описанные в разделе "Реализация перехватчика репликации системы Python SAPHanaSR".
Настройка ресурсов файловой системы
В этом примере каждый узел кластера имеет собственные файловые системы /hana/shared
/hana/data
HANA NFS и /hana/log
.
[1] Переключите кластер в режим обслуживания.
sudo pcs property set maintenance-mode=true
[1] Создайте ресурсы файловой системы для подключений hanadb1 .
sudo pcs resource create hana_data1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs sudo pcs resource create hana_log1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs sudo pcs resource create hana_shared1 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb1-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb1_nfs
[2] Создайте ресурсы файловой системы для подключений hanadb2 .
sudo pcs resource create hana_data2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-data-mnt00001 directory=/hana/data fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs sudo pcs resource create hana_log2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-log-mnt00001 directory=/hana/log fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs sudo pcs resource create hana_shared2 ocf:heartbeat:Filesystem device=10.32.2.4:/hanadb2-shared-mnt00001 directory=/hana/shared fstype=nfs options=rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys op monitor interval=20s on-fail=fence timeout=120s OCF_CHECK_LEVEL=20 --group hanadb2_nfs
Атрибут
OCF_CHECK_LEVEL=20
добавляется в операцию мониторинга, чтобы каждый монитор выполнял тест чтения и записи в файловой системе. Без этого атрибута операция монитора проверяет только подключение файловой системы. Это может быть проблема, так как при потере подключения файловая система может оставаться подключенной, несмотря на недоступность.Атрибут
on-fail=fence
также добавляется в операцию монитора. С этим параметром в случае сбоя операции монитора на узле этот узел немедленно ограждается. Без этого параметра поведение по умолчанию заключается в том, чтобы остановить все ресурсы, зависящие от неудачного ресурса, перезапустить неудачный ресурс, а затем запустить все ресурсы, зависящие от неудачного ресурса.Когда ресурс SAPHana зависит от неисправного ресурса, такое поведение не только занимает много времени, но также может привести к общему сбою. Ресурс SAPHana не может успешно остановиться, если сервер NFS, содержащий исполняемые файлы HANA, недоступен.
Предлагаемые значения времени ожидания позволяют ресурсам кластера противостоять приостановке, связанной с возобновлением аренды NFSv4.1. Дополнительные сведения см. в статье NFS в netApp Best practices. Время ожидания в предыдущей конфигурации может потребоваться адаптировать к определенной настройке SAP.
Для рабочих нагрузок, требующих более высокой пропускной способности, рекомендуется использовать
nconnect
параметр подключения, как описано в томах NFS версии 4.1 в Azure NetApp Files для SAP HANA. Проверьте, поддерживается лиnconnect
Azure NetApp Files в выпуске Linux.[1] Настройте ограничения расположения.
Настройте ограничения расположения, чтобы гарантировать, что ресурсы, управляющие уникальными подключениями hanadb1, никогда не могут выполняться в hanadb2 и наоборот.
sudo pcs constraint location hanadb1_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb2 sudo pcs constraint location hanadb2_nfs rule score=-INFINITY resource-discovery=never \#uname eq hanadb1
Параметр
resource-discovery=never
задается потому, что уникальные подключения для каждой общей папки узла имеют одну и ту же точку подключения. Например,hana_data1
использует точку подключения/hana/data
, иhana_data2
тоже использует точку подключения/hana/data
. Совместное использование той же точки подключения может привести к ложноположительным срабатыванию операции пробы, когда состояние ресурса проверяется при запуске кластера, и в свою очередь может привести к ненужному поведению восстановления. Чтобы избежать этого сценария, установите дляresource-discovery=never
этого параметра.[1] Настройка ресурсов атрибутов.
Настройте ресурсы атрибутов. Эти атрибуты имеют значение true, если подключены все подключения NFS узла (
/hana/data
,/hana/log
и/hana/data
) . В противном случае для них задано значение false.sudo pcs resource create hana_nfs1_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs1_active sudo pcs resource create hana_nfs2_active ocf:pacemaker:attribute active_value=true inactive_value=false name=hana_nfs2_active
[1] Настройте ограничения расположения.
Настройте ограничения расположения, чтобы гарантировать, что ресурс атрибута hanadb1 никогда не выполняется в hanadb2 и наоборот.
sudo pcs constraint location hana_nfs1_active avoids hanadb2 sudo pcs constraint location hana_nfs2_active avoids hanadb1
[1] Создание ограничений упорядочивания.
Настройте ограничения упорядочивания, чтобы запускать ресурсы атрибутов узла только после подключения всех подключений NFS узла.
sudo pcs constraint order hanadb1_nfs then hana_nfs1_active sudo pcs constraint order hanadb2_nfs then hana_nfs2_active
Совет
Если конфигурация включает в себя файловые системы, вне группы
hanadb1_nfs
илиhanadb2_nfs
включитеsequential=false
параметр, чтобы между файловыми системами не было упорядочения зависимостей. Все файловые системы должны начинаться раньшеhana_nfs1_active
, но они не должны запускаться в любом порядке относительно друг друга. Дополнительные сведения см. в статье Разделы справки настройка репликации системы SAP HANA в масштабируемом кластере Pacemaker при использовании файловых систем HANA в общих папках NFS
Настройка кластерных ресурсов SAP HANA
Выполните действия, описанные в разделе "Создание ресурсов кластера SAP HANA", чтобы создать ресурсы SAP HANA в кластере. После создания ресурсов SAP HANA необходимо создать ограничение правила расположения между ресурсами SAP HANA и файловыми системами (подключения NFS).
[1] Настройте ограничения между ресурсами SAP HANA и подключениями NFS.
Ограничения правил расположения задаются таким образом, чтобы ресурсы SAP HANA могли выполняться на узле, только если подключены все подключения NFS узла.
sudo pcs constraint location SAPHanaTopology_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
В RHEL 7.x:
sudo pcs constraint location SAPHana_HN1_03-master rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
В RHEL 8.x/9.x:
sudo pcs constraint location SAPHana_HN1_03-clone rule score=-INFINITY hana_nfs1_active ne true and hana_nfs2_active ne true
[1] Настройте ограничения упорядочивания, чтобы ресурсы SAP на узле остановились перед остановкой для любого из подключений NFS.
pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb1_nfs pcs constraint order stop SAPHanaTopology_HN1_03-clone then stop hanadb2_nfs
В RHEL 7.x:
pcs constraint order stop SAPHana_HN1_03-master then stop hanadb1_nfs pcs constraint order stop SAPHana_HN1_03-master then stop hanadb2_nfs
В RHEL 8.x/9.x:
pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb1_nfs pcs constraint order stop SAPHana_HN1_03-clone then stop hanadb2_nfs
Вывести кластер из режима обслуживания.
sudo pcs property set maintenance-mode=false
Проверьте состояние кластера и всех ресурсов.
Примечание.
В этой статье содержатся ссылки на термин, который корпорация Майкрософт больше не использует. Когда этот термин будет удален из программного обеспечения, мы удалим его из статьи.
sudo pcs status
Пример результата:
Online: [ hanadb1 hanadb2 ] Full list of resources: rsc_hdb_azr_agt(stonith:fence_azure_arm): Started hanadb1 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem):Started hanadb1 hana_log1 (ocf::heartbeat:Filesystem):Started hanadb1 hana_shared1 (ocf::heartbeat:Filesystem):Started hanadb1 Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem):Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Started hanadb1 hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb1 hanadb2 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb1 ] Slaves: [ hanadb2 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb1 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb1
Настройка репликации системы с поддержкой HANA в кластере Pacemaker
Начиная с SAP HANA 2.0 с пакетом обновления 01 (SPS 01), SAP поддерживает активные и чтение установки для репликации системы SAP HANA, где вторичные системы репликации системы SAP HANA можно использовать активно для рабочих нагрузок с интенсивным чтением. Для поддержки такой настройки в кластере требуется второй виртуальный IP-адрес, который позволяет клиентам получить доступ к базе данных SAP HANA с поддержкой чтения.
Чтобы обеспечить доступ к вторичному сайту репликации после перехода, кластеру необходимо переместить виртуальный IP-адрес вокруг вторичного ресурса SAPHana.
Дополнительная конфигурация, которая требуется для управления HANA активной и считываемой системной репликации в кластере Red Hat HA со вторым виртуальным IP-адресом, описана в разделе "Настройка репликации системы с поддержкой HANA Active/Read-Enabled" в кластере Pacemaker.
Прежде чем продолжить, убедитесь, что вы полностью настроили кластер Red Hat High Availability Cluster, управляя базой данных SAP HANA, как описано в предыдущих разделах документации.
Проверка настройки кластера
В этом разделе описано, как проверить настроенную систему.
Прежде чем начать тест, убедитесь, что Pacemaker не имеет никаких неудачных действий (с помощью состояния пк), нет непредвиденных ограничений расположения (например, оставшиеся части теста миграции), и что репликация системы HANA находится в состоянии синхронизации, например с
systemReplicationStatus
:sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
Проверьте конфигурацию кластера для сценария сбоя, когда узел теряет доступ к общей папке NFS (
/hana/shared
).Агенты ресурсов SAP HANA зависят от двоичных файлов, хранящихся в
/hana/shared
, для выполнения операций во время отработки отказа. В представленном сценарии файловая система/hana/shared
подключена через NFS.Сложно имитировать сбой, когда один из серверов теряет доступ к общей папке NFS. В качестве теста можно повторно подключить файловую систему как доступную только для чтения. Этот подход проверяет, что кластер может выполнить отработку отказа, если доступ
/hana/shared
к ней потерян на активном узле.Ожидаемый результат: при создании
/hana/shared
файловой системыOCF_CHECK_LEVEL
только для чтения атрибут ресурсаhana_shared1
, который выполняет операции чтения и записи в файловых системах, завершается ошибкой. Он не может писать ничего в файловой системе и выполнять отработку отказа ресурсов HANA. Такой же результат ожидается, когда узел HANA теряет доступ к общим папкам NFS.Состояние ресурсов перед запуском теста:
sudo pcs status
Пример результата:
Full list of resources: rsc_hdb_azr_agt (stonith:fence_azure_arm): Started hanadb1 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem): Started hanadb1 hana_log1 (ocf::heartbeat:Filesystem): Started hanadb1 hana_shared1 (ocf::heartbeat:Filesystem): Started hanadb1 Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Started hanadb1 hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb1 hanadb2 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb1 ] Slaves: [ hanadb2 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb1 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb1
Вы можете разместить
/hana/shared
в режиме только для чтения на активном узле кластера с помощью следующей команды:sudo mount -o ro 10.32.2.4:/hanadb1-shared-mnt00001 /hana/shared
hanadb
перезагрузится или выключится на основе действия, установленногоstonith
(pcs property show stonith-action
). После того как сервер (hanadb1
) будет отключен, ресурс HANA переходит вhanadb2
. Вы можете проверить состояние кластера.hanadb2
sudo pcs status
Пример результата:
Full list of resources: rsc_hdb_azr_agt (stonith:fence_azure_arm): Started hanadb2 Resource Group: hanadb1_nfs hana_data1 (ocf::heartbeat:Filesystem): Stopped hana_log1 (ocf::heartbeat:Filesystem): Stopped hana_shared1 (ocf::heartbeat:Filesystem): Stopped Resource Group: hanadb2_nfs hana_data2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_log2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_shared2 (ocf::heartbeat:Filesystem): Started hanadb2 hana_nfs1_active (ocf::pacemaker:attribute): Stopped hana_nfs2_active (ocf::pacemaker:attribute): Started hanadb2 Clone Set: SAPHanaTopology_HN1_03-clone [SAPHanaTopology_HN1_03] Started: [ hanadb2 ] Stopped: [ hanadb1 ] Master/Slave Set: SAPHana_HN1_03-master [SAPHana_HN1_03] Masters: [ hanadb2 ] Stopped: [ hanadb1 ] Resource Group: g_ip_HN1_03 nc_HN1_03 (ocf::heartbeat:azure-lb): Started hanadb2 vip_HN1_03 (ocf::heartbeat:IPaddr2): Started hanadb2
Мы рекомендуем тщательно протестировать конфигурацию кластера SAP HANA, выполнив также тесты, описанные в разделе "Настройка репликации системы SAP HANA в RHEL".