Network Performance Monitoring (NPM) and Diagnostics | Application Performance Monitoring (APM) | Application-Aware Network Performance Monitoring (AA NPM) | Network Fault Management | Information Security | Network Security

Часть 2. Какие проблемы способна решать система мониторинга сети?

Часть 2. Какие проблемы способна решать система мониторинга сети?

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

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

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

Простои становятся все более неприемлемыми

Простои становятся все более неприемлемыми

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

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

Приложения становятся все более чувствительными ко времени

Приложения становятся все более чувствительными ко времени

Благодаря резкому увеличению числа приложений для совместной работы в реальном времени, таких, как передача голоса и видео, а также росту числа архитектур распределенных приложений — сети с перемещаемыми данными сейчас более чувствительны ко времени, чем когда-либо прежде. Следствием этого является необходимость потоки данных для приложений с малым временем ожидания идентифицировать, отметить и обработать с более высоким приоритетом, чем другие данные, проходящие через одни и те же сетевые подключения. Основным средством для выполнения этих типов задач является технология качества обслуживания (QoS), позволяющая предоставлять различным классам трафика различные приоритеты в обслуживании. Устройства второго и третьего уровня (работающие на этих уровнях в сетевой модели OSI), такие как маршрутизаторы и коммутаторы, сконфигурированы с поддержкой политик QoS, на основе которых и формируется очередность их действий.

Конечно, в идеальном мире технология QoS будет всегда правильно настроена по всей сети от одного ее конца и до другого. Но реальность такова, что QoS либо вовсе не настроена, либо плохо сконфигурирована где-то на пути передачи данных. Эта маленькая ошибка может стать серьезной проблемой для чувствительных ко времени коммуникаций. Выявление этих проблем вручную зачастую требует регистрации и проверки каждой конфигурации QoS вдоль всего пути передачи данных. С другой стороны, многие системы для мониторинга сети имеют функциональные возможности для анализа качества обслуживания, такие как сетевые протоколы NetFlow или sFlow, которые позволяют автоматически идентифицировать неэффективные или неправильно настроенные политики QoS.

Растет сложность сетевой архитектуры

Растет сложность сетевой архитектуры

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

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

Корреляция событий и анализ основной причины являются слабоэффективными

Корреляция событий и анализ основной причины являются слабоэффективными

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

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

Поиск единого окна мониторинга и устранения неполадок

Поиск единого окна мониторинга и устранения неполадок

Потенциальная возможность интеграции такого большого количества полезных инструментов для мониторинга сети и производительности в единой, объединенной системе является очень привлекательной. Канули в лету те дни, когда приходилось независимо использовать мониторинг SNMP, лог-файлы серверов, коллекторы NetFlow и анализаторы пакетов. Теперь мы можем объединить все эти полезные возможности в едином продукте для мониторинга производительности сети. Более того, создавая единое окно, мы также создаем единое хранилище данных, для которого отчеты и интеллектуальные решения могут быть сделаны с помощью мощных методов корреляции данных.

Всегда на связи, Игорь Панов

См. также:

 

 

Комментарии
Тут пока ничего нет, но Вы можете быть первым!
Авторизуйтесь для этого
Заказать звонок

- Email
- Confirm
Имя *
Телефон *
Комментарий
Согласие на отправку персональных данных *

* - Обязательное для заполнения