Руководство по развертыванию платформы SAP BusinessObjects BI для Linux в Azure

В этой статье описана стратегия развертывания платформы SAP BusinessObjects BI (BOBI) в Azure для Linux. В этом примере в качестве каталога установки настраиваются две виртуальные машины с управляемыми дисками SSD (цен. категория "Премиум"). База данных Azure для MySQL используется в качестве базы данных CMS, а Azure NetApp Files (ANF) для сервера репозитория файлов совместно используется на обоих серверах. Веб-приложение Java Tomcat по умолчанию и приложение платформы BI устанавливаются вместе на обеих виртуальных машинах. Для балансировки нагрузки запросов пользователей используется Шлюз приложений Azure, в котором доступны собственные возможности разгрузки TLS/SSL.

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

Diagram of the SAP BOBI deployment on Azure for Linux

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

  • платформа SAP BusinessObjects 4.3;
  • SUSE Linux Enterprise Server 12 SP5
  • База данных Azure для MySQL (версия 8.0.15);
  • Соединитель API MySQL для C: libmysqlclient (версия: 6.1.11).
Файловая система Description Размер (ГБ) Ответственное лицо Групповой Хранилище
/usr/sap Файловая система для установки экземпляра SAP BOBI, веб-приложения Tomcat по умолчанию и драйверов базы данных (при необходимости). Рекомендации по выбору размера SAP bl1adm sapsys Управляемый диск SSD (цен. категория "Премиум")
/usr/sap/frsinput Каталог подключения предназначен для общих файлов на всех узлах BOBI. Он будет использоваться в качестве каталога репозитория входных файлов. Бизнес-потребности bl1adm sapsys Azure NetApp Files
/usr/sap/frsoutput Каталог подключения предназначен для общих файлов на всех узлах BOBI. Он будет использоваться в качестве каталога репозитория выходных файлов. Бизнес-потребности bl1adm sapsys Azure NetApp Files

Важно!

Хотя настройка платформы SAP BusinessObjects объясняется с помощью Azure NetApp Files, вы можете использовать NFS в Файлы Azure в качестве репозитория входных и выходных файлов.

Развертывание виртуальной машины Linux на портале Azure

Благодаря инструкциям из этого раздела мы создадим две виртуальные машины с помощью образа операционной системы Linux для платформы SAP BOBI. Ниже приведены общие действия по созданию виртуальных машин.

  1. Создайте группу ресурсов.

  2. Создайте виртуальную сеть.

    • Не используйте одну подсеть для всех служб Azure в развертывании платформы SAP BI. В соответствии с архитектурой платформы SAP BI необходимо создать несколько подсетей. В этом развертывании вы создадите три подсети: по одной для приложения, хранилища репозитория файлов и Шлюза приложений.
    • В Azure Шлюз приложений и Azure NetApp Files всегда должны находиться в отдельной подсети. Дополнительные сведения см. в статьях Общие сведения о настройке Шлюза приложений и Рекомендации по планированию сети Azure NetApp Files.
  3. Выберите подходящие варианты доступности в зависимости от предпочитаемой конфигурации системы в регионе Azure, в том случае, если она охватывает зоны, находится в пределах одной зоны или работает в регионе без зоны.

  4. Создайте виртуальную машину 1 (azusbosl1).

  5. Создайте виртуальную машину 2 (azusbosl2).

  6. Добавьте один диск SSD (цен. категория "Премиум"). Он будет использоваться в качестве каталога установки SAP BOBI.

Подготовка 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 и виртуальные машины, к которым будут подключаться ресурсы Azure NetApp Files, должны быть развернуты в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure.

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

  2. Настройте пул емкости Azure NetApp Files. В архитектуре платформы SAP BI, представленной в этой статье, используется один пул емкости Azure NetApp Files на уровне обслуживания "Премиум". Для сервера репозитория файлов SAP BI в Azure рекомендуется использовать Azure NetApp Files с уровнем обслуживания "Премиум" или "Ультра".

  3. Делегируйте подсеть в Azure NetApp Files.

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

    Вы можете развернуть тома NFS 3 или NFS 4.1, так как для платформы SAP BOBI поддерживаются оба эти протокола. Разверните тома в соответствующих подсетях Azure NetApp Files. IP-адреса томов Azure NetApp Files назначаются автоматически.

