Рекомендации по аварийному восстановлению для приложения SAP
Чтобы настроить аварийное восстановление для рабочей нагрузки SAP в Azure, необходимо регулярно проверять, настраивать и обновлять процесс. Тестирование аварийного восстановления помогает определить последовательность зависимых служб, необходимых для запуска отработки отказа рабочей нагрузки SAP или запуска системы на вторичном сайте. Организации обычно имеют свои системы SAP, подключенные к службам Active Directory (AD) и доменных имен (DNS), чтобы правильно функционировать. При настройке аварийного восстановления для рабочей нагрузки SAP убедитесь, что службы AD и DNS работают перед восстановлением SAP и других систем, отличных от SAP, чтобы обеспечить правильность работы приложений. Рекомендации по защите Active Directory и DNS см. в статье Настройка аварийного восстановления для Active Directory и DNS. Рекомендация аварийного восстановления для приложения SAP, описанного в этом документе, находится на абстрактном уровне. Необходимо разработать стратегию аварийного восстановления на основе конкретной настройки и документировать комплексный сценарий.
Рекомендация ПО аварийного восстановления для рабочих нагрузок SAP
Обычно в распределенных системах SAP NetWeaver; центральные службы, база данных и общее хранилище (NFS/SMB) являются одной точкой сбоев (SPOF). Чтобы уменьшить влияние различных SPOFs, необходимо настроить избыточность этих компонентов. Избыточность этих компонентов 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" и установки веб-диспетчера SAP в Azure.
- Вариант 1. Высокий уровень доступности с помощью решения кластера.
- Вариант 2. Высокий уровень доступности с параллельными веб-диспетчерами SAP.
Чтобы обеспечить аварийное восстановление для высокодоступной установки веб-диспетчера SAP в основном регионе, можно использовать Azure Site Recovery. Для параллельных веб-диспетчеров (вариант 2), работающих в основном регионе, можно настроить Azure Site Recovery для достижения аварийного восстановления. Но для веб-диспетчера SAP, настроенного с помощью параметра 1 в основном регионе, необходимо внести некоторые дополнительные изменения после отработки отказа, чтобы иметь аналогичную настройку высокого уровня доступности в регионе аварийного восстановления. Так как конфигурация веб-диспетчера SAP с высоким уровнем доступности с решением кластера настроена аналогично центральным службам SAP. Следуйте тем же рекомендациям, что и упоминалось для служб SAP Central.
Центральные службы SAP
Центральные службы SAP содержат сервер запросов и сообщений, который является одним из SPOF приложения SAP. В системе SAP может быть только один такой экземпляр, и его можно настроить для обеспечения высокой доступности. Ознакомьтесь с высоким уровнем доступности для SAP Central Service , чтобы понять различные решения с высоким уровнем доступности для рабочей нагрузки SAP в Azure.
Настройка высокой доступности для служб SAP Central Services защищает ресурсы и процессы от локальных инцидентов. Чтобы обеспечить аварийное восстановление для служб SAP Central, можно использовать Azure Site Recovery. Azure Site Recovery реплицирует виртуальные машины и подключенные управляемые диски, но существуют дополнительные рекомендации по стратегии аварийного восстановления. Дополнительные сведения см. в следующем разделе на основе операционной системы, используемой для центральных служб SAP.
Для системы SAP избыточность компонента SPOF в основном регионе достигается путем настройки высокой доступности. Чтобы достичь аналогичной установки высокого уровня доступности в регионе аварийного восстановления после отработки отказа, необходимо рассмотреть дополнительные точки. К ним относятся перенастройка кластера, обеспечение доступности общих каталогов SAP, репликация виртуальных машин и управляемых дисков на сайт аварийного восстановления с помощью Azure Site Recovery. В Linux высокий уровень доступности приложения SAP можно достичь с помощью решения кластера Pacemaker. На схеме ниже показаны различные компоненты, участвующие в настройке высокого уровня доступности для центральных служб SAP с помощью Pacemaker. Каждый компонент должен учитываться для того, чтобы на сайте аварийного восстановления был настроен аналогичный высокий уровень доступности. Если вы настроили веб-диспетчер SAP с помощью решения кластера Pacemaker, аналогичные рекомендации также будут применены.
Внутренняя подсистема балансировки нагрузки
Azure Site Recovery реплицирует виртуальные машины на сайт аварийного восстановления, но не реплицирует подсистему балансировки нагрузки Azure. Вам потребуется создать отдельный внутренний балансировщик нагрузки на сайте аварийного восстановления заранее или после отработки отказа. При создании внутренней подсистемы балансировки нагрузки заранее создайте пустой внутренний пул и добавьте виртуальные машины после события отработки отказа.
Решение кластера Pacemaker
Конфигурации кластера pacemaker находятся в локальных файлах виртуальных машин, которые реплицируются на сайт аварийного восстановления с помощью Azure Site Recovery. Конфигурация кластера pacemaker as-is не будет работать вне поля на виртуальных машинах после отработки отказа. Для обеспечения работы решения требуется дополнительная перенастройка кластера.
Ознакомьтесь с этими блогами, чтобы узнать о перенастройке кластера Pacemaker в регионе аварийного восстановления на основе типа вашего хранилища и механизма ограждения.
- Кластер SAP ASCS/ERS HA с устройством SBD (с помощью целевого сервера iSCSI) отработки отказа в регион аварийного восстановления с помощью Azure Site Recovery.
- Отказоустойчивый кластер SAP ASCS (в ОС Linux) в регион аварийного восстановления с помощью Azure Site Recovery.
Общие каталоги SAP для Linux
Настройка высокой доступности платформы SAP NetWeaver или ABAP использует сервер репликации enqueue для обеспечения избыточности уровня приложения для службы очереди системы SAP с конфигурацией кластера Pacemaker. Установка высокого уровня доступности центральных служб SAP (ASCS и ERS) использует подключения NFS. Поэтому необходимо убедиться, что двоичные файлы SAP и данные в этих подключениях NFS реплицируются на сайт аварийного восстановления. Azure Site Recovery реплицирует виртуальные машины и подключенный локальный управляемый диск, но не реплицирует подключения NFS. В зависимости от типа хранилища NFS, настроенного для установки, необходимо убедиться, что данные реплицируются и доступны на сайте аварийного восстановления. Методология межрегиональная репликация для каждого хранилища представлена на абстрактных уровнях. Необходимо подтвердить точные шаги для репликации хранилища и выполнения тестирования.
| Общие каталоги SAP | Межрегиональная репликация |
|---|---|
| NFS в файлах Azure | Custom (например, 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, Azure Site Recovery можно настроить для каждой виртуальной машины сервера приложений. Для общих хранилищ (файловой системы транспорта, файловой системы интерфейса), присоединенной к серверам приложений, следуйте соответствующей практике аварийного восстановления на основе типа общего хранилища.
Серверы баз данных SAP
Для баз данных, на которых выполняется рабочая нагрузка SAP, используйте собственную технологию репликации СУБД для настройки аварийного восстановления. Использование Azure Site Recovery для баз данных не рекомендуется, так как оно не гарантирует согласованность базы данных и имеет ограничение на получение данных. Технология репликации для каждой базы данных отличается, поэтому следуйте соответствующим рекомендациям по базе данных. В следующей таблице приведен список баз данных, используемых для рабочих нагрузок SAP, и соответствующая рекомендация по аварийному аварийному восстановления.
| База данных | Рекомендация по аварийному аварийному восстановления |
|---|---|
| SAP HANA | Репликация системы HANA (HSR) |
| Oracle | Oracle Data Guard (FarSync) |
| IBM DB2 | Аварийное восстановление высокого уровня доступности (HADR) |
| Microsoft SQL | Microsoft SQL AlwaysOn |
| SAP ASE | ASE HADR AlwaysOn |
| SAP MaxDB | Резервная база данных |
Для оптимизированного для затрат решения можно даже использовать вариант резервного копирования и восстановления для стратегии аварийного восстановления базы данных.
Резервное копирование и восстановление
Резервное копирование и восстановление — это другое решение, которое можно использовать для аварийного восстановления рабочих нагрузок SAP, если бизнес-RTO и RPO некритичны. Вы можете использовать azure backup, облачную службу резервного копирования для копирования различных компонентов рабочей нагрузки SAP, таких как виртуальные машины, управляемые диски и поддерживаемые базы данных. Дополнительные сведения о общих параметрах и ограничениях поддержки для сценариев и развертываний Azure Backup см . в таблице поддержки Azure Backup.
| Службы | Компонент | Поддержка Службы архивации Azure |
|---|---|---|
| Службы вычислений | Виртуальные машины Azure | Поддерживается |
| Хранилище | Azure Управляемые диски включая общие диски | Поддерживается |
| Хранилище | Общая папка Azure — SMB (цен. категория "Стандартный" или "Премиум") | Поддерживается |
| Хранилище | Большие двоичные объекты Azure | Поддерживается |
| Хранилище | Общий доступ к файлам Azure — NFS (цен. категория "Стандартный" или "Премиум") | Не поддерживается |
| Хранилище | Azure NetApp Files | Не поддерживается |
| База данных | База данных SAP HANA на виртуальных машинах Azure | Поддерживается |
| База данных | SQL Server на виртуальных машинах Azure | Поддерживается |
| База данных | Oracle | Поддерживается* |
| База данных | IBM DB2, SAP ASE | Не поддерживается |
Примечание.
*Резервное копирование Azure поддерживает базу данных Oracle с помощью резервного копирования виртуальных машин Azure для согласованных моментальных снимков базы данных.
Служба архивации Azure не поддерживает все хранилища и базы данных Azure, используемые для рабочей нагрузки SAP.
Служба архивации Azure сохраняет резервные копии в хранилище служб восстановления, которое реплицирует данные на основе выбранного типа репликации (LRS, ZRS или GRS). Для геоизбыточного хранилища (GRS) данные резервного копирования реплицируются в парный дополнительный регион. С включенной функцией восстановления между регионами можно восстановить данные поддерживаемого типа управления в дополнительном регионе.
Резервное копирование и восстановление являются более традиционным подходом, оптимизированным для затрат, но поставляется с компромиссом с более высоким уровнем RTO. Как необходимо восстановить все приложения из резервной копии, если происходит отработка отказа в регион аварийного восстановления. Поэтому необходимо проанализировать потребности бизнеса и соответствующим образом разработать стратегию аварийного восстановления.