Что такое сетевая инфраструктура
Сетевая инфраструктура.
в Интернет 26.02.2019 0 204 Просмотров
Сетевая инфраструктура – это взаимосвязанная группа компьютерных систем, связанных различными частями телекоммуникационной архитектуры. В частности, эта инфраструктура относится к организации различных её частей и их конфигурации – от отдельных сетевых компьютеров до маршрутизаторов, кабелей, точек беспроводного доступа, коммутаторов, магистралей, сетевых протоколов и методологий доступа к сети. Инфраструктура может быть открытой или закрытой, например открытая архитектура Интернета или закрытая архитектура частной интрасети. Они могут работать по проводным или беспроводным сетевым соединениям или с комбинацией того и другого.
Самая простая форма сетевой инфраструктуры обычно состоит из одного или нескольких компьютеров, сети или подключения к Интернету, а также концентратора для соединения компьютеров с сетевым подключением и привязки различных систем друг к другу. Концентратор просто связывает компьютеры, но не ограничивает поток данных в одну систему или из неё. Чтобы контролировать или ограничивать доступ между системами и регулировать поток информации, коммутатор заменяет концентратор для создания сетевых протоколов, которые определяют, как системы взаимодействуют друг с другом. Чтобы позволить сети, созданной этими системами, обмениваться данными с другими через сетевое соединение, требуется маршрутизатор, который соединяет сети и в основном обеспечивает общий язык для обмена данными в соответствии с правилами каждой сети.
Когда несколько компьютеров в одном доме совместно используют одно и то же подключение к Интернету, считается базовой формой сетевой инфраструктуры, независимо от того, обмениваются ли компьютеры информацией друг с другом или нет. Интернет сам по себе является более продвинутой сетевой инфраструктурой, в которой отдельные системы получают доступ к глобальной сети, в которой хранится информация о различных системах и которая позволяет получать доступ с помощью веб-стандартов и протоколов, чаще всего в виде веб-адресов, также называемых URL-адресами.
Офисные интрасети аналогичны глобальной сети Интернет, но работают в закрытой сетевой инфраструктуре, доступной только тем, кто находится в ней. Как правило, она состоит из центрального хранилища данных – одного или нескольких компьютеров, называемых серверами – а также кабельных сетей Ethernet, точек беспроводного доступа, маршрутизаторов, коммутаторов и отдельных компьютеров с доступом к центральному хранилищу данных. Отдельные компьютеры подключаются к сети через кабельный или беспроводной доступ. Маршрутизаторы и коммутаторы затем определяют, какой уровень доступа им разрешен, и выступают в качестве распределителей трафика, чтобы направить их в центральное хранилище данных на серверах. Когда отдельные компьютеры отправляют или получают данные, маршрутизаторы гарантируют, что они достигнут нужного места.
При построении сетевой инфраструктуры безопасность сети часто является главной задачей. В большинстве архитектур используются маршрутизаторы со встроенными межсетевыми экранами, а также программное обеспечение, позволяющее точно настроить управление доступом пользователей, выполнить мониторинг пакетов данных и строго определенные протоколы. Безопасность также можно контролировать, настраивая свойства общего доступа к сети в отдельных системах, что ограничивает доступ к папкам и файлам, которые могут увидеть другие пользователи в сети.
Изящные и безотказные сетевые решения
Сетевые решения
Сетевая инфраструктура – совокупность оборудования и программного обеспечения, которая создает среду для процесса обмена информацией, работы приложений и различных сервисов.
Телекоммуникационная инфраструктура сегодня – это фундамент IТ-инфраструктуры, основа для бизнес-коммуникаций современной компании, обеспечивающая надежные, простые в использовании, безопасные и мобильные сервисы, необходимые для успешного существования и динамичного развития компаний.
Сетевые инфраструктурные решения, предлагаемые «Инфосэл», помогают компаниям добиться своих целей при развертывании высокопроизводительных сетей благодаря функциям, которые обеспечивают новый уровень безопасности, доступности, производительности и простоты в эксплуатации. Платформы маршрутизации, коммутации и безопасности выбираются с целью предоставить пользователям филиалов, региональных офисов, центральных учреждений и центров обработки данных доступ к критически важным приложениям и сервисам в режиме реального времени.
Специалисты компании «Инфосэл» имеют огромный опыт по реализации комплексных сетевых решений в области построения сетей любой сложности, гарантируя надежность, отказоустойчивость и качество развернутой сетевой инфраструктуры. Компания «Инфосэл» предлагает широкий спектр профессиональных услуг, охватывающих весь жизненный цикл реализуемых компанией сетевых инфраструктур, начиная с предпроектной стадии создания, заканчивая вводом системы в эксплуатацию и последующим сопровождением.
Сетевая инфраструктура
Анализ сетевой инфраструктуры
Вначале нужно разобраться в том, что представляет собой инфраструктура сети предприятия. Сегодня в каждой компании очень важно качественно и оперативно реагировать на развитие рынка. Именно поэтому в организации должен присутствовать отлаженный механизм такого реагирования. На уровень управляемости компании влияет то, насколько профессионально в ней работают с информацией – собирают, обрабатывают, хранят данные, которые необходимы для решения поставленных задач. Для этого необходимо должным образом организовать информационную систему.
Основой информационной системы является сетевая инфраструктура. Когда в организации больше одного ПК, но нет объединяющей такие ПК сети, то возникает огромное количество разнообразных проблем. Они связаны с поиском, с передачей информации, ее восстановлением, с невозможностью использовать данные в условиях, отличных от офиса, с одновременной работой с другими документами, с подключением к интернету периферийным оборудованием. Но если правильно организовать и эксплуатировать объекты сетевой инфраструктуры, то такие проблемы легко решаются.
Компоненты сетевой инфраструктуры представлены следующими составляющими. Это локальная сеть, которая включает в себя локальное обеспечение различных аппаратных средств, объединенных одной платформой, активное оборудование в виде коммутаторов, маршрутизаторов, конверторов интерфейсов. Также сюда входят пассивные устройства, представляющие собой кабель, розетки, монтажные шкафы, кабельные каналы. Не в последнюю очередь это может быть периферийное оборудование, компьютерное оборудование в виде серверов, копиров, сканеров, рабочих станций и т. д.
Одним из главных составляющих сетевой инфраструктуры является локальная вычислительная сеть. Она объединяет вычислительные, локальные ресурсы и разделяет доступ к ним. Чтобы объединить пользователей такой сети, расположенных в различных помещениях, с разными рабочими станциями, используются специальные устройства по типу коммутаторов и маршрутизаторов. Используются возможности такой сети одновременно, то есть, независимо от того, где расположены рабочие места. Надежность, производительность такой сети (кабельной, беспроводной) зависит от того, какие были использованы технологии, сетевое программное обеспечение, активное оборудование.
Эксплуатация технических средств сетевой инфраструктуры
Чтобы сформировать базу сетевой инфраструктуры для эффективного, безопасного использования информации, применяются различные сетевые сервисы. Благодаря этому можно обеспечить надежность и доступность каждого ресурса организации. Эффективность бизнеса будет зависеть от того, насколько простым и удобным будет доступ пользователей к сервисам, к системам различных видов связи, к разным унифицированным коммуникациям. Защита сетевой инфраструктуры тоже имеет огромное значение. При чрезвычайных ситуациях можно потерять не только оборудование, но и информацию. Подобные ситуации могут угрожать целостности бизнеса. Требуются специальные программы, которые восстанавливают целостность сетевой инфраструктуры. Планирование различных чрезвычайных ситуаций входит в планирование сетевой инфраструктуры и часто осуществляется на стадии разработки ИТ компании. Также в случае возникновения чрезвычайных ситуаций применяется горячее оборудование, используемое в качестве запасного оборудования. Кроме того, существует холодное оборудование, которое требует подготовки для того, чтобы запустить его в работу.
Зачем нужен мониторинг сетевой инфраструктуры?
Когда в компании небольшой ИТ отдел, то обслуживанием сервисов, серверов, различного оборудования занимается один администратор. Каждый день он должен проверять рабочие станции, доступность сайтов, серверы, сетевое оборудование, отправлять отчеты, строить графики. Также специалист должен выполнять анализ сетевой инфраструктуры предприятия, чтобы правильно конфигурировать, осуществлять поддержку СИ. Именно поэтому требуется проводить аудит, чтобы вся информация в этой области могла быть актуальной.
Аутсорсинг сетевой инфраструктуры
Создание качественной ИТ инфраструктуры и ее обслуживание – это обязательное условие для успешного бизнеса. Сетевая инфраструктура становится сложнее, включает в себя множество ПО, различного оборудования, для чего потребуется много сотрудников. Чтобы снизить расходы на содержание штатных пользователей – специалистов компании, может использоваться аутсорсинг. Благодаря этому сокращаются издержки на содержание инфраструктуры, увеличивается качество обслуживания, снижаются риски проектов.
Сетевая инфраструктура: основные сведения, объекты и проектирование
Программные приложения, аппаратные элементы, маршрутизация, переключения – это основные функции каждой сети. Существуют службы, которые регулируют трафик данных, есть приложения, обеспечивающие сохранность информации. Также не обойтись без дополнительных устройств, представленных шлюзами безопасности. Очень важным моментом является процесс строительства IT-инфраструктуры. Здесь происходит анализ требований в бизнесе и с технической стороны, проектируется логическая архитектура и архитектура развертывания, выполняется внедрение и управление развертыванием.
Мониторинг инженерной инфраструктуры в дата-центре. Часть 4. Сетевая инфраструктура: физическое оборудование
Привет, Хабр! Меня зовут Алексей Багаев, я руководитель сетевого отдела в DataLine.
Сегодня я продолжу серию статей о мониторинге инфраструктуры наших дата-центров и расскажу о том, как у нас организован мониторинг сети. Это достаточно объемная тема, поэтому, чтобы избежать сумбура, я разделил ее на две статьи. В этой речь пойдет о мониторинге на физическом уровне, а в следующий раз рассмотрим логический уровень.
Сначала я опишу наш подход к мониторингу сети, а затем подробно расскажу о всех параметрах сетевого оборудования, которые мы отслеживаем.
Наш подход
Наша практика «мониторинга всего» длится уже более пяти лет. В каких-то областях мы не изобретаем велосипед и действуем стандартными методами, а где-то, в силу специфики, прибегаем к своим решениям. В частности, это касается мониторинга логического уровня сети, но, как я сказал ранее, это тема уже будущей статьи.
В случае с опросом физического уровня сети всё достаточно просто. Система мониторинга сетевой инфраструктуры построена на базе Open-source инструментов Nagios и Cacti. На всякий случай напомню их различия: Nagios регистрирует события в реальном времени, а Cacti агрегирует статистику, строит графики и отслеживает динамику показателей в долгосрочной перспективе.
Состояние сетевого оборудования отслеживается через запросы по стандартному протоколу SNMP:
запрос сервер–агент: GetRequest и агент–сервер: Trap.
В ОС всего управляемого сетевого оборудования есть MIB-базы. Нужный OID объекта, как правило, мы находим с помощью команды SNMPWalk или с помощью инструмента MIB Browser. Вы можете пройти по этой ссылке на англоязычную ветку Reddit, в комментариях есть несколько толковых рекомендаций на эту тему.
Разумеется, оборудование периодически меняется и модернизируется, и мы дорабатываем систему мониторинга под новые задачи. Прежде чем вводить новый хост в продуктив, параллельно с тестированием мы добавляем этот хост в систему мониторинга и определяем список объектов, которые будем отслеживать.
Мы собираем основные метрики подключенного оборудования, из самого элементарного – это проверка на UP/DOWN.
В целом нас интересуют:
Сеть мониторинга и мониторинг сети
В мониторинге сети мы используем два способа доступа к оборудованию: in-band и out-of-band. Предпочтительнее для нас out-of-band: при такой схеме трафик системы мониторинга не идет по продуктивным линкам, которые используются для предоставления сервисов заказчикам.
Наша сеть мониторинга.
Для мониторинга у нас есть специальная сеть: она подключена выделенными линками к портам на каждом сетевом хосте. Даже если на продуктивных линках возникнут проблемы, мониторинг будет работать без сбоев.
Часто бывает, что проблема на одном линке делает значительную часть сети недоступной для мониторинга. Это усложняет работу службы поддержки и тормозит процесс выявления неисправностей. Схема out-of-band решает эту проблему.
Не ко всем хостам удается подключить out-of-band, и в этих случаях мы используем in-band, когда трафик мониторинга идет вместе с продуктивным. Как ни странно, несмотря на явные недостатки этой схемы, у нее есть свое преимущество – надежность.
Продуктивные линки резервируются протоколами на уровне L2 и L3: при отказе основного линка трафик «переходит» на другой линк. Nagios на это может среагировать флапом сервисов, но служба поддержки останется при мониторинге.
Дальше пойду по порядку по всем узлам мониторинга физического сетевого оборудования.
Состояние сетевых хостов
Мы проверяем доступность хоста отправкой ICMP-запросов на его IP-адреса управления. Как правило, это выделенный IP в сети управления оборудованием.
Раз в минуту хост проверяется запуском плагина check_ping для Nagios. Каждый вызов сопровождается отправкой четырех ICMP-запросов с интервалом в 1 секунду. На скриншоте ниже видно, что последняя проверка прошла с результатом в 0% потерь пакетов. Среднее время отклика RTA (round trip average) составило 2,47 миллисекунды. Это норма.
Проверка состояния хоста. Статус UP: 0% потерь пакетов, среднее время RTA 2,47 мс. UPD:
скриншот изменен, спасибо за правки Tortortor
Как мы понимаем, что возникла неисправность? Разумеется, поручить наблюдение за всеми цифрами простому человеку невозможно: инженеры отслеживают состояние оборудования в удобном интерфейсе Nagios. В нем уже заданы проверенные пороговые значения для срабатывания статусов WARNING (приближение к нежелательным показателям) и CRITICAL (критическое превышение порога, требуется вмешательство специалиста).
Внимательно посмотрим на таблицу Performance Data с предыдущего скриншота: колонка Value содержит текущее значение параметра потери пакетов (Packet loss). WARNING выдается при достижении 80% потерянных пакетов от общего количества отправленных, CRITICAL – при 100. Показатель RTA (Round Trip Average), равный 2,47 мс, означает среднее время отклика. Предупреждение будет выдано при достижении 3 мс, критическое пороговое значение установлено на 5 мс.
На этом же экране можно получить краткую сводку по следующим показателям:
Температурные показатели
Недавно мои коллеги рассказывали о мониторинге холодоснабжения в машинных залах, где упомянули, что на каждый холодный коридор приходится по три температурных датчика. Эти датчики снимают общие показатели по коридору и позволяют судить о работе самой охлаждающей системы.
Для мониторинга сетевой инфраструктуры нужно знать показания температурных датчиков с каждой единицы оборудования. Это позволяет выявлять и устранять не только возможные перегревы хостов, но и определять на ранней стадии локальные перегревы стоек.
Для получения статуса устройства мы отправляем запрос вида snmpwalk | grep и получаем список всех OID по заданным фильтрам.
Запрос температурных показателей маршрутизатора Cisco ASR9006.
Изучив вывод, делаем более детальный запрос:
Делаем запрос параметра Inlet Temperature Sensordie для снятия значения температур.
И еще более детальный:
Выбираем параметры NP1 и NP2.
В итоге мы получаем OID 1.3.6.1.4.1.9.9.91.1.1.1.1.4.index и можем отследить показания нужного температурного датчика. На нашем примере – значение 590, т. е. 59 градусов по Цельсию.
В графическом представлении Nagios результаты опроса выглядят так:
На скриншоте мы видим следующее:
Состояние вентиляторов в коммутаторах
Чтобы оборудование не перегревалось, с помощью системы холодоснабжения нашего дата-центра и системы холодных и горячих коридоров мы обеспечиваем постоянный приток воздуха в стойку из холодного коридора и одновременное «выдувание» нагревшегося воздуха в горячий коридор. Роль «насосов», которые качают воздух через оборудование, выполняют вентиляторы внутри коммутаторов – не путать с вентиляторами на стойках. Мы отслеживаем их статус, чтобы не допустить перегрев оборудования.
Если вентилятор остановится, у нас будет некоторое количество времени на его замену, иначе оборудование может пострадать.
Чтобы получить актуальный статус вентилятора, делаем запрос, аналогичный приведенному выше:
iso.3.6.1.4.1.9.9.117.1.1.2.1.2.24330783 = INTEGER: 2
Ответ 2 означает ON. Вентилятор работает, Nagios не паникует.
Так отображается состояние вентиляторов в Nagios.
Небольшая ремарка: при настройке систем мониторинга наши специалисты в качестве пороговых используют значения, полученные при тестовых нагрузках и «краш-тестах». Выход из «нормального» диапазона предупреждает о надвигающейся проблеме, и у нас есть время на «гладкое» устранение неисправности. При этом во многих случаях в режиме реального времени нам достаточно простой индикации «работает/не работает».
Состояние модулей питания
Этот показатель весьма очевиден и не нуждается в комментариях. Упомянем только, что система оповещений сообщит нам о неисправности и/или отсутствии питания в самих блоках питания сетевого оборудования.
Если питание пропадет, дежурная служба быстро разберется, в чем причина. Это может быть проблема с кабелем питания, отсутствие питания на этом вводе или проблема непосредственно с самим блоком. Получив оповещение, инженер предпримет меры и восстановит штатный режим работы оборудования.
OID модулей питания: 1.3.6.1.4.1.9.9.117.1.1.2.1.2.index
Отправляем запрос и получаем статус: iso.3.6.1.4.1.9.9.117.1.1.2.1.2.53196292 = INTEGER: 2
Модуль питания в порядке.
Так состояние модулей питания отслеживается в Nagios.
Состояние портов
Для отслеживания магистральных и абонентских подключений мы мониторим следующие параметры:
Чтобы проверить операционный статус порта, производим стандартный запрос по OID.
Вводим OID нужного порта: 1.3.6.1.2.1.2.2.1.8.ifindex
Получаем ответ: iso.3.6.1.2.1.2.2.1.8.1073741829 = INTEGER: 2
Визуализация ответа в Nagios.
Если порт оптический, проверяем уровень сигнала на оптике.
1. Проверяем исходящий сигнал:
OID: 1.3.6.1.4.1.9.9.91.1.1.1.1.4.txindex
Ответ: iso.3.6.1.4.1.9.9.91.1.1.1.1.4.6869781 = INTEGER: 8580
2. Затем проверяем входящий сигнал:
OID: 1.3.6.1.4.1.9.9.91.1.1.1.1.4.rxindex
Ответ: iso.3.6.1.4.1.9.9.91.1.1.1.1.4.63630989 = INTEGER: 2499
Расшифрую цифры в примерах выше. Запрос возвращает нам значение в миллиВаттах и показывает четыре знака после запятой. То есть показатели выше означают 0,8 мВт и 0,2 мВт. Далее встроенная функция шаблона Cacti преобразует значение в дБм (Децибел-миллиВатт).
Статистика по уровням затухания на оптических линках полезна при анализе проблем в сети. Cacti позволяет увидеть динамику ухудшения характеристик и найти причину проблем на линке.
У нас был необычный случай с сигналом на одной из оптических трасс. На графике ниже виден провал в уровне приема оптического сигнала. Этот провал длился целую неделю, но потом уровень резко «отскочил» в нормальное состояние. Что это могло быть, нам остается только догадываться. Возможно, какой-то подрядчик проводил работы в телефонной канализации, а потом по-тихому все вернул на место.
Статистика сигнала на оптической трассе в Cacti.
Еще один очень важный параметр – пропускная способность (скорость) портов. Нам необходимо в режиме реального времени получать информацию о степени загруженности сетевых линков.
Эта метрика позволяет нам планировать трафик и управлять мощностями сети. Кроме того, имея статистику о пропускной способности линков, мы можем проанализировать последствия DDoS-атаки и принять меры по уменьшению влияния DDoS-атак в будущем.
Чтобы получить сводку о количестве принятых и отправленных пакетов информации, снова используем запросы:
OID: 1.3.6.1.2.1.31.1.1.1.6.ifindex
Ответ: iso.3.6.1.2.1.31.1.1.1.6.1073741831 = Counter64: 109048713968
2. Отправленные пакеты
OID: 1.3.6.1.2.1.31.1.1.1.10.ifindex
Ответ: iso.3.6.1.2.1.31.1.1.1.10.1073741831 = Counter64: 67229991783
Цифры, полученные в запросах выше, – это количество байт. Разница в этих значениях за N секунд/N и есть пропускная способность в байтах. Если умножить на восемь, получим бит/с. Т.е. мониторинг запрашивает раз в минуту значение, сравнивает его с предыдущим, вычисляет разницу между двумя значениями, переводим байт в бит и получаем скорость бит/с.
График скорости передачи данных в Cacti.
Нередко у наших абонентов возникает деградация каналов Интернет из-за переполнения выделенной для них полосы пропускания. Трудно сходу определить причину деградации: симптом на стороне абонента – частичная потеря пакетов. Для быстрого распознавания этой проблемы в Nagios мы выставляем пороги срабатывания на полосу пропускания каждого абонентского канала.
В дашборде Nagios это выглядит так:
Превышение порога скорости 80 Гбит/с на 100-гигабитном канале считается опасным, в таких случаях мы принимаем меры по разгрузке канала либо расширяем его. Помните, всегда нужно оставлять «пространство для маневра», т.е. свободную полосу пропускания на случай быстрого роста трафика. Это может быть пик посещаемости ресурса, бэкап или, в худшем случае, DDoS.
Наконец, для каждого порта мы мониторим ошибки. Используя статистику по ошибкам, мы локализуем и устраняем проблему.
1. Узнаем количество полученных пакетов с ошибками:
OID: 1.3.6.1.2.1.2.2.1.14.ifindex
Ответ: iso.3.6.1.2.1.2.2.1.14.1073741831 = Counter32: 0
2. Проверяем количество пакетов, которые не были отправлены, т.к. содержали ошибки:
OID: 1.3.6.1.2.1.2.2.1.20.ifindex
Ответ: iso.3.6.1.2.1.2.2.1.20.1073741831 = Counter32: 0
Статистика в Cacti фиксирует количество ошибок при передаче пакетов в секунду.
Показатели Discards In/Out и Errors In/Out на графике – это консолидированные счетчики всех возможных причин, по которым пакет данных мог не передаться протоколам вышестоящего уровня.
Чтобы отслеживать ошибки и узнавать о проблемах с линками, в Nagios предусмотрена система оповещений по каждому OID. Однако ошибки не всегда можно оперативно отследить, поэтому для своевременного оповещения дежурных инженеров в Nagios дополнительно настроен сервис мониторинга ошибок на портах.
Так выглядит проверка на наличие ошибок на портах в Nagios.
Пожалуй, это все ключевые метрики портов, которые мы мониторим.
Упомяну только об одном важном моменте: при перезагрузке коммутатора с операционной системой Cisco IOS, например Cisco Catalyst 6500, меняется соответствие «порт-ifindex». Это неизбежно приводит к необходимости перенастройки SNMP-запросов в системе мониторинга. Для закрепления значений индекса интерфейса (ifindex) нужно ввести команду snmp ifmib ifindex persist в глобальном режиме IOS, тогда после перезагрузки ifindex в MIB останутся неизменёнными.
Состояние процессоров
Загрузка процессора, приближенная к 100%, может негативно повлиять на здоровье сетевого хоста или сети в целом. Это тот случай, когда мы должны мгновенно узнавать о превышении допустимых порогов. Для этого, как вы уже поняли, мы используем Nagios. Изучая графики из Cacti и наблюдая за системой в реальном времени, мы понимаем тренды и цикличность работы процессоров. Все это помогает инженерам находить и обезвреживать проблемы до того, как они скажутся на работе сети.
Производим запрос состояния процессора сетевых устройств:
OID: 1.3.6.1.4.1.9.9.109.1.1.1.1.7.index
Ответ: iso.3.6.1.4.1.9.9.109.1.1.1.1.7.2098 = Gauge32: 2
Получаем значение загрузки CPU в минуту.
Состояние загрузки процессора в Nagios.
Открываем подробную информацию о состоянии процессора. Снова обратим внимание на пункт Performance Data на скриншоте ниже. Он содержит информацию о текущей загрузке процессора и пороговые значения. Текущая загрузка составляет 3%. Предупреждение система выдаст при загрузке 50% и даст сигнал CRITICAL при 70% загруженности.
Подробная информация о состоянии процессора. Все показатели в норме.
Control Plane Policy: влияние трафика на загрузку процессора
Этот показатель дополняет рассмотренную выше базовую информацию о загрузке процессора. Часть входящего трафика проходит обработку процессором, и мы отслеживаем его тип и количество отдельно. Повышенную загрузку CPU может вызвать как DDoS-атака, так и вполне валидный трафик (ICMP-, ARP-запросы и т.д.), которого просто слишком много.
Обрабатывая чрезмерное количество данных, любой процессор может загрузиться «под завязку» и не сможет обрабатывать служебный трафик, например протоколы маршрутизации — routing updates или hello/keepalive-пакеты. Соответственно, взаимодействие с соседним сетевым оборудованием прекратится, и сервис деградирует или упадёт.
Вот реальный пример:
Скорость потока пакетов протокола маршрутизации IPv6.
График загрузки CPU.
На графиках видно, как пакеты протокола маршрутизации IPv6 начинают «подгружать» CPU коммутатора. Этот факт можно не заметить своевременно и при увеличении потока IPv6-пакетов получить весьма болезненный инцидент на сети.
С помощью стресс-тестов на сетевом оборудовании мы определили, какой трафик по типу и количеству приводит к проблемам на сетевых устройствах, и установили на control plane policing оптимальные пороговые значения для каждого из них. Графики ниже показывают скачки значений выше пороговых.
Пример мониторинга CoPP (control plane policing) на одном из коммутаторов в продуктиве:
Количество бит в секунду пакетов трафика. ICMP, идущие в обработку на CPU.
Пакеты UDP.
Наблюдая за этими показателями, мы можем предупреждать повышенную нагрузку на процессор и сохранять стабильность сети. Как и в случае с остальными данными мониторинга, мы собираем историю с помощью Cacti и отображаем текущую ситуацию на мониторах с помощью Nagios.
Мониторинг оперативной памяти
Одна из самых опасных ситуаций в случае с оперативной памятью – утечка (memory leak). Предупреждать и устранять ее важно своевременно, так как в небольших интервалах (день, неделя) медленное, но неотвратимое уменьшение свободной памяти можно просто не заметить.
Частично решить эту проблему позволяет сбор долгосрочной статистики в Cacti. Мы можем отследить тенденцию к переполнению памяти и запланировать технологическое окно для перезагрузки оборудования. К сожалению, в большинстве случаев это единственный абсолютный метод «лечения» утечки.
Вот еще один пример из жизни нашей сети:
При очередном анализе показателей мониторинга инженеры обнаружили динамику уменьшения объема свободной памяти на одном из коммутаторов. Изменения были почти незаметны на коротких интервалах времени, но, если увеличить масштаб времени, скажем до месяца, появлялся тренд на плавное уменьшение свободной памяти. При заполнении памяти последствия для коммутатора могут быть непредсказуемы, вплоть до странностей в поведении протоколов маршрутизации. Например, часть маршрутов может перестать анонсироваться своему соседу. Или случайным образом начнет отказывать peer-link на системе VSS.
Ситуация, описанная выше, закончилась вполне благополучно. Мы согласовали с клиентами техокно и перегрузили коммутатор.
Итак, продолжим. Графики Cacti помогают определить точное время начала утечки, и, сопоставив логи, мы находим и «лечим» причину.
Делаем запрос загрузки оперативной памяти:
OID: 1.3.6.1.4.1.9.9.221.1.1.1.1.18.index
Ответ: iso.3.6.1.4.1.9.9.221.1.1.1.1.18.52690955.1 = Counter64: 2734644292
Значение указывает количество байтов из пула памяти, используемое операционной системой.
Статистика загрузки оперативной памяти в Cacti.
Дежурный инженер следит за тем, чтобы не было аномальных перепадов или тренда на постоянное заполнение свободной памяти по параметру Memory Usage. График в Cacti показывает память под процессы, ввод/вывод, общую память, количество свободной/занятой памяти.
Текущее значение свободной оперативной памяти коммутатора – выгрузка из Nagios.
В момент создания скриншота было свободно 45503272 байт ОП, установлены пороги срабатывания: для WARNING — в интервале от 35651584 до 39845888 байт, для CRITICAL — от 0 до 35651584 байт.
Небольшой бонус
Напишу пару слов о том, как система мониторинга оповещает нас о нештатных ситуациях.
В нашей собственной «кухне» мы не используем дополнительные email- или SMS-оповещения, так как дежурные инженеры отлично справляются с мониторингом показателей на экранах. Исключение составляют отдельные критичные показатели, об изменениях которых нам нужно узнавать незамедлительно и вне зависимости от человеческого фактора. Для этих показателей мы настраиваем e-mail- или SMS-рассылку. По желанию клиента мы можем настроить отдельные оповещения на каждое срабатывание. Здесь всё индивидуально. Когда какой-либо параметр в Nagios достигает состояния hard, система оповещает заказчика через тот канал, который мы для этого настроим.
И еще одна мелочь, но приятная. Система мониторинга не только позволяет быстро реагировать на события, но и помогает дежурным оперативно устранить проблему. Делаем мы это, размещая ссылку на инструкцию на хост или сервис Nagios:
Ссылка на ресурс с инструкцией находится под значком «красная книжка» (View Extra Host Notes), в качестве базы знаний с инструкциями мы используем Redmine. Дежурный может перейти по ссылке и уточнить последовательность действий для устранения неисправности. Слева на скриншоте есть картинка в виде телефона, по ней можно узнать ответственное за этот сервис подразделение, и, в случае затруднений, эскалация инцидента происходит именно на это подразделение производственной дирекции.
В заключение хочу обратить ваше внимание на довольно-таки критическую уязвимость SNMP-протокола (версий 1, 2c и 3) в операционных системах Cisco IOS и XE. Уязвимость позволяет злоумышленнику получить полный контроль над системой или инициировать перезагрузку операционной системы атакуемого хоста. Компания Cisco анонсировала уязвимость 29 июня 2017 г., а закрыта она была в новых релизах ПО, вышедших после середины июля. Если не получается по каким-либо причинам обновить софт, как временное решение Cisco рекомендует отключить следующие MIB-базы: