Привет, Хабр!  Мы провели вместе долгие часы, изучая коммутационное оборудование Eltex для ЦОД: строили фабрику, устраивали ей  пожар  нагрузочное тестирование,  тестировали на совместимость с заморскими вендорами… Не знаю как вы, а я очень устал от всех этих команд, проверок и… страха, что вся конфигурация сбросится, не сохранится, и мне придется набивать всю конфигурацию с нуля. И тут я подумал, ведь у Eltex есть система управления ECCM, заточенная под их оборудование. Почему бы мне параллельно с написанием статей не применить ее, чтобы воспользоваться всем спектром возможностей?

И вот она нарядная, на праздник к нам пришла…

Установка ECCM

Нет, я не буду здесь приводить команды для установки ECCM, для этого Eltex написал весьма неплохую инструкцию. Здесь мы поговорим о процессе.

Что у меня есть? Лабораторный стенд фабрики ЦОД и система виртуализации без доступа к интернету. По идее, развернув ECCM в системе виртуализации и добавив нужные лицензии (которые Eltex предоставил нам для тестирования), я должен получить ожидаемый результат. Прочитав инструкцию по диагонали (да-да, первый раз – именно так), я принял для себя, что в качестве ОС я буду использовать Astra Linux, так как она отлично ложится под концепцию импортозамещения и поддерживается производителем.

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

Сам ECCM разворачивается в Docker и использует сопутствующие контейнеры (например, для СУБД), и я смог, не обладая достаточными знаниями в области контейнеризации и в Linux, настроить и даже запустить Web-страницу входа.

Что у нас есть, как говорится, out-of-the-box? В системе уже есть демо-лицензии для 1 устройства каждой модели, а значит, 1 Spine и 1 Leaf я уже могу добавить (да что там говорить – я уже добавил!). Но мне нужно управлять 4-мя коммутаторами Leaf (MES5410-48) и 3-мя коммутаторами Spine (MES5500-32). Берем лицензии от Eltex и… «укажите, откуда брать лицензии?». Да, для сервера ECCM нужно указать адрес сервера лицензий ELM (Eltex License Manager). Гуглим про ELM.

Сервер ELM бывает 3-х типов: публичный адрес в интернете, On-Premise сервер и виртуальная машина. Интернет – не наш вариант (у нас нет доступа), аппаратный сервер нам тоже не подарили ☹ , остается виртуалка «ELM offline».

Сервер лицензий ELM также разворачивается на Astra Linux и запускается в контейнере. Получаем доступ, пытаемся загрузить лицензии… «Вставьте токен с сертификатом». Так вот что за коробочку мне сегодня привез курьер прямо из Новосибирска!

Вы когда-нибудь прокидывали токен с ESXi хоста в виртуальную машину? Нет, это не USB – это токен! Когда мне удалось это сделать, я очень хотел уйти на какие-нибудь рождественские каникулы и праздновать пару недель. Нет, токен – это очень безопасная штука, гарантирующая, что у вас есть аппаратная составляющая двухфакторной аутентификации. Но нужен ли он здесь? А если я куплю 5 раз по 1 лицензии, то мне нужно 5 токенов втыкать в сервер или каждый раз мне будут привозить новый токен, где в дополнение к существующим лицензиям будут добавлены новые? А если учесть, что токен для ЭЦП на текущий момент стоит не менее 1000 рублей, то операционные затраты производителя, ИМХО, могут быть значительными. А если сертификат ограничен сроком действия, то такие токены нужно менять. Странно, неудобно, дорого. Ну да не важно, нам для тестов сойдет.

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

Ура! Добавляем коммутаторы:

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

Ну что ж, система развернута, лицензия и оборудование добавлены. Давайте посмотрим, что она умеет.

«Хочу красиво». Интерфейс

Первое, что всегда хочется увидеть у системы управления, конечно же, какую-нибудь карту сети. И вот как это выглядит в ECCM:

