Метрики работы информационной системы

 

Чтобы определить, что такое безошибочная работа ИС, нужны критерии — метрики. Рассмотрим так называемые бизнес-метрики, т. е. те критерии безошибочной работы ИС, которые интересны компании с точки зрения осуществления ее производственной деятельности.

Существуют три основные бизнес-метрики работы ИС [64].

Ожидаемое время восстановления системы MTTR (Mean Time to Restore). Эта метрика задается бизнес-подразделениями компании службам администратора системы. Есть виды биз­неса, которые могут просуществовать без ИС только несколь­ко минут, а затем цена простоя за минуту станет критически высокой.

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

Ожидаемое время между отказами MTBF (Mean Time Be­tween Failures), или наработка на отказ, — это метрика работы оборудования, задаваемая производителем. Так как современ­ное компьютерное оборудование работает достаточно надежно (очень часто производителем дается пожизненная гарантия), то часть производителей не приводит эту метрику в своей тех­нической документации. Администратору системы следует в этом случае брать ее из публикуемых аналитических данных по данному виду оборудования.

Время подъема системы Uptime — это результирующая метрика, которая говорит о том, сколько времени пользова­тель не пользуется ИС из-за проблем диагностики ошибки и восстановления системы, т. е. это совокупность времени для поиска ошибок, их диагностики, времени восстановления и запуска ИС в промышленном режиме. Эта метрика задается бизнес-подразделениями службам администратора системы в SLA. Определяется она исходя из финансовых возможностей предприятия и, соответственно, его оснащенностью средства­ми диагностики и восстановления. Для служб администратора системы эта метрика является отчетной и определяет их воз­можность поддерживать ИС в работоспособном состоянии.

 

Диагностика ошибок Ethernet

 

Практически 99% всех ИС реализованы с использованием технологии Ethernet и протоколов TCP/IP. Поэтому в данном разделе рассмотрим, с какими ошибками может встретиться АС при использовании средств Ethernet [51, 65], а вопросы ди­агностики ошибок в среде протоколов TCP/IP будут изложены далее (в подразделе 8.7).

Коллизии в Ethernet [51] возникают при одновременном до­ступе к среде передачи двух устройств (node — нода), а также из-за задержек сигнала в устройствах, находящихся между ис­точником и приемником. При возникновении коллизии очень рано (на уровне передачи преамбулы) может быть не передан даже разделитель фреймов SFD. Коллизию при передаче пре­амбулы (до SFD) не распознают большинство диагностиче­ских средств, так как микросхемная база Ethernet обычно не передает информацию протоколам второго уровня модели OSI, пока не «увидит» SFD.

При обнаружении коллизии станцией или коммутатором, посылается «пробка» (JAM), которая представляет собой не- стандартизированный 32-битный фрейм. Часто это просто сигнал тактовой частоты 10 МГц. Если он посылается слиш­ком рано, то уничтожается (затирается) часть заголовка фрей­ма, и адрес источника или получателя искажается. Комму­таторы, обнаружив коллизию на одном из портов, разошлют пробку всем остальным портам, чтобы коллизия стала извест­на станциям.

В современных коммутируемых сетях с топологией кабель­ной системы типа «звезда» коллизия обнаруживается нодой сети при одновременном сигнале на пинах пары приема (RC) и пинах пары передачи (TR). Если коммутатор обнаруживает такую коллизию на своем порту, то распознает ее как локаль­ную. Если такая коллизия обнаруживается на порту рабочей станции, то передача фрейма прерывается, и он передается как короткий фрейм до 64 байт с неправильной контрольной суммой (FCS). Он настолько короткий, что заголовок не пере­дается целиком, а пробка занимает четыре последних байта. Коммутатор распознает этот фрейм как удаленную коллизию. Практически все коллизии в современных Ethernet-сетях вос­принимаются как удаленные. Все это необходимо понимать администратору системы при анализе Ethernet-сети.

Коллизии не являются ошибкой, они обязательны в сетях с конкурентным методом доступа. Вопрос только в их коли­честве. По рекомендациям компаний-производителей диа­гностических средств существует специальный вид проверки на ошибки длительностью в одну минуту [51]. Рассмотрим ее подробнее.

Проверка Ethernet «1 минута» предполагает следующий анализ:

- если потери производительности пропускной способно­сти канала составляют менее одного процента, считает­ся, что ошибок нет;

- процент средней утилизации (использования) канала (на сколько процентов в единицу времени загружен ка­нал) должен быть до 40%. При этом необходимо следить, чтобы не было долговременных всплесков утилизации более 60%. В противном случае администратору системы следует принимать меры по сегментации сети;

- средний процент коллизий не должен быть больше 5% от общего числа переданных фреймов. Превышение данно­го значения означает либо проблемы устройств физиче­ского уровня модели OSI, либо превышение количества станций в коллизионном домене;

