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

  • Tutorial
Предположим, у нас есть вот такая картина загрузки канала связи:


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

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

Если админ не совсем криворукий, а ситуация не очень хитрая, то минут за 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 либо в комментариях. Цены под вашу инфраструктуру могу тоже назвать в почте.
  • +24
  • 26,8k
  • 6

КРОК

387,00

№1 по ИТ-услугам в России

Поделиться публикацией

Похожие публикации

Комментарии 6
    +5
    это мечта, любого админа…
      +4
      еще бы opensource бы, да… предположу что цена решения(а это, похоже, ПАК) в долларах имеет от 5 разрядов, что по карману только «для золотодобывающей компании, для территориально распределённого банка, логистической компании»

      AVrublev, сколько оборудования(и какого?) необходимо дополнительно установить в сеть заказчика?
        0
        Решение может быть полностью построено на виртуальной платформе, так и все компоненты могут быть в виде ПАК. Выбор решения, виртуальная платформа или ПАК, зависит от объемов анализируемого трафика. Конечно, производительность ПАК выше.

        В базовом варианте в сеть заказчика нужно установить следующие компоненты:
        1. Сенсор для съема и хранения копии пакетов — Shark Sensor. Устанавливается около серверов в ЦОДе.
        2. Коллектор NetFlow статистики — Gateway.
        3. Головное устройство консолидации статистики, построения отчетов и аналитики — Cascade Profiler. Место установки не имеет значение, главное IP connectivity до Shark Sensor и Gateway.

        Если нужно анализировать сетевые потоки внутри регионального офиса, то устанавливаем дополнительный Shark Sensor там.
          0
          Есть опенсорсные *flow коллекторы, они отвечают на вопрос «что за трафик грузит канал?» или чуть глубже. Собственно, без этого жить вообще нельзя.

          Есть Cisco vNAM (виртуалка), он может ловить netflow или SPAN (до гигабита) и давать делать довольно глубокую аналитику. Ценник 4-значный, причем если SPAN мало или совсем нет, то первая цифра ценника — «1». Но под много трафика, конечно, надо аплайансы ставить.
        0
        А как вам может один пользователь сделать всплеск в канале? у вас резервирование не предусматривает использования всех мощностей всеми пользователями одновременно?
          0
          На WAN канале? Без переподписки? Исходя из «по гигабиту на пользователя, которых на площадке несколько тысяч»? Даже Газпром не настолько богат. На практике, обычно один пользователь технически способен нагрузить свой WAN канал полностью. А вот дальше начинают играть роль различные факторы, включая настроенный механизм приоритезации на канале (WFQ?), полисеры и так далее.

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

        Самое читаемое