Читаем SAP R/3 Системное администрирование полностью

- Реорганизацию системы спула (удаление устаревших запросов)

- Перенаправление запросов при отказе сервера

- Поиск необработанных запросов

Кроме того, статус очереди системы спула хоста проверяется согласно настройке по умолчанию через регулярные интервалы.

Можно определить число конфигурируемых рабочих процессов спула, задавая параметр rdisp/wp_no_spo в профиле инстанции.

Управление запросами

Рабочие процессы спула инстанции составляют одно целое, к ним нельзя обращаться по отдельности. Поэтому устройства вывода присваивают инстанции, а не определенному рабочему процессу (см. раздел 11.4). Каждая инстанция со службами спула управляет своими входящими запросами вывода в своей собственной очереди запросов спула как объектами в основной памяти. Если возникают перегрузка и переполнение очереди запросов спула, то в качестве коллектора входящих запросов используется очередь диспетчера, чтобы ни один запрос спула не был потерян. Когда очередь запросов спула сможет вместить все запросы вывода, рабочие процессы спула смогут снова перенести запросы из очереди диспетчера в очередь запросов спула. Обработка запросов спула продолжится только тогда, когда очередь диспетчера будет пустой или очередь запросов спула полностью заполненной.

Последовательная обработка

Сконфигурированные рабочие процессы спула могут обрабатывать запросы в инстанции последовательно, а иногда параллельно. Поэтому нет гарантии, что запросы вывода будут обработаны в том же порядке, в котором они были введены, если есть несколько рабочих процессов спула, выполняемых в инстанции. Некоторые запросы могут быть обработаны не в том порядке. При необходимости можно при создании устройства активировать параметр, чтобы обеспечить последовательную обработку запросов в том порядке, в котором они создаются. В этом случае рабочий процесс спула всегда обрабатывает все запросы для этого устройства в очереди спула, прежде чем принимает другие запросы. Однако в здесь ограничивается параллелизм между несколькими рабочими процессами спула, поэтому необходимо использовать этот параметр только тогда, когда это действительно необходимо (см. раздел 11.4).

11.3. Настройка сервера спула

Реальный сервер спула является сервером приложений SAP, имеющим, как минимум, один рабочий процесс спула. Каждый запрос вывода обрабатывается на сервере спула с помощью одного из рабочих процессов спула, сконфигурированных для инстанции. Каждое устройство вывода присваивается серверу спула, который обрабатывает запросы для этого устройства.

Можно определить архитектуру логического спула для следующих целей:

► Выравнивание нагрузки между серверами спула

► Доступность альтернативного средства при отказе сервера спула

► Возможность простого переноса определенной инфраструктуры принтера

Логический сервер

Логический сервер является иерархией из одного или нескольких логических серверов и точно одного реального сервера спула, который? в конечном счете? обрабатывает запросы вывода. При настройке архитектуры логического спула можно использовать логические серверы для представления реальных серверов спула. При определении логического сервера, кроме сервера спула, можно задать дополнительный сервер спула, который должен представлять логический сервер. Если необходимо, дополнительный сервер может выполнить задачи реального сервера спула, который отказал, или можно сконфигурировать подходящие настройки для использования этого дополнительного сервера для распределения нагрузки.

На рис. 11.3 показана реализация сценария отказа с определением логического сервера и его альтернативного сервера. Логический сервер «LOGI1» присвоен принтерам; «LOGI1» представляет реальный сервер спула «host1_PRD_00». Реальный сервер спула «host2_PRD_00» является альтернативным сервером. Если сервер спула «host1_PRD_00» отказывает, все запросы печати, предназначенные для устройств, которые присвоены логическому серверу «LOGI1», обрабатываются альтернативным сервером «host2_PRD_00».

Если определение «LOGI1» позволяет также распределение нагрузки, то система всегда будет определять наиболее подходящий сервер спула и разделять запросы соответственно между «host1_PRD_00» и «host2_PRD_ 00» (см. рис. 11.4).

Рис. 11.3.Сценарий отказа с логическим сервером спула

Рис. 11.4.Выравнивание нагрузки

Если принтеры были присвоены прямо серверу спула «host1_PRD_00», то ожидающие запросы вывода не будут обработаны, если сервер спула откажет.

Нагрузка сервера спула определяется числом рабочих процессов спула в инстанции, числом запросов для обработки и числом страниц для вывода.

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

Классификация

Перейти на страницу:

Похожие книги