Comments 7
Спасибо за ваш труд, коллеги!
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
Из любопытсва хочется поинтересоваться: а вариант написания собственной утилиты для мониторинга/управления зоопарком устройств не расматривался?
По моему скромному опыту, NETCONF очень выручает, особенно если имеется оборудование малоизвестных вендоров, для которого нет готовых модулей Ansible. Но которое хотя бы минимальным образом поддерживает RFC 6241.
При этом можно написать своего рода «единый API» для единообразной работы со всем железом. Например, условный «get_osfp_neighbors» который может отличаться нюансами реализации для разных устройств.
Спасибо за комментарий!
NETCONF — это уже следующий уровень зрелости, как нам видится. Если ansible — это первый этап, если так можно выразиться (пусть меня поправят) — template-based automation, то netconf — это уже более программистский подход, model-driven. Здесь YANG, XML, модели данных. Сама идея структурированного, программисткого подхода к сети требует серьезной команды, но к этому все должно прийти в итоге. Идея единообразного api на базе netconf/yang — это громко, амбициозно и заслуживает отдельной беседы
NETCONF — это уже следующий уровень зрелости, как нам видится. Если ansible — это первый этап, если так можно выразиться (пусть меня поправят) — template-based automation, то netconf — это уже более программистский подход, model-driven. Здесь YANG, XML, модели данных. Сама идея структурированного, программисткого подхода к сети требует серьезной команды, но к этому все должно прийти в итоге. Идея единообразного api на базе netconf/yang — это громко, амбициозно и заслуживает отдельной беседы
Мне кажется, не совсем удачно подобран пример или я что-то не так понял в схеме. Как по мне, такие резервы должны работать всегда. Зачем ложить интерфейсы? BGP, OSPF умеют резервировать. Если у вас упали основные железки, зачем менять Косты других маршрутов? Основные ведь должны пропасть. Не хватает VRRP для автоматического переезда шлюзов обслуживаемых сетей на резервные роутеры.
Спасибо за комментарий! Мы их очень ценим)
«такие резервы должны работать всегда» — согласен, но полностью держать работающий резерв в онлайне — это значит для каждого из сегментов держать дополнительное OSPF соседство. Это довольно затратно для RP CORE коммутатора да и в целом не нужно. Часть emergency маршрутизатора всегда в онлайне и служит для резервного доступа в сеть.
«Зачем ложить интерфейсы?» — как правило сами железки не падают. Ну или крайне редко. Падает логика внутри самих устройств. Что-то дропается непонятно почему, сессии зависают, голос булькает и т.д., при этом OSPF/BGP работают и в плане сети все хорошо. Интерфейсы кладутся жестко — мы точно уверены, что нет никаких возможностей для трафика пойти через FW.
«зачем менять Косты других маршрутов?» — потому что можем) ну и для перестраховки и красоты. Они и правда пропадают, и в целом мера излишняя, но мы любим такие.
«Не хватает VRRP для автоматического переезда шлюзов обслуживаемых сетей на резервные роутеры» — Это так же в тему падения железок, но не логики. да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика. И поправить еще несколько вещей в конфиге — стандартными средствами не обойтись.
В целом задача была сделать Cold резерв в варианте «Разбейте в случае необходимости». Чтобы не было лишнего присутствия в сети и лишней нагрузки и логики. Это делается для того, чтобы никогда не пригодилось.
«такие резервы должны работать всегда» — согласен, но полностью держать работающий резерв в онлайне — это значит для каждого из сегментов держать дополнительное OSPF соседство. Это довольно затратно для RP CORE коммутатора да и в целом не нужно. Часть emergency маршрутизатора всегда в онлайне и служит для резервного доступа в сеть.
«Зачем ложить интерфейсы?» — как правило сами железки не падают. Ну или крайне редко. Падает логика внутри самих устройств. Что-то дропается непонятно почему, сессии зависают, голос булькает и т.д., при этом OSPF/BGP работают и в плане сети все хорошо. Интерфейсы кладутся жестко — мы точно уверены, что нет никаких возможностей для трафика пойти через FW.
«зачем менять Косты других маршрутов?» — потому что можем) ну и для перестраховки и красоты. Они и правда пропадают, и в целом мера излишняя, но мы любим такие.
«Не хватает VRRP для автоматического переезда шлюзов обслуживаемых сетей на резервные роутеры» — Это так же в тему падения железок, но не логики. да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика. И поправить еще несколько вещей в конфиге — стандартными средствами не обойтись.
В целом задача была сделать Cold резерв в варианте «Разбейте в случае необходимости». Чтобы не было лишнего присутствия в сети и лишней нагрузки и логики. Это делается для того, чтобы никогда не пригодилось.
Спасибо за ответы, мне стало понятнее)
Скажу сразу, мы тоже используем ансамбль, но для более мелких задач.
У вас админы/сетевые инженеры, хоть иногда, работают в консоли или все только через Ансибль?
Кажется добиться того, что подобным образом можно было восстановить всю сетевую инфраструктуру, пусть даже небольшого, предприятия её нужно заморозить и не менять ничего. Либо увольнять тех, кто полез в консоль.
«да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика» — Тут я немного поспешил. Сам с ним работал только в реализации keepalived, которая может виртуализировать адреса на других интерфейсах, включая лупбэки. JunOS так, к сожалению, не умеет.
Скажу сразу, мы тоже используем ансамбль, но для более мелких задач.
У вас админы/сетевые инженеры, хоть иногда, работают в консоли или все только через Ансибль?
Кажется добиться того, что подобным образом можно было восстановить всю сетевую инфраструктуру, пусть даже небольшого, предприятия её нужно заморозить и не менять ничего. Либо увольнять тех, кто полез в консоль.
«да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика» — Тут я немного поспешил. Сам с ним работал только в реализации keepalived, которая может виртуализировать адреса на других интерфейсах, включая лупбэки. JunOS так, к сожалению, не умеет.
Дисклеймер: я всеми частями тела за внедрение автоматизации в сетях.
Но кейс который вы рассматриваете, весьма слабо иллюстрирует преимущества этой самой автоматизации. Как вы сами в середине статьи заметили, на написание и отладку плейбука было затрачено много усилий. Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига. Так что, по сравнению с написанием инструкции для человека, экономия невелика.
Но кейс который вы рассматриваете, весьма слабо иллюстрирует преимущества этой самой автоматизации. Как вы сами в середине статьи заметили, на написание и отладку плейбука было затрачено много усилий. Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига. Так что, по сравнению с написанием инструкции для человека, экономия невелика.
Спасибо за комментарий!
Тут в первую очередь вопрос подхода, как мы и писали в статье. Каждый сам решает, как ему сделать. Мы верим, что в светлом будущем рутинные\стандартные задачи будут делаться автоматически «по кнопке», не тратя ресурсы.
Касательно вашего комментария
«Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига» — это бесспорно. Времени было затрачено сильно много. Но тут классический момент — на этом примере было изучено много подводных камней, которых никак и нигде не узнаешь. Какие модули для какого оборудования лучше использовать, какие параметры модулей, и как лучше вообще не делать. Конкретный пример не про экономию — можно было написать блокнотик с командами и положить его себе под кровать, это проще, и тоже сработает. Это скорее про возможности, подход и средства. Преимущества данного конкретного примера — сеть перестраивается полностью по кнопке и правильно, и про это можно не думать.
«написанием инструкции для человека» — вот здесь главный момент и от чего мы хотим уйти. Не должно быть никаких инструкций для человека — это вообще не человеческое) инструкции они для машин. Если есть подробная и понятная инструкция — доверим это машине.
Тут в первую очередь вопрос подхода, как мы и писали в статье. Каждый сам решает, как ему сделать. Мы верим, что в светлом будущем рутинные\стандартные задачи будут делаться автоматически «по кнопке», не тратя ресурсы.
Касательно вашего комментария
«Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига» — это бесспорно. Времени было затрачено сильно много. Но тут классический момент — на этом примере было изучено много подводных камней, которых никак и нигде не узнаешь. Какие модули для какого оборудования лучше использовать, какие параметры модулей, и как лучше вообще не делать. Конкретный пример не про экономию — можно было написать блокнотик с командами и положить его себе под кровать, это проще, и тоже сработает. Это скорее про возможности, подход и средства. Преимущества данного конкретного примера — сеть перестраивается полностью по кнопке и правильно, и про это можно не думать.
«написанием инструкции для человека» — вот здесь главный момент и от чего мы хотим уйти. Не должно быть никаких инструкций для человека — это вообще не человеческое) инструкции они для машин. Если есть подробная и понятная инструкция — доверим это машине.
Sign up to leave a comment.
Network automation. Случай из жизни