Не обращаем внимание на предупреждения и аварийные сообщения – это всё исправим. Довольно неплохо выглядит, но… каждый коммутатор добавлен вручную, каждый линк добавлен вручную с указанием номеров интерфейсов. А номер интерфейса на коммутаторе будет недоступен, пока вы не настроите SNMP. То есть, если вы не настроите SNMP – вы НЕ нарисуете карту. Хотя, в качестве источника данных, есть еще LLDP и SSH. Собирать такую схему вручную и поддерживать ее актуальность будет не очень удобно. Надеюсь, в будущих версиях данный процесс как-то автоматизируется.

А что я могу взять с карты? Хммм…  Недоступно управление eLeaf2-2. Пойду проверю.

Действительно, выпал проводок. Как быстро ECCM увидит, что связь восстановилась? Достаточно оперативно (eLeaf2-2 стал оранжевым):

Что еще? Интерфейсы лежат, а я даже знаю, что это произошло из-за по-разному настроенных FEC режимов. Как бы быстро исправить? А нажму-ка я на имя коммутатора.

О, терминал! Жмем.

Удобненько… Нравится.

Интересно, а почему на карте 2 коммутатора голубого цвета, а остальные оранжевого? А-а-а, оранжевый цвет – есть проблемы. Ясно. Жмем на коммутатор, ищем проблемы:

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

С первого взгляда кажется, что проблем нет, но есть нюанс – по умолчанию проблемы показаны за «Текущий день» и это сбивает с толку. Если я выберу максимально возможный период времени, то увижу текущие проблемы:

Надеюсь, что в следующих версиях по умолчанию будет стоять «За весь период».

Ладно, как мы там изучаем новые продукты? Пробежались по меню.

«Ваше меню, пожалуйста» Разделы ECCM

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

Какие разделы есть в ECCM:

Что из этого может показаться интересным:

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

• Карта сети. Наглядно, полезно, но только до определенного количества устройств. Нам для стенда, конечно, хватит, но интересно посмотреть, как она будет выглядеть для, скажем, 50 коммутаторов в 2 ЦОД.

• ПО. Однозначно полезная штука. Очень удобно обновлять сразу несколько устройств, не заморачиваясь с командной строкой. Важно только, чтобы коммутатор был заранее настроен на корректный источник (в моем случае, используя команду «ip tftp source-vrf MGMT»).

• Шаблоны. Та самая вещь, которая делает систему мониторинга системой управления (терминал в web-интерфейсе не считается). Но шаблонами можно настроить что-то типовое, например, сменить адрес NTP-сервера. Это не самый гибкий инструмент. Настройка оборудования с использованием шаблонов – это скорее система оркестрации, чем система управления.

• Инициализация устройств. Честно сказать, я не очень доверяю автоматическим инициирующим механизмам, к тому же часто для настройки инициации приходится потратить времени не меньше, чем просто настроить и добавить в систему управления новое оборудование. Но это уже перспектива перехода к SDN-решению, а значит будет полезной. К тому же, если у вас много типовых объектов (новые магазины в ритейле, например), то функционал ZTP - отличное решение.

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

• События. Тут проще показать:

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

• Уведомления. Честно сказать, выглядит как дубликат событий. Так и не увидел практического смысла в этом разделе.

• SNMP trap и Syslog. Опять же, выглядит как дубликат событий. Не представляю, чтобы я воспользовался этими разделами здесь с учетом того, что эти пункты есть в подменю каждого конкретного устройства, где эта информация будет намного полезнее. А вот если пойти от обратного, не смотреть событие, а создать его, то эти разделы как раз и пригодятся.

• Настройки. Стандартно. Каждый настраивает как ему нравится. Из интересного – возможность настроить отправку уведомлений в Telegram.

Кажется, что все меню – это про «посмотреть», кроме разве что раздела «Сеть». Идем в сеть.

«А мы тут плюшками балуемся…» Раздел «Сеть»

Да, пожалуй, все плюшки находятся именно в разделе «Сеть».

Сразу бросается в глаза, что при добавлении новой группы устройств есть возможность выбрать тип группы «IP-фабрика».

