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


Обеспечение высокого уровня доступности для масштабируемой системы SAP HANA с помощью HSR на основе SUSE Linux Enterprise Server

В этой статье описывается, как развернуть высокодоступную систему SAP HANA в конфигурации с горизонтальным масштабированием, используя репликацию системы HANA (HSR) и Pacemaker на виртуальных машинах Azure SUSE Linux Enterprise Server. Общие файловые системы в представленной архитектуре смонтированы с помощью NFS и предоставляются с помощью Azure NetApp Files или NFS-ресурса на Azure Files.

В примерах конфигураций, командах установки и т. д. экземпляр системы HANA имеет значение 03, а ее идентификатор — HN1.

Прежде чем начать, ознакомьтесь со следующими примечаниями и документацией по SAP.

Обзор

Одним из способов достижения высокого уровня доступности HANA для масштабируемых установок HANA является настройка репликации системы HANA и защита решения с помощью кластера Pacemaker, что обеспечивает автоматический переход на резервный узел. При сбое активного узла кластер выполняет переключение ресурсов HANA на другую площадку.
В представленной конфигурации показаны три узла HANA на каждом сайте, а также узел создания большинства для предотвращения сценария разделения вычислительных мощностей. Инструкции можно адаптировать для включения дополнительных виртуальных машин в качестве узлов базы данных HANA.

В представленной архитектуре можно развернуть общую файловую систему /hana/shared HANA с помощью Azure NetApp Files или общего ресурса NFS в файлах Azure. Каждый узел HANA в пределах одного сайта репликации HANA монтирует общую файловую систему HANA через NFS. Файловые системы /hana/data и /hana/log являются локальными файловыми системами и не разделяются между узлами HANA DB. Вы установите SAP HANA в режиме, отличном от общего доступа.

Рекомендуемые конфигурации хранилища SAP HANA приведены в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure.

Внимание

При развертывании всех файловых систем HANA в Azure NetApp Files для рабочих систем, где производительность является ключом, рекомендуется оценить и рассмотреть возможность использования группы томов приложений Azure NetApp Files для SAP HANA.

Предупреждение

Развертывание /hana/data и /hana/log на Azure Files с использованием NFS не поддерживается.

Масштабирование SAP HANA с использованием HSR и кластера Pacemaker на SLES

На предыдущей схеме, которая соответствует рекомендациям по сети для SAP HANA, в одной виртуальной сети Azure представлены три подсети:

  • client 10.23.0.0/24 — для связи с клиентами;
  • для внутренней межузловой связи HANA - inter 10.23.1.128/26
  • hsr 10.23.1.192/26 — для репликации системы HANA.

Как /hana/data и /hana/log развертываются на локальных дисках, не требуется развертывать отдельную подсеть и отдельные карты виртуальной сети для обмена данными с хранилищем.

Если вы используете Azure NetApp Files, тома NFS для /hana/shared развертываются в отдельной подсети, делегированной Azure NetApp Files: anf 10.23.1.0/26.

Подготовка инфраструктуры

В следующих инструкциях предполагается, что вы уже создали группу ресурсов и виртуальную сеть Azure с тремя подсетями: clientи interhsr.

Развертывание виртуальных машин Linux с помощью портала Azure

  1. Разверните виртуальные машины Azure.

    Для конфигурации, представленной в этом документе, разверните семь виртуальных машин:

    • три виртуальных машины для узлов базы данных HANA на сайте репликации HANA 1: hana-s1-db1, hana-s1-db2 и hana-s1-db3;
    • три виртуальных машины для узлов базы данных HANA на сайте репликации HANA 2: hana-s2-db1, hana-s2-db2 и hana-s2-db3;
    • небольшую виртуальную машину, которая будет служить как основной компонент: hana-s-mm.

Разверните виртуальные машины в качестве узлов SAP DB с использованием размеров виртуальных машин, сертифицированных для SAP HANA, как указано на сертифицированных платформах IaaS sap HANA. Убедитесь, что при развертывании узлов базы данных HANA включена ускоренная сеть .

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

Разверните локальные управляемые диски для /hana/data и /hana/log. Минимальная рекомендуемая конфигурация хранилища для /hana/data и /hana/log описана в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure.

Разверните основной сетевой интерфейс для каждой виртуальной машины в подсети client виртуальной сети.
При развертывании виртуальной машины с помощью портала Azure имя сетевого интерфейса создается автоматически. В этих инструкциях для простоты мы будем называть автоматически создаваемые основные сетевые интерфейсы, подключенные к подсети client виртуальной сети Azure, следующим образом: hana-s1-db1-client, hana-s1-db2-client, hana-s1-db3-client и т. д.

Внимание

  • Убедитесь, что выбранная операционная система была сертифицирована для использования SAP HANA на конкретных типах виртуальных машин. Список сертифицированных для SAP HANA типов виртуальных машин и выпусков ОС доступен на сайте Certified and Supported SAP HANA® Hardware (Сертифицированное и поддерживаемое оборудование SAP HANA®). Чтобы просмотреть подробные сведения о поддерживаемых SAP HANA на определенных типах виртуальных машин выпусках ОС, щелкните необходимый тип виртуальной машины.
  • Если вы решили развернуть /hana/shared на NFS на Azure Files, рекомендуется развернуть на SUSE Linux Enterprise Server (SLES) 15 SP2 и на более поздние версии.
  1. Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных HANA, в подсети inter виртуальной сети (в этом примере это hana-s1-db1-inter, hana-s1-db2-inter, hana-s1-db3-inter, hana-s2-db1-inter, hana-s2-db2-inter и hana-s2-db3-inter).

  2. Создайте шесть сетевых интерфейсов, по одному для каждой виртуальной машины базы данных HANA, в подсети hsr виртуальной сети (в этом примере это hana-s1-db1-hsr, hana-s1-db2-hsr, hana-s1-db3-hsr, hana-s2-db1-hsr, hana-s2-db2-hsr и hana-s2-db3-hsr).

  3. Подключите созданные виртуальные сетевые интерфейсы к соответствующим виртуальным машинам, выполнив следующие действия.

    1. Перейдите к виртуальной машине на портале Azure.
    2. В меню слева выберите Виртуальные машины. Выполните фильтрацию по имени виртуальной машины (например, hana-s1-db1), а затем выберите виртуальную машину.
    3. В области Обзор выберите Остановить, чтобы освободить виртуальную машину.
    4. Выберите Сеть, а затем подключите сетевой интерфейс. Из раскрывающегося списка Подключение сетевого интерфейса выберите уже созданные сетевые интерфейсы для подсетей inter и hsr.
    5. Выберите Сохранить.
    6. Повторите шаги б–е для остальных виртуальных машин (в нашем примере это hana-s1-db2, hana-s1-db3, hana-s2-db1, hana-s2-db2 и hana-s2-db3).
    7. Пока оставьте виртуальные машины в остановленном состоянии. Далее мы включим функцию ускорения сети для всех новых подключенных сетевых интерфейсов.
  4. Включите ускорение сети для дополнительных сетевых интерфейсов для подсетей inter и hsr, выполнив следующие действия.

    1. Откройте Azure Cloud Shell на портале Azure.

    2. Выполните следующие команды, чтобы включить ускоренную сеть для дополнительных сетевых интерфейсов, подключенных к подсетям inter и hsr.

      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-inter --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-inter --accelerated-networking true
      
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s1-db3-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db1-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db2-hsr --accelerated-networking true
      az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hana-s2-db3-hsr --accelerated-networking true
      

      Примечание.

      Вам не нужно устанавливать пакет Azure CLI на узлах HANA для выполнения az команды. Его можно запустить с любого компьютера с установленным интерфейсом командной строки или использовать Azure Cloud Shell.

  5. Запуск виртуальных машин базы данных HANA