Учтите, что ресурсы Azure NetApp Files и виртуальные машины Azure должны находиться в одной виртуальной сети Azure или в одноранговых виртуальных сетях Azure. Например, azusbobi-frsinput и azusbobi-frsoutput — это имена томов, а nfs://10.31.2.4/azusbobi-frsinput и nfs://10.31.2.4/azusbobi-frsoutput — пути к томам Azure NetApp Files.

  • Том azusbobi-frsinput (nfs://10.31.2.4/azusbobi-frsinput).
  • Том azusbobi-frsoutput (nfs://10.31.2.4/azusbobi-frsoutput).

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

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

  • Минимальный размер пула емкости равен 4 ТиБ. Размер пула емкости можно увеличивать с шагом 1 ТиБ.
  • Минимальный размер тома составляет 100 ГиБ.
  • Azure NetApp Files и все виртуальные машины, к которым будут подключаться тома Azure NetApp Files, должны быть развернуты в одной виртуальной сети Azure или в одноранговых виртуальных сетях в одном регионе. Поддерживается доступ к Azure NetApp Files через пиринг виртуальных сетей в том же регионе. Доступ к NetApp Azure Files через глобальный пиринг пока не поддерживается.
  • В выбранной виртуальной сети должна быть подсеть, делегированная службе Azure NetApp Files.
  • Пропускная способность и характеристики производительности тома Azure NetApp являются функцией квоты тома и уровня обслуживания, как описано в статье Уровни обслуживания для Azure NetApp Files. При определении размера томов SAP в Azure NetApp убедитесь, что полученная пропускная способность соответствует требованиям к приложению.
  • Azure NetApp Files предлагает политику экспорта, которая позволяет управлять разрешенными клиентами, типом доступа (например, чтение и запись или доступ только для чтения).
  • Azure NetApp Files пока еще не поддерживает зоны. В настоящее время эта функция развернута не во всех зонах доступности региона Azure. Учитывайте возможную задержку в некоторых регионах Azure.
  • Тома Azure NetApp Files можно развернуть в виде томов NFSv3 или NFSv4.1. Для приложений платформы SAP BI поддерживаются оба протокола.

Настройка файловых систем на серверах Linux

Во всех действиях этого раздела используются следующий префикс.

[A]: этот шаг применяется ко всем узлам.

Форматирование и подключение файловой системы SAP

  1. [A]: выведите список всех подключенных дисков.

    sudo lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda      8:0    0   30G  0 disk
    ├─sda1   8:1    0    2M  0 part
    ├─sda2   8:2    0  512M  0 part /boot/efi
    ├─sda3   8:3    0    1G  0 part /boot
    └─sda4   8:4    0 28.5G  0 part /
    sdb      8:16   0   32G  0 disk
    └─sdb1   8:17   0   32G  0 part /mnt
    sdc      8:32   0  128G  0 disk
    sr0     11:0    1  628K  0 rom  
    # Premium SSD of 128 GB is attached to virtual machine, whose device name is sdc
    
  2. [A]: отформатируйте блочное устройство для /usr/sap.

    sudo mkfs.xfs /dev/sdc
    
  3. [A]: создайте каталог подключения.

    sudo mkdir -p /usr/sap
    
  4. [A]: получите UUID блочного устройства.

    sudo blkid
    
    # It will display information about block device. Copy UUID of the formatted block device
    
    /dev/sdc: UUID="0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b" TYPE="xfs"
    
  5. [A]: сохраните записи подключения файловой системы в /etc/fstab.

    sudo echo "UUID=0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b /usr/sap xfs defaults,nofail 0 2" >> /etc/fstab
    
  6. [A]: подключите файловую систему.

    sudo mount -a
    
    sudo df -h
    
    Filesystem                     Size  Used Avail Use% Mounted on
    devtmpfs                       7.9G  8.0K  7.9G   1% /dev
    tmpfs                          7.9G   82M  7.8G   2% /run
    tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
    /dev/sda4                       29G  1.8G   27G   6% /
    tmpfs                          1.6G     0  1.6G   0% /run/user/1000
    /dev/sda3                     1014M   87M  928M   9% /boot
    /dev/sda2                      512M  1.1M  511M   1% /boot/efi
    /dev/sdb1                       32G   49M   30G   1% /mnt
    /dev/sdc                       128G   29G  100G  23% /usr/sap
    

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

  1. [A]: создайте каталоги подключения.

    sudo mkdir -p /usr/sap/frsinput
    sudo mkdir -p /usr/sap/frsoutput
    
  2. [A]: настройте клиентскую ОС для поддержки подключения NFS 4.1 (применимо только при использовании NFS 4.1).

    Если вы используете тома Azure NetApp Files с протоколом NFS 4.1, выполните приведенную ниже настройку на всех виртуальных машинах, на которых необходимо подключить тома Azure NetApp Files в формате NFS 4.1.

    На этом шаге необходимо проверить параметры домена NFS. Убедитесь, что домен настроен в качестве домена Azure NetApp Files по умолчанию, т. е. defaultv4iddomain.com, а для сопоставления установлено значение nobody.

    sudo cat /etc/idmapd.conf
    # Example
    [General]
    Domain = defaultv4iddomain.com
    [Mapping]
    Nobody-User = nobody
    Nobody-Group = nobody
    

    Важно!

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

    Проверкаnfs4_disable_idmapping. Оно должно иметь значение Y. Чтобы создать структуру каталогов, в которой находится параметр nfs4_disable_idmapping, выполните команду mount. Вы не сможете вручную создать каталог в /sys/modules, так как доступ зарезервирован для ядра или драйверов.

    # 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 -t nfs -o sec=sys,vers=4.1 10.31.2.4:/azusbobi-frsinput /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
    
  3. [A]: добавьте записи подключения.

    Если вы используете NFS 3:

    sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab
    sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab
    

    Если вы используете NFS 4.1:

    sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
    sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
    
  4. [A]: подключите тома NFS.

    sudo mount -a
    
    sudo df -h
    
    Filesystem                     Size  Used Avail Use% Mounted on
    devtmpfs                       7.9G  8.0K  7.9G   1% /dev
    tmpfs                          7.9G   82M  7.8G   2% /run
    tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
    /dev/sda4                       29G  1.8G   27G   6% /
    tmpfs                          1.6G     0  1.6G   0% /run/user/1000
    /dev/sda3                     1014M   87M  928M   9% /boot
    /dev/sda2                      512M  1.1M  511M   1% /boot/efi
    /dev/sdb1                       32G   49M   30G   1% /mnt
    /dev/sdc                       128G   29G  100G  23% /usr/sap
    10.31.2.4:/azusbobi-frsinput   101T   18G  100T   1% /usr/sap/frsinput
    10.31.2.4:/azusbobi-frsoutput  100T  512K  100T   1% /usr/sap/frsoutput
    

Настройка Базы данных Azure для MySQL

В этом разделе описывается, как подготовить Базу данных Azure для MySQL с помощью портала Azure. В нем также приводятся инструкции по созданию базы данных CMS и базы данных аудита для платформы SAP BOBI, а также учетной записи пользователя для доступа к базе данных.

Приведенные инструкции применимы только в том случае, если вы используете Базу данных Azure для MySQL. Инструкции для других баз данных можно найти в документации по SAP или конкретной базе данных.

Создание базы данных

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

  • Выберите для Базы данных Azure для MySQL регион, в котором работают серверы приложений платформы SAP BI.

  • С помощью матрицы доступности продуктов (PAM) для SAP BI выберите поддерживаемую версию базы данных, соответствующую вашей версии SAP BOBI.

  • В области Вычисления и хранилище щелкните Настроить сервер и выберите соответствующую ценовую категорию, исходя из размера выходных данных.

  • Автоматическое увеличение хранилища включено по умолчанию. Помните, что объем хранилища можно только увеличить, но не уменьшить.

  • По умолчанию срок хранения резервных копий составляет 7 дней. При желании можно задать срок хранения до 35 дней.

  • Резервные копии Базы данных Azure для MySQL по умолчанию являются локально избыточными. Чтобы включить резервное копирование сервера в геоизбыточном хранилище, выберите Геоизбыточное хранилище в разделе параметров избыточности резервного копирования.

Важно!

Изменение параметров избыточности резервного копирования после создания сервера не поддерживается.

Примечание.

Возможность "Приватный канал" доступна только для серверов Базы данных Azure для MySQL ценовых категорий "Общего назначения" или "Оптимизированная для операций в памяти". Убедитесь в том, что сервер базы данных принадлежит к одной из этих ценовых категорий.

С помощью инструкций из этого раздела вы создадите приватный канал, который позволит виртуальным машинам SAP BOBI подключаться к службе Базы данных Azure для MySQL через частную конечную точку. Служба "Приватный канал Azure" предоставляет службы Azure в частной виртуальной сети.

  1. Выберите базу данных, созданную в предыдущем разделе.
  2. Перейдите в раздел Безопасность>Подключения к частной конечной точке.
  3. В разделе Подключения к частной конечной точке выберите пункт Частная конечная точка.
  4. Выберите пункт Подписка>Группа ресурсов>Расположение.
  5. Введите имя частной конечной точки.
  6. В разделе "Ресурс" укажите следующее:
    • Тип ресурса: Microsoft.DBforMySQL/servers.
    • Ресурс: база данных MySQL, созданная в предыдущем разделе.
    • Целевой подресурс: mysqlServer.
  7. В разделе Сети выберите виртуальную сеть и подсеть, в которой развернуто приложение SAP BOBI.

    Примечание.

    Если для подсети включена группа безопасности сети (NSG), группа будет отключена только для частных конечных точек в этой подсети, но по-прежнему будет применяться для других ресурсов.

  8. Примите значение По умолчанию (да) для параметра Интеграция с частной зоной DNS.
  9. Выберите свою частную зону DNS из раскрывающегося списка.
  10. Нажмите кнопку Просмотр и создание и создайте частную конечную точку.

Дополнительные сведения см. в статье Приватный канал для Базы данных Azure для MySQL.

Создание базы данных CMS и аудита

  1. Скачайте среду MySQL Workbench с веб-сайта MySQL и установите ее. Обязательно установите MySQL Workbench на сервере, который имеет доступ к Базе данных Azure для MySQL.

  2. Подключитесь к серверу с помощью MySQL Workbench. Следуйте инструкциям из раздела Получение сведений о подключении. Если проверка подключения пройдет успешно, появится приведенное ниже сообщение.

    Screenshot of message in MySQL Workbench.

  3. На вкладке "SQL-запрос" выполните приведенный ниже запрос, чтобы создать схему для базы данных CMS и базы данных аудита.

    # Here cmsbl1 is the database name of CMS database. You can provide the name you want for CMS database.
    CREATE SCHEMA `cmsbl1` DEFAULT CHARACTER SET utf8;
    
    # auditbl1 is the database name of Audit database. You can provide the name you want for CMS database.
    CREATE SCHEMA `auditbl1` DEFAULT CHARACTER SET utf8;
    
  4. Создайте учетную запись пользователя для подключения к схеме.

    # Create a user that can connect from any host, use the '%' wildcard as a host part
    CREATE USER 'cmsadmin'@'%' IDENTIFIED BY 'password';
    CREATE USER 'auditadmin'@'%' IDENTIFIED BY 'password';
    
    # Grant all privileges to a user account over a specific database:
    GRANT ALL PRIVILEGES ON cmsbl1.* TO 'cmsadmin'@'%' WITH GRANT OPTION;
    GRANT ALL PRIVILEGES ON auditbl1.* TO 'auditadmin'@'%' WITH GRANT OPTION;
    
    # Following any updates to the user privileges, be sure to save the changes by issuing the FLUSH PRIVILEGES
    FLUSH PRIVILEGES;
    
  5. Проверьте права и роли учетной записи пользователя MySQL.

    USE sys;
    SHOW GRANTS for 'cmsadmin'@'%';
    +------------------------------------------------------------------------+
    | Grants for cmsadmin@%                                                  |
    +------------------------------------------------------------------------+
    | GRANT USAGE ON *.* TO `cmsadmin`@`%`                                   |
    | GRANT ALL PRIVILEGES ON `cmsbl1`.* TO `cmsadmin`@`%` WITH GRANT OPTION |
    +------------------------------------------------------------------------+
    
    USE sys;
    SHOW GRANTS FOR 'auditadmin'@'%';
    +----------------------------------------------------------------------------+
    | Grants for auditadmin@%                                                    |
    +----------------------------------------------------------------------------+
    | GRANT USAGE ON *.* TO `auditadmin`@`%`                                     |
    | GRANT ALL PRIVILEGES ON `auditbl1`.* TO `auditadmin`@`%` WITH GRANT OPTION |
    +----------------------------------------------------------------------------+
    

Установка соединителя API MySQL для C на сервере Linux

Для доступа к базе данных серверу приложений SAP BOBI требуются драйверы клиента базы данных. Для доступа к базам данных CMS и аудита необходимо использовать соединитель API MySQL для C для Linux. Подключение ODBC к базе данных CMS не поддерживается. В этом разделе приводятся инструкции по настройке соединителя API MySQL для C в Linux.

  1. Ознакомьтесь со статьей Совместимость драйверов и инструментов управления MySQL с Базой данных Azure для MySQL. Проверьте наличие драйвера соединителя MySQL для C (libmysqlclient) в этой статье.

  2. Скачайте соответствующие драйверы, перейдя по этой ссылке.

  3. Выберите операционную систему и скачайте пакет RPM общего компонента соединителя MySQL. В этом примере используется версия соединителя mysql-connector-c-shared-6.1.11.

  4. Установите этот соединитель во все экземпляры приложения SAP BOBI.

    # Install rpm package
    SLES: sudo zypper install <package>.rpm
    RHEL: sudo yum install <package>.rpm
    
  5. Проверьте путь к файлу libmysqlclient.so.

    # Find the location of libmysqlclient.so file
    whereis libmysqlclient
    
    # sample output
    libmysqlclient: /usr/lib64/libmysqlclient.so
    
  6. Задайте для LD_LIBRARY_PATH каталог /usr/lib64 для учетной записи пользователя, которая будет использоваться для установки.

    # This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
    vi /home/bl1adm/.bashrc
    
    export LD_LIBRARY_PATH=/usr/lib64
    

Подготовка сервера

Во всех действиях этого раздела используются следующий префикс.

[A]: этот шаг применяется ко всем узлам.

  1. [A]: исходя из варианта Linux (SLES или RHEL), необходимо задать параметры ядра и установить необходимые библиотеки. См. раздел "Требования к системе" в руководстве по установке платформы бизнес-аналитики для Unix.

  2. [A]: убедитесь, что часовой пояс на компьютере настроен правильно. Обратитесь к разделу Дополнительные требования для Unix и Linux в руководстве по установке.

  3. [A]: создайте учетную запись пользователя (bl1adm) и группу (sapsys), в которой могут выполняться фоновые процессы программного обеспечения. Используйте эту учетную запись для установки и запуска программного обеспечения. Ей не требуются привилегии root.

  4. [A]: задайте для окружения учетной записи пользователя (bl1adm) поддерживаемый языковой стандарт UTF-8 и убедитесь, что программное обеспечение консоли поддерживает кодировки UTF-8. Чтобы убедиться, что операционная система использует правильный языковой стандарт, задайте для переменных среды LC_ALL и LANG предпочитаемый язык в окружении пользователя (bl1adm).

    # This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
    vi /home/bl1adm/.bashrc
    
    export LANG=en_US.utf8
    export LC_ALL=en_US.utf8
    
  5. [A]: настройте учетную запись пользователя (bl1adm).

    # Set ulimit for bl1adm to unlimited
    root@azusbosl1:~> ulimit -f unlimited bl1adm
    root@azusbosl1:~> ulimit -u unlimited bl1adm
    
    root@azusbosl1:~> su - bl1adm
    bl1adm@azusbosl1:~> ulimit -a
    
    core file size          (blocks, -c) unlimited
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 63936
    max locked memory       (kbytes, -l) 64
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 1024
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 8192
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) unlimited
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited
    
  6. Скачайте носители для платформы SAP BusinessObjects BI из SAP Service Marketplace и извлеките их содержимое.

Установка

Проверьте языковой стандарт для учетной записи пользователя bl1adm на сервере.

bl1adm@azusbosl1:~> locale
LANG=en_US.utf8
LC_ALL=en_US.utf8

Перейдите на носитель платформы SAP BOBI и выполните приведенную ниже команду от имени пользователя bl1adm.

./setup.sh -InstallDir /usr/sap/BL1

Следуйте указаниям по установке платформы SAP BOBI для Unix, относящимся к вашей версии. Вот несколько моментов, которые нужно учитывать при установке платформы SAP BOBI.

  • В разделе Configure Product Registration (Настройка регистрации продукта) вы можете использовать временный ключ лицензии для решений SAP BusinessObjects из примечания SAP № 1288121 или создать ключ лицензии в SAP Service Marketplace.

  • В разделе Select Install Type (Выбор типа установки) выберите установку Full (Полная) для первого сервера (azusbosl1). Для второго сервера (azusbosl2) выберите установку Custom / Expand (Пользовательская или расширение), чтобы расширить имеющуюся установку BOBI.

  • В разделе Select Default or Existing Database (Выбор базы данных по умолчанию или имеющейся базы данных) щелкните configure an existing database (Настроить имеющуюся базу данных), в результате чего вам будет предложено выбрать базу данных CMS и базу данных аудита. Для этих типов базы данных выберите MySQL.

    Если вы не хотите настраивать аудит во время установки, можно также выбрать No auditing database (Без базы данных аудита).

  • На экране Select Java Web Application Server (Выбор сервера веб-приложений Java) выберите параметры, соответствующие вашей архитектуре SAP BOBI. В этом примере мы выбрали параметр 1, чтобы установить сервер Tomcat на той же платформе SAP BOBI.

  • Введите сведения о базе данных CMS на экране Configure CMS Repository Database - MySQL (Настройка базы данных репозитория CMS — MySQL). В следующем примере показан ввод сведений о базе данных CMS для установки Linux. База данных Azure для MySQL по умолчанию использует порт 3306.

    Screenshot that shows SAP BOBI Deployment on Linux - CMS database.

  • (Необязательно.) Введите сведения о базе данных аудита на экране Configure Audit Repository Database - MySQL (Настройка базы данных репозитория аудита — MySQL). В следующем примере показан ввод сведений о базе данных аудита для установки Linux.

    Screenshot that shows SAP BOBI Deployment on Linux - audit database.

  • Следуйте инструкциям и введите необходимые входные данные для завершения установки.

Для развертывания с несколькими экземплярами запустите программу установки на втором узле (azusbosl2). На экране Select Install Type (Выбор типа установки) выберите установку Custom / Expand (Пользовательская или расширение), чтобы расширить имеющуюся установку BOBI.

В Базе данных Azure для MySQL шлюз перенаправляет подключения к экземплярам сервера. После установки подключения в клиенте MySQL отображается версия MySQL, установленная в шлюзе, а не фактическая версия, которая работает на вашем экземпляре сервера MySQL. Чтобы определить версию MySQL на экземпляре сервера, выполните команду SELECT VERSION(); в командной строке MySQL. Дополнительные сведения см. в статье Поддерживаемые версии сервера Базы данных Azure для MySQL.

Screenshot that shows SAP BOBI Deployment on Linux - CMC Settings.

# Run direct query to the database using MySQL Workbench

select version();

+-----------+
| version() |
+-----------+
| 8.0.15    |
+-----------+

После установки

После установки нескольких экземпляров платформы SAP BOBI необходимо выполнить дополнительные действия после настройки, чтобы обеспечить высокую доступность приложения.

Настройка имени кластера

В развертывании с несколькими экземплярами платформы SAP BOBI необходимо запускать несколько серверов CMS в кластере. Кластер состоит из двух или более серверов CMS, работающих вместе с общей системной базой данных CMS. Если на узле, работающем на сервере CMS, происходит сбой, узел с другим сервером CMS продолжит обрабатывать запросы платформы бизнес-аналитики. По умолчанию на платформе SAP BOBI имя кластера соответствует имени узла для первой устанавливаемой системы CMS.

Чтобы настроить имя кластера в Linux, выполните инструкции, указанные в руководстве администратора по платформе бизнес-аналитики SAP. После настройки имени кластера следуйте указаниям в примечании SAP 1660440, чтобы задать системную запись по умолчанию на странице входа в панель запуска CMC или BI.

Настройка входного и выходного расположения хранилища файлов в Azure NetApp Files

Хранилище файлов — это каталоги на диске, в которых находятся фактические файлы SAP BusinessObjects. Расположение сервера репозитория файлов по умолчанию для платформы SAP BOBI — локальный каталог установки. При развертывании с несколькими экземплярами важно настроить хранилище файлов в общем хранилище, например Azure NetApp Files. Это позволит получить доступ к хранилищу со всех серверов уровня хранилища.

  1. Если вы еще не создали тома NFS, создайте их в Azure NetApp Files. (Следуйте инструкциям из предыдущего раздела "Подготовка Azure NetApp Files").

  2. Подключите том NFS. (Следуйте инструкциям из предыдущего раздела "Подключение тома Azure NetApp Files").

  3. Чтобы изменить путь к репозиторию файлов (входящий и исходящий), следуйте указаниям в примечании SAP 2512660.

Кластеризация Tomcat: репликация сеансов

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

Например, предположим, что пользователь подключен к веб-серверу, на котором происходит сбой, когда пользователь перемещается по иерархии папок в приложении SAP BI. В правильно настроенном кластере пользователь может продолжить переходить по иерархии папок без перенаправления на страницу входа.

Согласно примечанию SAP № 2808640, действия по настройке кластеризации Tomcat предоставляются с помощью многоадресной рассылки. Обратите внимание, что в Azure многоадресная рассылка не поддерживается. Чтобы кластер Tomcat работал в Azure, необходимо использовать StaticMembershipInterceptor (примечание SAP 2764907). Дополнительные сведения см. в записи блога SAP в Azure: кластеризация Tomcat с помощью статического членства для платформы SAP BusinessObjects BI.

Веб-уровень балансировки нагрузки платформы SAP BI

При развертывании нескольких экземпляров SAP BOBI серверы веб-приложений Java (веб-уровень) работают на двух или более узлах. Чтобы равномерно распределять нагрузку пользователей между веб-серверами, можно развернуть подсистему балансировки нагрузки между пользователями и веб-серверами. Для управления трафиком к серверам веб-приложений в Azure можно использовать Azure Load Balancer или Шлюз приложений Azure. Сведения о каждом предложении приведены в следующем разделе.

Azure Load Balancer

Azure Load Balancer — это высокопроизводительная подсистема балансировки нагрузки уровня 4 (TCP, UDP) с низкой задержкой. Она распределяет трафик между работоспособными виртуальными машинами. Проба работоспособности позволяет отслеживать указанный порт на каждой виртуальной машине и передавать трафик только в рабочую виртуальную машину. Вы можете выбрать общедоступную или внутреннюю подсистему балансировки нагрузки, в зависимости от того, требуется ли доступ к платформе SAP BI из Интернета. Это решение является избыточным между зонами, поэтому оно обеспечивает высокий уровень доступности в зонах доступности.

Ознакомьтесь со схемой внутренней подсистемы балансировки нагрузки ниже. Сервер веб-приложений работает через порт 8080. По умолчанию это HTTP-порт Tomcat, который будет отслеживаться пробой работоспособности. Любой входящий запрос, поступающий от пользователей, будет перенаправлен на серверы веб-приложений (azusbosl1 или azusbosl2). Load Balancer не поддерживает завершение TLS/SSL (также известное как разгрузка TLS/SSL). Если для распределения трафика между веб-серверами вы используете подсистему балансировки нагрузки, выбирайте ценовую категорию "Стандартный".

Примечание.

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

Diagram that shows Azure Load Balancer balancing traffic across web servers.

Шлюз приложений Azure

Шлюз приложений Azure предоставляет контроллер доставки приложений (ADC) в виде службы. Эта служба используется, чтобы помочь приложению направлять пользовательский трафик на один или несколько серверов веб-приложений. Эта служба предлагает различные возможности балансировки нагрузки уровня 7, включая разгрузку TLS/SSL, брандмауэр веб-приложения (WAF) и сходство сеансов на основе файлов cookie.

На платформе SAP BI Шлюз приложений направляет веб-трафик приложений к указанным ресурсам — azusbosl1 или azusbos2. Вы можете назначить прослушиватель для порта, создать правила и добавить ресурсы в пул. На рисунке ниже Шлюз приложений с частным интерфейсным IP-адресом (10.31.3.20) выступает в качестве точки входа для пользователей. Он обрабатывает входящие подключения TLS/SSL (HTTPS — TCP, порт 443), расшифровывает данные TLS/SSL и передает незашифрованный запрос (HTTP — TCP, порт 8080) на серверы во внутреннем пуле. Это упрощает операции для поддержки только одного сертификата TLS/SSL в Шлюзе приложений.

Diagram that shows Application Gateway balancing traffic across web servers.

Чтобы настроить Шлюз приложений для веб-сервера SAP BOBI, ознакомьтесь с записью блога Балансировка нагрузки веб-серверов SAP BOBI с помощью Шлюза приложений Azure.

Примечание.

Шлюз приложений Azure является предпочтительным для балансировки нагрузки трафика на веб-сервер. Он предоставляет такие полезные функции, как разгрузка SSL, централизованное управление SSL для уменьшения количества операций шифрования и расшифровки на сервере, алгоритм циклического перебора для распределения трафика, возможности брандмауэра веб-приложения (WAF) и высокий уровень доступности.

Надежность платформы SAP BOBI в Azure

Платформа SAP BOBI включает в себя различные уровни, оптимизированные для определенных задач и операций. Когда компонент на любом из уровней становится недоступным, приложение SAP BOBI становится недоступным или его некоторые функциональные возможности перестают работать. Необходимо, чтобы каждый уровень обеспечивал надежность и работоспособность приложений, исключая какие-либо нарушения в работе организации.

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

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

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

  • Аварийное восстановление. Это процесс восстановления функциональности приложения в случае серьезной аварии, например, если весь регион Azure станет недоступным из-за стихийного бедствия.

Реализация этого решения зависит от характера конфигурации системы в Azure. Настройте решения для резервного копирования и восстановления, обеспечения высокой доступности и аварийного восстановления в соответствии с бизнес-требованиями.

Резервное копирование и восстановление

Резервное копирование и восстановление — это важный компонент любой стратегии аварийного восстановления организации. Чтобы разработать комплексную стратегию для платформы SAP BOBI, определите компоненты, которые могут привести к простою системы или нарушению работы приложения. На платформе SAP BOBI для защиты приложения крайне важно резервное копирование следующих компонентов:

  • каталог установки SAP BOBI (управляемые диски класса "Премиум");
  • сервер репозитория файлов (Azure NetApp Files или Файлы Azure (цен. категория "Премиум"));
  • база данных CMS (База данных SQL, База данных Azure для MySQL или база данных на виртуальных машинах Azure).

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

Резервное копирование и восстановление для каталога установки SAP BOBI

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

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

Резервное копирование и восстановление сервера репозитория файлов

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

  • Для Azure NetApp Files можно создавать моментальные снимки по запросу и запланировать автоматическое создание моментальных снимков с помощью политик моментальных снимков. Копии моментальных снимков обеспечивают копию тома на определенный момент времени. Дополнительные сведения см. в статье Управление моментальными снимками с помощью Azure NetApp Files.

  • Если вы создали отдельный сервер NFS, убедитесь, что для него есть стратегия резервного копирования и восстановления того же сервера.

Резервное копирование и восстановление для баз данных CMS и аудита

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

  • В службе "База данных Azure для MySQL" для сервера автоматически создаются резервные копии, которые сохраняются в локально избыточном или геоизбыточном хранилище, настроенном пользователем. База данных Azure для MySQL создает резервные копии файлов данных и журнала транзакций. В зависимости от поддерживаемого максимального размера хранилища создаются полные и разностные резервные копии (до 4 ТБ хранилища на сервере) или резервные копии на основе моментальных снимков (до 16 ТБ хранилища на сервере). При помощи этих резервных копий вы можете восстановить сервер до любой точки во времени в пределах заданного срока хранения резервных копий. Срок хранения резервных копий по умолчанию составляет семь дней. При необходимости его можно увеличить до 3 дней. Все резервные копии шифруются с помощью 256-битового шифрования AES. Эти файлы резервных копий не предоставляются пользователю, и их невозможно экспортировать. Эти резервные копии можно использовать только для операций восстановления в Базе данных Azure для MySQL. Скопировать базу данных можно с помощью утилиты mysqldump. Дополнительные сведения см. в статье Резервное копирование и восстановление в службе "База данных Azure для MySQL".

  • Для базы данных, установленной на виртуальной машине Azure, можно использовать стандартные средства резервного копирования или службу Azure Backup для поддерживаемых баз данных. Вы также можете использовать поддерживаемые средства резервного копирования сторонних производителей, которые предоставляют агент для резервного копирования и восстановления всех компонентов платформы SAP BOBI.

Высокая доступность

Высокий уровень доступности относится к группе технологий, которые минимизируют перебои в работе инфраструктуры ИТ, обеспечивая непрерывность бизнес-процессов служб и приложений. Это осуществляется благодаря использованию избыточных компонентов, отказоустойчивых компонентов или компонентов, защищенных с помощью отработки отказа, в одном центре обработки данных. В нашем случае центры обработки данных находятся в пределах одного региона Azure. Дополнительные сведения см. в статье Высокодоступная архитектура и сценарии для SAP NetWeaver.

В зависимости от результирующего размера платформы SAP BOBI необходимо разработать ландшафт и определить распределение компонентов BI между виртуальными машинами и подсетями Azure. Уровень избыточности в распределенной архитектуре зависит от требуемых для организации цели времени восстановления (RTO) и целевой точки восстановления (RPO). Платформа SAP BOBI включает в себя различные уровни, и компоненты на каждом уровне должны обеспечивать избыточность. Например:

  • избыточные серверы приложений, такие как серверы приложений бизнес-аналитики и веб-сервер;
  • уникальные компоненты, такие как база данных CMS, сервер репозитория файлов, Load Balancer.

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

Высокий уровень доступности серверов приложений

Добиться высокого уровня доступности серверов приложений можно за счет избыточности. Для этого настройте несколько экземпляров BI и веб-серверов на разных виртуальных машинах Azure.

Чтобы снизить влияние простоя из-за запланированных и незапланированных событий, рекомендуется следовать рекомендациям по архитектуре высокой доступности.

Дополнительные сведения см. в статье Управление доступностью виртуальных машин Linux.

Важно!

  • Понятия зон доступности Azure и групп доступности Azure являются взаимоисключающими. Пару или несколько виртуальных машин можно развернуть либо в определенной зоне доступности, либо в группе доступности, но вы не можете сделать и то, и другое.
  • При планировании развертывания между зонами доступности рекомендуется использовать гибкий масштабируемый набор с FD=1 по сравнению со стандартным развертыванием зоны доступности.

Высокий уровень доступности базы данных CMS

Если вы используете Базу данных Azure для MySQL для базы данных CMS и аудита, то по умолчанию вам предоставляется локально избыточная высокодоступная платформа. Вам нужно просто выбрать регион, и служба унаследует высокий уровень доступности, избыточность и устойчивость без необходимости настройки дополнительных компонентов. Если платформа SAP BOBI развертывается в зоне доступности, необходимо обеспечить избыточность между зонами для баз данных CMS и аудита. Дополнительные сведения см. в статьях Основные понятия высокого уровня доступности в Базе данных Azure для MySQL и Высокий уровень доступности для базы данных Azure SQL и управляемого экземпляра SQL.

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

Высокий уровень доступности для хранилища файлов

Хранилище файлов управляет каталогами на диске, в которых хранится такое содержимое, как отчеты, пространства и подключения. Он является общим для всех серверов приложений в этой системе. Поэтому необходимо убедиться, что он имеет высокий уровень доступности, как и другие компоненты платформы SAP BOBI.

Для платформы SAP BOBI на Linux вы можете выбрать Файлы Azure (цен. категория "Премиум") или Azure NetApp Files для общей папки, которая обеспечивает высокий уровень доступности и надежность. Дополнительные сведения см. в разделе Избыточность для Файлов Azure.

Обратите внимание, что служба общих папок доступна не во всех регионах. Дополнительные сведения см. в статье Доступность продуктов по регионам. Если служба недоступна в вашем регионе, вы можете создать сервер NFS, на котором можно будет предоставить общий доступ к файловой системе для приложения SAP BOBI. Но также необходимо учитывать его высокий уровень доступности.

Высокий уровень доступности Load Balancer

Для распределения трафика между веб-сервером можно использовать Azure Load Balancer или Шлюз приложений Azure. Избыточность для любой из этих служб можно обеспечить, исходя из номера SKU, выбранного для развертывания.

  • Для Azure Load Balancer избыточность можно обеспечить, настроив избыточный между зонами интерфейс Load Balancer (цен. категория "Стандартный"). Дополнительные сведения см. в статье Load Balancer и Зоны доступности.

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

    • Номер SKU версии 1 поддерживает сценарии высокого уровня доступности при развертывании двух или более экземпляров. Azure распределяет эти экземпляры по доменам сбоя и обновления, чтобы избежать одновременного сбоя всех экземпляров. Избыточность можно обеспечить в пределах зоны.
    • Номер SKU версии 2 автоматически гарантирует, что новые экземпляры распределяются между доменами сбоя и доменами обновления. Если вы выбрали избыточность между зонами, последние экземпляры также распределяются по зонам доступности, что обеспечивает устойчивость зон к сбоям. Дополнительные сведения см. в статье Автоматическое масштабирование и Шлюз приложений, избыточный между зонами, версии 2.

Эталонная высокодоступная архитектура для платформы SAP BOBI

На следующей схеме показана настройка платформы SAP BOBI, работающей на сервере Linux. Эта архитектура демонстрирует использование различных служб, таких как Шлюз приложений Azure, Azure NetApp Files и База данных Azure для MySQL. Эти службы обеспечивают встроенную избыточность между зонами, что упрощает процесс управления различными решениями высокой доступности.

Обратите внимание, что входящий трафик (HTTPS) балансируется с помощью SKU Шлюз приложений Azure версии 1/2, который является высокодоступным при развертывании на двух или более экземплярах. Несколько экземпляров веб-сервера, серверов управления и серверов обработки развертываются на отдельных виртуальных машинах для обеспечения избыточности. Azure NetApp Files обеспечивает встроенную избыточность в центре обработки данных, поэтому тома Azure NetApp Files для сервера репозитория файлов будут высокодоступными. База данных CMS подготавливается в Базе данных Azure для MySQL, которая обеспечивает высокий уровень доступности. Чтобы узнать больше, ознакомьтесь со статьей Основные понятия высокого уровня доступности в Базе данных Azure для MySQL.

Diagram that shows SAP BusinessObjects BI platform redundancy with availability sets.

Приведенная выше архитектура позволяет получить представление о том, как можно выполнить развертывание SAP BOBI в Azure. Но она не охватывает все возможные варианты конфигурации. Адаптировать развертывание можно на основе бизнес-требований.

В нескольких регионах Azure вы можете использовать зоны доступности. Это означает, что они обеспечиваются независимыми источниками питания, системами охлаждения и сетями. Это позволяет развертывать приложение в двух или трех зонах доступности. Если вы хотите обеспечить высокий уровень доступности между зонами доступности, можно развернуть платформу SAP BOBI в разных зонах доступности, убедившись, что каждый компонент в приложении будет избыточным между зонами.

Аварийное восстановление

В этом разделе описаны стратегии аварийного восстановления для платформы SAP BOBI на Linux. Этот раздел дополняет документ Настройка аварийного восстановления для многоуровневого развертывания приложения SAP NetWeaver, который содержит основные материалы, описывающие общий подход к аварийному восстановлению SAP. Сведения о платформе SAP BOBI см. в примечании SAP № 2056228, где описаны следующие методы безопасной реализации среды аварийного восстановления.

  • Полное или выборочное использование управления жизненным циклом или федерации для продвижения или распространения содержимого из основной системы.
  • Периодическое копирование содержимого CMS и сервера репозитория файлов.

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

Важно!

  • Доступность каждого компонента на платформе SAP BOBI необходимо учитывать в дополнительном регионе, а вся стратегия аварийного восстановления должна быть тщательно протестирована.
  • Если платформа SAP BI настроена с гибким масштабируемым набором с FD=1, необходимо использовать PowerShell для настройки Azure Site Recovery для аварийного восстановления. В настоящее время это единственный метод, доступный для настройки аварийного восстановления для виртуальных машин, развернутых в масштабируемом наборе.

Эталонная архитектура аварийного восстановления для платформы SAP BOBI

Данная эталонная архитектура выполняет развертывание платформы SAP BOBI в нескольких экземплярах с избыточными серверами приложений. Для аварийного восстановления необходимо выполнить отработку отказа всех компонентов платформы SAP BOBI с переносом в дополнительный регион. На схеме ниже Azure NetApp Files используется в качестве хранилища файлов, База данных Azure для MySQL в качестве репозитория CMS и аудита, а Шлюз приложений Azure — для балансировки нагрузки трафика. Стратегии защиты аварийного восстановления зависят от компонента, как описано в следующем разделе.

Diagram that shows SAP BusinessObjects BI platform disaster recovery.

Подсистема балансировки нагрузки

Подсистема балансировки нагрузки используется для распределения трафика между серверами веб-приложений платформы SAP BOBI. Для этого в Azure можно использовать Azure Load Balancer или Шлюз приложений Azure. Чтобы обеспечить аварийное восстановление для служб подсистемы балансировки нагрузки, необходимо реализовать еще один Azure Load Balancer или Шлюз приложений Azure в дополнительном регионе. Чтобы сохранить тот же URL-адрес после отработки отказа в рамках аварийного восстановления, необходимо изменить запись в DNS, указав на службу балансировки нагрузки, работающую в дополнительном регионе.

Виртуальные машины с серверами приложений бизнес-аналитики и серверами веб-приложений

Службу Azure Site Recovery можно использовать для репликации виртуальных машин, на которых выполняются серверы веб-приложений и серверы приложений бизнес-аналитики, в дополнительный регион. Она реплицирует серверы и все подключенные управляемые диски в дополнительный регион, чтобы при авариях и сбоях можно было легко выполнить отработку отказа в реплицированную среду и продолжить работу. Чтобы начать репликацию всех виртуальных машин приложений SAP в центре обработки данных аварийного восстановления Azure, следуйте указаниям из статьи о репликации виртуальных машин в Azure.

Серверы репозитория файлов

Хранилище файлов — это каталог на диске, в котором хранятся фактические файлы, например отчеты и документы бизнес-аналитики. Важно, чтобы все файлы в хранилище файлов были синхронизированы с регионом аварийного восстановления. В зависимости от типа службы файлового ресурса, используемой для платформы SAP BOBI на Linux, необходимо, чтобы в стратегии аварийного восстановления была предусмотрена синхронизация содержимого.

База данных CMS

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

База данных Azure для MySQL

База данных Azure для MySQL предлагает несколько вариантов восстановления базы данных в случае аварии. Выберите вариант, который подходит для вашей организации.

  • Чтобы усовершенствовать планирование непрерывности бизнес-процессов и аварийного восстановления, можно использовать реплики чтения в других регионах. Вы можете реплицировать данные с исходного сервера на несколько реплик (до пяти). Реплики чтения обновляются асинхронно посредством технологии репликации двоичных журналов MySQL. Реплики — это новые серверы, которыми вы управляете как обычными серверами службы "База данных Azure для MySQL". Дополнительные сведения см. в статье Реплики чтения в Базе данных Azure для MySQL.

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

    Примечание.

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

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

Уровни платформы SAP BOBI Рекомендация
Шлюз приложений Azure Параллельная конфигурация Шлюза приложений в дополнительном регионе.
Серверы веб-приложений Репликация с помощью Azure Site Recovery.
Серверы приложений бизнес-аналитики Репликация с помощью Site Recovery.
Azure NetApp Files Средство копирования файлов для репликации данных в дополнительный регион или репликация между регионами.
База данных Azure для MySQL Реплики чтения в разных регионах или восстановление с помощью геоизбыточных резервных копий.

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