Как сменить IP адрес на сервере, где установлена SAP система

Задача по смене IP адреса сервера, на котором установлена SAP система, в отличии от смены имени сервера (hostname), не должна вызывать особых затруднений. Это связано с тем, что SAP система для работы чаще использует hostname, которое преобразуется в IP адрес на уровне операционной системы.

Проверить данное преобразование можно вызовом команды niping (рис. 1).

Рис. 1. Преобразование hostname -> IP адрес.

При смене IP адреса сервера со стороны SAP системы нет необходимости в рестарте сервера приложений, достаточно изменить настройки на уровне операционной системы сервера.

Например, на сервере под управлением операционной системой MS Windows сначала необходимо сменить IP в настройках сетевой карты. Далее внести соответствующие изменения в файл C:\Windows\System32\drivers\etc\hosts (рис. 2).

Рис. 2. Файл hosts.

Диалоговые инстанции 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. Частные случаи можно посмотреть тут и тут.

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

Дополнительные сервера приложений. Транзакции.

Если в вашем "подворье" появились дополнительные диалоговые сервера, то придётся использовать ряд новых транзакций:

• SMLG - создание и администрирование logon групп,
• SM51 - список всех серверов приложений, с возможностью дистанционного входа, просмотра списка процессов и пользователей каждой инстанции,
• AL08 - список активных пользователей всех серверов приложений,
• SM66 - список активных процессов всех серверов приложений на одном экране.
  

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

Установка дополнительных диалоговых инстанций

Однажды наступает момент, когда вычислительных мощностей одного сервера для системы становится недостаточно. SAP позволяет распределить уровень приложений по нескольким серверам. И в данной ситуации грех этим не воспользоваться. :)

Я хотел бы описать несколько моментов, которые будут интересны тем, кто еще не устанавливал дополнительный сервер приложений.
Итак, вот они:

1. Аппаратная платформа для установки дополнительного сервера приложений может отличаться от платформы основного сервера.
2. При установке дополнительного сервера приложений стоит использовать в качестве имени системы (SID) такое же имя, что и у основной системы. Часто это не отмечено в инструкции по установке, но без этого ничего не получится. Проверено. :-)
3. Часть файловых систем необходимо монтировать удаленно, например по NFS, с центрального сервера. Если платформы разные, то ядро сервера приложений SAP с центрального сервера для диалоговой инстанции не подойдет. Но можно создать на центральном сервере приложений, рядом с директорией основного ядра, директорию для ядра платформы, на которой работает дополнительный сервер приложений. И монтировать удаленно уже эту директорию. Это позволит центролизовать процесс обновления ядра SAP диалоговых инстанций.
4. Вам придется использовать logon group для входа в систему. В системе они настраиваются через транзакцию SMLG. Стоит отметить, что за балансировку отвечает message server, который работает на центральной инстанции, и делает он это автоматически. Коннект к системе осуществляется через message server. Сначала клиентское место SAP посылает запрос message server-у с указанием имени logon group, с которой он хочет работать. Message server определяет, какие сервера входят в данную logon group, выбирает наименее загруженный и посылает его координаты клиенту. Клиент подключается уже к нему напрямую и весь сеанс работает только с ним.
5. На клиентской машине надо прописать координаты message server-а в файле Drive:/windir/system32/drivers/etc/services. Прочтите перед этим SAP note # 52959. Обратите внимание на важное замечание - оставлять пустую строку в конце данного файла.
6. Очень удобно администрировать записи message server-ов, строк SAP router, записей коннекта в SAP Logon через служебные файлики sapmsg.ini, saproute.ini, saplogon.ini. Данные файлики лежат в директории Drive:/windir/. Подробнее о формате файлов читайте в SAP note # 38119.

Главное, внимательно читайте инструкцию по установке. Раздел по установке дополнительных диалоговых инстанций небольшой, поэтому изучите его внимательно. Надеюсь Вам помогут эти фишки.

И с наступлением настоящей весны! :)

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