Рис. 10. Пример отчета: результаты поиска в Яндекс. Строки отчета являются ссылками.

Лекция 4.  Архитектуры и администрирование информационных систем

Архитектуры информационных систем

Архитектура — обобщенный взгляд на ИС. Всякий дом имеет фундамент, стены, двери, ок­на и крышу, но в разных сочетаниях. Так и ИС может в разных своих компонентах по-раз­ному сочетать свои функции. Говоря об архитектуре ИС, обычно рассматривают про­с­т­ран­ственно-логическое разделение функций между компонентами ИС.

В простейшем случае все функции ИС сосредоточены в одном компоненте (выполняются на одном компьютере). Такие ИС называют монолитными. Монолитные ИС, как правило, — одно­поль­зо­вательские.

Архитектура клиент-сервер

Распространена архитектура клиент-сервер. В компоненте "клиент" сосредотачиваются фун­кции клавиатурного ввода, формирования запросов на поиск, формирования ре­зуль­та­тов вывода; хранение и обработка, собственно поиск и формирование вывода вы­пол­ня­ют­ся сервером. Клиент и сервер взаимодействуют по определенному протоколу, фак­ти­чес­ки выступая как самостоятельные неполнофункциональные ИС. Обычно один сервер может взаимодействовать с несколькими клиентами. Клиент и сервер не обязательно раз­ме­щаются на различных компьютерах, но могут быть размещены и на одном компь­ю­те­ре.

Разделение функции между клиентом и сервером может быть различным. Например, кли­ент может только собирать вводимые данные, а все проверки выполняться сервером; в другом варианте ИС часть (или все) проверок может быть перенесена в клиента. Клиент может выполнять и какую-то обработку данных. Чтобы отразить степень переноса функ­ций в клиента, говорят о тонких (thin) и толстых (fat) клиентах. Тонкий клиент ме­нее требователен к вычислительным ресурсам компьютера, упрощает централизованное администрирование ИС, но повышает требования к вычислительным ресурсам сервера. Толстый клиент более требователен к вычислительным ресурсам, но снижает нагрузку на сервер.

Многозвенные архитектуры

Клиент-серверную архитектуру ИС иногда называют двухзвенной (two-tier). Сущест­ву­ют трехзвенные архитектуры и архитектуры с большим количеством звеньев. Много­з­вен­ные архитектуры возникают в случае необходимости сложной и/или спе­ци­а­ли­зи­ро­ван­ной обработки информации в ИС.

Примеры многозвенных архитектур

Диспетчер транзакций

Операции поиска и обработки данных, например, в банке или системе резервирования авиабилетов, могут быть схожими для различных клиентов и состоять из по­сле­до­ва­тель­нос­тей коротких несложных операций, которые, однако, могут влиять на операции со­сед­них клиентов (например, запросить рейс –> запросить место –> зарезервировать место –> отметить оплату –> место продано). Такие последовательности операций (называемые транзакциями) нельзя прерывать — последовательность либо должна быть выполнена це­ликом, либо целиком отменена.

Операции по координации таких действий возлагаются на диспетчер транзакций.

Сервер аутентификации

Сервер аутентификации проверяет возможность доступа в ИС, а OLAP-сервер выполняет сложный анализ данных.

Рис. 12. Сервер аутентификации проверяет возможность доступа к ИС,
а OLAP-процессор вы­пол­няет сложный анализ данных

Веб-сервер с динамическим порождением страниц

Клиент — веб-браузер — взаимодействует с веб-сервером по протоколу HTTP через два межсетевых экрана (брандмауэра, файервола) и прокси-сервер. На веб-сервере выпол­ня­ет­ся приложение PHP (ASP, JSP, Perl или какое-либо другое), которое обращается к сер­ве­ру баз данных.

Администрирование ИС

Администрирование ИС — это совокупность мероприятий, обеспечивающих требуемые характеристики эксплуатации ИС и выполняемых специально обученным персоналом — администраторами. Требуемые эксплуатационные характеристики могут быть раз­лич­ны­ми, однако некоторые из них встречаются в большинстве ИС, а некоторые — во всех ИС. Рассмотрим эти (встречающиеся во всех ИС) характеристики — надежность, дос­туп­ность (для пользователей) и эффективность — и соответствующие мероприятия.

Надежность

Надежность функционирования требуется от всех ИС.

Введем некоторые определения.

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

Под прекращением функционирования ИС понимается не только физический выход из строя оборудования, но и, например, такое изменение характеристик ИС, которое делает невозможным ее обычное применение (например, изменение времени реакции системы на действие пользователя с 0,1 до 10 сек или отказ в доступе санкционированному поль­зо­вателю).

Количественные характеристики надежности ИС (частота сбоев/отказов или обратная ве­личина — время наработки на сбой/отказ) задаются при разработке ИС при выполнении определенных условий эксплуатации:

Использовании оборудования и ПО необходимого уровня надежности Дублирования оборудования (горячего резервирования — во включенном состоя­нии) Резервирования оборудования (холодного — в выключенном состоянии) и электро­пи­тания Защиты ИС от несанкционированных внешних воздействий (атак) Выполнение работ по обслуживанию в соответствии с регламентом, например:
Обеспыливание системных блоков — 1 раз в 6 месяцев Проверка и замена вентиляторов блоков питания — 1 раз в 6 месяцев Проверка и замена вентиляторов процессоров — 1 раз в 2 месяца Проверка напряжения в сети питания — 1 раз в 3 дня Обновление БД антивируса — ежедневно Сканирование НЖМД — 1 раз в три дня Анализ и установка заплат ПО — 1 раз в 2 дня и т. д.

Выполнение регламентных работ фиксируется в журналах регламентных работ.

Журнал регламентных работ

Рис. 14. Пример журнала регламентных работ

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 5 6