Общие сведения о аварийном восстановлении и рекомендации по инфраструктуре для рабочей нагрузки SAP

  • Статья

Многие организации, работающие с критически важными бизнес-приложениями в Azure, настраивают стратегию высокого уровня доступности (HA) и аварийного восстановления (DR). Целью обеспечения высокого уровня доступности является увеличение уровня обслуживания бизнес-систем путем устранения отдельных точек сбоя в базовой системной инфраструктуре. Технологии высокой доступности снижают влияние незапланированных сбоев инфраструктуры и помогают в плановом обслуживании. Аварийное восстановление определяется как политики, инструменты и процедуры для обеспечения восстановления или продолжения жизненно важной технологической инфраструктуры и систем после географически широко распространенной природной или человеческой катастрофы.

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

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

Общие рекомендации по плану аварийного восстановления

Рабочая нагрузка SAP в Azure выполняется на виртуальных машинах в сочетании с различными службами Azure для развертывания различных уровней (центральных служб, серверов приложений, сервера базы данных) типичного приложения SAP NetWeaver. Как правило, стратегия аварийного восстановления должна быть запланирована для всего ИТ-ландшафта, работающего в Azure, то есть для учета приложений, отличных от SAP. Бизнес-решение, работающее в системах SAP, может не выполняться в целом, если зависимые службы или ресурсы не восстанавливаются на сайте аварийного восстановления. Поэтому вам нужно разработать четко определенный комплексный план аварийного восстановления, учитывая все компоненты и системы.

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

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

Чтобы достичь цели восстановления для различных сценариев, организация должна указать целевое время восстановления (RTO) и целевую точку восстановления (RPO) для своей рабочей нагрузки на основе бизнес-требований. RTO описывает время, которое может быть отключено, обычно измеряется в часах, минутах или секундах. В то время как RPO описывает объем транзакционных данных, приемлемых для бизнеса, чтобы обычные операции возобновлялись. Определение RTO и RPO вашего бизнеса имеет решающее значение, так как это поможет вам оптимально разработать стратегию аварийного восстановления. Компоненты (вычислительные ресурсы, хранилище, база данных и т. д.), участвующие в рабочей нагрузке SAP, реплицируются в регион аварийного восстановления с помощью различных методов (собственные службы Azure, технология репликации собственной базы данных, пользовательские скрипты). Каждый метод предоставляет разные RPO, которые должны учитываться при разработке стратегии аварийного восстановления. В Azure можно использовать некоторые из собственных служб Azure, таких как Azure Site Recovery, Azure Backup, которые помогут вам удовлетворить RTO и RPO рабочих нагрузок SAP. Ознакомьтесь с соглашением об уровне обслуживания Azure Site Recovery и Azure Backup , чтобы оптимально соответствовать RTO и RPO.

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

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

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

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

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

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

    • Службы и функции Azure в парных регионах Azure могут не быть симметричными. Например, Azure NetApp Files, номера SKU виртуальных машин, такие как серия M, доступные в основном регионе, могут быть недоступны в парном регионе. Чтобы проверить, доступен ли продукт или службы Azure в регионе, см. статью "Продукты Azure по регионам".

    • Параметр GRS доступен для учетной записи хранения со стандартным типом хранилища, который реплицирует данные в парный регион. Но стандартное хранилище не подходит для дисков СУБД ИЛИ виртуальных данных SAP.

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

Справочник по развертыванию рабочей нагрузки SAP

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

  • Разверните рабочую рабочую нагрузку SAP в основном регионе и нерабочей рабочей нагрузке в регион аварийного восстановления.
  • Разверните всю рабочую нагрузку SAP (рабочую и нерабочую) в основном регионе. Регион аварийного восстановления используется только в случае отработки отказа.

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

Организации должны планировать и разрабатывать стратегию аварийного восстановления для всего ит-ландшафта. Обычно системы SAP, работающие в рабочей среде, интегрируются с различными службами и интерфейсами, такими как Active Directory, DNS, стороннее приложение и т. д. Поэтому в планировании аварийного восстановления также необходимо включить системы, отличные от SAP, и другие службы. В этом документе основное внимание уделяется планированию восстановления для приложений SAP. Но вы можете расширить размер и область планирования аварийного восстановления для зависимых компонентов, чтобы соответствовать вашим требованиям.

Эталонная архитектура аварийного восстановления для рабочей нагрузки SAP

Компоненты инфраструктуры решения аварийного восстановления для рабочей нагрузки SAP

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

  • Network
  • Службы вычислений
  • Хранилище

Network

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

    Примечание.

    Попробуйте настроить VPN типа "сеть — сеть" (S2S) как резервную копию Azure ExpressRoute. Дополнительные сведения см. в статье Об использовании VPN S2S в качестве резервного копирования для частного пиринга Azure ExpressRoute.

  • Виртуальная сеть и подсети охватывают все зоны доступности в регионе. Для аварийного восстановления в двух регионах необходимо настроить отдельные виртуальные сети и подсети в регионе аварийного восстановления. Дополнительные сведения о сетевом восстановлении в виртуальной машине Azure см. в статье "Сведения о аварийном восстановлении сети" в регионе аварийного восстановления.

  • Azure Load Balancer (цен. категория предоставляет сетевые элементы для разработки высокодоступных систем SAP. Для кластеризованных систем Load Balancer (цен. категория предоставляет виртуальный IP-адрес службы кластера, например экземпляры и базы данных ASCS/SCS, работающие на виртуальных машинах. Чтобы запустить высокодоступную систему SAP на сайте аварийного восстановления, необходимо создать отдельную подсистему балансировки нагрузки и настроить конфигурацию кластера соответствующим образом.

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

  • Так как сетевые компоненты (например, виртуальная сеть, брандмауэр и т. д.) создаются отдельно в регионе аварийного восстановления, необходимо убедиться, что рабочая нагрузка SAP в регионе аварийного восстановления адаптирована к сетевым изменениям, таким как обновление DNS, брандмауэр и т. д.

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

Виртуальные машины

  • В Azure различные компоненты одной системы SAP выполняются на виртуальных машинах с различными типами SKU. Для аварийного восстановления защита приложения (SAP NetWeaver и не SAP) на виртуальных машинах Azure может быть включена путем репликации компонентов с помощью Azure Site Recovery в другой регион или зону Azure. С помощью Azure Site Recovery виртуальные машины Azure постоянно реплицируются с первичного на сайт аварийного восстановления. В зависимости от выбранного региона аварийного восстановления Azure тип SKU виртуальной машины может быть недоступен на сайте аварийного восстановления. Необходимо убедиться, что необходимые типы SKU виртуальной машины доступны в Azure DRregion, а также. Проверьте продукты Azure по регионам , чтобы узнать, доступен ли требуемый тип SKU семейства виртуальных машин.

    Внимание

    Если система SAP настроена с гибким масштабируемым набором с FD=1, необходимо использовать PowerShell для настройки Azure Site Recovery для аварийного восстановления. В настоящее время это единственный метод, доступный для настройки аварийного восстановления для виртуальных машин, развернутых в масштабируемом наборе.

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

    Примечание.

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

  • При использовании рабочих приложений, работающих в основном регионе, резервные экземпляры обычно используются для экономии затрат Azure. При использовании зарезервированных экземпляров необходимо зарегистрироваться для 1-летнего или 3-летнего срока обязательства, которое может оказаться не экономически эффективным для сайта аварийного восстановления. Кроме того, настройка Azure Site Recovery не гарантирует емкость требуемого номера SKU виртуальной машины во время отработки отказа. Чтобы убедиться, что емкость SKU виртуальной машины доступна, можно рассмотреть возможность включения резервирования емкости по запросу. Она резервирует вычислительные мощности в регионе Azure или зоне доступности Azure в течение любого периода времени без обязательств. Azure Site Recovery интегрирован с резервированием емкости по запросу. Благодаря этой интеграции можно использовать возможности резервирования емкости с Помощью Azure Site Recovery для резервирования вычислительных ресурсов на сайте аварийного восстановления и обеспечения отработки отказа. Дополнительные сведения см. в статье об ограничениях резервирования емкости по запросу.

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

Хранилище

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

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

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

    Тип хранилища Рекомендация по стратегии аварийного восстановления
    Управляемый диск Azure Site Recovery
    NFS в файлах Azure (LRS или ZRS) Пользовательский скрипт для репликации данных между двумя сайтами (например, rsync)
    NFS в Azure NetApp Files Использование репликации томов Azure NetApp Files между регионами
    Общий диск Azure (LRS или ZRS) Azure Site Recovery с общим диском Azure (в предварительной версии)
    SMB в файлах Azure (LRS или ZRS) Использование RoboCopy для копирования файлов между двумя сайтами
    SMB в Azure NetApp Files Использование репликации томов Azure NetApp Files между регионами

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

  • Разные собственные службы хранилища Azure (например, Файлы Azure, Azure NetApp Files) могут быть недоступны во всех регионах. Таким образом, чтобы после отработки отказа была аналогична настройка SAP в регионе аварийного восстановления, убедитесь, что соответствующая служба хранения предлагается на сайте аварийного восстановления. Дополнительные сведения см . в описании продуктов Azure по регионам.

  • Если вы используете хранилище избыточности между зонами (ZRS) для Файлы Azure и общего диска Azure в основном регионе, и вы хотите сохранить тот же параметр избыточности ZRS в регионе аварийного восстановления, а также обратитесь к [поддержка ZRS общих папок класса Premium](Файлы Azure поддержка хранилища, избыточного между зонами (ZRS) для общих папок класса Premium | Microsoft Learn) и ZRS для документов управляемых дисков для поддержки ZRS в регионах Azure.

  • При использовании зон доступности для аварийного восстановления имейте в виду следующие моменты:

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

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

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