 |
 |
 |
| |
Авторизация
Не зарегистрировались? Вы можете сделать это, нажав здесь. Когда Вы зарегистрируетесь, Вы получите полный доступ ко всем разделам сайта. |
|
 |
 |
 |
|  |
|
|
|
| |
«Хорошая погода» в сети
Разместил 03/09/2006 от admin |
|
 |
|
 |
| |
Повседневные проблемы в сети, как известно, многообразны: случайные обрывы соединения, перегрузки или низкая производительность могут иметь самые разные последствия и никогда не исключаются полностью. Поэтому постоянный и всеобъемлющий мониторинг так же важен, как и быстрый детальный обзор критичных точек
Границы между мониторингом, анализом и управлением сетью нередко оказываются размыты. Эти понятия не очень четко дифференцируются и используются не всегда корректно, а ведь все три перечисленные дисциплины различаются между собой довольно сильно.
Мониторингом сети называют (пассивное) наблюдение за потоками данных на протяжении длительного времени. При этом в сетевой системе идет активный процесс, регистрирующий многочисленные параметры: величину нагрузки на сеть, объем протокольных данных, изменение времени реакции. Главная задача — сбор подробной статистики. Данные, как правило, оцениваются централизованно и преобразуются в «удобочитаемую форму» при помощи приложения генерации отчетов.
Анализ данных или пакетов нацелен на обработку информации с более глубоких уровней базовой эталонной модели взаимодействия открытых систем. С его помощью можно регистрировать и декодировать мельчайшие ошибки в структуре данных или поведении станций и протоколов. Традиционно он используется в качестве «реакционной дисциплины» — как правило, в исключительных ситуациях и при ошибках. В последние годы классический сетевой анализ несколько утратил свои позиции по сравнению с мониторингом и управлением, теперь его рекомендуют использовать только в «распределенной» форме.
Управление сетью отличается «активным получением» значений параметров, прежде всего посредством протокола SNMP. При этом либо циклически опрашиваются стандартные статистические данные (MIB II, IETF/RFC1213) или специфическая информация (частные MIB), либо при помощи заранее определенных граничных значений отправляются и обрабатываются тревожные сообщения. В процессе опроса SNMP регулярно запрашивается статистический счетчик конечных устройств и сетевых систем, а поступающая информация записывается в специализированные базы данных. Помимо доставки данных команды Set протокола SNMP предоставляют возможность реконфигурации устройств.
МОНИТОРИНГ И АНАЛИЗ НА БАЗЕ ПОТОКОВ
Эта дисциплина «утвердилась» уже несколько лет назад, при этом так называемый мониторинг потоков развивается как отдельное направление. В отличие от массовой записи и хранения или обработки пакетов в классическом случае, анализ потоков отслеживает связи (потоки) между станциями или IP-адресами. Таблица потоков регистрирует пакеты данных либо в «выборочном режиме» (к примеру, каждый десятый пакет), либо пакет за пакетом. Вследствие заметно меньшего — по сравнению с анализом — объема данных мониторинг потоков может быть реализован в маршрутизаторах или коммутаторах при помощи главного процессора или специализированной интегральной схемы.
В целях ограничения объема данных, в особенности на магистральных коммутаторах и маршрутизаторах, вместо пакетов данных заранее сконфигурированному получателю (коллектору потоков) отправляется лишь обновление — статистическая информация со всеми деталями, при этом из памяти информация стирается. Доминирующими методами анализа на базе потоков являются Netflow (разработка Cisco) и S-Flow (разработка Foundry). Анализ и мониторинг потоков — это компромисс между очень точным анализом пакетов и статистической стратегией опроса SNMP. Новые потоковые технологии, к примеру Qflow, разработанная компанией Q1labs, базируются на схожей основной модели, однако концентрируются преимущественно на аспектах наблюдения, к примеру на распознавании аномалий и анализе безопасности.
Многие аналитические методы пытаются интерпретировать технические параметры и состояния для пользователя и определить причины отказов, падения производительности и проч. Часто это называют анализом основных причин (или первопричин). Очень сложно дать оценку отдельным ошибкам в общем контексте, потому что специфические для сети, сервера и приложений особенности не могут быть визуализированы немедленно. Часто анализ оказывается затруднен из-за сложности инфраструктуры ИТ, а иногда пользователь недооценивает влияния параметров, которыми на первый взгляд можно пренебречь. Порой для правильной оценки недостает решающей дополнительной информации, поскольку ее нельзя получить, к примеру, при помощи опроса SNMP.
В такой ситуации пригодятся активные методы тестирования, приобретающие все большее значение. Они используют реальную среду ИТ, чтобы из разных точек доступа к сети, а значит, с разных точек зрения проверять стандартизированным образом сетевые системы, службы и приложения и периодически контролировать их качество (готовность и производительность). При этом отдельные контрольные точки ведут себя как обычные пользователи.
Благодаря совмещению «частичных срезов» формируется очень пластичная качественная картина активных деловых процессов. Гибкость этого метода позволяет в зависимости от типа решения даже моделировать пользовательские сообщения, а также тесты приложений в пределах среды терминальных серверов. Однако измерение качества не непрерывно: проверки периодически прерываются, и в измерениях возникают пробелы.
|
|
 |
 |
 |
| |
|
|
|
| |
Рейтинг статьи
Средняя оценка: 0
Ответов: 0
|
|
|
|
|
|
|
