Существуют ли системы автоматизации управления сетью?

Question

[lexalex]

Подразумевается в основном управление коммутаторами, маршрутизаторами и прочими аппаратными устройствами (cisco, mikrotik и другие вендоры).

Большинство устройств позволяет управление по snmp, http/https, cli через ssh/console и пр.

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

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

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

Например: Allow protocol http from host A to host B
В результате интерпретатор сам смотрит какие сетевые устройства на этом пути, и отправляет необходимые команды на них. В идеале должен работать с железками разных вендоров. Для этого нужно будет формировать базу устройств и поддерживаемых команд.

Так вот может есть подобные решения уже и я плохо искал?

p.s. мне не удалось особо ничего найти, вот только решения у Tail-f, с недавнего времени принадлежащей cisco. И то толком ничего не понятно из-за маркетингового булщита.

Answer 1

[Сергей Петриков]

Почти у каждого вендора есть такая система, но работает только с железом этого вендора, ну может еще пара самых популярных моделей других, а так SNMP + куча костылей, на новом железе с поддержкой SSH можно присобачить ansible, на старом мучаться с expect.

Comments

[lexalex]

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

[Сергей Петриков]

lexalex: Не нужен там питон, все команды идут поверх SSH

[lexalex]

Сергей Петриков: Тогда шикарно. Не могли бы скинуть ссылки на примеры или часть документации?

Ещё подсказали про NOC. Вы не знакомы с этим проектом?

[Сергей Петриков]

C NOC знаком, дважды пытался развернуть на своей инфраструктуре и оба раза после установки удалял через неделю, кривой сырой и неудобный ИМХО.
Примеры для ansible, да легко:
1) Пример попроще, зато понятный сразу stackoverflow.com/questions/26295259/ansible-ad-ho...
2) Пример посложнее, но и интересней keepingitclassless.net/2014/04/san-config-automati...
Вообще у ansible отличная документация с примерами, никуда дальше их доки можно и не ходить, ну а что делать на железе уже от железа зависит и от его cli, с cisco, dell, extreme, huawei, juniper подружилось без проблем, а вот с D-link лично у меня подружить не вышло, кретинская компания, только они умудряются в одном и том же железе на минорных различиях прошивок применять РАЗНЫЙ cli (не говоря про кучу разных прошивок одного и того же железа версий ревизий и все с разным синтаксисом и глюками).

Answer 2

[Армянское Радио]

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

Comments

[lexalex]

Спасибо за наводку, но я всё же имел ввиду мультивендорное решение с функцией программирования сети.

Answer 3

[Василий]

Что будут делать админы (в смысле чем зарабатывать на жизнь), если изобретут такую штуку?

Comments

[АртемЪ]

То же что и раньше, админить.
Это лишь инструмент повышающий удобство и только.

[Василий]

Артем: ну да, только вместо отдела, будет один, а остальные пойдут улицу подметать. )

[АртемЪ]

Нет, сколько было столько и будет.
Повышение удобства работы на количество сотрудников не влияет.

[Sanes]

Артем: вы наверное не встречались с руководителями, которые сами с усами.

[Сергей Петриков]

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

[Василий]

Сергей Петриков: как только дело дойдет до производительности, kpi и прочей лабуды, половина пойдет лесом.

[Сергей Петриков]

Василий: Кого именно? FLS? - А кто с пользователями общаться будет, рассказывать какую кнопочку нажать и прочее, админы не будет и платят им не за это, робота тоже не повесить нужно живое общение, так что без первой линии никуда они же свичи настраивают базово, порты подписывают, роутеры клиентам помогают настроить и прочая рутинная работа.

[lexalex]

Не хотел вступать в полемику, но оставлю свои 5 копеек.

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

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

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

Answer 4

[throughtheether]

Так вот может есть подобные решения уже и я плохо искал?

Я имею ввиду систему позволяющую буквально программировать сеть, которая построена на разнородном оборудовании.

Чтобы реализовать то, что вы хотите, надо, на мой взгляд, учесть огромное количество вендор-специфичных нюансов, исключений и т.д., что приводит к тому, что такие решения или решают специфическую задачу (добавить новый сервер в данном ДЦ с заранее известной топологией сети, завести VLAN, прописать ACL и т.д.) и представляют собой трудновоспроизводимую систему костылей, или не существуют.

Comments

[lexalex]

Безусловно при разработке такой системы прийдётся столкнуться с множеством нюансов и спецификой оборудования вендора, но где нет их (нюансов)? Я убеждён, что такая система сможет решать не только типовые задачи, а проблемы тонокой настройки скрыть для сисадмина и перенести на интерпретатор. В особо сложных ситуациях всегда можно подключиться к оборудование напрямую.

Тут главный вопрос - как быстро будет разрабатываться такая система.

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

[throughtheether]

lexalex:

Не понимаю, что специфического в ваших примерах?

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

[lexalex]

Если мы говорим о развертывании такой системы на уже эксплуатируемой сети, то действительно потребуется либо явное описание сетевых устройств, либо функция автообнаружения (Device Autodiscovery).

Такой функционал уже давно поддерживается большинством систем.
Происходит опрос всех или заданных устройств по snmp или cli в автоматическом режиме. Также представление о сети формируется путём прослушки пакетов таких протоколов как cdp и пр.

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