alibek Опубликовано 6 июля, 2015 · Жалоба Не подскажите, как вы работаете с конфигами? У меня сейчас с этим небольшой бардак — где-то конфиги сохраняются на FTP/TFTP, где-то просто логгируются управляющие сеансы, где-то ничего не сохраняется. Хочется сделать "по взрослому", чтобы вся конфигурация сохранялась централизованно, с контролем версий. Не посоветуете какое-нибудь более-менее коробочное решение, чтобы самому все не делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 6 июля, 2015 · Жалоба По взрослому, это, наверное NOC. Я делаю вот на этом при помощи вот этого. Применяю только для D-Link, т.к. на доступе только он. Как раз в данный момент автоматизирую процесс. Briseis шлет на устройство команду save config, через 5 секунд - upload config, еще через 5 - download config. Конфиги генерятся dracon'ом, который пишет в MongoDB все уникальное (неизвестный ранее MD5), что через него пролетело. И есть front-end для просмотра базы монго и поиска отличий в конфигах. А так параллельно еще NOC собирает конфиги, но свой велосипед забавнее же. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DejaVu Опубликовано 6 июля, 2015 · Жалоба судя по вашим запросам вам нужен rancid :) http://www.shrubbery.net/rancid/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2015 · Жалоба alibek по-взрослому это будет поставить NMS от каждого вендора и собирать ими конфиги. ну правда NMS некоторых недовендоров это не умеют, так это оборудование не взрослое :) вообще, rancid(хранение в cvs и git(последние версии)), noc(хранение в БД) или тупо свои скрипты(это будет быстрее чем устанавливать и настраивать noc) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 6 июля, 2015 · Жалоба это будет быстрее чем устанавливать и настраивать noc Ну NOC мне интересен безотносительно хранения конфигов, а как инструмент мониторинга/учета. Я его правда сейчас не использую, но планирую со временем. Однако насколько я понял, NOC просто хранит конфиги за определенный период времени. CVS или SVN в этом плане удобнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alex39x Опубликовано 6 июля, 2015 · Жалоба У нас rancid + cvsweb. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 6 июля, 2015 · Жалоба (это будет быстрее чем устанавливать и настраивать noc) это в первый раз :) на пятой попытке можно управиться часа за четыре :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 июля, 2015 · Жалоба zi_rus ещё у нока периодически умирает дефолтная mongodb (хотя это как бы не проблема нока, но всё же). я сам особо не пользуюсь. коллеги используют как удобную бэкапилку конфигов и просмотр их Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 7 июля, 2015 · Жалоба не знаю что ты подразумеваешь под дефолтной монгой, у меня с этим проблем не было, сбор конфигов кстати очень удобный, а с недавних пор еще и валидировать их можно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 14 июля, 2015 · Жалоба Однако насколько я понял, NOC просто хранит конфиги за определенный период времени. diffы тоже поддерживаются Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 15 июля, 2015 · Жалоба В ноке физически хранится последний конфиг в целом виде, а предыдущие в виде диффов от него. Можно промежуточные явно целыми делать. Ключевое слово для раскуривания - gridvcs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 15 июля, 2015 · Жалоба А на практике это требуется? В смысле как часто и по каким причинам требуется смотреть старый конфиг? Чтобы узнать как были настроены вланы и интерфейсы, чтобы поднять что только что завалил? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 15 июля, 2015 · Жалоба Хочется сделать "по взрослому", чтобы вся конфигурация сохранялась централизованно, с контролем версий. Не посоветуете какое-нибудь более-менее коробочное решение, чтобы самому все не делать? Научить людей пользоваться git'ом не судьба? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 16 июля, 2015 · Жалоба Научить людей пользоваться git'ом не судьба? Кроме git'a потребуются костыли для опрашивания свичей и слива конфигов (ну на цисках есть archive, а на остальных?). Плюс еще неплохо бы валидацию прикрутить. Плюс... Короче, одним git'ом тут точно не обойтись Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 16 июля, 2015 · Жалоба Научить людей пользоваться git'ом не судьба? Зачем давать на откуп фактору человеческих ошибок то, что можно автоматизировать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 июля, 2015 · Жалоба А на практике это требуется? В смысле как часто и по каким причинам требуется смотреть старый конфиг? Чтобы узнать как были настроены вланы и интерфейсы, чтобы поднять что только что завалил? :) реально требуется. я как-то искал одного клиента с белыми /30 в конфигах за 10 лет (тупо grep-ом). или например после модернизации что-то забыто или ещё что-то, вообщем много вариантов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 16 июля, 2015 · Жалоба Да, реально требуется. Особенно если вы не единственный кто может завалить. Тем более что диффы весят немного, особенно если вырезать из конфига всякие ненужные динамические строки типа "generated <дата время>" и закидывать только реально изменившиеся конфиги Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 16 июля, 2015 · Жалоба Кроме git'a потребуются костыли для опрашивания свичей и слива конфигов (ну на цисках есть archive, а на остальных?). Плюс еще неплохо бы валидацию прикрутить. Плюс... Короче, одним git'ом тут точно не обойтись Какой-то бардак. 1. Конфиги, которые генерятся, сливать никуда не нужно, редактировать ручками их все равно нельзя. 2. Проблема, как я понял, - это конфиги, которые ручками правятся. Вот тут их все в репозитории и держите и всей командой в репозитории с ними и работаете (не на свичах!), в общем-то для такого git и задумывался. В этот же репозиторий ложите скрипт деплоя этих конфигов на свичи, с проверкой, что они задеплоились (тут уже зависит от свича, по хорошему он не должен принять кривой конфиг, а вернуть ошибку, так что скрипт должен прерваться и дать ее починить). Если все-таки допустили логическую ошибку или нарвались на баг и что-то поломалось, тут же git'ом откатываетесь и деплоите предыдущую версию, а как разберетесь и деплой будет успешным - протолкнете изменения в апстрим. Влияние ошибки можно уменьшить, если деплоить сначала на тестовые свичи или деплоить только на какие-то пару свичей, погонять немного и потом только на все. Есть еще ньюансы с командной работой, но я думаю тут на них никто не наткнется. В любом случае, коробочных решений тут быть не может - просто плохо понимаете, чего хотите. Не делайте фичи хотелками, поймите проблему и делайте решение проблемы хотелкой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xcme Опубликовано 16 июля, 2015 (изменено) · Жалоба У меня вот нет таких проблем. Речь про коммутаторы доступа или про агрегацию/ядро? На доступе у меня настройки условно разбиты на 3 части: 1. Управление. Настраивается вручную 1 раз при установке устройства. 2. Пользовательские vlan'ы. Также настраиваются 1 раз вручную при установке. При схеме vlan-на-свич у меня редко когда больше 2-3 пользовательских vlan на коммутаторе. 3. Все остальное. Генерируется на 100% автоматически. То есть если не крутить управление и эти 2-3 влана, то сломать попросту нечего, хоть 1 человек ковыряется, хоть 10. Если вдруг что-то не так - просто заливаем с сервера конфиг, который будет сгенерен как раз в этот момент и потому актуален. Нет такого, что кто-то постоянно копошится, экспериментирует, правит, пробует и т.п. Новые фичи отлаживаю я, затем применяю в генераторе конфигов и дальше все просто. С агрегацией/маршрутизацией чуть иначе, там 100% ручные настройки, но сеть не так часто перестраивается, чтобы там что-то менялось. Глобальные изменения делает один человек, протаскивать вланы могут все. Но и тут не возникает нужды постоянно делать диффы и что-то там искать. Бекапы делаются, но нужны они очень редко, раз в несколько месяцев, как правило. Изменено 16 июля, 2015 пользователем xcme Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 16 июля, 2015 · Жалоба Понимание того что это бывает полезно приходит с третьей-четвертой сотней l3 свитчей/роутеров или тысячей пятидесятой свитчей доступа. Потому что к этому времени в них начинают ковыряться шаловливые ручки дежурных администраторов, младших администраторов, просто неадекватных администраторов. И офигенно удобно когда что-то "само сломалось" просто глянуть дифф и увидеть что поменялось в конфиге. Git неудобно. Ибо нужно обвешивать костылями сбора и заливки, жрет больше места, нужно как-то бэкапить и реплицировать, геморройно искать, сложно и неудобно интегрировать в морду мониторинга (и еще более сложно научить пользоваться людей без нее), валидация вообще из области фантастики. А монгу можно поставить из репозитория одной командой. Ну и вся реализация gridvcs у меня по мотивам noc занимает полсотни строк, которые оформляются как модуль. Заливать что-то в конфиг из таких мест вообще зло. Как вы будете проверять что все дошло и корректно применилось? А если неправильно и вы сломали пару тысяч/десятков тысяч свитчей? Деплой изменений вообще отдельной системой делать нужно, причем бОльшая часть кода в ней это проверки. И поверьте, я пробовал git, svn, mercurial, хранение тупо в файликах и все это сливает текущему решению по полной. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nu11 Опубликовано 16 июля, 2015 · Жалоба Поддерживаю идею с монгой. Кластер из коробки, быстрая и удобная. Вещь на все случаи жизни. вся реализация gridvcs у меня по мотивам noc занимает полсотни строк, которые оформляются как модуль Поделитесь? Интересно на код взглянуть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 16 июля, 2015 · Жалоба Git неудобно. Ибо нужно обвешивать костылями сбора и заливки, жрет больше места, нужно как-то бэкапить и реплицировать, геморройно искать, сложно и неудобно интегрировать в морду мониторинга (и еще более сложно научить пользоваться людей без нее), валидация вообще из области фантастики. ... И поверьте, я пробовал git, svn, mercurial, хранение тупо в файликах и все это сливает текущему решению по полной. Неа, git вы вообще никогда не видели в глаза. Как и mercurial. Их, в отличии от всякого древнего хлама, типа svn и cvs, не нужно ни бэкапить, ни реплицировать. Не нужно ставить никакие монги и серверы репозиториев. Нужно только научиться пользоваться. Но, опять же, если вы позволяете править на свичах нагенеренные конфиги, вы сами создаете проблемы, которые сами пытаетесь решить костылями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 16 июля, 2015 · Жалоба Неа, git вы вообще никогда не видели в глаза. Как и mercurial. Их, в отличии от всякого древнего хлама, типа svn и cvs, не нужно ни бэкапить, ни реплицировать. Не нужно ставить никакие монги и серверы репозиториев. Нужно только научиться пользоваться. Но, опять же, если вы позволяете править на свичах нагенеренные конфиги, вы сами создаете проблемы, которые сами пытаетесь решить костылями. До. Не нужно. Нагрузка на сервер зашкаливает - реплицировать и размазывать не нужно. И диски не дохнут в серверах никогда. А есличо, потерянные данные лично Линус Торвальдс восстановит. Да и разворачивать сам хаб у себя не нужно, гит в светоносном эфире хранит все и работает. Или вы из этих, любителей на сервера сторонних сервисов где-то в интернете выкладывать? Интересная идея запретить. Запретить всему штату инженеров трогать что-либо и потом просто жить на работе ничего не успевая. А есличо и в другой город мотнуться не проблема там поработать часик. Хайлоада и больших масштабов вы походу не встречали, уважаемый. Поделитесь? Интересно на код взглянуть. Так прямо в NOC Project в открытых сорцах модуль gridvcs лежит, гуглится за пару минут. Я его только под реалии нашей системы мониторинга подправил немного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 16 июля, 2015 · Жалоба До. Не нужно. Нагрузка на сервер зашкаливает - реплицировать и размазывать не нужно. И диски не дохнут в серверах никогда. А есличо, потерянные данные лично Линус Торвальдс восстановит. Да и разворачивать сам хаб у себя не нужно, гит в светоносном эфире хранит все и работает. Не позорьтесь, такой бред писать, почитайте о работе git хоть немного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 16 июля, 2015 · Жалоба Ну просветите меня. Что такого космического умеет нынче гит что спасёт хранилище от сдохших дисков или размажет запись по нескольким серверам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...