[seagull]

Написал скрипт для управления Ip/Mac/Port binding, но думаю тут над одним вопросом - когда делать save на свитче? Каждый раз при прописывании правил - нехорошо вроде, потому как сохранение - это секунд 30, и если автоматом на свитч несколько клиентов разом будут прописыватся, то последствия будут непредсказуемые. да и ресурс флеша на запись не вечный вроде. Проходить кроном по свитчам раз в несколько часов, и делать сейв - при неожиданной перезагрузке свитча данные потеряются, глюки ловить умучаешься. Коллеги, как вы решаете такие проблемы?

[sol]

Биндинги пишутся в некую очередь, реализованную как таблица в SQL + lock table, файл + lock или каталог + lock file, организованный как в сендмейле. И ОДИН скрипт через время разносит накопленные биндинги по свитчам. Это что-бы избежать коллизий. С сейвом есть несколько стратегий. Ресурс флеша - 1000 записей. Никогда не будет столько привязок/перепривязок на одном свитче. Посему стратегия первая: после модификации биндингов - безусловно сейвить. Стратегия вторая - ничего не сейвить вообще. При этом скрипт привязок придется снабдить минимальным интеллектом и сделать из него гровелер. Скрипт запускается раз в 5 мин, обходит все свички и сравнивает, что есть и что должно быть. И правит. При этом снимается проблема очереди заданий и все скатывается к плоской табличке в которую просто вносятся изменения. У меня сделано вторым способом.

 

[terrible]

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

 

После сейва повторная проверка таблицы производится через неделю для профилактики, если конечно таблица не была ранее изменена. Все рады, в том числе и свич :)

 

Происходит это примерно вот так:

 

18:05:01 Контроль свичей Проверка параметров | Проверка свича dev.1355: ошибок не обнаружено

 

18:04:53 Контроль свичей Контроль IMB | Свич: dev.1355

Добавление ARP записи: 192.168.7.62:40-61-86-0c-6d-ad, port: 0, vlan: -> Успешно

 

18:03:57 Контроль свичей Контроль IMB | Свич: dev.1355

Добавление ARP записи: 192.168.7.62:40-61-86-0c-6d-ad, port: 0, vlan: -> Провал

Удаление ARP записи: 192.168.7.119:c8-2e-a9-c6-21-82, port: 0, vlan: -> Успешно

Изменено 11 августа, 2010 пользователем terrible

[littlesavage]

Как у terrible, только вообще без сейва.

Крутится скрипт, сверяет базу IMB на коммутаторе с основной базой, по имеющимся расхождениям вносит необходимые изменения.

Коммутаторы перезагружаются очень редко. Через несколько минут после перезапуска коммутатора "приходит" скрипт и выправляет всю таблицу IMB.

 

При необходимости, сверялка выполняется кнопкой из веб интерфейса. Коммутаторы блокируются MySQL'ым GET_LOCK/RELEASE_LOCK, за счет этого можно смело запустить несколько копий скрипта, хоть на разных машинах.

Изменено 11 августа, 2010 пользователем littlesavage