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

Высокая доступность крупных инстансов Azure для SAP на базе RHEL

Примечание.

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

В этой статье вы узнаете, как настроить кластер Pacemaker в RHEL 7 для автоматизации отработки отказа базы данных SAP HANA. Требуется хорошо разбираться в Linux, SAP HANA и Pacemaker, чтобы выполнить шаги, описанные в этом руководстве.

В следующей таблице приведены имена узлов, которые используются в этой статье. Блоки кода в статье показывают команды, которые необходимо выполнить, а также выходные данные в результате выполнения этих команд. Обратите особое внимание на то, на какой узел ссылается каждая команда.

Тип Имя хоста Узел
Основной хост sollabdsm35 узел 1
Второстепенный сервер sollabdsm36 узел 2

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

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

  1. Используйте следующие команды для создания одинаковых /etc/hosts на обоих узлах.

    root@sollabdsm35 ~]# cat /etc/hosts
27.0.0.1 localhost localhost.azlinux.com
10.60.0.35 sollabdsm35.azlinux.com sollabdsm35 node1
10.60.0.36 sollabdsm36.azlinux.com sollabdsm36 node2
10.20.251.150 sollabdsm36-st
10.20.251.151 sollabdsm35-st
10.20.252.151 sollabdsm36-back
10.20.252.150 sollabdsm35-back
10.20.253.151 sollabdsm36-node
10.20.253.150 sollabdsm35-node

  2. Создайте и выполните обмен ключами SSH.

    1. Создайте ключ SSH.
       [root@sollabdsm35 ~]# ssh-keygen -t rsa -b 1024
   [root@sollabdsm36 ~]# ssh-keygen -t rsa -b 1024

    1. Скопируйте ключи на другие узлы для SSH без пароля.

      [root@sollabdsm35 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub sollabdsm35
[root@sollabdsm35 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub sollabdsm36
[root@sollabdsm36 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub sollabdsm35
[root@sollabdsm36 ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub sollabdsm36

  3. Отключите selinux на обоих узлах.

    [root@sollabdsm35 ~]# vi /etc/selinux/config

...

SELINUX=disabled

[root@sollabdsm36 ~]# vi /etc/selinux/config

...

SELINUX=disabled

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

    [root@sollabdsm35 ~]# sestatus

SELinux status: disabled

[root@sollabdsm36 ~]# sestatus

SELinux status: disabled

  5. Выполните настройку NTP (протокол синхронизации времени по сети). Время и часовой пояс на обоих узлах кластера должны совпадать. Используйте следующую команду, чтобы открыть chrony.conf и проверить содержимое файла.

    1. В файл конфигурации необходимо добавить следующее содержимое. Измените фактические значения в соответствии с используемой средой.

      vi /etc/chrony.conf

 Use public servers from the pool.ntp.org project.

 Please consider joining the pool (http://www.pool.ntp.org/join.html).

server 0.rhel.pool.ntp.org iburst

    2. Включите службу chrony.

      systemctl enable chronyd

systemctl start chronyd



chronyc tracking

Reference ID : CC0BC90A (voipmonitor.wci.com)

Stratum : 3

Ref time (UTC) : Thu Jan 28 18:46:10 2021

chronyc sources

210 Number of sources = 8

MS Name/IP address Stratum Poll Reach LastRx Last sample

===============================================================================

^+ time.nullroutenetworks.c> 2 10 377 1007 -2241us[-2238us] +/- 33ms

^* voipmonitor.wci.com 2 10 377 47 +956us[ +958us] +/- 15ms

^- tick.srs1.ntfo.org 3 10 177 801 -3429us[-3427us] +/- 100ms

  6. Обновление системы

    1. Сначала установите последние обновления системы, прежде чем приступить к установке устройства SBD.

    2. Клиентам необходимо установить по меньшей мере версию 4.1.1-12.el7_6.26 пакета resource-agents-sap-hana, как описано в статье о политиках поддержки для кластеров высокого уровня доступности RHEL и управлении SAP HANA в кластере.

    3. Если вы не хотите полностью обновлять систему, даже если это рекомендовано, обновите по меньшей мере следующие пакеты.

      1. resource-agents-sap-hana
      2. selinux-policy
      3. iscsi-initiator-utils
      node1:~ # yum update

  7. Установите репозитории SAP HANA и RHEL-HA.

    subscription-manager repos –list

subscription-manager repos
--enable=rhel-sap-hana-for-rhel-7-server-rpms

subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms

  8. Установите инструменты Pacemaker, SBD, OpenIPMI, ipmitool и fencing_sbd на всех узлах.

    yum install pcs sbd fence-agent-sbd.x86_64 OpenIPMI
ipmitool

Настройка Watchdog

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

  1. Убедитесь, что демон watchdog не запущен на каких-либо системах.

    [root@sollabdsm35 ~]# systemctl disable watchdog
[root@sollabdsm36 ~]# systemctl disable watchdog
[root@sollabdsm35 ~]# systemctl stop watchdog
[root@sollabdsm36 ~]# systemctl stop watchdog
[root@sollabdsm35 ~]# systemctl status watchdog

● watchdog.service - watchdog daemon

Loaded: loaded (/usr/lib/systemd/system/watchdog.service; disabled;
vendor preset: disabled)

Active: inactive (dead)

Nov 28 23:02:40 sollabdsm35 systemd[1]: Collecting watchdog.service

  2. По умолчанию во время установки в качестве службы наблюдения для Linux устанавливается служба наблюдения iTCO, которая не поддерживается системами UCS и HPE SDFlex. Поэтому эту службу наблюдения необходимо отключить.

    1. Неправильная служба мониторинга установлена и загружена в системе.

      sollabdsm35:~ # lsmod |grep iTCO

iTCO_wdt 13480 0

iTCO_vendor_support 13718 1 iTCO_wdt

    2. Выгрузите неправильный драйвер из среды.

      sollabdsm35:~ # modprobe -r iTCO_wdt iTCO_vendor_support

sollabdsm36:~ # modprobe -r iTCO_wdt iTCO_vendor_support

    3. Чтобы драйвер не загружался при следующем запуске системы, драйвер должен быть занесен в список блокировок. Чтобы добавить модули iTCO в список блокировок, добавьте следующее в конец файла 50-blacklist.conf.

      sollabdsm35:~ # vi /etc/modprobe.d/50-blacklist.conf

 unload the iTCO watchdog modules

blacklist iTCO_wdt

blacklist iTCO_vendor_support

    4. Скопируйте файл на вторичный хост.

      sollabdsm35:~ # scp /etc/modprobe.d/50-blacklist.conf sollabdsm35:
/etc/modprobe.d/50-blacklist.conf

    5. Проверьте, запущена ли служба ipmi. Важно, чтобы таймер IPMI не был запущен. Управление таймером будет выполняться службой SBD Pacemaker.

      sollabdsm35:~ # ipmitool mc watchdog get

Watchdog Timer Use: BIOS FRB2 (0x01)

Watchdog Timer Is: Stopped

Watchdog Timer Actions: No action (0x00)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x00

Initial Countdown: 0 sec

Present Countdown: 0 sec

  3. По умолчанию требуемое устройство /dev/watchdog не создается.

    sollabdsm35:~ # ls -l /dev/watchdog

ls: cannot access /dev/watchdog: No such file or directory

  4. Выполните конфигурацию службы наблюдения IPMI.

    sollabdsm35:~ # mv /etc/sysconfig/ipmi /etc/sysconfig/ipmi.org

sollabdsm35:~ # vi /etc/sysconfig/ipmi

IPMI_SI=yes
DEV_IPMI=yes
IPMI_WATCHDOG=yes
IPMI_WATCHDOG_OPTIONS="timeout=20 action=reset nowayout=0
panic_wdt_timeout=15"
IPMI_POWEROFF=no
IPMI_POWERCYCLE=no
IPMI_IMB=no

  5. Скопируйте файл конфигурации службы наблюдения на второстепенный узел.

    sollabdsm35:~ # scp /etc/sysconfig/ipmi
sollabdsm36:/etc/sysconfig/ipmi

  6. Включите и запустите службу ipmi.

    [root@sollabdsm35 ~]# systemctl enable ipmi

Created symlink from
/etc/systemd/system/multi-user.target.wants/ipmi.service to
/usr/lib/systemd/system/ipmi.service.

[root@sollabdsm35 ~]# systemctl start ipmi

[root@sollabdsm36 ~]# systemctl enable ipmi

Created symlink from
/etc/systemd/system/multi-user.target.wants/ipmi.service to
/usr/lib/systemd/system/ipmi.service.

[root@sollabdsm36 ~]# systemctl start ipmi

    Теперь служба IPMI запущена и создается устройство /dev/watchdog, но таймер по-прежнему остановлен. Позже SBD будет управлять сбросом таймера наблюдения и включит таймер IPMI.

  7. Убедитесь, что /dev/watchdog существует, но не используется.

    [root@sollabdsm35 ~]# ipmitool mc watchdog get
Watchdog Timer Use: SMS/OS (0x04)
Watchdog Timer Is: Stopped
Watchdog Timer Actions: No action (0x00)
Pre-timeout interval: 0 seconds
Timer Expiration Flags: 0x10
Initial Countdown: 20 sec
Present Countdown: 20 sec

[root@sollabdsm35 ~]# ls -l /dev/watchdog
crw------- 1 root root 10, 130 Nov 28 23:12 /dev/watchdog
[root@sollabdsm35 ~]# lsof /dev/watchdog

Конфигурация SBD

В этой статье приведена информация о том, как настроить SBD. В этой статье используются те же два узла, sollabdsm35 и sollabdsm36, о которых шла речь в начале этой статьи.

  1. Убедитесь, что диск iSCSI или FC отображается в обоих узлах. В этом примере используется устройство SBD, основанное на FC. Дополнительные сведения об ограждении SBD см. в руководстве по проектированию для кластеров с высоким уровнем доступности RHEL с рекомендациями по SBD и статье о политиках поддержки для кластеров с высоким уровнем доступности RHEL — SBD и fence_sbd.

  2. Идентификатор LUN должен быть одинаковым на всех узлах.

  3. Проверьте статус многопутевого доступа для устройства sbd.

    multipath -ll
3600a098038304179392b4d6c6e2f4b62 dm-5 NETAPP ,LUN C-Mode
size=1.0G features='4 queue_if_no_path pg_init_retries 50
retain_attached_hw_handle' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 8:0:1:2 sdi 8:128 active ready running
| `- 10:0:1:2 sdk 8:160 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 8:0:3:2 sdj 8:144 active ready running
`- 10:0:3:2 sdl 8:176 active ready running

  4. Создание дисков SBD и настройка примитивного ограждения для кластера Это действие должно выполняться на первом узле.

    sbd -d /dev/mapper/3600a098038304179392b4d6c6e2f4b62 -4 20 -1 10 create

Initializing device /dev/mapper/3600a098038304179392b4d6c6e2f4b62
Creating version 2.1 header on device 4 (uuid:
ae17bd40-2bf9-495c-b59e-4cb5ecbf61ce)

Initializing 255 slots on device 4

Device /dev/mapper/3600a098038304179392b4d6c6e2f4b62 is initialized.

  5. Скопируйте файл конфигурации SBD в node2.

    vi /etc/sysconfig/sbd

SBD_DEVICE="/dev/mapper/3600a09803830417934d6c6e2f4b62"
SBD_PACEMAKER=yes
SBD_STARTMODE=always
SBD_DELAY_START=no
SBD_WATCHDOG_DEV=/dev/watchdog
SBD_WATCHDOG_TIMEOUT=15
SBD_TIMEOUT_ACTION=flush,reboot
SBD_MOVE_TO_ROOT_CGROUP=auto
SBD_OPTS=

scp /etc/sysconfig/sbd node2:/etc/sysconfig/sbd

  6. Убедитесь, что диск SBD виден с обоих узлов.

    sbd -d /dev/mapper/3600a098038304179392b4d6c6e2f4b62 dump

==Dumping header on disk /dev/mapper/3600a098038304179392b4d6c6e2f4b62

Header version : 2.1

UUID : ae17bd40-2bf9-495c-b59e-4cb5ecbf61ce

Number of slots : 255
Sector size : 512
Timeout (watchdog) : 5
Timeout (allocate) : 2
Timeout (loop) : 1
Timeout (msgwait) : 10

==Header on disk /dev/mapper/3600a098038304179392b4d6c6e2f4b62 is dumped

  7. Добавьте устройство SBD в файл конфигурации SBD.

    # SBD_DEVICE specifies the devices to use for exchanging sbd messages
# and to monitor. If specifying more than one path, use ";" as
# separator.
#

SBD_DEVICE="/dev/mapper/3600a098038304179392b4d6c6e2f4b62"
## Type: yesno
 Default: yes
 # Whether to enable the pacemaker integration.
SBD_PACEMAKER=yes

Инициализация кластера

В этой статье описано выполнение инициализации кластера. В этой статье используются те же два узла, sollabdsm35 и sollabdsm36, о которых шла речь в начале этой статьи.

  1. Задайте пароль пользователя кластера (все узлы).

    passwd hacluster

  2. Запустите PCS на всех системах.

    systemctl enable pcsd

  3. Остановите брандмауэр и отключите его (на всех узлах).

    systemctl disable firewalld

 systemctl mask firewalld

systemctl stop firewalld

  4. Запустите службу pcsd.

    systemctl start pcsd

  5. Запустите проверку подлинности кластера только из node1.

    pcs cluster auth sollabdsm35 sollabdsm36

    Username: hacluster

        Password:
        sollabdsm35.localdomain: Authorized
        sollabdsm36.localdomain: Authorized

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

    pcs cluster setup --start --name hana sollabdsm35 sollabdsm36

  7. Проверьте состояние кластера.

    pcs cluster status

Cluster name: hana

WARNINGS:

No stonith devices and `stonith-enabled` is not false

Stack: corosync

Current DC: sollabdsm35 (version 1.1.20-5.el7_7.2-3c4c782f70) -
partition with quorum

Last updated: Sat Nov 28 20:56:57 2020

Last change: Sat Nov 28 20:54:58 2020 by hacluster via crmd on
sollabdsm35

2 nodes configured

0 resources configured

Online: [ sollabdsm35 sollabdsm36 ]

No resources

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/disabled

  8. Если один узел не присоединяется к кластеру, проверьте, работает ли брандмауэр.

  9. Создание и включение устройства SBD

    pcs stonith create SBD fence_sbd devices=/dev/mapper/3600a098038303f4c467446447a

  10. Остановите кластер, перезапустите службы кластера (на всех узлах).

    pcs cluster stop --all

  11. Перезапустите службы кластера (на всех узлах).

    systemctl stop pcsd
systemctl stop pacemaker
systemctl stop corocync
systemctl enable sbd
systemctl start corosync
systemctl start pacemaker
systemctl start pcsd

  12. Corosync должен запустить службу SBD.

    systemctl status sbd

● sbd.service - Shared-storage based fencing daemon

Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor
preset: disabled)

Active: active (running) since Wed 2021-01-20 01:43:41 EST; 9min ago

  13. Перезапустите кластер (если он не запускается автоматически из pcsd).

    pcs cluster start –-all

sollabdsm35: Starting Cluster (corosync)...

sollabdsm36: Starting Cluster (corosync)...

sollabdsm35: Starting Cluster (pacemaker)...

sollabdsm36: Starting Cluster (pacemaker)...

  14. Включите параметры устройства ограничения.

    pcs stonith enable SBD --device=/dev/mapper/3600a098038304179392b4d6c6e2f4d65
pcs property set stonith-watchdog-timeout=20
pcs property set stonith-action=reboot

  15. Проверьте состояние нового кластера, теперь с одним ресурсом.

    pcs status

Cluster name: hana

Stack: corosync

Current DC: sollabdsm35 (version 1.1.16-12.el7-94ff4df) - partition
with quorum

Last updated: Tue Oct 16 01:50:45 2018

Last change: Tue Oct 16 01:48:19 2018 by root via cibadmin on
sollabdsm35

2 nodes configured

1 resource configured

Online: [ sollabdsm35 sollabdsm36 ]

Full list of resources:

SBD (stonith:fence_sbd): Started sollabdsm35

Daemon Status:

corosync: active/disabled

pacemaker: active/disabled

pcsd: active/enabled

sbd: active/enabled

[root@node1 ~]#

  16. Теперь должен запуститься таймер IPMI, и устройство /dev/watchdog должно быть открыто с помощью sbd.

    ipmitool mc watchdog get

Watchdog Timer Use: SMS/OS (0x44)

Watchdog Timer Is: Started/Running

Watchdog Timer Actions: Hard Reset (0x01)

Pre-timeout interval: 0 seconds

Timer Expiration Flags: 0x10

Initial Countdown: 20 sec

Present Countdown: 19 sec

[root@sollabdsm35 ~] lsof /dev/watchdog

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

sbd 117569 root 5w CHR 10,130 0t0 323812 /dev/watchdog

  17. Проверьте статус SBD.

    sbd -d /dev/mapper/3600a098038304445693f4c467446447a list

0 sollabdsm35 clear

1 sollabdsm36 clear

  18. Протестируйте ограждение SBD, вызвав падение ядра.

    • Вызовите сбой ядра.

      echo c > /proc/sysrq-trigger

System must reboot after 5 Minutes (BMC timeout) or the value which is
set as panic_wdt_timeout in the /etc/sysconfig/ipmi config file.

    • Вторым тестом является блокировка узла с помощью команд PCS.

      pcs stonith fence sollabdsm36

  19. Для остальных элементов кластеризации SAP HANA можно отключить fencing, установив следующие параметры:

  • набор свойств PCS stonith-enabled=false
  • Иногда проще не включать защиту во время настройки кластера, чтобы избежать неожиданных перезагрузок системы.
  • Для эффективного использования этот параметр должен иметь значение истины. Если для этого параметра не задано значение истины, кластер не будет поддерживаться.
  • набор свойств PCS stonith-enabled=true

Интеграция HANA в кластер

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

Способ по умолчанию и поддерживаемый способ — создание оптимизированного для высокой производительности сценария, в котором база данных может переключаться напрямую. В настоящем документе описывается только этот сценарий. В этом случае мы рекомендуем установить один кластер для системы QAS и отдельный кластер для системы PRD. Только в этом случае можно протестировать все компоненты перед переходом в рабочую среду.

Действия для настройки HSR

Режим репликации журналов Description
Синхронный режим в памяти (по умолчанию) Синхронный режим в памяти (mode=syncmem): запись журнала считается успешной, если данные были записаны в журнальный том первичной системы, а отправка журнала была подтверждена вторичным экземпляром после копирования в память. При потере подключения ко вторичной системе первичная система продолжает обработку транзакций и записывает изменения только на локальный диск. Потери данных происходят в тех случаях, когда первичная и вторичная системы одновременно испытывают сбой и вторичная система остается подключенной к сети, или когда выполняется перенаправление при отключенной от сети вторичной системе. Этот вариант обеспечивает лучшую производительность, так как нет необходимости ждать выполнения дисковых операций ввода-вывода на вторичном экземпляре, но он более уязвим относительно потери данных.
Синхронный Синхронный режим (mode=sync): запись журнала считается успешной, если данные записаны в журнальный том первичного и вторичного экземпляров. При потере подключения ко вторичной системе первичная система продолжает обработку транзакций и записывает изменения только на локальный диск. В рамках этого сценария потеря данных не происходит, если вторичная система подключена. Происходит потеря данных, когда выполняется перенаправление при отключенной вторичной системе. Кроме того, такой режим репликации может выполняться с полной синхронизацией. Это означает, что запись журнала успешно выполнена, если буфер журнала записан в файл журнала первичного и вторичного экземпляров. Кроме того, если вторичная система отключена (например, из-за сбоя в сети), первичные системы приостанавливают обработку транзакций до тех пор, пока не будет восстановлено подключение ко вторичной системе. В этом сценарии потеря данных не происходит. Вы можете настроить полную синхронизацию для системной репликации только с помощью параметра [system_replication]/enable_full_sync). Дополнительные сведения о включении параметра полной синхронизации см. в разделе о включении полной синхронизации для репликации системы.
Асинхронный Асинхронный режим (mode=async): первичная система отправляет буферы журнала повтора во вторичную систему асинхронно. Первичная система зафиксирует транзакцию, когда она будет записана в файл журнала первичной системы и отправлена во вторичную систему через сеть. При этом подтверждение от вторичной системы не ожидается. Этот параметр обеспечивает лучшую производительность, поскольку нет необходимости ждать выполнения операций ввода-вывода журнала во вторичной системе. Согласованность базы данных во всех службах во вторичной системе гарантируется. Однако она более уязвима к потере данных. Изменения данных могут быть потеряны при захвате контроля.

  1. Эти действия выполняются на узле node1 (основной).

    1. Убедитесь, что выбран нормальный режим журнала базы данных.

      
* su - hr2adm

* hdbsql -u system -p $YourPass -i 00 "select value from
"SYS"."M_INIFILE_CONTENTS" where key='log_mode'"



VALUE

"normal"

    2. Репликация системы SAP HANA будет работать только после выполнения исходного резервного копирования. При использовании следующей команды создается исходная резервная копия в каталоге /tmp/. Выберите подходящую файловую систему для резервного копирования базы данных.

      * hdbsql -i 00 -u system -p $YourPass "BACKUP DATA USING FILE
('/tmp/backup')"



Backup files were created

ls -l /tmp

total 2031784

-rw-r----- 1 hr2adm sapsys 155648 Oct 26 23:31 backup_databackup_0_1

-rw-r----- 1 hr2adm sapsys 83894272 Oct 26 23:31 backup_databackup_2_1

-rw-r----- 1 hr2adm sapsys 1996496896 Oct 26 23:31 backup_databackup_3_1

    3. Сделайте резервную копию всех контейнеров базы данных.

      * hdbsql -i 00 -u system -p $YourPass -d SYSTEMDB "BACKUP DATA USING
FILE ('/tmp/sydb')"

* hdbsql -i 00 -u system -p $YourPass -d SYSTEMDB "BACKUP DATA FOR HR2
USING FILE ('/tmp/rh2')"

    4. Включите процесс HSR в исходной системе.

      hdbnsutil -sr_enable --name=DC1

nameserver is active, proceeding ...

successfully enabled system as system replication source site

done.

    5. Проверьте состояние основной системы.

      hdbnsutil -sr_state

System Replication State


online: true

mode: primary

operation mode: primary

site id: 1

site name: DC1



is source system: true

is secondary/consumer system: false

has secondaries/consumers attached: false

is a takeover active: false



Host Mappings:

~~~~~~~~~~~~~~

Site Mappings:

~~~~~~~~~~~~~~

DC1 (primary/)

Tier of DC1: 1

Replication mode of DC1: primary

Operation mode of DC1:

done.

  2. Эти действия выполняются на узле node2 (второстепенный).

    1. Остановите базу данных.
    su – hr2adm

sapcontrol -nr 00 -function StopSystem
    1. Только для SAP HANA2.0: скопируйте файлы системы SAP HANA PKI SSFS_HR2.KEY и SSFS_HR2.DAT с основного узла на второстепенный.
    scp
root@node1:/usr/sap/HR2/SYS/global/security/rsecssfs/key/SSFS_HR2.KEY
/usr/sap/HR2/SYS/global/security/rsecssfs/key/SSFS_HR2.KEY



scp
root@node1:/usr/sap/HR2/SYS/global/security/rsecssfs/data/SSFS_HR2.DAT
/usr/sap/HR2/SYS/global/security/rsecssfs/data/SSFS_HR2.DAT
    1. Включите вторичный сайт как узел репликации.
    su - hr2adm

hdbnsutil -sr_register --remoteHost=node1 --remoteInstance=00
--replicationMode=syncmem --name=DC2



adding site ...

--operationMode not set; using default from global.ini/[system_replication]/operation_mode: logreplay

nameserver node2:30001 not responding.

collecting information ...

updating local ini files ...

done.
    1. Запустите базу данных.
    sapcontrol -nr 00 -function StartSystem
    1. Проверьте состояние базы данных.
    hdbnsutil -sr_state

~~~~~~~~~
System Replication State

online: true

mode: syncmem

operation mode: logreplay

site id: 2

site name: DC2

is source system: false

is secondary/consumer system: true

has secondaries/consumers attached: false

is a takeover active: false

active primary site: 1



primary primarys: node1

Host Mappings:



node2 -> [DC2] node2

node2 -> [DC1] node1



Site Mappings:



DC1 (primary/primary)

|---DC2 (syncmem/logreplay)



Tier of DC1: 1

Tier of DC2: 2



Replication mode of DC1: primary

Replication mode of DC2: syncmem

Operation mode of DC1: primary

Operation mode of DC2: logreplay



Mapping: DC1 -> DC2

done.
~~~~~~~~~~~~~~

  3. Кроме того, можно получить дополнительные сведения о состоянии репликации.

    ~~~~~
hr2adm@node1:/usr/sap/HR2/HDB00> python
/usr/sap/HR2/HDB00/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 | node1 | 30001 | nameserver | 1 | 1 | DC1 | node2 | 30001
| 2 | DC2 | YES | SYNCMEM | ACTIVE | |

| HR2 | node1 | 30007 | xsengine | 2 | 1 | DC1 | node2 | 30007 | 2 |
DC2 | YES | SYNCMEM | ACTIVE | |

| HR2 | node1 | 30003 | indexserver | 3 | 1 | DC1 | node2 | 30003 | 2
| DC2 | YES | SYNCMEM | ACTIVE | |


status system replication site "2": ACTIVE

overall system replication status: ACTIVE

Local System Replication State


mode: PRIMARY

site id: 1

site name: DC1

Описание режима репликации журнала

Дополнительные сведения о режиме репликации журналов см. в официальной документации SAP.

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

Чтобы гарантировать, что трафик репликации использует подходящую виртуальную локальную сеть для репликации, необходимо выполнить правильную настройку в global.ini. Если пропустить этот шаг, HANA будет использовать виртуальную локальную сеть Access для репликации, что может быть нежелательным.

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

  • Общедоступная сеть с адресами в диапазоне 10.0.1.*

  • Сеть для внутренней связи SAP HANA между узлами на каждом сайте: 192.168.1.*

  • Выделенная сеть для репликации системы: 10.5.1.*

В первом примере для параметра [system_replication_communication]listeninterface задано значение .global, и указаны только узлы соседнего сайта репликации.

В следующем примере для параметра [system_replication_communication]listeninterface задано значение .internal и указаны все узлы обоих сайтов.

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

Для репликации системы нет необходимости редактировать файл /etc/hosts, внутренние ("виртуальные") имена узлов должны сопоставляться с IP-адресами в файле global.ini для создания выделенной сети для репликации системы. Для этого используйте следующий синтаксис.

global.ini

разрешение имени хоста при репликации системы

<IP-адрес_сайт>=<имя-внутреннего-хоста_сайт>

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

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

Убедитесь, что выполнены следующие предварительные требования.

  • Кластер Pacemaker настроен в соответствии с инструкциями в документации и имеет исправное ограждение

  • Запуск SAP HANA при загрузке отключен на всех узлах кластера, поскольку запуском и остановкой будет управлять кластер

  • Процессы репликации системы SAP HANA и переключения с использованием инструментов SAP выполняются правильно между узлами кластера.

  • SAP HANA содержит учетную запись для мониторинга, которая может использоваться на обоих узлах кластера

  • Оба узла подписаны на каналы "Высокая доступность" и "RHEL для SAP HANA" (RHEL 6, RHEL 7).

  • Как правило, выполняйте все команды pcs только на узле, поскольку CIB будет автоматически обновляться из оболочки pcs.

  • Дополнительные сведения о политике кворума

Инструкции по настройке

  1. Настройте pcs.

    [root@node1 ~]# pcs property unset no-quorum-policy (optional – only if it was set before)
[root@node1 ~]# pcs resource defaults resource-stickiness=1000
[root@node1 ~]# pcs resource defaults migration-threshold=5000

  2. Выполните конфигурацию corosync. Для получения дополнительной информации см. Как настроить кластер высокой доступности RHEL 7 с использованием pacemaker и corosync.

    cat /etc/corosync/corosync.conf

totem {

version: 2

secauth: off

cluster_name: hana

transport: udpu

}



nodelist {

node {

ring0_addr: node1.localdomain

nodeid: 1

}



node {

ring0_addr: node2.localdomain

nodeid: 2

}

}



quorum {

provider: corosync_votequorum

two_node: 1

}



logging {

to_logfile: yes

logfile: /var/log/cluster/corosync.log

to_syslog: yes

}

  3. Создайте клонированный ресурс SAPHanaTopology.

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

    pcs resource create SAPHanaTopology_HR2_00 SAPHanaTopology SID=HR2 op start timeout=600 \
op stop timeout=300 \
op monitor interval=10 timeout=600 \
clone clone-max=2 clone-node-max=1 interleave=true
    Имя атрибута Описание
    SID Идентификатор системы SAP (SID) установки SAP HANA. Должен быть одинаковым для всех узлов.
    НомерЭкземпляра 2-значный идентификатор экземпляра SAP.

    • Состояние ресурса

      pcs resource show SAPHanaTopology_HR2_00

Clone: SAPHanaTopology_HR2_00-clone
 Meta Attrs: clone-max=2 clone-node-max=1 interleave=true
 Resource: SAPHanaTopology_HR2_00 (class=ocf provider=heartbeat type=SAPHanaTopology)
  Attributes: InstanceNumber=00 SID=HR2
  Operations: monitor interval=60 timeout=60 (SAPHanaTopology_HR2_00-monitor-interval-60)
              start interval=0s timeout=180 (SAPHanaTopology_HR2_00-start-interval-0s)
              stop interval=0s timeout=60 (SAPHanaTopology_HR2_00-stop-interval-0s)

  4. Создайте основной/второстепенный ресурс SAPHana.

    • Ресурс SAPHana отвечает за запуск, остановку и перемещение базы данных SAP HANA. Этот ресурс должен запускаться как основной/второстепенный ресурс кластера. Ресурс имеет следующие атрибуты.

      Имя атрибута Обязательное? Значение по умолчанию Описание
      SID Да Отсутствует Идентификатор системы SAP (SID) установки SAP HANA. Настройка должна быть одинаковой для всех узлов.
      НомерЭкземпляра Да ничего 2-значный идентификатор экземпляра SAP.
      PREFER_SITE_TAKEOVER нет да Следует ли для кластера предпочесть переключение на вторичный экземпляр вместо локального перезапуска основного? ("нет": предпочтителен локальный перезапуск; "да": предпочтительно переключение на удаленный сайт)
      АВТОМАТИЗИРОВАННЫЙ_РЕЕСТР нет ЛОЖЬ Следует ли регистрировать бывший основной экземпляр SAP HANA как резервный после переключения и DUPLICATE_PRIMARY_TIMEOUT? ("неверно": нет, требуется ручное вмешательство; "верно": да, бывший основной экземпляр будет зарегистрирован ресурсным агентом как второстепенный)
      Дублирование_Главный_Таймаут нет 7200 Разница во времени (в секундах) должна быть между основными метками времени, если возникает два варианта развития основной ситуации. Если разница во времени меньше временного интервала, кластер сохраняет один или оба экземпляра в состоянии "ОЖИДАНИЕ". Это дает администратору возможность реагировать на сбой. Бывший основной экземпляр, на котором произошел сбой, будет зарегистрирован после устранения временной разницы. После регистрации нового основного сервера все данные будут перезаписаны системной репликацией.

  5. Создайте ресурс HANA.

     pcs resource create SAPHana_HR2_00 SAPHana SID=HR2 InstanceNumber=00 PREFER_SITE_TAKEOVER=true DUPLICATE_PRIMARY_TIMEOUT=7200 AUTOMATED_REGISTER=true op start timeout=3600 \
 op stop timeout=3600 \
 op monitor interval=61 role="Slave" timeout=700 \
 op monitor interval=59 role="Master" timeout=700 \
 op promote timeout=3600 \
 op demote timeout=3600 \
 master meta notify=true clone-max=2 clone-node-max=1 interleave=true

 pcs resource show SAPHana_HR2_00-primary

 Primary: SAPHana_HR2_00-primary
  Meta Attrs: clone-max=2 clone-node-max=1 interleave=true notify=true
  Resource: SAPHana_HR2_00 (class=ocf provider=heartbeat type=SAPHana)
   Attributes: AUTOMATED_REGISTER=false DUPLICATE_PRIMARY_TIMEOUT=7200 InstanceNumber=00 PREFER_SITE_TAKEOVER=true SID=HR2
   Operations: demote interval=0s timeout=320 (SAPHana_HR2_00-demote-interval-0s)
               monitor interval=120 timeout=60 (SAPHana_HR2_00-monitor-interval-120)
               monitor interval=121 role=Secondary timeout=60 (SAPHana_HR2_00-monitor-
               interval-121)
               monitor interval=119 role=Primary timeout=60 (SAPHana_HR2_00-monitor-
               interval-119)
               promote interval=0s timeout=320 (SAPHana_HR2_00-promote-interval-0s)
               start interval=0s timeout=180 (SAPHana_HR2_00-start-interval-0s)
               stop interval=0s timeout=240 (SAPHana_HR2_00-stop-interval-0s)

 crm_mon -A1
 ....

 2 nodes configured

 5 resources configured

 Online: [ node1.localdomain node2.localdomain ]

 Active resources:

 .....

 Node Attributes:

 * Node node1.localdomain:

 + hana_hr2_clone_state : PROMOTED

 + hana_hr2_remoteHost : node2

 + hana_hr2_roles : 4:P:primary1:primary:worker:primary

 + hana_hr2_site : DC1

 + hana_hr2_srmode : syncmem

 + hana_hr2_sync_state : PRIM

 + hana_hr2_version : 2.00.033.00.1535711040

 + hana_hr2_vhost : node1

 + lpa_hr2_lpt : 1540866498

 + primary-SAPHana_HR2_00 : 150

 * Node node2.localdomain:

 + hana_hr2_clone_state : DEMOTED

 + hana_hr2_op_mode : logreplay

 + hana_hr2_remoteHost : node1

 + hana_hr2_roles : 4:S:primary1:primary:worker:primary

 + hana_hr2_site : DC2

 + hana_hr2_srmode : syncmem

 + hana_hr2_sync_state : SOK

 + hana_hr2_version : 2.00.033.00.1535711040

 + hana_hr2_vhost : node2

 + lpa_hr2_lpt : 30

 + primary-SAPHana_HR2_00 : 100

  6. Создайте ресурс с виртуальным IP-адресом.

    Кластер будет содержать виртуальный IP-адрес для доступа к основному экземпляру SAP HANA. Ниже приведен пример команды для создания ресурса IPaddr2 с IP-адресом 10.7.0.84/24.

     pcs resource create vip_HR2_00 IPaddr2 ip="10.7.0.84"
 pcs resource show vip_HR2_00

 Resource: vip_HR2_00 (class=ocf provider=heartbeat type=IPaddr2)

     Attributes: ip=10.7.0.84

     Operations: monitor interval=10s timeout=20s
 (vip_HR2_00-monitor-interval-10s)

     start interval=0s timeout=20s (vip_HR2_00-start-interval-0s)

     stop interval=0s timeout=20s (vip_HR2_00-stop-interval-0s)

  7. Создайте ограничения.

    • Для обеспечения правильной работы необходимо убедиться, что ресурсы SAPHanaTopology запущены перед запуском ресурсов SAPHana, а также что виртуальный IP-адрес присутствует на узле, на котором запущен основной ресурс SAPHana. Для этого необходимо создать следующие 2 ограничения. 
      pcs constraint order SAPHanaTopology_HR2_00-clone then SAPHana_HR2_00-primary symmetrical=false
pcs constraint colocation add vip_HR2_00 with primary SAPHana_HR2_00-primary 2000

Тестирование перемещения ресурса SAPHana на другой узел вручную

(Перехват SAP Hana кластером)

Чтобы протестировать перенаправление ресурса SAPHana с одного узла на другой, используйте команду, приведенную ниже. Обратите внимание, что параметр --primary не следует использовать при выполнении следующей команды, поскольку ресурс SAPHana работает по-другому на внутреннем уровне.

pcs resource move SAPHana_HR2_00-primary

После каждого вызова команды перемещения ресурса pcs кластер создает ограничения расположения для перемещения ресурса. Эти ограничения необходимо удалить, чтобы обеспечить автоматическое переключение в будущем. Чтобы их удалить, можно использовать следующую команду.

pcs resource clear SAPHana_HR2_00-primary
crm_mon -A1
Node Attributes:
    * Node node1.localdomain:
    + hana_hr2_clone_state : DEMOTED
    + hana_hr2_remoteHost : node2
    + hana_hr2_roles : 2:P:primary1::worker:
    + hana_hr2_site : DC1
    + hana_hr2_srmode : syncmem
    + hana_hr2_sync_state : PRIM
    + hana_hr2_version : 2.00.033.00.1535711040
    + hana_hr2_vhost : node1
    + lpa_hr2_lpt : 1540867236
    + primary-SAPHana_HR2_00 : 150
    * Node node2.localdomain:
    + hana_hr2_clone_state : PROMOTED
    + hana_hr2_op_mode : logreplay
    + hana_hr2_remoteHost : node1
    + hana_hr2_roles : 4:S:primary1:primary:worker:primary
    + hana_hr2_site : DC2
    + hana_hr2_srmode : syncmem
    + hana_hr2_sync_state : SOK
    + hana_hr2_version : 2.00.033.00.1535711040
    + hana_hr2_vhost : node2
    + lpa_hr2_lpt : 1540867311
    + primary-SAPHana_HR2_00 : 100

  • Выполните вход в HANA для проверки.

    • узел нижнего уровня:

      hdbsql -i 00 -u system -p $YourPass -n 10.7.0.82

result:

        * -10709: Connection failed (RTE:[89006] System call 'connect'
failed, rc=111:Connection refused (10.7.0.82:30015))

    • Повышенный хост:

      hdbsql -i 00 -u system -p $YourPass -n 10.7.0.84

Welcome to the SAP HANA Database interactive terminal.



Type: \h for help with commands

\q to quit



hdbsql HR2=>




DB is online

При использовании параметра AUTOMATED_REGISTER=false переключаться вперед и назад невозможно.

Если для этого параметра задано значение ложь, необходимо перерегистрировать узел.

hdbnsutil -sr_register --remoteHost=node2 --remoteInstance=00 --replicationMode=syncmem --name=DC1

Теперь узел node2, который был основным, действует как второстепенный узел.

Установите для этого параметра значение true, чтобы автоматизировать регистрацию пониженного хоста.

pcs resource update SAPHana_HR2_00-primary AUTOMATED_REGISTER=true
pcs cluster node clear node1

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

Ссылки

  1. Автоматическая репликация системы SAP HANA при вертикальном масштабировании в кластере Pacemaker
  2. Политики поддержки для кластеров с высоким уровнем доступности RHEL — управление SAP HANA в кластере
  3. Настройка Pacemaker в RHEL в Azure — Виртуальные машины Azure
  4. Управление крупными экземплярами HANA в Azure с помощью портала Azure — Виртуальные машины Azure