Добавление вторичных сайтов в кластер Pacemaker HANA

В этой статье описаны требования и настройка для настройки вторичного сайта репликации HANA для дополнения существующего кластера Pacemaker. Рассматриваются особенности SUSE Linux Enterprise Server (SLES) и RedHat Enterprise Linux (RHEL).

Обзор

SAP HANA поддерживает репликацию системы (HSR) с более чем двумя подключенными сайтами. Вы можете настроить более одного сайта в существующей паре HSR, управляемой Pacemaker в высокодоступной конфигурации. Например, можно развернуть дополнительные сайты во втором регионе Azure для целей аварийного восстановления.

Pacemaker и агент ресурсов кластера HANA управляют только первыми двумя сайтами в HSR. Кластер Pacemaker не управляет дополнительными сайтами.

SAP HANA поддерживает репликацию системы вторичных сайтов в двух режимах:

• Multitarget реплицирует изменения данных из первичной в несколько целевых систем. Дополнительные сайты подключены к первичной репликации в звездной топологии.

• Multitier — это каскадная или цепная конфигурация репликации системы HANA. Третий сайт подключается к вторичному.

Дополнительные концептуальные сведения о HANA HSR в одном регионе и разных регионах см. в статье о доступности SAP HANA в разных регионах Azure.

Необходимые условия

Требования для нескольких сайтов HSR отличаются для сценариев вертикального расширения HANA и горизонтального масштабирования HANA.

Масштабирование HANA: добавление многотаретной репликации системы HANA для целей аварийного восстановления

С помощью HANA HA хуков SAPHanaSR/susHanaSR для SLES и RHEL можно добавить дополнительные сайты в репликацию системы HANA. Среда Pacemaker осведомлена о мультитаргетной конфигурации HANA.

Сбой дополнительных сайтов не запускает никаких действий кластера. Кластер обнаруживает состояние репликации подключенных сайтов и отслеживаемый атрибут третьего сайта может изменяться между SOK и SFAIL состояниями. Любые тесты переключения на дополнительный сайт или процесса выполнения учения по аварийному восстановлению должны сначала поместить ресурсы кластера в режим обслуживания, чтобы предотвратить любое нежелательное действие кластера.

В следующем примере показана система репликации многонацелевой системы. Дополнительные сведения см. в разделе "Настройка репликации системы SAP HANA".

1. Развертывание ресурсов Azure для третьего узла. В зависимости от ваших требований, вы можете использовать другой регион Azure для целей аварийного восстановления.

   Шаги, необходимые для третьего сайта, аналогичны виртуальным машинам (VM) для масштабируемого вверх кластера HANA. Третий сайт использует инфраструктуру Azure. Версия ОС и HANA соответствуют существующему кластеру Pacemaker со следующими исключениями:

   • Подсистема балансировки нагрузки не развертывается для третьего сайта. Для виртуальной машины третьего сайта нет интеграции с существующей подсистемой балансировки нагрузки кластера.
   • Не устанавливайте пакеты ОС SAPHanaSR, SAPHanaSR-doc и шаблон пакета ОС, ha_sles на виртуальной машине третьего сайта.
   • Нет интеграции в кластер для ресурсов виртуальной машины или HANA на третьем сайте.
   • Настройка механизма HANA HA для третьего сайта в global.ini отсутствует.

2. Установите SAP HANA на третьем узле.

   Для третьего сайта необходимо использовать тот же идентификатор безопасности HANA и номер установки HANA.

3. Сначала установите и запустите SAP HANA на третьем сайте, затем зарегистрируйте третий сайт на основном сайте.

   В следующем примере SITE-DR используется в качестве имени третьего сайта.

   # Execute on the third site
   su - hn1adm
   
   # Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
   hdbnsutil -sr_register --name=SITE-DR --remoteHost=hn1-db-0 --remoteInstance=03 --replicationMode=async --online
   

4. Убедитесь, что репликация системы HANA отображает вторичный сайт и третий сайт.

   # Verify HANA HSR is in sync, execute on primary
   sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
   

5. Проверьте атрибут SAPHanaSR для третьего сайта. SITE-DR должно отображаться со статусом SOK в разделе Sites.

   # Check SAPHanaSR attribute on any cluster managed host (first or second site)
   sudo SAPHanaSR-showAttr
   # Example result
   # Global cib-time                 maintenance
   # --------------------------------------------
   # global Tue Feb 21 19:28:21 2023 false
   #
   # Sites     srHook
   # -----------------
   # HN1-SITE1 PRIM
   # HN1-SITE2 SOK
   # SITE-DR   SOK
   

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

Горизонтальное масштабирование HANA: добавление репликации многотаретной системы HANA для целей аварийного восстановления

