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

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

Этот раздел относится к:

Логотип Windows. Windows и Логотип Linux. Linux

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

Примечание.

Перезапуск виртуальной машины Azure в основном защищает виртуальные машины, а не приложения. Хотя перезапуск виртуальной машины не обеспечивает высокий уровень доступности для приложений SAP, он предлагает определенный уровень доступности инфраструктуры. Он также косвенно предлагает "более высокую доступность" систем SAP. Соглашение об уровне обслуживания также не требуется для перезапуска виртуальной машины после запланированного или незапланированного сбоя узла, что делает этот метод высокой доступности непригодным для критически важных компонентов системы SAP. Примерами критически важных компонентов может быть экземпляр ASCS/SCS или система управления базами данных (СУБД).

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

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

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

Пример архитектуры системы SAP NetWeaver, используюющей высокий уровень доступности инфраструктуры Azure и учетные записи хранения, могут выглядеть следующим образом:

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

Пример архитектуры системы SAP NetWeaver, используюющей высокий уровень доступности инфраструктуры Azure и управляемые диски, могут выглядеть следующим образом:

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

Для критически важных компонентов SAP вы достигли следующего:

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

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

    Эту конфигурацию можно обеспечить с помощью групп доступности Azure. Дополнительные сведения см. в разделе "Группы доступности Azure ".

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

    Каждый экземпляр сервера приложений SAP помещается в собственную учетную запись хранения Azure. Потенциальная недоступность одной учетной записи хранения Azure приведет к недоступности только одной виртуальной машины с экземпляром сервера приложений SAP. Однако помните, что в одной подписке Azure есть ограничение на количество учетных записей хранения Azure. Чтобы обеспечить автоматическое запуск экземпляра ASCS/SCS после перезагрузки виртуальной машины, задайте параметр автозапуска в профиле запуска экземпляра ASCS/SCS.

    Дополнительные сведения см. в разделе "Высокий уровень доступности" для серверов приложений SAP.

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

  • Более высокая доступность экземпляров SAP ASCS/SCS

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

    Чтобы обеспечить автоматический запуск экземпляра ASCS/SCS после перезагрузки виртуальной машины, задайте параметр автозапуска в профиле запуска экземпляра ASCS/SCS. Этот параметр означает, что экземпляр ASCS/SCS в качестве одной точки сбоя (SPOF), работающей на одной виртуальной машине, определяет доступность всего ландшафта SAP.

  • Более высокая доступность сервера СУБД

    Как и в предыдущем случае использования экземпляра SAP ASCS/SCS, вы используете перезапуск виртуальной машины Azure для защиты виртуальной машины с установленным программным обеспечением СУБД и обеспечивает "более высокую доступность" программного обеспечения СУБД с помощью перезапуска виртуальной машины.

    СУБД, выполняющаяся на одной виртуальной машине, также является spOF, и это детерминированный фактор для доступности всего ландшафта SAP.

Использование автоматического запуска для экземпляров SAP

SAP предлагает параметр, позволяющий запускать экземпляры SAP сразу после запуска ОС на виртуальной машине. Инструкции описаны в статье базы знаний SAP 1909114. Однако SAP больше не рекомендует использовать этот параметр, поскольку он не позволяет управлять порядком перезапуска экземпляров, если на одной виртуальной машине запущено несколько экземпляров или если на нескольких виртуальных машинах выполняются разные экземпляры.

Предположим, типичный сценарий Azure, где имеется один экземпляр сервера приложений SAP на виртуальной машине, и одна виртуальная машина в конечном итоге перезапускается, тогда автозапуск не является критическим. Но его можно включить, добавив следующий параметр в начальный профиль приложения SAP Advanced Business Application Programming (ABAP) или экземпляр Java:

Autostart = 1

Примечание.

Параметр автозапуска также имеет определенные недостатки. В частности, параметр активирует начало экземпляра SAP ABAP или Java при запуске связанной службы Windows или Linux экземпляра. Эта последовательность возникает при загрузке операционной системы. Однако перезапуски служб SAP также являются общим явлением для функций управления жизненным циклом программного обеспечения SAP, таких как Диспетчер обновлений программного обеспечения (SUM) или другие обновления или обновления. Эти функции не ожидают автоматического перезапуска экземпляра. Поэтому параметр автозапуска должен быть отключен перед выполнением таких задач. Параметр автозапуска также не должен использоваться для экземпляров SAP, кластеризованных, таких как ASCS/SCS/CI.

Дополнительные сведения о автозапуске для экземпляров SAP см. в следующих статьях:

Дальнейшие действия

Сведения о высокой доступности приложений SAP NetWeaver см. в статье о высокой доступности приложений SAP в Azure IaaS.