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

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

  • Статья

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

Windows logo. Windows и Linux logo. 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 и учетные записи хранения.

Diagram that shows the architecture of an SAP NetWeaver system that uses Azure infrastructure high availability and storage accounts.

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

Utilize Azure infrastructure high availability to achieve SAP application “higher availability

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

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

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

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

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

    Каждый экземпляр сервера приложений 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 для защиты виртуальной машины с установленным программным обеспечением СУБД, что позволяет косвенно повысить уровень доступности программного обеспечения СУБД.

    СУБД, выполняемая на одной виртуальной машине, также становится единой точкой отказа и определяет доступность всей системы SAP.

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

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

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

Autostart = 1

Примечание.

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

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

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

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