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

  • Статья

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

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

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

  • Доступность служб и бизнес-процессов.
  • Целевые значения времени восстановления (RTO) для сценариев сбоя или аварий.
  • Цели точек восстановления (RPO) для сценариев сбоя.
  • Операционные задачи и задачи управления жизненным циклом, а также технологии, которые заполняются во время сценариев сбоя. Эти задачи управления включают исправление гостевых операционных систем и систем управления базами данных, клонирование и обновление систем SAP.

Совет

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

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

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

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

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

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

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

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

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

  • Системы управления базами данных.
  • Отдельные точки отказа в приложении, например SAP ABAP и ASCS + SCS. Примеры: SAP NetWeaver и архитектура SAP S/4HANA.
  • Другие средства, такие как SAP Web Dispatcher.

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

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

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

Для уровня СУБД общий шаблон архитектуры заключается в том, чтобы реплицировать базы данных одновременно и с разными стеками хранилища, чем те, которые используются основной и вторичной виртуальными машинами. Azure не поддерживает архитектуры, в которых основная и вторичная виртуальные машины совместно используют хранилище для данных СУБД. Также не поддержка Azure журналы транзакций или повторов. Основной принцип заключается в использовании двух независимых стеков хранилища, даже если они основаны на общих ресурсах NFS. Этот подход является ограничением main при сравнении возможных локальных возможностей с тем, что возможно в 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.

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

Уровень Сценарий высокого уровня доступности Соглашение об уровне обслуживания платформы
Уровень 1 Зона доступности 99,99 %
Уровень 2 Группа доступности 99,95 %
Уровень 3 Одна виртуальная машина (самовосстановление) 99,9 %

Дополнительные сведения см. в следующем разделе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При резервном копировании и восстановлении локальной среды необходимо перенести эти возможности в системы SAP в Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Хранилище уровня "Стандартный" можно реплицировать между парными регионами, но нельзя использовать хранилище уровня "Стандартный" для хранения баз данных или виртуальных жестких дисков. Реплицировать резервные копии можно только между парными регионами, которые вы используете. Для всех остальных данных запустите репликацию с помощью собственных функций СУБД, таких как SQL Server Always On или репликация системы 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.
  • В качестве альтернативы использованию ExpressRoute рассмотрите возможность настройки VPN-подключений из локальной среды в основной и дополнительный регионы аварийного восстановления Azure.
  • Используйте 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 уровня "Премиум" в двух регионах.
  • Рассмотрите возможность группирования систем на основе их бизнес-важности и зависимости близкого взаимодействия на основе производительности приложений. Разверните каждую группу в отдельном регионе в парном регионе, чтобы свести к минимуму влияние регионального сбоя на бизнес. Например, две критически важные системы ECC, обслуживающие два разных бизнес-подразделения, можно развернуть в южной части Соединенного Королевства и в западной части Соединенного Королевства, чтобы свести к минимуму последствия регионального сбоя.

Дальнейшие действия

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