Непрерывность бизнес-процессов и аварийное восстановление для миграции SAP

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

Сценарий и область

Включайте принципы в архитектуру, которая использует сценарии локальной непрерывности бизнес-процессов и аварийного восстановления (BCDR). Эти принципы также применяются в Azure. Но Azure может иметь большую емкость оборудования, чем локальная среда, чтобы компенсировать сбой узла. Чтобы автоматически восстановить даже самые крупные виртуальные машины Azure, их можно настроить для перезапуска на другом сервере. Настройте развертывания Azure, чтобы использовать те же условия, что и локальные развертывания. Если вы используете конфигурации отказоустойчивого кластера для развертывания локальных систем или оборудования без операционной системы, разверните их так же в Azure. Для приложений SAP, выполняющих наиболее важные бизнес-процессы организации, требуются:

• Доступность служб и бизнес-процессов.

• Цели времени восстановления (ОСРВ) для сценариев сбоя или аварийных сценариев.

• Цели точки восстановления (RPOS) для сценариев сбоя.

• Задачи управления операционным и жизненным циклом, а также технологии, выполняемые во время сценариев сбоя. Эти задачи управления включают исправление гостевых операционных систем и систем управления базами данных, клонирование и обновление систем SAP.

В этой статье рассматриваются следующие аспекты BCDR для сценария SAP корпоративного масштаба:

• Высокий уровень доступности в регионе Azure

• Вопросы резервного копирования и восстановления

• Критерии для выбора между межрегионарным и региональным аварийном восстановлением

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

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

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

При реализации высокой доступности цель — обеспечить доступность для единой точки сбоя программного обеспечения SAP, например:

• Системы управления базами данных.

• Отдельные точки сбоя в приложении, такие как программирование приложений SAP Advanced Business Application (ABAP), ABAP SAP Central Services (ASCS) и SAP Central Services (SCS). Примеры высокой доступности включают SAP NetWeaver и архитектуру SAP S/4HANA.

• Другие средства, такие как веб-диспетчер SAP.

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

SAP и базы данных SAP поддерживают кластеры автоматического перехода на другой ресурс. В Windows функция отказоустойчивой кластеризации Windows Server 2022 поддерживает отработку отказа. В Linux, Linux Pacemaker или партнерские инструменты, такие как SIOS Protection Suite и Veritas InfoScale, поддерживают отработку отказа. В Azure можно развернуть только конфигурацию высокого уровня доступности в собственном центре обработки данных.

Дополнительные сведения см. в статье "Поддерживаемые сценарии для рабочих нагрузок SAP на виртуальных машинах Azure" и поддерживаемых сценариях для крупных экземпляров SAP HANA.

Для уровня СУБД общий шаблон архитектуры заключается в том, чтобы реплицировать базы данных одновременно и с различными стеками хранилища, отличными от используемых первичными виртуальными машинами и вторичными виртуальными машинами. Azure не поддерживает архитектуры, в которых основные виртуальные машины и вторичные виртуальные машины совместно используют хранилище для данных СУБД. Azure также не поддерживает журналы транзакций или журналы повторного входа. Основной принцип — использовать два независимых стека хранилища, даже если они основаны на общих папках сетевой файловой системы (NFS). Эти ограничения являются эксклюзивными для решений Azure, а не локальными решениями.

Azure предоставляет другие варианты, так как она поддерживает общий доступ к NFS и блоку сообщений сервера. Общие диски Azure можно использовать в Windows для КОМПОНЕНТОВ ASCS и SCS и конкретных сценариев высокой доступности. Настройте отказоустойчивые кластеры отдельно для компонентов уровня приложений SAP и уровня СУБД. Azure не поддерживает архитектуры высокой доступности, которые объединяют компоненты уровня приложений SAP и уровень СУБД в один отказоустойчивый кластер.

Большинство отказоустойчивых кластеров для компонентов уровня приложений SAP и уровня СУБД требуют виртуального IP-адреса для отказоустойчивого кластера. Часто возникает исключение при использовании Oracle Data Guard, для которого не требуется виртуальный IP-адрес. Azure Load Balancer должен обрабатывать виртуальный IP-адрес во всех остальных случаях. Для каждой конфигурации кластера можно использовать одну подсистему балансировки нагрузки. Рекомендуется использовать стандартную версию подсистемы балансировки нагрузки. Дополнительные сведения см. в статье о подключении к общедоступной конечной точке для виртуальных машин с помощью Azure Load Balancer уровня "Стандартный" в сценариях высокой доступности SAP.

Дополнительные сведения см. в статье о архитектуре высокого уровня доступности и сценариях sap NetWeaver.

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

Группы доступности Azure и зоны доступности

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

• Виртуальные машины не распределяются по разным зонам доступности.

