Высокая доступность масштабирования SAP HANA с помощью Azure NetApp Files в SUSE Enterprise Linux

В этой статье описывается настройка реплика развертывания системы SAP HANA при подключении файловых систем HANA через NFS с помощью Azure NetApp Files. В примерах конфигураций и команд установки используются номера экземпляра 03 и HANA System ID HN1. Sap HANA реплика tion состоит из одного первичного узла и по крайней мере одного дополнительного узла.

Когда шаги в этом документе помечены следующими префиксами, они означают:

  • [A] — шаг применяется ко всем узлам.
  • [1]. Шаг применяется только к node1.
  • [2]. Шаг применяется только к node2.

Прежде всего прочитайте следующие примечания и документы SAP:

Примечание.

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

Обзор

Традиционно в среде масштабирования все файловые системы sap HANA подключены из локального хранилища. Настройка высокой доступности системы SAP HANA реплика tion в SUSE Enterprise Linux опубликована в разделе "Настройка системы SAP HANA реплика tion в SLES".

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

Diagram that shows SAP HANA HA scale-up on Azure NetApp Files.

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

Подключено к node1 (hanadb1):

  • 10.3.1.4:/hanadb1-data-mnt00001 on /hana/data
  • 10.3.1.4:/hanadb1-log-mnt00001 on /hana/log
  • 10.3.1.4:/hanadb1-shared-mnt00001 on /hana/shared

Подключено на узле 2 (hanadb2):

  • 10.3.1.4:/hanadb2-data-mnt00001 on /hana/data
  • 10.3.1.4:/hanadb2-log-mnt00001 on /hana/log
  • 10.3.1.4:/hanadb2-shared-mnt0001 on /hana/shared

Примечание.

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

Конфигурация реплика tion системы SAP HA HANA использует выделенное имя виртуального узла и виртуальные IP-адреса. Load Balancer в Azure должен использовать виртуальный IP-адрес. В представленной конфигурации показана следующая подсистема балансировки нагрузки:

  • IP-адрес конфигурации внешнего интерфейса: 10.3.0.50 для hn1-db
  • Порт пробы: 62503

Настройка инфраструктуры Azure NetApp Files

Прежде чем продолжить настройку инфраструктуры Azure NetApp Files, ознакомьтесь с документацией по Azure NetApp Files.

Служба Azure NetApp Files доступна в нескольких регионах Azure. Проверьте, предоставляется ли служба Azure NetApp Files в выбранном регионе Azure.

Сведения о доступности Azure NetApp Files в регионе Azure см. в статье о доступности Azure NetApp Files по регионам Azure.

Важные замечания

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

Выбор размера базы данных HANA в Azure NetApp Files

Пропускная способность тома Azure NetApp Files зависит от размера тома и уровня обслуживания, как описано в разделе Уровни обслуживания для Azure NetApp Files.

При разработке инфраструктуры SAP HANA в Azure с помощью Azure NetApp Files помните о рекомендациях в томах NFS версии 4.1 в Azure NetApp Files для SAP HANA.

Конфигурация в этой статье представлена простыми томами Azure NetApp Files.

Внимание

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

