Рекомендации по аварийному восстановлению для приложения SAP

Чтобы настроить аварийное восстановление (DR) для рабочей нагрузки SAP в Azure, необходимо регулярно тестировать, настраивать и обновлять процесс. Тестирование аварийного восстановления помогает определить последовательность зависимых служб, необходимых перед запуском отработки отказа рабочей нагрузки SAP drover или запуском системы на вторичном сайте. Организации обычно имеют системы SAP, подключенные к службам Active Directory (AD) и dns для правильной работы. При настройке аварийного восстановления для рабочей нагрузки SAP перед восстановлением SAP и других систем, не относящихся к SAP, убедитесь, что службы AD и DNS работают правильно. Рекомендации по защите Active Directory и DNS см. в статье Настройка аварийного восстановления для Active Directory и DNS. Рекомендации по аварийному обеспечению для приложений SAP, описанные в этом документе, приведены на абстрактном уровне. Необходимо разработать стратегию аварийного восстановления на основе конкретной настройки и задокументировать комплексный сценарий.

Рекомендации по аварийному обеспечению для рабочих нагрузок SAP

Обычно в распределенных системах SAP NetWeaver; центральные службы, база данных и общее хранилище (NFS/SMB) являются единой точкой отказа (SPOF). Чтобы уменьшить влияние различных SPOF, необходимо настроить избыточность этих компонентов. Избыточность этих компонентов SPOF в основном регионе достигается путем настройки высокого уровня доступности. Установка высокого уровня доступности компонента защищает систему SAP от локального сбоя или аварии. Но для защиты приложений SAP от географически распределенных аварий необходимо реализовать стратегию аварийного восстановления для всех компонентов SAP.

Для систем SAP, работающих на виртуальных машинах, можно использовать azure Site Recovery для создания плана аварийного восстановления. Ниже приведен рекомендуемый подход к аварийному восстановлению для каждого компонента системы SAP. В этом документе не рассматриваются автономные подсистемы SAP, не относящиеся к NetWeaver, такие как TREX и приложения, не относящиеся к SAP.

Компоненты Рекомендация
Веб-диспетчер SAP Репликация виртуальной машины с помощью azure Site Recovery
Центральные службы SAP Репликация виртуальной машины с помощью azure Site Recovery
Сервер приложений SAP Репликация виртуальной машины с помощью azure Site Recovery
База данных SAP Использование метода репликации, предлагаемого базой данных
Общее хранилище Репликация содержимого с использованием соответствующего метода для каждого типа хранилища

Веб-диспетчер SAP

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

  • Вариант 1. Высокий уровень доступности с помощью решения кластера.
  • Вариант 2. Высокий уровень доступности с параллельными веб-диспетчерами SAP.

Чтобы обеспечить аварийное восстановление для установки высокодоступного веб-диспетчера SAP в основном регионе, можно использовать azure Site Recovery. Для параллельных веб-диспетчеров (вариант 2), работающих в основном регионе, можно настроить azure Site Recovery для достижения аварийного восстановления. Но если вы настроили SAP Web Dispatcher с помощью варианта 1 в основном регионе, необходимо внести некоторые дополнительные изменения после отработки отказа, чтобы настроить аналогичную настройку высокого уровня доступности в регионе аварийного восстановления. Так как конфигурация высокого уровня доступности SAP Web Dispatcher с кластерным решением настроена аналогично центральным службам SAP. Следуйте тем же рекомендациям, что и для центральных служб SAP.

Центральные службы SAP

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

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

Для системы SAP избыточность компонента SPOF в основном регионе достигается путем настройки высокого уровня доступности. Чтобы обеспечить аналогичную настройку высокого уровня доступности в регионе аварийного восстановления после отработки отказа, необходимо учитывать дополнительные аспекты, такие как перенастройка кластера, доступность общих каталогов SAP, а также репликация виртуальных машин и подключенный управляемый диск на сайт аварийного восстановления с помощью azure Site Recovery. В Linux высокий уровень доступности приложения SAP можно достичь с помощью кластерного решения pacemaker. На схеме ниже показаны различные компоненты, участвующие в настройке высокого уровня доступности для центральных служб SAP с помощью Pacemaker. Каждый компонент необходимо учитывать, чтобы на сайте аварийного восстановления был настроен аналогичный высокий уровень доступности. Если вы настроили SAP Web Dispatcher с помощью кластерного решения pacemaker, будет также применяться аналогичный фактор.

Архитектура системы SAP в Linux

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

Azure Site Recovery реплицирует виртуальные машины на сайт аварийного восстановления, но не реплицирует Azure Load Balancer. Вам потребуется создать отдельную внутреннюю подсистему балансировки нагрузки на сайте аварийного восстановления заранее или после отработки отказа. Если вы заранее создали внутреннюю подсистему балансировки нагрузки, создайте пустой серверный пул и добавьте виртуальные машины после события отработки отказа.

