Математическое обеспечение и администрирование информационных систем

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

Во-вторых, требуется выработать и  согласовать стандарты интерфейсов  на разработку или приобретение аппаратных и программных средств.

1.2. Архитектура «клиент-сервер» и «клиент-серверные» технологии.

1.2.1. Введение.

Говоря о прикладных системах, предназначенных  для работы с базами данных, чаще всего на ум приходит модель вычислений, основанная на двух взаимодействующих  компонентах - клиенте, отвечающем за организацию диалога с пользователем и несущем на себе бизнес-логику, и сервере, обеспечивающем многопользовательскую работу с данными и их целостность. Описанная таким образом архитектура клиент-сервер является более фундаментальным явлением, чем просто способ построения приложений a-la "многопользовательская бухгалтерия". На нынешнем уровне зависимости бизнеса от информационных систем разработчикам приходится сталкиваться не только с задачами реализации адекватных техническим требованиям функциональности и пользовательского интерфейса, но и с оптимизацией обмена данным между различными компонентами системы. Учитывая, что корпоративные системы обладают достаточно высоким уровнем сложности, в процессе их эксплуатации возникает ряд вопросов связанных с надежностью и управляемостью такой системы. Появление такого рода акцентов в процессе проектирования и разработки корпоративных систем приводит к необходимости решения следующей важной задачи - выделения из клиентской и серверной части системы компонентов, несущие на себе строго определенную служебную функциональность.

1.2.2. Традиционные подходы в моделировании

Попытаемся разбить систему  на функциональные фрагменты¹.

На верхнем уровне абстрагирования  достаточно четко можно выделить следующие компоненты:

• презентационная логика (Presentation Layer - PL);
• бизнес-логика (Business Layer - BL);
• логика доступа к ресурсам (Access Layer - AL).

Таким образом можно, можно придти к нескольким моделям клиент-серверного взаимодействия²:

• "Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. Такая модель подразумевает объединение в клиентском приложении как PL, так и BL (см. выше). Серверная часть, при описанном подходе, представляет собой сервер баз данных³., реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access.
• "Тонкий" клиент. Модель⁴, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.
• Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL.

Однако, разработчик - это не Илья Муромец, стоящий перед тремя дорогами, все больше напоминающими три наезженных колеи. При этом, описанные три модели организации клиент-серверных систем в определенной степени являются ориентирами в задании жесткости связей между различными функциональными компонентами, чем строго описываемыми программами в реальных проектах. Жесткость связей в схеме взаимодействия компонент системы часто определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL), обеспечивающего обмен информацией между различными компонентами.

1.2.3. Серверы приложений

С точки зрения применения описанных моделей, при проектировании прикладных систем разработчик часто сталкивается с правилом 20/80. Суть этого правила заключается в том, что 80% пользователей обращаются к 20% функциональности, заложенной в систему, но оставшиеся 20% задействуют основную бизнес-логику - 80%. В первую группу пользователей попадают операторы информационных систем (ввод и редактирование информации), а также рядовые сотрудники и менеджеры, обращающиеся к поисковым и справочным механизмам (поиск и чтение данных). Во вторую группу пользователей попадают эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления.

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

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

Таким образом, мы приходим к анализу  существующих распределенных объектных  моделей. На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ ActiveX и CORBA/DCE/Java. Если в первом случае требуемые механизмы поддержки модели являются неотъемлемой частью операционной платформы Win32 (Windows 95/NT/CE), то во втором случае предусмотрена действительная кроссплатформенность (например, везде, где есть виртуальная машина Java). Если попытаться объективно оценить (хотя любая такая попытка во многом субъективна) перспективы применения этих моделей, то для этого необходимо понять требования к операционным платформам, выдвигаемые различными функциональными компонентами системы. При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL, AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов (Reporting), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server - AS). Причем, сервер приложений не просто является некоим единым универсальным средним BL-звеном между клиентской и серверной частью системы, но AS существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия.

Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного  управления приводит к тому, что  системы корпоративных масштабов  требуют сочетания различных  клиент-серверных моделей в зависимости  от задач, решаемых на различных конкретных направлениях деятельности предприятия. Вспомнив, снова, о правиле 20/80 можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трех-уровневой, а многоуровневой (N-tier) модели, объединяющей различных по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware - MOM; Object Request Broker - ORB; ...) , переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого - мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т.п.

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

Рисунок 1.1. Многоуровневая клиент-серверная модель

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

1.2.4. Заключение

Тема построения многоуровневых клиент-серверных систем, наконец, стала уделом не только архитекторов, но и разработчиков. Многое из того, что казалась красивым и легким в теории, иногда оказывается нереализуемым на практике. Многоуровневые системы клиент-сервер уже доказывают свою жизнеспособность. Вероятно, пришло время начать их более детальное описание. Этот материал затронул только два взаимосвязанных подхода - серверов приложений и "многоуровневости от клиента", приводящих к системам с распределенной бизнес-логикой. Надеюсь, что это хорошая тема для детализации.

1.3. Построение многопользовательских  информационных систем и управление  ими.

1.3.1. Цели администрирования

Основной целью администрирования  является приведение информационной системы  в соответствие целям и задачам  предприятия или организации.

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

Система дает возможность администратору уделить больше внимания на решение  вопросов типа "что сделать?", а  не "как сделать?".

1.3.2. Обязанности системного администратора

• Планирование системы: (пользователи/группы; планирование использования дискового пространства; подсистемы (печать, сеть и т.п.); присвоение имен; определение системной политики);
• Установка и конфигурация аппаратных устройств;
• Установка программного обеспечения;
• Установка сети;
• Архивирование (резервное копирование) информации;
• Создание и управление счетами пользователей;
• Контроль защиты;
• Определение и управление подсистемами;
• Управление системными ресурсами;
• Мониторинг производительности;
• Планирование нагрузки;
• Управление лицензиями;
• Документирование системной конфигурации.

1.3.3. Проблема организации администрирования крупных информационных систем.

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

Использование небольшой группы автономных компьютеров требует самой минимальной регламентации. Объединение их в сеть приводит к необходимости создания развернутого и жесткого набора правил.

Качественный состав задач администрирования  и их приоритеты изменяются с ростом системы изменением ее функциональности. Так, например, небольшой сетью на базе Novell NetWare из 10-15 машин и не подключенной к Internet вполне может управлять один администратор, совмещая эти обязанности с обязанностями прикладного программиста. При этом, как правило, большинство настроек устанавливается по умолчанию и от администратора не требуется знания многих тонкостей.

Дальнейший рост системы требует  выделения администратора как отдельной  штатной единицы, причем не только из-за возрастающего объема рутинной работы (работа с бюджетами пользователей, архивирование данных, организация поддержки сетевой печати и т.п.), но и из-за появления принципиально новых задач.

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

Основные компоненты администрирования крупных информационных систем:

1. Работа с пользователями. Сюда входит создание и удаление пользовательских бюджетов (учетных записей), их блокировка и разблокирование, настройка сценариев входа, консультирование пользователей по различным аспектам работы с системой и нахождению тех или иных ресурсов. Здесь главное - найти разумную грань, чтобы администратор не был ответственен за смену картриджа в локальном принтере пользователя - это все-таки задача службы технической поддержки. Более того, во многих компаниях на службу технической поддержки возлагают обязанности по установке и настройке сетевого клиентского программного обеспечения на компьютерах пользователей.
2. Управление данными. Предоставление пользователям прав на доступ к конкретным ресурсам, профилактическое обслуживание баз данных (индексация, оптимизация, упаковка), организация резервного копирования.
3. Анализ производительности и оптимизация системы. Большинство систем имеют оптимальные настройки "по умолчанию" и не требуют особого вмешательства. Однако, узкие места все же могут возникать. Производители известных сетевых операционных систем на основе богатого опыта эксплуатации выводят наборы эмпирических правил, помогающих администратору вносить изменения в настройки с минимальным риском ухудшить другие показатели или сделать систему неработоспособной. Такие рекомендации имеются, в частности, у фирм Novell и Sun Microsystems; администратору остается только их изучить и знать перечень параметров, которые необходимо контролировать. Многих проблем можно избежать еще на стадии планирования сети. В частности, неправильный выбор типов кадров Ethernet и их соотношения может привести к резкому снижению производительности, а то и к нарушению работы системы при отключении одного из компонентов.
4. С предыдущей задачей связана задача учета системных ресурсов. Учет ресурсов позволяет заметить тенденции к появлению узких мест до того, как появятся проблемы с производительностью и провести соответствующую модернизацию. Кроме того, система учета совершенно необходима при платном использовании ресурсов. Сюда относится контроль использования дискового пространства, печати, учет трафика.
5. Техническое обслуживание и модернизация. Если собственно техническое обслуживание (очистка от пыли, смазка вентиляторов, подтяжка креплений, контроль состояния аккумуляторов, изменение физической топологии сети и т. п.) может осуществляться службой технической поддержки, то грамотное формулирование заявок на изменение аппаратной конфигурации, организация закупки дополнительных лицензий или обновленной версии программного обеспечения - задача администратора.
6. Очень часто как отдельную функцию выделяют задачу управления активным сетевым оборудованием и сетью в целом.
7. Немаловажным компонентом администрирования системы является обеспечение информационной безопасности. Сюда входит составление плана доступа пользователей к ресурсам (в соответствии с принятой в компании политикой информационной безопасности) и контроль его исполнения. К функциям обеспечения безопасности относятся также отслеживание появления различных уязвимостей в используемых операционных системах, организация получения и установки "заплаток" (patches).
8. И последняя (по порядку изложения, но не по значимости) задача - это задача аудита, данные которого используются почти всеми приведенными выше задачами. С целью обеспечения непротиворечивости получаемой информации доступ к подсистеме аудита должен быть ограничен. Причем лицо, ответственное за подсистему аудита не должно иметь административных полномочий по управлению системой и данным, по которым аудит ведется. Такое разделение позволит существенно повысить уровень безопасности: если человек знает, что его действия протоколируются, то он воздержится от попыток совершения каких-либо манипуляций с информацией во вред компании. По этой же причине он оказывается защищенным от давления со стороны третьих лиц совершить нечто противоправное.