Самоучитель
системного администратора

11.1. Особенности отказов различных компонентов

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

Мониторинг отказоустойчивой структуры

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

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

Неисправности подсистемы передачи данных

С одной стороны, неисправность подсистемы передачи данных легко обнаружить. Достаточно попытаться скопировать по сети большой файл, например, в 100 Мбайт. По сети с пропускной способностью 100 Мбит/сек файл должен передаться менее чем за 20 сек, для гигабитной сети — менее чем за 5 сек. Если время копирования больше, то следует искать проблемы.

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

Обнаружение неисправностей сетевой инфраструктуры

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

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

Случаи выхода из строя сетевых портов нередки. Особенно часто это происходит на длинных (близких к максимальному значению) медных линиях связи после гроз.

    Примечание

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

Если порты исправны, то между ними должны передаваться пакеты данных. Сегодня в большинстве систем применяется протокол TCP/IP, поэтому опишем последовательность проверки соединения для такого случая.

Диагностика IP-протокола

Для диагностики соединения с использованием протокола TCP/IP рекомендуется использовать следующую последовательность операций:

  1. Проверка параметров настройки IP-протокола.
  2. Проверка достижимости ближайших компьютеров сети.
  3. Проверка функционирования серверов имен.
    Примечание

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

Проверка параметров настройки IP-протокола

Для отображения параметров IP-протокола используются утилиты ipconfig (Windows КТ/200х/ХР/УМа/7), winipcfg (Windows 9x/ME), ifconfig (*nix-системы).

Утилиты ipconfig, ifconfig выполняются в режиме командной строки. Утилита winipcfg имеет графический интерфейс.

Утилиты выводят на экран параметры настройки протокола TCP/IP: значения адреса, маски, шлюза. Далее показан пример листинга после запуска утилиты ifconfig, с помощью одноименной команды ifconfig.

Программа показывает параметры сетевого интерфейса eth0 и локального интерфейса lo.

Если указанные утилиты покажут, что сетевому адаптеру присвоен адрес 169.254.134.123 (или аналогичный из подсети 169.254.0.0/16), то можно сделать заключение, что в сети недоступен сервер, автоматически присваивающий параметры IP-протокола. Часто причиной подобной ошибки (если ранее компьютер нормально работал в сети) является нарушение контакта в подсоединении сетевого кабеля.

Чтобы инициировать получение параметров адреса, в Windows можно выполнить команду ipconfig /renew, для *nix-систем можно просто перезапустить сетевые службы (например, командой /etc/init.d/networking restart для Ubuntu). Если параметры адреса не присваиваются автоматически, то следует временно назначить их вручную (соответственно используемому на предприятии диапазону адресов).

Проверка достижимости ближайших компьютеров сети

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

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

1. Сначала проверяется работоспособность протокола TCP/IP путем "пингования" локального интерфейса — адреса 127.0.0.1:

ping 127.0.0.1

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

    Примечание

    В листинге приведена информация, выводимая данной командой в среде Ubuntu. Поскольку в ОС Linux команда ping, применяемая без ключей, передает пакеты непрерывно, то явно указана необходимость посылки только одного пакета (можно ввести команду без ключа с последующим прерыванием посылки пакетов сочетанием клавиш <Ctrl>+<C>).

Если будет показано сообщение о недостижимости адресата, то это означает ошибку установки протокола IP. В этом случае целесообразно удалить протокол из системы, перезагрузить компьютер и вновь установить поддержку протокола TCP/IP.

2. Следующим шагом необходимо проверить ответ локального компьютера по присвоенному ему IP-адресу. Для этого следует выполнить команду:

ping <адрес>

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

3. Следующая проверка — это выполнение команды ping с указанием IP-адреса любого компьютера в локальном сегменте. Можно использовать любой адрес, относительно которого вы уверены, что он достижим в локальной сети на момент проверки. Например, IP-адрес шлюза или адрес DNS-сервера.

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

    Примечание

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

