Поделиться через

Общие сведения о аварийном восстановлении и рекомендации по инфраструктуре для рабочей нагрузки 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 уровня приложений)
  • Для выполнения требований бизнеса необходимы операционные задачи для тестирования стратегии аварийного восстановления (например, упражнение по проверке отказа DR, выполняемое каждый год для соответствия требованиям).

Чтобы достичь цели восстановления для различных сценариев, организация должна указать целевое время восстановления (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 и виртуальные машины серии 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 следует учитывать следующие компоненты инфраструктуры.

  • Сеть
  • Вычисления
  • Хранилище

Сеть

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

    Примечание.

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

  • Виртуальная сеть и подсети охватывают все зоны доступности в регионе. Для аварийного восстановления в двух регионах необходимо настроить отдельные виртуальные сети и подсети в регионе аварийного восстановления. Чтобы узнать больше о настройке сетевой инфраструктуры в регионе аварийного восстановления в виртуальных машинах Azure, см. статью "О сетевых возможностях в Azure VM Disaster Recovery".

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

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

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

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

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

  • В Azure различные компоненты одной системы SAP выполняются на виртуальных машинах с различными типами SKU. Для целей аварийного восстановления защиту приложения (SAP NetWeaver и других) на виртуальных машинах Azure можно обеспечить путем репликации компонентов с помощью Azure Site Recovery в другой регион или зону Azure. С помощью Azure Site Recovery виртуальные машины Azure постоянно реплицируются с первичного на сайт аварийного восстановления. В зависимости от выбранного региона аварийного восстановления Azure тип SKU виртуальной машины может быть недоступен на сайте аварийного восстановления. Необходимо убедиться, что необходимые типы SKU виртуальной машины доступны в регионе DR в Azure тоже. Проверьте продукты 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 Files и общих дисков Azure в основном регионе и хотите поддерживать тот же вариант избыточности ZRS в регионе аварийного восстановления, обратитесь к документу [поддержка ZRS для общих папок класса Premium](Файлы Azure поддержка хранилища, избыточного между зонами (ZRS) для общих папок класса Premium | Microsoft Learn) и документу поддержка ZRS для управляемых дисков в регионах Azure.

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

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

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

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