• Тип виртуальных машин, которые можно развернуть с помощью одного набора доступности, ограничен, так как первая виртуальная машина, развернутая в наборе, определяет узел. Например, нельзя объединить виртуальные машины серии M и виртуальные машины серии E в одну группу доступности.

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

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

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

Если вы используете зоны доступности в решении SAP, создайте все остальные службы Azure и компоненты инфраструктуры в ландшафте SAP для избыточности зон, чтобы обеспечить истинное избыточность зоны. Примеры служб и компонентов, которые необходимо учитывать, включают шлюзы Azure ExpressRoute, Load Balancer, Файлы Azure, Azure NetApp Files, обратные прокси-серверы, брандмауэры, антивирусные службы и инфраструктуру резервного копирования.

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

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

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

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

• При создании групп доступности используйте максимальное количество доменов сбоя и доступных доменов обновления. Например, если развернуть более двух виртуальных машин в одной группе доступности, используйте максимальное количество доменов сбоя (три). И используйте достаточно доменов обновления, чтобы ограничить влияние потенциальных сбоев физического оборудования, сетевых сбоев или прерываний питания в дополнение к запланированному обслуживанию Azure. Число доменов сбоя по умолчанию — два, и вы не можете изменить его в сети позже.

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

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

• Если вы используете группы размещения близкого взаимодействия, используйте один для каждого идентификатора системы SAP (SID). Группы не охватывают зоны доступности или регионы Azure.

• При использовании групп размещения близкого взаимодействия Azure в развертывании зон доступности убедитесь, что два компонента SAP (центральные службы и сервер приложений) находятся в одной группе размещения близкого взаимодействия. Виртуальные машины базы данных в двух зонах больше не являются частью групп размещения близкого взаимодействия. Группы размещения близкого взаимодействия для каждой зоны ограничены развертыванием виртуальной машины, на которой выполняются экземпляры SAP ASCS и SCS. Преимущество этой конфигурации заключается в том, что у вас есть больше гибкости для изменения размера виртуальных машин. Вы также можете легко переключаться на новые типы виртуальных машин в уровне СУБД или на уровне приложения системы SAP.

• Azure не поддерживает объединение ASCS и базы данных с высоким уровнем доступности в одном кластере Linux Pacemaker. Разделите их на отдельные кластеры. Можно объединить до пяти кластеров центральных служб в паре виртуальных машин.

• Используйте Load Balancer (цен. категория перед кластерами ASCS и баз данных.

• Запустите все производственные системы на ssd Azure Premium и используйте Azure NetApp Files или хранилище дисков Azure Ultra. Как минимум, убедитесь, что диск ОС находится на уровне "Премиум", чтобы повысить производительность и получить лучшее соглашение об уровне обслуживания.

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

• Используйте собственную технологию репликации баз данных для синхронизации базы данных в паре высокой доступности.

• Используйте одну из следующих служб для запуска кластеров центральных служб SAP в зависимости от ОС:

  • Кластер SUSE Linux Enterprise Server Pacemaker поддерживает агент забора Azure и не более трех устройств изоляции узлов.

  • Кластер Red Hat Enterprise Linux Pacemaker поддерживает агент забора Azure и не поддерживает устройства изоляции узлов.

  • Кластер Windows.

  • Программное обеспечение кластера, сертифицированное не от Майкрософт, с сертификатом SAP.

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

Хранилище для рабочих нагрузок SAP

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

• Вы должны запускать SAP HANA в Azure только в сертифицированных SAP типах хранилища. Для определенных конфигураций дисков необходимо запустить определенные тома. Например, конфигурации могут включать ускоритель записи или использовать хранилище SSD класса Premium. Кроме того, необходимо убедиться, что файловая система, которая выполняется в хранилище, совместима с СУБД, работающей на компьютере. Дополнительные сведения см. в разделе "Конфигурации хранилища" для SAP HANA.

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

  Тип хранилища	Поддержка конфигурации высокой доступности
  Общие диски Azure (локально избыточное хранилище (LRS) или хранилище, избыточное между зонами (ZRS))	Отказоустойчивый кластер Windows Server 2022. Дополнительные сведения о конфигурации см. в разделе "Проектирование высокой доступности SAP с помощью отказоустойчивой кластеризации Windows Server 2022".
  NFS на Файлы Azure (LRS или ZRS)	Кластер на основе Pacemaker в средах Linux. Обязательно проверьте доступность NFS в различных регионах.
  NFS в Azure NetApp Files	Кластер на основе Pacemaker в средах Linux. Дополнительные сведения см. в статье Azure NetApp Files для виртуальных машин SAP.
  SMB на Файлы Azure (LRS или ZRS)	Отказоустойчивый кластер Windows Server 2022. Дополнительные сведения о конфигурации см. в разделе "Установка sap NetWeaver с высоким уровнем доступности" с помощью Файлы Azure SMB.
  SMB в Azure NetApp Files	Отказоустойчивый кластер Windows Server 2022. Дополнительные сведения о конфигурации см. в разделе "Высокий уровень доступности для SAP NetWeaver" с помощью Azure NetApp Files (SMB) для приложений SAP.

• Вместо служб общего хранилища Azure можно использовать традиционные кластеры NFS (на основе репликации распределенных реплицированных блочных устройств), GlusterFS или общий том кластера с Локальные дисковые пространства в качестве альтернативного общего решения для хранения рабочих нагрузок SAP в Azure. Эти варианты особенно полезны, если службы общего хранилища Azure либо недоступны в целевом регионе Azure, либо не поддерживают целевую архитектуру. Дополнительные сведения о доступности службы хранилища см. в продуктах Azure по регионам.

• Сведения о вариантах хранения, доступных для рабочих нагрузок SAP в Azure, см . в рекомендациях и рекомендациях по настройке аварийного восстановления.

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

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

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

• Выполните восстановление на определенный момент времени для рабочих баз данных в любой момент времени, соответствующего RTO. Восстановление на определенный момент времени обычно обеспечивает защиту от ошибок оператора, таких как удаление данных на уровне СУБД или с помощью SAP.

• Сохраняйте хранилище, чтобы сохранить долгосрочные резервные копии, чтобы соответствовать нормативным требованиям.

• Используйте резервные копии базы данных для клонирования системы SAP и восстановления резервных копий на другом сервере или виртуальной машине.

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

• Резервное копирование серверов приложений SAP и виртуальных машин, дисков или моментальных снимков виртуальных машин.

• Резервное копирование системы SAP HANA с включенной репликацией.

• Резервное копирование моментальных снимков экземпляра базы данных SAP HANA.

При резервном копировании и восстановлении локальной среды необходимо перенести эти возможности в системы SAP в Azure. Если вам нравится текущее решение, проверьте, поддерживает ли поставщик резервного копирования развертывания Azure или имеет ли оно программное обеспечение как услуга (SaaS) для Azure.

Azure предоставляет службу SaaS резервного копирования с именем Azure Backup, которая принимает моментальные снимки виртуальных машин и управляет потоковой передачей резервных копий SQL Server и SAP HANA . Если вы используете Azure NetApp Files для хранения баз данных SAP HANA, можно запускать резервные копии на основе моментальных снимков хранилища, согласованных с HANA.

Вы также можете использовать Azure Backup для резервного копирования баз данных, в которых включена репликация системы SAP HANA (HSR). Azure Backup автоматически управляет резервными копиями при отработки отказа и устраняет необходимость вмешательства вручную. Резервное копирование также предоставляет:

• Немедленная защита без полного резервного копирования, поэтому вы можете защитить экземпляры HANA или узлы установки HSR в виде одного контейнера HSR.

• Преимущество мгновенного резервного копирования и мгновенного восстановления.

• Согласованный с HANA подход на основе моментальных снимков, который интегрируется с Backint для SAP HANA. Резервное копирование можно использовать в качестве одного продукта для всего ландшафта HANA и для любого размера базы данных.

Дополнительные сведения см. в статье о системе базы данных SAP HANA с включенной репликацией и резервном копировании моментальных снимков экземпляра SAP HANA.

Рекомендации по проектированию резервного копирования и восстановления

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

• Резервное копирование SAP HANA можно использовать для развертываний HANA размером до 8 ТБ. Дополнительные сведения см. в таблице поддержки для резервного копирования баз данных SAP HANA на виртуальных машинах Azure.

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

• Проверьте время резервного копирования и восстановления, чтобы убедиться, что они соответствуют требованиям RTO для восстановления всех систем одновременно после аварии.

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

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

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

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

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

Карта регионов Azure включает более 65 регионов Azure, а не все они выполняют одни и те же службы. Для более крупных развертываний программного обеспечения SAP, особенно тех, которые используют SAP HANA, найдите регионы Azure, которые предлагают виртуальные машины серии Azure серии Azure или виртуальные машины серии Mv2. Служба хранилища Azure также объединяет регионы в пары для репликации меньшей части типов хранилища в другой регион. Дополнительные сведения см. в статье Обзор парных регионов Azure.

Основные проблемы, связанные с созданием пар регионов Azure для рабочих нагрузок SAP:

• Эти пары не всегда согласуются со службами виртуальных машин серии M или Mv2. Многие организации, которые развертывают свои системы SAP, не используют парные регионы Azure. Вместо этого они выбирают регионы на основе доступности необходимых типов виртуальных машин.

• Вы можете реплицировать стандартное хранилище между парными регионами, но для хранения баз данных или виртуальных жестких дисков нельзя использовать стандартное хранилище. Резервные копии можно реплицировать только между парными регионами, которые вы используете. Для всех остальных данных запустите репликацию с помощью собственных функций СУБД, таких как sql Server AlwaysOn или репликация системы SAP HANA. Используйте сочетание средств Site Recovery, таких rsync как или robocopyдругое программное обеспечение, отличное от Майкрософт, для уровня приложений SAP.

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

Еще одним важным фактором является обеспечение требуемой операционной емкости в регионе аварии. При возникновении аварии может потребоваться запустить приложение SAP для минимального периода времени с минимальным объемом ИТ-ресурсов и критически важных кадров только во время восстановления нормальной работы в основном регионе. Эта стратегия требует, чтобы у вас была минимальная ИТ-инфраструктура, доступная в регионе аварийного восстановления.

После определения регионов Azure необходимо выбрать шаблон развертывания:

• Развертываете рабочие системы в основном регионе?

• Развертывать непроизводственные системы SAP в регионе аварийного восстановления?

• Будет ли использоваться архитектура, которая группует все системы SAP в основной регион? Эта конфигурация гарантирует, что регион аварийного восстановления используется только для аварийного восстановления.

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

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

В некоторых организациях используется сочетание архитектуры высокого уровня доступности и аварийного восстановления, которая группировать высокий уровень доступности с аварийным восстановлением в одном регионе Azure. Но группирование высокого уровня доступности с помощью аварийного восстановления не идеально подходит. Зоны доступности Azure поддерживают эту архитектуру. Расстояние между зонами доступности в одном регионе Azure не так велико, как расстояние между двумя регионами Azure, поэтому стихийная катастрофа может поставить под угрозу службы приложений в регионе, где она происходит. Кроме того, необходимо учитывать задержку между серверами приложений SAP и серверами баз данных. Согласно заметке SAP 1100926, время округления меньше или равно 0,3 мс является хорошим значением, а время меньше или равно 0,7 мс является умеренным значением. Поэтому для зон с высокой задержкой есть операционные процедуры, чтобы гарантировать, что серверы приложений SAP и серверы баз данных всегда выполняются в одной зоне. Организации выбирают эту архитектуру по следующим причинам:

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

• Суверенитет данных является фактором.

• Геополитические факторы участвуют.

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

Еще одним фактором, который следует учитывать при выборе региона аварийного восстановления, является RPO и RTO для отработки отказа на сайт аварийного восстановления. Чем больше расстояние между рабочим регионом и регионами аварийного восстановления, тем выше задержка сети. Асинхронная репликация между регионами Azure, но задержка в сети может повлиять на пропускную способность, которую можно реплицировать и целевой объект RPO. Чтобы свести к минимуму RPO, можно использовать объединенную архитектуру высокого уровня доступности и аварийного восстановления. Но эта конфигурация представляет собой потенциально более высокий риск от крупномасштабных стихийных бедствий.

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

• Убедитесь, что маршрутизация между доменами (CIDR) для основной виртуальной сети не конфликтует или не перекрывается с CIDR виртуальной сети сайта аварийного восстановления.

• Настройте подключения ExpressRoute из локальной среды к основным и вторичным регионам аварийного восстановления Azure.

• Попробуйте настроить VPN-подключения из локальной среды к основным и вторичным регионам аварийного восстановления Azure. Используйте этот метод в качестве альтернативы использованию ExpressRoute.

• Используйте Site Recovery для репликации сервера приложений на сайт аварийного восстановления. Site Recovery также помогает реплицировать виртуальные машины кластера центральных служб на сайт аварийного восстановления. При вызове аварийного восстановления необходимо перенастроить кластер Linux Pacemaker на сайте аварийного восстановления. Например, может потребоваться заменить виртуальный IP-адрес или SBD или запустить corosync.conf.

• Репликация содержимого хранилища ключей, таких как сертификаты, секреты или ключи в регионах, чтобы расшифровать данные в регионе аварийного восстановления.

• Используйте репликацию между регионами в Azure NetApp Files для синхронизации томов файлов между основным регионом и регионом аварийного восстановления.

• Используйте собственную репликацию базы данных, а не Site Recovery, чтобы синхронизировать данные с сайтом аварийного восстановления.

• Пиринг основных и аварийного восстановления виртуальных сетей. Например, для репликации системы HANA необходимо выполнить пиринг виртуальной сети SAP HANA DB, необходимой для виртуальной сети SAP HANA DB сайта аварийного восстановления.

• Если вы используете хранилище Azure NetApp Files для развертываний SAP, как минимум, создайте две учетные записи Azure NetApp Files на уровне "Премиум" в двух регионах.

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

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

Варианты развертывания для SAP в Azure