4. Последняя проверка — это команда ping, с указанием в качестве параметра не IP-адреса, а имени какого-либо компьютера (например, имя www-сервера вашего провайдера):

ping <имя>

Если не будет ответа на ввод команды с именем существующего хоста, то это может свидетельствовать либо об ошибке в задании DNS-серверов, либо об их неработоспособности.

Проверка доступности приложений на удаленном компьютере

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

Существуют различные возможности проверить удаленные системы. Во-первых, в Support Tools присутствует утилита portqry.exe, которая позволяет увидеть ответ удаленной системы на запрос по конкретному порту. Так, для проверки достижимости FTP-сервера можно выполнить следующую команду:

portqry -n kenin -e 21

Результатом будет, например, такой вывод:

Утилита сообщила, что порт 21 открыт, и отобразила информацию, которую выдает FTP-сервер, работающий на этом компьютере (имя компьютера kenin).

Сходные утилиты, позволяющие получить ответ на запрос, отправленный на конкретный порт, легко найти в Интернете. Но проще использовать программу telnet, которая входит в состав всех операционных систем. Для систем Windows NT 6.0 и старше ее надо добавить в число установленных компонентов (она называется клиентом telnet). В предыдущих версиях утилита доступна по умолчанию. Запуская эту утилиту с параметрами в виде имени удаленной системы и номером порта, вы осуществляете попытку подключения к соответствующему порту. Если попытка подключения будет происходить, то либо на экране появится ответ, либо экран на некоторое время "зависнет", после чего соединение разорвется по таймауту. Если порт не отвечает, то вы увидите на экране сообщение о невозможности подключения. Далее приведен листинг команды telnet при проверке доступности порта 25 (порт почтового сервера, попытка неудачна) и 80 (порт сервера WWW, видно, что порт ответил на запрос).

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

Листинг команды tracert таков:


Утилита показывает узлы, через которые пересылается пакет, и задержку в его передаче на каждом этапе. По результату выполнения данной команды можно оценить, что наибольшая задержка в прохождении сигнала возникает на каналах связи с узлами, стоящими в строках 7 и 8. Одиночные звездочки свидетельствуют, что ответ от этого узла не получен в заданный диапазон времени. Если в строке стоят все звездочки, то это может обозначать, что администраторы соответствующих хостов не разрешили прохождение ICMP-пакетов (пакеты, которые используются в том числе и командами ping и tracert).

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

Проверка качества канала связи

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

Обычно такие ситуации связаны с перегрузкой канала: пропускная способность магистральных линий всегда меньше суммы пропускных способностей подключенных к ней каналов связи. В правильно спроектированной локальной сети предприятия такие ситуации встречаются редко. Обычно проблемы возникают только в случае внедрения видеонаблюдения (5—6 камер при передаче кадров высокого разрешения успешно исчерпывают полосу 100 Мбит сети) или в точке выхода в Интернет. В глобальной сети ситуация более типовая, но вы не сможете повлиять на нее. В критических ситуациях можно приобрести канал передачи между двумя точками с заданным качеством обслуживания, но подобные решения доступны не всегда и стоимость часто не позволяет применить их на практике.

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

Объективные показатели качества канала связи

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

    Примечание

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

Для объективного анализа состояния линии связи можно использовать следующие основные показатели:

  • коэффициент использования пропускной способности сети;
  • число ошибочных пакетов;
  • величина коллизий;
  • загрузка процессора активного оборудования.

Коэффициент использования пропускной способности сети

Для сети Ethernet значение этого показателя выше примерно 70% свидетельствует уже о критической ситуации.

Число ошибочных пакетов

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

Величина коллизий

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

Загрузка процессора активного оборудования

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

