Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Чтобы настроить аварийное восстановление для рабочей нагрузки 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" и установки веб-диспетчера SAP в Azure.
- Вариант 1. Высокий уровень доступности с помощью решения кластера.
- Вариант 2. Высокий уровень доступности с параллельными веб-диспетчерами SAP.
Чтобы обеспечить аварийное восстановление для высокодоступной установки веб-диспетчера SAP в основном регионе, можно использовать Azure Site Recovery. Для параллельных веб-диспетчеров (вариант 2), работающих в основном регионе, можно настроить Azure Site Recovery для достижения аварийного восстановления данных (DR). Но для веб-диспетчера 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 Web Dispatcher с использованием кластерного решения Pacemaker, то аналогичные соображения также будут применяться.
Внутренняя подсистема балансировки нагрузки
Azure Site Recovery реплицирует виртуальные машины на сайт аварийного восстановления, но не реплицирует подсистему балансировки нагрузки Azure. Вам потребуется создать отдельный балансировщик внутренней нагрузки на площадке аварийного восстановления до этого или после устранения отказа. При создании внутренней подсистемы балансировки нагрузки заранее создайте пустой внутренний пул и добавьте виртуальные машины после события отработки отказа.
Решение кластера Pacemaker
Конфигурации кластера Pacemaker хранятся в локальных файлах виртуальных машин, которые реплицируются на площадку для аварийного восстановления с помощью Azure Site Recovery. Конфигурация кластера pacemaker в исходном виде не будет работать без дополнительной настройки на виртуальных машинах после переключения в случае отказа. Для обеспечения работы решения требуется дополнительная перенастройка кластера.
Ознакомьтесь с этими блогами, чтобы узнать о перенастройке кластера Pacemaker в регионе аварийного восстановления в зависимости от типа вашего хранилища и механизма изоляции.
- Кластер SAP ASCS/ERS HA с устройством SBD (с использованием целевого сервера iSCSI), переключение на регион аварийного восстановления с помощью Azure Site Recovery.
- Переключение отказоустойчивого кластера SAP ASCS (в ОС Linux) в резервный регион с помощью Azure Site Recovery.
Общие каталоги SAP для Linux
Настройка высокой доступности платформы SAP NetWeaver или ABAP использует сервер репликации enqueue для достижения резервирования на уровне приложения для службы enqueue системы SAP с конфигурацией кластера Pacemaker. Установка высокого уровня доступности центральных служб SAP (ASCS и ERS) использует подключения NFS. Поэтому необходимо убедиться, что двоичные файлы SAP и данные в этих монтажах NFS реплицируются на сайт восстановления. Azure Site Recovery реплицирует виртуальные машины и подключенный локальный управляемый диск, но не реплицирует подключения NFS. В зависимости от типа хранилища NFS, настроенного для установки, необходимо убедиться, что данные реплицируются и доступны на сайте аварийного восстановления. Методология межрегиональной репликации для каждого хранилища представлена на абстрактном уровне. Необходимо подтвердить точные шаги для репликации хранилища и выполнения тестирования.
| Общие каталоги SAP | Межрегиональная репликация |
|---|---|
| NFS в файлах Azure | Пользовательский (например, rsync) |
| NFS в ANF | Да (репликация между регионами) |
| Кластер NFS | Индивидуальное |
Совет
Мы рекомендуем развернуть одну из первичных служб NFS Azure: NFS на Azure Files или NFS на томах ANF для хранения общих данных в высокодоступной системе SAP. Помните, что мы не подчеркиваем эталонные архитектуры SAP, используя кластеры NFS.
Механизм ограждения
Независимо от операционной системы (SLES или RHEL) и её версии, pacemaker требует допустимого механизма защиты для правильной работы всей системы. В зависимости от типа механизма фенсинга, который вы настроили в основном регионе, необходимо убедиться, что тот же механизм фенсинга настроен на площадке аварийного восстановления после перехода на резервный узел.
| Механизм ограждения | Рекомендация по аварийному восстановлению между регионами |
|---|---|
| SBD с помощью целевого сервера iSCSI | Репликация целевого сервера iSCSI с помощью Azure Site Recovery.
На виртуальных машинах аварийного восстановления снова обнаружьте диск iSCSI. |
| Агент ограждения Azure | Включите удостоверения управляемой системы (MSI) на виртуальных машинах DR. Назначьте пользовательские роли. Обновите ресурс агента ограждения в кластере. |
| 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 Data Guard (FarSync) |
| IBM DB2 | Аварийное восстановление высокого уровня доступности (HADR) |
| Microsoft SQL | Microsoft SQL AlwaysOn |
| SAP ASE | ASE HADR AlwaysOn |
| SAP MaxDB | Резервная база данных |
Для оптимизированного по затратам решения можно даже использовать вариант резервного копирования и восстановления в стратегии DR базы данных.
Резервное копирование и восстановление
Резервное копирование и восстановление — это другое решение, которое можно использовать для аварийного восстановления рабочих нагрузок SAP, если бизнес-RTO и RPO некритичны. Вы можете использовать azure backup, облачную службу резервного копирования для копирования различных компонентов рабочей нагрузки SAP, таких как виртуальные машины, управляемые диски и поддерживаемые базы данных. Для получения дополнительной информации об общих параметрах и ограничениях поддержки для сценариев и развертываний Azure Backup см. таблицу поддержки Azure Backup.
| Службы | Компонент | Поддержка Службы архивации Azure |
|---|---|---|
| Вычислять | Виртуальные машины Azure | Поддерживается |
| Хранилище | Управляемые диски Azure, включая общие диски | Поддерживается |
| Хранилище | Файловый ресурс Azure — SMB (стандартный или премиум) | Поддерживается |
| Хранилище | Блобы Azure | Поддерживается |
| Хранилище | Общий файловый ресурс Azure — NFS (стандартный или премиум-класса) | Не поддерживается |
| Хранилище | Файлы Azure NetApp | Не поддерживается |
| База данных | База данных SAP HANA на виртуальных машинах Azure | Поддерживается |
| База данных | SQL Server на виртуальных машинах Azure | Поддерживается |
| База данных | Оракул | Поддерживается* |
| База данных | IBM DB2, SAP ASE | Не поддерживается |
Примечание.
*Резервное копирование Azure поддерживает базу данных Oracle с помощью резервного копирования виртуальных машин Azure для согласованных моментальных снимков базы данных.
Служба архивации Azure не поддерживает все хранилища и базы данных Azure, используемые для рабочей нагрузки SAP.
Служба архивации Azure сохраняет резервные копии в хранилище служб восстановления, которое реплицирует данные на основе выбранного типа репликации (LRS, ZRS или GRS). Для геоизбыточного хранилища (GRS) данные резервного копирования реплицируются в связанный вторичный регион. С включенной функцией восстановления между регионами можно восстановить данные поддерживаемого типа управления в дополнительном регионе.
Резервное копирование и восстановление — это более традиционный подход, оптимизированный по затратам, но он сопряжён с компромиссом в виде большего времени восстановления (RTO). Необходимо восстановить все приложения из резервной копии, если происходит переключение на регион аварийного восстановления. Поэтому необходимо проанализировать потребности бизнеса и соответствующим образом разработать стратегию аварийного восстановления.