@dchostsupport
Статья давно не обновлялась, поэтому информация могла устареть.
Иногда к нам поступают жалобы на работу сетевой инфраструктуры нашего дата-центра. К сожалению, сообщения в духе "у меня плохой 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 install mtr-nox11
winmtr (Windows): http://winmtr.sourceforge.net/
Проверка при помощи mtr
Для корректной работы утилиты, желательно выключить пакетные фильтры операционной системы и приложения прикладного уровня (англ. application layer): веб-сервера, почтовые сервера, файловые-сервера, сервера имен, клиентов/серверов пиринговых сетей и т.п. В идеальном варианте это должна быть чистая инсталляция ОС или можно загрузиться из шаблона восстановления при помощи DCImanager.
Для диагностики работы внутри локальной сети ДЦ подойдет следующая команда:
# mtr -s 1000 -r -n -bw -c 1000 -i 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 1000 -r -n -bw -c 1000 -i 1 <ip_адрес_источник> # mtr -s 1000 -r -n -bw -c 1000 -i 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-трансивер.
