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


Добавление третьего сайта HSR в кластер HANA Pacemaker

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

Обзор

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

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

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

  • Multitarget реплика tes data change from primary to more one target system. Третий сайт подключен к первичной реплика в звездной топологии.
  • Multitier — это двухуровневая реплика tion. Каскадная или цепочка, настройка трех разных уровней HANA. Третий сайт подключается к вторичному.

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

Предварительные требования для SLES

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

Примечание.

Требования в этой статье допустимы только для ландшафта с поддержкой Pacemaker. Без Pacemaker требования к версии SAP HANA применяются к выбранному режиму реплика tion. Pacemaker и агент ресурсов кластера HANA управляют только двумя сайтами. Третий сайт HSR не контролируется кластером Pacemaker.

  • Масштабирование и горизонтальное масштабирование: SAP HANA SPS 04 или более поздней версии требуется для использования многотаретного HSR с кластером Pacemaker.
  • Масштабирование и горизонтальное масштабирование: не более одной системы SAP HANA реплика, подключенной из-за пределов кластера Linux.
  • Только горизонтальное масштабирование HANA: SLES 15 с пакетом обновления 1 (SP1) или более поздней версии.
  • Только горизонтальное масштабирование HANA: пакет SAPHanaSR-ScaleOut версии 0.180 или более поздней.
  • Только масштабирование HANA: sap HANA high-availability (HA) hook SAPHanaSrMultiTarget используется. Предварительная версия перехватчика SAPHanaSR высокого уровня доступности HANA не учитывается для горизонтального масштабирования.

Предварительные требования для RHEL

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

Примечание.

Требования в этой статье допустимы только для ландшафта с поддержкой Pacemaker. Без Pacemaker требования к версии SAP HANA применяются для выбранного режима реплика tion. Pacemaker и агент ресурсов кластера HANA управляют только двумя сайтами. Третий сайт HSR не контролируется кластером Pacemaker.

  • Только для масштабирования HANA: сведения о минимальной версии ОС, SAP HANA и агентах ресурсов кластера см. в политиках поддержки RedHat для кластеров RHEL.
  • Только масштабирование HANA: реплика HANA в Azure с кластером Pacemaker не поддерживается реплика.

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

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

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

В следующем примере показана система многонацелевой реплика tion. Дополнительные сведения см . в документации по SAP. Diagram that shows an example of a HANA scale-up multitarget system replication system.

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

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

    • Подсистема балансировки нагрузки не развертывается для третьего сайта. Для виртуальной машины третьего сайта нет интеграции с существующей подсистемой балансировки нагрузки кластера.
    • Не устанавливайте пакеты ОС SAPHanaSR, SAPHanaSR-doc и шаблон пакета ОС, ha_sles на виртуальной машине третьего сайта.
    • Нет интеграции с кластером для ресурсов виртуальной машины или HANA третьего сайта.
    • Установка перехватчика HANA для третьего сайта в 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 реплика tion отображает вторичный сайт и третий сайт.

    # 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. Если реплика tion на сайт аварийного восстановления не удается выполнить действие кластера.

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

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

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

В следующем примере показана система многонацелевой реплика tion. Дополнительные сведения см . в документации по SAP. Diagram that shows an example of a HANA scale-out multitarget system replication system.

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

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

    • Подсистема балансировки нагрузки не развертывается для третьего сайта. Нет интеграции с существующим подсистемой балансировки нагрузки кластера для виртуальных машин третьего сайта.
    • Не устанавливайте пакеты ОС SAPHanaSR-ScaleOut, SAPHanaSR-ScaleOut-doc и шаблон пакета ОС ha_sles на виртуальных машинах третьего сайта.
    • Виртуальная машина разработчика большинства для третьего сайта не существует, так как интеграция с кластером отсутствует.
    • Создайте том NFS /hana/shared для эксклюзивного использования третьего сайта.
    • Нет интеграции с кластером для виртуальных машин или ресурсов HANA третьего сайта.
    • Установка перехватчика HANA для третьего сайта в 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 реплика tion отображает вторичный сайт и третий сайт.

    # 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. Если реплика tion на сайт аварийного восстановления не удается выполнить действие кластера.

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

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

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

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

Diagram flow that shows how a HANA autoregistration works with a third site during a takeover.

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