Диагностика сетевого оборудования. Тестирование и диагностика лвс

Сети на базе TCP/IP содержат большое количество удобных утилит и команд, позволяющих наблюдать за статусом сети и диагностировать возникающие проблемы (табл. 7.1).

Утилита pingявляется одним из основных диагностических средств в сетях TCP/IP и входит в поставку всех современных сетевых операционных систем. Функциональность ping также реализована в некоторых встроенных ОС маршрутизаторов, доступ к результатам выполнения ping для таких устройств по протоколу SNMP определяется RFC 2925 (Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations).

Так как программа использует ICMP и создает raw-пакеты, для ее выполнения в unix-системах необходимы права суперпользователя. Чтобы обычные пользователи могли использовать ping, на /bin/ping ставят SUID бит в права доступа (chmod4755 /bin/pingи попросить выполнить эту команду администратора). Пример запуска утилиты ping:

Пример. Запуск ping.

%ping -c 3 fpm2.ami.nstu.ru

PING fpm2.ami.nstu.ru (217.71.130.131): 56 data bytes

64 bytes from 217.71.130.131: icmp_seq=0 ttl=57 time=5.458 ms

64 bytes from 217.71.130.131: icmp_seq=1 ttl=57 time=3.088 ms

64 bytes from 217.71.130.131: icmp_seq=2 ttl=57 time=1.927 ms

Fpm2.ami.nstu.ru ping statistics ---

3 packets transmitted, 3 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 1.927/3.491/5.458/1.469 ms

Таблица 7.1

Утилита tracerouteпредназначена для определения маршрутов следования данных в сетях TCP/IP. Она выполняет отправку данных указанному узлу сети, при этом отображая сведения о всех промежуточных маршрутизаторах, через которые прошли данные на пути к целевому узлу. В случае проблем при доставке данных до какого-либо узла программа позволяет определить, на каком именно участке сети возникли неполадки.

tracerouteвходит в поставку большинства современных сетевых операционных систем. В системах Microsoft Windows эта программа носит названиеtracert , а в системах GNU/Linux –traceroute .

Для определения промежуточных маршрутизаторов tracerouteотправляет серию пакетов целевому узлу, при этом каждый раз увеличивая на 1 значение поля TTL («время жизни»). Это поле обычно указывает максимальное количество маршрутизаторов, которое может быть пройдено пакетом. Первый пакет отправляется с TTL, равным 1, и поэтому первый же маршрутизатор возвращает обратно сообщение ICMP, указывающее на невозможность доставки данных.Tracerouteфиксирует адрес маршрутизатора, а также время между отправкой пакета и получением ответа (эти сведения выводятся на монитор компьютера). Затемtracerouteповторяет отправку пакета, но уже с TTL, равным 2, что позволяет первому маршрутизатору пропустить пакет дальше.

Процесс повторяется до тех пор, пока при определенном значении TTL пакет не достигнет целевого узла. При получении ответа от этого узла процесс трассировки считается завершенным.

На оконечном хосте IP-дейтаграмма с TTL = 1 не отбрасывается и не вызывает ICMP-сообщения типа срок истек , а должна быть отдана приложению. Достижение пункта назначения определяется следующим образом: отсылаемыеtracerouteдейтаграммы содержат UDP-пакет с таким номером UDP-порта адресата (превышающим 30000), что он заведомо не используется на адресуемом хосте. В пункте назначения UDP-модуль, получая подобные дейтаграммы, возвращает ICMP-сообщения об ошибке «порт недоступен». Таким образом, чтобы узнать о завершении работы, программеtracerouteдостаточно обнаружить, что поступило ICMP-сообщение об ошибке этого типа.

Примерв Windows:

C:\Documents and Settings\dnl>tracert fpm2.ami.nstu.ru

Пример.Результат выполнения командыtracert

Трассировка маршрута к fpm2.ami.nstu.ru

с максимальным числом прыжков 30:

1 2 ms 1 ms 1 ms ifgate.interface.nsk.su

2 2 ms 1 ms 2 ms cisco.n-sk.ru

3 1 ms 1 ms 1 ms router.n-sk.ru

4 2 ms 1 ms 1 ms nsk-ix.n-sk.ru

5 2 ms 1 ms 1 ms c7120.nstu.ru

6 2 ms 2 ms 1 ms ix-i.nstu.ru

7 2 ms 3 ms 1 ms ami.nstu.ru

8 2 ms 3 ms 1 ms fpm2.ami.nstu.ru

Трассировка завершена.

Запуск программы производится из командной строки. Для этого вы должны войти в нее (Пуск – Выполнить – В графе «Открыть» пишется «cmd», нажимается ОK). В открывшемся окне пишем:

tracert fpm2.ami.nstu.ru

где tracert – обращение к программе, а fpm2.ami.nstu.ru– символьное имя (DNS-имя) или IPv4 адрес.

Примерв Linux:

В Unix/Linux системах существуют режимы, в которых запуск программы возможен только от имени суперпользователя root(администратора). К числу этих режимов относится важный режим трассировки с помощьюICMP (ключ -I).

Во всех остальных случаях (и в том числе в режиме, который используется по умолчанию) traceroute может работать от имени обычного рядового пользователя (на серверахfpm2 иSaturnключ-Iиспользовать запрещено, поэтому информация, выводимая на экран, будет неполной).

Пример. Результат выполнения командыtraceroute

%traceroute -I saturn.ami.nstu.ru

traceroute to saturn.ami.nstu.ru (217.71.130.153), 64 hops max, 60 byte packets

1 ifgate (195.62.2.1) 1.262 ms 1.258 ms 1.138 ms

2 cisco.n-sk.ru (195.62.0.93) 2.798 ms 1.629 ms 1.903 ms

3 router.n-sk.ru (195.62.1.49) 1.232 ms 1.175 ms 1.170 ms

4 nsk-ix.n-sk.ru (195.62.1.80) 1.567 ms 1.446 ms 1.579 ms

5 c7120.nstu.ru (217.71.128.237) 1.771 ms 1.659 ms 1.582 ms

6 ix-i.nstu.ru (217.71.128.70) 2.040 ms 1.593 ms 1.753 ms

7 ami.nstu.ru (217.71.131.2) 2.996 ms 2.718 ms 1.612 ms

8 saturn.ami.nstu.ru (217.71.130.153) 4.268 ms 3.108 ms 2.051 ms

Замечание. Утилитаtracerouteиспользуется в том числе и в познавательных целях, например, чтобы определить, почему внутри одного города между провайдерами так долго проходят пакеты. Оказалось, пакеты передавались не через внутреннюю точку обмена трафиком, а через город на другом континенте. В отчете по лабораторной работе желательно привести подобный случай для Новосибирска.

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

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

Примериспользования команды netstat (для операционной системыSunOC):

name MTU Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue

le0 1500 solar sun 7442667 27558 736826 33 125361 0

lo0 536 loopback localhost 1283 0 1283 0 0 0 ,

где name – имя сетевого интерфейса;

lo0 – циклический (loopback) интерфейс (или «заглушка»), используемый для проверки сетевых протоколов;

MTU – (Maximum Transmition Unit) размер в байтах максимального пакета данных, поддерживаемого данным интерфейсом. Для Ethernet MTU=1500, для FDDI – 4428, для lo0 – 536;

Net/Dest – назначение сети. Это имя, значение которого можно получить по номеру сети (Network Number), может быть установлено в файле /etc/networks;

