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

В этой статье описывается стратегия развертывания платформы SAP BusinessObjects Business Intelligence (SAP BOBI) в Azure для Windows. В этом примере настраиваются две виртуальные машины с управляемыми дисками SSD от Azure категории "Премиум" в качестве каталога установки. База данных SQL Azure, предлагаемая в формате "платформа как услуга", используется для баз данных центрального сервера управления (central management server, CMS) и аудита. Файлы Azure класса "Премиум", протокол SMB, используются как общее хранилище файлов для обеих виртуальных машин. По умолчанию веб-приложение Tomcat на Java и приложение платформы бизнес-аналитики устанавливаются вместе на обе виртуальные машины. Для балансировки нагрузки от запросов пользователя используется шлюз приложений Azure, в котором доступны собственные возможности разгрузки TLS/SSL.

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

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

• Платформа SAP BusinessObjects 4.3 SP01 с исправлением 1
• Windows Server 2019
• База данных SQL (версия 12.0.2000.8)
• Драйвер Microsoft ODBC — msodbcsql.msi (версия 13.1)

Файловая система	Description	Размер (ГБ)	Требуемый доступ	Хранилище
F:	Файловая система для установки экземпляра SAP BOBI, веб-приложения Tomcat по умолчанию и драйверов базы данных (при необходимости).	Рекомендации по выбору размера SAP	Права локального администратора	Управляемые диски SSD (ценовая категория "Премиум")
\\azusbobi.file.core.windows.net\frsinput	Каталог подключения предназначен для общих файлов на всех узлах SAP BOBI. Он будет использоваться в качестве хранилища входных файлов.	Бизнес-потребности	Права локального администратора	Azure NetApp Files
\\azusbobi.file.core.windows.net\frsoutput	Каталог подключения предназначен для общих файлов на всех узлах SAP BOBI. Он будет использоваться в качестве каталога хранилища выходных файлов.	Бизнес-потребности	Права локального администратора	Azure NetApp Files

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

В этом разделе мы создадим две виртуальные машины с образом операционной системы Windows для платформы SAP BOBI. Для создания виртуальных машин выполняются следующие общие действия.

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

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

   • Не используйте одну подсеть для всех служб Azure в развертывании платформы SAP BI. В соответствии с архитектурой платформы SAP BI может потребоваться создание нескольких подсетей. В этом развертывании мы создадим две подсети: подсеть приложения бизнес-аналитики и подсеть шлюза приложений.
   • Следуя примечанию к SAP № 2276646, определите порты для взаимодействия между различными компонентами через платформу SAP BOBI.
   • База данных SQL обменивается данными через порт 1433. Исходящий трафик через порт 1433 должен быть разрешен на серверах приложений SAP BOBI.
   • В Azure шлюз приложений должен находиться в отдельной подсети. Дополнительные сведения см. в статье Обзор конфигурации шлюза приложений.
   • Если вместо Файлов Azure вы используете для хранения файлов Azure NetApp Files, создайте отдельную подсеть для Azure NetApp Files. Дополнительные сведения см. в статье Рекомендации по планированию сети для Azure NetApp Files.

3. Выберите подходящие варианты доступности в зависимости от предпочитаемой конфигурации системы в регионе Azure, в том случае, если она охватывает зоны, находится в пределах одной зоны или работает в регионе без зоны.

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

   • Вы можете использовать настраиваемый образ или выбрать образ из Azure Marketplace. В зависимости от своих задач см. инструкции в статье Развертывание виртуальной машины из Azure Marketplace для SAP или Развертывание виртуальной машины из пользовательского образа для SAP.

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

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

Предоставление Файлов Azure класса "Премиум"

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

Файлы Azure предоставляют стандартные общие папки, размещенные на оборудовании с жесткими дисками, и общие файлы класса "Премиум", размещенные на оборудовании с SSD. Для хранилища файлов SAP BusinessObjects используйте Файлы Azure класса "Премиум".

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

Развертывание учетной записи хранения файлов Azure и общих папок NFS

