Конфигурации с горизонтальным масштабированием

Экземпляр служб Microsoft SQL Server Notification Services можно масштабировать на несколько серверов. Также можно разместить генератор, поставщиков событий и распространителей на разных серверах. Кроме этого, можно установить внепроцессные поставщики событий и приложения управления подписками на отдельных серверах. В этом разделе продемонстрированы три распространенных сценария масштабирования: приложение, которому необходима более высокая пропускная способность распространения; приложение, использующее внепроцессный (независимый) поставщик событий, и приложение, у которого есть приложение управления подписками на веб-сервере.

Масштабирование распространителя

В приложениях с большими объемами сведений распространитель может запаздывать, поскольку форматирование уведомлений может сильно загружать процессоры, а для распространения уведомлений требуется достаточная пропускная способность систем, доставляющих уведомления. С целью минимизации «узких мест» в распространении можно масштабировать распространителя на несколько серверов, определив несколько распространителей в определении приложения. Распространители берут на себя работу по распространению, когда они становятся доступными.

На приведенном ниже рисунке показана система, в которой для служб Notification Services используется три сервера: на одном сервере запущен генератор и внутрипроцессные поставщики событий, а на двух других — распространители.

Генератор расположен вместе с внутрипроцессными поставщиками событий. Это связано с тем, что процесс генератора не требует существенных ресурсов процессоров или дисков. Большая часть функций генератора выполняется на сервере базы данных.

Примечание.
Генератор для каждого приложения можно разместить на его собственном сервере, но каждое приложение использует только один генератор.

Рекомендуемое количество процессоров для форматирования и распространения зависит от сложности алгоритма форматирования и настроек журналов распространения. При сложном форматировании для сервера, на котором находится распространитель, необходимо больше ресурсов для обработки. При записи в журнал текста уведомлений в базах данных приложений должно быть достаточное дисковое пространство для сохранения записанных сведений. Дополнительные сведения см. в разделе Настройка ведения журнала на распространителе.

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

Внепроцессные поставщики событий

Ядро служб Notification Services может запускать узел поставщиков событий, поддерживающий стандартные поставщики событий, поставляемые со службами уведомлений, и пользовательские внутрипроцессные поставщики событий, разработанные пользователем или сторонними организациями. Однако бывают случаи, когда проще использовать внепроцессный (или независимый) поставщик событий. Часто эти внепроцессные поставщики событий запускаются на отдельных серверах, например на веб-серверах.

Внепроцессные поставщики событий используют API-интерфейс служб Notification Services для соединения с базами данных и пересылки событий, но для них не требуется ядро служб Notification Services. Для использования внепроцессного поставщика событий на отдельном сервере требуется установка клиентских компонентов служб Notification Services и регистрация экземпляра на этом сервере, но при этом не требуется создание службы Windows, запускающей ядро служб Notification Services.

На приведенной ниже диаграмме показана система с удаленным внепроцессным поставщиком событий.

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

Интерфейсы управления подписками

Подобно внепроцессным поставщикам событий, интерфейсы управления подписками используют API-интерфейс служб Notification Services для соединения с базами данных и пересылки событий, но для них не требуется ядро служб Notification Services. На сервере, например на веб-сервере, на котором размещены интерфейсы управления подписками, необходимо установить клиентские компоненты служб Notification Services и зарегистрировать экземпляр, на котором размещено приложение управления подписками. Службу WIndows при этом создавать не нужно.

На следующей диаграмме показана система с удаленным приложением управления подписками.

Для получения сведений о развертывании см. Развертывание интерфейса управления подписками.

См. также

Задачи

Пошаговое руководство по масштабному развертыванию

Основные понятия

Конфигурации оборудования
Замечания относительно служб Notification Services
Анализ базы данных
Планирование ресурсов базы данных

Справка и поддержка

Получение помощи по SQL Server 2005