- широковещательный трафик (Broadcast) не может со­ставлять более 5—10% пропускной способности канала.

При правильной работе ошибок не должно быть обнару­жено.

Теперь рассмотрим основные ошибки, которые могут про­изойти в сетях Ethernet [51, 65]. К ним относятся поздняя кол­лизия, короткий фрейм, неверная контрольная сумма (FCS), «болтовня» (Jabber), «карлики» (Runts), «привидения» (Ghosts), ошибки выравнивания.

Поздняя коллизия (late collision) — это коллизия, которая фиксируется уже после того, как устройство передало в канал связи первые 64 байта фрейма, но обнаружило сигнал одно­временного приема и передачи на соответствующих пинах. При этом регистрируется неправильная контрольная сумма, а в последних четырех байтах содержится пробка. Так как кол­лизия происходит после того, как 64-ый байт был передан, то автоматически фрейм повторно не передается. Вместо этого протокол верхнего уровня (например, TCP или SPX) должен среагировать на то, что данные отсутствуют, и послать запрос на повторную передачу данных.

Как правило, поздняя коллизия вызвана дефектным сете­вым оборудованием.

Короткий фрейм — это фрейм длиной менее 64 байт (по­сле 8-байтной преамбулы) с правильной контрольной суммой (последовательностью FCS). Наиболее вероятная причина по­явления коротких фреймов — неисправная сетевая плата или неправильно сконфигурированный сетевой драйвер.

Неверная контрольная сумма (FCS). Когда фрейм данных пересылается от одного сетевого устройства к другому, пере­дающая станция вычисляет контрольную последовательность фрейма (FCS- или CRC-контрольную сумму) и добавляет ее в конец фрейма. Принимающая станция повторно вычисляет FCS и сравнивает его с FCS, которая была добавлена во фрейм данных передающей стороной. Если два значения совпадают, то считается, что фрейм был передан без ошибок. Если они отличаются друг от друга, это означает, что данные были ис­кажены в процессе передачи. Эта ситуация называется ошиб­кой FCS. Большое число ошибок FCS от одной станции ука­зывает на работающий со сбоями сетевой адаптер (NIC) либо на неправильно сконфигурированные драйверы NIC, либо на плохое кабельное подключение. Если ошибки FCS регистри­руются от многих станций, то это может указывать на непо­ладки в кабельной системе, неправильные версии драйвера NIC, дефектный порт коммутатора или внешние электриче­ские помехи (шумы).

Карлики (Runts). Многие анализаторы протоколов и сете­вых мониторов подсчитывают фреймы-карлики. К сожале­нию, термин Runt не стандартизирован, и его определение имеет разные значения в различных продуктах. Runt может быть любым типом фрейма, который короче, чем разрешен­ный минимум в Ethernet (48 байт), включая локальные уда­ленные коллизии или коллизии на этапе передачи преамбулы с хорошей или плохой FCS.

Привидения (Ghosts) — это фреймы длиной не менее 72 байт с неправильной контрольной последовательностью. Впервые данный термин был введен компанией Fluke в целях опреде­ления фреймов, пораженных шумами, и дифференциации их отличий от удаленных коллизий. Для администратора сети очень важно, что в этом случае результаты диагностики за­висят от сегмента, где происходят измерения.

Ghosts являются «коварными» ошибками, так как они не распознаются программными анализаторами протоколов (как и коллизии на этапе передачи преамбулы). Некоторые типы шума воспринимаются нодами как получение фреймов. На самом деле никакой информации не передается. Различные сетевые интерфейсы будут реагировать на это по-разному. Не существует стандартов реагирования на шумы в сегмен­тах сети. Коммутаторы будут иногда передавать эти сигналы в другие сегменты сети.

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

Обычно причиной появления ghosts являются электротех­нические проблемы.

Болтовня (Jabber) определяется как длинный фрейм (long frame), длиннее 1518 байт. Длинный фрейм может иметь пра­вильную или неправильную контрольную последовательность. Длинные фреймы с неправильной контрольной последова­тельностью обычно называют Jabber. Обнаружение длинных фреймов с правильной контрольной последовательностью ука­зывает чаще всего на некорректность работы сетевого драй­вера. Ошибки типа Jabber свидетельствуют об неисправности активного оборудования или наличии внешних помех.

В соответствии со спецификациями IEEE 802.3 сетевые устройства (например, коммутатор) должны отключить порт при обнаружении большого числа фреймов Jabber. После крат­кого промежутка времени, порт будет повторно включен, если Jabber отсутствует. В действительности не все сетевые устрой­ства осуществляют эту часть спецификации. Некоторые устройства вообще не обнаруживают Jabber, в то время как другие устройства могут обнаружить и отключить проблем­ные порты, но повторно их не активируют. Наличие большого числа фреймов Jabber приведет к повышению занятости кана­ла и резкому замедлению работы сети.

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