Настройка Azure Load Balancer

Во время настройки виртуальной машины можно создать или выбрать выход из подсистемы балансировки нагрузки в разделе сети. Выполните следующие действия, чтобы настроить стандартную подсистему балансировки нагрузки для установки высокой доступности базы данных HANA.

Примечание.

  • Для горизонтального масштабирования HANA выберите сетевой интерфейс для client подсети при добавлении виртуальных машин в серверный пул.
  • Полный набор команд в Azure CLI и PowerShell добавляет виртуальные машины с основным сетевым интерфейсом в серверном пуле.

Выполните действия, описанные в статье "Создание подсистемы балансировки нагрузки", чтобы настроить стандартную подсистему балансировки нагрузки для системы SAP с высоким уровнем доступности с помощью портал Azure. Во время настройки подсистемы балансировки нагрузки рассмотрите следующие моменты:

  1. Конфигурация внешнего IP-адреса: создание внешнего IP-адреса. Выберите ту же виртуальную сеть и имя подсети, что и виртуальные машины базы данных.
  2. Серверный пул: создайте внутренний пул и добавьте виртуальные машины базы данных.
  3. Правила для входящего трафика: создание правила балансировки нагрузки. Выполните те же действия для обоих правил балансировки нагрузки.
    • Внешний IP-адрес: выберите внешний IP-адрес.
    • Внутренний пул: выберите внутренний пул.
    • Порты высокой доступности: выберите этот параметр.
    • Протокол. Выберите TCP.
    • Проверка работоспособности: создайте проверку работоспособности со следующими сведениями:
      • Протокол. Выберите TCP.
      • Порт: например, номер экземпляра 625<>.
      • Интервал. Введите 5.
      • Пороговое значение пробы: введите 2.
    • Время ожидания простоя (минуты): введите 30.
    • Включите плавающий IP-адрес: выберите этот параметр.

Примечание.

Свойство конфигурации пробы работоспособности, также известное как numberOfProbes на портале, не учитывается. Чтобы управлять числом успешных или неудачных последовательных проб, задайте для свойства probeThreshold значение 2. В настоящее время невозможно задать это свойство с помощью портал Azure, поэтому используйте Azure CLI или команду PowerShell.

Примечание.

Если виртуальные машины без общедоступных IP-адресов размещаются в серверном пуле внутреннего (без общедоступного IP-адреса) подсистемы балансировки нагрузки Azure уровня "Стандартный", подключение к интернету не выполняется, если только не выполняется дополнительная настройка для включения маршрутизации на общедоступные конечные точки. Дополнительные сведения о настройке исходящего подключения см. в статье "Подключение к общедоступной конечной точке для виртуальных машин" с помощью Azure Standard Load Balancer в сценариях высокой доступности SAP.

Внимание

  • Не включайте метки времени TCP на виртуальных машинах Azure, размещенных за Azure Load Balancer. Включение меток времени TCP приведёт к сбоям в проверках состояния. Установите параметр net.ipv4.tcp_timestamps на 0. Для получения дополнительных сведений см. проверки работоспособности балансировщика нагрузки и SAP-заметку 2382421.
  • Чтобы предотвратить изменение значения, установленного вручную с помощью saptune, с net.ipv4.tcp_timestamps на 0 и обратно на 1, обновите saptune до версии 3.1.1 или выше. Дополнительные сведения см. в разделе saptune 3.1.1 . Необходимо ли обновить?.

Развертывание NFS

Существует два варианта развертывания нативного NFS в Azure для /hana/shared. Вы можете развернуть том NFS на Azure NetApp Files или NFS-репозиторий на Azure Files. Файлы Azure поддерживают протокол NFSv4.1, NFS в Azure NetApp files поддерживает как NFSv4.1, так и NFSv3.

В следующих разделах описаны шаги по развертыванию NFS. Вам нужно выбрать один из вариантов.

Подсказка

Вы решили развернуть /hana/shared на общей папке NFS на Azure Files или на томе NFS на Azure NetApp Files.

Развертывание инфраструктуры Azure NetApp Files

Разверните тома Azure NetApp Files для файловой /hana/shared системы. Вам потребуется отдельный том /hana/shared для каждой площадки репликации системы HANA. Дополнительные сведения см. в разделе Настройка инфраструктуры Azure NetApp Files.

