22
I N T ER N E T
Коммутатор
Web-сервер
Маршрутизатор
Сервер баз
данных
Файловый сервер
Рис. 2.1. Фрагмент сети, участвующий в решении задачи
Конечной целью разрабатываемой информационной системы является
предоставление доступа к контенту пользователям – посетителям сайта.
На начальном этапе разработки были собраны пожелания заказчика к
конечному продукту. Особо отмечены следующие требования к веб-
приложению:
Простой, понятный и интуитивный интерфейс;
Предоставление клиенту-держателю контента возможности
редактирования информации о контенте;
Возможность поиска по размещенному на сайте контенту;
Наличие на сайте формы обратной связи;
Возможность сотруднику компании-заказчика вносить новые записи
в базу данных через приложение.
Результатом работы с сайтом является:
Для клиента-держателя контента:
Распространение контента до конечных пользователей-потребителей
контента;
Распространение контактной информации об авторах контента для
связи с ними;
Для сотрудника компании-агрегатора контента:
Сохранение новых записей о клиентах-держателях контента;
23
Получение информации о новых заявках на распространение
контента;
Для пользователя-потребителя контента:
Доступ к контенту;
Доступ к информации о клиентах-держателях контента;
Связь с держателями контента.
Представления заказчика о работе сайта были проанализированы и
представлены в виде схемы на рисунке 2.2.
Просмотр главной страницы сайта
Поиск контента
Оформление заявки
на сотрудничество
Редактирование
информации о
контенте
Добавление новых
записей об авторах
контента
Выбор критериев поиска,
получение результатов, просмотр
информации о контенте
Доступно всем пользователям
Ввод начальных данных о клиенте-
держателе контента,
предоставление информации для
альтернативно связи с компанией-
агрегатором
Доступно всем пользователям
Начальный ввод данных о контенте
в форму, редактирование
информации об авторе и контенте
через форму, сохранение
информации в БД
Доступно только авторизованным
пользователям
Ввод данных о клиенте в форму,
сохранение в БД
Только сотрудникам компании-
агрегатора
Рис. 2.2. Схема работы сайта по представлению заказчика
2.2 Расчет надежности комплекса технических средств
Для оценки общей надежности проекта необходимо провести расчеты
отдельных показателей надежности комплекса технических средств на основе
представленной выше модели комплекса технических средств.
24
Требование, предъявляемое к надежности КТС: g(t)>0,999.
На основе фрагмента сети, участвующего в решении задачи, составим
модель надежности КТС. Данная модель изображена на рисунке 2.3.
Internet
Маршрутизатор Web-сервер Коммутатор
Сервер баз
данных
ЛВС ЛВСЛВС ЛВС Коммутатор
ЛВС
Файловый
сервер
1
2
3
4
5
6
7
8
9
10
1112
Рис. 2.3. Модель надежности комплекса технических средств
Модель надежности представляет собой структуру из 12 последовательно
соединенных, восстанавливаемых (равноценно заменяемых) функциональных
блоков. Каждый компонент имеет постоянные значения следующих
параметров: интенсивность отказов и интенсивность восстановлений.
Интенсивность отказов – параметр, который обратно пропорционален
заявленному производителем гарантийному сроку службы изделия
(указывается в техническом паспорте изделия).
Второй параметр - «интенсивность восстановления» – величина,
обратная ожиданию времени восстановления работоспособности, или
времени, которое потребуется затратить на ремонт оборудования после его
отказа. Этот параметр рассчитывается на основе статистической информации.
В таблице 2.1 представлены расчетные параметры для каждого из
элементов модели КТС предлагаемых вариантов, где:
λ
i
- интенсивность отказов (λ=1/T, где T – срок гарантии в часах);
μ
i
- интенсивность восстановления;
t - время работы за расчетный период (5 лет, t = 43 800 часов)
Таблица 2.1. Сроки гарантии, интенсивности отказов и восстановления
25
Проект 1
Проект 2
Наименование
№
элемента
на схеме
Срок
гарантии
(T)
λ
i
(1/час)
μ
i
(1/час)
λ
i
(1/час)
μ
i
(1/час)
ЛВС
3,5,7,9,11
26 280 ч
0.00003805
0,5
0.00003805
1
Маршрутизатор
2
17 520 ч
0.00005708
0,5
0.00005708
0,5
Коммутатор
6,10
17 520 ч
0.00005708
0,25
0.00005708
0,5
Web-сервер
4
35 040 ч
0.00002853
0,75
0.00002853
1
Сервер баз
данных
8
35 040 ч
0.00002853
0,5
0.00002853
1
Файловый
сервер
12
35 040 ч
0.00002853
0,5
0.00002853
1
Для того, чтобы правильно рассчитать общую надежность
разрабатываемой системы, необходимо учесть еще один параметр, от которого
напрямую зависит ее работоспособность – бесперебойный доступ к сети
интернет.
В связи с тем, что в настоящее время интернет провайдеры
предоставляют бесперебойный доступ к сети, вероятность отказа этого
элемента близка к нулю. В наших расчетах мы также будем полагать, что
вероятность отказа этого элемента (№ 1 на рис. 2.3) равна нулю.
Функция готовности g(t) для последовательной модели надежности
определяется через надежность каждого из входящих в нее компонентов, и
вычисляется как их произведение по следующей формуле [13]:
????
????
????????,где
????
????
????
????
, где i=1,…,12
Руководствуясь данной формулой, получаем значения показателя
готовности для каждого из проектов. Результаты расчетов готовности
каждого элемента информационной системы и их произведение представлены
в таблице 2.2:
26
Таблица 2.2. Расчет функции готовности для последовательной модели надежности
Наименование
Обозначение
Проект 1
Проект 2
ЛВС
g
3
(t)=g
5
(t)=g
7
(t)=g
9
(t)= g
11
(t)
0.9999239
0.9999619
Маршрутизатор
g
2
(t)
0.9998859
0.9998859
Коммутатор
g
6
(t)= g
10
(t)
0.9997717
0.9998859
Web-сервер
g
4
(t)
0.9999619
0.9999715
Сервер баз данных
g
8
(t)
0.9999429
0.9999429
Файловый сервер
g
12
(t)
0.9999429
0.9999429
Итоговое значение
надежности
g(t)
0.99889703
0.99932469
Полученное значение надежности комплекса технических средств
проекта 2 (зеленый маркер) удовлетворяет требованию g(t)>0,999.
Так как значение надежности КТС для проекта №1 (красный маркер) не
удовлетворяет требованию, необходимо повысить надежность комплекса
введением избыточных параллельных элементов для блоков 3, 5, 7, 9, 11, т.е.
резервированием канала ЛВС.[8] Для этого изменим модель надежности
путем введения дополнительных элементов в ненагруженном режиме
(добавленные в модель резервные элементы начинают работать только в
случае отказа основного) (рис. 2.4):
Internet
Маршрутизатор Web-сервер Коммутатор
Сервер баз
данных
ЛВС ЛВСЛВС ЛВС Коммутатор
ЛВС
Файловый
сервер
1
2
3
4
5
6
7
8
9
10
11
12
ЛВС ЛВС ЛВС ЛВС
ЛВС
Рис. 2.4. Последовательно-параллельная модель надежности КТС для проекта 1
27
Основной и резервный блоки полностью идентичны и потому имеют
равные интенсивности отказа и восстановления. В таком случае, выражение
функции готовности можно упростить, и она примет следующий вид[12]:
????
????
????
????
????
????
Рассчитаем gi(t) для параллельных блоков:
g3(t)=g5(t)=g7(t)=g9(t)= g11(t)=0,9999999
Получаем для проекта №1 итоговое значение готовности:
g(t)=0,999277 >0,999.
На основании произведенных выше расчетов можно сделать вывод, что
для обеспечения заданной надежности комплекса технических средств
проекта №1 действительно необходим ввод дополнительных резервных
блоков. Добавив резервные блоки в модель, мы повысили надежность системы
до требуемого уровня.
2.4 Расчет достоверности информации
Необходимо провести расчеты показателей достоверности вносимой в
базу данных информации[4]. Будет рассмотрена выполняемая сотрудником
компании в ручном режиме операция «Внесение информации о контенте в
базу данных».
Предположим, что данная операция выполняется вне вычислительного
центра, например, в браузере, установленном на рабочем компьютере
сотрудника.
Построим модель достоверности для выполняемой операции «Внесение
информации о контенте в базу данных» для данного случая (рис. 2.5):
28
Ввод информации в
форму
Передача данных по
среде передачи
Сохранение
информации в базе
данных
Машинно-ручная операция
P1
Машинная операция
P2
Машинная операция
P3
Рис. 2.5. Модель достоверности для операции «Внесение информации о контенте в базу
данных»
Требование по заданию: p
1
>0,999; p
2
>0,999; p
3
>0,999; P>0,999
Рассчитаем объем вводимых пользователем символов с учетом
установленных проектом размеров максимальной длины полей формы,
информация из которых, после отправки запроса на сервер, будет записана в
таблицы базы данных (табл. 2.3):
Таблица 2.3. Объем вводимых символов
Наименование поля таблицы БД
Тип данных
Длина поля, байт
Код
Числовой
10
Тип контента
Числовой
10
Жанр
Числовой
10
Автор
Текстовый
50
Название
Текстовый
60
Альбом
Текстовый
60
Год
Дата
8
Описание
Текстовый
100
ВСЕГО:308 байт.
Для расчета максимально допустимого объема вводимых символов,
передаваемого в запросе с формы на сайте, к общей длине полей прибавим
накладные расходы TCP/IP протокола, связанные с упаковкой и
транспортировкой пакета по сети. С учетом преамбулы (8 байт), информации
об IP адресе получателя (6 байт), информации об IP адресе отправителя (6
байт) и полем контрольной суммы (4 байта) получаем максимально
возможный объем передаваемых на сервер данных Q = 332 байта.
29
Расчет достоверности согласно построенной модели будет проводится в
три отдельных этапа: для «ручных» операций, для машинных операций и для
операций сохранения информации в базу данных. Затем, чтобы узнать общую
достоверность необходимо применить формулу для расчета общей
достоверности:
, где p
i
– достоверность информации на i-ом этапе.
Для расчета достоверности необходимы дополнительные исходные
данные, которые влияют на итоговый результат, и должны быть учтены в
расчетах. Эти данные представлены в таблице 2.4:
Таблица 2.4. Исходные данные для расчета достоверности информации
Наименование
Проект 1
Проект 2
Вероятность ошибки при ручном вводе
q
1
1*10
-3
Вероятность обнаружения ошибок при
самоконтроле
0,9
Интенсивность отказа сервера БД
0.0002853 (1/час)
0.0002853 (1/час)
Интенсивность сбоев ЛВС
0.0003805 (1/час)
0.003805 (1/час)
Объем вводимых символов
Q
332 байт
332 байт
Пропускная способность ЛВС
100 Мбит/с
1000 Мбит/с
Пропускная способность коммутатора
100 Мбит/с
1000 Мбит/с
Пропускная способность маршрутизатора
1000 Мбит/с
1000 Мбит/с
Среднее время доступа к жесткому диску
8,5 мс
8,5 мс
Операции ручного ввода для обоих вариантов одинаковы, потому
значение, полученное на данном этапе расчетов, применимо к обоим
вариантам проекта.
Рассчитаем достоверность для операций ручного ввода информации в
форму по формуле вероятности искажения информации:
????
????
,
30
где q
1
– вероятность искажения единицы обрабатываемой информации,
Q – объем единиц обрабатываемой информации.
Подставляем в формулу: q = 0,282632 p
1
= 1-q = 0,717368 < 0,999
Полученное значение 0,717368 не удовлетворяет заданному условию,
так как требование, предъявляемое к этому значению: не менее 0,999. Из чего
следует, что необходимо принять меры по повышению достоверности
вводимой информации.
Введем схему контроля ошибок при ручном вводе информации (рис.2.6):
Вход
Преобразование
Контроль
Ошибки есть?
да
нет
Вход
Рис. 2.6. Схема контроля ошибок при ручном вводе
Контроль формата вводимых пользователем с клавиатуры символов при
заполнении формы на сайте можно обеспечить, выполняя посредством
скриптов либо используя возможности языка http, дополнительные проверки,
например, при вводе проверять формат, тип и длину в полях формы, по
возможности, заменить поля формы типа input полями с выбором вариантов
типа select, дополнительно вычислять и отправлять на сервер контрольную
сумму (хеш), которую проверять на сервере перед записью и т.д.
31
В нашем случае, полная вероятность поступления искаженного символа
данных на выход алгоритма вычисляется следующей формулой:
???? ????
, где
k – вероятность обнаружения ошибки при контроле,
r – вероятность внесения ошибки после выполнения корректирующей
операции,
N – количество операций контроля.
При N = 2 получаем:
????
????
????
При N = 3 получаем:
????
????
????
> 0,999
Из расчетов следует, что для достижения необходимого значения
достоверности ввода информации с клавиатуры следует применить
трехкратный контроль.
Далее рассчитаем достоверность информации для машинных операций.
В случае машинной обработки информации применятся следующая формула:
где
- интенсивность сбоев технических устройств,
- время обработки.
Рассчитаем время t передачи пакета длиной 332 байта по узлам сети.
Предположим, что предполагаемое количество операций на обработку запроса