Address – имя машины (опция -n позволяет вывести также IP-адрес);

Ipkts/Ierrs – число пришедших пакетов и число ошибок;

Opkts/Oerrs – то же самое для исходящих пакетов;

Collis – число произошедших коллизий. Величина, называемая коэффициентом коллизий (collision rate), вычисляется как (Collis/Opkts)*100. Хорошим считается коэффициент 0…2 %, при 3…5 % можно начинать беспокоиться, если же он больше 5 %, дела совсем плохи;

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

Пример использования утилиты netstat дляLinux:

Bash-3.2$ netstat -i

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0 1500 0 173351491 0 0 0 156580779 0 0 0 BMRU

eth1 1500 0 183024 0 0 0 247635 0 0 0 BMRU

lo 16436 0 547246 0 0 0 547246 0 0 0 LRU

Лекция 13 Диагностика сетей

Лекция 13

Тема: Диагностика сетей

а. Администраторы сети, которые формируют сетевую среду (подавляющее меньшинство).

б. Пользователи сети, кто вынужден эту среду осваивать и в ней жить.

Вторая категория, в силу своего численного превосходства, способна задать столько вопросов, на которые первая, даже будучи столь же многочисленной, не смогла бы ответить. Вопросы бывают простые, например: "Почему не работает электронная почта?" (хотя известно, что вторые сутки за неуплату обесточен весь вычислительный центр). Бывают и сложные: "Как уменьшить задержку отклика, если канал перегружен?"

Число компьютерных сетей увеличивается лавинообразно, растет число больших (>10 ПК) и многопротокольных сетей (802.11, 802.16, 802.17 и т.д.). По мере увеличения сети усложняется ее обслуживание и диагностика, с чем сталкивается администратор при первом же отказе. Наиболее сложно диагностировать многосегментные сети, где ПК разбросаны по большому числу помещений, далеко отстоящих друг от друга. По этой причине сетевой администратор должен начинать изучать особенности своей сети уже на фазе ее формирования и готовить себя и сеть к будущему ремонту.

При возникновении нештатной ситуации администратор должен суметь ответить на ряд вопросов:

Связана проблема с оборудованием или программным обеспечением;

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

Сетевая диагностика - это получение и обработка информации о состоянии сети.

Документирование сети

Начинать надо с исчерпывающего документирования аппаратной и программной части сети. Администратор всегда должен иметь под рукой схему сети, отвечающую реальному положению на текущий момент, и подробное описание конфигурации программного обеспечения с указанием всех параметров (физические и IP-адреса всех интерфейсов, маски, имена ПК, маршрутизаторов, значения MTU, MSS, TTL и других системных переменных, типовые значения RTT и других параметров сети, измеренных в разных режимах.).

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

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

В лекции будет предполагаться, что сеть на физическом уровне использует стандарт Ethernet, а для межсетевой связи протокол TCP/IP (Интернет). Этим перечнем разнообразие сетевых сред не исчерпывается, но многие приемы и программные диагностические средства с успехом могут использоваться и в других случаях. Большинство из рассматриваемых программ работают в среде UNIX, но существуют их аналоги и для других ОС.

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

При переходе на стандарты передачи 1 и тем более 10Гбит/с возникают дополнительные проблемы. Обработка таких потоков с целью диагностики может существенно замедлить работу машины. Аналогичные проблемы возникают при построении IPS/IDS-систем, а также антивирусных программ. Впрочем эта проблема становится тяжелой также из-за фантастического роста числа сигнатур (миллионы) атак и вирусов. Одним из способов решения задачи является привлечение аппаратных средств, а также организация нескольких потоков обработки, что достаточно реально для машин с несколькими процессорами.

Программные средства диагностики

В Интернет имеется немало общедоступных специализированных диагностических программных продуктов: Etherfind, Tcpdump , netwatch, snmpman, netguard, ws_watch.

Такие средства входят также и в комплекты поставки большинства стандартных сетевых пакетов для ОС MS-DOS, UNIX, Windows NT, VMS и других: ping, tracetoute, netstat, arp, snmpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery. Перечисленные выше диагностические программы являются необходимым инструментом для отладки программ, передающих и принимающих пакеты.

Диагностические команды ОС

Таблица 1.

Название команды Назначение

arp Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса)

chnamsv Служит для изменения конфигурации службы имен на ЭВМ (для TCP/IP)

chprtsv Изменяет конфигурацию службы печати на ЭВМ-клиенте или сервере

gettable Получает таблицы ЭВМ в формате NIC

hostent Непосредственно манипулирует записями адресного соот-ветствия ЭВМ в конфигурационной базе данных системы

hostid Устанавливает или отображает идентификатор данной ЭВМ

hostname Устанавливает или отображает имя данной ЭВМ

htable Преобразует файлы ЭВМ в формат, используемый программами сетевой библиотеки

ifconfig Конфигурирует или отображает параметры сетевых интерфейсов ЭВМ (для протоколов TCP/IP)

ipreport Генерирует сообщение о маршруте пакета на основе специфицированного маршрутного файла

iptrace Обеспечивает отслеживание маршрута движения пакетов на интерфейсном уровне для протоколов Интернет

lsnamsv Отображает информацию базы данных DNS

lsprtsv Отображает информацию из базы данных сетевой службы печати

mkhost Создает файл таблицы ПК

mknamsv Конфигурирует службу имен клиент ПК (для TCP/IP)

mktcpip Устанавливает требуемые величины для запуска TCP/IP на ЭВМ

namerslv Непосредственно манипулирует записями сервера имен для локальной программы DNS в базе данных конфигурирования системы

netstat Отображает состояние сети

no Конфигурирует сетевые опции

rmnamsv Удаляет TCP/IP службу имен из ЭВМ

rmprtsv Удаляет службу печати на машине клиента или сервере

route Служит для ручного манипулирования маршрутными таб-лицами

ruptime Отображает состояние каждой ЭВМ в сети

ruser Непосредственно манипулирует записями в трех отдельных системных базах данных, которые регулируют доступом внешних ЭВМ к программам

securetcpip Активизирует сетевую безопасность

setclock Устанавливает время и дату для ЭВМ в сети

slattach Подключает последовательные каналы в качестве сетевых интерфейсов

timedc Присылает информацию о демоне timed

trpt Выполняет отслеживание реализации протокола для TCP-сокетов

Для того чтобы диагностировать ситуацию в сети, необходимо представлять себе взаимодействие различных ее частей в рамках протоколов TCP/IP и иметь некоторое представление о работе Ethernet .

Сети, следующие рекомендациям Интернет, имеют локальный сервер имен (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35; цифры, напечатанные полужирным шрифтом, соответствуют кодам документов, содержащим описания стандартов), служащий для преобразования символьного имени сетевого объекта в его IP-адрес. Обычно эта машина базируется на ОС UNIX.

DNS-сервер обслуживает соответствующую базу данных, которая хранит много другой полезной информации. Многие ПК имеют SNMP-резиденты (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098), обслуживающие управляющую базу данных MIB (RFC-1792, -1748-49, -1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13), содержимое которой поможет также узнать много интересного о состоянии вашей сети. Сама идеология Интернет предполагает богатую диагностику (протокол ICMP, RFC-1256, 1885, -1788, -792).

Использование протокола ICMP

Протокол ICMP используется в наиболее популярной диагностической программе ping (входит в поставку практически всех сетевых пакетов). Возможная форма вызова этой программы имеет вид:

ping <имя или адрес ЭВМ или другого объекта> [размер пакета] [число посылок]

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