Общие папки Azure развертываются в учетных записях хранения. Это объекты верхнего уровня, которые представляют общий пул хранилища. Этот пул хранилища можно использовать для развертывания нескольких общих папок. Azure поддерживает несколько типов учетных записей хранения для разных сценариев хранилища, которые могут использовать клиенты. Для хранилища файлов SAP BusinessObjects необходимо создать учетную запись FileStorage. Она потребуется для развертывания общих папок Azure на оборудовании класса "Премиум" с SSD.

Примечание.

Учетные записи FileStorage можно использовать только для хранения общих папок Azure. Никакие другие ресурсы хранилища, включая BLOB-объекты, контейнеры, очереди и таблицы, в учетной записи FileStorage разворачивать нельзя.

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

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

Учетная запись хранения файлов Azure

1. Чтобы создать учетную запись хранения через портал Azure, выберите Создать ресурс>Хранилище>Учетная запись хранения.

2. На вкладке Основные сведения заполните все обязательные поля, чтобы создать учетную запись хранения.

   1. Выберите пункт Подписка>Группа ресурсов>Регион.

   2. Укажите имя учетной записи хранения. Например, введите azusbobi. Имя может быть любым, но при этом глобально уникальным.

   3. Выберите уровень производительности Премиум и тип учетной записи FileStorage.

   4. В метке Репликация выберите уровень избыточности. Выберите Локально избыточное хранилище (LRS).

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

   5. Выберите Далее.

3. На вкладке Сеть выберите в качестве метода подключения пункт Частная конечная точка. Дополнительные сведения см. в разделе Рекомендации по работе с сетями в службе "Файлы Azure".

   1. В разделе "Частная конечная точка" выберите Добавить.

   2. Выберите пункт Подписка>Группа ресурсов>Расположение.

   3. Введите имя частной конечной точки. Например, введите azusbobi-pe.

   4. Выберите файл в подресурсе хранилища.

   5. В разделе Сети выберите виртуальную сеть и подсеть, в которой развернуто приложение бизнес-аналитики SAP BusinessObjects.

   6. Примите значение по умолчанию (Да) для параметра Интеграция с частной зоной DNS.

   7. Выберите свою частную зону DNS из раскрывающегося списка.

   8. Нажмите кнопку OK , чтобы вернуться на вкладку Сетевые подключения в окне Создание учетной записи хранения.

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

5. На вкладке Дополнительно выберите другие параметры безопасности.

   Поле Требуется безопасное перемещение указывает, требуется ли для учетной записи хранения шифрование при передаче для обмена данными с учетной записью хранения. Если требуется поддержка SMB 2.1, это поле нужно отключить. Для платформы SAP BOBI оставьте значение по умолчанию (включено).

6. Далее создайте учетную запись хранения.

Дополнительные сведения о создании учетной записи хранения см. в статье Создание учетной записи хранения FileStorage.

создание файловых ресурсов Azure;

Следующим шагом является создание файлов Azure в учетной записи хранения. Служба файлов Azure использует для общих папок класса "Премиум" подготовленную модель. В подготовленной бизнес-модели вместо оплаты по факту использования вы указываете свои требования к хранилищу в службе файлов Azure заранее. Дополнительные сведения об этой модели см. в разделе Подготовленная модель. В этом примере мы создадим два файла Azure: frsinput (256 ГБ) и frsoutput (256 ГБ) для хранилища файлов SAP BOBI.

1. Перейдите к учетной записи хранения azusbobi>Общие папки.
2. Выберите пункт Новая общая папка.
3. Введите имя общей папки. Например, введите frsinput или frsouput.
4. Вставьте требуемый размер общей папки в поле Подготовленная емкость. Например, введите 256 ГБ.
5. Выберите SMB в поле Протокол.
6. Выберите Создать.

Настройка диска данных на виртуальной машине Windows

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

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

Инициализация нового диска данных

