Предоставление услуг |
В данном разделе описываются административные службы, которые вы должны можете предоставлять своим клиентам, и приводится краткий обзор методов реализации этих служб.
Предоставление услуг
Если вы обслуживаете несколько компаний или виртуальных организаций в рамках одного экземпляра службы Active Directory, то требуется создать базовую структуру предоставления услуг. Новый клиент должен иметь возможность автоматически подписываться на услуги и подписывать своих новых пользователей, не беспокоясь о настройке консоли управления MMC, службы Active Directory или параметров безопасности.
Система предоставления услуг состоит из нескольких блоков. Среди них основным является обработчик системы предоставления услуг, снабженный COM-интерфейсом, принимающим данные формата XML, HTTP и DAV (Distributed Authoring and Versioning).
Обработчик системы предоставления услуг может функционировать как отдельный модуль, например, когда информация поступает непосредственно от конечных пользователей через веб-страницу. Он может работать в конфигурации «главный-подчиненный»; например, главным элементом может быть система выставления счетов, отправляющая данные о подписке обработчику системы предоставления услуг, а сам обработчик будет играть роль подчиненного узла.
Обработчик системы предоставления услуг взаимодействует с объектом настройки. Объект настройки представляет собой интерфейс для работы с некоторой системой, такой как служба Active Directory или Exchange 2000. Вы можете также создавать свои объекты настройки для собственной базы данных или службы выставления счетов.
Связь между обработчиком системы предоставления услуг и объектом настройки осуществляется в виде транзакций с помощью службы транзакций MTS (Microsoft Transaction Services). Благодаря этому в случае какой-либо ошибки можно будет произвести откат транзакции. Объекты настройки службы Active Directory и Exchange 2000 взаимодействуют с их службами через интерфейсы ADSI и CDOEXM.
На этой схеме показано схематическое изображение системы предоставления услуг.
Рис. 9. Система предоставления услуг
Для передачи информации в службу Active Directory объект настройки этой службы использует следующие команды интерфейсов ADSI и CDOEXM:
v CreateOrganization;
v DeleteOrganization;
v CreateUser;
v DeleteUser;
v CreateDistributionList;
v DeleteDistributionList;
v EnableUser;
v DisableUser;
v AddUserToGroup;
v RemoveUserFromGroup;
v ChangePassword;
v ListAllFromGroup;
v GetProperties;
v SetProperties;
v CreateContact;
v DeleteContact;
v ResetPassword;
v LookupOrgFromTrustee;
v LookupOrgFromUPN.
Для передачи информации на сервер Exchange объект настройки сервера Exchange использует следующие команды интерфейсов ADSI и CDOEXM:
v CreateOrganization/DeleteOrganization;
v DisableMailBox;
v EnableMailBox;
v CreateMailBox;
v DeleteMailBox;
v SetDefaultMailBoxSize;
v GetMailBoxSize;
v MoveMailBox.
Если вы создаете свою собственную систему предоставления услуг, вы должны включить эти команды в базовые интерфейсы компонентов ADSI и CDOEXM.
В базе данных Microsoft SQL Server™ ведется журнал аудита, в котором хранится протокол выполнения всех транзакций, проходящих через обработчик системы предоставления услуг. В этот журнал включаются результаты каждой транзакции (успешное завершение или сбой, а также причина сбоя), коды ошибок и сообщения.
Все службы ведут журналы событий. Если вы создаете свои объекты настройки, то должны также обеспечить занесение всех событий в журнал. Можно настроить систему на запись событий в журнал, однако лучше представлять эти события в виде событий поставщика WMI. В таком случае создается служба, которая подписывается на события WMI, собирает их и сохраняет в базе данных сервера SQL Server. В результате вы получаете возможность проводить анализ использования служб; к тому же на этой основе можно создать интерфейс для работы с системой выставления счетов.
Примечание. В настоящее время корпорация Майкрософт работает над описанной структурой и планирует закончить работы в конце 2000 г.
Выставление счетовБиллинг
Вам как ASP-поставщику нужно каким-то образом организовать взимание платы с клиентов за предоставляемые услуги. Для этого необходимо составить план обслуживания, в котором описываются предлагаемые услуги и указывается их стоимость. Затем необходимо организовать мониторинг и ведение журнала для каждой службы. Корпорация Майкрософт не выпускает программное обеспечение для службы выставления счетов, но она предлагает фундамент, на базе которого вы можете сами создавать соответствующие программные средства. В данном разделе рассказывается в общих чертах, как может работать подобная система выставления счетов. За более подробной информацией о создании системы выставления счетов обращайтесь в фирму, разрабатывающую такое программное обеспечение.
Каждое действие, добавление или удаление, осуществляемое с помощью обработчика системы предоставления услуг, порождает события, которые могут быть занесены в журнал событий сервера Windows 2000 Server. В этот журнал записываются и другие события, связанные с пользователями, виртуальными организациями и службами. Эти записи можно использовать при выставлении счетов.
Типичным примером инструмента, применяемого для выставления счетов, является квота на почтовый ящик. Когда пользователь превысит лимит размера своего почтового ящика, генерируется предупреждение, которое вносится в журнал событий. Это событие порождает сообщение, автоматически выдаваемое пользователю и системе выставления счетов; в нем пользователю предлагается возможность увеличить размер его почтового ящика.
При добавлении новой компании или нового пользователя объект настройки помещает все записи в службу Active Directory и систему Exchange 2000. Вы (или независимый производитель программ выставления счетов) можете построить свой объект настройки, записывающий в базу данных дополнительные сведения, которые понадобятся для выставления счета. Графическое представление этого механизма приводилось в предыдущем разделе настоящего документа.
Информация, используемая в системе выставления счетов, должна собираться из различных файлов журналов, доступных через службу WMI. В частности, должен учитываться журнал событий сервера Windows 2000 Server или журнал службы IIS системы Windows 2000. Можно также привлекать события системы Web Storage System, события протокола или события транспорта; это позволит выполнять определенные действия в зависимости от режима использования служб.
При создании специальных служб выставления счетов на основе транзакций убедитесь, что все транзакции регистрируются, по крайней мере, в журнале событий сервера Windows 2000 Server. Но лучшим решением является предоставление всей информации через поставщика WMI. Это позволит другой службе подписаться на услуги поставщика и использовать данную информацию для иных целей.
Служба выставления счетов должна подписаться на доступ к различным поставщикам WMI (и системным, и собственным) и собирать всю информацию в базу данных счетов. Как уже отмечалось, такую базу данных можно использовать и для анализа режима использования служб.
Совместная работа в режиме реального времени |
Необходимо, чтобы пПользователи должны иметь возможность взаимодействоватьмогли сотрудничать друг с другом в режиме реального времени, где бы они ни находились. Они должны иметь возможность участвовать в групповых обсуждениях и совместных проектах, работать с общими файлами, вести конфиденциальные беседы независимо от своего местонахождения. Вы можете предоставить своим клиентам такие услуги; для этого используются следующие службы совместной работы, поддерживаемые в Exchange 2000:
v Instant Messaging (служба немедленной передачи сообщений);
v Chat Service (служба разговоров);
v Conferencing Service (служба конференций).
Эти службы подробно описываются в последующих разделах.
Служба немедленной передачи сообщений
С помощью службы немедленной передачи сообщений (Instant Messaging) пользователи могут вести конфиденциальную беседу «один на один» и подписываться на информацию о присутствии своих корреспондентов. Информация о присутствии содержит сведения о состоянии: Online (работает в сети), Invisible (невидим), Busy (занят), Be Right Back (сейчас вернется), Away (отсутствует), On the Phone (говорит по телефону), Out to Lunch (на обеде) или Appear Offline (работает автономно). Если пользовать подписан на информацию о присутствии другого пользователя, то при изменении состояния последнего он будет тут же оповещен об этом факте.
Служба немедленной передачи сообщений, в отличие от обычной электронной почты, не сохраняет копии сообщений в системе. Когда вы завершаете сеанс немедленной передачи сообщений, эти сообщения теряются.
В состав службы немедленной передачи сообщений входит три фундаментальных элемента:
v домен немедленной передачи сообщений – логическая совокупность пользователей и серверов, представленная виртуальным сервером;
v домашний сервер немедленной передачи сообщений – виртуальный сервер, на котором размещаются учетные записи пользователей данной службы, а также хранится информация о присутствии;
v маршрутизатор немедленной передачи сообщений – принимает сообщения и выбирает для них маршрут к соответствующему домашнему серверу.
Служба немедленной передачи сообщений запускается работает на сервере IIS (Microsoft Internet Information Services – информационные службы Интернета) в качестве подключаемой библиотеки с помощью DLL-файла интерфейса ISAPI (Internet Server Application Programming Interface). Все атрибуты пользователей и данные, необходимые для проверки подлинности, предоставляются службой Active Directory. Информация о присутствии хранится в базе данных узла, которая также играет роль модуля ESE (Extensible Storage Engine – расширяемый модуль обработки хранилищ данных). Связь между службой IIS, базой данных узла и службой Active Directory реализуется на уровне серверного приложения. Связь между клиентом и сервером поддерживается средствами протокола RVP (Rendezvous protocol), представляющего собой расширение протокола HTTP-DAV (HTTP-Distributed Authoring and Versioning). Архитектура системы немедленной передачи сообщений представлена на следующей схеме.
Рис 10. Архитектура системы немедленной передачи сообщений
FTM (Firewall Topology Module – модуль топологии брандмауэра) представляет собой службу сервера немедленной передачи сообщений, в которой хранится информация о каждом таком сервере, независимо от того, по какую сторону брандмауэра он находится. Кроме того, службой FTM сохраняются сведения о том, как можно проникнуть через брандмауэр. Служба FTM содержит данные, которые определяют, может ли данный IP-адрес источника подключиться к данному IP-адресу назначения и требуется ли прокси-сервер. Прокси-сервер – это сервер немедленной передачи сообщений, расположенный между брандмауэром и домашним сервером или сервером маршрутизации.
Идентификация всех пользователей службы немедленной передачи сообщений осуществляется при помощи уникальных URL-адресов. Каждому пользователю назначаются два URL-адреса: адрес домашнего сервера и адрес домена, указывающий на маршрутизатор немедленной передачи сообщений. Вместо URL-адреса можно использовать имя пользователя службы немедленной передачи сообщений, формат которого вы можете установить в виде user@im_domain. Чтобы такими именами можно было пользоваться, вы должны зарегистрировать все домены немедленной передачи сообщений в системе DNS (Domain name system – система доменных имен).
Масштабирование службы немедленной передачи сообщений
Один домашний сервер немедленной передачи сообщений может обслуживать доодновременных подключений, а один маршрутизатор немедленной передачи сообщений – доодновременных подключений. Подключение означает, что пользователь запустил на клиентском компьютере службу немедленной передачи сообщений.
В секторе индивидуальных пользователей служба немедленной передачи сообщений применяется иначе, чем в сфере бизнеса. Типичный бизнес-пользователь проводит в подключенном режиме в среднем 80% рабочего времени, тогда как обычный пользователь – лишь 5–10% времени.
Клиенты подключаются к маршрутизаторам немедленной передачи сообщений, которые ретранслируют входящие запросы на соответствующий домашний сервер. На следующем рисунке показана топология развернутой системы немедленной передачи сообщений.
Рис. 11. Топология немедленной передачи сообщений
Подробнее о службе немедленной передачи сообщений см. раздел Instant Messaging (Немедленная передача сообщений) в документации по серверу Exchange 2000 Server.
Служба разговоров
С помощью службы разговоров (Chat Service) пользователи могут обсуждать различные темы в форумах со связью типа «один-ко-многим» (эти форумы также называют каналами или комнатами). Комнаты организованы в виде виртуальных сообществ, в каждом из которых затрагивается свой круг тем.
Служба разговоров Exchange 2000 интегрирована в систему Windows 2000 и использует следующие ее средства:
v службу каталогов Active Directory;
v средства безопасности Windows 2000;
v службы кластеризации.
Для установки службы разговоров в среде размещения на сервере ASP-поставщика необходимо сначала оценить размеры обслуживаемых компаний. Типичный сервер разговоров может поддерживать одновременно допользователей из разных сообществ. Если у ваших заказчиков приблизительно такое количество пользователей, вам следует установить службу разговоров на компьютере с четырьмя процессорами и оперативной памятью объемом 512 МБ.
Если организации, являющиеся вашими заказчиками, имеют небольшие размеры, можно для каждой из них создать свое сообщество. С помощью службы Active Directory можно проводить проверку подлинности пользователей и формировать списки управления доступом для каждого сообщества так, чтобы оно было скрыто от других компаний. Например, предположим, что к вашему серверу разговоров подключается пользователь *****@***com. Поскольку для всех сообществ действуют таблицы управления доступом (ACL), JohnB сможет видеть лишь каналы, выделенные для компании .
Если среди ваших клиентов есть крупная компания, вы можете установить выделенный сервер разговоров, который будет обслуживать сообщества, относящиеся только к этой компании. Присвойте серверу подходящее имя, назначьте ему запись DNS и правильно установите параметры безопасности. О том, как это делать, см. раздел Instant Messaging (Немедленная передача сообщений) в документации по серверу Exchange 2000 Server. На следующем рисунке показана схема развертывания службы разговоров, в которой выделены серверы для конкретных организаций.
Рис. 12. Размещение службы разговоров на выделенных серверах
Несколько Сслужба разговоров могут, как служба, размещаться на одном сервереемая на сервере ASP-поставщика, поддерживает сообщества, которые представляют собой в общем случае несколько виртуальных экземпляров службы разговоров, находящихся на одном сервере, но с точки зрения подключенного пользователя они выглядят как несколько автономных служб разговоровсерверов. Вы настраиваете параметры и систему безопасности отдельно для каждого сообщества, что позволяет оказывать услуги по сопровождению и проводить индивидуальное развертывание.
Служба разговоров Exchange 2000 интегрирована со службой безопасности системы Windows, и поэтому к сообществам и зарегистрированным каналам (комнатам) можно применять списки управления доступом (ACL). Для проверки подлинности можно использовать любой интерфейс SSPI (Security Service Provider Interface – интерфейс поставщика служб безопасности), при условии, что его поддерживает клиент службы разговоров; в частности, могут использоваться поставщики независимых производителей и самих заказчиков. К числу дополнительных средств управления безопасностью относятся запреты на присутствие и классы участников, с помощью которых можно, используя протокол разговоров, контролировать и ограничивать доступ и возможности пользователей.
Служба разговоров Exchange 2000 также поддерживает модель Server Extensibility (расширяемость сервера), которая подробно описывается в материалах комплекта Microsoft Platform SDK. На основе этой модели вы можете разрабатывать собственные расширения, которые позволяют наблюдать за событиями, происходящими в службе разговоров, и реагировать на них.
Можно создавать расширения, поддерживающие модель COM, на языках Microsoft Visual Basic, Visual C++ и др. С помощью соответствующего API-интерфейса расширения могут реагировать на события, связанные с серверами, пользователями и каналами, – и локально, и в сети разговоров. Вдобавок к возможностям расширения API-интерфейса, объектная модель сервера разговоров (Chat Server Object Model) обеспечивает широкий спектр услуг доступа к каналам и пользователям, зарегистрированным на сервере. Наконец, объектная модель администрирования службы разговоров (Chat Service Administration object model) позволяет настраивать саму службу разговоров.
Вы можете использовать расширения для создания собственных моделей входа, а те, в свою очередь, – для анализа использования служб и выставления счетов.
Как и в предыдущих выпусках, служба разговоров использует в качестве основного инструмента наблюдения за рабочими характеристиками счетчики производительности Windows. Служба разговоров и ее сообщества поддерживаюет также несколько собственных счетчиков. Счетчики службы разговоров предоставляют информацию о самой службе, например, общее число клиентских подключений, серверных операций, поставленных в очередь, и активных рабочих потоков. Счетчики сообществ разговоров позволяют изучать отдельные экземпляры сообщества: например, они показывают число анонимных клиентов, число клиентов, прошедших проверку достоверности, число подсоединений к каналу, число полученных или отправленных байтов. Подробнее о событиях службы разговоров Exchange и счетчиках системного монитора см. в документации комплекта Platform SDK.
Службы конференций
Сервер Exchange 2000 Conferencing Server дает пользователям возможность проводить виртуальные встречи. На клиентской стороне пользователю предоставляются такие мультимедийные услуги, как аудио - и видеосвязь, передача файлов, разговоры и общая доска. Пользователи могут планировать интерактивные встречи и резервировать необходимые для них ресурсы с помощью приложения Microsoft Outlook 2000. Клиентский компьютер использует протокол T.120, интегрированный в такие продукты, как программа проведения конференций Microsoft NetMeeting®.
Сервер Exchange 2000 построен на базе архитектуры CTP (Conference Technology Provider – поставщик технологии конференций). В комплект Exchange 2000 включены два CTP-поставщика: один для многоадресных аудио - и видеоконференций и один для информационных конференций. При обслуживании конференций сервер Exchange 2000 выступает в роли сервера информационных конференций с полной поддержкой протокола T.120 и способен поддерживать аудио - и видеопотоки многоадресной передачи по протоколу IP.
Многоточечные информационные конференции поддерживают следующие возможности.
v Совместное использование приложений. Пользователь может предоставить в общее пользование другим участникам конференции программу, работающую на его компьютере, такую какнапример, Microsoft Word. Участники конференции смогут одновременно просматривать одну и ту же информацию и наблюдать за действиями, которые выполняет в документе пользователь, предоставивший приложение в общий доступ.
v Передача файлов. Участник конференции может отправить файл другому участнику или всем остальным участникам. Передача файла происходит в фоновом режиме, так что все могут продолжать работать в приложении, пользоваться доской или вести разговор.
v Доска. С помощью этого многостраничного многопользовательского приложения для рисования участники конференции могут чертить схемы и отображать другую графическую информацию.
v Разговоры. Пользователь может вводить текстовые сообщения, адресованные другим участникам конференции, а также вести заметки по ходу встречи и записывать выполняемые действия.
Основное различие между решением одноранговой конференц-связи, подобным NetMeeting, и серверным решением, таким как Exchange 2000, заключается в том, что во втором случае весь сеанс связи проходит централизованно на сервере. При использовании NetMeeting «хозяином» конференции становится инициировавший ее клиент, и когда он выходит из конференции, она завершается.
Сервер использует многоадресную передачу по протоколу IP; эта эффективная технология связи типа «один-ко-многим» создает связующее дерево, в котором любые два маршрутизатора связаны между собой только одним путем. Клиент регистрируется (подписывается) на маршрутизаторе многоадресной передачи. Многоадресную IP‑передачу следует отличать от широковещательной рассылки, когда информация отправляется каждому клиенту, подключенному к сети.
В качестве транспорта многоадресной IP-передачи используется протокол RTP (Real-Time Transport Protocol), который предусматривает использование стандартного мультимедийного заголовка, включающего штамп времени, порядковый номер пакета и информацию о формате полезных данных.
Exchange 2000 устанавливает две службы Windows 2000 для проведения конференций:
v Exchange Conferencing Service (служба конференций Exchange) – компонент службы конференций, отвечающий за планирование и резервирование, называемый также Conference Management Service (служба управления конференциями);
v модуль Exchange T.120 MCU (Multi-point control unit – блок управления многоточечной связью) – среда проведения сеансов конференций в стандарте T.120.
Компоненты сервера Exchange 2000 Conferencing Server показаны на следующем рисунке.
Рис. 13. Сервер Exchange 2000 Conference Server
Система Windows 2000 поддерживает информационные конференции Exchange с использованием следующих служб:
v Active Directory;
v IIS;
v сервер DHCP (Dynamic Host Configuration Protocol) с поддержкой расширенной многоадресной передачи;
v QoS (Quality of Service – качество обслуживания).
Сервер DHCP с поддержкой расширенной многоадресной передачи
Чтобы вести многоадресную передачу, сервер должен иметь адрес для многоадресных IP-конференций. Такие адреса предоставляет протокол MADCAP (Multicast Address Dynamic Client Allocation Protocol). MADCAP – это расширение службы DHCP, входящее в комплект поставки этой службы, но независимое от нее. Службы MADCAP могут работать на одном сервере, а служба DHCP – на другом.
Сервер, на котором работает служба управления конференциями и, следовательно, CTP-поставщик службы видеоконференций, должны иметь сетевое подключение к серверу Windows 2000 Server с установленной службой MADCAP. Последнюю можно запустить независимо от любых имеющихся служб DHCP, но устанавливается она с помощью службы DHCP.
QoS
Обычный трафик данных основан на передаче по протоколу IP без установки подключений, причем этот протокол не гарантирует доставку каждого пакета. Приложения реального времени, в частности, мультимедийные приложения, работают в зависимости от доступности сети и ее пропускной способности; в связи с этим возникает необходимость в поддержании качества обслуживания (QoS). В системе Windows 2000 поддержка QoS реализована с помощью ряда компонентов, которые могут сотрудничать взаимодействовать друг с другом и вызывать друг друга; в частности, предлагаются следующие возможности:
v поддержка мультимедийных приложений, работающих в режиме реального времени;
v гарантия своевременной передачи больших массивов данных;
v возможность совместного использования сети в режиме, исключающем дефицит пропускной способности, предоставляемой приложениям.
Сервер конференций в центре данных
При развертывании крупномасштабной системы Exchange 2000 Conferencing Server необходимо установить выделенные серверы для каждой службы. Число требуемых модулей T.120 MCU зависит от профиля использования служб. На следующем рисунке показана схема развертывания сервера конференций, включающая службу управления конференциями и два модуля T.120 MCU.
Рис. 14. Развертывание сервера Exchange Conferencing Server со службой управления конференциями и двумя модулями MCU
Между использованием сервера конференций внутри корпорации и для услуг хостингативной среде и его использованием в среде размещения, реализуемой ASP-поставщиком, существуют четкие различия. В корпоративной среде каналы связи между клиентами и сервером не проходят через брандмауэр и Интернет. Хостинг Ссервера конференций в среде размещения реализовать труднее, поскольку служба управления конференциями и модули MCU находятся позади за брандмауэраом, и пользователи должны обращаться к серверу конференций через этот брандмауэр.
Задача развертывания еще более усложняется, когда клиент находится в среде организации и для доступа в Интернет должен проникнуть через ее внутренний брандмауэр. В этом случае клиент, осуществляющий доступ к серверу конференций, вынужден преодолевать два брандмауэра.
Служба видеоконференций
Служба видеоконференций создает источник событий, из которого выдаются сообщения об ошибках. Эти события должны генерироваться для всех сбоев, прерывающих работу действующих служб. В дальнейшем после ликвидации сбоя генерируется еще одно событие, сигнализирующее о восстановлении работы.
В службе видеоконференций реализованы следующие счетчики производительности:
v Active Conferences – число активных конференций;
v Join Requests – число запросов на подсоединение;
v Active MADCAP – описание последней области, обслуживавшей адрес многоадресной передачи последней;
v Active ILS – имя сервера ILS (Internet Locator Service – служба локатора Интернета), на котором публикуются общедоступные конференции;
v ILS Publish Errors – число конференций, которые не удалось опубликовать на сервере ILS;
v Public Conferences – число активных общедоступных конференций;
v Private Conferences – число активных частных конференций;
v Join Request Denied – число запросов на подсоединение, отклоненных из-за того, что число участников уже достигло максимально допустимого предела.
Журналы
Служба управления конференциями создает журнал событий, в котором регистрируются некоторые виды операций. Конфигурация, фиксирующая такие события, определяется на странице свойств службы управления конференциями. Каждое событие записывается в файл типа CSV, именем которого служит дата генерации файла, как это делается для файлов журналов IIS.
Используя эти файлы, вы можете изучать операции сервера конференций в целях выставления счетов, анализа использования служб и т. п.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 |