Кластерное решение Pacemaker

Конфигурации кластера pacemaker находятся в локальных файлах виртуальных машин, которые реплицируются на сайт аварийного восстановления с помощью azure Site Recovery. Конфигурация кластера pacemaker "как есть" не будет работать на виртуальных машинах после отработки отказа. Для обеспечения работы решения требуется дополнительная перенастройка кластера.

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

Общие каталоги SAP для Linux

Установка высокого уровня доступности платформы SAP NetWeaver или ABAP использует сервер репликации в очередь для обеспечения избыточности на уровне приложений для службы постановки в очередь системы SAP с конфигурацией кластера Pacemaker. При настройке высокого уровня доступности центральных служб SAP (ASCS и ERS) используются подключения NFS. Поэтому необходимо убедиться, что двоичные файлы SAP и данные в этих подключениях NFS реплицируются на сайт аварийного восстановления. Azure Site Recovery реплицирует виртуальные машины и подключенный локальный управляемый диск, но не реплицирует подключения NFS. В зависимости от типа хранилища NFS, настроенного для установки, необходимо убедиться, что данные реплицированы и доступны на сайте аварийного восстановления. Методология межрегиональная репликации для каждого хранилища представлена на абстрактном уровне. Необходимо подтвердить точные действия для репликации хранилища и выполнения тестирования.

Общие каталоги SAP Межрегиональная репликация
NFS в файлах Azure Пользовательский (например, rsync)
NFS в ANF Да (репликация между регионами)
Кластер NFS Особые настройки

Совет

Мы рекомендуем развернуть одну из собственных служб NFS Azure: NFS на томах Файлы Azure или NFS ANF для хранения общих данных в высокодоступной системе SAP. Имейте в виду, что мы не акцентируем внимание на эталонных архитектурах SAP, используя кластеры NFS.

Механизм ограждения

Независимо от операционной системы (SLES или RHEL) и ее версии, pacemaker требует допустимый механизм ограждения для правильной работы всего решения. В зависимости от типа механизма ограждения, настроенного в основном регионе, необходимо убедиться, что тот же механизм ограждения настроен на сайте аварийного восстановления после отработки отказа.

Механизм ограждения Рекомендация по аварийному обеспечению между регионами
SBD с использованием целевого сервера iSCSI Репликация целевого сервера iSCSI с помощью azure Site Recovery.
На виртуальных машинах аварийного восстановления снова обнаружите диск iSCSI.
Агент ограждения Azure Включите управляемые системные удостоверения (MSI) на виртуальных машинах аварийного восстановления.
Назначение пользовательских ролей.
Обновите ресурс агента ограждения в кластере.
SBD с использованием общего диска Azure* Настройте новый общий диск Azure в регионе аварийного восстановления. Подключите общий диск Azure к виртуальным машинам аварийного восстановления после отработки отказа.
Настройка устройства SBD с общим диском Azure.

*ZRS для общего диска Azure доступен в ограниченных регионах.

Примечание

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

Серверы приложений SAP

В основном регионе избыточность серверов приложений SAP достигается путем установки экземпляров на нескольких виртуальных машинах. Чтобы обеспечить аварийное восстановление для серверов приложений SAP, Site Recovery Azure можно настроить для каждой виртуальной машины сервера приложений. Для общих хранилищ (файловая система транспорта, файловая система интерфейсных данных), подключенных к серверам приложений, следуйте соответствующей методике аварийного восстановления в зависимости от типа общего хранилища.

Серверы баз данных SAP

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

База данных Рекомендации по аварийному обеспечению
SAP HANA Репликация системы HANA (HSR)
Oracle; Oracle Data Guard (FarSync)
IBM DB2 Аварийное восстановление с высоким уровнем доступности (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE Always On ASE HADR
SAP MaxDB Резервная база данных

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

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

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

Службы Компонент Поддержка Azure Backup
Вычисления Виртуальные машины Azure Поддерживается
Память Azure Управляемые диски, включая общие диски Поддерживается
Память Общая папка Azure — SMB (цен. категория "Стандартный" или "Премиум") Поддерживается
Память Большие двоичные объекты Azure Поддерживается
Память Общий доступ к файлам Azure — NFS (цен. категория "Стандартный" или "Премиум") Не поддерживается
Память Azure NetApp Files Не поддерживается
База данных База данных SAP HANA на виртуальных машинах Azure Поддерживается
База данных SQL Server на виртуальных машинах Azure Поддерживается
База данных Oracle Поддерживается*
База данных IBM DB2, SAP ASE Не поддерживается

Примечание

*Azure Backup поддерживает базу данных Oracle с помощью резервного копирования виртуальных машин Azure для создания моментальных снимков, согласованных с базами данных.

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

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

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

Ссылки