Для приложения бизнес-аналитики SAP BusinessObjects требуется раздел, в который можно установить его двоичные файлы. Приложение SAP BOBI можно установить в раздел ОС (C:), предварительно убедившись в наличии достаточного места для развертывания и ОС. Для временных файлов и веб-приложений рекомендуется иметь не меньше 2 ГБ. Кроме того, рекомендуется хранить двоичные файлы установки SAP BOBI в разных разделах.

В данном примере приложение SAP BOBI устанавливается в отдельный раздел (F:). Инициализируйте SSD (ценовая категория "Премиум"), подключенный во время подготовки виртуальной машины.

1. [A] Если к виртуальной машине (azuswinboap1 и azuswinboap2) не подключен ни один диск данных, выполните действия, описанные в разделе Добавление диска данных, чтобы подключить новый управляемый диск данных.
2. [A] После подключения управляемого диска к виртуальной машине инициализируйте диск, выполнив действия, описанные в разделе Инициализация нового диска данных.

Подключение Файлов Azure класса "Премиум"

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

[A] Чтобы подключить общую папку Azure, выполните действия, описанные в разделе Подключение общей папки Azure.

Чтобы подключить общую папку Azure на сервере Windows, протокол S МБ требует открытия TCP-порта 445. Если порт 445 заблокирован, подключения завершатся ошибкой. Вы можете проверка, если брандмауэр или ISP блокирует порт 445 с помощью командлетаTest-NetConnection. См. раздел "Порт 445 заблокирован".

Настройка базы данных CMS: SQL Azure

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

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

Создание сервера Базы данных SQL

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

1. Перейдите на страницу Выберите вариант развертывания SQL.

2. В разделе Базы данных SQL установите параметру Тип ресурса значение Сервер базы данных. Выберите Создать.

3. На вкладке Основные сведения заполните все необходимые поля, чтобы создать сервер Базы данных SQL.

   1. В разделе Сведения о проекте выберите пункты Подписка и Группа ресурсов.

   2. Введите имя сервера. Например, введите azussqlbodb. Имя сервера может быть любым, но при этом глобально уникальным.

   3. Выберите расположение.

   4. Введите имя входа администратора сервера. Например, введите boadmin. Затем введите Пароль.

4. На вкладке Сеть измените значение параметра Разрешить службам и ресурсам Azure доступ к этому серверу на Нет в разделе Правила брандмауэра.

5. В окне Дополнительные параметры оставьте параметры по умолчанию.

6. Далее создайте сервер базы данных SQL.

На следующем шаге создайте базы данных CMS и аудита на сервере базы данных SQL (azussqlbodb.database.windows.net).

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

После того как вы подготовите сервер базы данных SQL, перейдите к ресурсу azussqlbodb. Затем выполните указанные ниже действия, чтобы создать базы данных CMS и аудита.

1. На странице Обзор azussqlbodb нажмите Создать базу данных.

2. На вкладке Основные сведения заполните все обязательные поля.

   1. Введите имя базы данных. Например, введите bocms или boaudit.

   2. В параметре Вычисление и хранение нажмите Настроить базу данных. Выберите соответствующую модель в зависимости от результата изменения размера. Подробные сведения о параметрах см. в разделе Модели определения размеров для базы данных SQL Azure.

3. На вкладке Сеть выберите в качестве метода подключения пункт Частная конечная точка. Частная конечная точка будет использоваться для доступа к Базе данных SQL в настроенной виртуальной сети.

   1. Нажмите Добавить частную конечную точку.

   2. Выберите пункт Подписка>Группа ресурсов>Расположение.

   3. Введите имя частной конечной точки. Например, введите azusbodb-pe.

   4. В списке Целевой подресурс выберите SqlServer.

   5. В разделе Сети выберите виртуальную сеть и подсеть, в которой развернуто приложение бизнес-аналитики SAP BusinessObjects.

   6. Примите значение По умолчанию (да) для параметра Интеграция с частной зоной DNS.

   7. Выберите свою частную зону DNS из раскрывающегося списка.

   8. Нажмите кнопку OK, чтобы вернуться на вкладку Сетевые подключения в окне Создание базы данных SQL.

4. На вкладке Дополнительные параметры измените значение Параметр сортировки на SQL_Latin1_General_CP850_BIN2.

5. Далее создайте базу данных CMS.

Аналогичным образом можно создать базу данных аудита. Например, введите boaudit.

Загрузка и установка драйвера ODBC

Серверам приложений SAP BOBI требуются клиент или драйверы базы данных для доступа к базе данных CMS или аудита. Драйвер Microsoft ODBC используется для доступа к базам данных CMS и аудита, работающим в Базе данных SQL. В этом разделе содержатся инструкции по скачиванию и настройке драйвера ODBC в Windows.

1. Чтобы узнать, какие соединители базы данных совместимы с Базой данных SQL, см. раздел Поддержка репозитория CMS и аудита в ОС в статье Матрица доступности продуктов для платформы бизнес-аналитики SAP BusinessObjects.
2. Скачайте версию драйвера ODBC по этой ссылке. В этом примере мы скачиваем драйвер ODBC 13.1.
3. Установите драйвер ODBC на все серверы бизнес-аналитики (azuswinboap1 и azuswinboap2).
4. После установки драйвера в azuswinboap1 выберите Пуск>Средства администрирования Windows>Источники данных ODBC (64 бит).
5. Перейдите на вкладку DSN системы.
6. Нажмите Добавить, чтобы создать подключение к базе данных CMS.
7. Выберите Драйвер ODBC 13 для SQL Server и нажмите кнопку Готово.
8. Введите сведения о базе данных CMS, как показано ниже, и нажмите кнопку "Далее".
   • Имя: имя базы данных, созданной в разделе "Создание базы данных CMS и аудита". Введите, например, bocms или boaudit.
   • Описание: описание, описывающее источник данных. Например, введите База данных CMS или База данных аудита.
   • Сервер: имя сервера, созданного в разделе "Создание сервера базы данных SQL". Введите, например, azussqlbodb.database.windows.net.
9. Выберите вариант С проверкой подлинности SQL Server с помощью идентификатора входа и пароля, вводимых пользователем, чтобы проверить подлинность в Azure SQL Server. Введите учетные данные пользователя, выбранные при создании сервера базы данных SQL. Например, введите boadmin. Выберите Далее.
10. Измените базу данных по умолчанию на bocms, а все остальные значения по умолчанию оставьте без изменений. Выберите Далее.
11. Установите флажок Использовать стойкое шифрование для данных, а все остальные значения по умолчанию оставьте без изменений. Выберите Готово.
12. Источник данных для базы данных CMS создан. Теперь можно нажать Проверить источник данных, чтобы проверить подключение к базе данных CMS из приложения бизнес-аналитики. Операция должна быть выполнена успешно. В случае сбоя устраните неполадки с подключением.

Примечание.

База данных SQL обменивается данными через порт 1433. Исходящий трафик через порт 1433 должен быть разрешен на серверах приложений SAP BOBI.

Повторите указанные выше шаги, чтобы создать подключение к базе данных аудита на сервере azuswinboap1. Аналогичным образом установите и настройте оба источника данных ODBC (bocms и boaudit) на всех серверах приложений бизнес-аналитики (azuswinboap2).

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

Чтобы подготовить серверы для установки платформы бизнес-аналитики, выполните инструкции в последнем руководстве по SAP. Актуальные сведения см. в разделе "Подготовка" Руководства по установке платформы бизнес-аналитики SAP для Windows.

Установка

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

Перейдите на носитель платформы бизнес-аналитики SAP BusinsessObjects и запустите setup.exe.

Выполните инструкции руководства по установке платформы SAP Business Intelligence для Windows, которые относятся к вашей версии. Вот несколько моментов, которые нужно учитывать при установке платформы SAP BOBI в Windows.

• На экране Настройка папки назначения укажите папку назначения, в которую нужно установить платформу бизнес-аналитики. Например, введите F:\SAP BusinessObjects*.

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

• На экране Выбор типа установки выберите полную установку на первом сервере (azuswinboap1). Для другого сервера (azuswinboap2) выберите параметр Пользовательская/развернутая, чтобы расширить существующую установку SAP BOBI.

• На экране Выбор базы данных по умолчанию или существующей базы данных выберите Настроить существующую базу данных, в результате чего вам будет предложено выбрать базу данных CMS и аудита. Выберите Microsoft SQL Server с использованием ODBC в качестве типа базы данных CMS и типа базы данных аудита.

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

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

• Введите сведения о базе данных CMS на экране Настройка базы данных репозитория CMS — SQL Server (ODBC). На следующем рисунке показан пример ввода сведений о базе данных CMS для установки Windows.

  

• (Необязательно.) Введите сведения о базе данных аудита на экране Настройка базы данных аудита — SQL Server (ODBC). На следующем рисунке показан пример ввода сведений о базе данных аудита для установки Windows.

  

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

Для развертывания с несколькими экземплярами запустите программу установки на втором узле (azuswinboap2). На экране Выбор типа установки выберите параметр Пользовательская/развернутая, чтобы расширить существующую установку BOBI. Дополнительные сведения см. в блоге SAP Настройка платформы бизнес-аналитики SAP BusinessObjects в базе данных SQL Azure.

Важно!

Номера версий ядра СУБД для SQL Server и Базы данных SQL не совпадают. Они представляют собой внутренние номера сборок этих трех отдельных продуктов. Ядро СУБД Базы данных SQL основано на той же базе кода, что и ядро СУБД SQL Server. Что важнее всего, ядро СУБД в Базе данных SQL всегда имеет самые новые части ядра СУБД SQL. Версия 12 Базы данных SQL более новая, чем версия 15 SQL Server.

Чтобы узнать текущую версию Базы данных SQL, можно либо проверить параметры в консоли центрального управления, либо выполнить следующий запрос с помощью sqlcmd или SQL Server Management Studio. Информацию о соотнесении версий SQL до совместимости по умолчанию см. в статье Уровень совместимости базы данных.

1> select @@version as version;
2> go
version
------------------------------------------------------------------------------------------
Microsoft SQL Azure (RTM) - 12.0.2000.8
        Feb 20 2021 17:51:58
        Copyright (C) 2019 Microsoft Corporation

(1 rows affected)

1> select name, compatibility_level from sys.databases;
2> go
name                                                                  compatibility_level
--------------------------------------------------------------------- -------------------
master                                                                                150
bocms                                                                                 150
boaudit                                                                               150

(3 rows affected)

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

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

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

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

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

Настройка входного и выходного расположения хранилища файлов в Файлах Azure класса "Премиум"

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

1. Если он не создан, следуйте инструкциям, приведенным в предыдущем разделе "Предоставление Файлов Azure класса «Премиум»", чтобы создать и подключить Файлы Azure класса "Премиум".

   Совет

   На основе того, развертывается ли виртуальная машина зональным или региональным способом, необходимо определить избыточность хранилища для файлов Azure Premium (ZRS или LRS).

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

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

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

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

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

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

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

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

  Примечание.

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

  

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

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

  

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

  Примечание.

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

Надежность платформы бизнес-аналитики SAP BusinessObjects в Azure

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

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

