Настройка Pacemaker в Red Hat Enterprise Linux в Azure
В этой статье описывается, как настроить базовый кластер Pacemaker на Red Hat Enterprise Server (RHEL). Инструкции охватывают RHEL 7, RHEL 8 и RHEL 9.
Необходимые компоненты
Прежде всего прочитайте следующие примечания и документы SAP:
- Заметка SAP 1928533, которая имеет следующее:
- Список размеров виртуальных машин Azure, поддерживаемых для развертывания программного обеспечения SAP.
- важные сведения о доступных ресурсах для каждого размера виртуальной машины Azure;
- Поддерживаемые сочетания программного обеспечения и операционной системы SAP (ОС) и базы данных.
- сведения о требуемой версии ядра SAP для Windows и Linux в Microsoft Azure.
- примечание к SAP 2015553, в котором описываются предварительные требования к SAP при развертывании программного обеспечения SAP в Azure;
- Примечания SAP 2002167 рекомендует параметры ОС для Red Hat Enterprise Linux.
- Примечания SAP 3108316 рекомендует параметры ОС для Red Hat Enterprise Linux 9.x.
- примечание к 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. Руководство по планированию и внедрению
- Развертывание виртуальных машин Azure для SAP в Linux (данная статья)
- Развертывание СУБД Виртуальных машин Azure для SAP на Linux.
- Реплика системы SAP HANA в кластере Pacemaker
- Общая документация по RHEL:
- Документация по RHEL для конкретной службы Azure:
- Политики поддержки кластеров RHEL с высоким уровнем доступности — Microsoft Azure Виртуальные машины в качестве членов кластера
- Установка и настройка кластера высокой доступности Red Hat Enterprise Linux 7.4 (и более поздних версий) в Microsoft Azure
- Рекомендации по внедрению RHEL 8 — высокий уровень доступности и кластеров
- Настройте SAP S/4HANA ASCS/ERS с помощью Standalone Enqueue Server 2 (ENSA2) в Pacemaker на RHEL 7.6
- Предложения RHEL для SAP в Azure
Установка кластера
Примечание.
Red Hat не поддерживает программное обеспечение, эмулированное сторожевой. Red Hat не поддерживает SBD на облачных платформах. Дополнительные сведения см. в разделах "Политики поддержки для кластеров с высоким уровнем доступности RHEL" — sbd и fence_sbd.
Единственным поддерживаемым механизмом ограждения кластеров Pacemaker RHEL в Azure является агент забора Azure.
Ниже описаны префиксы и их значение:
- [A]: применимо ко всем узлам;
- [1]: применимо только к узлу 1
- [2]: применимо только к узлу 2
Различия в командах или конфигурации между RHEL 7 и RHEL 8/RHEL 9 отмечены в документе.
[A]: регистрация. Этот шаг необязательный. Если вы используете образы с поддержкой высокой доступности SAP RHEL, этот шаг не требуется.
Например, если вы развертываете на RHEL 7, зарегистрируйте виртуальную машину и подключите ее к пулу, который содержит репозитории для RHEL 7.
sudo subscription-manager register # List the available pools sudo subscription-manager list --available --matches '*SAP*' sudo subscription-manager attach --pool=<pool id>
При присоединении пула к образу RHEL с оплатой по мере использования Azure Marketplace вы фактически удвоите счет за использование RHEL. Вы платите один раз за образ с оплатой по мере использования и один раз за право RHEL в присоединенном пуле. Чтобы устранить эту ситуацию, Azure теперь предоставляет образы RHEL собственной подписки. Дополнительные сведения см. в статье Образы Red Hat Enterprise Linux с использованием собственной подписки в Azure.
[A]: включение RHEL для репозиториев SAP. Этот шаг необязательный. Если вы используете образы с поддержкой высокой доступности SAP RHEL, этот шаг не требуется.
Чтобы установить необходимые пакеты на RHEL 7, включите следующие репозитории:
sudo subscription-manager repos --disable "*" sudo subscription-manager repos --enable=rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-sap-for-rhel-7-server-rpms sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-eus-rpms
[A] Установите надстройку RHEL HA.
sudo yum install -y pcs pacemaker fence-agents-azure-arm nmap-ncat
Важно!
Рекомендуется использовать следующие версии агента забора Azure (или более поздней версии), чтобы клиенты могли воспользоваться более быстрым временем отработки отказа, если остановка ресурсов завершается сбоем или узлы кластера больше не могут взаимодействовать друг с другом:
RHEL 7.7 или более поздней версии использует последнюю доступную версию пакета для агентов забора.
RHEL 7.6: fence-agents-4.2.1-11.el7_6.8
RHEL 7.5: fence-agents-4.0.11-86.el7_5.8
RHEL 7.4: fence-agents-4.0.11-66.el7_4.12
Дополнительные сведения см. в статье о том, что виртуальная машина Azure запущена в качестве члена кластера высокого уровня доступности RHEL, занимает очень много времени, чтобы быть забором, или отключение забора завершается сбоем или временем ожидания перед завершением работы виртуальной машины.
Важно!
Мы рекомендуем использовать следующие версии агента забора Azure (или более поздней версии) для клиентов, которые хотят использовать управляемые удостоверения для ресурсов Azure вместо имен субъектов-служб для агента забора:
RHEL 8.4: забор-агенты-4.2.1-54.el8.
RHEL 8.2: fence-agents-4.2.1-41.el8_2.4
RHEL 8.1: fence-agents-4.2.1-30.el8_1.4
RHEL 7.9: fence-agents-4.2.1-41.el7_9.4.
Важно!
В RHEL 9 рекомендуется использовать следующие версии пакетов (или более поздние версии), чтобы избежать проблем с агентом ограждения Azure:
забор-агенты-4.10.0-20.el9_0.7
fence-agent-common-4.10.0-20.el9_0.6
ha-cloud-support-4.10.0-20.el9_0.6.x86_64.rpm
Проверьте свою версию агента ограждения Azure. При необходимости обновите его до минимальной требуемой версии или более поздней.
# Check the version of the Azure Fence Agent sudo yum info fence-agents-azure-arm
Важно!
Если вам нужно обновить агент забора Azure, а если вы используете пользовательскую роль, обязательно обновите пользовательскую роль, чтобы включить действие powerOff. Дополнительные сведения см. в разделе "Создание настраиваемой роли для агента ограждения".
При развертывании в RHEL 9 также установите агенты ресурсов для облачного развертывания.
sudo yum install -y resource-agents-cloud
[A] Настройте разрешение имен узлов.
Вы можете использовать DNS-сервер или изменить
/etc/hosts
файл на всех узлах. В этом примере показано, как использовать файл/etc/hosts
. Замените IP-адрес и имя узла в следующих командах.Важно!
Если вы используете имена узлов в конфигурации кластера, важно иметь надежное разрешение имен узлов. Связь кластера завершается ошибкой, если имена недоступны, что может привести к задержкам отработки отказа кластера.
Преимущество использования
/etc/hosts
заключается в том, что кластер становится независимым от DNS, который также может быть одной точкой сбоев.sudo vi /etc/hosts
Вставьте следующие строки в
/etc/hosts
. Измените IP-адрес и имя узла в соответствии с параметрами среды.# IP address of the first cluster node 10.0.0.6 prod-cl1-0 # IP address of the second cluster node 10.0.0.7 prod-cl1-1
[A] Измените
hacluster
пароль на тот же пароль.sudo passwd hacluster
[A] Добавьте правила брандмауэра для Pacemaker.
Добавьте приведенные ниже правила брандмауэра для всех взаимодействий между узлами кластера.
sudo firewall-cmd --add-service=high-availability --permanent sudo firewall-cmd --add-service=high-availability
[A] Включите базовые службы кластеров.
Чтобы включить службу Pacemaker и запустить ее, выполните приведенные ниже команды.
sudo systemctl start pcsd.service sudo systemctl enable pcsd.service
[1] Создание кластера Pacemaker.
Чтобы выполнить проверку подлинности узлов и создать кластер, выполните приведенные ниже команды. Задайте для маркера значение 30000, чтобы разрешить сохранение памяти. Дополнительные сведения см. в этой статье для Linux.
Если вы создаете кластер на RHEL 7.x, используйте следующие команды:
sudo pcs cluster auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup --name nw1-azr prod-cl1-0 prod-cl1-1 --token 30000 sudo pcs cluster start --all
Если вы создаете кластер на RHEL 8.x/RHEL 9.x, используйте следующие команды:
sudo pcs host auth prod-cl1-0 prod-cl1-1 -u hacluster sudo pcs cluster setup nw1-azr prod-cl1-0 prod-cl1-1 totem token=30000 sudo pcs cluster start --all
Проверьте состояние кластера, выполнив следующую команду:
# Run the following command until the status of both nodes is online sudo pcs status # Cluster name: nw1-azr # WARNING: no stonith devices and stonith-enabled is not false # Stack: corosync # Current DC: prod-cl1-1 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum # Last updated: Fri Aug 17 09:18:24 2018 # Last change: Fri Aug 17 09:17:46 2018 by hacluster via crmd on prod-cl1-1 # # 2 nodes configured # 0 resources configured # # Online: [ prod-cl1-0 prod-cl1-1 ] # # No resources # # Daemon Status: # corosync: active/disabled # pacemaker: active/disabled # pcsd: active/enabled
[A] Задайте ожидаемые голоса.
# Check the quorum votes pcs quorum status # If the quorum votes are not set to 2, execute the next command sudo pcs quorum expected-votes 2
Совет
Если вы создаете кластер с несколькими узлами, то есть кластер с более чем двумя узлами, не устанавливайте для голосов значение 2.
[1] Разрешить одновременные действия забора.
sudo pcs property set concurrent-fencing=true
Создание устройства ограждения
Устройство ограждения использует управляемое удостоверение для ресурса Azure или субъекта-службы для авторизации в Azure.
Чтобы создать управляемое удостоверение (MSI), создайте назначаемое системой управляемое удостоверение для каждой виртуальной машины в кластере. Если управляемое удостоверение, назначаемое системой, уже существует, оно используется. Не используйте назначаемые пользователем управляемые удостоверения с Pacemaker в настоящее время. Устройство забора на основе управляемого удостоверения поддерживается в RHEL 7.9 и RHEL 8.x/RHEL 9.x.
[1] Создайте пользовательскую роль для агента ограждения.
Управляемое удостоверение и субъект-служба по умолчанию не имеют разрешений на доступ к ресурсам Azure. Необходимо предоставить управляемому удостоверению или субъекту-службе разрешения для запуска и остановки (выключения) всех виртуальных машин кластера. Если вы еще не создали пользовательскую роль, ее можно создать с помощью PowerShell или Azure CLI.
Используйте следующее содержимое для входного файла. Необходимо адаптировать содержимое к подпискам, т. е. заменить xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
и yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
идентификаторы подписки. Если у вас есть только одна подписка, удалите вторую запись AssignableScopes
.
{
"Name": "Linux Fence Agent Role",
"description": "Allows to power-off and start virtual machines",
"assignableScopes": [
"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"/subscriptions/yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
],
"actions": [
"Microsoft.Compute/*/read",
"Microsoft.Compute/virtualMachines/powerOff/action",
"Microsoft.Compute/virtualMachines/start/action"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
[А] Назначение настраиваемой роли
Используйте управляемое удостоверение или субъект-службу.
Назначьте пользовательскую роль Linux Fence Agent Role
, созданную в последнем разделе, каждому управляемому удостоверению виртуальных машин кластера. Каждое назначаемое системой управляемое удостоверение виртуальной машины требует назначения роли для каждого ресурса виртуальной машины. Дополнительные сведения см. в статье Назначение доступа на основе управляемого удостоверения для ресурса с помощью портала Azure. Убедитесь, что назначение роли управляемого удостоверения каждой виртуальной машины содержит все виртуальные машины кластера.
Важно!
Помните, что назначение и удаление авторизации с управляемыми удостоверениями может быть отложено до тех пор, пока не будет эффективным.
[1] Создание устройств ограничения
После изменения разрешений для виртуальных машин можно настроить устройства ограждения в кластере.
sudo pcs property set stonith-timeout=900
Примечание.
pcmk_host_map
Параметр требуется только в команде, если имена узлов RHEL и имена виртуальных машин Azure не совпадают. Задайте сопоставление в формате имя_узла:имя_виртуальной_машины.
См. раздел команды, выделенный полужирным шрифтом. Дополнительные сведения см. в статье о том, какой формат следует использовать для указания сопоставлений узлов с устройствами ограждения в pcmk_host_map?.
Для RHEL 7.x используйте следующую команду, чтобы настроить устройство ограждения:
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
Для RHEL 8.x/9.x используйте следующую команду, чтобы настроить устройство ограждения:
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version greater than 2.0.4-6.el8) OR (HANA scale out)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 \
op monitor interval=3600
# Run following command if you are setting up fence agent on (two-node cluster and pacemaker version less than 2.0.4-6.el8)
sudo pcs stonith create rsc_st_azure fence_azure_arm msi=true resourceGroup="resource group" \
subscriptionId="subscription id" pcmk_host_map="prod-cl1-0:prod-cl1-0-vm-name;prod-cl1-1:prod-cl1-1-vm-name" \
power_timeout=240 pcmk_reboot_timeout=900 pcmk_monitor_timeout=120 pcmk_monitor_retries=4 pcmk_action_limit=3 pcmk_delay_max=15 \
op monitor interval=3600
Если вы используете устройство ограждения на основе конфигурации субъекта-службы, прочитайте статью "Изменение имени участника-службы на MSI для кластеров Pacemaker с помощью ограждения Azure" и узнайте, как преобразовать в конфигурацию управляемого удостоверения.
Совет
- Чтобы избежать рас забора в кластере pacemaker с двумя узлами, можно настроить
priority-fencing-delay
свойство кластера. Это свойство вводит дополнительную задержку в ограждении узла, имеющего более высокий общий приоритет ресурсов при возникновении сценария разделения мозга. Дополнительные сведения см. в статье "Можно ли Pacemaker заборить узел кластера с наименьшими работающими ресурсами?". - Это свойство
priority-fencing-delay
применимо к Pacemaker версии 2.0.4-6.el8 или более поздней версии и в кластере с двумя узлами. Если вы настраиваетеpriority-fencing-delay
свойство кластера, вам не нужно задаватьpcmk_delay_max
это свойство. Но если версия Pacemaker меньше 2.0.4-6.el8, необходимо задатьpcmk_delay_max
свойство. - Инструкции по настройке
priority-fencing-delay
свойства кластера см. в соответствующих документах SAP ASCS/ERS и SAP HANA.
Операции мониторинга и ограждения десериализованы. В результате, если существует более длительное выполнение операции мониторинга и одновременное событие ограждения, задержка в отработку отказа кластера отсутствует, так как операция мониторинга уже запущена.
[1] Поддержка использования устройства ограничения
sudo pcs property set stonith-enabled=true
Совет
Агент ограждения Azure требует исходящего подключения к общедоступным конечным точкам. Дополнительные сведения и возможные решения см. в разделе "Подключение к общедоступной конечной точке" для виртуальных машин с использованием стандартной подсистемы балансировки нагрузки.
Конфигурация Pacemaker для запланированных событий Azure
Azure предлагает запланированные события. Запланированные события отправляются через службу метаданных и позволяют приложению подготовиться к таким событиям.
Агент azure-events-az
ресурсов Pacemaker отслеживает запланированные события Azure. Если обнаружены события и агент ресурсов определяет, что доступен другой узел кластера, он задает атрибут работоспособности кластера.
Если для узла задан атрибут работоспособности кластера, триггеры ограничения расположения и все ресурсы с именами, которые не начинаются health-
с узла, переносятся с узла с запланированным событием. После того как затронутый узел кластера свободен от запуска ресурсов кластера, запланированное событие будет подтверждено и может выполнить его действие, например перезапуск.
[A] Убедитесь, что пакет для
azure-events-az
агента уже установлен и обновлен.RHEL 8.x: sudo dnf info resource-agents RHEL 9.x: sudo dnf info resource-agents-cloud
Минимальные требования к версии:
- RHEL 8.4:
resource-agents-4.1.1-90.13
- RHEL 8.6:
resource-agents-4.9.0-16.9
- RHEL 8.8:
resource-agents-4.9.0-40.1
- RHEL 9.0:
resource-agents-cloud-4.10.0-9.6
- RHEL 9.2 и более поздней версии:
resource-agents-cloud-4.10.0-34.1
- RHEL 8.4:
[1] Настройте ресурсы в Pacemaker.
#Place the cluster in maintenance mode sudo pcs property set maintenance-mode=true
[1] Задайте стратегию и ограничение кластера Pacemaker health-node.
sudo pcs property set node-health-strategy=custom sudo pcs constraint location 'regexp%!health-.*' \ rule score-attribute='#health-azure' \ defined '#uname'
Важно!
Не определяйте другие ресурсы в кластере, начиная с
health-
ресурсов, описанных в следующих шагах.[1] Задайте начальное значение атрибутов кластера. Запустите для каждого узла кластера и для сред горизонтального масштабирования, включая виртуальную машину разработчика большинства.
sudo crm_attribute --node prod-cl1-0 --name '#health-azure' --update 0 sudo crm_attribute --node prod-cl1-1 --name '#health-azure' --update 0
[1] Настройте ресурсы в Pacemaker. Убедитесь, что ресурсы начинаются с
health-azure
.sudo pcs resource create health-azure-events \ ocf:heartbeat:azure-events-az op monitor interval=10s sudo pcs resource clone health-azure-events allow-unhealthy-nodes=true
Выберите кластер Pacemaker из режима обслуживания.
sudo pcs property set maintenance-mode=false
Снимите все ошибки во время включения и убедитесь, что
health-azure-events
ресурсы успешно запущены на всех узлах кластера.sudo pcs resource cleanup
Выполнение первого запроса для запланированных событий может занять до двух минут. Тестирование Pacemaker с запланированными событиями может использовать действия перезагрузки или повторного развертывания для виртуальных машин кластера. Дополнительные сведения см. в разделе Запланированные события.
Необязательная конфигурация ограничения
Совет
Этот раздел применим только в том случае, если вы хотите настроить специальное устройство fence_kdump
ограждения.
Если вам нужно собрать диагностические сведения на виртуальной машине, может потребоваться настроить другое устройство ограждения на основе агента fence_kdump
ограждения. Агент fence_kdump
может обнаружить, что узел ввел аварийное восстановление kdump и может разрешить службе аварийного восстановления завершиться до вызова других методов ограждения. Обратите внимание, что fence_kdump
это не замена традиционных механизмов ограждения, таких как агент забора Azure, когда вы используете виртуальные машины Azure.
Важно!
Помните, что при fence_kdump
настройке в качестве устройства ограждения первого уровня он вводит задержки в операциях ограждения и, соответственно, задержки в отработке отказа ресурсов приложения.
Если аварийное дампа успешно обнаружено, ограждение задерживается до завершения службы аварийного восстановления. Если неисправный узел недоступен или не отвечает, ограждение отложено по времени, настроенное число итераций и fence_kdump
время ожидания. Дополнительные сведения см. в Разделы справки настройке fence_kdump в кластере Red Hat Pacemaker?.
Предлагаемое fence_kdump
время ожидания может потребоваться адаптировать к конкретной среде.
Рекомендуется настроить fence_kdump
ограждение только при необходимости сбора диагностика в виртуальной машине и всегда в сочетании с традиционными методами ограждения, такими как агент забора Azure.
В следующих статьях Red Hat КБ содержатся важные сведения о настройке fence_kdump
ограждения:
- См. Разделы справки настройку fence_kdump в кластере Red Hat Pacemaker?.
- Узнайте , как настроить уровни ограждения и управлять ими в кластере RHEL с помощью Pacemaker.
- См. fence_kdump сбоем с "время ожидания после X секунд" в кластере RHEL 6 или 7 HA с помощью kexec-tools старше 2.0.14.
- Сведения об изменении времени ожидания по умолчанию см. в Разделы справки настройке kdump для использования с надстройкой RHEL 6, 7, 8 HA?
- Сведения об уменьшении задержки отработки отказа при использовании
fence_kdump
см. в статье "Можно ли уменьшить ожидаемую задержку отработки отказа при добавлении fence_kdump конфигурации?".
Выполните следующие необязательные действия, чтобы добавить fence_kdump
в качестве конфигурации ограждения первого уровня в дополнение к конфигурации агента ограждения Azure.
[A] Убедитесь, что
kdump
он активен и настроен.systemctl is-active kdump # Expected result # active
[A] Установите агент ограждения
fence_kdump
.yum install fence-agents-kdump
[1] Создайте
fence_kdump
устройство ограждения в кластере.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" timeout=30
[1] Настройте уровни ограждения таким образом, чтобы
fence_kdump
механизм ограждения занимался первым.pcs stonith create rsc_st_kdump fence_kdump pcmk_reboot_action="off" pcmk_host_list="prod-cl1-0 prod-cl1-1" pcs stonith level add 1 prod-cl1-0 rsc_st_kdump pcs stonith level add 1 prod-cl1-1 rsc_st_kdump pcs stonith level add 2 prod-cl1-0 rsc_st_azure pcs stonith level add 2 prod-cl1-1 rsc_st_azure # Check the fencing level configuration pcs stonith level # Example output # Target: prod-cl1-0 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure # Target: prod-cl1-1 # Level 1 - rsc_st_kdump # Level 2 - rsc_st_azure
[A] Разрешить необходимые порты через
fence_kdump
брандмауэр.firewall-cmd --add-port=7410/udp firewall-cmd --add-port=7410/udp --permanent
[A] Убедитесь, что
initramfs
файл изображения содержитfence_kdump
файлы иhosts
файлы. Дополнительные сведения см. в Разделы справки настройке fence_kdump в кластере Red Hat Pacemaker?.lsinitrd /boot/initramfs-$(uname -r)kdump.img | egrep "fence|hosts" # Example output # -rw-r--r-- 1 root root 208 Jun 7 21:42 etc/hosts # -rwxr-xr-x 1 root root 15560 Jun 17 14:59 usr/libexec/fence_kdump_send
[A] Выполните настройку
fence_kdump_nodes
/etc/kdump.conf
, чтобы избежатьfence_kdump
сбоя с истечением времени ожидания для некоторыхkexec-tools
версий. Дополнительные сведения см. в разделе fence_kdump время ожидания, если fence_kdump_nodes не указан с помощью kexec-tools версии 2.0.15 или более поздней , а fence_kdump завершается сбоем с "время ожидания после X секунд" в кластере RHEL 6 или 7 с высоким уровнем доступности с версиями kexec-tools старше 2.0.14. Здесь представлена пример конфигурации для двухузлового кластера. После внесения изменений/etc/kdump.conf
образ kdump должен быть повторно создан. Чтобы повторно создать службу, перезапуститеkdump
службу.vi /etc/kdump.conf # On node prod-cl1-0 make sure the following line is added fence_kdump_nodes prod-cl1-1 # On node prod-cl1-1 make sure the following line is added fence_kdump_nodes prod-cl1-0 # Restart the service on each node systemctl restart kdump
Проверьте конфигурацию, выполнив аварийное завершение работы узла. Дополнительные сведения см. в Разделы справки настройке fence_kdump в кластере Red Hat Pacemaker?.
Важно!
Если кластер уже работает продуктивно, запланируйте тест соответствующим образом, так как сбой узла оказывает влияние на приложение.
echo c > /proc/sysrq-trigger
Следующие шаги
- См. сведения о планировании и реализации azure Виртуальные машины для SAP.
- См. статью Развертывание программного обеспечения SAP на виртуальных машинах Azure.
- См. сведения о развертывании СУБД Azure Виртуальные машины для SAP.
- Сведения о том, как установить высокий уровень доступности и планировать аварийное восстановление SAP HANA на виртуальных машинах Azure, см. в статье о высокой доступности SAP HANA в Azure Виртуальные машины.