С помощью поставщиков SAP HANA HA susHanaSR или SAPHanaSrMultiTarget можно добавить третий узел масштабирования HANA. Этот третий сайт часто используется для аварийного восстановления в другом регионе Azure. Среда Pacemaker знает о мультицелевой настройке аварийного восстановления HANA. Этот раздел применяется только к системам, работающим Pacemaker в SUSE. Дополнительные сведения см. в разделе "Предварительные требования" в этом документе.

Сбой третьего узла не запускает никаких действий кластера. Кластер обнаруживает состояние репликации подключенных сайтов и отслеживаемый атрибут третьего сайта может изменяться между SOK и SFAIL состояниями. Все тесты переключения на третий или аварийный восстановительный сайт, а также выполнение проверки процедур аварийного восстановления должны сначала поместить ресурсы кластера в режим обслуживания, чтобы предотвратить любые нежелательные действия кластера.

В следующем примере показана система репликации многонацелевой системы. Дополнительные сведения см. в разделе "Настройка репликации системы SAP HANA".

1. Развертывание ресурсов Azure для третьего сайта. В зависимости от ваших требований, вы можете использовать другой регион Azure для целей аварийного восстановления.

   Шаги, необходимые для масштабирования HANA на третьем сайте, отражают шаги по развертыванию горизонтально масштабируемого кластера HANA. Третий сайт использует шаги по установке инфраструктуры Azure, ОС и HANA для SITE1 масштабируемого кластера со следующими исключениями:

   • Подсистема балансировки нагрузки не развертывается для третьего сайта. Нет интеграции с существующим подсистемой балансировки нагрузки кластера для виртуальных машин третьего сайта.
   • Не устанавливайте пакеты ОС SAPHanaSR-ScaleOut, SAPHanaSR-ScaleOut-doc и шаблон пакета ОС ha_sles на виртуальных машинах третьего сайта.
   • Для третьего узла отсутствует виртуальная машина, реализующая большинство, поскольку нет интеграции с кластером.
   • Создайте том NFS /hana/shared для эксклюзивного использования третьего сайта.
   • Нет интеграции с кластером для виртуальных машин или ресурсов HANA третьего сайта.
   • Настройка механизма HANA HA для третьего сайта в global.ini отсутствует.

   Для третьего сайта необходимо использовать тот же идентификатор безопасности HANA и номер установки HANA.

2. При горизонтальном масштабировании SAP HANA на третьем сайте, установленном и запущенном, зарегистрируйте третий сайт с основным сайтом.

   В следующем примере SITE-DR используется в качестве имени третьего сайта.

   # Execute on the third site
   su - hn1adm
   
   # Register the HANA third site to the primary. Switch --online will shutdown the HANA instance on third site.
   hdbnsutil -sr_register --name=SITE-DR --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=async --online
   

3. Убедитесь, что репликация системы HANA отображает вторичный сайт и третий сайт.

   # Verify HANA HSR is in sync, execute on primary
   sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
   

4. Проверьте атрибут SAPHanaSR для третьего сайта. SITE-DR должно отображаться со статусом SOK в разделе Sites.

   # Check SAPHanaSR attribute on any cluster managed host (first or second site)
   sudo SAPHanaSR-showAttr
   # Expected result
   # Global cib-time                 maintenance prim  sec sync_state upd
   # ---------------------------------------------------------------------
   # HN1    Fri Jan 27 10:38:46 2023 false       HANA_S1 -   SOK        ok
   #
   # Sites     lpt        lss mns         srHook srr
   # ------------------------------------------------
   # SITE-DR                              SOK
   # HANA_S1   1674815869 4   hana-s1-db1 PRIM   P
   # HANA_S2   30         4   hana-s2-db1 SOK    S
   

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

Автоматическая регистрация третьего сайта

Во время запланированного или незапланированного события перехода между двумя сайтами кластера Pacemaker HSR на третий сайт также прерывается. Pacemaker не изменяет репликацию HANA на третий сайт.

SAP предоставляет параметр register_secondaries_on_takeover , начиная с HANA 2 SPS 04. Если для параметра задано значение true, после переключения HSR между сайтами кластера 1 и 2 HANA автоматически регистрирует третий сайт на новом первичном сервере, чтобы сохранить многоцелевую настройку HSR. Настройте параметр register_secondaries_on_takeover = true HANA в блоке [system_replication]global.ini на обоих сайтах SAP HANA в кластере Linux. И для SITE1, и для SITE2 необходим параметр в соответствующем файле конфигурации HANA global.ini. Этот параметр также можно использовать за пределами кластера Pacemaker.

Для многоуровневой системы HSR автоматическая регистрация SAP HANA для третьего сайта не предусмотрена. Чтобы сохранить цепочку репликации HSR для многоуровневого подхода, необходимо вручную зарегистрировать третий сайт на текущем вторичном сервере.

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

• Обзор аварийного восстановления и инфраструктура
• Аварийное восстановление для рабочих нагрузок SAP
• Архитектура и сценарии высокой доступности для SAP NetWeaver