• Резервное копирование и восстановление: этот процесс создает периодические копии данных и приложений в отдельных расположениях. Если исходные данные или приложения будут утеряны или повреждены, копии можно использовать для восстановления или возврата в предыдущее состояние.
• Высокий уровень доступности: все компоненты платформы высокой доступности дублируются в регионе Azure, чтобы обеспечить работоспособность приложения, если один из серверов станет недоступным.
• Аварийное восстановление: этот процесс восстанавливает функциональные возможности приложения, если есть серьезные потери. Например, весь регион Azure может стать недоступным из-за стихийного сбоя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• База данных SQL использует для создания полных резервных копий (еженедельно), разностных резервных копий (раз в 12–24 часа) и резервных копий журналов транзакций (раз в 5–10 минут) технологию SQL Server. Периодичность создания резервных копий журналов транзакций зависит от объема вычислительных ресурсов и объема активности базы данных.

  Пользователи могут выбрать настройку избыточности хранилища резервных копий с использованием BLOB-объектов LRS, ZRS или GRS. Механизмы избыточности хранилища хранят несколько копий ваших данных, чтобы защитить их от плановых и внеплановых событий, включая временные отказы оборудования или сети либо перебои электроэнергии, а также массовые стихийные бедствия. По умолчанию База данных SQL хранит резервную копию в BLOB-объектах GRS, которые реплицируются в парный регион. В зависимости от требований организации вместо них можно использовать BLOB-объекты LRS или ZRS. Актуальные сведения о графике, хранении и использовании резервных копий Базы данных SQL см. в статье Автоматическое резервное копирование: База данных SQL Azure и управляемый экземпляр SQL Azure.

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

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

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

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

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

• Избыточные серверы приложений, такие как серверы приложений бизнес-аналитики и веб-серверы
• Уникальные компоненты, такие как база данных CMS, хранилище файлов и подсистема балансировки нагрузки

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

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

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

Пока не все регионы Azure предлагают зоны доступности, так что выбирайте стратегию развертывания с учетом своего региона. Регионы Azure, которые предлагают зоны, перечислены в статье Что такое зоны доступности в Azure?

Важно!

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

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

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

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

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

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

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

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

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

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

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

Эталонная архитектура высокой доступности для платформы бизнес-аналитики SAP BusinessObjects

В следующей эталонной архитектуре описывается настройка платформы SAP BOBI между зонами доступности на сервере Windows. Архитектура демонстрирует использование различных служб Azure, таких как шлюз приложений, файлы Azure класса "Премиум" (хранилище файлов) и База данных SQL (база данных CMS и аудита). Платформа SAP BOBI включает встроенную избыточность между зонами, что снижает сложность управления различными решениями высокой доступности.

На следующем рисунке входящий трафик (HTTPS — TCP/443) сбалансирован подсистемой балансировки нагрузки с использованием SKU шлюза приложений версии 2, который охватывает несколько зон доступности. Шлюз приложений распределяет запросы пользователей между веб-серверами, распределенными между зонами доступности. Веб-сервер направляет запрос в экземпляры сервера управления и обработки, развернутые на отдельных виртуальных машинах в разных зонах доступности. Файлы Azure класса "Премиум" с ZRS подключаются по частному каналу к виртуальным машинам на уровне управления и хранилища для доступа к такому содержимому, как отчеты, вселенная и подключения. Приложение обращается к базе данных CMS и аудита, работающей в экземпляре базы данных SQL, избыточном между зонами, который реплицирует базы данных в несколько физических расположений в регионе Azure.

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

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

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

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

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

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

Важно!

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

Справочник по архитектуре аварийного восстановления для платформы бизнес-аналитики SAP BusinessObjects

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

Load Balancer

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

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

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

Хранилище файлов

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

• Файлы Azure класса "Премиум" поддерживают только LRS и ZRS. Для стратегии аварийного восстановления ресурсов Файлов Azure (цен. категория "Премиум") можно использовать AzCopy или Azure PowerShell, чтобы копировать файлы в другую учетную запись хранения в другом регионе. Дополнительные сведения см. в статье Аварийное восстановление и отработка отказа учетной записи хранения.

• Azure NetApp Files предоставляет тома NFS и SMB, поэтому для репликации данных между регионами Azure можно использовать любое средство копирования файлов. Чтобы узнать больше о копировании тома Azure NetApp Files в другой регион, ознакомьтесь с вопросами и ответами об Azure NetApp Files.

  Вы можете использовать репликацию между регионами Azure NetApp Files, которая в настоящее время находится на этапе предварительной версии. Для этой репликации используется технология NetApp SnapMirror. При использовании этой технологии по сети отправляются только измененные блоки, преобразованные в эффективный формат со сжатием. Эта защищаемая технология позволяет сократить объем данных, требующих репликации между регионами, снижая тем самым затраты на передачу данных. Кроме того, сокращается время репликации, что позволяет добиться уменьшения RPO. Дополнительные сведения см. в разделе Требования и рекомендации по использованию репликации между регионами.

База данных CMS

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

База данных SQL Azure

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

Вариант 1. Восстановление резервной копии геоизбыточной базы данных

По умолчанию База данных SQL хранит данные в BLOB-объектах GRS, которые реплицируются в парный регион. Для Базы данных SQL избыточность хранилища резервных копий можно настроить при создании базы данных CMS и аудита или обновить для существующей базы данных. Изменения, внесенные в существующую базу данных, применяются только к будущим резервным копиям. Вы можете восстановить любую базу данных SQL в любом регионе Azure из последних геореплицированных резервных копий. При геовосстановлении в качестве источника используется геореплицированная резервная копия. Между созданием резервной копии и ее георепликацией в BLOB-объект Azure в другом регионе существует задержка. В результате восстановленная база данных может представлять собой исходную базу данных в состоянии, в котором она находилась в течение часа до сбоя.

Важно!

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

Вариант 2. Гео-реплика или группа автоматической отработки отказа

Георепликация — это компонент Базы данных SQL, который позволяет создавать доступные для чтения базы данных — получатели на основе отдельных баз данных на сервере в том же или в другом регионе. Если георепликация для базы данных CMS и аудита включена, приложение может инициировать отработку отказа в базу данных — получатель в другом регионе Azure. Геоизбыточное реплика включается для отдельных баз данных, но для обеспечения прозрачной и согласованной отработки отказа нескольких баз данных (CMS и аудита) для приложения SAP BOBI рекомендуется использовать группу автоматической отработки отказа. Она предоставляет семантику группы поверх активной георепликации, что означает, что весь SQL Server (все базы данных) реплицируется в другой регион, а не в отдельные базы данных. Проверьте таблицу возможностей, в которой георепликация сравнивается с группами отработки отказа.

Группы автоматической отработки отказа предоставляют конечные точки прослушивателя только для чтения и записи, которые остаются неизменными во время отработки отказа. Конечная точка чтения и записи может храниться как прослушиватель в записи подключения ODBC для базы данных CMS и аудита. Независимо от того, используете ли вы активацию вручную или автоматическую активацию отработки отказа, отработка отказа переключит все базы данных — получатели в группе в базу данных — источник. После выполнения автоматической отработки отказа базы данных запись DNS автоматически обновляется, чтобы перенаправить конечные точки в новый регион. Приложение автоматически подключается к базе данных CMS, так как конечная точка чтения и записи сохраняется как прослушиватель в подключении ODBC.

На следующем рисунке группа автоматической отработки отказа для SQL Server (azussqlbodb), выполняющаяся в регионе "Восточная часть США 2", реплика в дополнительный регион "Восточная часть США" (сайт аварийного восстановления). Конечная точка прослушивателя чтения и записи сохраняется как прослушиватель в подключении ODBC для сервера приложений бизнес-аналитики на базе Windows. После отработки отказа конечная точка останется неизменной. Для подключения приложения бизнес-аналитики к базе данных SQL в дополнительном регионе ручное вмешательство не требуется.

Этот вариант обеспечивает более низкое значение RTO и RPO, чем вариант 1. Дополнительные сведения об этом параметре см. в разделе "Использование групп автоматической отработки отказа" для обеспечения прозрачной и согласованной отработки отказа нескольких баз данных.

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

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

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

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

  Важно!

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

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

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

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

• Настройка аварийного восстановления для многоуровневого развертывания приложения SAP
• Планирование и реализация виртуальных машин Azure для SAP
• Развертывание виртуальных машин Azure для SAP NetWeaver
• SAP NetWeaver на виртуальных машинах Azure. Руководство по развертыванию СУБД SQL Server