Развертывание SAP ASCS/ERS с помощью виртуальных машин SAP HANA с высоким уровнем доступности на RHEL

В этой статье описывается, как установить и настроить SAP HANA вместе с ABAP SAP Central Services (ASCS)/SAP Central Services (SCS) и экземплярами сервера репликации enqueue (ERS) в одном кластере с высоким уровнем доступности, работающем в Red Hat Enterprise Linux (RHEL).

Ссылки

Обзор

В этой статье описывается сценарий оптимизации затрат, в котором развертываются экземпляры SAP HANA, SAP ASCS/SCS и SAP ERS в той же настройке высокой доступности. Чтобы свести к минимуму количество виртуальных машин для одной системы SAP, необходимо установить SAP ASCS/SCS и SAP ERS на тех же узлах, где выполняется SAP HANA. При настройке SAP HANA в настройке кластера высокой доступности необходимо также управлять SAP ASCS/SCS и SAP ERS. Конфигурация в основном является дополнением к уже настроенной настройке кластера SAP HANA. В этой настройке sap ASCS/SCS и SAP ERS устанавливаются в имя виртуального узла, а его каталог экземпляра управляется кластером.

Представленная архитектура демонстрирует NFS в Файлы Azure или Azure NetApp Files для каталога экземпляров с высоким уровнем доступности для установки.

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

Имя экземпляра Номер экземпляра Имя виртуального узла Виртуальный IP-адрес (порт пробы)
БАЗА ДАННЫХ SAP HANA 03 saphana 10.66.0.13 (62503)
Центральные службы SAP ABAP (ASCS) 00 sapascs 10.66.0.20 (62000)
Сервер постановки в очередь для репликации (ERS) 01 sapers 10.66.0.30 (62101)
Системный идентификатор SAP HANA HN1 --- ---
Идентификатор системы SAP NW1 --- ---

Примечание.

Установите экземпляры диалоговых окон SAP (PAS и AAS) на отдельных виртуальных машинах.

Diagram that shows the architecture of an SAP HANA, SAP ASCS/SCS, and ERS installation within the same cluster.

Важные рекомендации по оптимизации затрат

  • Экземпляры диалоговых окон SAP (PAS и AAS) (например , sapa01 и sapa02) должны быть установлены на отдельных виртуальных машинах. Установите SAP ASCS и ERS с именами виртуальных узлов. Дополнительные сведения о назначении имени виртуального узла виртуальной машине см. в блоге об использовании имен виртуальных узлов SAP с Linux в Azure.
  • При развертывании HANA, ASCS/SCS и ERS в той же настройке кластера количество экземпляров базы данных HANA, ASCS/SCS и ERS должно отличаться.
  • Определите размер SKU виртуальных машин в соответствии с рекомендациями по выбору размера. Необходимо учитывать поведение кластера, в котором несколько экземпляров SAP (HANA DB, ASCS/SCS и ERS) могут выполняться на одной виртуальной машине, если другая виртуальная машина в кластере недоступна.
  • Для установки экземпляров SAP ASCS и ERS можно использовать другое хранилище (например, Azure NetApp Files или NFS в Файлы Azure).

    Примечание.

    Для систем SAP J2EE размещение /usr/sap/<SID>/J<nr> в NFS в службе Файлы Azure не поддерживается. Файловые системы базы данных, такие как /hana/data и /hana/log, не поддерживаются в NFS на Файлы Azure.

  • Чтобы установить дополнительные серверы приложений на отдельных виртуальных машинах, можно использовать общие папки NFS или локальный управляемый диск для файловой системы каталогов экземпляра. Если вы устанавливаете больше серверов приложений для системы SAP J2EE, /usr/sap/<SID>/J<nr> в NFS на Файлы Azure не поддерживается.
  • Рекомендации по Файлы Azure и рекомендации по Azure NetApp Files см. в NFS, так как к этой настройке применяются те же рекомендации.

Необходимые компоненты

Конфигурация, описанная в этой статье, является дополнением к уже настроенной настройке кластера SAP HANA. В этой конфигурации экземпляр SAP ASCS/SCS и ERS устанавливаются на имя виртуального узла. Каталог экземпляра управляется кластером.

Установите базу данных HANA и настройте систему HANA реплика tion (HSR) и кластер Pacemaker, выполнив действия по обеспечению высокого уровня доступности SAP HANA на виртуальных машинах Azure на виртуальных машинах Azure в Red Hat Enterprise Linux или высокой доступности масштабирования SAP HANA с помощью Azure NetApp Files в Red Hat Enterprise Linux в зависимости от того, какой вариант хранения вы используете.

После установки, настройки и настройки кластера HANA выполните следующие действия, чтобы установить экземпляры ASCS и ERS.

Настройка Azure Load Balancer для ASCS и ERS

В этой статье предполагается, что вы уже настроили подсистему балансировки нагрузки для настройки кластера HANA, как описано в разделе "Настройка Azure Load Balancer". В том же экземпляре Azure Load Balancer выполните следующие действия, чтобы создать дополнительные интерфейсные IP-адреса и правила балансировки нагрузки для ASCS и ERS.

  1. Откройте внутреннюю подсистему балансировки нагрузки, созданную для настройки кластера SAP HANA.
  2. Конфигурация внешнего IP-адреса: создайте два внешних IP-адреса, один для ASCS и другой для ERS (например, 10.66.0.20 и 10.66.0.30).
  3. Серверный пул: этот пул остается неизменным, так как мы развертываем ASCS и ERS в одном серверном пуле.
  4. Правила для входящего трафика: создайте два правила балансировки нагрузки, один для ASCS и другой для ERS. Выполните те же действия для обоих правил балансировки нагрузки.
  5. Внешний IP-адрес: выберите внешний IP-адрес.
    1. Серверный пул: выберите внутренний пул.
    2. Порты высокой доступности: выберите этот параметр.
    3. Протокол. Выберите TCP.
    4. Проба работоспособности: создайте пробу работоспособности со следующими сведениями (применяется как для ASCS, так и для ERS):
      1. Протокол. Выберите TCP.
      2. Порт: например, 620<экземпляров no.> для ASCS и 621<экземпляра no. для ERS.>
      3. Интервал. Введите 5.
      4. Пороговое значение пробы: введите 2.
    5. Время ожидания простоя (минуты): введите 30.
    6. Включите плавающий IP-адрес: выберите этот параметр.

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

Внимание

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

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

Внимание

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

Настройка SAP ASCS/SCS и ERS

На основе хранилища выполните действия, описанные в следующих статьях, чтобы настроить SAPInstance ресурс для экземпляра SAP ASCS/SCS и SAP ERS в кластере.

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

Тщательно протестируйте кластер Pacemaker: