Высокодоступная архитектура и сценарии для SAP NetWeaver

  • Статья

Определения терминов

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

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

Общие сведения о высокой доступности

Высокий уровень доступности SAP в Azure можно разделить на три типа:

  • Высокая доступность инфраструктуры Azure.

    Например, высокая доступность вычислений (на виртуальных машинах), сети или хранилища и ее преимущества для повышения доступности приложений SAP.

  • Использование перезапуска виртуальной машины инфраструктуры Azure для защиты приложений SAP:

    Если вы решили не применять такие функции, как отказоустойчивый кластер Windows Server (WSFC) или Pacemaker в Linux, используйте перезапуск виртуальной машины Azure. Он восстанавливает функциональные возможности в системах SAP, если существует любое запланированное и незапланированное время простоя инфраструктуры физического сервера Azure и общей базовой платформы Azure.

  • Высокий уровень доступности приложений SAP.

    Для обеспечения высокой доступности всей системы SAP необходимо защитить все ее важные компоненты. Например:

    • избыточные серверы приложений SAP;
    • уникальные компоненты. Примером может служить компонент единой точки отказа (SPOF), такой как экземпляр ASCS/SCS или СУБД (DBMS).

Высокая доступность SAP в Azure отличается от высокой доступности SAP в локальной физической или виртуальной среде.

Для Linux нет конфигурации высокого уровня доступности SAP, интегрированной с sapinst, так как для Windows нет. Дополнительные сведения об обеспечении высокого уровня доступности SAP в локальной среде Linux см. в статье с информацией о партнерских решениях для обеспечения высокой доступности.

Высокая доступность инфраструктуры Azure

Соглашение об уровне обслуживания для одноэкземплярных виртуальных машин

В настоящее время существует соглашение об уровне обслуживания с одной виртуальной машиной 99,9 % с хранилищем класса Premium. Чтобы понять, какой может быть доступность одной виртуальной машины, можно выполнить сборку продукта, регулируемого различными доступными соглашениями об уровне обслуживания Azure.

Для расчета используется период 30 дней в месяц или 43 200 минут. Например, время простоя 0,05 % соответствует 21,6 минутам. Обычно доступность различных служб вычисляется следующим образом:

