Диагностирование сети

Материал из wiki.planetahost.ru
Перейти к: навигация, поиск

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

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

Для того, чтобы убедиться в работоспособности сети, существует множество диагностических утилит, таких как ping, nslookup, traceroute, mtr, tracepath...

Первичная диагностика

Для начала следует проверить работоспособность основного сетевого интерфейса сервера при помощи следующей команды:

ping <ip_адрес_интерфейса>

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

ping <адрес_соседа>

После этого необходимо проверить работоспособность серверов DNS с помощью команды:

host <имя_хоста имя_сервера_DNS>

Наконец, для проверки возможности доступа к Интернету необходима команда:

ping <интернет_сервер>

Например:

ping www.ru 

Диагностика с трассировкой маршрута

Если проблема выражена в потере пакетов, jitter или больших задержках ping, то полезно сделать trace (в двух направлениях) с помощью такого инструмента, как mtr/WinMTR.

mtr — это бесплатная утилита, одновременно сочетающая в себе возможности программ ping и traceroute.

Установка mtr

SuSE: через Yast

Debian/Ubuntu: apt-get install mtr-tiny

Gentoo: emerge -av mtr

FreeBSD: pkg_add -r mtr-nox11

winmtr (Windows): http://winmtr.sourceforge.net/

Проверка при помощи mtr

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

Для диагностики работы внутри локальной сети ДЦ подойдет следующая команда:

# mtr -s 1500 -r -c 1000 -i 0.1 82.146.46.60 

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

Список хостов Web-DC для трассировки

Список хостов, которые можно пропинговать в WebDC для диагностики следующий: 82.146.46.60; 188.120.247.1; 188.120.243.74; 92.63.101.191. Так или иначе на каждом из хостов работают сетевые сервисы, поэтому в момент их предельной нагрузки могут появляться задержки. Рекомендуем сделать mtr нескольких из перечисленных хостов. Для получения более точных результатов рекомендуется проводить тестирование от 3 до 10 раз. Окончательным результатом можно считать среднее значение полученной величины.

Список хостов интернет для трассировки

Для диагностики работы "Интернета" подойдут DNS сервера yandex и google (77.88.8.8, 77.88.8.1 и 8.8.8.8, 8.8.4.4) следующий синтаксис:

# mtr -s 1500 -r -c 1000 -i 0.1 <ip_адрес_источник> 
# mtr -s 1500 -r -c 1000 -i 0.1 <ip_адрес_назначение> 

Общее правило трассировки

Поскольку в нашем ДЦ используется асинхронная маршрутизация, то необходимо соблюдать одно базовое условие - трассировка mtr должна отработать в обоих направлениях, то есть, на проблемный сервер и в обратном направлении. Аналогично, для получения более точных результатов рекомендуется проводить тестирование от 3 до 10 раз, и чередовать различные хосты. Обычно тест до одного узла занимает 3-4 минуты.

Правила подачи запроса в службу поддержки

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

Сообщения о проблемах с сетью не содержащие данной информации не могут быть приняты к рассмотрению.

В качестве примера приведем воображаемую переписку клиента К со специалистом службы поддержки С:

К: У меня наблюдаются потери пакетов внутри сети дата центра и в глобальную сеть, 
   узлы { 82.146.46.60; 188.120.247.1; 188.120.243.74; 92.63.101.191 } пингуются с потерями, в районе 7%. Вывод MTR в прикрепленном файле;
С: Наши сетевые инженеры проверят коммутацию до вашего сервера, для диагностики предоставьте доступ на сервер.
К: Доступ к серверу — root:PASSWORD
С: Проблема устранена, заменен неисправный SFP-трансивер.