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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время существует соглашение об уровне обслуживания 99,9 % для одной виртуальной машины с премиум-хранилищем. Чтобы понять, какой может быть доступность одной виртуальной машины, можно выполнить сборку продукта, регулируемого различными доступными соглашениями об уровне обслуживания 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 в Зоне доступности. Единственной возможностью для объединения наборов доступности и зон доступности являются группы близкого размещения. Для получения дополнительной информации см. статью "Объединение наборов доступности и зон доступности с группами размещения с близким взаимодействием".
• Вы не можете использовать Базовый балансировщик нагрузки для создания отказоустойчивых кластерных решений на основе служб отказоустойчивого кластера Windows или Linux Pacemaker. Вместо этого необходимо использовать стандартную версию SKU Azure Load Balancer.
• 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.

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

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

• Развертывание в разных зонах в регионе: для максимальной доступности системы SAP должны развертываться в разных зонах в регионе. Это гарантирует, что если одна зона недоступна, система SAP продолжает быть доступна в другой зоне. Если вы развертываете новую рабочую нагрузку SAP в зонах доступности, рекомендуется использовать гибкий набор масштабируемых виртуальных машин с параметром развертывания FD=1. Это позволяет развертывать несколько виртуальных машин в разных зонах в регионе, не беспокоясь о ограничениях емкости или группах размещения. Платформа набора масштабирования обеспечивает, что виртуальные машины, развернутые с использованием набора масштабирования, будут распределяться между различными доменами сбоя в пределах зоны, насколько это возможно. Все высокодоступные компоненты SAP, такие как SAP ASCS/ERS, базы данных SAP распределяются по разным зонам, в то время как несколько серверов приложений в каждой зоне распределяются по разным доменам сбоя на основе наилучших усилий.
• Развертывание в одной зоне региона. Чтобы развернуть систему SAP с высоким уровнем доступности в регионе с несколькими зонами доступности, и если все компоненты системы должны находиться в одной зоне, рекомендуется использовать группы доступности с вариантом развертывания групп размещения близкого взаимодействия. Этот подход позволяет сгруппировать все системные компоненты SAP в одной зоне доступности, гарантируя, что виртуальные машины в группе доступности распределяются по разным доменам сбоя и обновления. Хотя это развертывание выравнивает вычислительные ресурсы с доменами сбоя хранилища, их близкое расположение не гарантируется. Однако этот вариант развертывания является региональным, он не поддерживает Azure Site Recovery для аварийного восстановления между зонами. Кроме того, этот параметр ограничивает всё развертывание SAP одним центром обработки данных, что может привести к ограничениям по емкости, если необходимо изменить размер SKU или масштабировать экземпляры приложений.
• Развертывание в регионе без зон: если вы развертываете систему 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), такой как экземпляр SAP ASCS/SCS или система управления базами данных (СУБД).

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

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

Windows и 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, следует развертывать в разных учетных записях хранения.

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

Windows

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

• Общая папка кластера — общая папка

  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью SMB на Файлы Azure.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью SMB в Azure NetApp Files.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью масштабируемого файлового сервера (SOFS).

• Общий ресурс кластера — общий диск

  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью общего диска Azure.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью SIOS.

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

Linux

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

• SUSE Linux Enterprise Server (SLES)

  • Высокая доступность экземпляра SAP ASCS/SCS с помощью NFS с простым подключением.
  • Высокая доступность экземпляра SAP ASCS/SCS с использованием NFS на Azure Files.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью NFS в Azure NetApp Files.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью сервера NFS.

• Red Hat Enterprise Linux (RHEL)

  • Высокая доступность экземпляра SAP ASCS/SCS с использованием NFS на Azure Files.
  • Высокий уровень доступности экземпляра SAP ASCS/SCS с помощью NFS в Azure NetApp Files.

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

Окно

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

• Общая папка: экземпляр SAP ASCS/SCS с много-SID высокой доступностью для отказоустойчивой кластеризации Windows Server и общей папки.
• Общий диск: экземпляр SAP ASCS/SCS с поддержкой нескольких SID для отказоустойчивой кластеризации Windows Server и совместного использования диска.

Linux

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

• SUSE Linux Enterprise Server (SLES): высокая доступность для SAP NW на виртуальных машинах Azure на SLES для приложений SAP, руководство по мульти-SID.
• Red Hat Linux Enterprise (RHEL): высокая доступность для SAP NW на виртуальных машинах Azure на RHEL для приложений SAP с несколькими SID.

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

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