Помните, я говорил, что мы попробуем варианты Greenfield и Brownfield разворачивания фабрики? Напомню, Greenfield – это способ разворачивания системы с нуля, когда каждая настройка передается на оборудование из системы управления. Brownfield – это когда вы уже всё настроили на оборудовании, и только потом развернули систему управления, в которую захотели импортировать имеющиеся настройки. Заинтригован, но отложим на потом.

Процесс добавления устройств вполне стандартный – вручную по IP или через автообнаружение по диапазону IP+SNMP (для определения модели).

После того, как устройство добавлено в систему, мы можем посмотреть всё те же SNMP trap/Задачи/События/Проблемы/Syslog, но уже конкретно для данного устройства, что намного полезнее, чем на главном экране в общей куче (да, там есть фильтры, но смотреть удобнее для конкретного устройства).

Из нового и интересного – раздел «Метрики». По сути, это графики на основании преднастроенных метрик:

Но, скорее всего, полезность здесь будет представлять только загрузка CPU:

Интерфейсы. Сначала я подумал, что это просто таблица с текущим состоянием интерфейсов:

Но, нажав на один из интерфейсов, я получил статистику по его загрузке, причем разобранную на broadcast/unicast/multicast/error, а это уже может быть полезно при поиске причин проблем.

Но вот чего здесь не хватило – это исторической информации по состоянию интерфейса:

• если он в down сейчас, то когда он был в up?

• не было ли у него flap за последнее время (ну, когда дергается туда-сюда)?

• интерфейс поднялся по физике или на нем дали команду no shutdown?

Меню «ARP-таблица» и «MAC-таблица». Если вы ждете, что сразу увидите тут информацию, это не так. Сначала нужны танцы с бубном: в меню «Настройки»/«Мониторинг»/«Параметры» нужно найти в секции «Тип устройства» свою модель коммутатора и для нее в разделе «Интервалы обнаружения и хранения SNMP-сущностей» включить тумблеры «ARP-таблица» и «MAC-таблица»:

И только после этого вы увидите ожидаемый результат:

Почему бы не вывести по умолчанию информацию вроде «Сбор ARP-записей выключен для данной модели. Перейдите по ссылке для настройки»?

Разделы «Блоки питания», «Вентиляторы», «Температурные датчики» – полезно быстро посмотреть, что БП не сдох, вентиляторы крутятся, а коммутатор не стекает на пол в виде расплавленного железа.

Раздел «Управление» – пожалуй, одна из самых полезных частей ECCM.

В секции конфигураций можно посмотреть историю версий и сделать их сравнение (стандартный diff):

Также можно сделать макрос (несколько команд) и отправить на исполнение на устройство. Будет полезным, если в ходе настройки вы понимаете, что «откусите себе ногу», то есть потеряете управление. Макрос выполнится полностью, даже если после первой же команды доступ пропадет. Но есть нюансы. Рекомендую перед началом использования макросов исследовать принцип их работы под конкретную версию ПО.

В общем, теперь я за сохранность конфигураций спокоен.

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

Так, что еще…

Управление ПО. Вот тут мне понравилось, правда. Во-первых, мне нравится идея активного и неактивного/резервного ПО. То есть, мне не нужно указывать, с какой конкретно версии мне следует загрузиться, я могу просто нажать «Переключить ПО».

В командной строке это выглядит вот так:

Пошло что-то не так – просто откатились на предыдущую версию. Класс!

Во-вторых, все образы лежат централизованно на сервере ECCM, и я в любой момент могу выбрать, какой именно образ мне нужно загрузить:

Вот и всё, что можно сделать с нашим оборудованием.

«Greenfield», но не чай

Теперь давайте поговорим про то, как же можно использовать ECCM для развертывания фабрики ЦОД. Сразу скажу, что вариант Brownfield, – это вообще не вариант. Почему? Да потому, что данное понятие подразумевает, что система понимает объекты настройки: сущность физического или логического интерфейса, сущность протокола маршрутизации, сущность порта доступа или uplink, сущность параметров конкретного сетевого устройства или параметров для подключаемого конечного оборудования и т.д., и т.п. То есть в режиме Brownfield система разбирает конфигурацию по этим сущностям, раскладывает их в какие-то профили и объекты, выполняет связь между ними, но ECCM этого не делает. Она просто собирает конфигурацию, хранит, сравнивает ее и может выгрузить обратно как нечто цельное.