Все команды для подключения /hana/shared в этой статье представлены для томов /hana/shared NFSv4.1. Если вы развернули тома /hana/shared в качестве томов NFSv3, не забудьте настроить команды подключения /hana/shared для NFSv3.

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

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

  1. Создайте учетную запись NetApp в выбранном регионе Azure, следуя инструкциям в разделе Создание учетной записи NetApp.

  2. Настройте пул емкости Azure NetApp Files, следуя инструкциям по настройке пула емкости Azure NetApp Files.

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

  3. Делегируйте подсеть в Azure NetApp Files согласно инструкциям по делегированию подсети в Azure NetApp Files.

  4. Разверните тома Azure NetApp Files, следуя инструкциям по созданию тома NFS для Azure NetApp Files.

    При развертывании томов обязательно выберите версию NFSv4.1. Разверните тома в выделенной подсети Azure NetApp Files. IP-адреса томов Azure NetApp Files назначаются автоматически.

    Ресурсы Azure NetApp Files и виртуальные машины Azure должны находиться в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure. Например, hanadb1-data-mnt00001, hanadb1-log-mnt00001 и т. д. являются именами томов, а nfs://10.3.1.4/hanadb1-data-mnt00001, nfs://10.3.1.4/hanadb1-log-mnt00001 и т. д. пути к файлам томов Azure NetApp Files.

    В hanadb1:

    • Том hanadb1-data-mnt00001 (nfs://10.3.1.4:/hanadb1-data-mnt00001)
    • Том hanadb1-log-mnt00001 (nfs://10.3.1.4:/hanadb1-log-mnt00001)
    • Том hanadb1-shared-mnt00001 (nfs://10.3.1.4:/hanadb1-shared-mnt00001)

    В hanadb2:

    • Том hanadb2-data-mnt00001 (nfs://10.3.1.4:/hanadb2-data-mnt00001)
    • Том hanadb2-log-mnt00001 (nfs://10.3.1.4:/hanadb2-log-mnt00001)
    • Том hanadb2-shared-mnt00001 (nfs://10.3.1.4:/hanadb2-shared-mnt00001)

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

Агент ресурсов для SAP HANA включен в состав SUSE Linux Enterprise Server for SAP Applications. Образ SUSE Linux Enterprise Server для приложений SAP 12 или 15 доступен в Azure Marketplace. Образ можно использовать для развертывания новых виртуальных машин.

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

В этом документе предполагается, что вы уже развернули группу ресурсов, azure виртуальная сеть и подсеть.

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

Внимание

Убедитесь, что выбранная ОС сертифицирована для SAP HANA на определенных типах виртуальных машин, которые планируется использовать в развертывании. Вы можете искать типы виртуальных машин, сертифицированные SAP HANA, и их выпуски ОС на платформах IaaS, сертифицированных sap HANA. Убедитесь, что вы просматриваете сведения о типе виртуальной машины, чтобы получить полный список выпусков ОС, поддерживаемых SAP HANA, для конкретного типа виртуальной машины.

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

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

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

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

Примечание.

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

Дополнительные сведения о необходимых портах для SAP HANA см. в главе Подключения к базам данных клиента руководства Базы данных клиента SAP HANA или в примечании к SAP 2388694.

Внимание

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

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

Внимание

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

Подключение тома Azure NetApp Files

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

    sudo mkdir -p /hana/data/HN1/mnt00001
    sudo mkdir -p /hana/log/HN1/mnt00001
    sudo mkdir -p /hana/shared/HN1
    
  2. [A] Проверьте параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, то есть defaultv4iddomain.com, и сопоставление не задано никому.

    sudo cat /etc/idmapd.conf
    

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

    [General]
    Domain = defaultv4iddomain.com
    [Mapping]
    Nobody-User = nobody
    Nobody-Group = nobody
    

    Внимание

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

  3. [A] Измените /etc/fstab оба узла, чтобы окончательно подключить тома, относящиеся к каждому узлу. В следующем примере показано, как постоянно подключать тома.

    sudo vi /etc/fstab
    

    Добавьте следующие записи на /etc/fstab обоих узлах.

    Пример для hanadb1:

    10.3.1.4:/hanadb1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    10.3.1.4:/hanadb1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    10.3.1.4:/hanadb1-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    

    Пример для hanadb2:

    10.3.1.4:/hanadb2-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    10.3.1.4:/hanadb2-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    10.3.1.4:/hanadb2-shared-mnt00001 /hana/shared/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
    

    Подключите все тома.

    sudo mount -a
    

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

  4. [A] Убедитесь, что все тома HANA подключены с помощью протокола NFS версии NFSv4.

    sudo nfsstat -m
    

    Убедитесь, что флаг vers имеет значение 4.1.

    Пример из hanadb1:

    /hana/log/HN1/mnt00001 from 10.3.1.4:/hanadb1-log-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
    /hana/data/HN1/mnt00001 from 10.3.1.4:/hanadb1-data-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
    /hana/shared/HN1 from 10.3.1.4:/hanadb1-shared-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.3.0.4,local_lock=none,addr=10.3.1.4
    
  5. [A] Проверьте nfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, в которой находится nfs4_disable_idmapping , выполните команду подключения. Вы не сможете вручную создать каталог /sys/modules , так как доступ зарезервирован для ядра или драйверов.

    #Check nfs4_disable_idmapping
    sudo cat /sys/module/nfs/parameters/nfs4_disable_idmapping
    
    #If you need to set nfs4_disable_idmapping to Y
    sudo echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
    #Make the configuration permanent
    sudo echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
    

Установка SAP HANA

  1. [A] Настройка разрешения имен узлов для всех узлов.

    Вы можете использовать DNS-сервер или изменить /etc/hosts файл на всех узлах. В этом примере показано, как использовать файл /etc/hosts. Замените IP-адрес и имя узла в следующих командах:

    sudo vi /etc/hosts
    

    Вставьте следующие строки в /etc/hosts файл. Измените IP-адрес и имя узла в соответствии с параметрами среды.

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

    sudo vi /etc/sysctl.d/91-NetApp-HANA.conf
    

    Добавьте следующие записи в файл конфигурации:

    net.core.rmem_max = 16777216
    net.core.wmem_max = 16777216
    net.ipv4.tcp_rmem = 4096 131072 16777216
    net.ipv4.tcp_wmem = 4096 16384 16777216
    net.core.netdev_max_backlog = 300000
    net.ipv4.tcp_slow_start_after_idle=0
    net.ipv4.tcp_no_metrics_save = 1
    net.ipv4.tcp_moderate_rcvbuf = 1
    net.ipv4.tcp_window_scaling = 1
    net.ipv4.tcp_sack = 1
    
  3. [A] Создайте файл /etc/sysctl.d/ms-az.conf конфигурации с дополнительными параметрами оптимизации.

    sudo vi /etc/sysctl.d/ms-az.conf
    

    Добавьте следующие записи в файл конфигурации:

    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv4.tcp_max_syn_backlog = 16348
    net.ipv4.conf.all.rp_filter = 0
    sunrpc.tcp_slot_table_entries = 128
    vm.swappiness=10
    

    Совет

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

  4. [A] Настройте sunrpc параметры, как рекомендуется в sap Note 3024346 — ядро Linux Параметры для NetApp NFS.

    sudo vi /etc/modprobe.d/sunrpc.conf
    

    Вставьте следующую строку:

    options sunrpc tcp_max_slot_table_entries=128
    
  5. [A] Настройка SLES для HANA.

    Настройте SLES, как описано в следующих заметках SAP на основе версии SLES:

  6. [A] Установите SAP HANA.

    Начиная с HANA 2.0 с пакетом обновления 01 (SPS 01), контейнеры многотенантных баз данных (MDC) — это параметр по умолчанию. При установке системы HANA SYSTEMDB и клиента с одинаковым идентификатором безопасности создаются вместе. В некоторых случаях клиент по умолчанию не требуется. Если вы не хотите создать начальный клиент вместе с установкой, следуйте инструкциям в sap Note 2629711.

    1. hdblcm Запустите программу из каталога программного обеспечения установки HANA.

      ./hdblcm
      
    2. Введите следующие значения на запрос в командной строке:

      • Для выбора установки: введите 1 (для установки).
      • Для выбора дополнительных компонентов для установки: введите 1.
      • Для пути установки введите [/hana/shared]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода имени локального узла [.]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • В разделе "Добавить дополнительные узлы в систему"? (y/n) [n]: выберите n.
      • Для ввода идентификатора системы SAP HANA: введите HN1.
      • Введите номер экземпляра [00]: введите 03.
      • Для выбора режима базы данных / ВВОД индекса [1]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для выбора системного использования и ввода индекса [4]: введите 4 (для пользовательского).
      • Для ввода расположения томов данных [/hana/data]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода расположения томов журнала [/hana/log]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ограничения максимального выделения памяти? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • В поле "Введите имя узла сертификата" для узла "..." [...]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода пароля пользователя агента узла SAP (sapadm): введите пароль пользователя агента узла.
      • Для подтверждения пароля пользователя агента узла SAP (sapadm): снова введите пароль пользователя агента узла, чтобы подтвердить.
      • В поле Ввод пароля Администратор istrator (hn1adm): введите пароль системного администратора.
      • Для подтверждения пароля системы Администратор istrator (hn1adm): введите пароль системного администратора еще раз, чтобы подтвердить.
      • Для входа в систему Администратор istrator Home Directory [/usr/sap/HN1/home]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для командной строки входа в систему Администратор istrator [/bin/sh]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода системного Администратор istrator user ID [1001]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для ввода идентификатора группы пользователей (sapsys) [79]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для пароля пользователя базы данных (SYSTEM): введите пароль пользователя базы данных.
      • Для подтверждения пароля пользователя базы данных (SYSTEM) введите пароль пользователя базы данных еще раз, чтобы подтвердить.
      • Для перезагрузки системы после перезагрузки компьютера? [n]: нажмите клавишу ВВОД, чтобы принять значение по умолчанию.
      • Для чего вы хотите продолжить? (y/n): проверьте сводку. Для продолжения введите y.
  7. [A]. Обновите агент узла SAP.

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

    sudo /usr/sap/hostctrl/exe/saphostexec -upgrade -archive <path to SAP Host Agent SAR>
    

Configuring SAP HANA System Replication (Настройка репликации системы SAP HANA)

Выполните действия в системе SAP HANA реплика tion, чтобы настроить реплика системы SAP HANA.

Конфигурация кластера

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

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

Выполните действия по настройке Pacemaker на SUSE Enterprise Linux в Azure, чтобы создать базовый кластер Pacemaker для этого сервера HANA.

Реализация перехватчиков HANA SAPHanaSR и susChkSrv

Этот важный шаг оптимизирует интеграцию с кластером и улучшает обнаружение при необходимости отработки отказа кластера. Настоятельно рекомендуется настроить как перехватчики SAPHanaSR, так и susChkSrv Python. Выполните действия, описанные в разделе "Реализация системы Python реплика перехватчиков SAPHanaSR и susChkSrv".

Настройка кластерных ресурсов SAP HANA

В этом разделе описаны необходимые действия, необходимые для настройки ресурсов кластера SAP HANA.

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

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

sudo crm_mon -r

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

# Online: [ hn1-db-0 hn1-db-1 ]
# Full list of resources:
# stonith-sbd     (stonith:external/sbd): Started hn1-db-0
# Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]
#     Started: [ hn1-db-0 hn1-db-1 ]
# Master/Slave Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03]
#     Masters: [ hn1-db-0 ]
#     Slaves: [ hn1-db-1 ]
# Resource Group: g_ip_HN1_HDB03
#     rsc_ip_HN1_HDB03   (ocf::heartbeat:IPaddr2):       Started hn1-db-0
#     rsc_nc_HN1_HDB03   (ocf::heartbeat:azure-lb):      Started hn1-db-0

Создание ресурсов файловой системы

Создайте фиктивный ресурс кластера файловой системы. Он отслеживает и сообщает о сбоях, если возникла проблема с доступом к подключенной к NFS файловой системе /hana/shared. Это позволяет кластеру активировать отработку отказа, если возникла проблема с доступом к /hana/shared. Подробные сведения см. в статье Обработка неисправной общей папки NFS в кластере SUSE с высоким уровнем доступности для репликации системы HANA.

  1. [A] Создайте структуру каталогов на обоих узлах.

    sudo mkdir -p /hana/shared/HN1/check
    sudo mkdir -p /hana/shared/check
    
  2. [1] Настройте кластер для добавления структуры каталогов для мониторинга.

    sudo crm configure primitive rsc_fs_check_HN1_HDB03 Filesystem params \
        device="/hana/shared/HN1/check/" \
        directory="/hana/shared/check/" fstype=nfs  \
        options="bind,defaults,rw,hard,rsize=262144,wsize=262144,proto=tcp,noatime,_netdev,nfsvers=4.1,lock,sec=sys" \
        op monitor interval=120 timeout=120 on-fail=fence \
        op_params OCF_CHECK_LEVEL=20 \
        op start interval=0 timeout=120 \
        op stop interval=0 timeout=120
    
  3. [1] Клонирование и проверка только что настроенный том в кластере.

    sudo crm configure clone cln_fs_check_HN1_HDB03 rsc_fs_check_HN1_HDB03 meta clone-node-max=1 interleave=true
    

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

    sudo crm status
    
    # Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb1 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Tue Nov  2 17:57:39 2021
    # Last change:  Tue Nov  2 17:57:38 2021 by root via crm_attribute on hanadb1
    # 2 nodes configured
    # 11 resource instances configured
    
    # Node List:
    # Online: [ hanadb1 hanadb2 ]
    
    # Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
    #  Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
    #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb1 (Monitoring)
    #  rsc_SAPHanaTopology_HN1_HDB03     (ocf::suse:SAPHanaTopology):     Started hanadb2 (Monitoring)
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
    #  rsc_SAPHana_HN1_HDB03     (ocf::suse:SAPHana):     Master hanadb1 (Monitoring)
    #  Slaves: [ hanadb2 ]
    # Resource Group: g_ip_HN1_HDB03:
    #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
    #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
    #  Started: [ hanadb1 hanadb2 ]
    

    Атрибут OCF_CHECK_LEVEL=20 добавляется в операцию мониторинга, чтобы отслеживать операции чтения и записи в файловой системе. Без этого атрибута операция монитора проверяет только подключение файловой системы. Это может оказаться проблемой, так как при потере соединения файловая система может оставаться подключенной, являясь при этом недоступной.

    Атрибут on-fail=fence также добавляется в операцию монитора. С этим параметром в случае сбоя операции монитора на узле этот узел немедленно ограждается.

Внимание

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

Проверка настройки кластера

В этом разделе описано, как проверить настроенную систему.

  1. Прежде чем начать тест, убедитесь, что Pacemaker не имеет никаких неудачных действий (через состояние crm) и никаких непредвиденных ограничений расположения (например, оставшиеся элементы теста миграции). Кроме того, убедитесь, что система HANA реплика tion находится в состоянии синхронизации, например с systemReplicationStatus.

    sudo su - hn1adm -c "python /usr/sap/HN1/HDB03/exe/python_support/systemReplicationStatus.py"
    
  2. Проверьте состояние ресурсов HANA с помощью следующей команды:

    SAPHanaSR-showAttr
    
    # You should see something like below
    # hanadb1:~ SAPHanaSR-showAttr
    # Global cib-time                 maintenance
    # --------------------------------------------
    # global Mon Nov  8 22:50:30 2021 false
    # Sites srHook
    # -------------
    # SITE1 PRIM
    # SITE2 SOK
    # Site2 SOK
    # Hosts   clone_state lpa_hn1_lpt node_state op_mode   remoteHost roles                            score site  srmode sync_state version                vhost
    # --------------------------------------------------------------------------------------------------------------------------------------------------------------
    # hanadb1 PROMOTED    1636411810  online     logreplay hanadb2    4:P:master1:master:worker:master 150   SITE1 sync   PRIM       2.00.058.00.1634122452 hanadb1
    # hanadb2 DEMOTED     30          online     logreplay hanadb1    4:S:master1:master:worker:master 100   SITE2 sync   SOK        2.00.058.00.1634122452 hanadb2
    
  3. Проверьте конфигурацию кластера для сценария сбоя при завершении работы узла. В следующем примере показано завершение работы узла 1:

    sudo crm status
    sudo crm resource move msl_SAPHana_HN1_HDB03 hanadb2 force
    sudo crm resource cleanup
    

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

    sudo crm status
    
    #Cluster Summary:
    # Stack: corosync
    # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
    # Last updated: Mon Nov  8 23:25:36 2021
    # Last change:  Mon Nov  8 23:25:19 2021 by root via crm_attribute on hanadb2
    # 2 nodes configured
    # 11 resource instances configured
    
    # Node List:
    # Online: [ hanadb1 hanadb2 ]
    # Full List of Resources:
    # Clone Set: cln_azure-events [rsc_azure-events]:
    #  Started: [ hanadb1 hanadb2 ]
    # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
    #  Started: [ hanadb1 hanadb2 ]
    # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
    #  Masters: [ hanadb2 ]
    #  Stopped: [ hanadb1 ]
    # Resource Group: g_ip_HN1_HDB03:
    #  rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
    #  rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
    # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
    # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
    #  Started: [ hanadb1 hanadb2 ]
    

    Остановите HANA на node1:

    sudo su - hn1adm
    sapcontrol -nr 03 -function StopWait 600 10
    

    Зарегистрируйте узел 1 в качестве дополнительного узла и состояние проверка:

    hdbnsutil -sr_register --remoteHost=hanadb2 --remoteInstance=03 --replicationMode=sync --name=SITE1 --operationMode=logreplay
    

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

    #adding site ...
    #nameserver hanadb1:30301 not responding.
    #collecting information ...
    #updating local ini files ...
    #done.
    
    sudo crm status
    
    sudo SAPHanaSR-showAttr
    
  4. Проверьте конфигурацию кластера для сценария сбоя, когда узел теряет доступ к общей папке NFS (/hana/shared).

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

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

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

    Состояние ресурсов перед запуском теста:

    sudo crm  status
    
    #Cluster Summary:
     # Stack: corosync
     # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
     # Last updated: Mon Nov  8 23:01:27 2021
     # Last change:  Mon Nov  8 23:00:46 2021 by root via crm_attribute on hanadb1
     # 2 nodes configured
     # 11 resource instances configured
    
     #Node List:
     # Online: [ hanadb1 hanadb2 ]
    
     #Full List of Resources:
     # Clone Set: cln_azure-events [rsc_azure-events]:
       # Started: [ hanadb1 hanadb2 ]
     # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
       # Started: [ hanadb1 hanadb2 ]
     # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
       # Masters: [ hanadb1 ]
       # Slaves: [ hanadb2 ]
     # Resource Group: g_ip_HN1_HDB03:
       # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb1
       # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb1
     # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
     # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
       # Started: [ hanadb1 hanadb2 ]
    

    Вы можете разместить /hana/shared в режиме только для чтения на активном узле кластера с помощью следующей команды:

    sudo mount -o ro 10.3.1.4:/hanadb1-shared-mnt00001 /hana/sharedb
    

    Сервер hanadb1 перезагружается или отключается на основе набора действий. После выключения сервера hanadb1 ресурс HANA переходит в hanadb2. Вы можете проверка состояние кластера.hanadb2

    sudo crm status
    
    #Cluster Summary:
     # Stack: corosync
     # Current DC: hanadb2 (version 2.0.5+20201202.ba59be712-4.9.1-2.0.5+20201202.ba59be712) - partition with quorum
     # Last updated: Wed Nov 10 22:00:27 2021
     # Last change:  Wed Nov 10 21:59:47 2021 by root via crm_attribute on hanadb2
     # 2 nodes configured
     # 11 resource instances configured
    
     #Node List:
     # Online: [ hanadb1 hanadb2 ]
    
     #Full List of Resources:
     # Clone Set: cln_azure-events [rsc_azure-events]:
       # Started: [ hanadb1 hanadb2 ]
     # Clone Set: cln_SAPHanaTopology_HN1_HDB03 [rsc_SAPHanaTopology_HN1_HDB03]:
       # Started: [ hanadb1 hanadb2 ]
     # Clone Set: msl_SAPHana_HN1_HDB03 [rsc_SAPHana_HN1_HDB03] (promotable):
       # Masters: [ hanadb2 ]
       # Stopped: [ hanadb1 ]
     # Resource Group: g_ip_HN1_HDB03:
          # rsc_ip_HN1_HDB03  (ocf::heartbeat:IPaddr2):        Started hanadb2
       # rsc_nc_HN1_HDB03  (ocf::heartbeat:azure-lb):       Started hanadb2
     # rsc_st_azure        (stonith:fence_azure_arm):       Started hanadb2
     # Clone Set: cln_fs_check_HN1_HDB03 [rsc_fs_check_HN1_HDB03]:
       # Started: [ hanadb1 hanadb2 ]
    

    Мы рекомендуем тщательно протестировать конфигурацию кластера SAP HANA, выполнив тесты, описанные в реплика системе SAP HANA.

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