Ниже приведен пример использования команды tracetoute, которая во многом эквивалентна ping (но базируется непосредственно на IP, используя соответствующие опции):

traceroute kirk.Bond.edu.au

Программа traceroute посылает по три пакета с нарастающими значениями TTL, если отклик на пакет не получен печатается символ *. Большие задержки (RTT) в приведенном примере определяются спутниковыми каналами связи (время распространения сигнала до спутника!).

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

Применение DNS для целей диагностики

Как уже отмечалось выше, одним из важнейших частей любого узла Интернет является сервер имен (DNS). Конфигурация DNS-сервера определяется тремя файлами: named.boot, named.ca и named.local. Зонная информация содержится в файле named.rev, а данные о локальном домене в файле named.hosts. Отладка, контроль и диагностика DNS-сервера осуществляется с использованием программ nslookup (или dig).

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

Программа ifconfig служит для контроля состояния сетевых интерфейсов, их конфигурирования и проверки. С помощью этой команды интерфейсу присваивается IP-адрес, субсетевая маска и широковещательный адрес.

Применение NETSTAT

Одной из наиболее информативных команд является netstat (за исчерпы-вающим описанием опций и методов применения отсылаю к документации на ваше сетевое программное обеспечение).

Эта команда может вам дать информацию о состоянии интерфейсов на ПК, где она исполнена: netstat -i

В последнее время появилось несколько комплексных (общедоступных) пакетов диагностики (NetWatch, WS_watch, SNMPMAN, Netguard и др.). Некоторые из этих пакетов позволяют построить графическую модель тестируемой сети, выделяя цветом или с помощью вариации картинок работающие ЭВМ. Программы, использующие протокол SNMP, проверяют наличие посредством специального запроса доступность SNMP-демона, с помощью ICMP-протокола определяют работоспособность ЭВМ, после чего отображают переменные и массивы данных из управляющей базы данных MIB (если эта база имеет уровень доступа public). Это может делаться автоматически или по запросу оператора. SNMP-протокол позволяет мониторировать вариации загрузки отдельных сегментов сети пакетами UDP, TCP, ICMP и т.д., регистрируя количество ошибок по каждому из активных интерфейсов. Для решения этой задачи можно использовать соответствующую программу, которая регулярно опрашивает MIB интересующих вас ЭВМ, а полученные числа заносятся в соответствующий банк данных. При возникновении нештатной ситуации администратор сети может просмотреть вариации потоков в сегментах сети и выявить время и причину сбоя в системе. Аналогичные данные можно получить с помощью программы, переводящей интерфейс Ethernet в режим приема всех пакетов (mode=6). Такая программа допускает получение данных по всем типам пакетов, циркулирующих в данном кабельном сегменте.

Определенный интерес может представлять диагностическая программа ttcp, которая позволяет измерять некоторые характеристики TCP- или UDP-обменов между двумя узлами.

При переходе сетей в гигабитный диапазон скоростей, в частности на 10Гбит/с, возникают трудности мониторинга состояния сети.

Если программы периодически работают медленно, компьютеры "зависают" или отключаются от сервера, и программисты при этом говорят, что во всем виновата сеть, а администратор сети, - что во всем виноваты программы, то эта статья адресована именно вам.

Изложенный в этой статье материал не что иное, как обобщение многолетнего практического опыта компании "ПроЛАН" по выявлению "скрытых дефектов" и "узких мест" локальных сетей.

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

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

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

Основных причин неудовлетворительной работы прикладного ПО в сети может быть несколько: повреждения кабельной системы, дефекты активного оборудования, перегруженность сетевых ресурсов (канала связи и сервера), ошибки самого прикладного ПО. Часто одни дефекты сети маскируют другие. Таким образом, чтобы достоверно определить, в чем причина неудовлетворительной работы прикладного ПО, локальную сеть требуется подвергнуть комплексной диагностике. Комплексная диагностика предполагает выполнение следующих работ (этапов).

• Выявление дефектов физического уровня сети: кабельной системы, системы электропитания активного оборудования; наличия шума от внешних источников.
• Измерение текущей загруженности канала связи сети и определение влияния величины загрузки канала связи на время реакции прикладного ПО.
• Измерение числа коллизий в сети и выяснение причин их возникновения.
• Измерение числа ошибок передачи данных на уровне канала связи и выяснение причин их возникновения.
• Выявление дефектов архитектуры сети.
• Измерение текущей загруженности сервера и определение влияния степени его загрузки на время реакции прикладного ПО.
Выявление дефектов прикладного ПО, следствием которых является неэффективное использование пропускной способности сервера и сети.

В рамках данной статьи мы рассмотрим первые четыре этапа комплексной диагностики локальной сети, а именно: диагностику канального уровня сети.

Мы не будем подробно описывать методику тестирования кабельной системы сети. Несмотря на важность этой проблемы, ее решение тривиально и однозначно: полноценно кабельная система может быть протестирована только специальным прибором - кабельным сканером. Другого способа не существует. Нет смысла заниматься трудоемкой процедурой выявления дефектов сети, если их можно локализовать одним нажатием клавиши AUTOTEST на кабельном сканере. При этом прибор выполнит полный комплекс тестов на соответствие кабельной системы сети выбранному стандарту.

Хотелось бы обратить ваше внимание на два момента, тем более что о них часто забывают при тестировании кабельной системы сети с помощью сканера.

Режим AUTOTEST не позволяет проверить уровень шума создаваемого внешним источником в кабеле. Это может быть шум от люминесцентной лампы , силовой электропроводки, сотового телефона, мощного копировального аппарата и др. Для определения уровня шума кабельные сканеры имеют, как правило, специальную функцию. Поскольку кабельная система сети полностью проверяется только на этапе ее инсталляции, а шум в кабеле может возникать непредсказуемо, нет полной гарантии того, что шум проявится именно в период полномасштабной проверки сети на этапе ее инсталляции.

При проверке сети кабельным сканером вместо активного оборудования к кабелю подключаются с одного конца - сканер, с другого - инжектор. После проверки кабеля сканер и инжектор отключаются, и подключается активное оборудование: сетевые платы, концентраторы, коммутаторы. При этом нет полной гарантии того, что контакт между активным оборудованием и кабелем будет столь же хорош, как между оборудованием сканера и кабелем. Мы неоднократно встречались со случаями, когда незначительный дефект вилки RJ-45 не проявлялся при тестировании кабельной системы сканером, но обнаруживался при диагностике сети анализатором протоколов.

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

Организация процесса диагностики сети

