Архитектура и сценарии высокой доступности виртуальных машин Azure для 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

Высокий уровень доступности инфраструктуры Azure относится к различным возможностям платформы 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.

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

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

Azure Availability Zones (Зоны доступности Azure)

Azure находится в процессе развертывания концепции Azure Availability Zones в разных регионах Azure. В регионах Azure, где предлагаются зоны доступности, имеется несколько дата-центров, которые независимы по поставке источников питания, систем охлаждения и сети. Причина предложения разных зон в одном регионе Azure заключается в том, чтобы позволить развертывать приложения в двух или трех Availability Zones предлагаемых. Если проблемы в источниках питания и (или) сети повлияют только на одну инфраструктуру зоны доступности, развертывание приложения в регионе Azure по-прежнему полностью работает. В конечном итоге мощность может несколько снизиться, так как некоторые виртуальные машины в одной зоне могут быть потеряны. Виртуальные машины в двух других зонах всё ещё работают. Регионы Azure, которые предлагают зоны, перечислены в Azure Availability Zones.

При использовании Availability Zones есть некоторые аспекты, которые следует рассмотреть. Ниже приведен список соображений, таких как:

• Нельзя развернуть наборы доступности Azure в пределе зоны доступности. Единственная возможность объединить наборы доступности и зоны доступности — с помощью групп размещения близости proximity. Для получения дополнительной информации см. статью "Объединение наборов доступности и зон доступности с группами размещения с близким взаимодействием".
• Вы не можете использовать Basic Load Balancer для создания отказоустойчивых кластерных решений на основе служб отказоустойчивых кластеров Windows или Linux Pacemaker. Вместо этого необходимо использовать номер SKU Azure Standard Load Balancer.
• Azure Availability Zones не дают никаких гарантий определенного расстояния между различными зонами в одном регионе.
• Задержка сети между различными зонами доступности 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 Storage

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

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

Дополнительные сведения см. в разделе репликация Azure Storage.

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

Тип ресурса «Управляемые диски» в Azure Resource Manager рекомендуется в качестве варианта хранения вместо виртуальных жестких дисков (VHD), которые хранятся в учетных записях хранения 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 или система управления базами данных (СУБД - DBMS).

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

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

Windows и Linux

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

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

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

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

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

Windows

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

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

  • Высокая доступность инстанции SAP ASCS/SCS с использованием SMB на Azure Files.
  • Высокая доступность экземпляра 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 с высокой доступностью для отказоустойчивого кластеринга Windows Server и общего доступа к файлам.
• Общий диск: Конфигурация высокой доступности многосайдовой SAP ASCS/SCS для кластеризации отказоустойчивости Windows Server и общего диска.

Linux

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

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

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

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