(Служба доступности #1/100) x (служба доступности #2/100) x (служба доступности #3/100) *...

Например:

(99.95/100) x (99.9/100) x (99.9/100) = 0,9975 или общая доступность 99,75 %.

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

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

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

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

Дополнительные сведения см. в статье об управлении доступностью виртуальных машин в Azure с помощью группы доступности.

Зоны доступности Azure

Azure находится в процессе развертывания концепции Azure Зоны доступности в разных регионах Azure. В регионах Azure, где предлагаются Зоны доступности, есть несколько центров обработки данных с независимыми источниками питания, системами охлаждения и сетями. В одном регионе Azure предлагаются разные зоны, чтобы обеспечить возможность развертывать приложения в двух или трех предложенных Зонах доступности. Если неполадки с источниками питания или сетью затрагивают инфраструктуру только одной зоны доступности, развертывание приложения в регионе Azure по-прежнему будет работать нормально. Через время возможно некоторое снижение емкости, так как некоторые виртуальные машины в одной зоне могут быть потеряны. Виртуальные машины в двух других зонах по-прежнему будут работать. Регионы Azure, которые предлагают зоны, перечислены в статье Что такое Зоны доступности в Azure?.

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

  • Вы не можете развертывать группы доступности Azure в Зоне доступности. Только возможность объединения групп доступности и Зон доступности с группами размещения близкого взаимодействия. Дополнительные сведения см. в статье "Объединение групп доступности и зон доступности с группами размещения близкого взаимодействия".
  • Вы не можете использовать Load Balancer (цен. категория "Базовый") для создания отказоустойчивых кластерных решений, основанных на службах отказоустойчивого кластера Windows или Linux Pacemaker. Вместо этого необходимо использовать номер SKU Load Balancer (цен. категория Azure.
  • Azure Зоны доступности не предоставляет никаких гарантий определенного расстояния между различными зонами в одном регионе.
  • Задержка сети между различными Зонами доступности Azure в разных регионах Azure может отличаться. В таких случаях, когда клиент может достаточно запускать уровень приложений SAP, развернутый в разных зонах, так как задержка сети от одной зоны к активной виртуальной машине СУБД по-прежнему допустима из влияния бизнес-процесса. В тех случаях, когда задержка между активной виртуальной машиной СУБД в одной зоне и экземпляром приложения SAP в другой зоне может быть слишком навязчивой и неприемлемой для бизнес-процессов SAP. В результате архитектуры развертывания должны отличаться: архитектура "активная — активная" для приложения или "активная — пассивная", если задержка слишком высока.
  • Использование управляемых дисков Azure является обязательным для развертывания в Azure Зоны доступности.

Масштабируемый набор виртуальных машин с гибкой оркестрацией

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

Масштабируемый набор виртуальных машин с гибкой оркестрацией обеспечивает гибкость для создания масштабируемого набора в пределах региона или охвата его между зонами доступности. При создании гибкого масштабируемого набора в регионе с платформойFaultDomainCount>1 (FD>1) виртуальные машины, развернутые в масштабируемом наборе, будут распределены по указанному количеству доменов сбоя в одном регионе. С другой стороны, создание гибкого масштабируемого набора между зонами доступности с помощью platformFaultDomainCount=1 (FD=1) будет распространять виртуальные машины между разными зонами, а масштабируемый набор также распределяет виртуальные машины между различными доменами сбоя в каждой зоне на основе наилучших усилий. Для рабочей нагрузки SAP поддерживается только гибкий масштабируемый набор с FD=1.

Преимущество использования гибких масштабируемых наборов с FD=1 для межзонального развертывания вместо традиционного развертывания зон доступности заключается в том, что виртуальные машины, развернутые с масштабируемым набором, будут распределены по разным доменам сбоя в пределах зоны наилучшим образом. Чтобы избежать ограничений, связанных с использованием группы размещения близкого взаимодействия для обеспечения доступности виртуальных машин во всех центрах обработки данных Azure или под каждым сетевым позвоночником, рекомендуется развернуть рабочую нагрузку SAP в зонах доступности с помощью гибкого масштабируемого набора с FD=1. Эта стратегия развертывания гарантирует, что виртуальные машины, развернутые в каждой зоне, не ограничены одним центром обработки данных или сетевым позвоночником, а также все системные компоненты SAP, такие как базы данных, ASCS/ERS и уровень приложений, область на зональном уровне.

Поэтому для нового развертывания рабочей нагрузки SAP в зонах доступности рекомендуется использовать гибкий масштабируемый набор с FD=1. Дополнительные сведения см. в статье о масштабируемом наборе виртуальных машин для документа рабочей нагрузки SAP.

Запланированное и незапланированное обслуживание виртуальных машин

Есть два типа событий платформы Azure, которые могут повлиять на доступность виртуальных машин:

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

Дополнительные сведения см. в разделе обслуживания виртуальных машин в Azure.

Репликация службы хранилища Azure

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

Так как служба хранилища Azure сохраняет три образа данных по умолчанию, использование RAID 5 или RAID 1 на нескольких дисках Azure не требуется.

Дополнительные сведения см. в статье Репликация службы хранилища Azure.

управляемые диски Azure.

Управляемые диски — это тип ресурса в Azure Resource Manager, рекомендуемый вариант хранения вместо виртуальных жестких дисков (VHD), хранящихся в учетных записях хранения Azure. Управляемые диски автоматически соответствуют группе доступности Azure виртуальной машины, к которым они подключены. Они повышают ее доступность и доступность служб, выполняющихся на ней.

Дополнительные сведения об Управляемых дисках Azure см. в статье Обзор компонента "Управляемые диски" Azure.

Мы советуем использовать управляемые диски, так как они упрощают развертывание виртуальных машин и управление ими.

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

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

Функции Масштабируемый набор виртуальных машин с гибкой оркестрацией (FD=1) Зона доступности 1 Группа доступности
Поведение развертывания Экземпляры приземлились между 1, 2 или 3 зонами доступности и распределяются по разным стойкам в каждой зоне на основе наилучших усилий Экземпляры земли в 1, 2 или 3 зонах доступности Экземпляры приземлились в регионе и распределялись по разным доменам сбоя и обновления
Назначение виртуальных машин и управляемых дисков определенной зоне доступности Да Да No
Домен сбоя. Максимальное распространение (Azure максимально распределяет экземпляры) Да No Да, на основе количества доменов сбоя, определенных во время создания.
Выравнивание домена сбоя хранилища No Нет Да
Резервирование мощности Да (назначение резервирования емкости на уровне виртуальной машины) Да Нет

Примечание.

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

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

Тип системы Между различными зонами в регионе В зоне singe региона В регионе без зон
Система SAP с высоким уровнем доступности Гибкий масштабируемый набор с FD=1 Группы доступности с группами размещения близкого взаимодействия Группы доступности
Группы доступности и Зоны доступности с группами размещения близкого взаимодействия Гибкий масштабируемый набор с FD=1 (выберите только одну зону) Гибкий масштабируемый набор с FD=1 (зоны не определены)
Зоны доступности Группы доступности
  • Развертывание в разных зонах в регионе: для максимальной доступности системы SAP должны развертываться в разных зонах в регионе. Это гарантирует, что если одна зона недоступна, система SAP продолжает быть доступна в другой зоне. Если вы развертываете новую рабочую нагрузку SAP в зонах доступности, рекомендуется использовать гибкий набор масштабируемых виртуальных машин с параметром развертывания FD=1. Это позволяет развертывать несколько виртуальных машин в разных зонах в регионе, не беспокоясь о ограничениях емкости или группах размещения. Платформа масштабируемого набора гарантирует, что виртуальные машины, развернутые с масштабируемым набором, будут распределяться между различными доменами сбоя в пределах зоны наилучшим образом. Все высокодоступные компоненты SAP, такие как SAP ASCS/ERS, базы данных SAP распределяются по разным зонам, в то время как несколько серверов приложений в каждой зоне распределяются по разным доменам сбоя на основе наилучших усилий.
  • Развертывание в одной зоне региона. Чтобы развернуть систему SAP с высоким уровнем доступности в регионе с несколькими зонами доступности, и если все компоненты системы должны находиться в одной зоне, рекомендуется использовать группы доступности с вариантом развертывания групп размещения близкого взаимодействия. Этот подход позволяет сгруппировать все системные компоненты SAP в одной зоне доступности, гарантируя, что виртуальные машины в группе доступности распределяются по разным доменам сбоя и обновления. Хотя это развертывание соответствует доменам сбоя хранилища, близкое взаимодействие не гарантируется. Однако этот вариант развертывания является региональным, он не поддерживает Azure Site Recovery для аварийного восстановления между зонами. Кроме того, этот параметр ограничивает все развертывание SAP одним центром обработки данных, что может привести к ограничению емкости, если необходимо изменить размер SKU или экземпляры приложения горизонтального масштабирования.
  • Развертывание в регионе без зон: если вы развертываете систему SAP в регионе, в котором нет зон, рекомендуется использовать группы доступности. Этот параметр обеспечивает избыточность и отказоустойчивость путем размещения виртуальных машин в разных доменах сбоя и доменах обновления.

Важно!

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

Использование высокой доступности инфраструктуры Azure для защиты приложений SAP

Если вы решили не использовать такие функции, как WSFC или Pacemaker в Linux (поддерживается для SUSE Linux Enterprise Server 12 и более поздних версий, а также Red Hat Enterprise Linux 7 и более поздних версий), перезапуск виртуальной машины Azure используется. Он восстанавливает функциональные возможности в системах SAP, если существует любое запланированное и незапланированное время простоя инфраструктуры физического сервера Azure и общей базовой платформы Azure.

Дополнительные сведения о подходе см. в статье "Использование перезапуска виртуальной машины инфраструктуры Azure" для повышения доступности системы SAP.

Высокий уровень доступности приложений SAP в Azure IaaS

Для обеспечения высокой доступности всей системы SAP необходимо защитить все ее важные компоненты. Например:

  • избыточные серверы приложений SAP;
  • уникальные компоненты. Примером может служить компонент единой точки отказа (SPOF), такой как экземпляр ASCS/SCS или СУБД (DBMS).

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

Архитектура высокого уровня доступности для серверов приложений SAP

Windows logo. Windows и Linux logo. Linux

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

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

  • Гибкий масштабируемый набор с platformFaultDomainCount=1 (FD=1): серверы приложений SAP, развернутые с гибким масштабируемым набором (FD=1), распределяют виртуальные машины между разными зонами доступности, а масштабируемый набор также распределяет виртуальные машины между различными доменами сбоя в каждой зоне на основе наилучших усилий. Это гарантирует, что если одна зона недоступна, серверы приложений SAP, развернутые в другой зоне, по-прежнему будут доступны.
  • Зона доступности: серверы приложений SAP, развернутые в зонах доступности, гарантируют, что виртуальные машины охватывают разные зоны для обеспечения избыточности. Это гарантирует, что если одна зона недоступна, серверы приложений SAP, развернутые в другой зоне, по-прежнему будут доступны. Дополнительные сведения см. в статье о конфигурациях рабочей нагрузки SAP с помощью Azure Зоны доступности
  • Группа доступности: серверы приложений SAP, развернутые в группе доступности, обеспечивают распределение виртуальных машин между различными доменами сбоя и доменами обновления. При размещении виртуальных машин в разных доменах обновления убедитесь, что виртуальные машины не обновляются одновременно во время запланированного простоя обслуживания. В то время как размещение виртуальных машин в другом домене сбоя гарантирует защиту виртуальной машины от сбоев оборудования или прерываний питания в центре обработки данных. Но количество доменов сбоя и обновления, которые можно использовать в группе доступности Azure в единице масштабирования Azure, является конечным. Если вы продолжаете добавлять виртуальные машины в одну группу доступности, две или более виртуальных машин в конечном итоге будут входить в тот же домен сбоя или обновления. Дополнительные сведения см. в разделе Группы доступности Azure документа о планировании и внедрении SAP NetWeaver на виртуальных машинах Azure.

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

Важно!

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

Архитектура высокой доступности для экземпляра SAP ASCS/SCS на Windows

Windows logo. Windows

Решение WSFC можно использовать для защиты экземпляра SAP ASCS/SCS. В зависимости от типа конфигурации общей папки кластера (общей папки или общего диска) можно ссылаться на соответствующее решение на основе типа хранилища.

Архитектура высокой доступности для экземпляра SAP ASCS/SCS на Linux

Linux logo. Linux

В Linux конфигурация экземпляра SAP ASCS/SCS кластеризация зависит от дистрибутива операционной системы и типа используемого хранилища. Рекомендуется реализовать подходящее решение в соответствии с конкретной платформой кластера ОС.

Конфигурации SAP NetWeaver с несколькими идентификаторами безопасности для кластеризованного экземпляра SAP ASCS/SCS

Windows logo. Окно

Несколько идентификаторов безопасности поддерживается c WSFC при использовании общей папки и общего диска. Дополнительные сведения об использовании архитектуры высокого уровня доступности с несколькими идентификаторами безопасности в Windows см. в следующих статьях:

Linux logo. Linux

Кластеризация с несколькими ИД безопасности поддерживается в кластерах Pacemaker Linux для SAP ASCS/ERS, но в одном кластере может быть только пять идентификаторов безопасности SAP. Дополнительные сведения об использовании архитектуры высокого уровня доступности с несколькими идентификаторами безопасности в Linux см. в следующих статьях:

Высокий уровень доступности экземпляра СУБД

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

База данных Рекомендация по аварийному аварийному восстановления
SAP HANA Репликация системы HANA (HSR)
Oracle Oracle Data Guard;
IBM DB2 Аварийное восстановление высокого уровня доступности (HADR)
Microsoft SQL Microsoft SQL AlwaysOn
SAP ASE ASE HADR AlwaysOn