На рис. 11.8 представлен фрагмент окна программы Observer, которое отображает данные по пропускной способности портов маршрутизатора. Для их получения используются стандартные параметры SNMP для маршрутизатора; информация запрашивается и отображается на графике каждые 2 секунды. Четко видно, что загрузка одного из портов составляет в среднем 70—80%. Фактически это означает исчерпание ресурсов пропускной способности канала (на рисунке показаны данные маршрутизатора, установленного на канале доступа в Интернет с ограниченной пропускной способностью).

Рис. 11.8.
Мониторинг состояния сети по протоколу SNMP

    Примечание

    На рис. 11.8 показано окно коммерческой программы, однако аналогичные данные могут быть получены и при помощи бесплатных утилит. Например, на сайте www.mrtg.org можно найти программу Multi Router Traffic Grapher (и ее исходные коды) для отображения данных статистики маршрутизатора. Изначально программа предназначалась для Linux, но имеется также ее бесплатная версия для Windows, работающая на Perl.

Утилита pathping

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


Программа pathping выводит статистические данные о достижимости каждого промежуточного хоста, причем время усреднения выбирается исходя из конкретной ситуации (в примере подсчет проводился за период в 375 сек). Первым параметром выводится время доступа к данному хосту, затем показано количество отправленных на него пакетов и число неполученных ответов (с процентом успеха). После этого отображаются аналогичные значения для достижимости конечного хоста при расчете прохождения пакетов от данной промежуточной точки. Так, цифры в 14-й строке говорят о том, что время доступа к хосту составляет 1059 мсек и при отправке на него 100 пакетов на четыре отсутствовал ответ. А если бы сигнал на конечный хост передавался с позиции номер 14, то при посылке 100 пакетов ответ был бы получен на все. В завершение после имени данного промежуточного хоста утилита сообщила, что количество успешных пакетов составило 96%.

Оценка качества аудио- и видеопотоков

Оценка качества передачи аудио- и видеосигналов имеет некоторые отличия. Данные по сети Ethernet передаются, в основном, по протоколу TCP: если пакет по тем или иным причинам теряется или искажается в процессе пересылки, то системы обнаруживают ошибки и повторяют пересылку информации.

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

Выделяются следующие основные показатели:

  • задержка при передаче данных;
  • джиттер;
  • потеря пакетов.

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

Задержка при передаче данных ip-телефонии

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

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

Джиттер

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

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

Допустимые потери пакетов в телефонном разговоре

Человек может не заметить ухудшение качества разговора при потере пакетов меньшей примерно 5%. Но уже при потере в 10% и более слышно бульканье, речь становится малоразборчивой.

Способы получения объективных показателей передачи мультимедийных данных

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

Для анализа состояния инфраструктуры можно использовать программы, предназначенные для мониторинга сетевого трафика. Одна из наиболее популярных и функциональных программ этого класса — это Observer производства Network Instruments, LLC (www.networkinstruments.com).

    Примечание

    Программа для мониторинга сети из состава Windows (Network Monitor) позволяет перехватывать пакеты, передаваемые по сети, но не содержит серьезных средств анализа полученных данных. Observer — коммерческий продукт, но для проведения анализа состояния сети можно воспользоваться бесплатно предоставляемой версией ограниченного срока пользования (trial-версией). Кроме того, серьезными возможностями обладает бесплатный сниффер Wireshark (бывший Ethereal — http://www.wireshark.org/). В том числе, возможностью перехвата и анализа голосового трафика. На рис. 11.9 (из документации продукта) показан пример окна анализа RTP-трафика.

Рис. 11.9.
Окно анализа голосового потока

Снифферы часто формируют интегральные показатели качества разговора. Например, одним из таких показателей является коэффициент MOS. Этот коэффициент представляет собой экспертную оценку качества: он рассчитывается по определенной методике на основе сравнения группой слушателей полученного сигнала и эталона. Считается, что коэффициент MOS больший 4 соответствует бизнес-качеству разговора, а меньший 2,5 является недопустимым.


Рейтинг@Mail.ru