Тогда Greenfield? Ломаем фабрику? Строим с нуля?

Знаете что? Воспользуюсь-ка я ECCM и сохраню всю текущую (рабочую!) конфигурацию.

Итак, что мы можем? Использовать шаблоны для настройки. Да, но нет. На самом деле, я вижу использование шаблонов полезным, когда нужно провести массовое применение одинаковых команд на целой куче оборудования. Но где именно это может пригодиться: смена IP-адресов NTP, Syslog, смена Community для SNMP и даже настройка Overlay! Да, одни и те же сети, VLAN, VXLAN, EVPN и пр. действительно будет удобно менять/добавлять в процессе эксплуатации, но не во время разворачивания с нуля.

А что там по поводу «добавить группу типа IP-фабрика»?

Не буду здесь приводить процесс создания IP-фабрики, к тому же он детально расписан у Eltex (https://docs.eltex-co.ru/pages/viewpage.action?pageId=627618450), но смысл в том, что ECCM должен стать DHCP-сервером для новых коммутаторов, чтобы использовать функционал ZTP.

Из интересного в мастере создания фабрики – этап валидации топологии, где можно наглядно посмотреть схему (она потом сохранится в карте сети):

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

Тогда что получается? Получается, что Underlay-фабрики мы вполне можем настроить в автоматическом режиме благодаря созданию группы IP-фабрики (всё равно в Underlay потом не залезаем), а настройки Overlay мы можем дальше настраивать используя шаблоны. Но для этого это должны быть абсолютно не настроенные коммутаторы, потому что ECCM будет заливать на них всё минимально нужное самостоятельно.

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

• что делать, если нужно заменить коммутатор Leaf?

• какие топологии поддерживаются?

• можно ли организовать Multi-Pod через Handoff?

• Какие протоколы и порты должны быть открыты между коммутаторами фабрики и ECCM (ведь посередине может стоять МСЭ)?

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

«А если найду?»

Знаете, в данном продукте можно реализовать еще много полезного функционала. Сейчас ниша российского ПО для управления сетями, я считаю, еще свободна. Нет ни одного полноценного SDN-решения (российского, для ЦОД). Очень важно грамотно начать данный марш, детально проработать механику, построить четкую Data-модель, систематизировать подход к управлению, определить принципы взаимодействия между всеми компонентами.

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

• Настройка устройств, их компонентов и логических элементов сети с использованием профилей;

• Определение соответствия выполненных настроек политикам корпоративной безопасности (compliance), включая соответствие требованиям hardening;

• Поддержка REST API;

• Возможность подмены оборудования простым переприменением родительского профиля настроек (все IP-адреса, конфигурация и пр. применяются на новом оборудовании);

• Возможность настройки RBAC-модели для обеспечения доступа только к подконтрольным устройствам (аналог Tenant);

• Автоматическое построение карты сети;

• Изменение способа внесения изменений в конфигурацию сетевых устройств (netconf?)

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

• Изменить систему лицензирования (не через токен).

Коллеги, а чего сидим? Я этот список могу долго продолжать. Помогайте и вы! Давайте поможем отечественному разработчику и накидаем наших потребностей. Не стесняйтесь, пишите в комментарии ваши хотелки. Скажу по секрету, что сейчас идеальное время для этого, ведь Eltex рассматривает развитие ECCM как одну из приоритетных задач, а мы со своей стороны можем рассказать от первого лица потребности заказчиков.

Выводы

Знаете, мне почему-то на ум пришла фраза «хвалить нельзя ругать» (поставьте запятую где считаете нужным). Я рад, что производитель сетевого оборудования разрабатывает собственную систему (управления? мониторинга?). Это действительно важно. Но в текущей реализации я пока нашел для себя полезным только хранение версий конфигурации, обновление ПО, шаблоны настроек и красивую карту сети.

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

Как там было? Поддержите отечественного производителя!

Конец

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

Ах да, вы же ждете в конце картинку из Ералаша? 

Я – инженер, я непредсказуем в решениях своих ?

До новых встреч!