Централизуем управление сетью
Если по роду своей деятельности вы являетесь сетевым или ИТ-администратором, то наверняка вам приходилось сталкивались с ситуациями, когда существующим программным и аппаратным техническим решениям, находящимся в эксплуатации, недостаёт прозрачного, интуитивно понятного, централизованного средства управления, отладки и мониторинга.
Что бы ни придумывали разработчики систем управления сетевой инфраструктурой в попытке предоставить техническому персоналу удобный инструмент с графическим интерфейсом, который заменил бы собой все другие средства управления, по сей день рабочей лошадкой «сетевой братии» остаётся всем уже давно знакомый и привычный CLI (она же командная строка). Здесь я не буду рассматривать небольшие решения, вроде домашних роутеров или коммутаторов для SMB, поскольку они изначально не предполагают широкий выбор поддерживаемых технологий и протоколов, и простого web интерфейса там вполне достаточно (хотя какой-никакой CLI есть и на них). Речь скорее идёт о комплексных распределенных сетях, включающих многоуровневую архитектуру, логическую и физическую сегментацию, географическое распределение, а также разнородность представленных производителей оборудования. На мой взгляд причина тому далеко не одна:
— большинство с уществующих платформ управления, мониторинга, отладки не даёт той полноты функциональных возможностей, которыми наделена командная строка. Какие-то системы более продвинуты, какие-то менее, но в целом необходимость зайти в CLI и что-то вбить вручную остаётся всегда;
— даже в небольших сетях можно встретить целый «зоопарк» из названий производителей железа и их моделей (особенно это часто встречается в компаниях, работающих достаточно давно без внятной ИТ-политики управления). С другой стороны мы видим, что каждый производитель стремится ограничить конечных пользователей использованием именно своего оборудования, а потому никакой речи о мультивендорной поддержке систем управления не идёт;
— существующие сети передачи данных достигли той ступени развития, когда даже хорошо спроектированные и построенные сети изобилуют таким количеством различных протоколов и технологий (особенно с начала бурного строительства центров обработки данных и развития виртуализации вычислительных ресурсов), что найти подходящий программный продукт для соответствия всем задачам и требованиям крайне сложно;
— постепенное исчезновение чёткой грани между традиционной сетью передачи данных и вычислительными средами по мере развития технологий виртуализации. Примерами могут служить такие протоколы, как OpenFlow или VEPA. А поскольку распределение зон ответственности между «сетевиками» и «серверистами», как правило, всегда вполне понятны и определены, не совсем ясно для кого писать и как позиционировать конечный продукт;
— как централизовать управление различными функциональными сегментами сети — остаётся вопросом открытым: беспроводная сеть управляется через одно приложение, политики безопасности и ныне крайне популярный BYOD реализуются через другое, оркестрация среды ЦОДа через третье…
Подобных аргументов можно найти ещё много, но все они будут так или иначе сводится к вышеописанным. Как можно реализовать через одно окно функции конфигурации, мониторинга, управления, поиска и устранения проблем для проводной и беспроводной инфраструктуры, ресурсов ЦОД, удалённых площадок, сетей SDN и MPLS?
Компания HP традиционно придерживалась/придерживается принципа открытых архитектур и использования стандартизованных решений и протоколов, поэтому при выборе стратегии развития собственной системы управления был взят курс на централизацию управления всеми функциональными подсистемами сетевой среды, обеспечивая поддержку широкого спектра оборудования от разных производителей. Модель развития продукта предусматривает гомогенную архитектуру, где функционал не распыляется по нескольким отдельным друг от друга продуктам, которые требуют самостоятельного администрирования. Мы стремимся объединить весь набор инструментов для управления различными сетями в единый, удобный и понятный интерфейс.
Дать исчерпывающую информацию по данному продукту в рамках одной статьи дело практически невыполнимое, поэтому я бы хотел начать с вопросов, связанных прежде всего с проектированием и развёртыванием системы управления, общими вопросами по выборе модели и архитектуры, которые позволят не ошибиться в стратегическом плане. Последующие статьи обязательно будут посвящены глубокому разбору функциональных возможностях с примерами практического применения.
Итак, что же такое IMC? Это модульное программное средство, которое реализует функции FCAPS (Fault, Configuration, Accounting, Performance, Security), а отбросив маркетинговые аббревиатуры, попросту позволяет централизованно управлять сетевой инфраструктурой, производить поиск и отладку проблем, осуществлять мониторинг различных сервисов и ресурсов, создавать и применять различные политики, а также формировать различную отчётную информацию.
Краткий список поддерживаемых функций выглядит следующим образом:
• автоматическое обнаружение и определение сетевых устройств; • автоматическое построение топологий L2 и L3, IRF, LLDP-MED, виртуальных сетей VMware и Hyper-V, а также их кастомизация; • графическое отображение и управление протоколами xSTP; • управление аварийными событиями, их корреляция; • генерация статистики и отчётной документации; • генерация различных графиков и анализ производительности сети; • управление списками доступа ACL; • управление виртуальными сетями VLAN; • управление конфигурациями и программным обеспечением сетевых устройств; • мониторинг в реальном режиме времени; • распределение задач по ролям; • управление гостевым доступом; • наличие мобильного клиента под Android и iOS
и многое, многое другое.
На сегодняшний день 7-я версия является наиболее актуальной. В ней был полностью переработан пользовательский интерфейс (теперь практически все модули используют HTML5), добавлены множество новых и полезных функций в базовую платформу, такие как поддержка MDC, VCF, ISSU, динамическая прорисовка топологий, добавлены новые модули, UI для мобильных устройств, стала более удобной и понятной схема лицензирования. Список изменений очень большой, поэтому лучше почитать соответствующий release note, которые прилагается к файлу с дистрибутивом IMC.
Дистрибутив доступен для скачивания и позволяет использовать приложение бесплатно в режиме trial в течение 60 дней, после чего потребуется либо ввести лицензию, либо переустановить с нуля.
Версии IMC
На данный момент доступно 6 версий для скачивания:
• Standard• Enterprise• Basic• Basic WLAN Manager• Smart Connect• Smart Connect with WSM Virtual Appliance
В большинстве случаев вам подойдут версии либо Standard, либо Enterprise, поскольку обе они, помимо функций базовой платформы, предлагают серьёзное расширение функционала путём установки дополнительных модулей (о которых я расскажу чуть позже). Обе версии включают в себя лицензию на 50 устройств. Можно говорить о том, что один IP адрес устройства в IMC равен одной лицензии. Если с коммутаторами, маршрутизаторами, контроллерами, файрволлами всё более ли менее понятно, то как быть с кластерами из нескольких устройств (например, стек из коммутаторов или маршрутизаторов с объединёнными control plane). Поскольку IP адрес для управления один на весь стек, то и лицензия будет использована одна.
Также обе версии позволяют использовать иерархическую модель установки, о которой я также упомяну далее, и наращивать количество устройств, управляемых через IMC. При максимальных аппаратных ресурсах сервера можно управлять до 15000 устройств с одной платформы.
В чём Enterprise лучше Standard:
• Модуль NTA (Network Traffic Analyzer) и лицензия на 5 устройств для него идут вместе с основной платформой IMC• Доступен eAPI для написания собственных скриптов и разработки собственных расширений и кастомизации• Может быть Master«ом в иерархической модели внедрения
Вкратце, Enterprise ориентирован на очень крупные модели применения в больших распределённых сетях; Standard соответствует требования предприятий среднего уровня.
Перед установкой
Рассчитать минимальные аппаратные вычислительные ресурсы можно на основе нижеприведённых таблиц:
Разрядность ОС Количество устройств Количество единиц сбора* Количество операторов онлайн Кол-во ядерCPU** Объём памяти Размер памяти дляJava Объём жесткого диска для установки Объём жесткого диска для эксплуатации 32 бита 0 — 200 0 -5К 20 2 4 Гб 512 Мб 3 Гб 30 Гб 5К -50К 10 60 Гб 200 — 500 0 — 10К 30 4 6 Гб 1 Гб 3 Гб 50 Гб 10К — 100К 10 100 Гб Разрядность ОС Количество устройств Количество единиц сбора* Количество операторов онлайн Кол-во ядерCPU** Объём памяти Размер памяти дляJava Объём жесткого диска для установки Объём жесткого диска для эксплуатации 64 бита 0 — 200 0 -5К 20 2 4 Гб 2 Гб 3 Гб 30 Гб 5К -50К 10 60 Гб 200 — 500 0 — 10К 30 4 8 Гб 2 Гб 3 Гб 50 Гб 10К — 100К 10 100 Гб 1К — 2К 0 — 20К 30 6 12 Гб 4 Гб 4 Гб 60 Гб 20К-200К 10 200 Гб 2К — 5К 0 — 30К 40 8 24 Гб 8 Гб 5 Гб 80 Гб 30К — 300К 20 250 Гб 5К — 10К 0 — 40К 50 16 32 Гб 12 Гб 7 Гб 100 Гб 40К — 400К 20 300 Гб 10К — 15К 0 — 40К 50 24 64 Гб 16 Гб 10 Гб 200 Гб 40К — 400К 20 600 Гб Единица сбора*– представляет собой сбор какой-либо статистики за 5 минут. Например, если мониторим загрузку физического интерфейса исходящим трафиком раз в 1 минуту, то считается, что используем 5 единиц сбора. Если же будем замерять исходящий + входящий трафик, тогда 10 единиц сбора.CPU** — под ядром CPU понимаются физические ядра, а не виртуальные.
Данные требования распространяются только на саму платформу IMC без учёта дополнительных модулей.
На данный момент поддерживается инсталляция на следующих операционных системах:
• Windows® Server 2003 with Service Pack 2• Windows® Server 2003×64 with Service Pack 2 and KB942288• Windows® Server 2003 R2 with Service Pack 2• Windows® Server 2003 R2×64 with Service Pack 2 with KB942288• Windows® Server 2008 with Service Pack 2• Windows® Server 2008×64 with Service Pack 2• Windows® Server 2008 R2 with Service Pack 1• Red Hat Enterprise Linux 5• Red Hat Enterprise Linux 5×64• Red Hat Enterprise Linux 5.5• Red Hat Enterprise Linux 5.5×64• Red Hat Enterprise Linux 6.1×64
Также хотелось бы привести список поддерживаемых БД, в случае если понадобиться что-то более производительное и масштабируемое нежели та, что идёт вместе с платформой:
• Microsoft SQL Server 2005 Service Pack 3 (только Windows)• Microsoft SQL Server 2008 Service Pack 3 (только Windows)• Microsoft SQL Server 2008 Service Pack 3 (только 64-bit—Windows 64-bit)• Microsoft SQL Server 2008 R2 Service Pack 1 (только Windows)• Microsoft SQL Server 2008 R2 Service Pack 1 (только 64-bit—Windows)• Oracle 11g Release 1 (только Linux)• Oracle 11g Release 2 (только Linux)• Oracle 11g Release 2 (только 64-bit—Linux)• MySQL Enterprise Server 5.1 (Linux и Windows—до 1,000 устройств)• MySQL Enterprise Server 5.5 (Linux и Windows— до 1,000 устройств)
Также стоит отметить, что HP рекомендует устанавливать IMC на отдельный физический сервер. Впрочем, это не мешает развернуть платформу на «виртуалке» с аналогичными аппаратными характеристиками.
Для увеличения производительности ввода/вывода есть следующие рекомендации:
• Если количество единиц сбора составляет 100 000 — 200 000, рекомендуется использование 2-х или более жестких диска и карта RAID с кэшем 256 Мб или более; • Если количество единиц сбора составляет 200 000 — 300 000, рекомендуется использование 2 или более жестких диска и карта RAID с кэшем 512 Мб или более; • Если количество единиц сбора составляет 300 000 — 400 000, рекомендуется использование 2 или более жестких диска и карта RAID с кэшем 1 Гб или более; • HP рекомендует RAID 5-го уровня, которые требует 3 или более дисков. Если же вы используете более 4-х дисков, рекомендуется использовать уровень RAID 0+1.
Установка
Сам процесс установки занимает порядка 2–3 часов в зависимости от сложности выбранного решения. Здесь я его приводить не буду, поскольку он весьма простой и подобен установке любого приложения под Windows. Также он очень подробно расписан в мануалах, приложенных к самому инсталляционному образу платформы.
Я же хотел бы заострить внимание на концептуальных вопросах, которые помогут вам не ошибиться при проектировании и внедрении платформы.
Централизованное или иерархическое внедрение
Централизованное решение IMC является идеальным решением для инфраструктур с небольшим количеством управляемых узлов, каждый из которых расположены в одном или нескольких зданиях одного города. В таком случае IMC должна быть установлена на выделенный сервер, причём база данных может быть установлена вместе с платформой, либо же на отдельном сервере.
В каких случаях лучше применять централизованное управление:
• Когда количество управляемых с помощью IMC узлов менее 5000• Когда большинство узлов расположены территориально в одном месте• Когда количество единиц сбора не превышает 400 000• Когда кол-во операторов IMC, имеющих одновременный доступ, не превышает 50.
Иерархический способ внедрения отвечает требованиям управления в крупных географически распределённых сетях с большим количеством управляемых узлов. Каждая из IMC платформ работает со своей встроенной либо внешней БД. Оператор, при обращении к child IMC платформе, получает полный доступ к функционалу. В то же время информация по производительности и авариям реплицируется на parent IMC. Стоит отметить, что в роли parent может выступать только версия IMC Enterprise.
В каких случаях лучше применять централизованное управление:
• Когда количество управляемых с помощью IMC узлов более 5000• Когда большинство узлов географически разнесены друг от друга• Когда операторы IMC находятся географически в разных местах• Когда количество единиц сбора превышает 400 000• Когда кол-во операторов IMC, имеющих одновременный доступ, превышает 50.
Карта протоколов IMC
В случае, если на одном из участков сети работают межсетевые экраны, полезно знать по каким протоколам и портам работает IMC.
Варианты обеспечения отказоустойчивости
Платформа IMC включает в себя инструмент DBman, который позволяет автоматически осуществлять резервное копирование и восстановление базы данных, поскольку именно она содержит всю полезную информацию о вашей сети. Также данный инструмент отвечает за бэкап информации сервисных модулей расширения. Вы можете выбрать одну из двух моделей резервного копирования: single system HA или dual system HA.
Single system HA. Это наиболее простая реализация отказоустойчивости, когда БД копируется либо на локальный жесткий диск, либо на внешний сервер.
Dual system HA. Данная модель является наиболее устойчивой к разного рода неприятностям, поскольку мы имеем на деле 2 платформы IMC, которые имеют одинаковый набор функциональных модулей и которые синхронизируют свои базы данных, обеспечивая непрерывную работу системы управления на случай выхода из строя основной копии. Если остановка IMC грозит вашей сети значимыми последствиями в предоставлении сервиса, именно эта модель обеспечения отказоустойчивости должна рассматриваться в первую очередь.
Дополнительную информацию по платформе и модулям для него, различные конфиг и админ руководства можно найти на нашем сайте в соответствующем разделе.
