Pull to refresh
100.5

Сетевые детективы: ищем причины скачков трафика и нагрузки

Reading time6 min
Views31K
Предположим, у нас есть вот такая картина загрузки канала связи:


Что вызвало всплеск трафика? Что происходило в канале связи?

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

Если админ не совсем криворукий, а ситуация не очень хитрая, то минут за 10 можно будет выделить конкретные причины, создающие проблемы, и ещё минут за 15–20 проанализировать проблему. Если же ситуация сложнее (мы рассмотрим ещё пример ниже), то искать аномалии в поведении трафика можно сутками. С инструментарием обнаружения таких аномалий у нас на поиск проблемы в этом примере уйдёт 1 минута.

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



Хотим разобраться: трафик каких приложений/сервисов передаётся в канале связи и что вызвало всплеск?



Ага, понятно… CIFS — 92% от общего объёма трафика.



Выясняем, кто там работал (какие хосты и пользователи).



Первая пара клиент — сервер загрузила канал связи на 99% по CIFS.



Если у нас есть интеграция системы диагностики с Active Directory, мы можем выяснить, кто это. Пробуем.



У нас это некий Джон Смит. У проблемы появилась фамилия. И всё это за 1 минуту.



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

Теперь посмотрим пример посложнее, когда тормозит целая ERP-система.

Итак, есть вот такая картина:


ERP тормозит, пользователи жалуются. Почему? Куда смотреть? Где смотреть?

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

Общая задача


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

Используем Riverbed Cascade


Полное решение состоит из трёх с половиной частей:
  • Профайлера, отвечающего за анализ данных. Дополнение для рабочей станции Pilot Console — помощник профайлеру для быстрой обработки и анализа копии пакетов (TCP Dump), записанных на сенсорах. Если по-простому, Pilot — графический интерфейс ко всем известному Wireshark.
  • Gateway — сбор данных с первичных источников типа коммутаторов, маршрутизаторов и так далее. Gateway принимает все типы flow, данные дедуплицируются и отправляются на Profiler для анализа.
  • Сенсоров, наблюдающих за зеркалированными данными, измерением задержек. Также сенсоры хранят собранные пакеты у себя для исторического анализа возникших проблем. Статистика направляется на Profiler для анализа.



Пример для конкретного ЦОДа: установлены все три модуля. Shark Sensor принимает зеркалированные данные с коммутатора серверной фермы, Virtual Shark анализирует взаимодействия между виртуальными машинами — Gateway принимает flow с маршрутизаторов и оптимизаторов. Потом вся статистика идёт на профайлер. Pilot работает с копией трафика, хранящегося на Shark Sensor

Задумчивый сервер


Возвращаемся к ERP с проблемой.

image

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



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


Зелёная черта внизу графика — нормальный профиль работы сервера. Такой должен быть при стабильной работе сервера.

На графике реальные значения времени отклика сервера показаны синим цветом. Прокручиваем отчёт ниже.



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

Рассмотрим статистику проблемного сервера.



Видим MAC-адрес сервера, IP-адрес коммутатора и порт коммутатора, куда подключён сервер. Рассмотрим транзакции проблемного сервера в графической оболочке к Wireshark — Pilot Console.
На отчёте времени отклика сервера по объектам видно, что увеличено время предоставления лишь одного объекта.



Вот он, попался: complex.psp

Проверяем. Строим диаграмму взаимодействия по транзакциям. Проверяем:



Да, это оно.

Если кто ещё не верит, пусть проверит — переходим к ручному пакетному анализу в Wireshark той же транзакции.





Итак, мы только что получили исчерпывающую картину взаимодействия пользователей с Web-серверами сервиса ERP, что позволило найти сбойный Web-сервер, а даже точнее, сбойный объект на сервере.

Локализация проблем с многоуровневыми приложениями




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

Совместимость с оптимизаторами трафика



В предыдущем посте я уже писал про устройства-оптимизаторы трафика, которые умеют отлично сжимать каналы данных и часто используются банками, телеком-операторами и другими крупными компаниями, а также средним и крупным бизнесом, стремящимся эффективнее использовать канал связи и ускорить работу приложений. Так вот, поскольку оптимизаторы — продукт того же производителя, сетевая статистика с них может собираться и с помощью системы мониторинга Riverbed Cascade. Два решения отлично (и дёшево, что важно) сочетаются, что комплексно решает проблемы производительности приложений компаний.

Вот эти показатели оптимизации трафика собраны как раз Riverbed Cascade:


Соотношение LAN-трафика (синий график) и WAN-трафика (зелёный график) с оптимизацией. Наглядно видно, насколько уменьшился объём трафика в канале связи


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

Отчёты


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

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

Экспертные системы


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

Здесь же Riverbed Cascade обходит всех конкурентов: он снимает десятки метрик и строит профили нормального поведения каждой метрики. Пороговые значения ставить не надо, система соберёт историческую статистику, и на её основе будут сформированы пороговые значения. А при отклонении от нормы система проинформирует администратора или его руководителя.

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

И даже если установленные антивирусные системы не видят распространение нового вируса в сети, Riverbed Cascade обнаружит распространение «червя» по появившемуся аномальному трафику.

Вопросы


Мы реализовали это решение (в комплекте с оптимизацией трафика) для золотодобывающей компании, для территориально распределённого банка, логистической компании, закончили проект для энергетической компании и ещё десятки проектов поменьше. Такая штука нужна в каждом ЦОДе, как мне кажется. В общем, если есть вопросы — задавайте на AVrublevsky@croc.ru либо в комментариях. Цены под вашу инфраструктуру могу тоже назвать в почте.
Tags:
Hubs:
Total votes 42: ↑33 and ↓9+24
Comments6

Articles

Information

Website
croc.ru
Registered
Founded
Employees
1,001–5,000 employees
Location
Россия