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

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

  • Параметр GRS доступен для учетной записи хранения со стандартным типом хранения, который реплика tes данных в парный регион. Но стандартное хранилище не подходит для дисков СУБД ИЛИ виртуальных данных 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, выполняемая в Azure, использует различные компоненты инфраструктуры для запуска бизнес-решения. Чтобы спланировать аварийное восстановление для такого решения, важно, чтобы все компоненты инфраструктуры, настроенные в основном регионе, были доступны и могут быть настроены в регионе аварийного восстановления. При разработке решения аварийного восстановления для рабочей нагрузки SAP в Azure следует учитывать следующие компоненты инфраструктуры.

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

Сеть

• 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 может обслуживать общедоступные (Интернет) или частные клиенты или оба в зависимости от конфигурации. После отработки отказа для приема аналогичного входящего трафика HTTP в регионе аварийного восстановления необходимо настроить отдельную Шлюз приложений 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, рекомендуется использовать собственную технологию реплика tion базы данных для синхронизации данных с сайтом аварийного восстановления. Большие виртуальные машины, на которых выполняются базы данных, могут быть недоступны во всех регионах. Если вы используете зоны доступности для аварийного восстановления, необходимо проверка, что соответствующие номера 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 для хранилищ.

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

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

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

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

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

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

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

• Для общих дисков Azure требуется программное обеспечение кластера, например отказоустойчивый кластер Windows Server (WSFC), которое обрабатывает связь узла кластера и блокировку записи. Таким образом, чтобы использовать стратегию аварийного восстановления для общего диска Azure, необходимо также управлять общим диском с помощью программного обеспечения кластера на сайте аварийного восстановления. Затем можно использовать скрипт для копирования данных из общего диска, подключенного к кластеру в основном регионе, на общий диск, подключенный к другому кластеру в регионе аварийного восстановления.

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

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