Любая методика тестирования сети существенно зависит от имеющихся в распоряжении системного администратора средств. По нашему мнению, в большинстве случаев необходимым и достаточным cредством для обнаружения дефектов сети (кроме кабельного сканера) является анализатор сетевых протоколов. Он должен подключаться к тому домену сети (collision domain), где наблюдаются сбои, в максимальной близости к наиболее подозрительным станциям или серверу (см. Правило #3.3).

Если сеть имеет архитектуру с компактной магистралью (collapsed backbone) и в качестве магистрали используется коммутатор, то анализатор необходимо подключать к тем портам коммутатора, через которые проходит анализируемый трафик. Некоторые программы имеют специальные агенты или зонды (probes), устанавливаемые на компьютерах, подключенных к удаленным портам коммутатора. Обычно агенты (не путать с агентами SNMP) представляют собой сервис или задачу, работающую в фоновом режиме на компьютере пользователя. Как правило, агенты потребляют мало вычислительных ресурсов и не мешают работе пользователей, на компьютерах которых они установлены. Анализаторы и агенты могут быть подключены к коммутатору двумя способами.

При первом способе (см. Рисунок 1а) анализатор подключается к специальному порту (порту мониторинга или зеркальному порту) коммутатора, если таковой имеется, и на него по очереди направляется трафик со всех интересующих портов коммутатора.

Рисунок 1а. Зеркальный трафик со всех портов коммутатора по очереди направляется на порт коммутатора, к которому подключен анализатор протоколов.

Если в коммутаторе специальный порт отсутствует, то анализатор (или агент) следует подключать к портам интересующих доменов сети в максимальной близости к наиболее подозрительным станциям или серверу (см. Рисунок 1б). Иногда это может потребовать использования дополнительного концентратора. Согласно Правилу #3.3, данный способ предпочтительнее первого. Исключение составляет случай, когда один из портов коммутатора работает в полнодуплексном режиме. Если это так, то порт предварительно необходимо перевести в полудуплексный режим.

Рисунок 1б. Анализатор протоколов и удаленные агенты контролируют основные домены сети. Для диагностики домена сервера используется дополнительный концентратор.

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

Во-первых, анализатор протоколов должен иметь встроенную функцию генерации трафика (см. Правило #3.4). Во-вторых, анализатор протоколов должен уметь "прореживать" принимаемые кадры, т. е. принимать не все кадры подряд, а, например, каждый пятый или каждый десятый с обязательной последующей аппроксимацией полученных результатов. Если эта функция отсутствует, то при сильной загруженности сети, какой бы производительностью ни обладал компьютер, на котором установлен анализатор, последний будет "зависать" и/или терять кадры. Это особенно важно при диагностике быстрых сетей типа Fast Ethernet и FDDI.

Предлагаемую методику мы будем иллюстрировать на примере использования чисто программного анализатора протоколов Observer компании Network Instruments, работающего в среде Windows 95 и Windows NT. С нашей точки зрения, этот продукт обладает всеми необходимыми функциями для эффективного проведения диагностики сетей.

Итак, предположим, что прикладное программное обеспечение в вашей сети Ethernet стало работать медленно, и вам необходимо оперативно локализовать и ликвидировать дефект.

Первый этап

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

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

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

Предположим, что анализатор протоколов установлен в том домене сети (collision domain), где прикладное ПО работает медленно. Средняя утилизация канала связи составляет 19%, пиковая доходит до 82%. Можно ли на основании этих данных сделать достоверный вывод о том, что причиной медленной работы программ в сети является перегруженность канала связи? Вряд ли.

Часто можно слышать о стандарте де-факто, в соответствии с которым для удовлетворительной работы сети Ethernet утилизация канала связи "в тренде" (усредненное значение за 15 минут) не должна превышать 20%, а "в пике" (усредненное значение за 1 минуту) - 35-40%. Приведенные значения объясняются тем, что в сети Ethernet при утилизации канала связи, превышающей 40%, существенно возрастает число коллизий и, соответственно, время реакции прикладного ПО. Несмотря на то что такие рассуждения в общем случае верны, безусловное следование подобным рекомендациям может привести к неправильному выводу о причинах медленной работы программ в сети. Они не учитывают особенности конкретной сети, а именно: тип прикладного ПО, протяженность домена сети, число одновременно работающих станций.

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

Правило # 1.1.

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

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

Если рабочая станция и сервер обладают высокой производительностью, и между ними идет обмен большими порциями данных, то утилизация в канале связи может достигать 80-90% (особенно в пакетном режиме - burst mode). Это абсолютно не замедляет работу сети, а, наоборот, свидетельствует об эффективном использовании ее ресурсов прикладным ПО.

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

Правило # 1.2.

Высокая утилизация канала связи сети только в том случае замедляет работу конкретного прикладного ПО, когда именно канал связи является "узким местом" для работы данного конкретного ПО.

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

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

Проще всего это сделать, воспользовавшись функцией генерации трафика, имеющейся в ряде анализаторов протоколов (например, в Observer). С помощью этой функции интенсивность генерируемой нагрузки следует наращивать постепенно, и на ее фоне производить измерения времени выполнения операции. Фоновую нагрузку целесообразно увеличивать от 0 до 50-60% с шагом не более 10%.

Если время выполнения операции в широком интервале фоновых нагрузок не будет существенно изменяться, то узким местом системы является не канал связи. Если же время выполнения операции будет существенно меняться в зависимости от величины фоновой нагрузки (например, при 10% и 20% утилизации канала связи время выполнения операции будет значительно различаться), то именно канал связи, скорее всего, ответственнен за низкую производительность системы, и величина его загруженности критична для времени реакции прикладного ПО. Зная желаемое время реакции ПО, вы легко сможете определить, какой утилизации канала связи соответствует желаемое время реакции прикладного ПО.

В данном эксперименте фоновую нагрузку не следует задавать более 60-70%. Даже если канал связи не является узким местом, при таких нагрузках время выполнения операций может возрасти вследствие уменьшения эффективной пропускной способности сети.

Правило # 1.3.

Максимально допустимая утилизация канала связи зависит от протяженности сети.

При увеличении протяженности домена сети допустимая утилизация уменьшается. Чем больше протяженность домена сети, тем позже будут обнаруживаться коллизии. Если протяженность домена сети мала, то коллизии будут выявлены станциями еще в начале кадра, в момент передачи преамбулы. Если протяженность сети велика, то коллизии будут обнаружены позже - в момент передачи самого кадра. В результате накладные расходы на передачу пакета (IP или IPX) возрастают. Чем позже выявлена коллизия, тем больше величина накладных расходов и большее время тратится на передачу пакета. В результате время реакции прикладного ПО, хотя и незначительно, но увеличивается.

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

Второй этап

Измерение числа коллизий в сети.

Если две станции домена сети одновременно ведут передачу данных, то в домене возникает коллизия. Коллизии бывают трех типов: местные, удаленные, поздние.

Местная коллизия (local collision) - это коллизия, фиксируемая в домене, где подключено измерительное устройство, в пределах передачи преамбулы или первых 64 байт кадра, когда источник передачи находится в домене. Алгоритмы обнаружения местной коллизии для сети на основе витой пары (10BaseT) и коаксиального кабеля (10Base2) отличны друг от друга.

В сети 10Base2 передающая кадр станция определяет, что произошла локальная коллизия по изменению уровня напряжения в канале связи (по его удвоению). Обнаружив коллизию, передающая станция посылает в канал связи серию сигналов о заторе (jam), чтобы все остальные станции домена узнали, что произошла коллизия. Результатом этой серии сигналов оказывается появление в сети коротких, неправильно оформленных кадров длиной менее 64 байт с неверной контрольной последовательностью CRC. Такие кадры называются фрагментами (collision fragment или runt).

В сети 10BaseT станция определяет, что произошла локальная коллизия, если во время передачи кадра она обнаруживает активность на приемной паре (Rx).

Удаленная коллизия (remote collision) - это коллизия, которая возникает в другом физическом сегменте сети (т. е. за повторителем). Станция узнает, что произошла удаленная коллизия, если она получает неправильно оформленный короткий кадр с неверной контрольной последовательностью CRC, и при этом уровень напряжения в канале связи остается в установленных пределах (для сетей 10Base2). Для сетей 10BaseT/100BaseT показателем является отсутствие одновременной активности на приемной и передающей парах (Tx и Rx).

Поздняя коллизия (late collision) - это местная коллизия, которая фиксируется уже после того, как станция передала в канал связи первые 64 байт кадра. В сетях 10BaseT поздние коллизии часто фиксируются измерительными устройствами как ошибки CRC.

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

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

Даже если канал связи не является узким местом системы, коллизии несущественно, но замедляют работу прикладного ПО. Причем основное замедление вызывается не столько самим фактом необходимости повторной передачи кадра, сколько тем, что каждый компьютер сети после возникновения коллизии должен выполнять алгоритм отката (backoff algorithm): до следующей попытки выхода в канал связи ему придется ждать случайный промежуток времени, пропорциональный числу предыдущих неудачных попыток.

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

Правило # 2.1.

Не все измерительные приборы правильно определяют общее число коллизий в сети.

Практически все чисто программные анализаторы протоколов фиксируют наличие коллизии только в том случае, если они обнаруживают в сети фрагмент, т. е. результат коллизии. При этом наиболее распространенный тип коллизий - происходящие в момент передачи преамбулы кадра (т. е. до начального ограничителя кадра (SFD)) - программные измерительные средства не обнаруживают, так уж устроен набор микросхем сетевых плат Ethernet. Наиболее точно коллизии обнаруживают аппаратные измерительные приборы, например LANMeter компании Fluke.

Правило # 2.2.

Высокая утилизация канала связи не всегда сопровождается высоким уровнем коллизий.

Уровень коллизий будет низким, если в сети одновременно работает не более двух станций (см. Правило # 1.1) или если небольшое число станций одновременно ведут обмен длинными кадрами (что особенно характерно для пакетного режима). В этом случае до начала передачи кадра станции "видят" несущую в канале связи, и коллизии редки.

Правило # 2.3.

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

Если кабельная система предварительно была протестирована сканером, то наиболее вероятной причиной повышенного уровня коллизий является шум в линии связи, вызванный внешним источником, или дефектная сетевая плата, неправильно реализующая алгоритм доступа к среде передачи (CSMA/CD).

Компания Network Instruments в анализаторе протоколов Observer оригинально решила задачу выявления коллизий, вызванных дефектами сети. Встроенный в программу тест провоцирует возникновение коллизий: он посылает в канал связи серию пакетов с интенсивностью 100 пакетов в секунду и анализирует число возникших коллизий. При этом совмещенный график отображает зависимость числа коллизий в сети от утилизации канала связи.

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

В анализаторе протоколов Observer график, показанный на Рисунке 3, меняет цвет в зависимости от числа коллизий и наблюдаемой при этом утилизации канала связи.

Правило # 2.4.

При диагностике сети 10BaseT все коллизии должны фиксироваться как удаленные, если анализатор протоколов не создает трафика.

Если вы пассивно (без генерации трафика) наблюдаете за сетью 10BaseT и физический сегмент в месте подключения анализатора (измерительного прибора) исправен, то все коллизии должны фиксироваться как удаленные.

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

Правило # 2.5.

Коллизии в сети могут быть следствием перегруженности входных буферов коммутатора.

Следует помнить, что коммутаторы при перегруженности входных буферов эмулируют коллизии, дабы "притормозить" рабочие станции сети. Этот механизм называется "управление потоком" (flow control).

Правило # 2.6.

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

Если компьютеры, включенные в сеть не имеют общей точки заземления (зануления), то между корпусами компьютеров может возникать разность потенциалов. В персональных компьютерах "защитная" земля объединена с "информационной" землей. Поскольку компьютеры объединены каналом связи локальной сети, разность потенциалов между ними приводит к возникновению тока по каналу связи. Этот ток вызывает искажение информации и является причиной коллизий и ошибок в сети. Такой эффект получил название ground loop или inter ground noise.

Аналогичный эффект возникает в случае, когда сегмент коаксиального кабеля заземлен более чем в одной точке. Это часто случается, если Т-соединитель сетевой платы соприкасается с корпусом компьютера.

Обращаем ваше внимание на то, что установка источника бесперебойного питания не снимает описанных трудностей. Наиболее подробно данные проблемы и способы их решения рассматриваются в материалах компании APC (American Power Conversion) в "Руководстве по защите электропитания" (Power Protection Handbook).

При обнаружении большого числа коллизий и ошибок в сетях 10Base2 первое, что надо сделать, - проверить разность потенциалов между оплеткой коаксиального кабеля и корпусами компьютеров. Если ее величина для любого компьютера в сети составляет более одного вольта по переменному току, то в сети не все в порядке с топологией линий заземления компьютеров.

Третий этап

Измерение числа ошибок на канальном уровне сети.

В сетях Ethernet наиболее распространенными являются следующие типы ошибок.

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

Последнее время мы наблюдаем большое число ошибок этого типа на относительно медленных компьютерах (486/SX), работающих под Windows 95 с сетевыми платами NE2000. Причина нам неизвестна.

Длинный кадр (long frame) - кадр длиннее 1518 байт. Длинный кадр может иметь правильную или неправильную контрольную последовательность. В последнем случае такие кадры обычно называют jabber. Фиксация длинных кадров с правильной контрольной последовательностью указывает чаще всего на некорректность работы сетевого драйвера; фиксация ошибок типа jabber - на неисправность активного оборудования или наличие внешних помех.

Ошибки контрольной последовательности (CRC error) - правильно оформленный кадр допустимой длины (от 64 до 1518 байт), но с неверной контрольной последовательностью (ошибка в поле CRC).

Ошибка выравнивания (alignment error) - кадр, содержащий число бит, не кратное числу байт.

Блики (ghosts) - последовательность сигналов, отличных по формату от кадров Ethernet, не содержащая разделителя (SFD) и длиной более 72 байт. Впервые данный термин был введен компанией Fluke с целью дифференциации различий между удаленными коллизиями и шумами в канале связи.

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

Рискуя навлечь на себя праведный гнев дистрибьюторов программ сетевого управления на основе SNMP, мы осмелимся тем не менее утверждать, что степень влияния ошибок канального уровня сети на время реакции прикладного ПО сильно преувеличена.

В соответствии с общепринятым стандартом де-факто число ошибок канального уровня не должно превышать 1% от общего числа переданных по сети кадров. Как показывает опыт, эта величина перекрывается только при наличии явных дефектов кабельной системы сети. При этом многие серьезные дефекты активного оборудования, вызывающие многочисленные сбои в работе сети, не проявляются на канальном уровне сети (см. Правило # 3.8).

Правило # 3.1.

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

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

Не все сетевые платы и сетевые драйверы предоставляют анализатору протоколов идентичную и полную информацию об ошибках в сети. Сетевые платы 3Com вообще никакой информации об ошибках не выдают. Если вы установите анализатор протоколов на такую плату, то значения на всех счетчиках ошибок будут нулевыми.

EtherExpress Pro компании Intel сообщают только об ошибках CRC и выравнивания. Сетевые платы компании SMC предоставляют информацию только о коротких кадрах. NE2000 выдают почти полную информацию, выявляя ошибки CRC, короткие кадры, ошибки выравнивания, коллизии.

Сетевые карты D-Link (например, DFE-500TX) и Kingstone (например, KNE 100TX) сообщают полную, а при наличии специального драйвера - даже расширенную, информацию об ошибках и коллизиях в сети.

Ряд разработчиков анализаторов протоколов предлагают свои драйверы для наиболее популярных сетевых плат.

Правило # 3.2.

Обращайте внимание на "привязку" ошибок к конкретным MAC-адресам станций.

При анализе локальной сети вы, наверное, обращали внимание, что ошибки обычно "привязаны" к определенным МАС-адресам станций. Однако коллизии, произошедшие в адресной части кадра, блики, нераспознанные ситуации типа короткого кадра с нулевой длиной данных не могут быть "привязаны" к конкретным МАС-адресам.

Если в сети наблюдается много ошибок, которые не связаны с конкретными МАС-адресами, то их источником скорее всего является не активное оборудование. Вероятнее всего, такие ошибки - результат коллизий, дефектов кабельной системы сети или сильных внешних шумов. Они могут быть также вызваны низким качеством или перебоями питающего активное оборудование напряжения.

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

Правило # 3.3.

В пределах одного домена сети (collision domain) тип и число ошибок, фиксируемых анализатором протоколов, зависят от места подключения измерительного прибора.

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

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

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

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

Подтверждение приведенного правила можно найти на серверах Web компаний Fluke (www.fluke.com) и Net3 Group (www.net3group.com).

Правило # 3.4.

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

Генерация трафика позволяет обострить имеющиеся проблемы и создает условия для их проявления. Трафик должен иметь невысокую интенсивность (не более 100 кадров/с) и способствовать образованию коллизий в сети, т. е. содержать короткие (<100 байт) кадры.

При выборе анализатора протоколов или другого диагностического средства внимание следует обратить прежде всего на то, чтобы выбранный инструмент имел встроенную функцию генерации трафика задаваемой интенсивности. Эта функция имеется, в частности, в анализаторах Observer компании Network Instruments и NetXray компании Cinco (ныне Network Associates).

Правило # 3.5.

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

Правило # 3.6.

Если доля ошибок CRC в общем числе ошибок велика, то следует определить длину кадров, содержащих данный тип ошибок.

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

При большой доле ошибок CRC в общем числе ошибок целесообразно выяснить причину их появления. Для этого ошибочные кадры из серии надо сравнить с аналогичными хорошими кадрами из той же серии. Если ошибочные кадры будут существенно короче хороших, то это, скорее всего, результаты коллизий. Если ошибочные кадры будут практически такой же длины, то причиной искажения, вероятнее всего, является внешняя помеха. Если же испорченные кадры длиннее хороших, то причина кроется, вероятнее всего, в дефектном порту концентратора или коммутатора, которые добавляют в конец кадра "пустые" байты.

Сравнить длину ошибочных и правильных кадров проще всего посредством сбора в буфер анализатора серии кадров с ошибкой CRC.

Правило # 3.7.

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

Наиболее надежным способом локализации дефектов является поочередное отключение подозрительных станций, концентраторов и кабельных трасс, тщательная проверка топологии линий заземления компьютеров (особенно для сетей 10Base2).

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

Правило # 3.8.

Отсутствие ошибок на канальном уровне еще не гарантирует того, что информация в вашей сети не искажается.

В начале данного раздела уже упоминалось, что влияние ошибок канального уровня на работу сети сильно преувеличено. Следствием ошибок нижнего уровня является повторная передача кадров. Благодаря высокой скорости сети Ethernet (особенно Fast Ethernet) и высокой производительности современных компьютеров, ошибки нижнего уровня не оказывает существенного влияния на время реакции прикладного ПО.

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

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

Причина таких дефектов в следующем. Информация искажается (или исчезает) "в недрах" активного оборудования - сетевой платы, маршрутизатора или коммутатора. При этом приемо-передающий блок этого оборудования вычисляет правильную контрольную последовательность (CRC) уже искаженной ранее информации, и корректно оформленный кадр передается по сети. Никаких ошибок в этом случае, естественно, не фиксируется. SNMP-агенты, встроенные в активное оборудование, здесь ничем помочь не могут.

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

Опытный администратор сети может возразить, что кроме защиты информации на канальном уровне в протоколах IPX и TCP/IP возможна защита информации с помощью контрольной суммы.

В полной мере на защиту с помощью контрольной суммы можно полагаться, только если прикладное ПО в качестве транспортного протокола задействует TCP или UDP. Только при их использовании контрольной суммой защищается весь пакет. Если в качестве "транспорта" применяется IPX/SPX или непосредственно IP, то контрольной суммой защищается лишь заголовок пакета.

Даже при наличии защиты с помощью контрольной суммы описанное искажение или исчезновение информации вызывает существенное увеличение времени реакции прикладного ПО.

Если же защита не установлена, то поведение прикладного ПО может быть непредсказуемым.

Помимо замены (отключения) подозрительного оборудования выявить такие дефекты можно двумя способами.

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

Вторым способом является метод стрессового тестирования сети.

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

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

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

Какие параметры необходимо отслеживать при диагностике сети? Методика упреждающей диагностики сети

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

Наблюдаемыми параметрами обычно являются:

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

Зная зависимость между временем реакции прикладного ПО и значениями наблюдаемых параметров, администратор сети должен определить максимальные значения параметров, допустимые для данной сети. Эти значения вводятся в виде порогов (thresholds) в диагностическое средство. Если в процессе эксплуатации сети значения наблюдаемых параметров превысят пороговые, то диагностическое средство проинформирует об этом событии администратора сети. Такая ситуация свидетельствует о наличии в сети проблемы.

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

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

NDF (Network Diagnostics Framework) позволяет пользователям диагностировать и устранять неполадки, предоставляя диагностические оценки и информацию о последовательности операций, которая позволит устранить проблему. NDF упрощает и автоматизирует многие из стандартных операций по устранению неполадок и реализации решений для устранения проблем сети.

Теперь Microsoft поставляет NDF в составе Windows 7 наряду с другими новшествами, такими как доступ к утилите устранения неполадок из области уведомлений, апплет «Устранение неполадок компьютера» (Troubleshooting) в панели управления и трассировка сети средствами Event Tracing for Windows (ETW). Все они облегчают просмотр и сбор информации, необходимой для исследования неполадок сети, требующих исправления — автоматически или за счет вмешательства пользователя.

Устранение неполадок с использованием значка сети в области уведомлений

Утилиту устранения неполадок легко запустить, щелкнув правой кнопкой значок сети в области уведомлений рабочего стола Windows 7 и выбрав команду «Диагностика неполадок» (Troubleshoot problems). Откроется окно утилиты «Диагностика сетей Windows» (Windows Network Diagnostics) и запустится диагностика сети.

Поиск неполадок из Панели управления

В Windows 7 не нужно ждать, пока произойдет сбой сети, чтобы выполнить встроенную диагностику. Открыть сеанс поиска неполадок можно в любой момент, открыв служебную программу «Устранение неполадок компьютера» (Troubleshooting) на Панели управления, рис. 1. В данном случае служебная программа обнаружила, что у компьютера нет подключения к Интернету. Об этом говорит сообщение в верхней части страницы, при этом предлагается попытаться подключиться повторно.

Рис. 1 Открытие апплета устранения неполадок компьютера в панели управления.

Если щелкнуть «Сеть и Интернет» (Network and Internet), откроется диалоговое окно, показанное на рис. 2. Там можно выбрать один из семи вариантов исследования сетевых подключений, в том числе устранить неполадки подключения к Интернету, доступа к файлам и папкам на других компьютерах и печати.

Рис. 2 Поиск неполадок сети и подключения к Интернету.

При выборе любого из этих семи вариантов открывается мастер, помогающий выполнить диагностику неполадки и, если возможно, устранить ее автоматически или вручную. Средство диагностики также ведет запись в журнал трассировки событий (Event Tracing Log, ETL). Если неполадку не удается устранить, можно исследовать журнал самостоятельно или переслать его более сведущим людям. Для этого щелкните в диалогом окне поиска неполадок «Просмотр журнала» (View History). На рис.3 показан пример журнала ETL.

Рис. 3 Пример журнала ETL.

Каждая запись в журнале представляет отдельный сеанс поиска неполадок. Двойной щелчок сеанса открывает его журнал (рис. рис.4.

Рис. 4 Пример журнала устранения неполадок.

Чтобы просмотреть детали процедуры поиска неполадок обнаружения, щелкните ссылку «Обнаружение проблемы» (Detection details) - откроется окно, похожее на показанное на рис. 5.

Рис. 5 Типичное окно с подробностями поиска неполадок.

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

Просматривать и анализировать ETL-файлы можно средствами Сетевого монитора версии 3.3. Также для этой цели можно задействовать средство «Просмотр событий» и Tracerpt.exe. Можно преобразовать файл в XML или текстовый формат командой netsh trace convert. Подробные результаты сеанса поиска неполадок можно получить в виде CAB-файла, для чего нужно щелкнуть правой кнопкой сеанс в окне «Журнал устранения неполадок» (Troubleshooting History) и выбрать Сохранить как (Save As). Как и ETL-файлы, CAB-файл можно отправить в отдел поддержки для анализа.

Трассировка сети средствами Netsh.exe

Windows 7 включает новый контекст утилиты Netsh.exe - netsh trace, служащий для трассировки сети. Команды в этом контексте позволяют выборочно включать трассировку провайдеров или сценариев. Провайдер - это отдельный компонент в стеке сетевых протокол, такой как Winsock, TCP/IP, службы беспроводной локальной сети или NDIS. Сценарий трассировки - это набор провайдеров, реализующих одну функциональность, например совместный доступ к файлам или беспроводную локальную сеть. Чтобы избавиться от несущественных подробностей и уменьшить размер ETL-файла, можно применять фильтры.

Как правило, для выполнения детального анализа неполадок сети нужно предоставлять сотрудникам отдела поддержки или службе поддержки клиентов Microsoft как информацию о трассировки компонента, так и запись сетевого трафика во время проявления неполадки. До Windows 7 для получения этих данных приходилось выполнять две различных процедуры: использовать команды Netsh.exe для включения и отключения трассировке и задействовать сетевой анализатор, такой как Сетевой монитор, для записи сетевого трафика. После этого предстояло решить нелегкую задачу синхронизации информации из этих двух источников, чтобы определить, как сетевой трафик соотносится с событиями в журналах трассировки.

В Windows 7 при выполнении трассировки сети в контексте netsh trace ETL-файлы могут последовательно содержать информацию и сетевого трафика, и трассировки компонента. Полученные ETL-файлы можно изучать средствами Сетевого монитора версии 3.3, который предоставляет намного более эффективный интерфейс анализа и исследования сетевых неполадок (рис. На рис. 6 показан пример файла ETL, который просматривается в Network Monitor 3.3.

Рис. 6 Использование сетевого монитора версии 3.3 для просмотра сетевого трафика, сохраненного в ETL-файле.

Эта новая возможность позволяет не требовать от конечных пользователей или сотрудников отдела поддержки для записи сетевого трафика устанавливать и использовать Сетевой монитор на компьютере, где наблюдаются неполадки. Имейте в виду, что по умолчанию ETL-файлы, созданные в сеансах диагностики неполадок апплета «Устранение неполадок компьютера» (Troubleshooting) не содержат данных сетевого трафика.

Для последовательной регистрации данных трассировки и сетевого трафика многих компонентов сетевого стека (таких как Winsock, DNS, TCP, NDIS, WFP и т. п.) в Windows используется корреляция на основе идентификатора транзакции, которая называется группировкой и используется для сбора и записи трассировки и трафика в ETL-файле. Группировка в ETL-файлах позволяет исследовать всю транзакцию как единую последовательность взаимосвязанных событий.

Подробнее о командах Netsh.exe для трассировки см. врезку «Запуск и остановка трассировки в Netsh.exe».

При использовании Netsh.exe в Windows 7 могут создаваться два файла. ETL-файл содержит события трассировки компонентов Windows и, если требуется, сетевого трафика. По умолчанию ETL-файл называется Nettrace.etl и размещается в папке %TEMP%\\NetTraces. Можно задать другое имя и место, задав параметр tracefile=. Необязательный CAB-файл может содержать файлы нескольких типов, в том числе текстовые файлы, файлы реестра Windows, XML и другие - они содержат дополнительную информацию для поиска неполадок. CAB-файл также включает копию ETL-файла. По умолчанию CAB-файл называется Nettrace.cab и размещается в папке %TEMP%\NetTraces.

Трассировку средствами Netsh.exe можно совмещать с диагностированием с помощью апплета «Устранение неполадок компьютера» панели управления. Сначала выполните соответствующую команду Netsh.exe, чтобы запустить трассировку сценария, например: netsh trace scenario=internetclient report=yes. В апплете «Устранение неполадок компьютера» запустите сеанс устранения неполадок подключения к Интернету. По завершении сеанса выполните команду netsh trace stop. Теперь при просмотре журнала сеанса устранения неполадок будет доступен CAB-файл.
Боковая панель: Запуск и остановка трассировки в Netsh.exe

Чтобы запустить трассировку сети в Netsh.exe, прежде всего надо открыть окно командной строки с дополнительными правами. Чтобы получить список провайдеров трассировки, выполните команду netsh trace show providers. Получить список сценариев, можно командой netsh trace show scenarios. Чтобы получить список провайдеров в сценарии, выполните netsh trace show scenario ScenarioName.

Можно запустить трассировку одного или нескольких провайдеров или сценариев. Например, трассировка сценария InternetClient запускается командой netsh trace start scenario=internetclient. Чтобы запустить трассировку нескольких сценариев, надо последовательно их задать:netsh trace start scenario=FileSharing scenario=DirectAccess.

Чтобы создать CAB-файл с форматированным отчетом, добавьте параметр report=yes. Для задания имени и местоположения ETL- и CAB-файлов служит параметр tracefile=parameter. Если в ETL файле нужно записать еще и сетевой трафик, добавьте параметр capture=yes.

Вот пример команды, которая запустит трассировку сценария WLAN, создаст CAB-файл с форматированным отчетом, запишет сетевой трафик и сохранит файлы под именем WLANTest в папке C:\\Tshoot: netsh trace start scenario=WLAN capture=yes report=yes tracefile=c:\tshoot\WLANtest.etl.

Чтобы остановить трассировку, используйте команду netsh trace stop command.

Боковая панель: Использование сетевого монитора версии 3.3 для просмотра ETL-файлов

Чтобы Сетевой монитор версии 3.3 смог полностью отображать ETL-файлы, сгенерированные в Windows 7, нужно сконфигурировать полные анализаторы Windows. По умолчанию Сетевой монитор версии 3.3 использует стандартные анализаторы Windows. Чтобы конфигурировать полные анализаторы Windows, выберите Tools/Options/Parsers. В списке анализаторов выберите Windows/Stubs, чтобы отключить стандартные анализаторы и включить полные анализаторы, далее щелкните OK.

Джозеф Дейвис (Joseph Davies) - ведущий технический писатель в группе команды технических писателей по теме сетей Windows в Microsoft. Он является автором и соавтором нескольких книг, опубликованных в издательстве Microsoft Press, в числе которых «Windows Server 2008 Networking and Network Access Protection (NAP)», «Understanding IPv6, Second Edition» и «Windows Server 2008 TCP/IP Protocols and Services».

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

Диагностикой сети является, в частности, измерение числа ошибок передачи данных, степени загрузки (утилизации) ее ресурсов или времени реакции прикладного ПО.

Тестирование - это процесс активного воздействия на сеть с целью проверки ее работоспособности и определения потенциальных возможностей по передаче сетевого трафика. Как правило, оно проводится с целью проверить состояние кабельной системы (соответствие качества требованиям стандартов), выяснить максимальную пропускную способность или оценить время реакции прикладного ПО при изменении параметров настройки сетевого оборудования или физической сетевой конфигурации.

Поиск неисправностей в сети аппаратными средствами.

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

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

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

3. Кабельные сканеры позволяют определить длину кабеля, затухание, импеданс, схему разводки, уровень электрических шумов и оценить полученные результаты. Для определения местоположения неисправности кабельной системы (обрыва, короткого замыкания и т.д.) используется метод «кабельного радара», или Time Domain Reflectometry (TDR). Суть эго метода состоит в том, что сканер излучает в кабель короткий электрический импульс и измеряет время задержки до прихода отраженного сигнала. По полярности отраженного импульса определяется характер повреждения кабеля (короткое замыкание или обрыв). В правильно установленном и подключенном кабеле отраженный импульс отсутствует.

4. Тестеры (омметры) – наиболее простые и дешевые приборы для диагностики кабеля. Они позволяют определить непрерывность кабеля, однако, в отличие от кабельных сканеров, не обозначают, где произошел сбой. Проверка целостности линий связи выполняется путем последовательной «прозвонки» витых пар с помощью омметра.

Подключение персонального компьютера к локальной сети

Первое, что нужно сделать – это убедиться в работоспособности сетевой карты компьютера/ноутбука и наличии установленных драйверов. Еще одна немаловажная деталь, необходимая для локальной сети – это свитч (коммутатор) и сам сетевой кабель. Вместо коммутатора можно использовать Wi-Fi роутер. Но количество портов будет ограничено, зато в качестве бонуса будет доступ к сети интернет.

Подключение к локальной сети происходит в следующей последовательности.

Сетевой кабель присоединаятся к коммутатору и сетевой карте компьютера. Далее включается компьютер и свитч. ОС загрузится, примерно за это же время свитч-роутер мигнет лампочками, и можно приступать к настройкам сетевых параметров: надо перейти в «Панель управления» – «Просмотр состояния сети и задач» – «Изменение параметров адаптера» – «ПКМ» – «Свойства» – «Настроить IP-адрес компьютера» – «Протокол Интернета версии 4» – «Свойства». Ввести IP-адрес в формате «192.168.YYY.ХХХ». Нажать на маску сети один раз, она установится автоматически. Необходимо учесть, что последние два блока чисел и маска сети должны совпадать с адресами той сети, к которой настраивается подключение. Например, если сеть «192.168.1.ХХХ», то «1» - это номер подсети, а «ХХХ» - любое число от 1 до 254. После настройки нужно нажать «ОК».

Далее нужно установить рабочую группу, это необходимо для отображения компьютера в соответствующей группе. В офисе, например, в группе «Бухгалтерия» будут рабочие машины только из отдела «Бухгалтерия». Далее надо зайти в свойства «Мой компьютер» – «Изменить параметры». В свойствах системы нажать «Изменить», для присоединения компьютера к рабочей группе. Ввести имя компьютера и рабочую группу. Нажать «ОК» и перезагрузить ПК для вступления изменений в силу.

Еще один вариант подключения – беспроводной. Этот способ пригоден только при наличии Wi-Fi роутера. Для этого понадобятся Wi-Fi адаптер (для установки внутрь или USB-порта) и Wi-Fi роутер. Нужно подключить адаптер. Система автоматически распознает его, установит для него драйверы или попросит вставить диск с драйверами. В системном лотке рядом с часами отобразится значок беспроводной сети. Далее надо нажать на него, появится список доступных для подключения сетей, в котором нужно найти свою и подключиться. В этом случае достаточно только установить домашнюю группу, IP-адрес будет присвоен автоматически. В ноутбуке уже встроены сетевая карта и Wi-Fi адаптер.

Подключение персонального компьютера к сети интернет

Для подключения компьютера к ПК необходимо проделать следующее: «Пуск» – «Панель управления» – «Сеть и Интернет» – «Центр управления сетями и общим доступом» – «Изменение параметров адаптера» – «Сетевые подключения» – «Подключение по локальной сети» – «ПКМ» – «Свойства» – «Сеть» – «Протокол Интернета версии 4 (ТСР/IPv4)» – «Свойства». В последующем окне нужно поставить отметки напротив функций «Получить IP-адрес автоматически» и «Получить адрес DNS-сервера автоматически».

Подключая компьютер к беспроводной сети Wi-Fi, нужно произвести следующие действия: перейти в «Центр управления сетями и общим доступом» – «Подключение к сети». Справа всплывет окно, в котором показаны настройки подключения к сети. Нужно убедиться, не активен ли режим «в самолете» – он должен быть выключен. Ниже будет предоставлен список доступных подключений. Нужно выбрать сеть и подключиться. Можно также поставить отметку напротив строки «Подключаться автоматически» – компьютер будет сам подключаться к этой сети, если она доступна. Обычно при проверке требований сети требуется ввести пароль, но иногда бывает и бесплатный Wi-Fi.

Изучение АСУ предприятия

Автоматизированная система управления (сокращённо АСУ) – комплекс аппаратных и программных средств, а также персонала, предназначенный для управления различными процессами в рамках технологического процесса, производства, предприятия. АСУ применяются в различных отраслях промышленности, энергетике, транспорте и т.п. Термин «автоматизированная», в отличие от термина «автоматическая», подчёркивает сохранение за человеком-оператором некоторых функций, либо наиболее общего, целеполагающего характера, либо не поддающихся автоматизации. АСУ с системой поддержки принятия решений (СППР) являются основным инструментом повышения обоснованности управленческих решений.

Важнейшая задача АСУ – повышение эффективности управления объектом на основе роста производительности труда и совершенствования методов планирования процесса управления. Различают автоматизированные системы управления объектами (технологическими процессами – АСУТП, предприятием – АСУП, отраслью – ОАСУ) и функциональные автоматизированные системы, например, проектирование плановых расчётов, материально-технического снабжения и т.д.

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

­ предоставление лицу, принимающему решение (ЛПР), релевантных данных для принятия решений;

­ ускорение выполнения отдельных операций по сбору и обработке данных;

­ снижение количества решений, которые должно принимать ЛПР;

­ повышение уровня контроля и исполнительской дисциплины;

­ повышение оперативности управления;

­ снижение затрат ЛПР на выполнение вспомогательных процессов;

­ повышение степени обоснованности принимаемых решений.

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

Основными классификационными признаками, определяющими вид АСУ, являются:

­ сфера функционирования объекта управления (промышленность, строительство, транспорт, сельское хозяйство, непромышленная сфера и т. д.);

­ вид управляемого процесса (технологический, организационный, экономический и т. д.);

­ уровень в системе государственного управления.

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

­ планирование и (или) прогнозирование;

­ учет, контроль, анализ;

­ координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам.