Доступность : Высокая доступность

Управление производительностью: Рекомендации и Описание технологических решений

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

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

Общие сведения

Планирование мощности является процессом, которым вы определяете требования для ресурсов сети будущего для предотвращения производительности или влияния на доступность на критически важных для бизнеса приложениях. В области планирования мощности базовые средства сети (ЦПУ, память, буферы, входящие/исходящие октеты, и т.д.) могут влиять на время отклика. Поэтому имейте в виду, что проблемы производительности часто коррелируют с емкостью. В сетях это, как правило, - пропускная способность и данные, которые должны ждать в очередях, прежде чем это сможет быть передано через сеть. В голосовых приложениях это время ожидания почти наверняка влияет на пользователей потому что факторы, такие как влияние задержки и дрожания качество голосового вызова.

Другая основная проблема, которая усложняет управление производительностью, - то, что невзирая на то, что высокий уровень доступности сети критически важен и для крупного предприятия и для сетей поставщика услуг, тенденция состоит в том, чтобы искать краткосрочные экономические усиления рискуя (часто непредвиденный) более высокие стоимости в конечном счете. Во время каждого бюджетного цикла администраторы сети и персонал реализации проекта изо всех сил пытаются найти баланс между производительностью и внедрением FAST. Далее, администраторы сети сталкиваются с трудностями, которые включают быструю разработку продукта для совещания узких рыночных окон, сложных технологий, укрепления бизнеса, конкурирующих рынков, незапланированное время простоя, отсутствие экспертных знаний, и часто недостатки программных средств.

В свете этих проблем, как производительность соответствует в Network Management Framework? Первичная функция идеальной системы управления сетями должна оптимизировать эксплуатационные качества сети. Как только вы принимаете это как конечную цель для управления сетью, тогда фокус управления сетью должен поддержать функционирование сети при пиковой производительности.

Идеальная система управления сетями включает эти основные операции:

  • Сообщает оператору нависшего ухудшения производительности.

  • Когда ухудшение производительности или сбой имеют место, предоставляет простое формирование резервных маршрутов и обходит.

  • Предоставляет программные средства для точного определения причин ухудшения производительности или сбоя.

  • Служит основной станцией для способности сети к восстановлению и жизнеспособности.

  • Передает производительность в режиме реального времени.

На основе этого определения для идеальной системы управление производительностью становится важным для управления сетью. Эти проблемы управления производительностью важны:

  • Эффективность работы пользователя

  • Производительность приложения

  • Планирование пропускной способности

  • Упреждающее управление обработкой отказов

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

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

Факторы критического успеха

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

Примечание: Дополнительную информацию см. в Индикаторах управления производительностью.

Это факторы критического успеха для управления производительностью:

  • Соберите базовые показатели и для сети и для данных прикладной программы.

  • Выполните анализ возможных вариантов в сети и приложениях.

  • Выполните исключение, сообщающее для проблем емкости.

  • Определите издержки управления сетью для всех предложенных или сервисы управления потенциальной сети.

  • Проанализируйте информацию о емкости.

  • Периодически рассматривайте информацию о емкости и для сети и для приложений, а также базовых показателей и исключения.

  • Имейте обновление или настраивающиеся процедуры, установленные для обработки проблем емкости и на реактивной и на долгосрочной основе.

Индикаторы для управления производительностью

Индикаторы производительности предоставляют механизм, которым организация может измерить факторы критического успеха. Индикаторы производительности для планирования производительности включают:

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

  • Создайте детализированный и цели уровня измеряемого обслуживания.

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

  • Соберите список переменных для базовых показателей, таких как интервал опроса, понесенные издержки управления сетью, возможные пороги срабатывания триггера, используется ли переменная в качестве спускового механизма для trap-сообщения и анализа тенденции, используемого против каждой переменной.

  • Имейте периодическое совещание, которое рассматривает анализ базовых показателей и тенденций.

  • Задокументируйте методологию анализа возможных вариантов. Это должно включать моделирование и проверку когда это применимо.

  • Когда пороги, превышают, развиваются, документация относительно методологии использовала увеличивать сетевые ресурсы. Один элемент к документу является линией времени, требуемой вставить дополнительную полосу пропускания глобальной сети (WAN) и таблицу расчета затрат.

Структура процесса управления производительностью

Эти шаги предоставляют поток процессов высокого уровня для управления производительностью:

  1. Разработайте основные понятия управления сетью операций

    1. Определите необходимые характеристики: сервисы, масштабируемость и задачи доступности

    2. Определите доступность и цели управления сетью

    3. Определите SLA производительности и метрики

    4. Определите SLA

  2. Измерьте уровень

    1. Соберите данные базового анализа сети

    2. Оценки доступности

    3. Время отклика меры

    4. Точность меры

    5. Использование меры

    6. Планирование пропускной способности

  3. Выполните превентивный анализ отказов

    1. Используйте пороги для упреждающего управления обработкой отказов

    2. Внедрение управления сетью

    3. Эксплуатационные показатели сети

Разработайте основные понятия управления сетью операций

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

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

  • Определите тех основные характеристики к эффективному использованию инфраструктуры сети.

  • Определите сервисы/приложения, которые поддерживает сеть.

  • Инициируйте сквозное управление обслуживанием.

  • Инициируйте метрики на основе производительности для улучшения полного сервиса.

  • Соберите и распределите информацию об управлении производительностью.

  • Поддержите стратегическую оценку сети с отзывом от пользователей.

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

Как менеджер сети, вы находитесь в позиции для объединения часто противоречивой плановой производительности пользователей. Например, если основное требование для сети является передачей больших файлов от одного местоположения до другого, вы хотите фокусироваться на высокой пропускной способности и меньше на временах отклика интерактивных пользователей. Бойтесь ограничивать представление производительности, пока вы не рассматриваете множества проблем. Например, когда вы тестируете сеть, посмотрели на уровни загрузки, которые используются. Загрузка часто на основе очень небольших пакетов и пропускной способности на очень больших пакетах. Любая из этих проверок производительности могла бы произвести очень положительная картина, но на основе сетевого трафика, тесты не могли бы представить истинную картину производительности. Изучите производительность сети при как можно большем количестве возможных условий рабочей нагрузки и задокументированную производительность.

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

Наконец, гарантируйте, что вы не создаете далекие от реальности ожидание производительности сети. Далекие от реальности ожидание обычно создаются при недоразумении подробных данных сетевых протоколов или приложений. Часто низкая производительность времен не является отказом сети, а скорее результатом дизайна некачественного нанесения. Единственный способ задокументировать и измерить производительность приложения состоит в том, чтобы иметь базовые показатели производительности сети до установки приложения.

Определите необходимые характеристики: сервисы, масштабируемость и задачи доступности

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

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

  • Полный трафик

  • Громкость

  • Количество маршрутов

  • Количество виртуальных каналов

  • Числа соседей

  • Широковещательные домены

  • Производительность устройства

  • Емкость носителя

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

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

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

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

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

Это цели стандартной производительности:

  • Время отклика

  • Использование

  • Throughput

  • Емкость (скорость максимальной пропускной способности)

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

Определите доступность и цели управления сетью

Задачи доступности определяют уровень обслуживания или требуемые уровни сервиса для сетевого сервиса. Это помогает гарантировать, что решение встречает конечные требования доступности. Определите другие классы обслуживания для определенной структуры и детализируйте требования к сети для каждого класса, которые являются соответствующими требованиям доступности. Различные области сети могли бы также потребовать разных уровней доступности. Цель более высокой доступности могла бы требовать увеличения объема резервирования и процедур поддержки. Когда вы определяете задачу доступности для определенного сетевого сервиса и измеряете доступность, организация сети может понять компоненты и уровни сервиса, требуемые достигнуть спроектированных SLA.

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

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

Определите SLA производительности и метрики

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

Определите SLA

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

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

Измерьте уровень

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

Соберите данные базового анализа сети

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

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