В этом примере используются следующие тома Azure NetApp Files:

  • том HN1-shared-s1 (nfs://10.23.1.7/HN1-shared-s1)
  • том HN1-shared-s2 (nfs://10.23.1.7/HN1-shared-s2).

Развертывание инфраструктуры NFS на Azure Files

Разверните ресурсы общего доступа NFS в Azure Files для файловой системы /hana/shared. Вам потребуется отдельное общее хранилище Azure Files NFS для каждого сайта репликации системы HANA. Дополнительные сведения см. в разделе Как создать общую папку NFS.

В этом примере использовались следующие разделяемые ресурсы NFS в Azure Files:

  • share hn1-shared-s1 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1)
  • share hn1-shared-s2 (sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2)

Настройка и подготовка операционной системы

Инструкции в следующих разделах начинаются с одной из следующих аббревиатур:

  • [A]: применимо ко всем узлам, включая формирователь большинства
  • [AH]: применимо ко всем узлам базы данных HANA;
  • [M]: применимо только к главному узлу мейкера
  • [AH1]: применимо ко всем узлам базы данных HANA на сайте 1;
  • [AH2]: применимо ко всем узлам базы данных HANA на сайте 2;
  • [1]: применимо только к узлу базы данных HANA 1, участок 1
  • [2]: применимо только к узлу базы данных HANA 1 на месте 2.

Настройте и подготовьте ОС, выполнив следующие действия.

  1. [A] Поддерживайте файлы хоста на виртуальных машинах. Включите в них записи для всех подсетей. Для этого примера в /etc/hosts были добавлены приведенные ниже записи.

    # Client subnet
    10.23.0.19      hana-s1-db1
    10.23.0.20      hana-s1-db2
    10.23.0.21      hana-s1-db3
    10.23.0.22      hana-s2-db1
    10.23.0.23      hana-s2-db2
    10.23.0.24      hana-s2-db3
    10.23.0.25      hana-s-mm    
    
    # Internode subnet
    10.23.1.132     hana-s1-db1-inter
    10.23.1.133     hana-s1-db2-inter
    10.23.1.134     hana-s1-db3-inter
    10.23.1.135     hana-s2-db1-inter
    10.23.1.136     hana-s2-db2-inter
    10.23.1.137     hana-s2-db3-inter
    
    # HSR subnet
    10.23.1.196     hana-s1-db1-hsr
    10.23.1.197     hana-s1-db2-hsr
    10.23.1.198     hana-s1-db3-hsr
    10.23.1.199     hana-s2-db1-hsr
    10.23.1.200     hana-s2-db2-hsr
    10.23.1.201     hana-s2-db3-hsr
    
  2. [A] Создайте файл конфигурации /etc/sysctl.d/ms-az.conf с параметрами конфигурации Microsoft для Azure.

    vi /etc/sysctl.d/ms-az.conf
    
    # Add the following entries in the configuration file
    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
    

    Подсказка

    Не следует явно задавать net.ipv4.ip_local_port_range и net.ipv4.ip_local_reserved_ports в файлах конфигурации sysctl, чтобы разрешить агенту узла SAP управлять диапазонами портов. Дополнительные сведения см. в примечании к SAP № 2382421.

  3. [AH] Подготовка виртуальных машин. Примените рекомендуемые параметры в соответствии с заметкой SAP 2205917 для SUSE Linux Enterprise Server для приложений SAP.

Подготовка файловых систем

Вы решили развернуть общие каталоги SAP в общей папке NFS в Файлах Azure или в томе NFS в Azure NetApp Files.

Подключите общие файловые системы (Azure NetApp Files NFS)

В этом примере общие файловые системы HANA развертываются в Azure NetApp Files и монтируются посредством NFSv4.1. Выполните действия, описанные в этом разделе, только если вы используете NFS в Azure NetApp Files.

  1. [AH] Подготовьте ОС для запуска SAP HANA в NetApp Systems с NFS, как описано в заметке SAP 3024346 — параметры ядра Linux для NetApp NFS. Создайте файл /etc/sysctl.d/91-NetApp-HANA.conf для параметров конфигурации NetApp.

    vi /etc/sysctl.d/91-NetApp-HANA.conf
    
    # Add the following entries in the configuration file
    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
    
  2. [AH] Настройте параметры sunrpc, как рекомендуется в примечании SAP 3024346 — параметры ядра Linux для NetApp NFS.

    vi /etc/modprobe.d/sunrpc.conf
    
    # Insert the following line
    options sunrpc tcp_max_slot_table_entries=128
    
  3. [A]: создайте точки подключения для томов базы данных HANA.

    mkdir -p /hana/shared
    
  4. [A]: проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, т. е. defaultv4iddomain.com, а для сопоставления установлено значение Никто.
    Этот шаг необходим, если используется служба Azure NetAppFiles с NFSv4.1.

    Внимание

    Обязательно укажите домен NFS в /etc/idmapd.conf виртуальной машине в соответствии с конфигурацией домена по умолчанию в Azure NetApp Files: defaultv4iddomain.com. В случае несоответствия между конфигурацией домена на клиенте NFS (т. е. виртуальной машине) и NFS-сервере (т. е. конфигурацией Azure NetApp) разрешения для файлов на томах NetApp в Azure, подключенных к виртуальным машинам, будут отображаться как nobody.

    sudo cat /etc/idmapd.conf
    # Example
    [General]
    Domain = defaultv4iddomain.com
    [Mapping]
    Nobody-User = nobody
    Nobody-Group = nobody
    
  5. [AH]: проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, где nfs4_disable_idmapping находится, выполните команду подключения. Вы не сможете вручную создать каталог в /sys/modules, так как доступ зарезервирован для ядра или драйверов.
    Этот шаг необходим, если используется служба Azure NetAppFiles с NFSv4.1.

    # Check nfs4_disable_idmapping 
    cat /sys/module/nfs/parameters/nfs4_disable_idmapping
    # If you need to set nfs4_disable_idmapping to Y
    mkdir /mnt/tmp
    mount 10.23.1.7:/HN1-share-s1 /mnt/tmp
    umount  /mnt/tmp
    echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
    # Make the configuration permanent
    echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    
  6. [AH1] Подключите общие тома Azure NetApp Files к виртуальным машинам базы данных HANA на SITE1.

    sudo vi /etc/fstab
    # Add the following entry
    10.23.1.7:/HN1-shared-s1 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    # Mount all volumes
    sudo mount -a 
    
  7. [AH2] Подключите общие тома Azure NetApp Files к виртуальным машинам HANA DB на SITE2.

    sudo vi /etc/fstab
    # Add the following entry
    10.23.1.7:/HN1-shared-s2 /hana/shared nfs rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    # Mount the volume
    sudo mount -a 
    
  8. [AH]: убедитесь, что соответствующие файловые системы /hana/shared/ подключены ко всем виртуальным машинам базы данных HANA с помощью протокола NFS версии NFS 4.1.

    sudo nfsstat -m
    # Verify that flag vers is set to 4.1 
    # Example from SITE 1, hana-s1-db1
    /hana/shared from 10.23.1.7:/HN1-shared-s1
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.1.7
    # Example from SITE 2, hana-s2-db1
    /hana/shared from 10.23.1.7:/HN1-shared-s2
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.1.7
    

Монтирование общих файловых систем (NFS в Azure Files)

В этом примере общие файловые системы HANA развертываются в NFS в Файлах Azure. Выполните действия, описанные в этом разделе, только если вы используете NFS для Azure Files.

  1. [A]: создайте точки подключения для томов базы данных HANA.

    mkdir -p /hana/shared
    
  2. [AH1] Подключите общие тома Azure NetApp Files к виртуальным машинам базы данных HANA на SITE1.

    sudo vi /etc/fstab
    # Add the following entry
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
    # Mount all volumes
    sudo mount -a 
    
  3. [AH2] Подключите общие тома Azure NetApp Files к виртуальным машинам HANA DB на SITE2.

    sudo vi /etc/fstab
    # Add the following entries
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2 /hana/shared  nfs nfsvers=4.1,sec=sys  0  0
    # Mount the volume
    sudo mount -a 
    
  4. [AH]: убедитесь, что соответствующие файловые системы /hana/shared/ подключены ко всем виртуальным машинам базы данных HANA с помощью протокола NFS версии NFS 4.1.

    sudo nfsstat -m
    # Example from SITE 1, hana-s1-db1
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s1
     Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.19,local_lock=none,addr=10.23.0.35
    # Example from SITE 2, hana-s2-db1
    sapnfsafs.file.core.windows.net:/sapnfsafs/hn1-shared-s2
     Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.23.0.22,local_lock=none,addr=10.23.0.35
    

Подготовьте данные и зарегистрируйте локальные файловые системы

В представленной конфигурации файловые системы /hana/data и /hana/log развертываются на управляемом диске и локально подключены к каждой виртуальной машине базы данных HANA. Для создания локальных данных и томов журналов на каждой виртуальной машине базы данных HANA необходимо выполнить действия.

Настройте структуру дисков с помощью диспетчера логических томов (LVM). В следующем примере предполагается, что к каждой виртуальной машине HANA подключены три диска данных, которые используются для создания двух томов.

  1. [AH]: выведите список всех доступных дисков.

    ls /dev/disk/azure/scsi1/lun*
    

    Пример результата:

    /dev/disk/azure/scsi1/lun0  /dev/disk/azure/scsi1/lun1  /dev/disk/azure/scsi1/lun2 
    
  2. [AH]: создайте физические тома для всех дисков, которые вы хотите использовать.

    sudo pvcreate /dev/disk/azure/scsi1/lun0
    sudo pvcreate /dev/disk/azure/scsi1/lun1
    sudo pvcreate /dev/disk/azure/scsi1/lun2
    
  3. [AH] Создайте группу томов для файлов данных. Используйте одну группу томов для файлов журналов и одну для общего каталога SAP HANA:\

    sudo vgcreate vg_hana_data_HN1 /dev/disk/azure/scsi1/lun0 /dev/disk/azure/scsi1/lun1
    sudo vgcreate vg_hana_log_HN1 /dev/disk/azure/scsi1/lun2
    
  4. [AH] Создайте логические тома.

    Линейный том создается при использовании lvcreate без переключателя -i. Мы рекомендуем создать чередующийся том для повышения производительности операций ввода-вывода, определяя размеры блоков чередования по значениям из статьи Конфигурации хранилища виртуальных машин SAP HANA в Azure. Аргумент -i должен обозначать число базовых физических томов, а аргумент -I — размер полосы. В этом документе используется два физических тома для тома данных, поэтому аргумент -i имеет значение 2. Размер блока чередования для тома данных составляет 256 КиБ. Для журнального тома используется один физический том, поэтому параметры -i и -I явно не используются в командах для журнального тома.

    Внимание

    Параметр -i, значение которого соответствует числу базовых физических томов, необходимо указать для всех томов данных или журналов, для которых используется более одного физического тома. Используйте параметр -I, чтобы указать размер полосы при создании тома с чередованием.
    См. конфигурации хранилища виртуальных машин SAP HANA для получения рекомендаций по конфигурациям хранилища, включая размеры полос и количество дисков.

    sudo lvcreate -i 2 -I 256 -l 100%FREE -n hana_data vg_hana_data_HN1
    sudo lvcreate -l 100%FREE -n hana_log vg_hana_log_HN1
    sudo mkfs.xfs /dev/vg_hana_data_HN1/hana_data
    sudo mkfs.xfs /dev/vg_hana_log_HN1/hana_log
    
  5. [AH] Создайте каталоги для монтирования и скопируйте идентификаторы UUID всех логических томов.

    sudo mkdir -p /hana/data/HN1
    sudo mkdir -p /hana/log/HN1
    # Write down the ID of /dev/vg_hana_data_HN1/hana_data and /dev/vg_hana_log_HN1/hana_log
    sudo blkid
    
  6. [AH] Создайте fstab записи для логических томов и монтируйте.

    sudo vi /etc/fstab
    

    Вставьте следующую строку в файл /etc/fstab:

    /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_data_HN1-hana_data /hana/data/HN1 xfs  defaults,nofail  0  2
    /dev/disk/by-uuid/UUID of /dev/mapper/vg_hana_log_HN1-hana_log /hana/log/HN1 xfs  defaults,nofail  0  2
    

    Подключите новые тома:

    sudo mount -a
    

Создание кластера Pacemaker

Следуйте указаниям из статьи Setting up Pacemaker on SUSE Linux Enterprise Server in Azure (Настройка Pacemaker на SUSE Linux Enterprise Server в Azure), чтобы создать базовый кластер Pacemaker для этого сервера HANA. Добавьте в кластер все виртуальные машины, включая машину, ответственную за формирование большинства.

Для масштабируемого кластера убедитесь, что следующие параметры заданы правильно.

  • Не устанавливайте quorum expected-votes в значение 2, так как это не кластер из двух узлов.
  • Убедитесь, что свойство concurrent-fencing=true кластера задано, чтобы ограждение узла было десериализовано.
  • Ресурс stonith-sbd должен включать параметр pcmk_action_limit=-1 со значением минус 1 (неограниченно), чтобы разрешить десериализованные действия STONITH.

Установка

В этом примере для развертывания SAP HANA в конфигурации с горизонтальным увеличением масштаба с HSR на виртуальных машинах Azure мы использовали HANA 2.0 SP5.

Подготовка к установке SAP HANA

  1. [A]: перед установкой HANA задайте корневой пароль. После завершения установки можно отключить корневой пароль. Выполните как root команду passwd.

  2. [1, 2]: измените разрешения для /hana/shared.

    chmod 775 /hana/shared
    
  3. [1]: убедитесь, что вы можете войти с помощью протокола SSH на виртуальные машины базы данных HANA hana-s1-db2 и hana-s1-db3 на этом сайте без запроса пароля. Если это не так, обмен ключами SSH, как описано в разделе "Включение доступа SSH через открытый ключ".

    ssh root@hana-s1-db2
    ssh root@hana-s1-db3
    
  4. [2]: убедитесь, что вы можете войти с помощью протокола SSH на виртуальные машины базы данных HANA hana-s2-db2 и hana-s2-db3 на этом сайте без запроса пароля.
    Если это не так, то обменяйтесь ключами SSH.

    ssh root@hana-s2-db2
    ssh root@hana-s2-db3
    
  5. [AH] Установите дополнительные пакеты, необходимые для HANA 2.0 с пакетом обновления 4 (SP4) и более поздних версий. Дополнительные сведения см. в заметке SAP 2593824 для используемой версии SLES.

    # In this example, using SLES12 SP5
    sudo zypper install libgcc_s1 libstdc++6 libatomic1
    

Установка HANA на первом узле на каждом сайте

  1. [1] Установите SAP Hana, следуя инструкциям из руководства по установке и обновлению SAP HANA 2.0. В приведенных ниже инструкциях мы опишем установку SAP HANA на первом узле сайта 1.

    a. Запустите программу hdblcm как root из каталога с установочным программным обеспечением HANA. Используйте параметр internal_network и передайте диапазон адресов подсети, используемой для обмена данными между узлами HANA.

    ./hdblcm --internal_network=10.23.1.128/26
    

    б. Когда появится приглашение, введите следующие значения:

    • По запросу Выберите действие: введите 1 (для установки).
    • На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
    • Для пути установки: нажмите клавишу ВВОД (путь по умолчанию — /hana/shared).
    • Для Local Host Name: нажмите Enter, чтобы принять значение по умолчанию.
    • На запрос Желаете добавить узлы в систему? введите n.
    • На запрос SAP HANA System ID (Идентификатор системы SAP HANA): введите HN1.
    • Введите номер экземпляра [00]: 03.
    • На запрос Local Host Worker Group [default] (Рабочая группа локального узла [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Select System Usage / Enter index [4] (Выберите использование системы / Введите индекс [4]): введите 4 (для пользовательского использования).
    • На запрос Location of Data Volumes [/hana/data/HN1] (Расположение томов данных): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • В поле Location of Log Volumes [/hana/log/HN1] (Расположение томов журналов [/hana/log/HN1]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Restrict maximum memory allocation? [n] (Ограничить максимальное выделение памяти? [n]): введите n.
    • На запрос Certificate Host Name For Host hana-s1-db1 (Имя узла сертификата для узла hana-s1-db1): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • Когда запрашивается SAP Host Agent User (sapadm) Password, введите пароль.
    • При запросе Подтвердите пароль пользователя SAP Host Agent (sapadm): введите пароль.
    • На запрос System Administrator (hn1adm) Password (Пароль системного администратора (hn1adm)): введите пароль.
    • При появлении System Administrator Home Directory [/usr/sap/HN1/home]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Оболочка входа системного администратора [/bin/sh]: нажмите клавишу Enter, чтобы принять значение по умолчанию.
    • На запрос System Administrator User ID [1001]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Enter ID of User Group (sapsys) [79] (Введите идентификатор группы пользователей (sapsys) [79]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • Для System Database User (system) Password (Пароль пользователя системной базы данных (system)): введите пароль системы.
    • На запрос Confirm System Database User (system) Password (Подтвердите пароль пользователя системной базы данных (system)): введите пароль пользователя system.
    • На запрос Restart system after machine reboot? (Перезапустить систему после перезагрузки компьютера?) [n]: введите n
    • На запрос Do you want to continue (y/n)? (Хотите продолжить (д/н)?): проверьте сводку и, если все выглядит правильно, введите д (Да).
  2. [2]: повторите предыдущий шаг, чтобы установить SAP HANA на первом узле на сайте 2.

  3. [1, 2]: проверьте файл global.ini.

    Откройте файл global.ini и убедитесь, что конфигурация внутреннего взаимодействия между узлами SAP HANA настроена. Проверьте раздел communication. В нем должен быть указан диапазон адресов для подсети inter, а параметр listeninterface должен иметь значение .internal. Проверьте раздел internal_hostname_resolution. Он должен содержать IP-адреса виртуальных машин HANA, принадлежащих к подсети inter.

      sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
      # Example from SITE1 
      [communication]
      internal_network = 10.23.1.128/26
      listeninterface = .internal
      [internal_hostname_resolution]
      10.23.1.132 = hana-s1-db1
      10.23.1.133 = hana-s1-db2
      10.23.1.134 = hana-s1-db3
    
  4. [1, 2]: подготовьте global.ini к установке в среде без общего доступа, как описано в примечании SAP 2080991.

     sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
     [persistence]
     basepath_shared = no
    
  5. [1, 2]: перезапустите SAP HANA, чтобы активировать изменения.

     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem
     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem
    
  6. [1, 2]: убедитесь, что интерфейс клиента будет использовать IP-адреса из подсети client для обмена данными.

    # Execute as hn1adm
    /usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
    # Expected result - example from SITE 2
    "hana-s2-db1","net_publicname","10.23.0.22"
    

    Сведения о том, как проверить конфигурацию, см. в примечании SAP 2183363 - Configuration of SAP HANA internal network (2183363: настройка внутренней сети SAP HANA).

  7. [AH]: измените разрешения для каталогов данных и журналов, чтобы избежать ошибок установки HANA.

     sudo chmod o+w -R /hana/data /hana/log
    
  8. [1]: установите дополнительные узлы HANA. Примеры инструкций на этом шаге приведены для сайта 1.

    a. Запустите резидентную программу hdblcm с правами пользователя root.

     cd /hana/shared/HN1/hdblcm
     ./hdblcm 
    

    б. Когда появится приглашение, введите следующие значения:

    • На запрос Choose an action (Выберите действие) введите 2 (для добавления хостов).
    • На запрос Enter comma separated host names to add (Введите имена узлов с разделителями-запятыми): введите hana-s1-db2, hana-s1-db3.
    • На запрос Additional components for installation (Выберите дополнительные компоненты для установки): введите 2, 3.
    • На запрос Enter Root User Name [root] (Введите имя пользователя root): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • Выберите роли для узла 'hana-s1-db2' [1]: введите 1 (для рабочего)
    • На запрос Enter Host Failover Group for host 'hana-s1-db2' [default] (Введите группу отработки отказа для узла hana-s1-db2 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Enter Storage Partition Number for host 'hana-s1-db2' [<<assign automatically>>] (Введите номер раздела хранилища для узла hana-s1-db2 [<<автоматическое назначение>>]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Enter Worker Group for host 'hana-s1-db2' [default] (Введите группу рабочих узлов для узла hana-s1-db2 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • Для выбора ролей для узла 'hana-s1-db3' [1]: введите 1 (для рабочего узла).
    • На запрос Enter Host Failover Group for host 'hana-s1-db3' [default] (Введите группу отработки отказа для узла hana-s1-db3 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Enter Storage Partition Number for host 'hana-s1-db3' [<<assign automatically>>] (Введите номер раздела хранилища для узла hana-s1-db3 [<<автоматическое назначение>>]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Enter Worker Group for host 'hana-s1-db3' [default] (Введите группу рабочих узлов для узла hana-s1-db3 [по умолчанию]): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос System Administrator (hn1adm) Password (Пароль системного администратора (hn1adm)): введите пароль.
    • На запрос Enter SAP Host Agent User (sapadm) Password (Введите пароль пользователя SAP Host Agent (sapadm)): введите пароль.
    • При запросе Подтвердите пароль пользователя SAP Host Agent (sapadm): введите пароль.
    • Для Certificate Host Name For Host hana-s1-db2 (Имя узла сертификата для узла hana-s1-db2): нажмите Enter, чтобы принять значение по умолчанию.
    • На запрос Certificate Host Name For Host hana-s1-db3 (Имя узла сертификата для узла hana-s1-db3): нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
    • На запрос Do you want to continue (y/n)? (Хотите продолжить (д/н)?): проверьте сводку и, если все выглядит правильно, введите д (Да).
  9. [2]: повторите предыдущий шаг, чтобы установить дополнительные узлы SAP HANA на сайте 2.

Настройка репликации системы SAP HANA 2.0

  1. [1] Настройте репликацию системы на сайте 1.

    Выполните резервное копирование баз данных от имени пользователя hn1adm.

    hdbsql -d SYSTEMDB -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupSYS')"
    hdbsql -d HN1 -u SYSTEM -p "passwd" -i 03 "BACKUP DATA USING FILE ('initialbackupHN1')"
    

    Скопируйте файлы ключей безопасного хранилища системы на дополнительный сайт:

    scp /usr/sap/HN1/SYS/global/security/rsecssfs/data/SSFS_HN1.DAT hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/data/
    scp /usr/sap/HN1/SYS/global/security/rsecssfs/key/SSFS_HN1.KEY  hana-s2-db1:/usr/sap/HN1/SYS/global/security/rsecssfs/key/
    

    Создайте основной сайт:

    hdbnsutil -sr_enable --name=HANA_S1
    
  2. [2] Настройте системную репликацию на сайте 2.

    Зарегистрируйте второй сайт, чтобы запустить репликацию системы. Выполните следующую команду от имени <hanasid>adm:

    sapcontrol -nr 03 -function StopWait 600 10
    hdbnsutil -sr_register --remoteHost=hana-s1-db1 --remoteInstance=03 --replicationMode=sync --name=HANA_S2
    sapcontrol -nr 03 -function StartSystem
    
  3. [1] Проверка состояния репликации

    Проверьте состояние репликации и подождите, пока все базы данных синхронизируются.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
    # | Database | Host          | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary     | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
    # |          |               |       |              |           |         |           | Host          | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
    # | -------- | ------------- | ----- | ------------ | --------- | ------- | --------- | ------------- | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
    # | HN1      | hana-s1-db3   | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db3   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | SYSTEMDB | hana-s1-db1   | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1   |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db1   | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1   |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db1   | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    # | HN1      | hana-s1-db2   | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db2   |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #
    # status system replication site "2": ACTIVE
    # overall system replication status: ACTIVE
    #
    # Local System Replication State
    #
    # mode: PRIMARY
    # site id: 1
    # site name: HANA_S1
    
  4. [1, 2]: измените конфигурацию HANA таким образом, чтобы данные репликации системы HANA направлялись через виртуальные сетевые интерфейсы репликации системы HANA.

    • Остановите HANA на обоих сайтах.

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
      
    • Измените файл global.ini, чтобы добавить сопоставление узла для репликации системы HANA. Используйте IP-адреса из подсети hsr.

      sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
      #Add the section
      [system_replication_hostname_resolution]
      10.23.1.196 = hana-s1-db1
      10.23.1.197 = hana-s1-db2
      10.23.1.198 = hana-s1-db3
      10.23.1.199 = hana-s2-db1
      10.23.1.200 = hana-s2-db2
      10.23.1.201 = hana-s2-db3
      
    • Запустите HANA на обоих сайтах.

      sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
      

    Дополнительные сведения см. в разделе Host Name Resolution for System Replication (Разрешение имен узлов для репликации системы).

Реализация агентов ресурсов HANA

SUSE предоставляет два различных пакета программного обеспечения для агента ресурсов Pacemaker для управления SAP HANA. Пакеты программного обеспечения SAPHanaSR-ScaleOut и SAPHanaSR-angi используют немного другой синтаксис и параметры и несовместимы. Дополнительные сведения и различия между SAPHanaSR-angi и SAPHanaSR-ScaleOut см. в заметках о выпуске SUSE и документации . В этом документе рассматриваются оба пакета на отдельных вкладках в соответствующих разделах.

Предупреждение

Не заменяйте пакет SAPHanaSR-ScaleOut на SAPHanaSR-angi в уже настроенном кластере. Для обновления с SAPHanaSR до SAPHanaSR-angi требуется определенная процедура. Дополнительные сведения см. в записи блога SUSE о том, как обновить до SAPHanaSR-angi.

  • [A] Установите пакеты высокого уровня доступности SAP HANA.

Примечание.

SAPHanaSR-angi имеет минимальные требования к версии SAP HANA 2.0 SPS 05 и SUSE SLES для приложений SAP 15 SP4 или выше.

Выполните следующую команду на всех виртуальных машинах кластера, включая создателя большинства, чтобы установить пакеты высокой доступности:

sudo zypper install SAPHanaSR-angi
sudo zypper in -t pattern ha_sles

Настройка поставщиков SAP HANA HA/DR

Поставщики SAP HANA HA/DR оптимизируют интеграцию с кластером и повышают эффективность обнаружения, когда требуется отказа кластера. Основной хук-скрипт — susHanaSR (для SAPHanaSR-angi) или SAPHanaSrMultiTarget (для пакета SAPHanaSR-ScaleOut). Для интеграции кластера необходимо настроить питоновский механизм susHanaSR/SAPHanaSrMultiTarget. Для HANA 2.0 SPS 05 и более поздних версий рекомендуется реализовать как susHanaSR/SAPHanaSrMultiTarget, так и хуки susChkSrv.

Перехватчик susChkSrv расширяет функциональные возможности основного поставщика susHanaSR/SAPHanaSrMultiTarget HA. Он действует, когда процесс HANA аварийно завершает работу hdbindexserver. Если один процесс завершается сбоем, HANA обычно пытается перезапустить его. Перезапуск процесса indexserver может занять много времени, в течение которого база данных HANA не реагирует.

При реализации susChkSrv выполняется немедленное и настраиваемое действие. Действие инициирует переход на резервную систему в течение настроенного тайм-аута вместо ожидания перезапуска процесса hdbindexserver на том же узле. В масштабируемом режиме HANA susChkSrv действует для каждого узла кластера, работающего независимо от HANA. Настроенное действие завершает работу HANA или изолирует затронутую виртуальную машину, что инициирует механизм отказоустойчивости в настроенный период ожидания.

  1. [1,2] Остановите HANA на обоих узлах репликации системы. Выполните команду от имени <sid>adm:

    sapcontrol -nr 03 -function StopSystem
    
  2. [1,2] Установите хуки провайдера высокой доступности HANA. Хуки должны быть установлены на обеих платформах баз данных HANA.

    1. [1,2] Настройте global.ini на каждом сайте кластера. Если необходимые условия для хука susChkSrv не выполнены, весь блок [ha_dr_provider_suschksrv] не должен быть настроен.
      Поведение susChkSrv можно настроить с помощью параметра action_on_lost. Допустимые значения: [ ignore | stop | kill | fence ].

      # add to global.ini on both sites. Do not copy global.ini between sites.
      [ha_dr_provider_sushanasr]
      provider = susHanaSR
      path = /usr/share/SAPHanaSR-angi
      execution_order = 1
      
      [ha_dr_provider_suschksrv]
      provider = susChkSrv
      path = /usr/share/SAPHanaSR-angi
      execution_order = 3
      action_on_lost = kill
      
      [trace]
      ha_dr_sushanasr = info
      ha_dr_suschksrv = info
      

      SUSE предоставляет HA-хуки по умолчанию в каталоге /usr/share/SAPHanaSR-angi. Использование стандартного расположения гарантирует, что обновления пакетов ОС автоматически обновляют код хука Python, а HANA использует обновленный код при следующем перезапуске. Кроме того, можно указать собственный путь, например /hana/shared/myHooks, чтобы отделить обновления ОС от используемой вами версии хука.

    2. [AH] Для кластера требуется настройка sudoers на узлах кластера для <sid>adm. В примере для этого создается новый файл. Выполните следующую команду от имени привилегированного пользователя. Замените <sid> на системный идентификатор SAP в нижнем регистре, <SID> на системный идентификатор SAP в верхнем регистре и <siteA/B> на выбранные имена сайтов HANA.

      cat << EOF > /etc/sudoers.d/20-saphana
      # SAPHanaSR-angi requirements for HA/DR hook scripts
      Cmnd_Alias SOK_SITEA    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEA  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteA> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias SOK_SITEB    = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SOK   -t crm_config -s SAPHanaSR
      Cmnd_Alias SFAIL_SITEB  = /usr/sbin/crm_attribute -n hana_<sid>_site_srHook_<siteB> -v SFAIL -t crm_config -s SAPHanaSR
      Cmnd_Alias HELPER_TAKEOVER  = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=checkTakeover
      Cmnd_Alias HELPER_FENCE     = /usr/bin/SAPHanaSR-hookHelper --sid=<SID> --case=fenceMe
      
      <sid>adm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB, HELPER_TAKEOVER, HELPER_FENCE
      

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


  1. [1, 2] Запустите SAP HANA на обоих сайтах репликации. Выполните приведенные команды с правами пользователя <sid>adm.
sapcontrol -nr 03 -function StartSystem 
  1. [1] Проверьте установку крюка. Выполните следующую команду от имени <sap-sid>adm на активном узле репликации системы HANA.
cdtrace    
grep HADR.*load.*susHanaSR nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140145]{-1}[-1/-1] 2025-05-26 07:51:34.677221 i ha_dr_provider   HADRProviderManager.cpp(00083) : loading HA/DR Provider 'susHanaSR' from /usr/share/SAPHanaSR-angi
grep susHanaSR.*init nameserver_*.trc | tail -3
# Example output
# nameserver_hana-s1-db1.30301.453.trc:[140157]{-1}[-1/-1] 2025-05-26 07:51:34.724422 i ha_dr_susHanaSR  susHanaSR.py(00042) : susHanaSR.init() version 1.001.1
  1. [AH] Проверьте установку хука susChkSrv. Запустите следующую команду от имени <sap-sid>adm на любом узле HANA.
cdtrace
egrep '(LOST:|STOP:|START:|DOWN:|init|load|fail)' nameserver_suschksrv.trc
# Example output
# 2023-01-19 08:23:10.581529  [1674116590-10005] susChkSrv.init() version 0.7.7, parameter info: action_on_lost=fence stop_timeout=20 kill_signal=9
# 2023-01-19 08:23:31.553566  [1674116611-14022] START: indexserver event looks like graceful tenant start
# 2023-01-19 08:23:52.834813  [1674116632-15235] START: indexserver event looks like graceful tenant start (indexserver started)

Создание ресурсов кластера SAP HANA

  1. [1] Создайте ресурс топологии HANA. Убедитесь, что кластер находится в режиме обслуживания.
sudo crm configure property maintenance-mode=true

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaTopology_<SID>_HDB<InstNum> ocf:suse:SAPHanaTopology \
  op monitor interval="50" timeout="600" \
  op start interval="0" timeout="600" \
  op stop interval="0" timeout="300" \
  params SID="<SID>" InstanceNumber="<InstNum>"

sudo crm configure clone cln_SAPHanaTopology_<SID>_HDB<InstNum> rsc_SAPHanaTopology_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true"
  1. [1] Далее создайте ресурс экземпляра HANA.
# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaController_<SID>_HDB<InstNum> ocf:suse:SAPHanaController \
  op start interval="0" timeout="3600" \
  op stop interval="0" timeout="3600" \
  op promote interval="0" timeout="900" \
  op demote interval="0" timeout="320" \
  op monitor interval="60" role="Promoted" timeout="700" \
  op monitor interval="61" role="Unpromoted" timeout="700" \
  params SID="<SID>" InstanceNumber="<InstNum>" PREFER_SITE_TAKEOVER="true" \
  DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="false" \
  HANA_CALL_TIMEOUT="120"

sudo crm configure clone mst_SAPHanaController_<SID>_HDB<InstNum> rsc_SAPHanaController_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true" promotable="true"

Внимание

Рекомендуется в качестве лучшей практики устанавливать для параметра AUTOMATED_REGISTER значение no только при выполнении тщательных тестов отказоустойчивости, чтобы предотвратить автоматическую регистрацию отказавшего основного экземпляра в качестве вторичного. После успешного завершения тестов отработки отказа установите значение AUTOMATED_REGISTER на да, чтобы репликация системы могла возобновиться автоматически после захвата.

  1. [1] Создание агентов ресурсов файловой системы для /hana/shared

SAPHanaSR-angi добавляет новый агент управления ресурсами SAPHanaFilesystem для мониторинга доступа на чтение и запись к /hana/shared/SID. ОС статически монтирует файловую систему /hana/shared/SID, причем у каждого узла есть записи в /etc/fstab. SAPHanaFilesystem и Pacemaker не подключают файловую систему для HANA.

# Replace <placeholders> with your instance number and HANA system ID

sudo crm configure primitive rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> ocf:suse:SAPHanaFilesystem \
  op start interval="0" timeout="10" \
  op stop interval="0" timeout="20" \
  op monitor interval="120" timeout="120" \
  params SID="<SID>" InstanceNumber="<InstNum>" ON_FAIL_ACTION="fence"

sudo crm configure clone cln_SAPHanaFilesystem_<SID>_HDB<InstNum> rsc_SAPHanaFilesystem_<SID>_HDB<InstNum> \
  meta clone-node-max="1" interleave="true"

# Add a location constraint to not run filesystem check on majority maker VM
sudo crm configure location loc_SAPHanaFilesystem_not_on_majority_maker cln_SAPHanaFilesystem_<SID>_HDB<InstNum> -inf: hana-s-mm
  1. [1] Продолжайте использовать ресурсы кластера для виртуальных IP-адресов и ограничений.
# Replace <placeholders> with your instance number and HANA system ID, and respective IP address and load balancer port  

sudo crm configure primitive rsc_ip_<SID>_HDB<InstNum> ocf:heartbeat:IPaddr2 \
  op start timeout=60s on-fail=fence \
  op monitor interval="10s" timeout="20s" \
  params ip="10.23.0.27"
  
sudo crm configure primitive rsc_nc_<SID>_HDB<InstNum> azure-lb port=62503 \
  op monitor timeout=20s interval=10 \
  meta resource-stickiness=0
  
sudo crm configure group g_ip_<SID>_HDB<InstNum> rsc_ip_<SID>_HDB<InstNum> rsc_nc_<SID>_HDB<InstNum>

Создание ограничений кластера

# Colocate the IP with primary HANA node
sudo crm configure colocation col_saphana_ip_<SID>_HDB<InstNum> 4000: g_ip_<SID>_HDB<InstNum>:Started \
  mst_SAPHanaController_<SID>_HDB<InstNum>:Promoted  
  
# Start HANA Topology before HANA  instance
sudo crm configure order ord_SAPHana_<SID>_HDB<InstNum> Optional: cln_SAPHanaTopology_<SID>_HDB<InstNum> \
  mst_SAPHanaController_<SID>_HDB<InstNum>
  
# HANA resources don't run on the majority maker node
sudo crm configure location loc_SAPHanaController_not_on_majority_maker mst_SAPHanaController_<SID>_HDB<InstNum> -inf: hana-s-mm
sudo crm configure location loc_SAPHanaTopology_not_on_majority_maker cln_SAPHanaTopology_<SID>_HDB<InstNum> -inf: hana-s-mm
  1. [1] Настройте дополнительные свойства кластера.
sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=50
  1. [1]: выведите кластер из режима обслуживания. Убедитесь, что статус состояния кластера в норме и что все ресурсы запущены.
# Cleanup any failed resources - the following command is example 
sudo crm resource cleanup rsc_SAPHana_HN1_HDB03

# Place the cluster out of maintenance mode
sudo crm configure property maintenance-mode=false
  1. [1] Проверьте связь между хуком высокой доступности HANA и кластером, показывая состояние SOK для SID и обоих сайтов репликации с состоянием P(ервичный) или S(вторичный).
sudo SAPHanaSR-showAttr
Global cib-update dcid prim       sec        sid topology
----------------------------------------------------------
global 0.165361.0 7    HANA_S2 HANA_S1    HN1 ScaleOut

Resource                        promotable
-------------------------------------------
msl_SAPHanaController_HN1_HDB03 true
cln_SAPHanaTopology_HN1_HDB03

Site        lpt        lss mns     opMode    srHook srMode srPoll srr
----------------------------------------------------------------------
HANA_S2  1748611494 4   hana-s2-db1 logreplay PRIM   sync   PRIM   P
HANA_S1  10         4   hana-s1-db1 logreplay SOK    sync   SFAIL  S

Host     clone_state roles                        score  site       srah version     vhost
----------------------------------------------------------------------------------------------
hana-s1-db1  DEMOTED     master1:master:worker:master 100    HANA_S1 -    2.00.074.00 hana-s1-db1
hana-s1-db2  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db2
hana-s1-db3  DEMOTED     slave:slave:worker:slave     -12200 HANA_S1 -    2.00.074.00 hana-s1-db3
hana-s2-db1  PROMOTED    master1:master:worker:master 150    HANA_S2 -    2.00.074.00 hana-s2-db1
hana-s2-db2  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db2
hana-s2-db3  DEMOTED     slave:slave:worker:slave     -10000 HANA_S2 -    2.00.074.00 hana-s2-db3
hana-mm                                                                               hana-mm

Примечание.

Время ожидания в приведенной выше конфигурации указано только для примера. Его нужно настроить для конкретной установки HANA. Например, время ожидания при запуске лучше увеличить, если запуск базы данных SAP HANA выполняется долго. SAPHanaSR-angi позволяет использовать дополнительные параметры для более быстрого действия во время события кластера. Для получения подробной информации о параметре ON_FAIL_ACTION SAPHanaController, необязательном агенте SAPHanaSR-alert-fencing и других параметрах обратитесь к документации по SUSE. За реализацией следует выполнить дополнительное расширенное тестирование кластера в вашей среде.

Тест отказоустойчивости SAP HANA

Примечание.

В этой статье содержатся ссылки на термины, которые корпорация Майкрософт больше не использует. Когда эти термины будут удалены из программных продуктов, мы удалим их и из этой статьи.

  1. Перед началом теста проверьте состояние репликации кластера и системы SAP HANA.

    a. Убедитесь, что нет неудачных действий кластера.

    #Verify that there are no failed cluster actions
    crm status
    # Example 
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Full list of resources:
    #
    # stonith-sbd    (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s1-db1 ]
    #     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #     Stopped: [ hana-s-mm ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s1-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s1-db1
    

    б. Проверьте, синхронизируется ли репликация системы SAP HANA.

    # Verify HANA HSR is in sync
    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    #| Database | Host         | Port  | Service Name | Volume ID | Site ID | Site Name | Secondary    | Secondary | Secondary | Secondary | Secondary     | Replication | Replication | Replication    |
    #|          |              |       |              |           |         |           | Host         | Port      | Site ID   | Site Name | Active Status | Mode        | Status      | Status Details |
    #| -------- | ------------ | ----- | ------------ | --------- | ------- | --------- | ------------ | --------- | --------- | --------- | ------------- | ----------- | ----------- | -------------- |
    #| SYSTEMDB | hana-s1-db1  | 30301 | nameserver   |         1 |       1 | HANA_S1   | hana-s2-db1  |     30301 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db1  | 30307 | xsengine     |         2 |       1 | HANA_S1   | hana-s2-db1  |     30307 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db1  | 30303 | indexserver  |         3 |       1 | HANA_S1   | hana-s2-db1  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db3  | 30303 | indexserver  |         4 |       1 | HANA_S1   | hana-s2-db3  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #| HN1      | hana-s1-db2  | 30303 | indexserver  |         5 |       1 | HANA_S1   | hana-s2-db2  |     30303 |         2 | HANA_S2   | YES           | SYNC        | ACTIVE      |                |
    #
    #status system replication site "1": ACTIVE
    #overall system replication status: ACTIVE
    #
    #Local System Replication State
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    #
    #mode: PRIMARY
    #site id: 1
    #site name: HANA_S1
    
  2. Мы рекомендуем тщательно проверить конфигурацию кластера SAP HANA, проведя тесты, задокументированные в HA для SAP HANA на виртуальных машинах Azure на SLES и SLES Replication scale-out Performance Optimized Scenario.

  3. Проверьте конфигурацию кластера на случай сбоя, когда узел теряет доступ к общей папке NFS (/hana/shared).

    Агенты ресурсов SAP HANA зависят от бинарных файлов, хранящихся в /hana/shared, для выполнения операций при отказе. В представленной конфигурации файловая система /hana/shared подключена посредством NFS. Можно протестировать систему, создав временное правило брандмауэра для блокировки доступа к файловой системе /hana/shared, подключенной к NFS, на одной из виртуальных машин основного сайта. Этот подход позволяет проверить, произойдет ли переключение кластера, если будет утрачен доступ к /hana/shared на активном узле репликации системы.

    Ожидаемый результат: при блокировке доступа к /hana/shared подключенной файловой системе NFS на одной из основных виртуальных машин сайта операция мониторинга, которая выполняет операцию чтения и записи в файловой системе, завершится ошибкой, так как она не сможет получить доступ к файловой системе и запустит отработку отказа ресурсов HANA. Такой же результат ожидается, когда узел HANA теряет доступ к NFS-ресурсу.

    Состояние ресурсов кластера можно проверить, выполнив команду crm_mon или crm status. Состояние ресурсов перед запуском теста:

    # Output of crm_mon
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Active resources:
    #
    #stonith-sbd     (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s1-db1 ]
    #     Slaves: [ hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1     
    

    Чтобы сымитировать сбой для /hana/shared, выполните следующие действия:

    • При использовании NFS в Azure NetApp Files сначала подтвердите IP-адрес тома /hana/shared Azure NetApp Files на основном сайте. Для этого можно выполнить команду df -kh|grep /hana/shared.
    • При использовании NFS в Файлах Azure сначала определите IP-адрес частной конечной точки для учетной записи хранения.

    Затем настройте временное правило брандмауэра, чтобы заблокировать доступ к IP-адресу файловой системы /hana/shared, подключенной к NFS, выполнив следующую команду на одной из виртуальных машин основного сайта репликации системы HANA.

    В этом примере команда была выполнена на hana-s1-db1 для тома Azure NetApp Files /hana/shared.

    iptables -A INPUT -s 10.23.1.7 -j DROP; iptables -A OUTPUT -d 10.23.1.7 -j DROP
    

    Кластерные ресурсы в этом случае переносятся на другой сайт репликации системы HANA.

    Если задано значение AUTOMATED_REGISTER="false", необходимо настроить репликацию системы SAP HANA на вторичном сайте после перехода. В этом случае можно выполнить приведенные ниже команды, чтобы перенастроить SAP HANA как вторичную систему.

    # Execute on the secondary 
    su - hn1adm
    # Make sure HANA is not running on the secondary site. If it is started, stop HANA
    sapcontrol -nr 03 -function StopWait 600 10
    # Register the HANA secondary site
    hdbnsutil -sr_register --name=HANA_S1 --remoteHost=hana-s2-db1 --remoteInstance=03 --replicationMode=sync
    # Switch back to root and cleanup failed resources
    crm resource cleanup SAPHana_HN1_HDB03
    

    Состояние ресурсов после теста:

    # Output of crm_mon
    #7 nodes configured
    #24 resource instances configured
    #
    #Online: [ hana-s-mm hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    #
    #Active resources:
    #
    #stonith-sbd     (stonith:external/sbd): Started hana-s-mm
    # Clone Set: cln_fs_HN1_HDB03_fscheck [fs_HN1_HDB03_fscheck]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
    #     Started: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db1 hana-s2-db2 hana-s2-db3 ]
    # Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
    #     Masters: [ hana-s2-db1 ]
    #     Slaves: [ hana-s1-db1 hana-s1-db2 hana-s1-db3 hana-s2-db2 hana-s2-db3 ]
    # Resource Group: g_ip_HN1_HDB03
    #     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hana-s2-db1
    #     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hana-s2-db1
    

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