Петров Б.М., Уткина О.Н. АНАЛИЗ ОСОБЕННОСТЕЙ ОЦЕНКИ ЖИВУЧЕСТИ СЕРВЕРНЫХ ПРОГРАММНЫХ СРЕДСТВ НАНОПРОЦЕССОРНЫХ СИСТЕМ
При разработке серверных («облачных») систем, использующих новейшие достижения наноэлектроники, необходимо рассмотреть основные особенности программных средств (ПС) серверных нанопроцессор-ных систем (СНПС), которые влияют на оценку живучести СНПС. В статье рассмотрены отличие серверных технологий от клиентских.
Разработка современных серверных («облачных») систем, базирующихся на новых методах обработки информации и использующих новейшие достижения наноэлектроники, потребовала разработки новых моделей расчета живучести программных средств СНПС для основных типов серверов: -print, -mail, -web,
-ftp, -vpn, -DHCP, -DNS, -proxy, сервер БД.
Значительное повышение живучести серверных нанопроцессорных систем может быть получено за счет использования программных средств для мониторинга и управления сетеобразной многоядерной структурой кристалла нанопроцессора, древообразной многокорневой многокэшовой структурой памяти, многоконвейерной структурой с различными уровнями конвейеров, использованием микротехнологий, обеспечивающих плотность упаковки операций в одном такте для большой разрядности, которые позволяют перейти от интеграции схем к интеграции систем и удовлетворить все возрастающие требования заказчиков к быстродействию, точности и количеству решаемых задач при разработке современных аппаратно-программных комплексов управления и обработки информации.
Использование новых сложных методов обработки информации, значительно усложняет современные СНПС, а возрастающая ответственность выполняемых ими функций выдвигает на одно из первых мест проблему расчета живучести СНПС. В статье рассмотрены методы расчета и обеспечения живучести программных средств СНПС.
Проблема живучести программного обеспечения (ПО) возникла при создании больших вычислительных комплексов, когда трудоемкость и стоимость технических средств (логических элементов и приборов памяти) стала непрерывно снижаться, а стоимость и трудоемкость разработки ПО стала повышаться.
В настоящее время в Интернете находятся десятки миллиардов к пакетов (1010), которые имеют емкость десятки миллиардов байт информации (1010), которые обрабатываются на серверах с производительностью сотни миллиардов (1011), производительность серверных систем равна произведению тактовой частоты на разрядность системной шины данных, в итоге мы имеем информационную сложность Интернета 1031, которая должна обеспечиваться новыми моделями расчета и обеспечения живучести.
В настоящее время Интернет используют не только коммерческие структуры, но и космические и авиационные системы у нас и за рубежом, цена ошибки (потери), которую не смогли обнаружить на этапе подготовки и внедрения серверных систем превысила десятки и сотни млн. долл. (не считая морально-политических и других последствий).
Особенностями СНПС, которые обеспечивают высокую защищенность за счет живучести и безопасности, являются:
- конфигурирование массива с избыточностью данных;
- конфигурирование CRON;
- конфигурирование LVM;
- MD5-sum для контроля целостности;
- проверка на spy, и на back door;
- наличие firewall и clam;
- наличие межсетевых экранов и сканеров безопасности;
- наличие политики безопасности сетевого оборудования;
- наличие системы аутентификации и авторизации;
- наличие системы обнаружения атак;
- наличие системы антивирусной защиты;
- ограничения на ввод ID и шифрование каналов.
Особенностями СНПС, которые обеспечивают высокую функциональность за счет быстродействия и доступа в Интернет, являются:
- оптимальная настройка маршрутизации;
- оптимизация пропускной способности сети;
- планирование приоритетов вторичных процессов;
- балансировка нагрузки и многоканальность;
- наличие системы от несанкционированного доступа;
- дефрагментация и физическая чистка HDD;
- автоматизация уведомлений;
- делегирование доступа и чистка баз данных.
Особенностями СНПС, которые обеспечивают высокую работоспособность за счет системы обслуживания и стабильности, являются:
- поиск и удаление временных файлов;
- поиск и удаление .bac файлов;
- поиск и удаление битых ссылок;
- регулярное и своевременное обновление всей системы;
- RAID с избыточностью;
- наличие вторичных серверов и нескольких внешних IP;
- наличие ИБП и сетевых фильтров.
Вероятность достижения требуемого уровня функциональности СНПС сильно зависит от:
- допустимого коэффициента нагрузки (0,1 - 0,8) и от балансировки ее;
- возможности перераспределения обязанностей, коэффициента
делегирования задач (0,3 - 0,9) вторичным серверам;
- коэффициента конфигурации и полноты, глубины и достоверности
проверок (число точек контроля в серверах);
- сложности выполняемых задач, коэффициента ресурсоемкости задач (0,1
- 1,0) при построении очередей задач.
При этом сервер должен выдерживать не менее 98% атак, а система резервного копирования должна каждый день делать инкрементальное резервное копирование и раз в неделю полное резервное копирование, а источник бесперебойного питания должен обеспечивать работу сервера не менее 8 часов, а
СНПС должна уметь обрабатывать не менее 1000 обращений к базе данных. При конфигурировании необходимо обращать особое внимание на самые важные для данной ситуации характеристики и необходимо проводить постоянный мониторинг для своевременного обнаружения и исправления возникающих проблем при обслуживании сервера.
Для получения максимальной вероятности достижения требуемого уровня функциональности СНПС необходимо в первую очередь обеспечивать:
- оптимальное построение очередей задач;
- разработку адаптивной системы резервного копирования под текущие задачи;
- высокий уровень безопасности за счет анализа всех направлений, по которым можно ожидать атаки;
- постоянное поддержание баз данных в компонентном состоянии;
- мониторинг, дефрагментацию и регулярную чистку сервера.
Внедрение микропроцессоров (МП), сверхбольших интегральных схем (СБИС) памяти, цифровых сигнальных процессоров (ЦСП), программи-руемых логических интегральных схем (ПЛИС), микроконтроллеров (МК) и нанопроцессоров (НП) и привело к значительному увеличению сложности ПО. Существует прогноз, что к 2012 году, когда будут внедрены разрабатываемые сейчас системы, вклад ПО составит более 95 % стоимости технических вычислительных средств.
В настоящее время существует несколько моделей оценки живучести ПС микропроцессоров, модели оценки живучести ПС нанопроцессоров с учетом их особенностей, пока в литературе не рассматривались. Все известные модели оценки живучести ПС МП можно разделить на две группы.
В первой группе моделей на этапе разработки ПО определяется показатель сложности ПО. Оцениваются количественные и качественные характеристики: общее время выполнения алгоритма с учетом
сложности арифметических и логических команд и их длительности (длина программы Тго), ее объем, уровень и интеллектуальное содержание программы. Следует отметить, что рассматриваемые модели имеют два серьезных недостатка, которые на порядок и более ухудшают оценку сложности. Во-первых, они не учитывают структуру алгоритма, а во-вторых, объем и время программирования изменяется нелинейно при усложнении алгоритма, поэтому приходится корректировать наработку на ошибку в ПС -
ТПО .
Во второй группе моделей для прогнозирования одной из важнейших характеристик живучести ПО -интенсивности ошибок используют модели, базирующиеся на теории надежности технических систем. Эти модели чаще всего используются на практике, т.к. они позволяют определить следующие показатели живучести ПО: времена появления ошибок; результирующее время между ошибками; количество ошибок за
заданный период времени.
Как в технических средствах, в качестве показателей живучести используются: функция надежности (вероятность безошибочной работы) - , среднее время между появлениями ошибок в ПО - Тср, ин-
тенсивность ошибок ^по(Ъ), которую обозначают через функцию риска Z(t) (количество, скорость, темп
выявления ошибок) условную вероятность того, что ошибка произойдет в интервале времени ( ^ t + А ^ при условии, что программа не отказывала в течение времени ^
Модели второй группы отличаются между собой теми ограничениями и предположениями, которым они соответствуют. Поэтому необходимо очень строго сравнивать предположения, принятые в конкретной модели.
При исследовании живучести ПО предполагаем, что в процессе функционирования в СНПС возникают различные виды отказов (сбои, перемежающиеся отказы, ошибки, внезапные отказы), включающие отказы технических и программных средств (ТС, ПС).
Живучесть СНПС определяется совместной вероятностью Рснпс = Ртс(А) х Рпо(В/А) , где Ртс(А) - безусловная вероятность безотказной работы технических средств; Рпо(В/А) - условная вероятность без-
отказной работы программного обеспечения при условии, что в технических средствах отказ не произошел. Как отмечено в [1], целесообразно принять допущение о независимости отказов в ТС и ПС,
Т.е. РБНПС = Ртс (А) х Рпо (в) .
Изменение системной функции СНПС при возникновении различных видов отказов происходит случайным образом и описывается различными моделями, применение которых позволяет при расчете живучести СНПС вычислять вероятностные характеристики, адекватно отражающие реальные процессы взаимодействия различных видов отказов. При выборе показателей живучести СНПС для проведения расчетов целесообразно использовать два подхода, которые в настоящее время применяются для создания надежных технических и программных средств и приведены в табл. 1.
В первом подходе, который для программных средств называется подходом "безотказности" ( инто-лерантным ) "правильностью" программ, задается показатель ТО (Топо). Этот показатель характеризует уровень создания правильного программного обеспечения. Показатель То зависит от сложности программного обеспечения, от количества функциональных и логических команд, от использованной технологии программирования, от времени отладки ПО.
Таблица 1Выбор номенклатуры показателей безотказности технических и программных средств серверных нанопроцессорных систем вида II (СНПС)
Надежность и живучесть НПС Надежность элементной базы (нанопроцессоры и команды) Интолерантный подход Живучесть структуры Толерантный подход Живучесть архитектуры (структуры и протоколы обмена данных и управления) Толерантный подход
Свойство Показатель Свойство Показатель Свойство Показатель
Технические средства НПС Безотказность То.тс - средняя наработка на отказ в технических средствах Отказо- устойчи- вость Р (^ - вероятность, что не произойдет срыва выполнения задания, из-за отказов в технических средствах Безотказ- ность, отказо- устойчи- вость ТО.ТС - средняя наработка на отказ в технических средствах; Р (^ - вероятность, что не произойдет срыва
выполнения задания, из-за отказов в технических средствах
Программные средства НПС Правильность То.пс - средняя наработка на ошибку в программных средствах Устойчи- вость Р (^ - вероятность, что не произойдет срыва решения задачи, из-за появления ошибки в программных средствах Правиль- ность (коррект- ность), устойчи- вость ТО.ПС - средняя наработка на ошибку в программных средствах; Р (^ - вероятность, что не произойдет срыва решения задачи, из-за появления ошибки в программных средствах
Изделия вида II (СНПС), которые в процессе эксплуатации могут находиться, кроме двух состояниях - работоспособном или неработоспособном, в некотором числе частично неработоспособных состояний, в которые они переходят в результате частичного отказа, что соответствует свойству живучести. Живучесть архитектуры это совместный учет отказов элементной базы, устойчивость структуры и протоколов обмена данных и управления для обеспечения эффективной работы за счет корректного отключения т количества ядер, различных уровней КЭШ - памяти, различных ступеней конвейеров и различных микротехнологий.
Повышение значения показателя Топо может быть за счет уменьшения количества и сложности команд, совершенствования программирования и методов тестирования, за счет внедрения методов автоматического доказательства правильности программ.
Второй подход называется проектированием СНПС "с допуском на сбой" (толерантным), "устойчивостью" программ и задается показателем Р(^ - вероятностью успешного выполнения задания или ТС -
средней наработкой на ошибку, приводящей к срыву выполнения задания. Этот показатель характеризует устойчивость ПО к различного рода ошибкам, искажениям, отказам и зависит от различных видов избыточности (информационной, временной, алгоритмической), введенных в СНПС и согласованных с механизмами типовых ошибок.
По мере увеличения сложности программных средств СНПС второй подход становится более перспективным и более экономичным, чем первый. Универсальность СНПС позволяет осуществлять последовательный переход от проектирования специализированных СНПС частного применения к СНПС универсального применения, которые имеют большую естественную алгоритмическую и архитектурную избыточность. Кроме того, все мероприятия по повышению надежности, применяемые в первом подходе автоматически приводят к повышению показателей надежности второго подхода.
Программное обеспечение в СНПС представляет одну из областей возникновения ошибок и значительно влияет на работоспособность устройства. Для оценки безотказности программного обеспечения построена укрупненная модель, позволяющая учесть основные особенности ПО в СНПС. Для адекватного отражения в модели реальных процессов отказов ПО предварительно проведен анализ видов и механизмов ошибок. На основе анализа приняты следующее определения и допущения, которые позволяют построить инженерную модель расчета безотказности ПО СНПС:
- программа называется правильной, если она выдает правильные результаты при правильных исходных данных и при отсутствии ошибок в командах и константах;
- программа называется устойчивой, если она выдает правильные результаты при наличии ошибок в исходных данных или в командах, т.е. возникающие ошибки в процессе функционирования нейтрализуются;
- отказ ПО определяется как недопустимое отклонение результатов выполнения задания от заданных в ТУ, по точности, по времени;
- безотказность ПО характеризуется вероятностью безотказной (безошибочной) работы ПО в течение заданного времени, в заданных условиях (т.е. с требуемой точностью и быстродействием), для данного СНПС в комплект которого включено ПО;
- для проведения расчетов в качестве основной характеристики безотказности ПО используется интенсивность отказов ^цо ;
- в начале отладки ПО содержит N0 ошибок, которые возникают на этапе разработки из-за неправильного кодирования, ошибок в последовательности передачи управления, несоответствия условий обработки заданным требованиям по точности, быстродействию, области допустимых значений, из-за неправильного описания или неполного учета возникающих ситуаций. N0 не зависит от времени отладки, а зависит от сложности ПО, типа НП и используемой технологии программирования;
- устранение ошибок, в небольших по объему программных модулях СНПС, происходит без внесения новых ошибок, т.е. считаем, что интенсивность ошибок ПО является не возрастающей функцией;
- проведение полного и тщательного анализа типа ошибок и его влияния на ПО не реально из-за множества логических путей, поэтому проверка ПО в СНПС проводится выборочно. Адекватное отражение реальных условий работы можно получить при тестировании наиболее вероятного множества входных данных, которое охватывает наиболее вероятные ветви алгоритма и наиболее сложные и вероятные сочетания условных переходов.
Точное определение вида закона распределения времени безотказной работы ПО СНПС на практике получить очень трудно. Попытки описать время безотказной работы ПО двух- или трехпараметрическим законом распределения успехов не имели, так как точность увеличивалась незначительно, а сложность вычислений из-за сложности определения дополнительных параметров увеличилась в несколько раз.
Обработка множества гистограмм, приведенных в литературе, показывает хорошее совпадение экспериментальных данных с теоретическими кривыми экспоненциального закона. Отклонения, которые наблюдаются в некоторых гистограммах на начальном участке, объясняются растягиванием сроков ввода и начала обработки информации по отказам у различных пользователей. Некоторые разработчики из-за большого потока ошибок на начальном этапе не успевают их анализировать и поэтому снижают интенсивность отработки ПО.
Время функционирования ПО не влияет на остаточное время жизни ПО (так как в ПО не происходят процессы, вызывающие износ и старение, а этим свойством обладает только экспоненциальное распределение), то логично принять этот закон для описания безотказности, при котором мы получаем оценку снизу.
Различают последствия при возникновении ошибок:
а) средние (45%) и незначительные (ЗО%) последствия при ошибках в данных, которые искажают данные, точность вычислений (т.е. ухудшают характеристики СНПС) , эти ошибки обнаруживаются и исправляются при циклической обработке;
б) катастрофические (5%) и серьезные (20%) последствия при ошибках в командах, в последовательности передачи управления, которые приводят к искажению программы и срыву решения задачи.
В таблицах 2, 3, 4, 5 приведена классификация ошибок ПО по типам, этапам возникновения и обнаружения ошибок [1].
Таблица 2
Тип ошибки Вес ошибки, %
Неполная или ошибочная спецификация 25
Отклонение от спецификации 15
Нарушение стандартов программирования 14
Ошибочная выборка данных 10
Логическая ошибка в последовательности операций 9
Ошибка в арифметической операции 8
Ошибки в документации и в исходных данных 8
Ошибка в обработке прерываний 8
Ошибка в константах 3
Таблица 3
Причины ошибок Вес ошибки, %
Ошибки в числовых значениях 20
Недостаточные требования к быстродействию 18
Недостаточные требования к точности 15
Ошибочные символы и знаки 14
Ошибки оформления 12
Ошибочные модели описания аппаратуры 11
Ошибочные и неопределенные исходные данные 10
Таблица 4
Этап, на котором допущена ошибка Вес ошибки, %
Выбор цели 10
Алгоритмизация и спецификация 40
Кодирование 43
Отладка 3
Опытная эксплуатация 2
Тиражирование и поддержание 2
Таблица 5
Этап, на котором обнаружена ошибка Вес ошибки, %
Разработка контрольных примеров и тестов 20
Отладка 24
Натурные испытания и моделирование 22
Стыковка с другими программами при комплексных испытаниях 16
Сдача заказчику и эксплуатация 18
ЛИТЕРАТУРА
1. Петров Б.М., Уткина О.Н. Применение компьютерных технологий для разработки меЬ-портала экспертной системы анализа живучести информационных систем. Сб. трудов межд. научно-практич. конф. «Информационные технологии в образовании, науке и производстве» г. Серпухов 2008 г., с.128-132.