Выполните базовые показатели текущей сети до нового решения (приложение или изменение IOS) развертывания и после развертываний для измерения набора ожиданий для нового решения. Эти базовые показатели помогают определять, встречает ли решение производительность и емкость сравнительного теста и задачи доступности. Типичный маршрутизатор / базовый отчет коммутатора включает проблемы емкости, отнесенные в ЦПУ, память, управление буферами, использование ссылки/сред и пропускную способность. Существуют другие типы основных данных, которые вы могли бы также включать, на основе определенных целей в концепции действий. Например, основы доступности демонстрируют увеличенную устойчивость/доступность сетевой среды. Выполните базовое сравнение между старыми и новыми средами для подтверждения требований решения.

Другие специализированные базовые показатели являются базисом приложений, который ценен, когда вы отклоняетесь требования к сети приложений. Эта информация может использоваться для составления счетов и/или составления бюджета целей в цикле обновления. Базисы приложений могут также быть важными в доступности области применения относительно предпочтительных сервисов или качеств обслуживания на приложение. Информация о базисе приложений в основном состоит из пропускной способности, используемой приложениями на период времени. Некоторые приложения для управления сетью могут также базовая производительность приложения. Отказ типа трафика (Telnet или FTP) также важен для планирования. В некоторых организациях более ограниченные критическим ресурсом области сети проверены для главных говорящих. Администраторы сети могут использовать эту информацию, чтобы планировать, запланировать, или настроить сеть. При настройке сети вы могли бы модифицировать качество обслуживания или параметры очереди для сетевого сервиса или приложения.

Оценки доступности

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

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

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

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

Время отклика меры

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

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

  • Перегрузка сети

  • Меньше, чем предпочитаемый маршрут назначению (или никакой маршрут вообще)

  • Недостаточно мощные сетевые устройства

  • Сбои сети, такие как широковещательный шторм

  • Шум или ошибки CRC

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

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

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

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

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

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

Альтернатива сервер-центричному опросу должна распределить усилие ближе источнику и назначению, которое вы хотите моделировать для меры. Используйте управление распределенной сетью pollers и внедрите Агента системы обеспечения обслуживания Cisco IOS (SAA) функциональность. Можно включить SAA на маршрутизаторах для измерения времени отклика между маршрутизатором и целевым устройством, таким как сервер или другой маршрутизатор. Можно также задать TCP или порт UDP, который вынуждает трафик быть переданным и направленным таким же образом как трафик, который это моделирует.

С интеграцией голоса, видео и данных на мультисервисных сетях, клиенты внедряют назначение приоритетов QoS в своей сети. Простой ICMP или измерение UDP точно не отражают время отклика, так как другие приложения получают другие приоритеты. Кроме того, с коммутацией на основе тэгов маршрутизация трафика могла бы варьироваться на основе типа приложения, содержавшегося в определенном пакете. Таким образом, Функция проверки связности ICMP ping могла бы получить другие приоритеты в том, как каждый маршрутизатор обрабатывает ее и мог бы получить другие, менее эффективные маршруты.

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

Точность меры

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

С более ранними сетевыми технологиями, особенно в глобальном, определенный уровень ошибок был приемлем. Однако с высокоскоростными сетями и современными сервисами глобальной сети (WAN), передача значительно более точна, и частоты ошибок близко к нолю, пока нет актуальная проблема. Некоторые типичные причины ошибок интерфейса включают:

  • Нестандартное проводное соединение

  • Электрическая помеха

  • Неисправное оборудование или программное обеспечение

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

Переменные, описанные в этой таблице, используются в формулах частоты ошибок и точности:

Нотация Описание
ΔifInErrors Дельта (или различие) между двумя циклами опроса, которые собирают объект ifInErrors snmp, который представляет количество входящих пакетов с ошибкой.
ΔifInUcastPkts Дельта между двумя циклами опроса, которые собирают объект snmp ifInUcastPkts, который представляет количество входящих одноадресных пакетов.
ΔifInNUcastPkts Дельта между двумя циклами опроса, которые собирают объект snmp ifInNUcastPkts, который представляет количество входящих неодноадресных пакетов (групповая адресация и широковещание).

