Диалоговые инстанции SAP: балансировка нагрузки

Любая SAP система имеет трехзвенную архитектуру.

Рис. 1. Трехзвенная архитектура SAP системы

Уровень базы данных представляет собой инстанцию базы данных (ORACLE, MSSQL, MAXDB, DB2, SYBASE ASE). Идентифицируется DBSID.

Уровень приложений состоит из центральной инстанции SAP (CI). Если упрощенно, то это исполняемые файлы SAP kernel плюс ABAP/J2EE программы, хранящиеся в базе данных. Идентифицируется SAP SID или просто SID, которые обычно совпадает с DBSID.

Ну и наконец, уровень представления, который в большинстве случаев располагается на рабочей станции пользователя и представляет собой SAP GUI. В случае использования "тонкого клиента" (пользователь работает через Web-браузер) уровень презентации переносится на сервер SAP (ITS сервер).

Для повышения быстродействия SAP позволяет распределить уровень приложений по нескольким серверам. Для этого необходимо к центральной инстанции установить один или несколько дополнительных диалоговых инстанций SAP (DI).

Рис. 2. SAP система с несколькими серверами приложений

Рабочие процессы (в основном диалоговые) диалоговых инстанций имеют свои соединения к shadow-процессам ORACLE. А процесс Message Server (MS) центральной инстанции организовывает работу диалоговых инстанций, при запуске регистрируя их у себя, а затем распределяя соединения пользователей и отслеживая состояние SAP инстанций.

Установку дополнительной диалоговой инстанции я описывал тут и тут. Полезные транзакции для работы с ними можно посмотреть здесь.

Пользователи системы через SAP GUI могут коннектиться напрямую на любую диалоговую инстанцию (включая центральную), зная IP-адрес/hostname сервера и номер инстанции. Но в данном случае это очень "скучно". Интереснее создать логон-группы (SAP LogonGroup) в транзакции SMLG, распределив диалоговоые инстанции между ними. На рабочем месте каждого пользователя в SAP Logon прописать ту или иную логон-группу и указать адрес Message Sever. Вход в систему в данном случае происходит по следующей схеме:

1. Первый пакет от SAP GUI пользователя отправляется к Message Server.
2. Message Server имея список запущенных серверов приложений, входящих в логон-группу пользователя, выделяет один из них, посылая обратный пакет с координатами сервера, пользователю.
3. Получив сетевой пакет от Message Server, SAP GUI соединяется с сервером приложений, координаты которого получил.

Рис. 3. Соединение с системой SAP через логон-группу

Обсудим, как лучше распределить сервера приложений (диалоговые инстанции) по логон-группам. Возьмем для примера систему SAP ERP, в которой работают 400 пользователей, равномерно распределенные по SAP модулям системы: MM, FI и PM. Данные пользователи работают в 8 подразделениях предприятия. Установлены центральная инстанция системы и 6 дополнительных серверов приложений.

Следуя управленческому подходу, можно разделить сервера приложений, создав логон-группы для подразделений. Например, на 6 диалоговых серверах будут созданы 3 логон-группы (по 2 сервера на группу). Пользователи 8 подразделений будут распределены по 3 логон-группам по территориальному или иному признаку. Этот подход, к сожалению, не эффективный.

Рекомендуемым подходом будет распределить пользователей по модулям системы. То есть создать 3 логон-группы (по 2 сервера приложений в каждой): MM_users, FI_users, PM_users. В SAP Logon пользователям прописать логон-группу, с функциональностей которой пользователь работает. Преимущество данного решения следующее. В сервере приложений SAP есть несколько буферов для ускорения работы системы (самый крупные и важные - Program buffer и Table buffer). И когда на инстанции работают пользователи одного модуля, то они запускают в основном приложения своего модуля и обращаются к таблицам, содержащим данные этого модуля. Таким образом, SAP буферы диалоговых инстанций логон-группы будут содержать программы, объекты словаря, экраны и данные таблиц только одного модуля. Это резко повышает количество попаданий в буфер, эффективность использования буферов и памяти сервером приложений SAP. И уменьшает время реакции (response time) всей системы.

Конечно, если какой-то модуль в системе очень сильно нагружает систему, в сравнении с другими, например, PM, то эффективнее будет отдать логон-группе PM_users 3 диалоговых инстанции. А на трех других создать логон-группу для модулей FI и MM.

Вообще грамотное использование диалоговых инстанций позволяет получить ряд плюсов:

• минимум 2 диалоговые инстанции в логон-группе обеспечат отказоустойчивость группы. При выходе из строя одной из инстанций в логон-группе пользователи смогут работать на оставшейся (пользователи, кто был на злополучной инстанции вынуждены будут переконнектиться к системе) без изменения записи в SAP Logon. 
• минимум 2 диалоговые инстанции в логон-группе  активируют встроенный механизм балансировки нагрузки между инстанциями внутри логон-группы. Message server при выборе диалоговой инстанции для пользователя руководствуется временем отклика (response time) и количеством пользователей, работающих на инстанциях.
• распределение пользователей по диалоговым инстанциям позволяет исключить из логон-групп центральную инстанцию. После чего, уменьшив размеры SAP буферов на центральной инстанции, можно отдать все ресурсы сервера (CPU, ОЗУ) базе данных (ей-то мало не бывает никогда :о) ).

 Подводя итоги, правила "лучшей практики" в случае логон-групп следующие:

• включайте в логон-группу минимум 2 сервера приложений,
• разделяйте пользователей по модулям/функциональности,
• закрывайте центральную инстанцию для пользователей (по возможности),
• "кормите" ORACLE лучше, так как больше рабочих процессов SAP требуют больше процессов ORACLE. Частные случаи можно посмотреть тут и тут.

Автор: Шиболов Вячеслав Анатольевич