Формула для частоты ошибок обычно выражается как процент:

Частота ошибок = (ΔifInErrors) *100

-------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts)

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

Формула точности берет частоту ошибок и вычитает ее от 100 (снова в форме процента):

Точность = 100 - (ΔifInErrors) *100

-----------------------------------------

(ΔifInUcastPkts + (ΔifInNUcastPkts)

Эти формулы отражают, что ошибка и точность с точки зрения ILS MIB взаимодействуют (RFC 2233) счетчики общего назначения. Результат выражен с точки зрения процента, который сравнивает ошибки с общими пакетами, замеченными и передаваемыми. Частота ошибок, которая результаты вычтены от 100, который производит степень точности. Степень точности 100% совершенна.

Так как переменные ILS MIB сохранены как счетчики, необходимо взять два цикла опроса и изобразить различие между двумя (следовательно Дельта, используемая в уравнении).

Использование меры

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

Использование является принципиальной мерой, чтобы определить, насколько полный сетевые каналы (ссылки). ЦПУ меры, интерфейс, организация очереди и другие связанные с системой измерения емкости для определения степени, до которой использованы ресурсы сетевой системы.

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

Поскольку интерфейс становится переполненным, сетевое устройство должно или сохранить пакет в очереди или сбросить от него. Если маршрутизатор пытается сохранить пакет в полной очереди, пакет отброшен. Когда трафик передан с быстрого интерфейса на более медленный интерфейс, отброшенные пакеты заканчиваются. Это обозначено в формуле Q = u / (1-u), где u является использованием, и Q является средней глубиной очереди (случайный принятый трафик). Таким образом, уровни высокого коэффициента использования на ссылках приводят к высоким средним глубинам очереди, который является предсказуемой задержкой, если вы знаете размер пакета. Некоторые сообщающие о сети поставщики указывают, что можно упорядочить меньше пропускной способности и заплатить меньше за глобальную сеть (WAN). Однако последствия задержки появляются при выполнении каналов WAN при 95%-м использовании. Кроме того, поскольку сети перемещены на VoIP, администраторы сети, возможно, должны были бы изменить свою политику и выполнить каналы WAN при приблизительно 50%-м использовании.

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

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

Нотация Описание
ΔifInOctets Дельта (или различие) между двумя циклами опроса, которые собирают объект snmp ifInOctets, который представляет количество входящих байтов трафика.
ΔifOutOctets Дельта между двумя циклами опроса, которые собирают объект snmp ifOutOctets, который представляет количество исходящих октетов трафика.
ifSpeed Скорость интерфейса, как сообщается в объекте ifSpeed snmp. Обратите внимание на то, что ifSpeed не мог бы точно отразить скорость Интерфейса WAN.

Подключения к ЛВС с общим доступом имеют тенденцию быть полудуплексом в основном, потому что обнаружение конфликтов требует, чтобы устройство слушало, прежде чем это передаст. Подключения к глобальной сети (WAN) являются, как правило, полным дуплексом, потому что соединение "точка-точка"; оба устройства могут передать и получить в то же время, так как они знают, что существует только одно другое устройство, которое совместно использует соединение.

Так как переменные ILS MIB сохранены как счетчики, необходимо взять два цикла опроса и изобразить различие между двумя (следовательно Дельта, используемая в уравнении).

Для полудуплексных средств используйте эту формулу загрузки интерфейса:

(ΔifInOctets + ΔifOutOctets) * 8 * 100

----------------------------------------------------

(кол-во секунд в Δ) * ifSpeed

Для дуплексных средств вычисление использования более сложно. Например, при полном последовательном подключении T-1, линейная скорость равна 1.544 Mbps. Это означает, что интерфейс T-1 может и получить и передать 1.544 Мбит/с для объединенной возможной пропускной способности 3.088 Мбит/с.

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

макс. (ΔifInOctets, (ΔifOutOctets) * 8 * 100

-----------------------------------------

(кол-во секунд в Δ) * ifSpeed

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

Использование входных данных = ΔifInOctets *8 * 100

-------------------------------------

(кол-во секунд в Δ) * ifSpeed

И

Выходной коэффициент использования = ΔifOutOctets *8 * 100

------------------------------------

(кол-во секунд в Δ) * ifSpeed

В то время как эти формулы несколько упрощены, они не учитывают издержки, привязанные к конкретному протоколу. Более точные формулы существуют для обработки уникальных сторон каждого протокола. Как пример, RFC 1757 содержит формулы использования Ethernet, которые учитывают служебную информацию пакета. Однако команда высокой доступности нашла, что общие формулы, представленные здесь, могут использоваться надежно и по LAN и по Интерфейсам WAN в большинстве случаев.

Планирование пропускной способности

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

Выполните превентивный анализ отказов

Превентивный анализ отказов важен для управления производительностью. Тот же тип данных, которые собраны для управления производительностью, может использоваться для превентивного анализа отказов. Однако синхронизация и использование этих данных являются другими между упреждающим управлением обработкой отказов и управлением производительностью.

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

Где опрос производительности данных обычно выполняется каждые 10, 15, или даже 30 минут, распознавание условия отказа должно быть в намного более коротком временном интервале. Один метод упреждающего управления обработкой отказов с помощью Сигнальных оповещений "rmon" и групп событий. Можно установить пороги на устройствах, которые не опрошены внешними устройствами, таким образом, пороги намного короче. Другой метод, который не покрыт этим документом, с помощью распределенной системы управления, которая позволяет опросить на локальном уровне с агрегированием данных в диспетчере администраторов.

Используйте пороги для упреждающего управления обработкой отказов

Пороговая обработка является процессом, в котором вы определяете интересные места в определенных потоках данных и генерируете события, когда вызваны пороги. Используйте данные производительности сети для устанавливания тех порогов.

Существует несколько различных типов порогов, некоторые из которых более применимы к определенным типам данных. Пороги только применимы к числовым данным, так преобразуйте любые текстовые данные в дискретные целочисленные значения. Даже если вы не знаете все возможные текстовые строки для объекта, можно все еще перечислить "содержательные" строки и назначить все другие строки на значение набора.

Существует два класса порогов для двух классов числовых данных: непрерывный и дискретный. Непрерывные пороги применяются к непрерывный или данные серии времени, такие как данные, хранившие в счетчиках SNMP или приборах. Дискретные пороговые значения применяются к перечислимым объектам или любым дискретным числовым данным. Объекты Boolean являются перечисляемыми значениями с двумя значениями: истина или ложь. Дискретные данные можно также назвать данными события, потому что события отмечают переход от одного значения до следующего.

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

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

Данные серии времени могут быть представлены или как счетчики, где каждая новая точка данных добавлена к сумме точек предыдущих данных, или как прибор, где данные представлены как скорость по временному интервалу. Существует два различных форм непрерывных порогов, применимых к каждому типу данных: абсолютные непрерывные пороги и относительные непрерывные пороги. Используйте абсолютные непрерывные пороги с приборами и относительные непрерывные пороги со счетчиками.

Для определения пороговых значений для сети выполните эти шаги:

  1. Выберите объекты.

  2. Выберите устройства и интерфейсы.

  3. Определите пороговые значения для каждого объекта или объекта/типа интерфейса.

  4. Определите степени серьезности ошибки для события, генерируемого каждым порогом.

Достаточное количество работы требуется для определения что пороги использовать на который объекты (и для который устройства и интерфейсы). К счастью, при сборе базовых показателей производительности данных вы уже сделали значительную часть той работы. Кроме того, NSA и программа сервиса высокой доступности (HAS) могут сделать рекомендации, которые помогают вам устанавливать объекты и создают диапазоны. Однако необходимо адаптировать эти рекомендации для индивидуальной сети.

Поскольку вы собрали производительность данных для сети, программа HAS рекомендует сгруппировать интерфейсы категориями. Это упрощает устанавливающие пороги, потому что вы, возможно, должны были бы определить пороги для типа носителя каждой категории, а не для каждого устройства и объекта на том устройстве. Например, вы хотели бы установить другие пороги для Ethernet и сети FDDI. Обычно считается, что можно выполнить сети FDDI в ближе к 100%-му использованию, чем вы можете сегмент общего канала Ethernet/. Однако полнодуплексный Ethernet может быть выполнен намного ближе к 100%-му использованию, потому что они не подвергаются коллизиям. Вы могли бы хотеть установить пределы коллизий очень низко для полнодуплексных каналов, потому что вы никогда не должны видеть коллизию.

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

Группировка и категоризация сетевых устройств и интерфейсов не могут быть слишком подчеркнуты. Чем больше вы в состоянии сгруппировать и категоризировать, тем проще можно интегрировать пороговые события в платформу управления сетью. Используйте базовые показатели в качестве основного ресурса для этой информации. Обратитесь к Управлению мощностью и производительностью: Описание технологических решений Оптимальных методов для получения дополнительной информации.

Внедрение управления сетью

Организация должна иметь систему управления реализованной сети, которая в состоянии обнаружить значения определенного порога и отчёт относительно значений для указанных периодов времени. Используйте систему управления сетью RMON, которая может заархивировать пороговые сообщения в файле журнала для ежедневного анализа или более завершенного решения для базы данных, которое позволяет поиски пороговых исключений для данного параметра. Информация должна быть доступна штату функционирований сети и менеджеру на постоянной основе. Внедрение управления сетью должно включать возможность обнаружить сбои программного обеспечения/аппаратных средств или обратные трассировки, интерфейсную надежность, ЦПУ, использование соединения, очередь или буферные неудачи, объем широковещания, переходы несущей и интерфейсный сброс.

Метрики функционирований сети

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

  • Количество проблем, которые происходят приоритетом вызова

  • Минимум, максимум, и среднее время для закрытия в каждом приоритете

  • Обзор проблем типом проблемы (аппаратные средства, сбой в программном обеспечении, конфигурация, питание, ошибка пользователя)

  • Отказ времени для закрытия для каждого типа проблемы

  • Доступность группой доступности или SLA

  • Как часто вы встретили или пропустили требования SLA

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

Индикаторы управления производительностью

Показатели эффективности предоставляют механизм, с помощью которого организации измеряют критические факторы успеха.

Задокументируйте бизнес - цели сетевого управления

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

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

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

  • Определите комплексный план с достижимыми целями.

  • Определите каждый бизнес-сервис / приложение, которые требуют сетевой поддержки.

  • Определите те метрики на основе производительности, должен был измерить сервис.

  • Запланируйте набор и распределение данных метрики быстродействия.

  • Определите поддержку, необходимую для оценки сети и обратной связи с пользователями.

  • Задокументировали, детализировали, и цели уровня измеряемого обслуживания.

Задокументируйте соглашения об уровне обслуживания

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

SLA "живут" документы, потому что деловая среда и сеть являются динамичными по своей природе. Что работает сегодня для измерения, SLA мог бы стать устаревшим завтра. Только то, когда они устанавливают петлю обратной связи от пользователей и действуют на ту информацию, может функционирования сети поддерживать количество высокой доступности, требуемое организацией.

Создайте список переменных для базовых показателей

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

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

  • Реактивные проблемы могут часто решаться быстрее с базой данных за прошлые периоды.

  • Создание отчетов производительности и планирование мощности требуют этого типа данных.

  • Цели уровня обслуживания могут быть измерены против него.

Рассмотрите исследования тенденций и базовые показатели

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

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

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

Проводите эти отзывы каждые две недели и проводите более полную аналитическую встречу каждые шесть - двенадцать недель. Эти совещания позволяют вам решать и краткосрочные и долгосрочные проблемы.

Задокументируйте методологию анализа возможных вариантов

Анализ возможных вариантов включает моделирование и подтверждение решений. Перед добавлением нового решения сети (или новое приложение или изменение в Cisco IOS Release), документ некоторые альтернативы.

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

Задокументируйте Методологию, используемую для Производительности Повышения производительности сети

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

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

Сводка

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

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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 15115